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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine