Productivity and Power with .NET Enterprise Services
.NET Enterprise Services is a set of powerful services designed to considerably ease the task of developing robust, scalable, high-quality applications, in a fraction of the time it takes to develop such applications without these services. Enterprise Services requires both the client and the server to be .NET components. You configure your methods using attributes that specify the functionality required by your component.
To use almost all of the services offered by Enterprise Services, the server must derive from the ServicedComponent class. The Enterprise Services architecture is interception-based, meaning Enterprise Services intercept the calls to the object and perform pre- and post-calls processing (see Figure 4
|Figure 4: .NET Enterprise Services architecture.|
The client of an Enterprise Services component interacts with a proxy. When the client makes a call on the proxy, the proxy makes a highly optimized call to unmanaged code to a set of chained interceptors asking them to do pre-call processing. The chain is comprised of interceptors according to the configured services. The first interceptor could verify the caller is authorized to call the object, the second interceptor could acquire a synchronization lock, the third could begin a transaction, the fourth could retrieve an object from a pool, and so on.
When the pre-call processing is done, control returns to the proxy that makes the call on the object. The method call itself never leaves managed code, so there is no interop penalty. Contrary to common knowledge, Enterprise Services usually does not use interop unless it will yield significant performance gain over managed code. In addition, for remote calls, Enterprise Services uses DCOM under the hood, but again, the method call parameters are never marshaled to and from unmanaged code so there is no marshaling penalty. Consequently, Enterprise Services is actually the best performing option at the disposal of developers today, out performing both remoting and Web services by at least one order of magnitude if not more.
What is truly impressive about Enterprise Services is the set of services it offers: host startup and idle time management, instance management and scalability, transaction management, concurrency management, granular security and full security call context propagation, loosely coupled events, asynchronous disconnected calls, administrative tools for services management and application activation, and more. Enterprise Services can take care of all these aspects of the application, and let developers focus on implementing business logic.
|.NET remoting architecture is a modular and extensible architecture.|
The downside of Enterprise Services is that it cannot cross boundaries, and it is a closed architectureyou cannot add your own custom services to the interception chain. In addition, Enterprise Services requires a fair amount of time and effort to master the details of how the services are set up and combined, making them an expert tool, rather than something every developer can easily use.
Without considering Indigo, if you have to choose a technology today, the best way to do that is by elimination, as shown in Figure 5. If you need to interoperate across boundaries, then Web services are pretty much your only option. If you do not need to cross technology boundaries, and you can assume that both the client and the server are developed in .NET, you need to ask yourself whether you need extensibility. If the answer is yes, then .NET remoting is for you.
|Figure 5: Choosing a .NET technology today|
You still need to decide which format and channel to use. If a firewall is present, then SOAP format over HTTP is what you use. For any other cross-machine calls choose binary over TCP for best performance, and if all the calls are made across processes but on the same machine, then use IPC. If you do not need extensibility, then bite the bullet and use Enterprise Services. You gain not only productivity and faster time to market, but also quality because Microsoft has done an excellent job in implementing these services, both in robustness and in performance. You can also adopt a hybrid approach. When implementing a service that needs to be accessed across boundaries, allow clients to access the service over Web services; while inside the service, use Enterprise Services.