Generalizing COM Interfaces

[Previous] [Next]

Now let's get back to the diagram to see whether we can simplify the model.

Many Interfaces Look the Same

Figure 9-7 highlights the fact that several classes need an interface that allows administrators and other users to maintain data about a specific class of horses. Figure 9-7 displays two such classes, each one with its own maintenance interface.

click to view at full size.

Figure 9-7. The IHorseMaintADO and ITrainerMaintADO interfaces.

Interestingly, the two interfaces look exactly the same. It doesn't take a genius to come up with the idea that the two classes should share the same interface. Figure 9-8 displays such a simplified design.

Figure 9-8. The HorseManager and TrainerManager objects now share the same IMaintADO interface.

Figure 9-9 shows that it's perfectly all right to extend this idea to the viewer interface. Horses as well as trainers are selectable through name patterns, and at least in our solution, both types use a numeric ID to identify individual trainers and horses. Now, as you can see in Figure 9-9, four interfaces have become two. And more important, they fit many other classes in this project as well as in other projects.

click to view at full size.

Figure 9-9. The HorseManager and TrainerManager objects also share the generalized IViewerADO interface.

Increasing interface sharing

You can't use all of our generalized interfaces for all of our classes, however, as you can see in Figure 9-10. To identify a certain country, for instance, a user of our application needs to supply a string ID rather than a numeric one.

click to view at full size.

Figure 9-10. Oops! The CountryManager class can't use the generalized interfaces. Why not? Because the ID of a country is a string.

This isn't a technical issue; it's a business need. The ID of a country must be a string because that's how it's used and that's how it's stored in the database. The ID of Sweden is 'SWE', not something like 123. We have to adapt both our minds and our generalized interface to that fact.

We can radically enhance the usability and versatility of our interfaces by means of a simple change. A Variant can host a string as well as a numeric value, so why not change the data type for each ID argument to a Variant? Then, as Figure 9-11 shows, CountryManager objects (and objects of many other classes) will be able to share the same general interface.

click to view at full size.

Figure 9-11. Now, after changing ID arguments in the interfaces to Variants, the CountryManager class can also support the interfaces.

Permission Roles in COM+ and MTS

A role in COM+ or MTS is an interesting abstraction of users and groups, used to control permissions to access components and interfaces. Applying a role to a component or an interface specifies that any user belonging to the role can call the component or interface. An interesting aspect of roles is that you can define them as you develop your application, even if you don't have a clue as to who the eventual users or user groups will be. This practice allows you to design the security profile of your COM+ and MTS components long before you map users and user groups to your roles.

You define these roles on the application level in COM+ and on the package level in MTS. (As we mentioned in Chapter 2, "Designing for Scalability," a COM+ application corresponds to an MTS package.) Conceptually, COM+ and MTS manage role security the same way, but there are some differences. In MTS, you can't assign roles to methods but only to packages, components, and interfaces. In COM+, you can assign roles to individual methods in addition to assigning them to applications, components, and interfaces. Still, for both technologies, you declare the security profile by assigning roles at development time, and you assign users and user groups to roles at deployment time.

Facade roles

We've said it before, and we'll say it again: in our architecture, the only kind of object the client ever sees is the facade kind. Accordingly, this is the only kind of object the user should have permission to use and execute.

In our horse racing application, several roles can be mapped to actual users or actual user groups. Incidentally, these roles largely coincide with the set of actors you can define in a use case model for the system. Figure 9-12 is a diagram of such a model, and it contains five different actor categories. Let's examine just two of them here:

  • The Customer role is the central actor role for this system. The system is built for customers, and customer needs should govern all system development as well as security actions.
  • The Administrator role covers those users that are responsible for the content of the system. Such users should maintain information concerning horses, trainers, jockeys, and so on, and they should enter races and results into the system.
  • click to view at full size.

    Figure 9-12. Actors in the use case model for our horse racing system.

We don't have to talk about the other user roles to make our point. The two we've just described are enough.

Take a look at Figure 9-13. It's a snapshot from the COM+ Component Services snap-in. A snapshot from MTS Explorer would look very much the same.

Figure 9-13 shows how only users within the Administrator role have access to objects in the Racing - Administrator Facades COM+ application, whereas administrators as well as customers have access to objects in the Racing - Customer Facades application.

Figure 9-13. Roles determine who is and who isn't permitted to use objects in a COM+ application.

Main business services roles

In the preceding section, we talked about how roles are applied to facade applications, components, interfaces, and methods at development time and how users and user groups are assigned to roles at deployment time. We also talked about how actors in a use case diagram correspond to the type of roles we have mentioned so far, roles that represent real users. Now it's time to talk about another kind of role, the kind played by a COM+ application (or an MTS package).

If you want to restrict access to your main business components and interfaces to facade components, which we highly recommend, you must make sure that your facade components run as themselves. To make it possible for them to do that, you or an administrator must create a specific Windows NT or Windows 2000 account for them. Such an account would be what we call an impersonal account since applications rather than real people would use it.

COM+ applications (and MTS packages) can run either as the interactive user or as a specific user. A COM+ application that runs as the interactive user runs as whoever happens to be logged in on the computer that executes the application. This option is often perfect during development, but we normally don't recommend it for the released product. For the released product, you should have the application run as a specific user, and this user should be the type of impersonal Windows NT or Windows 2000 account that we mentioned in the preceding paragraph. Figure 9-14 shows an example of a COM+ application run by this kind of impersonal user.

Figure 9-14. An impersonal user runs the Racing - Customer Facades application.

The User text box in Figure 9-14 is too small to allow you to see clearly, but the user assigned to run the package is COMPlus_APP_Cstmr_Facade in the RACINGMAIN domain. Before you can assign this user to run the package, you must create a Windows 2000 account or a Windows NT account for it. But that should go without saying.

So now you have a specific and impersonal, as in not human, user to run the Racing - Customer Facades application. The next thing you must do is give this user permission to run the main business services applications it needs to access. For that, you need a role in each of these applications because COM+ applications use roles to control permission. Figure 9-15 shows you how only members of the Administrator Facades and Customer Facades roles have access to objects in the Racing - Main Racing Business COM+ application.

All you have to do now is to make the impersonal user running the respective facade applications a member of the roles that are permitted to access the main business application. When you or an administrator has done that, your main business application is both secured and accessible. When a component in the Racing - Customer Facades application—the client—calls on a component in the Racing - Main Racing Business application—the server—COM+ examines who's running the client and if the user is a member of any of the roles allowed to access the component. If so, access is allowed; if not, access is denied.

Now, as Figure 9-15 indicates, customers as well as administrators are able to use objects in the Racing - Main Racing Business COM+ application, but only through their respective facade COM+ applications, not directly.

Figure 9-15. Only members of the Administrator Facades and Customer Facades roles have permission to run objects in the Racing - Main Racing Business COM+ application.

Some services performed by HorseManager objects would, however, be extremely improper for customers to use. So we need a more fine-grained permission system, and COM+ particularly but also MTS has that because both allow you to assign roles not only to components but also to the individual interfaces of components.

The Horse component (ADBArkRacingBsns.Horse), shown in Figure 9-16, exposes several interfaces. One of them, the IHorseMaint interface, allows only Administrator Facades to use it. Another one, the IHorseViewer interface, permits both Administrator Facades and Customer Facades roles to use it.

As we mentioned before, you can go an additional step down in COM+ (but not in MTS) to assign roles to the individual methods of the interface.

In a similar way, components in the data access COM+ application permit access only to main business services components. Using roles, components and interfaces in the Data Access application forbid UI components and facade components to use them directly. The only way for a UI component to access data if the security system is properly set up is to access a facade component to which the user of the UI component has access. That facade component can't access the data access component directly, only through a main business services component.

click to view at full size.

Figure 9-16. Different interfaces of the same object might have different permission profiles.

Such a security system is built on trust. Using role-based security, data access components trust certain main business services components, which trust certain facade components. The facade components trust human users that belong to a specified role or a specified set of rules. Building such a system, you assume that once a user is permitted to call a method in a facade component, that user should indirectly have access to everything the facade method needs to do its job.

This is the main idea behind role-based security in COM+ and MTS. Both COM+ and MTS also use another kind of trust. The following sentences refer to COM+ in describing this trust system, but you can replace the words COM+ applications with MTS packages. They both work the same way as far as trust goes. Components within the same application in COM+ always trust one another. When an object belonging to a COM+ application calls another component belonging to the same COM+ application, COM+ doesn't do any security check at all. It's only when a call is made into a COM+ application, or between COM+ applications, that permission is checked. The trust that exists inside a COM+ application doesn't extend to the outside of the application.

To boil it down, role-based security in COM+ and MTS makes it easy to set up and maintain a fine-grained declarative security system for a distributed application. If you need it, you can use code to programmatically enhance the security of the system, but if you plan your system right you normally won't have to. For the facades of your business services tier, assign roles in which the members are real human users and user groups. Let the facades be the only place where COM+ checks the real users' permissions. For the main business components, assign roles in which the members are impersonal users that run the facades. For the data access components, assign roles in which the members are impersonal users that run your main business services components. For the database, assign permissions to the impersonal users running the data access components, not to the real users that access the facade components.



Designing for scalability with Microsoft Windows DNA
Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)
ISBN: 0735609683
EAN: 2147483647
Year: 2000
Pages: 133

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net