The key to building distributed applications is the ability to break software applications into modules, called components, which are the building blocks of distributed applications. Each component is responsible for a specific function. To increase efficiency, these components can be distributed to run on separate computers. The Component Object Model (COM) defines of how Windows-based components work together.
Since it was first introduced in the early 1990s, COM has been an important and evolving Windows technology. In Windows 2000, this model is called COM+. To understand how COM+ works, it helps to understand how the component object model works.
How COM Works
A good example of a distributed application is an electronic-commerce order entry process, which integrates data and processes from a variety of locations, including both servers and clients. In today’s development environment, such a process often combines elements of traditional software, such as a database, with those based on Internet technologies, such as a browser.
Figure 3: Software Components
COM allows application developers to break large, complex software applications into a series of pre-built components, which are easy to understand, develop, and change. A component is a software module that is written to handle a particular type of information or a particular process. For example, a customer record can be created using a component that provides for name, address, and other distinguishing information. Components can contain relevant business logic to handle each element of a transaction, for example, specifying the proper length for a telephone number.
Each component is designed so it can be easily modified to address particular requirements. This way, rather than writing the same kind of code over and over, developers can use standard software code, say for an address record, and only adjust the elements that vary for an individual application.
To create a business process, developers connect components together. By reducing the amount of code developers have to write from scratch, this approach reduces the cost of developing software and makes it easier for organizations to modify applications as business conditions change. Because applications built using components can be linked together over networks, component software is also an efficient way to write distributed applications.
Basic COM Features
The following COM features make it a flexible technology for developers to use:
Location transparent. Every COM component can be called within a process, across processes on a single computer, or across multiple computers without being recompiled.
Language-neutral. Because COM is a binary standard, an implementation of COM written in one language is compatible with other COM implementation, making it language-neutral. For example, a Java developer can reuse other COM components written in languages such as Visual Basic or C++. This allows developers to assemble an application from components written in whatever language is appropriate and convenient.
Discoverable interfaces. Discoverable interfaces provide tools and other applications to let developers discover the interfaces and parameters that are supported by the component. This makes it easy for developers to work with the component without the need to understand its inner workings.
COM has evolved to meet the needs of the increasingly sophisticated applications made possible by networked personal computers. In particular, Windows NT® Server 4.0 expanded COM in two major areas. First, Distributed COM (DCOM) extended the COM model to span multiple networked computers. Second, Microsoft Transaction Services (MTS) allowed developers to build component-based applications with transactions that span components and databases.
These technologies have been tightly integrated and refined to create COM+ in Windows 2000. Before going into a deeper description of COM+, the next section provides a general overview of how transaction services work.
Note: you’ll sometimes see the entire set of COM-related application service technologies—COM, DCOM, and COM+—referred to generically as COM.
In the mid-1990s, Microsoft broadened the applicability of COM by introducing transaction processing support as a separate service called Microsoft Transaction Server (MTS). Transaction services help developers write and manage component-based distributed applications by providing much of the software infrastructure needed to execute the business logic that runs in the middle tier of the n-tier architecture. Transaction services include code for connectivity, directory, security, process, and thread management, as well as the database connections required to create a transaction-aware application.
In Windows 2000, COM+ integrates transaction services, as described in the next section of this paper. To make it easier to understand the affect of that integration, this section provides background on how transaction services work.
A transaction is a set of events that are committed or rolled back as a unit—either all the events happen, or none of them do. The creation of a complete transaction can require the cooperation of a number of components. In the example illustrated in Figure 4, the order entry application is made of components that, using DCOM, retrieve and process information from several servers. Windows transaction support provides built in programming services that let developers ensure that the entire transaction either succeeds or is completely reversed, without having to write extensive custom code to handle the mechanics of the transaction.
Figure 4: Transaction Services
Transaction services and COM work together to increase the capabilities of an application. The easiest way to understand how transactions and COM work together is to look at a typical scenario, illustrated in Figure 4 above. Suppose a customer is ordering products over the Internet. The entire order entry system can be built using COM components containing the business logic required to process orders. The individual elements of the customer’s order will likely use several processes and databases, hosted on different servers.
For example, the process would use a customer information database to record the customer’s name and address; an inventory database to make sure there is product available to fill the order, a shipping database to track the shipment, and a credit verification process to make sure the customer’s credit card is valid.
When the customer places the order, all the processes and database transactions need to be recorded as a whole. The transaction service monitors the entire transaction, and only commits all the changes if the entire transaction is successful. If a communications or hardware failure should interrupt the order processing, the transaction service will either roll back the entire order, or hold it for complete processing when communications are restored. Likewise, should the customer cancel the order, the transaction service can allow the reversal of all the processes and database entries. Note: Component Services cannot roll back changes to the file system or changes to other, non-transactional resources.
Before transaction support was offered with Windows, developers had to write scripts and components to manually track the requested changes and restore data if any changes failed. With transactions, developers simply have to designate that scripts or components require transactions. This means that developers can put together applications that use components without having to write the specialized code needed to address such issues.
|
