Specifying Exception Classes
There are instances, when the queue cannot recover from errors by itself. An example would be insufficient access rights to write messages to the utilized queue. In this case, a special exception class can be invoked. This class is specified on a component-by-component basis. The setting can be found in the "Advanced" tab of the component property dialog:
Providing adequate security for a software system is often one of those tasks that is the least interesting to the developer, ranking at about the same level as writing documentation. Sometimes it is left until the final stages of the development process, or in some cases it is overlooked entirely. As COM and COM+ applications become more common, adequate security is rapidly becoming an even more important consideration. In today's world of components and distributed systems, security means more than whether a user can run an individual application, but is instead a vital element that should be integrated throughout the entire system.
In distributed applications, the COM+ Security model provides platform independence. Because security is implemented on the server side, the system can be used by clients of different platforms. This allows the component developer to program to the security interface instead of worrying about the underlying implementation. Windows 2000 provides a standard interface called the Security Support Provider Interface (SSPI), which allows security vendors to create their own security systems that are tailored to various business needs. The design and architecture of SSPI is similar to that of ODBC. ODBC provided a standard way of retrieving data from various databases by using different ODBC drivers that implemented a standard ODBC API.
In the same way, SSPI provides the developer with a common interface to the system security, but at the same time allows security providers to internally implement their own security enforcement mechanisms. Windows 2000 ships with both NTLMSSP (NT LAN Manager Security Support Provider) and Kerberos. NTLMSSP is primarily provided for backward compatibility, while the default Kerberos is a more sophisticated and feature-rich authentication package.
The term security is a bit ambiguous, and means different things to different people. From a software point of view, security specifies and enforces WHO can perform WHAT action in WHAT part of the system. Authentication is the process that determines WHO is trying to perform the task, and makes sure that she is who she claims to be. Authorization is the process that then determines whether or not the user is allowed to perform the task she is requesting.
COM+ security consists of the following features:
First let's examine role-based security. A role is a symbolic name that identifies a group of users specific to a certain COM+ application. Conceptually, this is very similar to that of a "user group" in Windows 2000. Let's say, for example, that we are building an application for an organization that has managers, administrators and employees. The managers may have permission to instantiate a customer object and to change information, while the administrators may only be able to instantiate and view existing information. Perhaps employees are not allowed to do anything at all with the customer object. Individual users can simply be assigned to roles, according to the type of security desired for them. This approach gives us an easy and flexible method for creating and maintaining security.
There are two types of role-based security - declarative and programmatic. For each COM+ application, the system administrator can utilize the Component Services Administrative Tool snap-in to set up the security:
Declarative security has the advantage that it is extremely easy to set up and requires no added code in the component. It is quite flexible because it allows roles to be defined not only at the component level, but also at the individual method levels. However, if a finer degree of granularity is required, declarative security can also be used to provide total control and flexibility from within the components, in a programmatic fashion.
Our first secure component
Let's create a small component and secure it using the COM+ security features.
Our example is a very simple customer business object. The object itself doesn't
provide many features, so that we can keep this example simple:
As you can see, some of the values in this component are hard-coded for example purposes.
We compile this code into a multi-threaded COM DLL (create a project named "VFPSecure", add the PRG that holds the above code, and build the project as a multi-threaded COM server).
Once we have built the component, we can install it in the COM+ system. To do so, open the Component Services MMC snap-in from the Windows start menu (Programs/Administrative Tools/Component Services). Drill down into the COM+ applications of the current computer (My Computer), right-click on the COM+ Applications item, and add a new COM+ application. In the wizard, specify a name for your application, and accept all the defaults.
Now that we have a new COM+ Application, we can add our components to it. Depending on whether you build the Visual FoxPro or the Visual Basic version, you will use the VFPSecure.DLL or VBSecure.DLL in the following example.
Right-click on the "Components" item in your new COM+ Application, and select "New/Component" to launch the component setup wizard. Make sure you choose to install a new component and don't select to import a previously registered component: