Defining the Physical Architecture | Designing Component-Based Applications

Once the conceptual design is in place, you can start fleshing out the physical architecture of your application. During physical design, you perform the following tasks:

Group COM classes into components
Group COM components into MTS packages and processes
Assign packages and processes to machines

At this stage, you won't fully define the physical architecture. In fact, some decisions about assigning packages and processes to machines can be left to the system administrator who installs your application. However, if there are performance, deployment, or security requirements that will constrain your design and implementation, you should define those now. Also, you will need to determine how COM classes are grouped into components in order to implement the classes.

Grouping Classes into Components

For most classes used in MTS, organizing classes into components is easy. Each externally creatable COM class is implemented in its own in-process component. If you happen to have some COM classes (call them S1, S2, and so on) that are instantiated only via some other class (call it C), you will probably want to include Sn in C's component.

You don't want to include too many classes in a single component for the same reason you don't want to include too many methods in a single interface—if your component carries a lot of unnecessary overhead, people won't want to use it. However, if you have several classes that share implementation code or are generally used together, you might want to put all the classes in one component to simplify deployment and maintenance. For example, independent software vendors (ISVs) that create libraries of COM classes for sale to other developers might want to package those classes into a small number of components to simplify setup, redistribution, and licensing. All the classes defined so far in the Island Hopper application are placed in individual components.

Grouping Components into Packages and Processes

As mentioned, MTS uses packages as units of trust and units of deployment. A package is simply a set of components that perform related application functions. A component can be installed in only one package on a machine. There are two types of packages: library packages and server packages. A library package runs in the process of the client that created it. A server package runs in a separate process.

We'll discuss grouping components into packages and processes in detail in Chapter 10. For now, all you really need to do is look at your deployment and security requirements to see whether they imply anything about packaging. For example, if you need to authorize calls to a component, the calls must cross a package boundary. Components that must run on separate machines obviously need to go into separate packages. You can also look at the presentation layer to identify processes running outside the scope of MTS. In the Island Hopper application, we can identify two likely packages at this point: one for things controlled by the classified ads department and one for things controlled by the accounting department.

Assigning Packages and Processes to Machines

Most decisions about where packages and processes should run can (and should) be postponed until much later. However, if you have identified particular deployment requirements that apply to certain components, you should document how those requirements apply to the packages and processes you've defined. The Island Hopper application has no special deployment requirements for integrating into an existing enterprise infrastructure. All the components can run on a single machine.

Documenting the Physical Architecture

You can use Visual Modeler to document the physical design of your application as well as the logical design. You use component diagrams to describe how classes are grouped into components and packages. You use deployment diagrams to describe how packages and processes are distributed among machines in your system.

To create a component diagram, open your existing Visual Modeler document and expand the Component View in the Browser pane. You'll see one default component diagram named Main in that view. Double-clicking Main will open its component diagram. You can add an element to the diagram by choosing Create from the Tools menu and then selecting the appropriate element to add. You can add component packages and components to this diagram, as well as create dependencies between them. You can also create additional diagrams and attach them to specific packages in the model.

NOTE
A component package in Visual Modeler corresponds roughly to an MTS package. A component in Visual Modeler can be a COM component, a separate application, or a utility DLL.

The easiest way to begin your component diagram is to use the Main diagram to list the MTS packages and separate client processes in your application as well as define the dependencies between them. Model each MTS package as a Visual Modeler package. Model each client process as a Visual Modeler component and set its stereotype to Application using the Specification Properties window. Set the name of each package and application using its Specification Properties window—you can access the Specification Properties window by selecting the item and choosing Specification from the Browse menu. If classes in the logical model will be implemented directly in a client application, use the Realizes tab in the Specification Properties window to assign classes to the application.

For each package, create a new component diagram. You can do this by right- clicking on a package name in the Browser pane and choosing New and then Component Diagram from the pop-up menus. Add the COM components assigned to the package to this diagram. Model each COM component as a Visual Modeler component and set its stereotype to DLL using the Specification Properties window. Set the name of the component using its Specification Properties window. Now you can assign classes from the logical model to the component on the Realizes tab. Right-click on a class from the list and choose Assign from the pop-up menu, as shown in Figure 7-8.

To create a deployment diagram, open your existing Visual Modeler document and double-click on Deployment View in the Browser pane to open the deployment diagram. You can add an element to the diagram by choosing Create from the Tools menu and then selecting the appropriate element. Machines are represented as nodes in this diagram. Physical connections between machines are represented as connections. You set the name of a node or connection by using its Specification Properties window. You can also use the Specification Properties window to provide additional documentation for each element. You can assign processes to nodes using the Details tab of the Specification Properties window. The processes you enter here are not directly connected to other elements of your model, such as any components or packages you have defined. Nor does Visual Modeler generate any code based on this diagram. However, it is useful for documenting deployment constraints and decisions. A deployment diagram for the Island Hopper application is shown in Figure 7-9.

Figure 7-8. Assigning a class to a component in Visual Modeler.

click to view at full size.

Figure 7-9. Deployment diagram for the Island Hopper classified ads application.

You should continue to update the component and deployment diagrams as you make packaging and deployment decisions throughout the application's lifetime.

NOTE
The complete component and deployment diagrams for the Island Hopper classified ads application are contained in the CLASSIFIED.MDL file, which is located in the \IslandHopper\Design directory on the companion CD. You can use Microsoft Visual Modeler or Rational Rose to view this model.