Before my presentation at our quarterly ISV Community Days had a rather long discussion staying in a circle of ISV techies.

To the left was PM from one of the ERP vendor who're doing Remoting and to the right stayed Web-services guy with process automation app.

It was again a controversy: what use for distributed apps - WS or Remoting.

ERP guy points were:

• Need stateful object model - it allows me to keep objects in memory between calls and therefore perform long running taks a breeze
• XML serializer is too slow
• Having types on the client doesn't confuse - there is a way to update those types when server changes
• No needs for special host process - IIS goes very well for HTTP/SOAP, does all authentication stuff, is secure, etc...
• Remoting will be for ever... By the way what will change in .NET 2.0?

OK, points seem to be reasonable... and... the following was my answers:

• Stateful model? That's probably the biggest dim point on Web-services. Not just because you obviously can have a state for WS in ASP.NET but because it's really a mistakenly mixing activation pattern and state. Yes, it's true that Web-services end-point is activated in singe-call mode by default. For "OLTP" operations it also pushes a good notation of freeing resources and commiting transaction on each call. Another point is state. Before all: question of keeping state is only valid when state resides in memory. Why have state in memory? Because you'd like to offload database.So it's like a cache - a sort of optimization and not a design pattern at all. If consider it this way - you'll discover that when you use Web-services and single-call pattern then there are a number of options to keep a state data around - be it a real cache (Cache API),  external process, static variables or the same bunch of objects that you previously created in Remoting.
• When I hear that something is slow the first question I ask is: did you really measure that? Did you? In which conditions? For which operations? Was it a fair bottleneck or you just think it slower? I'll give an example. You have an interface and some object which implements it. In order to perform some logical operation you need to call 3 methods and set 5 properties on the interface. When you use Remoting it takes N ms. Now you want to compare the same implementation on Web-services and it takes N + M ms. What a pity! And you decide that Web-services terrifically slow. What's wrong here? The interface! You never, ever should design Web-services interface like this. Web-services idea is: 1 logical operations == 1 method == 1 message.
• About types on the client. For me it is about productivity. Good developer is a lazy one. You like update client and server when you change implementation? Let it be... The less dependency the better (if you develop anything more complex than notepad). Think about XML, why it's so successful...
• IIS is good host. Completely agree - it's best. SOAP is also good thing. And single-call pattern is good too. So why did you use Remoting whatsoever in this case?
• Remoting will be, true. It's cool technology and please use it everywhere - but inside boundaries under your control (cross-appdomain, cross process inside your app, etc). In .NET 2.0 we get authentication over TCP and crypto stuff. Look at http://msdn2.microsoft.com/library/59hafwyt.aspx and http://msdn2.microsoft.com/library/k62k71x0.aspx

This posting is provided "AS IS" with no warranties, and confers no rights