Webservice Vs Remoting

Webservices are ideally suited for clients outside the firewall calling components on your
server over the Internet. If both your clients and components are inside the firewall, Web
services may work fine; however, all of your data travels through a Web server, which
can slow performance. To speed things up, Microsoft provides a binary mechanism called
remoting.

.NET remoting
While Web services are arguably the best way for clients outside of your organisation to
access components, what about components within your organisation? Many companies
are building Web services and using them internally. There is nothing wrong with this
approach, but it doesn't provide the best performance. If components are created in .NET
and the client applications are .NET, you can place components on shared servers and
access them via remoting.

Remoting is the .NET technology that replaces DCOM allowing you to communicate
between a client application and components in a binary format. As a result, remotable
components are faster than Web services. However, creating remotable components is
more difficult because you must add additional code to your components. This code isn't
much more complicated than its Web service counterpart, but you cannot directly
instantiate a remote component. Instead, you must create a host application that
instantiates the component and listens for requests. The good news is that this host can be
a Windows service, a Windows application, a console application, or anything that can
run and hold the object open.

Not only do you have to create a host application, you must also make several decisions
about the remotable object, such as which channel to use. .NET supports both HTTP and
TCP channels. The HTTP channel actually uses the SOAP protocol to transport messages
to and from remotable objects; this means all messages are serialised to XML. The TCP
channel uses a binary stream to transport the messages.

Next, you must choose between two activation modes: Singleton and SingleCall.
Singleton types have only one instance of an object at any time. All client requests are
serviced by that single instance. This allows you to "share" data between requests or,
more likely, maintain state between requests. SingleCall types, on the other hand, create a
new instance of the object for each client request. SingleCall objects are more like Web
services because they are stateless and are created and destroyed for each request.

.NET is architected in such a way that remotable components can change channels
without being recompiled. You can place the channel information in a configuration file
and change from TCP to HTTP or vice versa without recompiling the application.
Similarly, you can change a configuration file for the client to match the channel that the
host is using.
Quick code comparisons
The entire code for the Web service follows:
<%@ WebService Language="VB" Class="ConvertMoney" %>
Imports System.Web.Services
<WebService()>Public Class ConvertMoney
Inherits WebService
<WebMethod()>Public Function _
PoundsToDollars(BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class

Here is the code to implement the same thing with a remotable component:

Public Class ConvertMoney

Inherits System.MarshalByRefObject
Public Function _
PoundsToDollars(ByVal BritishPounds As Double) As Double
Return BritishPounds * 1.44
End Function
End Class

The component looks simpler. In fact, the only difference is that it inherits from
System.MarshalByRefObject. But remember, you need to build a host application that
instantiates the object and listens for requests. The code for the host object could look
like this:

Imports System.Runtime.Remoting
Imports System.Runtime.Remoting.Channels
Imports System.Runtime.Remoting.Channels.Tcp
Imports RemoteConvertMoney
Module Module1
Sub Main()
Dim tcpChannel As New TcpChannel(7777)
ChannelServices.RegisterChannel(tcpChannel)
Dim ChangeMoney As New ConvertMoney
RemotingServices.Marshal(ChangeMoney, "ConvertMoney")
Console.ReadLine()
End Sub
End Module
In this case, the host application is a console application. You start the application and it
launches a console application and creates the object. The console application runs until
someone presses the [Enter] key, and the object is available until needed.
As you can see, the amount of work required to create the remotable component is more
than the Web service.

Make the choice

There is no absolute answer to whether you should choose Web services or remoting in
most cases. If your entire distributed application is inside your organisation firewall and
performance is critical, remoting via the TCP channel is the best choice. If the entire
application is inside the firewall and performance isn't as critical, or if you want to keep
things as simple as possible, Web services is a better choice.

But, if you need to allow access to clients other than .NET, you'll need to use Web
services regardless of whether or not the client is inside or outside the firewall. In the end,
the choice is left to the developer, so you'll need thorough knowledge of both
technologies to make a proper decision.

.NET , COM, COM+

.NET provides a completely new approach to creating and deploying components. They are
also known as Assemblies. With COM , the developer had to register the component on the
server, i.e it's information had to be updated in the system registry. The purpose was to keep the
information of the components in a central location so that COM+ can find the appropriate
component. With .NET assemblies, the assembly file encapsulates all the meta data required in
special sections called Manifests. In .NET , for an assembly to be available to the client , it only
has to be in the same directory as the client application. When the client application requests for
an instance of a particular component , the .NET runtime searches the same directory for the
assembly and then interrogates the assembly's manifest to know the various classes that the
component provides. Since the information about the component is kept in manifests, the
developer doesn't have to register the component on the server and several versions of the same
component can safely co-exist together on the same machine.

Creating a .NET assembly is a lot like creating a VB6 component, the developer only has to
worry about the business logic, all the background plumbing code is generated by the .NET, also
since the .NET runtime maintains garbage collection externally, the component does not have to
worry about keeping it's reference count as was done in COM with the help of the IUnknown
Interface.In short, creating a .NET assembly is easier than creating a VB6 COM.
Pure .NET assemblies can't be registered under COM+ services since they comply with a
different standard than the original COM's binary one. In the face of .NET, there have been
references to COM as "Classic COM" which could mean that .NET assemblies are the way
forward. But the dependability of current applications on COM+ suggests that COM could be
around for quite a while. That could be one of the reasons why Microsoft provides developers
with tools to use .NET assemblies and COM together.

The Type Library Importer (TLBIMP.exe) utility creates .NET wrappers for the COM
components so the old legacy code can be used with .NET applications.
The Type Library Exporter (TLBEXP.exe) utility creates COM wrappers for .NET
components which could be useful if you want to migrate your current application to .NET taking
the piecemeal approach i.e gradually replacing the COM components with their equivalent .NET
assemblies.