RSS
  Is DCOM Truly The Object Of Middleware's Desire? As you find your internal development adopting distributed object technology as its middleware framework, can you rely on DCOM to scale with your enterprise's needs? Although it's difficult to claim that any object technology is completely mature and well-understood, the fact of the matter is, you need to be choosing the right technology today to make sure you have the expertise for when you want to deploy your applications tomorrow. Management and services are two key areas that are defining the success of distributed object technology on the network. In both of these areas, particularly management tools, we found that DCOM has significant advantages. Though the services DCOM offers are competent, if Microsoft can shore these up while sta ying ahead of the game with management tools, you'll be able to confidently maintain DCOM on the network. Furthermore, we find that DCOM provides an efficient transport mechanism with flexible security that employs readily available authenticators. Today, DCOM offers a much more accessible technology. It has the tools to allow you to develop your understanding of the technology without being overwhelmed. If cross-platform capability is a must, it might be better to steer clear, but if your network is comprised primarily of NT Servers on the back end, then Microsoft has made an offer you can't refuse. Anthony Frey can be reached at afrey@nwc.com. | ||
| DCOM And Microsoft Transaction Server
Aquestion that is frequently raised about Microsoft Corp.'s Distributed Component Object Model (DCOM) is how it fits in with Microsoft's Transaction Server (MTS), as well as the upcoming Microsoft Message Queue Server (MSQS), formerly known as Falcon. The answer is MTS is essentially built on DCOM. This means it is written using the Component Object Model (COM) and uses DCOM for communication with resource managers, such as SQL Server, and other MTS servers on the network. When COM components, which are also called "packages," are installed into MTS, client and server components that are distributed across more than one node and must use DCOM to communicate are automatically managed. In contrast, MSQS does not use DCOM for the transfer of actual messages, since the highly synchronous nature of Remote Procedure Call (RPC) mechanisms are not suited to messaging. However, MSQS does use DCOM to exchange control and management information among queue manager nodes. From our initial looks at MTS, we've found that the package explorer that's provided with MTS is an effective tool that can be used to manage components on local and remote systems. Although we haven't had an opportunity to fully review the re cently released MTS, we do expect it to provide a very good example of an application built using the DCOM infrastructure | ||
 |
Updated July 10, 1997 |
