COM+ Application Architecture Using Microsoft .Net
Written by: Rickie Lee
Nov. 11, 2004
In the previous article, .Net服务组件（ServicedComponent）简介及其使用, we know some basic features of COM+ component in .Net framework and explore how you can create and register a serviced component according to an article at CodeProject.com web site.
During the simple demo article, Creating COM+ Objects using EnterpriseServices in .Net, the client and COM+ serviced component are hosted on the same computer. So the client can communicate directly with COM+ serviced component. However, during the practical enterprise application, the client application is usually not in the same machine with serviced component.
This article will focus on how to use a COM+ serviced component and some useful features of COM+ attributes. Then a practical COM+ application architecture will be depicted, which is more suitable to COM+ based enperise applications. At last a demo application is built in order to further verify the correctness and feasibility of my favorite COM+ application architecture.
Using a COM+ Component
Now that you have a serviced component, how can you use it in the client application? You have three basic options:
(1) DCOM
This is the same approach you would use in Visual Basic 6.0. It's heartily discouraged, however, because DCOM is difficult to configure properly and inflexible in the enterprise (especially if your server is behind a firewall).
(2) XML Web services
In this case, your XML Web service effectively acts as a layer in between the COM+ component and the client. The XML Web service instantiates the COM+ component directly, just as it would with any other .NET assembly.
(3) .Net Remoting
This is often the most flexible approach. Using a component host, you can expose a serviced component exactly as you would expose any other .NET object.
Obviously, The second and third solutions are recommended to use a serviced component in enterprise environment. In both ways, the client application calls to the serviced components are wrapped with a stateless service provider, like XML Web services and .Net Remoting.
In addition, we know web services scenario is used to communicate between applications, even .Net applications. And .Net Remoting is used to communicate between tiers in an application. Anyway, the above rules are recommended general design guide or policy. In different projects or situations, you should use these distributed technologies flexibly.
Recommending COM+ features
There are lots of configurable attributes on COM+. Obviously, every attribute has its goal, which has mentioned in the previous article. Correspondingly, some attributes are used frequently and more useful in enterprise applications, such as Object Pooling, Just-in-Time Activation and Automatic Transactions.
(1) Object Pooling
The COM+ Object Pooling service enables you to reduce the overhead of creating each object from scratch. When an object is activated, it is pulled from the pool. When the object is deactivated, it is placed back into the pool to await the next request.
Object pooling is conceptually similar to ADO.Net Connection pooling. With connection pooling, the connection is released to the pool when the Close method is called and is acquired when the Open method is invoked. With object pooling, the process is similar with it. The object is released using a Dispose method and is acquired automatically when it is instantiated.
If Dispose isn't called, the object won't be returned to the pool until the .NET garbage collector tracks it down, which will adversely affect other clients, particularly if the pool is small enough that you might quickly run out of instances to satisfy ongoing requests. In the meanwhile, you need make sure that external clients shouldn't have the ability to directly interact with a pooled object. Instead, your service provider should be the only class that uses a pooled component. It can then ensure that the pooled object is properly released at the end of every method call.
The following example sets size and time-out limits on the serviced component class.
ObjectPooling(Enabled=true, MinPoolSize=5, MaxPoolSize=10, CreationTimeOut=20000)]
(2) Just-in-Time Activation
The COM+ Just-in-Time (JIT) Activation service allows idle server resources to be used more productively. When a component is configured as JIT activated, COM+ can deactivate an instance of it while a greedy client still holds an active reference to the object. The next time the client calls a method on the object, COM+ reactivates the object transparently to the client, just in time. For a component as JIT activated, the object is activated when first created. On the method call return, COM+ deactivates the object but leaves the context in memory. The deactivated object releases all resources, including locks on expensive data stores. Therefore, the client can maintain a permanent reference but no object is tied up at the server side.
To ensure the object is deactivated on the method call return, it is necessary to set the object’s done bit. For transactional components, you can either apply the AutoCompleteAttribute to a class or call ContextUtil.SteComplete or ContextUtil.SetAbort. For non-transactional components, call ContextUtil.DeactivateOnReturn.
Keep in mind that automatic transactions require JIT activation; therefore, JIT activation is implicitly enabled when classes are configured for automatic transactions.
In fact, there are alternative solutions to handle the greedy client’s issue by using XML Web Services and single-call .Net Remoting objects in .net framework. These objects follow the same activation pattern as JIT-activated object in COM+. They are created at the start of a method call and are destroyed at the end, even though the greedy client might maintain a reference over the lifetime of the application. In the next section, the architecture of these scenarios has been depicted.
To mark a component for JIT activation, you need to add the [JustInTimeActivation] attribute to the class definition:
[JustInTimeActivation]
(3) Automatic Transactions
Automatic transaction processing is a service provided by COM+ that enables you to configure a class at design time to participate in a transaction at runtime. Transactions are one of the best-known features of COM+. Well, there are a lot of articles in the Internet, which demonstrate how to use automatic transactions feature of COM+ using Microsoft .Net.
A COM+ transaction isn’t a replacement for ADO.Net transactions (SqlTransaction object) or stored procedure transactions. These types of transactions are handled directly by the data source, which allows them to complete much more quickly. In the case of a transaction encapsulated by a stored procedure, the entire process can take place on the server without requiring any additional network calls. This provides excellent performance.
To mark a component for automatic transactions, you need add the [Transaction] attribute to the serviced component class definiction:
Transaction(TransactionOption.Required, Isolation=TransactionIsolationLevel.Serializable, Timeout=10)]
Please refer to MSDN to learn many other options on TransactionOption enumbertaion.
When you apply [AutoComplete] to a method, the component deactivates immediately when the method ends. Furthermore, the transaction is automatically committed, assuming no unhandled exceptions are encountered. If an unhandled exception is generated, the transaction is rolled back.
Remember that COM+ transaction is used when it need modify more than one data source. If it modifies only one data source, it can use an ADO.Net transaction. If it performs all its work in a single stored procedure, it can use an even more efficient stored procedure transaction.
My favorite COM+ Application Architectures Using Microsoft .Net
So far, you are supposed that you can build a serviced component using Microsoft .Net. Then this section will focus on how to build COM+ application architecture. My favorite COM+ application architecture is as follows.
From the figure, we can know that the client never directly invokes the serviced components. Instead, your service provider should be the only class that uses a serviced component, such as XML web services and .Net Remoting components. It can then ensure that the serviced component object is properly released at the end of every method call. Therefore, even the client can maintain a permanent reference to the service provider object but no object is tied up at the server side.
In addition, it’s simple for client to call XML Web services and .Net Remoting components. These are well-known technologies in .Net Framework. Due to the service providers are hosted in the same machine with COM+ serviced components, it’s also easy to develop the service providers. These service providers are taking care of the client’s requests, and forwarding them to COM+ serviced components. COM+ serviced component will receives the request, processes it, and then returns a response.
XML Web Services are hosted in IIS server and can be accessed over the Internet using standard web protocols. Instead, .Net Remoting components can be hosted in IIS server or Windows services. It is usually used in enterprise intranet environment.
I develop a demo application to verify the above COM+ application architecture in weekend. The demo application is involved in COM+/Serviced Component, .Net Remoting and Web Services technologies in .Net framework. .Net Remoting and Web Services component have been hosted in IIS.
Please leave your email address if you want to try the demo application.
Any questions or opinions, welcome to comment here. Thanks.
References:
1, Matthew MacDonald, Microsoft® .NET Distributed Applications: Integrating XML Web Services and .NET Remoting
2, Rickie, .Net服务组件（ServicedComponent）简介及其使用