Business Objects for .NET Remoting using C#Builder - by Lino Tadros

By: Lino Tadros

Abstract: This article will discuss the 3 different ways of architecting Business Objects for .NET Remoting systems without having to deploy any of its code to its client applications.

Untitled Document Business Objects in .NET Remoting with C#

As we wait for a new version of the Delphi Compiler for .NET, let’s focus on the .NET Remoting technology as a serious contender for Distributed applications using the new C#Builder product just released by Borland Software Corporation.

This article will discuss the logical architecture of a Remoting server and will discuss the different possibilities available to us using this technology.

As we have seen from my previous article on .NET Remoting on the BDN about 100 years ago (Sorry about that!), we can encapsulate the business logic of a Distributed Server in a separate assembly as long as our main object inherits from MarshalByRefObject.

The reality of the matter is, I wrote that demo, in the previous article, to make it super clear the separate pieces needed to make .NET Remoting work, on the other hand, having the Client share the implementation code of the business object was a pretty bad idea. Nobody will ever want to do that!

I will show you 3 different ways of solving this problem in this article.
First, let’s create a Business Object in C#Builder as an Abstract Class:


This is accomplished by creating a new Class Library in C#Builder and calling it BORemoting then adding the code in the screen above to create the Borcon2003Abs abstract class with all its methods.

We can compile this class library and we would be able to produce an assembly called BORemoting.dll that really has no implementation for most of our class and its abstract functions.

Then we will have to create a new Class Library in a completely separate project and reference the BORemoting.dll assembly.

We are going to call the Class Library “BORemotingImpl” where we will inherit from the abstracted class and override all the abstracted functions as shown in the next screenshot.


Compiling this project group will create 2 different assemblies, the first is BORemoting.dll that will be referenced from all Client applications and the BORemotingImpl that will be referenced from all Server applications for the .NET Rremoting system that you would like to build.

The second way of doing this is probably my favorite, by using Interfaces!

It is really very close to what we did already but cleaner by using Interfaces which was meant to be used in such an occasion for abstracted functionality and encapsulation of the code.

Create a new Class Library called “InterfaceRemoting” and create an Interface IBorcon2003 as shown below and compile. That will produce an assembly called “InterfaceRemoting.dll”

Then like we did before, add a new Class Library, reference the previous assembly, implement a class that inherits from the Interface IBorcon 2003 and finally implement all methods of the interface.


It sure is cleaner and makes sense. For all clients, the reference will always be based on the Interface assembly and the server will be based on the implementation assembly so you never have to ship the implementation of your intellectual property to anyone that really does not need to have it.

The third and final method is built into the .NET Remoting framework and works very well. It requires some understanding of using the .NET Framework utilities that ship with the framework to get it to work, it is called SOAPSUDS.

SoapSuds functionality is to extract metadata or type definition from a running server or an implementation assembly and generate a new assembly that contains only this meta information.

It is a Command line utility that can generate a new assembly based on a URL of where the server is running or an existing assembly that contains the implementation.

Soapsuds –url:<url> -oa:<newAssemblyname>.dll
Or
Soapsuds –ia:<oldAssembly> -oa:<newAssembly>.dll

Remember, although it is called SOAPsuds, it is really not only for SOAP Remoting server only but can easily be used with TCP/IP Remoting servers as well by passing –nowp on the command line to the end of the soapsuds command to not generate Wrapper Proxies. We will discuss this subject in a later article in details.

We are just starting the series of articles for .NET Remoting, I expect to go for 5 or 6 parts just on this subject. I expect to start discussing the Serializable attribute, client activation, LifeTimeServices, Sponsors, Marshellers, and lots of more fun stuff.
Till next time, have fun!

Falafel Software is all about making the most of software development technology in order to complete the project on time and on budget with best possible user experience. Falafel Software offers a comprehensive suite of software development solutions ranging from strategy to design to implementation that businesses need in order to realize high returns on their investment.

 

Copyright ) 2003 Alain Tadros, Falafel Software Inc.
ALL RIGHTS RESERVED. NO PART OF THIS DOCUMENT CAN BE COPIED IN ANY FORM WITHOUT THE EXPRESS, WRITTEN CONSENT OF THE AUTHOR.

Server Response from: SC2