I l @ ve RuBoard |
Chapter 14. Serviced Components and COM+COM is a powerful technology. In the old days, to build COM components successfully you had to understand how the "plumbing" worked ”you were forced to spend time worrying about building implementations of IUnknown , IDispatch , and other common interfaces before you could even begin to worry about implementing your business logic. Microsoft Visual Basic 6.0 changed that to some extent, generating much of the required boilerplate code for you automatically. The Microsoft .NET Framework goes a step further by generating COM callable wrappers (CCWs) for your classes if you want to expose them to COM clients . If you read the previous chapter, this is old news. COM had its critics ”it was difficult to build scalable systems or manage distributed transactions or pool resources using COM. So Microsoft developed Microsoft Transaction Server (MTS), which became amalgamated with the Microsoft Windows 2000 operating system family as COM+. COM+ provides a range of features that are aimed squarely at developers who need to create high-performance, easily maintainable systems, including these:
COM+ also has other features, such as the ability to import transactions from an outside environment (known as "Bring Your Own Transaction," or BYOT), compensating resource managers that allow you to implement transactional semantics with nontransactional resources, and interoperability with other processing models that are executing on other platforms through the COM Transaction Integrator. These features are beyond the scope of this chapter, which will instead concentrate on the core features previously listed. If you're approaching J# development as an experienced Java 2 Enterprise Edition (J2EE) programmer, you'll notice many functional similarities between COM+ and the Enterprise JavaBeans (EJB) model. However, there are a number differences (some subtle, others not so subtle) that this chapter will make you aware of. The use of declarative attributes in COM+ to request functionality from the component runtime should be familiar to you because these mechanisms are also used by the .NET Framework. There is good reason for this: Even though COM+ predates .NET, it was designed with .NET in mind. The .NET Framework Class Library contains the System.EnterpriseServices namespace, which defines classes, attributes, and enumerations for interacting with COM+. You can build COM+ components and COM+ clients quickly and easily using the contents of this namespace. In the .NET world, COM+ components are referred to as serviced components . Out of necessity, COM+ had to define its own infrastructure for managing issues such as security. Although the mechanisms used are similar to those of .NET, they are not the same, and they operate independently. This means you have to do a bit of work when you implement COM+ security from managed code. However, COM+ and .NET will merge seamlessly and become one in the not-too- distant future, eliminating such issues. In this chapter, we'll take a good look at how to build COM+ clients and serviced components in J#. You'll learn how to invoke methods on a serviced component synchronously and asynchronously. We'll discuss how to use transactions and take advantage of COM+ object pooling, and we'll look at how to implement COM+ security. Note This chapter assumes that you have some familiarity with COM+ concepts (but you do not need to be an expert). |
I l @ ve RuBoard |