COM and MTS Packaging

[Previous] [Next]

We also want to spend a little time talking about packaging in MTS and COM+. Both technologies give you many options for packaging your components in a flexible way. You can also easily move a component from one MTS package or COM+ application to another.

One thing that you should understand about COM+ applications and MTS packages is that each package or application will run in its own process. All calls within the same package or application are made in-process; all calls between applications or packages are out-of-process.

You should also understand that packages in Rational Rose and Microsoft Visual Modeler are different from packages in MTS. The Rose packages are logical Unified Modeling Language (UML) packages, which can be physically deployed in different ways, even compiled together in different combinations, whereas MTS packages are as physical as can be. You can't install parts of an MTS package on one computer and other parts on another computer. As long as you're still a Microsoft Windows NT and MTS developer or user, you have to be careful when you talk about packages. A package can be an MTS package or a Rose package, and they are very different concepts. As soon as you leave Windows NT and MTS for Windows 2000 and COM+, this difficulty goes away. In COM+, the application has taken the same role the package did in MTS.

For the rest of this section, we're going to let the concept of COM+ applications cover both COM+ applications and MTS packages; we won't mention MTS packages anymore. But if you still work with MTS, please read MTS package every time we write COM+ application.

From a security standpoint, components within the same COM+ application trust one another. In a hypothetical example, you could set up a special component named TM (Transaction Manager) to manage a certain complex transaction. This component calls two other components named TS1 and TS2 (for transactional services or modifier 1 and 2, respectively), both of which modify the database and both of which are installed in the same COM+ application as TM. Security is set up in such a way that a client C is permitted to create and call TM objects but forbidden to create or call TS1 or TS2 objects. If C tries to make a direct call to TS1 or TS2, COM+ rejects the call and returns an error message saying so.

But C can create and call a TM object. The TM object then calls first TS1 and then TS2 on behalf of C. Because both of these components are installed in the same COM+ application as TM, both these calls are successful. This means that client C can take advantage of services performed by the TS1 and TS2 components, but only indirectly, through the TM object. When the TM object calls TS1 and TS2, COM+ doesn't even bother to check for TM's permission. Components installed in the same COM+ application always trust one another, so there's no need to waste any time on security checking inside applications.

Security is checked when a client enters a COM+ application, never when the same client moves between components in that application.

Easy Packaging

The easiest form of packaging is to put all your components in the same COM+ application. We'd like to show you a small series of pictures, each of them representing one way of packaging the same set of components. We've taken the set of components from our horse racing application, but we've minimized the set to a handful so we can manage them with ease. In the first example—see Figure 23-6—we've packaged all our components in the same COM+ application.

Such a deployment can be very efficient since all the calls between compo nents are made in-process. But from a security standpoint, such deployment might be less attractive. As soon as a user enters the package, everything the compo nents he uses try to do is permitted. Components in the same package trust one another, remember?

By the way, take a look at the arrows connecting users to components and also component to component. We found it interesting to see how well ordered the movements of events are between users and facade objects as well as between main business objects and data access objects, but also how disordered they are between facade objects and main business objects. This emphasizes the role facade objects have: they simplify matters for clients.

Figure 23-6. All the components are installed in the same COM+ application.

Imagine this picture without the facade tier. Client programs would have to cope with that lack of order, with that complexity. Now they don't have to. The facades handle it for them.

As we show our next few deployment alternatives, we'll skip the arrows between components. We feel they've done their job. We'll draw arrows between applications, but that's all.

Facade package per type of user

In Figure 23-7, we've deployed our components in a somewhat more sophis ticated manner. Each type of user—or actor, if you like—has its own facade application. This means that the security system can be much more sophisticated. This deployment makes it easier to give users access to the functionality they need and should be permitted to use, just as it can keep them away from functionality they don't have any valid business with.

The design presented in Figure 23-6, with every component installed in the same COM+ application, has only one deployment alternative. You must install every component on the same computer. With the design presented in Figure 23-7, several deployment options are available.

• First, you could put all your facade applications on one computer, perhaps a server running Microsoft Internet Information Service. You could put the main business application and the data access application on another computer. Such a deployment would bring the combined power of two computers to your application, and it would also add flexibility to it.
• Second, you could put your facade applications on client computers. You can't do that if your clients are standard HTML 3.2 clients, but you can if they're ordinary Windows clients, for example running Microsoft Visual Basic forms. You can also do it for DHTML clients running on Microsoft Internet Explorer 4.0 or later. With such a deployment, you have added considerable power and flexibility to your application.
• Even though you've spread your components around in several COM+ applications, you could still put them all on a single computer. So if you compare this strategy with the one COM+ application solution, you really haven't lost anything. Rather, you don't lose anything if you don't count the performance loss you must suffer from making a number of out-of-process calls that could have been in-process calls.



Figure 23-7. Now each type of user (actor) has its own facade package.

You can, however, take this design at least one step further, as you can see in Figure 23-8. This figure shows the main business components and the data access components no longer sharing the same COM+ application. Because they're now in different applications, you can also deploy them on different servers.

More and more, we find arguments for deploying data access components on the same server as the database. For one thing, a complex transaction, requiring more than one access in the database, runs faster than it would if every data base access also required a network round-trip. For another thing, every time a business rule check means accessing the database, the check runs faster if the data access objects and the database are on the same server. And for the same reason, which is fewer network round-trips. So, in many situations, a distribution of components between packages like the one shown in Figure 23-8 can be ideal. Not in all situations, though. We must remind you that your data access components in this deployment will compete for resources with the database software. To get the true picture, you must balance network round-trips against server resources, and you'll probably get different results for different installations.

Figure 23-8. With this packaging, many deployment options are available.

Resource Objects and Real Business Objects

In some cases, it would even pay to separate resource objects from operational business objects. A resource object is something you need to run a business. A customer, a supplier, a product: all of them are resources needed to run a commercial business operation. To run a horse racing operation, you need resources such as horses, jockeys, trainers, and racetracks. Operational business objects would be orders, invoices, and purchases in a commercial business; in the horse racing business, they would be race days, races, and race entrants.

Resource objects are more liable to be reused by many applications than operational business objects are. Therefore, it's sometimes a good idea to package resource components and operational business components in different COM+ applications. We wouldn't recommend that you always do this, but sometimes it might be profitable to at least consider this possibility. Such a design, separating resource components from operational business components, would give you a chance to install the resource components on a central server, or even in an application cluster such as the one being released with Microsoft Application Center 2000 by the end of this year. Each operational business COM+ application could have its own server, and all these operational business COM+ applications would share the use of the resource components.