Remoting-v-webservices - the prescriptive guidance is nuts ?
Web-services excel for cross-platform/cross-language communication. However, what about communication for the internal tiers of an app, where it is .NET on both sides ? It's the endless debate of remoting-v-webservices. Remoting - faster performance and richer type system, versus the lower-performance, lowest common denominator of web-services.
The message that I perceive from MS is "use web-services for everything - remoting is only for in-process, cross-app domain communication", but as Rocky Lhotka suggest "the prescriptive guidance is nuts."
http://tinyurl.com/5wnul
So, is the "politically correct" choice of web-services really that sensible for the internal tiers of an application ?
Andy Mackie
p.s. Whatever is used, anything but DCOM! Deployment nightmare...
Current recommendations from Microsoft around Web Services vs. Remoting is that Web Services are a more viable long-term solution. Microsoft's Distributed Computing Group, which owns Web Services, .NET Remoting, WSE, DCOM, COM+, Enterprise Services, MSMQ, and Indigo, is encouraging a move toward Web Services and recommends avoiding implementations using .NET Remoting. Information can be found here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/introindigov1-0.asp. Note especially the section on Coexistence and Migration. If you're running ASMX Web Services, there will be a clean migration path. .NET Remoting-based applications will require more work to migrate.
From a more pratical perspective having personally used both technologies on large projects, both are trying to accomplish the same thing - communication between distributed nodes. One of the problems with .NET Remoting is that support is lacking in usage scenarios beyond basic communication. You want security - roll your own. You want transactions - roll your own. You want reliability - roll your own. WSE and Indigo support the WS-* specifications, which include standards for WS-Security, WS-Transactions, WS-ReliableMessenging, and many others. Many vendors are supporting these specs, which gives hope for a cross-platform, interoperable distributed platform.
As for what to do today, I would probably look at whether Web Services will suffice for your application. If you need features included in the WS-* specs, I would consider using WSE.
The only time I recommend using remoting is when you need to have the ability to have delegates fire methods on the client in addition to the client consuming exposed functionality.
Basically, if you need more real-time communication and don't want to implement polling for bandwidth, or activity related reasons go with remoting but be aware that Microsoft have effectively said it's obsolete and will be replaced by indigo (although will remain in .NET for some time). If you don't need that functionality, you can use Webservices. If you need cross platform support then you don't have a choice and must use webservices.
If the XML format of web-service's was not an issue, then why on earth are Microsoft adding a binary SOAP format into Indigo ? Binary SOAP!!!
The concept of remote objects appears to be entirely supported in Indigo via "Indigo RemoteObject's".
http://msdn.microsoft.com/library/en-us/dnintlong/html/longhornch06.asp
As for work to migrate, if you use shared-interfaces in remoting, it is a simple mechanical process to migrate, according to http://blogs.msdn.com/mattavis/default.aspx
As for web-services, using WSE2 does not provide a clean migration path to Indigo. "Applications built using WSE 1.0 and WSE 2.0 won't interoperate with applications built on Indigo...some amount of effort will be required to move existing code from WSE to Indigo". So what's the difference compared to remoting ?
http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/introindigov1-0.asp
Remoting security - host it in IIS and you get all of IIS authentication features. .NET 2 also introduces enhanced remoting security/encryption.
In the end, it seems to come down to full .NET type support -v- whatever XML offers, and performance. If it's .NET on both sides, what benefit does web-services bring (other than bloat) ? Don't get me wrong, I absolutely think web-services are what should be used for inter-application communication, but are they really the best for communciation inside an application ?
I agree with Andrew. .NET remoting is supperior in so many ways to web services (for certain scenarios) that it is ridiculous to write it off just because Microsoft said it'll be a clearer upgrade path to Indigo. .NET remoting is faster and offers support for more features. That being said watch out for passing Datasets using .NET remoting it really won't gain you anything. In version 1.0 and 1.1 of the framework Datasets are always serialized using XML.
At least 2.0 will give you an option of binary.
I agree with you Andrew, why use web service within your application. I think remoting provides with a much richer experience with the .NET data types. But if my application were talking to another application then I would most likely use web service. Well put Andrew.ka
I have published clear guidance on how, when and where to most effectively use our distributed systems technologies on my blog (
http://blogs.msdn.com/richardt). This guidance has been written up into a set of MSDN whitepapers which should be published within the next few weeks.
The reasons behind our guidance are many and have been very carefully considered. We also considered where we're going in the future in our guidance because we understand the impact that Indigo will have on building distributed systems on the Microsoft platform.
There are a few things to bear in mind when considering which technologies to use and when, in particular for Remoting.
Remoting is a powerful technology. It supports many of the notions of simple remote services, but does not support many of the more advanced details such as distributed transactions and security out of the box. Remoting also allows you to get very close to the wire and directly influence the format of the message and the means by which it is written/read to/from the wire.
However, Remoting also suffers from a lack of broad and rich hosting capabilties - you essentially have two options - IIS or your own custom host. If you choose the latter, you've got to make your hosting app secure, reliable, manageable etc. If you choose the former, you have to run IIS ... which is not always possible.
Now, let's consider two things: the impact of Service Orientation and future technologies like Indigo.
Service Orientation is an approach to building loosely-coupled, agile, autonomous distributed systems. Such Service Oriented systems benefit enormously from vastly increased flexibility and the ability to evolve over time in a way that systems built on distributed components find it very difficult to achieve. In Service Oriented systems, servces communicate by sending messages containing data sent "by value" across a wire (real or virtual) - traditional "objects" are not exchanged by reference between processes as this unnecessarily couples callers and services and reduces interoperability.
The technology that has closest fidelity with the notions of Service Orientation is Web Services, specifically, the advanced Web Services protcols encompassed within the WS-* suite. Now, it's important to note that WS-* is expressed in terms of InfoSet, not XML. This means that, so long as no information is lost, WS-* compatible messages can be encoded into formats other than XML so long as both ends of the wire understand how to decode the messages correctly.
This is how we build a BinaryXML encoder in Indigo - we do a lot of work to optimize the serialization and deserialization of Indigo's messages to/from the wire in as optimal a manner as possible. Of course, this our BinaryXML encoder is geared towards Indigo-Indigo communications, whereas XML is used primarily for cross-platform interop scenarios.
Now, let's consider the future: Indigo. Indigo is Microsoft's next-generation distributed systems platform for building Service Oriented systems. For a great overview of Indigo, read "Introducing Indigo: An Early Look". Note that this is much more up-to-date paper than Don's 2003 whitepaper which was quoted earlier in this thread - this was a very early look at a very early version of Indigo - much has changed since then!
Indigo supports a very rich type system, exceeding that of either ASMX and/or Remoting. Indigo supports multiple transports, multiple encoding mechanisms and many combinations of security, reliability, transactions and other useful capabilities. Building Service Oriented systems using Indigo will result in considerable performance and scalability improvements. While you can expose a services to other platforms and/or other organizations using XML-SOAP/HTTP, you can also communicate with services using BinaryXML-SOAP/TCP inside your intranet if you wish. If you want to communcate with services on your local box, you can use BinaryXML-SOAP/Named Pipes for secure, really high performance comms. Indigo scales-out fantastically using NLB, scales-up from single-proc machines to 64-way 64-bit behemoths and also scales-in from far-away services to intra-process services ... and all of this by making changes to configuration files only!!!
Thus, our guidance aims to get you to a place with our existing technologies where you'll have an easier time integrating with or upgrading your code to Indigo in the future.
Note that Indigo will not interop on the wire with .NET Remoting endpoints. Note that if you choose to use Remoting and build custom channels and sinks, you'll have a harder time porting your code to Indigo. Understand that Remoting is for .NET Remoting - .NET Remoting communciations. If you even foresee the possibility of a chance that you want/need to interop with other platforms or future technologies from Microsoft, then constrain your use of Remoting if you don't want to have to (potentially) do a lot of extra work.
One thing I do want to point out is that Indigo does not support the RemoteObject semantics. Whilst earlier builds of Indigo supported this concept, we moved instead to supporting the exchanging of End-Point References (EPR's) instead of object references as this gives is an interoperable and decoupled way in which to support semantics similar to passing objects by reference.
Please read through my many blog posts on this subject BEFORE you choose to do any further development on Remoting and if you're willing to live with the potential issues, then go in peace. Otherwise, start preparing for Indigo now - it'll transform the way you build systems.
Rich:
Thanks for the post. I do see some issues with your comments though.
First, I know that remoting in 1.1 does not have security out of the box. But my understanding is that in 2.0 it will? If so, that seems a boon for Remoting.
Second, please elaborate on the "broad and rich hosting capabilities" web services enjoy? I know of IIS, and that's it. Anything else (Windows Service, COM+ app) would fit your definition of "roll your own", because that's what you can do with Remoting too.
I have used remoting in my application for communication between clients and a server on a LAN. It uses the binary formatter and the TCP channel. Why? The question is, why not? Using SOAP and hosting in IIS (whether the channel is TCP or HTTP) reduces the performance of the application, which is paramount in this scenario. I know it reduces the performance, because as an option, SOAP over TCP and SOAP over HTTP are also provided in this (commercial) application using WSE 2.0.
The application's architecture is definitely "Service Oriented", only it's implemented using Remoting and Web Services combined.
I understand that Indigo will offer tremendous benefits and that the upgrade path from .NET Remoting will be somewhat more involved than from ASMX Web Services (By the way, I don't use ASMX web services, but use HttpModules). However, our service interfaces in the application are a more 500 lines of code (which includes handing out security tokens, etc.) Compared to the entire application, 500 lines of code is Nothing (null in C#) 
So having to re-write those in order to enjoy the rich functionality of Indigo *should* be well worth it. If it's not worth it, Indigo has missed it's goals and we'll stay with Binary TCP and .NET Remoting.
Not to break down your guidance (I haven't seen the final white paper yet, and do not keep up with your blog that well either), but it seems to me that using XML for everything is considering Web Services the proverbial hammer. I believe that ASMX, Remoting, WSE 2.0, and in the future, Indigo, all have a place in a developer's toolbox.
(Of course, only the future will tell whether the decision to use .NET Remoting was a decent one. So far however, we could not have done better.)
Thanks,
SA.
