Web Middleware

The Web middleware layer can be implemented as a collection of ASP or ASP.NET pages on Internet Information Server on Windows 2000 Server. Any Web pages on the benefits Web site used for benefits enrollment or other employee matters should be restricted so that the secure sockets layer (SSL) protocol is enabled to encrypt communications. Directory Security for the folder containing these pages should be set to require "Secure Communications" requiring a server certificate issued by a recognized certificate authority.

The more difficult aspects of the Web middleware layer have to do with using MSMQ for messaging and participating in a coordinated distributed transaction to handle MSMQ sends and database writes. There are several ways to program the Web middleware. One scheme is to package all of the application logic in VBScript on ASP pages. The VBScript code would make calls to the needed Windows and system APIs for handling messaging, transactions, and access to databases. Another approach would be to create COM or COM+ components using Visual C++ to handle the messaging, transactions, and data access and make calls to use these COM or COM+ components from the VBScript code on the ASP pages.

There is the possibility of performances issues with an all ASP solution since the ASP pages are interpreted at runtime. Compared with VBScript, Visual C++ provides greater flexibility and control when dealing with the transactions and messaging APIs. Consequently, the second approach is the one illustrated in this chapter.

One of the requirements for MSMQ in the proposed scenario is that Active Directory be used and that the MSMQ service be installed on the primary domain controller. This is a requirement because of the need for encryption and authentication for MSMQ messages sent and received between processes. MSMQ creates certificates used for encryption and digital signing and stores this information in MSMQ on the domain controller and in Active Directory.

The MSMQ message can be stored in either private or public queues, the distinction being whether the queue is advertised. In this scenario, either one will work. An application must know the name of any private queues so a private queue provides some limited security through obscurity. Real security will be provided by enforcing users (and processes invoked by users) to authenticate for access to the messages in a queue. These authentication issues are handled automatically by configuring properties on a queue when it is created. This requires that IIS and other server processes used be started under a domain user account, not the Local System account on a particular Windows server where the service is hosted. Encryption of messages is handled by setting a property before it is sent. The MSMQ messages also need to be marked as transactional in order to guarantee delivery.

To handle messaging, the MSMQ APIs can be called directly or COM+ queued components can be used. COM+ queued components are built on top of the MSMQ message service, so in either case the MSMQ service must be installed and configured properly and the appropriate MSMQ queues created.

One of the samples installed as part of the Platform Software Development can be used as a starting point for building the COM objects to handle messaging and database access. This sample is located under the samples\netds\messagequeuing\mqtrans folder below where the Platform SDK was installed. The MQTrans sample is a Visual C++ console application that demonstrates how to coordinated transactions that include sending or receiving MSMQ messages and database updates using ODBC. This sample illustrates how to set up a coordinated transaction to handle MSMQ message sends and database updates using the Distributed Transaction Coordinator (DTC).

Previous Next