Prizes & Awards
My Profile
Active Members
TodayLast 7 Days
more...
|
Resources » Articles » .NET Framework »
.Net Remoting vs Web Service
|
.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
Public Class ConvertMoney
Inherits WebService
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.
|
Responses
|
| Author: Bharat Kuckreja 07 Apr 2005 | Member Level: Bronze Points : 0 | A nice article to start with the basics of Web Service and Remoting
| | Author: Ashish Sharma 07 Apr 2005 | Member Level: Bronze Points : 0 | Article is very good and helps in making a decision which is more suited remoting or web service, in one's case.
|
|