Introduction

In this articlen I discuss distributed architecture and how .NET fits into it.

Before discussing distributed architecture, it is worth looking at the past. In doing so, you can see that building distributed systems is not a very old issue and various technologies have been provided by different vendors to achieve the goals. This includes technologies such as DCOM, Corba, and more.

In the past, many systems were implemented using these older technologies, and many more are still being implementing with them. Each of these technologies have their own advantages and disadvantages.

These older technologies (DCOM/CORBA) provide specific soltions with great limitations. They can also be difficult to implement. Moreover, each of these had their own place.

Enter .NET

Now, let's dig into the .NET world...

With .NET, Microsoft performs similar tasks to what the older technologoies provided. It does this with remoting, Web services, and COM+. COM+ was previously available, as were Web services. With .NET, however, Web services are now easier to develop and implement. .NET provides easier ways to develop and implement Web services!

Remoting is the new term, while COM+ has been around. You can use these technologies similarly to previous DCOM components.

Even though remoting, COM+, and Web Services are different technologies, they still can be seamlessly integrated with each other. Before getting into this integration, first you should know when to use each of these three services.

1. Remoting: Operates inside the firewall, usually within an enterprise. It is generally faster then Web services. This speed is due to its binary transfer protocols. Its transportation mode is TCP (recommended) although HTTP is also supported. Remoting services cannot cross a firewall; however, they can use SOAP and HTTP to achieve this goal. Performance is not optimized when using SOAP in this way; thus, Web services are a better bet for this.

   You have to write an application for hosting the remote service because it does not ship with any default hosting services. Also, you have to provide your own security features, although you can host it in IIS to take the advantage of IIS secutity. The other hosting options might be Windows services (this helps in hosting the remote obejct with the OS security defined for Windows services and also you can schedule it).

2. Web Services: Web services are not a new tool but .NET gives them the necessary platform to achieve popularity among developers. The characteristics of Web services are HTTP channels with SOAP messaging of XML-formatted data. Because it uses SOAP and XML, it can easily cross firewalls and is the platform-independent way to get to a service. Web services are slower than remoting due to the SOAP syntax and text transfer protocols. There is no requirement for hosting Web services because they are automatically hosted by IIS.

   You should keep in mind that Web services is schema based, whereas .NET remoting is object based.

3. COM+: COM+ is all about providing services to the business components. It may be transactions, JITing, pooling, security, or something else. You can use COM+ to distribute your component to different locations and manage the componets at a centralized sever

This link again provides you some insight into the topic: http://www.microsoft.com/mspress/books/sampchap/6723.asp.

The Decision

Many programmers new to .Net will initially be confused on why Microsoft provides three different distributed technologies. I was initially, when I first learned .Net.

When you think through all three of these technologies, you will find that Microsoft has provided the best architecture, and that each one has specific focus and advantages and you will find that all three can be integrated.

Following are some of the decision making points:

Let me made it clear again that COM+ is all about providing service to serviced components where as Web service and remoting provide access to remote services. You can deploy services to different systems using the export option in COM+ (for windows application developement). You can also use IIS with COM+ in Web application to take the advantages of the services.

If your application going to be used inside your firewall always opt for remoting. You can use remoting for your local intranet applications. In this case you may host the remote object in IIS.

The next thing is Web service. If you are opting for your application to be accessed across the internet or from a universal repository, then this option is best as Web services can easily cross the firewall.

Web services provide the information on their interfaces, and they can be easily understood. Because Web services follow the Soap and xml format, they can easily be integrated with other platform and languages. COM+ differs in that it does not provides any expose of intefaces to outside world. Remote objects contain metadata; however, you still have to extract it on your own if you want to expose it for the consumer.

The Integration and Co-working of These Technologies

COM+ Versus Remoting

To register your component with COM+, your component must be inherited from serviced components (though you can configure your component to take the advantages of the serviced component class with out inherit it from serviced components with setting the required attributes for the class for this follow the link http://www.15seconds.com/files/031008.zip ) and to be designated as remoteobject it should be derived from marshalbyrefobjects (I am not considering MBV).

I will now describing the interrelation:

.NET Remoting and Enterprise Services are tightly integrated. See this link for a better understanding.

The serviced component class is derived from marshalbyrefobjects so it has already has the remoting features built into it. You do not need to do anything to marshal it. You can simply host this class by writing an appropriate server application and a client to consume it. (Initially I thought as VB .Net didn't support multiple inheritence, and for this integration I required features from two classes). I used interfaces and containment to implement this. (Thanks go to Mike for showing me the right idea at the right time.)

Before you explore the use of remote component together with COM+, you should look at a few more things. This includes looking at the garbage collection of remoteobject, the jit issue, and more. I am not going to cover these here.

COM+ Versus Web Services

For the interrelation of COM+ and Web services, remember that you can publish a COM+ component as a Web service. In the Component Services administrative tool, create a COM+ application on Windows XP. Import the DLL you created as a component. Navigate to the Activation tab of the COM+ application Properties page, and select Uses SOAP. Enter a SOAP Vroot such as VnetSoap, and click OK. The application is now published as an XML Web service and can be activated using Soap.

How you consume a Web service through Soap is an entirely new topic, so I will not elaborate on it as it is very simple. The next side of the story is that Web services can take part in your COM+ transactions and hence can be part of your COM+.

Remoting and Web Services

For this you can use soapsuds — which create XML schemas describing services exposed in a common language runtime assembly. It also creates runtime assemblies to access services described by XML schemas. A schema definition can be a local file or it can be dynamically downloaded from the Internet. Thus Web services can be consumed through remoting.

Creating Simple Applications

Building a Web service:

Start a new solution select asp.net Web service project. Your service must inherits from System. Here is the simple code to get the data and also performing update, insert, and delete

Imports System.Web.Services
Imports System.Data.SqlClient
Public Class Service1
    Inherits System.Web.Services.WebService
#Region " Web Services Designer Generated Code "

  <WebMethod()> Public Function getdata(ByVal strcon As String, _
                ByVal strsql As String) As DataSet
        Dim con As New SqlConnection(strcon)
        Dim ad As New SqlDataAdapter(strsql, con)
        Dim ds As New DataSet()
        ad.Fill(ds)
        Return ds

    End Function

    <WebMethod()> Public Function UpdateDeleteInsert(ByVal strcon _
                  As String, ByVal strsql As String) As String
        Try

            Dim con As New SqlConnection(strcon)
            Dim cmd As New SqlCommand()
            con.Open()
            cmd.Connection = con
            cmd.CommandText = strsql
            cmd.ExecuteNonQuery()
            con.Close()
            Return True
        Catch ex As Exception
            Return ex.Message
        End Try
    End Function

End Class

Optionally you can set transactionoption, caching, etc., with appropriate attribute to the Web service. For example like <WebMethod(CacheDuration:=60)>

To consume the service:

Add a Web reference to the respective service and

  Dim obj As New localhost.Service1()
        DataGrid1.DataSource = obj.getdata(TextBox1.Text, TextBox2.Text)
        DataGrid1.DataMember = "tablename"
        DataGrid1.Show()

To invoke the update, insert, or delete simply call the method through obj1.updateinsertdelete

Now to get this service through remoting use soapsud.exe. Here is the syntax:

soapsuds {-url:schemaUrl | -types:type1,assemblyname[,serviceEndpoint]
[;type2,assemblyname][...]] | -is:schemafile | -ia:assemblyfile} [options

Example:

soapsuds -url:http://localhost/Service/MyService.soap?wsdl 
-os:MyService.xml

The following command downloads a schema from a URL and generates code.

soapsuds -url:http://localhost/Service/MyService.soap?wsdl -gc

The following command downloads a schema from a URL, saves it to a file, and generates code.

soapsuds -url:http://localhost/Service/MyService.soap?wsdl 
-os:StockQuote.xml -gc

The following command downloads a schema from a URL, generates code, compiles, and generates an assembly.

soapsuds -url:http://localhost/Service/MyService.soap?wsdl 
-oa:StockQuote.dll

The following command converts a type to a schema and saves it to a file.

soapsuds -types:MyClass.MyMethod,Service -os:StockQuote.xml

The following command converts a type to a schema and generates code.

soapsuds -types:MyClass.MyMethod,Service -gc

The following command converts a type to a schema, saves it to a file, and generates code.

soapsuds -types:MyClass.MyMethod,Service -os:MyService.xml -gc 

Be aware of this also from msdn suport

http://support.microsoft.com/default.aspx?scid=kb;en-us;828987: BUG: A Client That Is Linked with the Soapsuds Proxy DLL Throws a Remoting Exception at Run Time

Here is the link for getting metadata assembly using soapsud: http://support.microsoft.com/default.aspx?scid=kb;en-us;323491

Creating a Simple Remoting Application

The following are the steps for creating a simple remoting application:

1. Create your remote object. It should be derived from marshalbyrefobjects (or derived it from serviced components by including a reference to enterpriseservices).

Imports System

Public Class ServiceClass
   Inherits MarshalByRefObject
public sub new()
end sub
public function remotfunc
end function
end class

2. Create a host application which will host the remote object:

Imports System
Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.Channels
Imports System.Runtime.Remoting.Channels.Http
imports ServiceClass
Public Class ServerProcess

   Public Shared Sub Main()

      Dim channel As New HttpChannel(8080)
      ChannelServices.RegisterChannel(channel)

        RemotingConfiguration.RegisterWellKnownServiceType
                (GetType(ServiceClass), "ServiceClass",
                 WellKnownObjectMode.SingleCall)

3. The client to access the remote object :-

Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.ChannelsImports
        System.Runtime.Remoting.Channels.Tcp
Imports ServiceClass


Dim channel As TcpClientChannel = New channel TcpClientChannel
    ChannelServices.RegisterChannel(channel)
    RemotingConfiguration.RegisterWellKnownClientType
            (GetType(ServiceClass),
            "tcp://localhost:54321/ServiceClass")
    dim db as new serviceclass
db.remotefunc

To Create COM+ Component:

1. Create a class library application that inherits from serviced components.
2. Define the attributes for the class as per the requirement like transacoption.require and activationoption=library etc.
3. Strongly sign the assembly and use regsvcs to register it in COM+

Notes:

1. Do not rely on lazy registration (recommended)
2. Be sure to give an appropriate version
3. If you want to expose your ServicedComponents by remoting. You can host your ServicedComponents in IIS by selecting uses Soap on the Activation tab of the properties for the COM+ application. You can use a custom host that hosts the ServicedComponents from a COM+ library application.

Conclusion

Before you select any architecture, be sure that it fits into the requirements and although you can optimize one architectture to fit into the other, do use the one that has been optimized for your needs.

For additional details see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfSoapsudsUtilitySoapSudsexe.asp.

Any comment, suggestion, and recommendation will be highly appreciated. You can reach me by clicking on my name at the top of this article.

shreeman

References:

www.ingorammer.com/Conferences/BelgianDotNetUserGroup/ Remoting_Vs_WebServices__Brussels.pdf

p2p.wrox.com/archive/pro_vb_dotnet/2002-06/4.asp

weblogs.asp.net/rhurlbut/archive/ 2004/04/01/106015.aspx

www.stylusinc.net/technology/soap/soap2.shtml

and MSDN