Since the very early days of programming, developers have had to divide their code-writing efforts between two competing goals: on the one hand, you must define the logic of the business context; and on the other, your program must handle the technicalities to support the application environment.
For example, an order-entry application has code to manage business functions (such as calculating shipping charges or pricing order items) and code to navigate the technical context (such as accessing the inventory database). The business-logic code usually gets most of the attention, while the technical code is generally seen as a necessary evil - a kind of technological tax that becomes more expensive as your environment grows in complexity.
But this technological toll is often the most expensive part of your code, because it's the part that can force a complete rewrite when moving an application to a new technical context. For example, if you decide to port a client/server, order-entry application to the Web, you probably won't have to change the business logic much (if at all). But the code required to navigate the new environment will be very different, and creating that code could cause your development costs to soar.
The Windows 2000 operating system offers COM+, the latest evolution of the distributed computing model, which incorporates the functionality of MTS (Microsoft Transaction Server) and promises a simplified programming interface open to future improvements. COM+ also makes it easier to use APIs across different services on the Windows 2000 platform, therefore cutting development costs. Bear in mind, however, that right now COM+ is only available if you use Windows 2000.
Microsoft created the original COM (Component Object Model) so that it could let users connect components to services residing either on the same computer or on another machine. If you've ever dragged a Microsoft Excel spreadsheet into a Word document, you've had an embryonic example of COM in action (double-clicking the spreadsheet object in Word will fire up Excel). Expand the same concept to different services, such as transactional or queue management, and the same rules apply. For example, an object can request queue management services via built-in interfaces that become active at execution time.
But one of COM's limitations is that the interface to request each OS service must be hard-wired into the application. For example, let's assume that an order-entry application contains interface calls to query an inventory database to verify and then update the inventory. In this scenario, the database must be immediately available; otherwise transactions will fail.
A better approach would be to store queries and requests for updates in a message queue, instructing the database server to read and write queued messages. This approach also makes applications more flexible, allowing them to be used from disconnected laptops, for example. But the technological tax is costly, because you'd have to insert new interface calls to handle queued messages, rather than having direct access to the database.
Enter COM+, which introduces an intermediate layer (known as the interceptor) between the application and the services. The interceptor is activated whenever an application makes a call for a service, and its role is to prepare the proper technical environment for the application, according to a table of attributes stored in a repository external to the application.
Therefore, using COM+, developers don't have to write extensive passages of code to make their applications context compliant. Rather, the various services that the context requires can be automatically set at execution time by the interceptor. You can even set different attributes to generate behaviors for the same application. At execution time, the interceptors will call the proper services according to the context and the property set.
Of course, the idea of an interceptor that automatically completes your application with OS services is not new. In fact, the concept was built into MTS. But in Windows 2000, the MTS services are integrated and interface-consistent with COM+, which is an added bonus for the developer because of the unified API semantic.
The interceptor is one of the most important innovations in COM+. From a developer's point of view, it's a godsend, because it makes developing code for distributed software much easier. It also cuts the programming cost where it is most expensive - coping with a constantly changing technical context. Think of it as Windows 2000's deduction to the technological tax.
But there's more to COM+ than the integrator. You also get services that could suggest a future integration of MSMQ (Microsoft Message Queue) services. Again, by directly accessing COM+ and using a consistent application-program interface, developers can request code application requests for services in the form of queued messages, rather than having requests sent directly to the service's provider. Two components of COM+, a recorder and a reader, forward and retrieve those messages from the MSMQ server, hiding the different semantics that the server requires from the developer.
At press time, it was unclear if this feature will evolve in COM+-based support for messaging services - which would be a welcome new development. Right now, you can access message services either via the COM+ API (with some limitations, such as exposing the format of each message) or via native MSMQ calls. The current dual set of messaging service calls offered by MSMQ and COM+ could lead to confusion as to which one to use and when.
Finally, COM+ Events offer APIs to provide publish-and-subscribe services (which are again included in the underlying OS and consistent with the COM semantic). The new Event Services feature stores information about providers and subscribers for each event.
You can define what must be monitored and who must be informed. For example, in our order-entry system, you could request notifications when the stock-on-hand quantity reaches the reorder point and automatically start an application to handle that event. These services could come in handy in situations involving an institutionalised information publisher and multiple volatile subscribers (such as retrieving stock market quotes or tracking fluctuations on the currency market).
All things considered, COM+ offers several attractive features that will let companies save time and money in the development and deployment stages. Again, however, COM+ is only available with Windows 2000, so any company interested in reaping the benefits of COM+ will have to weigh the technological benefits against the costs of ownership and migration.the bottom lineMicrosoft COM+Business Case: COM+ offers a simplified programming model that lets developers produce complex applications quickly, which translates to cost savings. However, COM+ is only available with Windows 2000, so companies will have to weigh the expected savings in development costs against the cost of migrating to a new OS.
Technical Case: COM+ will provide more application independence from varied technical scenarios. COM+ can also simplify programming work and offer more flexibility in development and deployment among services with a common API.
Pros: ¥ Consistent API for most development activities ¥ Flexible, run-time behavior of applications ¥ Simplified, attribute-driven programming modelCons: ¥ Requires installing Windows 2000Microsoft http://www.microsoft.com.au