From: www.itworld.com

The new wave of distributed computing

December 13, 2000 —

 

SINCE THE VERY EARLY days of programming, developers have had to divide their
code-writing efforts between two competing goals: On 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. Foor 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 institutionalized
information publisher and multiple volatile subscriibers (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.