Webservices and remoting

COM is Component Object Model. This is specification developed by Microsoft. Component is pre compiled block of code which is reusable and language independent. In order to use COM you must know the interfaces of COM. The family of COM technologies includes COM+, Distributed COM (DCOM) and ActiveX Controls.

DCOM is a Distributed component object Model runs at the given server.

Webservices and  remoting

webservices apply between defferent vendor but remoting only on same vendor.
that is
a webservice application made in java platform can be used in a .Net application or project.
but remoting doesnt provide this.

Let me try to explain both without getting too much into technicalities.

In pre-.NET days, the protocol to communicate between a client and a server or between components across machines on a Windows platform was DCOM. But, DCOM had it's own limiations and all, the major ones being that it works only on MS o/s, was MS proprietory, needs a specific port to be opened if using Firewall and so on.

Now DCOM was basically to facilitate communcation between components across processes. .NET Remoting is the same, except that in .NET, there are AppDomains instead of processes.

.NET Remoting replaces DCOM. Now, no more proprietory protocols used. Remoting works over TCP and HTTP. Supports binary as well as XML.

Also, you need a "server" to host your Remoting component. It could be a normal .exe app, or you can host your component in IIS or via a Windows Service. Your choice.

Now .NET Remoting is a good option if you are creating an app that is to be used within the corporate network as it will use TCP. TCP is definitely faster than HTTP. So, if you need to transfer data between apps within the same network, use .NET Remoting.

Now, what if the data needs to go outside your network. Well, you could use .NET Remoting over HTTP, but that is not advisable as (a) HTTP is slow, (b) you'll have to give access to the outside world to your network and (c) U R defeating the purpose of Remoting.

So, in such a case where you do not know "who" is gonna connect to your app, from where, what platform do they use and what format do they need data in (and send too), go for Web Services. They could be using J2EE for all you know.

Web Services is a standard, wherein it uses all standard protocols/technologies like HTTP, XML, SOAP, UDDI and WSDL. All it needs is a Web Server (IIS in this case).

Anybody who has a net connection can access a Web service. Of course, you'll have to take care of the security part too. But let's not get into that right now.

Also, if I had to define a Web service in one line, I'd say "It is a Web Page without a UI.".

Let me know if you need more info.

The following list outlines some of the major differences between .NET Remoting and Web services that will help you to decide when to use one or the other:

ASP.NET based Web services can only be accessed over HTTP. .NET Remoting can be used across any protocol.

Web services work in a stateless environment where each request results in a new object created to service the request. .NET Remoting supports state management options and can correlate multiple calls from the same client and support callbacks.

Web services serialize objects through XML contained in the SOAP messages and can thus only handle items that can be fully expressed in XML. .NET Remoting relies on the existence of the common language runtime assemblies that contain information about data types. This limits the information that must be passed about an object and allows objects to be passed by value or by reference.

Web services support interoperability across platforms and are good for heterogeneous environments. .NET Remoting requires the clients be built using .NET, or another framework that supports .NET Remoting, which means a homogeneous environment.