| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

### MTS (Microsoft Transaction Server)

Microsoft’s distributed transaction processing service was code-named VIPER and is now called Microsoft Transaction Server. MTS enables a developer to write applications that access multiple distributed and different DBMSs (MS SQL Server, Informix, DB2/6000) or “Resource Managers” (like file systems or queue managers) under transaction control. MTS coordinates the update of data on these different DBMSs and ensures that either all the data is updated successfully on all the DBMSs or none of the updates are made. To do this it uses the well known approach of two-phase commit.

MTS uses a standard called the XA standard from the X/Open Group and Microsoft’s own object-based approach called OLETX. Unlike the CORBA-based products, Transaction Server does not support OTS (Object Transaction Services).

Transaction Server is based on DCOM, providing a value-added service based on the DCOM model and using all the other DCOM services. Thus, for example, the developer could use the services of OLE DB to access different databases and files in a “transparent” way, but also put the updates of the data in all these different files under transaction control.

MTS was originally priced separately, but is part of Windows NT 4 at no additional cost. It uses the same COM object-based interface to build transaction-based applications out of prebuilt components written in different languages.

### Cedar

Cedar is the internal code name for the Microsoft technology, technology which works in conjunction with Microsoft’s Transaction Server (MTS). It has just been renamed COM TI (Transaction Integrator) but as most Microsoft literature still refers to it as Cedar, I have used this name in the book. Cedar makes CICS and IMS programs appear as though they were MTS components. Thus IBM CICS and IMS programs running on MVS mainframes can be placed under the control of transactions running under Windows NT. MTS and Cedar communicate with one another to translate CICS and IMS calls to the equivalent MTS calls. Microsoft has a “zero mainframe footprint” strategy, which means that all mainframe interaction is achieved from a Windows NT platform base using gateways and proxy components—no modules are needed on the mainframe.

Cedar is based on technology from TransAccess. TransAccess technology (it supplied an RPC product) was acquired from Netwise in November 1995, and the original TransAccess product is still being supported by third-party companies. But TransAccess technology was used to develop Cedar and now underpins its operation.

### MSMQ (Microsoft Message Queue Server)

MSMQ, originally code-named Falcon, is a message queuing service. MSMQ is short for the full name now given to the service of Microsoft Message Queue Server.

Message queuing is not the same as mail messaging. Certainly the approach taken is similar, because there is store and forward capability built into MSMQ, but the difference is that whereas mail messaging handles mail between people, MSMQ handles messages between computer processes—messages that the receiving process uses in its processing. Thus, MSMQ enables one process to communicate with another process using messages that are stored along the route they have taken on queues.

If we think for a moment about the possible ways one process could communicate with another, we can see that one process could call another by name—in effect invoking functions (this is the default approach used within DCOM), or we could have a form of processing whereby one process does not directly invoke the other process, but sends it a message (the approach used in MSMQ). The approaches are complementary—both are useful means of communication.

Message queuing services don’t request processes to be activated with input and output parameters. Instead, message queuing products provide a much looser form of communication whereby the data needed by the receiving process is stored in the message and the message is then sent; there is no direct invocation of the process.

Whereas the invocation of a process often has to be quite tightly coupled with the sending of data and receipt of the reply synchronized, processes which send messages can be very loosely coupled. The process sending the message can continue with its processing after the message has been sent—acting asynchronously.

Microsoft released the beta test version of FALCON, as it was then known, in the third quarter of 1996. It was released in December 1997. MSMQ is part of Windows NT 4 at no additional cost and is due to be fully integrated into DCOM as part of Windows NT 5.

### LDAP/ADSI and the Active Directory

The Active Directory is the store or database holding information about the location of components, the users and groups in the system, the passwords of those users, the components that those users can access, plus other data needed to drive the system at runtime. In the same way that practically all commercial applications need data in databases in order to operate, DCOM uses the Active Directory to drive its operation. The Active Directory is due to be a replacement for the Registry files used at the moment.

LDAP (Lightweight Directory Access Protocol) and ADSI (Active Directory Service Interface) are simply APIs and the means by which developers can access the Directory services. More than one option is provided, and we will be seeing in the chapter on Directory services that Microsoft is providing access to other Directory systems as well as their own via these interfaces. This is the reason we have placed the service box under the heading of “translation” since although access via ADSI to the Active Directory requires no translation of the API, access to other Directory services will.

### Security Services

Security services—the ability to control who has access to the system and which components they can access—is a key requirement of software to support distributed computing. It is of little use if the platform on which the user signs on has checks, but the moment the user is transferred to another computer via the underlying middleware, none of the security checks are transferred along the way. Security services need themselves to be distributed so that there is “end to end” security checking.

DCOM’s security services are currently provided primarily by Windows NT, but plans for security mean that in the future DCOM’s security services could indeed be end-to-end and cover other platforms besides Windows NT. We will look at both the current checks and the future in the chapter on security services.

Previous | Table of Contents | Next