 |
|
Believe it or not, the release of the Windows 2000 family of operating systems is just around the corner. In the plethora of long-awaited features that have fueled discussions, religious debates, and rumor-style announcements over the past couple of years, the award for the most significant and ground-breaking piece (in the Windows realm at least) easily goes to COM+.
An evolutionary technological step that merges both the old-style COM (Component Object Model, Microsoft's successful attempt at standardizing binary-level component-based development) and the newer but not less complicated MTS (Microsoft Transaction Server), COM+ seamlessly injects into Windows 2000 a rich set of services geared towards the programmers of multitier enterprise systems grounded on COM. From transparent transactional services (unlike in the NT 4.0/MTS days, when the developer had to deal with a context wrapper to enable them) to load balancing, from JITA to queued components, including load balancing and simplified deployment of installation packages (now called COM+ Applications), the suite of built-in tools in possession by the next generation of Windows programmers can egregiously stand the competition of Corba and the Java camps, who bank on a combination of applets, servlets, and EJBs.
According to Microsoft's Windows DNA vision for the enterprise, the full bag of services, still linked by the glue that is COM (DCOM on distributed scenarios) at the lower levels, constitutes the net to which business logic code hooks to in the much touted "middle tier." And to make implementation and maintenance simpler, the attribute-based programming model (which holds its roots in the presence of contexts and interceptors) finally permeates the technology inside out.
Simpler in comparison to the past, sure, but not simple at all in absolute terms. Leveraging COM+ services to the best to build a real-world information system with a good eye for future evolutions still requires a considerable effort. Especially during the first months following the official inception of the product, when its actual strengths and glitches haven't been unearthed yet, but await the first courageous programmers to run into them and spread the word. This being said, what is a poor enterprise programmer to do to avoid serious headaches?
By all means, the first action should be to pick up a copy of Understanding COM+. Very readable and accessible, this book perfectly reaches the goal of presenting COM+ from a 10,000 feet view to the current COM programmer as well as to the manager on duty, regardless of the programming language of choice. The design, the writing style, and the reasonable number of pages have all been tailored to permit a comfortable read in very short timeframes. Don't expect real code or internalist type tips-and-tricks from this book: The alleged target is to communicate the big picture, not the nitty-gritty details.
The only real drawback of this manual is a consequence of one of its best advantages: The author had the privilege of working closely with the COM+ team in Microsoft during the shaping of the content. This helped immensely shipping it months ahead of time, unfortunately, Microsoft's strategy slightly changed in the meantime. The news is that the Transactional Shared Property Manager, the IMDB, and the Load Balancing services will all either be released at a later point in time, included in only the most large-scale (and high-priced) versions of Windows 2000 or substantially revisited. This explains the nonbrilliant grades I gave it under the categories Timeliness and Accuracy.
While not the ultimate COM+ cookbook and even somewhat unreliable in certain chapters due to the uncertainty that surrounds some described services (this is Microsoft's fault, not the author's), David Platt has done a good job at clearing up what COM+ really means at the current point in time, what services and major paradigms it purports, and how they were designed to work fit in a multitier system.
Because this technological area is so complicated, it is unlikely that the average programmer will purchase less than 3-4 books on the subject and spend less than several weeks familiarizing with it. In this perspective, make sure the first item in the "to read" list is Understanding COM+. You'll find it enormously easier to internalize and assess more pragmatic texts later on.
-- Davide Marcato (http://www.DavideMarcato.com)
(From Chapter 3 - Transactions, page 94)
"Just-In-Time Activation in Transactions
"Just-in-time activation is a mechanism, provided by the operating system whereby actual instances of an object are activated just prior to the first call made to them and are deactivated immediately after they finish their work. When I say that an object is activated, I mean that it is either created or fetched from a pool of existing objects. When I say that an object is deactivated, I mean that it is either destroyed or placed back in the pool. (Object pooling is discussed later in the "Transactions and Object State" section of this chapter.) Use of JIT activation is mandatory for transactional components. Nontransactional components can also use it if needed.
" In JIT activation, the client creates an object and receives a standard proxy and stub connected by a channel, as shown in figure 3-13. Once the object is created, the client makes calls to it as usual. When the object is deactivated, COM+ releases its reference to the actual server-side object, as shown in figure 3-14, and the object is destroyed or placed back in the pool.
" However, since the client has not released its reference to the object, the client-side proxy still exists, and so do the server-side stub and the channel connecting them, as shown in the diagram. When the client next makes a call to the proxy, the proxy communicates with the stub via the channel, and a new instance of the desired object is activated "just in time," as shown in figure 3-15.
" JIT activation was first presented to the world as a scalability feature for recovering resources. A user-driven client application often creates an object, makes a method call, and holds on to the object for later use. Five minutes or an hour later, the client might make another method call. In between, the object is hanging around, tying up resources. This doesn't matter much in the desktop environment, where you typically have one, two or three clients per COM server, but an enterprise server can easily have a hundred or more clients coming and going. You can see the resource-loading problems that would arise if the clients all hung on to resources that they weren't currently using, because they might need them later."
(From Chapter 7 - Load Balancing, page 216)
"Load-Balanced Client Design
" A client application doesn't do anything different when creating a component that is load-balanced than it does when creating one that isn't. The client application simply creates an object, specifying the load-balancing router as the host. The client doesn't know whether the object that resulted from the call is running on the machine it specified or on one to which the router delegated the object creation. In general, you probably don't want your clients to have to care whether their components are load balanced or not.
" A client should be aware that if a component is load balanced, a server dying doesn't necessarily mean that the client is useless until that server comes back up. The application cluster may contain other servers that can take over the load. Suppose a client creates an object that, after load balancing, actually resides on server A. The client makes a few calls on the object, then server A blows its power supply and dies. In this case, the next time the client makes a call on the object, the call will time out, and the client will receive an error code indicating that the server has in fact died. The client should, at this point, release its object and try to re-create it; the router will route the creation request to a server that is still running. A client that thinks it might be using a load balanced component should release and re-create the object when it encounters a server failure."
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.