The COM+ Microsoft product is a sophisticated runtime environment built to provide application infrastructure support. The support found in COM+ generally targets medium-to-large enterprise-level applications. Microsoft identified the most complex type of service routines that developers constantly needed to "figure out" and prepackaged a robust, almost plug-and-play reusable product. The "plumbing" that an n-tier or 3- tier application would typically require to com plete its support for middle-layer components comes with COM+ out of the box.
Microsoft provides the Component Services console (an MMC snap-in) to manage COM+. Click the Start button and select Programs Administrative Tools Component Services, as shown in Figure 19-1.
Once you have launched the Component Services console, you will see an MMC snap-in window. A default tree structure view is available on the left pane. You can drill down to the preinstalled system-level COM+ applications by double-clicking the Computers My Computer COM+ Applications nodes (see Figure 19-2).
Caution | Feel free to explore a bit. But do be careful. Keep in mind that these preinstalled COM+ applications support system-level services. Whatever you do, do not delete or modify either of these preinstalled COM+ applications. |
Drill down into several of the nodes to discover the child nodes. You will notice that each COM+ application has a Components node (the icon that looks like a folder). As shown in Figure 19-3, the preinstalled COM+ application named System Application has five components.
While you are exploring the System Application COM+ application, notice in the right pane (after you click the Components icon) those components displayed as round ball-like structures with a plus sign (+) on them (see Figure 19-4). In fact, one of these components may already be "spinning." These "balls" represent installed components. A spinning ball indicates that the component and the client process that is using the component are active.
You can change the view shown in the right pane of the Component Services console window to see a varying level of detail. You can do this by selecting the View option from the toolbar ( optionally , you can use the View icons, as shown in Figure 19-5).
The last thing that I would like to point out in the Component Services console window is the Running Processes node. [2] If you look in the left pane, you will notice a folder icon labeled Running Processes. After you expand this node, you will see any COM+ applications that are actively running. As shown in Figure 19-6, at a minimum you will typically see the preinstalled System Appli cation COM+ application.
Notice the relationship between the Running Processes node and the other nodes shown under the COM+ application's parent node.
Can you see where all of this is heading? That is right. Your goal in this chapter will be to create .NET components in Visual Studio .NET (VS .NET). Then you will install those components into COM+ as COM+ applications. Your built assembly (.dll) will be represented by one of these "balls" that you will see in your own COM+ application's Components folder. How exciting!
For now, let's explore the topic of COM+ a bit more. Don't worry, you'll return to the Component Services console later.
On the mainframe when I developed COBOL/CICS programs, I recall using the term "transaction" on a daily basis. "Transaction" was ingrained into every aspect of the COBOL/CICS programming environment. Some called CICS a Transaction Processor (TP). As you know, the phrase "to create a CICS program" is synonymous with the phrase "to create a CICS transaction." During your mainframe CICS development, you depended on the simple mechanics of the transaction.
Mainframe CICS developers generally understood that CICS features such as Dynamic Transaction Backout (DTB), Emergency Restart, and the Journal/Log brought the real benefits of the CICS transaction. On the mainframe, it was gen erally understood that the CICS task, by default, represented a logical unit of work (LUW) and that a CICS SYNCPOINT command could limit the LUW. The point being that these CICS technologies supported the ability to do a rollback/backout if and when it was ever needed. Yes, CICS transactions were great.
Now, I ask you, is that all that CICS was capable of ”just supporting transac tions? No, of course not. As you know, CICS was capable of much more. Likewise, COM+ (Enterprise Services) provides transactional support, and COM+ is capable of much, much more.
Cross-Reference | In Chapter 3, you were introduced to COM+. An abbreviated list of the "services" was presented at that time. |
The following represents a more complete list [3] of COM+ services:
Transactional support
COM Transaction Integrator (COMTI)
Compensating Resource Manager (CRM)
Distributed Transaction Coordinator (DTC)
Just-in-Time (JIT) Activation
Loosely coupled events (LCE)
Object constructor strings
Object Pooling
Queued Components
Role-based security
Shared Property Manager
Synchronization (activity)
Application Pooling
Application recycling
Applications running as NT services
Instrumentation
Low-Memory Activation Gates
Partitions
Resource Dispenser
Services without components
SOAP service
Granted, the transactional support of COM+ is almost all that you ever hear about. However, as you can see, transactional support is just one among many "services" offered by COM+ (hence the name "Enterprise Services").
A full discussion of each COM+ service is beyond the scope of this book. I briefly introduce two of them in section "Using Your Serviced Component." Oth erwise, please use the references provided at the end of this chapter in the "To Learn More" section to assist your continued exploration into COM+ (Enterprise Services).
As you experienced on the mainframe, the transactional support provided by CICS was "separate" from the transactional support provided by DB2 DBMS technol ogies. Yes, it was possible to combine them to work together in one application. Yet, you understood that the CICS transactional support [4] was at the program/task level, whereas the DBMS transactional support was at the database query level.
The same contrast exists in the Windows environment when you use a DBMS such as SQL Server and a product such as COM+ (Enterprise Services). As part of your application design, choose wisely between the two levels of transactional support. If your application requires the benefits of transactional support, please be reminded that you have a choice between component level and database level.
A general approach might be to use database-level transactional support if your database updates are limited to one server, one database, and so on. As your application's level of complexity increases (e.g., multiple databases, disparate data stores, and so forth), it becomes more appropriate to look toward COM+ for trans actional support.
You may even consider adding other COM+ services such as the Distributed Transaction Coordinator (DTC) and Compensating Resource Manager (CRM). The transactional support provided by COM+ greatly exceeds what is available at the database level.
You now have a high-level understanding of what COM+ is. Additionally, you know how to access the Component Services console, which you can use to con figure and manage COM+. Are you ready to find out how to create a .NET-managed component that you can use to access COM+ services? Good! Let's now turn to the topic of creating serviced components.
[2] The COM+ Running Processes folder is available on Windows XP and newer operating systems that have Enterprise Services (COM+ 1.5).
[3] This list was published October 2002 by the COM+ documentation team as part of the platform SDK (see http://msdn.microsoft.com/library/en-us/cossdk/htm/services_toplevel_8uyb.asp and http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/whatsnewcomplus_350z.asp ).
[4] When you work with transactions on the Windows platform, the ACID test applies just as it did on the mainframe/CICS platform. (As you may recall, ACID stands for atomicity, consistency, isolation, and durability.)