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
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