17.2.1- COM+ and Component Services

<< 17.2.0- COM+ Components

Chapter17

17.3.0- Summary >>

COM+ and Component Services

We've mentioned in passing that in COM+, Microsoft have taken the transaction and component management capabilities of Microsoft Transaction Server (MTS) and integrated them with COM – along with 'some other bits and pieces of functionality'. So let's break it up a bit, and try to understand some of the different facilities that COM+ provides.

COM+ as a Transaction Manager

As we've seen, we can use COM+ as a transaction manager for our applications. As we saw earlier, this means (for example) that COM+ is able to listen to our transacted applications as each transaction is performed; it can analyze the votes cast and determine whether the transaction should be committed or aborted; and it can help us to manage the commit and rollback procedures within our durable data (in our data stores).

 

In the examples we've seen in this chapter so far, we've seen this in action – in each case we saw a simple ASP application that used COM+ to manage the transactions involved.

COM+ as a Component Manager

Moreover, COM+ can also manage the components themselves. So, how would we use COM+ as a component manager? Well, we can tell COM+ to create a deployment unit called a COM+ Application (or just an Application). Then, we install the necessary components into the COM+ Application. Then, when some other ordinary application (such as an ASP application) needs to use the objects of such a component, COM+ manages the instantiation of these objects for us.

 

So, if you like, these COM+ components belong to COM+ itself (by virtue of being installed into a COM+ Application) – and COM+ manages the way that they are farmed out to the applications that require them.

 

Further, if these components require transactional support, then COM+ is able to act as transaction manager to those components. We tell COM+ about the transactional needs of a component at the time we install the component into COM+ (we'll do exactly that in our example shortly). This means, for example, that we can call a transactional component from an ASP page, and we don't need to set the @TRANSACTION directive in our ASP page. Because the component is installed into a COM+ Application, COM+ will automatically act as the transaction manager for the component.

We haven't used this technique so far in this chapter. In a moment, we'll see an example that uses a transacted component, installed into a COM+ Application, to perform a cash transfer. We'll see that the ASP page that uses this component doesn't need to concern itself with transactions at all – the COM+ Application does it all for us. 

COM+ as a Security Manager

COM+ also provides a number of security features for the components that are installed into the COM+ Applications. There are automatic security features, which can be added and configured using the Component Services administrative tool that we'll meet in a moment. Other security features can be integrated directly into the development of the component. COM+ also allows us to implement role-based security – this is the central feature of COM+ security. It allows us to set our security preferences for individual methods of a component, so that we can allow some methods to be accessible to all users, but allow other methods to be accessible to only certain privileged users.

COM+ Services

In addition to the 'integration' of COM and MTS, COM+ also brings a number of COM-related facilities, called services. A service is some facility that is provided by COM+, and which the installed component can choose to use when it is called. For example, if the component can generate COM+ events, then COM+ provides support for this by loading and initializing the appropriate set of libraries at runtime, when the component is called. These libraries are COM+ services.

 

We've skimmed over the main points of COM+ here. A detailed discussion of COM+ is beyond the scope of this book. One popular book that covers the basics of COM+ in more detail is Understanding COM+ (Microsoft Press, ISBN 0-735606-66-8).

The Component Services Snap-In

So how do we control and configure the COM+ Applications, COM+ Services and all the other things provided by COM+? The easy answer lies in the Microsoft Management Console (MMC). Microsoft have provided a snap-in, called Component Services, which snaps into the MMC shell and gives us easy access to all the different areas of COM+.

 

Let's have a look at the Component Services snap-in now. The easiest way to open this snap-in is from the Start menu There, select Programs | Administrative Tools | Component Services. This will automatically start up the MMC shell, with the Component Services snap-in (and a couple of other snap-ins) within:

 

 

This is an easy-to-use interface that allows us to configure our COM+ components and other aspects of COM+. The pane on the left of this dialog works just like a folder structure in Windows Explorer. Expand the Component Services node a few levels, until you see something like this: 

 

 

As you can see, there are a number of nodes under the My Computer node, and one of them is COM+ Applications. Under here, we can access for all the COM+ Applications that are installed into COM+ on this computer.

 

As we mentioned above, a COM+ Application is a set of COM components. Generally, the components within a particular COM+ Application perform related functions. By grouping a set of components together in this way (i.e. within a COM+ Application), we can perform administration and configuration on the entire group of components as a whole, if we wish.

 

You should find that a number of COM+ Applications already exist in your Component Services window – as they do here, on my machine. In the example below we'll be creating a new COM+ Application of our own, adding a component to it, configuring it and then using it in an ASP page.

An Example using a COM+ Application

Now, we'll complete this chapter by using the techniques of componentization and transactions all-in-one. Our example returns to the cash transfer problem in our Bank scenario. We'll take a ready-made component that encapsulates the cash transfer logic, the data access logic and the transaction logic, and we'll install it into a COM+ Application; then we'll use that component within a non-transactional ASP page.

 

Before we look at the example, let's just think briefly about the process that we would go through when creating components for installation into COM+. It is, essentially, a three-step process:

 

• Designing and building the components
• Creating the COM+ Application, and installing the components
• Configuring the COM+ Application to meet our requirements

 

You'll be able to see these three steps in the example that follows – except that we're going to take a short-cut for the first step by using a ready-written component.

Our Ready-Written BankAccount Component

We've done a little component design and creation, back in Chapter 16 – we used the Windows Script Component tool to build the script-based components CarpetPricer.wsc and BankAccount.wsc, and we used them within ASP pages. But for this example we'll use something a little more robust than a script-based component.

 

In fact, in this example we're going to use a component called WroxBank.Account, which is contained in the dynamic link library file WroxBank.dll. This component was written using Visual Basic 6.0, and compiled into the DLL (the DLL is the executable version of the component). Components written in languages such as Visual Basic, Java, and C++ are generally more robust than their script-based counterparts – they're more easy to transport, more efficient and considerably easier to install into a COM+ Application (which expects a file such as a .dll or and .exe).

 

We're not going to show you how to program this component in Visual Basic. If you'd like to know how it works, you can take a look at the WroxBank.vbp file that contains the source code for the component. If you like, you can use the source files provided to compile the .dll for yourself – you'll need a copy of the Visual Basic 6.0 development software. Alternatively, we've provided the compiled WroxBank.dll file too, so you don't need to compile it if you don't want to.

The source files and the .dll are available along with the other files for this chapter at the WROX website .

 

The WroxBank.Account component will support the ability to transfer funds from one account to another, through a single method called Transfer. The syntax for this method is as follows:

 

 blnSuccess = objBank.Transfer(strDB, srcAcctID, destAcctID, amount)

 

Here, the strDB parameter expects a database connection string – we'll use this parameter to pass the connection string for the database that holds our bank account information. The srcAcctID and destAcctID parameters expect the account IDs of the two accounts involved in the transfer. The amount parameter represents the amount of money being transferred from the source to the destination. Note that the method will return a Boolean value, which indicates whether or not the transfer was successful.

 

OK, that's all we need to set up this example and get it running.

There are lots of steps in this example, but as you'll see it's not difficult to complete. First, we'll register the WroxBank.dll file on our machine. Then we'll use two wizards – the first will help us to create a COM+ Application, and the second will help us to install our component into the new COM+ Application. Then we'll configure the component within the COM+ Application (to tell COM+ that the component requires transaction support); and finally we'll test it using a simple ASP page.

 

1.    We'll be using the Bank database that we've used in the other examples in this chapter. Therefore, you'll need to ensure that your Bank.mdf file is contained within the C:\MSSQL7\Data folder (or, if you're using SQL Server, that your Bank database is set up on the SQL Server machine).

2.    Take a copy of the WroxBank.dll file, which you'll find with the other files for this chapter, and save it to a convenient folder on your hard disk. (Alternatively, use Visual Basic to compile WroxBank.dll for yourself, using Visual Basic 6.0.)

3.    Now we need to register the component. To do this, select Start | Run. In the resulting dialog, type RegSvr32 <path>\WroxBank.dll. For example, if you saved WroxBank.dll into a folder called C:\Wrox\BegASP folder, then you should type something like this:

 

 

When you click on OK, the component should be added to your machine's registry. Then you'll receive the following confirmation of success:

 

Click OK again to continue. Now the component is ready to be installed into COM+.

4.    The next step is to create a new COM+ Application, which can contain any components that we wish to group together. If you haven't already done so, open up the Component Services snap-in (by selecting Start | Programs | Administration Tools | Component Services). Expand the nodes on the left of the dialog until you can see the COM+ Applications node. Then highlight the COM+ Applications node, and from the Action menu select New | Application:

 

 

This will launch the COM Application Installation Wizard, which will walk us through the creation of our new COM+ Application.

5.    The first screen in the wizard is just a splash-screen; just click Next. The second screen asks us whether our new COM+ Application is based on a pre-built Application, or should be a new one. We are creating a new application, so select Create an empty application (this will immediately take you to the next step of the wizard):

 

6.    Now we need to enter the name of our new COM+ Application – type the name Bank into the text box. We also need to specify whether we want a Server or Library application. The default is Server, which means that our installed components and the ASP application that calls it would run in different pieces of processing space on our machine. That's fine for our application, so select Server application and click Next.

 

 

If we'd opted for a Library application, then the components of the application would run in the same piece of processing space as the calling application. A Server application provides a slight performance penalty, because calls to the component must cross the boundary between pieces of processing space. However, they are a little safer because if one part of the application crashes then the other parts of the application are protected and will not crash.

Also, we can Stop and re-Start a Server COM+ Application without affecting the web server, which means that it's much easier to change and retest the component repeatedly if necessary.

 

7.    The next step is to determine the 'user identity' under which the application will execute. For our example, and for most of the COM+ applications that will be used with ASP, we will select Interactive User. This means that the incoming user's credentials will be used for the component:

 

 

Then click Next. That's the last step of the wizard – the final page just informs you that the COM+ Application is created (so just click Finish). If you return to look at the Component Services snap-in, you'll see that there is a new node called Bank, under the COM+ Applications node.

8.    Now we can install our components into the COM+ Application. Expand the tree a little further until you can see the Components node underneath it (the right-hand pane of the window displays any components installed in the application – at this stage it will be empty). Highlight the Components node, and from the Action menu select New | Component:

 

9.    This will fire up the Add Component Wizard (again, the first screen is just a splash-screen, so click Next). This wizard helps us to install components and event classes into our COM+ Application. We're not concerned with COM+ events or new components – we're going to install our WroxBank component, which is already registered. Therefore, in the second screen select the second button:

 

 

10.  After a short wait, the next screen will display a list of all components that are registered on the system (and which aren't part of a COM+ Application). Place a check in the Details checkbox – this will allow us to view the filenames and CLSIDs of the components. Now scroll though the list until you find the WroxBank.Account component that we just installed. Click on the component to install it into our COM+ Application. Then click Next:

 

11.  That's the end of the wizard. The final screen tells us that we've provided enough information to install the component into our COM+ Application. If you return once more to the Component Services snap-in, you'll see that our component has appeared under the Components node.

12.  Now we can modify the properties of any components in the COM+ Application. To do this, highlight the WroxBank.Account node in the snap-in, and from the Action menu select Properties: 

 

 

This will bring up the WroxBank.Account Properties dialog. All we need to do here is set the transaction properties of this component; so choose the Transactions tab. Since we want this component to always work inside of a transaction, we will set the Transaction Support radio button to Required. Then press OK to close this property page:

 

13.  Now our component is ready to use, so we'll write an ASP page that will use it. Here's a very simple page to test it – you can build a more complex page in the style of earlier pages In this chapter if you like. Open up your favorite editor, create a new file (which we'll call ComponentBank.asp), and enter the following code:

 

<!-- #INCLUDE FILE="BankConnection.asp" -->

<%

  Dim objAcct, strDB

  Set objAcct = Server.CreateObject("WroxBank.Account")

  strDB = strConn

 

  Dim srcAcct, destAcct, amt, blnSuccess

  srcAcct = "9832-5830"

  destAcct = "4735-9275"

  amt = 225

 

  blnSuccess = objAcct.Transfer(strDB, srcAcct, destAcct, amt)

  Response.Write "<P>Transaction Success = " & blnSuccess & "</P>"

  Set objAcct = Nothing

%>

 

14.  Save this file as ComponentBank.asp, into your \inetpub\wwwroot\BegASPFiles folder. Then use your browser to view the page, and observe the results. If the account IDs in the code were valid, the source account balance was large enough to support the transasction, and the other business rules were met, then the transfer should complete successfully.

15.  Change the amt variable in the ComponentBank.asp file to a number greater than the balance in the source account; or change the account details to specify an invalid account ID. Now reload the page in your browser so that another transfer is attempted. You will see that the transaction is aborted – and if you observe the values in the database, you will see that no changes were made.

How It Works

Since the COM+ component has its transaction property set to Required, it will always be executed within the scope of a transaction. Note that our sample ASP page does not have a @TRANSACTION parameter at the top – this means that there is not an existing transaction when the page calls the component's methods. The Required parameter on the component will force a new transaction to be started.

 

So now within this component, we have an active transaction. The component performs interactions with the database, as well as checking and maintaining the business rules (such as validating the account IDs and confirming that there is enough in the source account to support the transfer without going overdrawn). If an error occurs while accessing the database, or if one of the bank system's business rules is violated as a result of a database operation, then COM+ will detect the failure and will arrange for the transaction to be aborted.

 

When the transaction is aborted, COM+ steps in and ensures that any changes made to the database are rolled back. This is just like what happened when we were controlling th transaction from the ASP page, in the earlier examples of this chapter– when the @TRANSACTION directive is set to REQUIRED and SetAbort is called.

 

So by simply writing transaction-aware components, and then configuring these components to require a transaction, we can take advantage of transaction processing without having to worry about them in our ASP pages.

 

This technique has great advantages in a development shop, where one team is responsible for component building, and another team is responsible for ASP script-writing. The component builders can have all of the transaction knowledge, and build that knowledge into the design and installation of their components. All the ASP developers have to do is write ASP pages that use these components, and all of the transaction handling is transparent to them.

<< 17.2.0- COM+ Components

Chapter17

17.3.0- Summary >>