On the road to Indigo - Is .NET Remoting Dead? [Updated]
'Is .NET Remoting Dead?' [Updated]
No! Nope! Niet! Non! Negative! Nuh-huh! [shake head vigorously]!!!
This has been SUCH a hard message to communicate, so let’s make this VERY clear:
.NET Remoting as we know it in the current .NET frameworks is NOT going away. It is NOT going to be removed from the .NET frameworks when Indigo ships. There are NO plans to remove it from the .NET frameworks. .NET Remoting will be here for some time to come!
So where does the confusion arise from?
The simple statement “.NET Remoting will be depricated once Indigo is released“
What we mean by this statement is that when Indigo is released, the semantics of object remoting will be supported through the Indigo infrastructure rather than the current .NET Remoting infrastructure. This will help overcome a number of the limitations that .NET Remoting currently suffers (such as having to share assemblies with callers), whilst extending the many benefits of Indigo to developers requiring Remote object semantics.
Does this mean that existing .NET Remoting applications will need to be modified in order to work correctly when Indigo is released?
No … unless you want your EXISTING Remoted components to be interoperable with new Indigo Services on the wire. This is because .NET Remoting will not interoperate with Indigo on the wire and vice-versa. Remoting uses RPC/Encoded SOAP whereas Indigo and ASMX align with WS-I Base Profile reqiurements around Doc/literal (default for ASMX) or RPC/literal encoding.
In order for your remoted components to be interoperable and callable by, or from, Indigo Services, you have two options:
1) Port your .NET Remoting Components source code to Indigo and host them as Indigo Services. This will, of course, necessitate modifying all your caller applications, but provides the optimal technical solution.
2) Wrap your existing .NET Remoting components with an Indigo proxy Service that you create which calls the existing remoted components on the caller’s behalf. This is a stepping-stone approach since it means that existing applications can continue to access the Remoting components as normal, but that new code can access the Indigo Service. The existing callers can then be ported over a period of time, easing the migration process.
If you were to choose option 2, why would you migrate your existing applications to Indigo if they work fine. Arguably this is a business decision, but by porting your code to Indigo, you are then able to leverage all the advanced features of Indigo such as enhanced communications security, reliability, flexibility and control.
Option 1 is our recommended approach – port your Remoting components to Indigo and expose them as services as soon as possible after the launch of Indigo. You will gain huge benefits in terms of security and your services will be able to achieve unmatched levels of reliability and availability (through the use of features such as Indigo’s reliable messaging infrastructure).
How much change will be required to your existing source code?
In practice, very little! Converting your existing Remoting code to Indigo, will largely involve renaming some namespaces and attributes and changing a few inheritance points.
However, with .NET Remoting components, there is one large caveat to this: If you have developed custom channels and sinks to, for example, support a custom wire-format, then this code may require some considerable modification. The reason for this is that Indigo has a different architecture to support such extensibility and you’ll need to convert your custom code to Indigo Channel Providers.
However, if you have implemented some advanced feature (such as a reliable messaging protocol) you may well find that you will be able to just throw this code away and adopt Indigo’s advanced, standards based protocol / feature support instead!
“So, should I continue to use remoting in my applications today?“
Remoting as a technology has some useful capabilities in niche areas. In particular:
However, we recommend minimizing your use of .NET Remoting to these niche areas, and suggest that you utilize Enterprise Services for the development of components inside your services, and ASMX/WSE for exposing your services at your boundaries. This will help you develop Service Oriented systems today that migrate to Indigo as smoothly as possible in the future.
I discuss this subject much further in my posting on “Prescriptive Guidance for Today's Technologies“
In Summary:
- .NET Remoting is NOT going away or being removed from the .NET frameworks.
- .NET Remoting remain available for the foreseeable future (if not for ever!)
- Indigo is the strategic platform of choice for developing secure, flexible and powerful services and fully supports remote object semantics
- Migrating your .NET Remoting code to Indigo or fronting your Remoting components with Indigo Services will be required in order for your Remoting components to be interoperable with Indigo
- Migrating your existing .NET Remoting code to Indigo will be simple …
- … Although you will have to do work to port any necessary custom channel/sink code to Indigo Channel Providers
- Migrating your components to Indigo will give you many advantages and capabilities that would previously not have been possible or very hard to achieve!
- Use .NET Remoting for in-process, cross-app-domain communicaitons and for handling custome wire protocols and formats.
- Use Enterprise Services for in-service component development
- Use ASMX / WSE to expose your services
