Windows Communication Foundation provides a unified messaging API that provides the capability to integrate with a number of legacy technologies. This chapter focuses on the Windows Communication Foundation’s capability to integrate with COM+ and non–Windows Communication Foundation MSMQ (Microsoft Message Queuing) applications.

Windows Communication Foundation provides a rich environment for creating distributed applications. If one has a substantial investment in component-based application logic hosted in COM+, one can use the Windows Communication Foundation to extend one’s existing logic rather than having to rewrite it. A common scenario is when one wishes to expose existing COM+ or Enterprise Services business logic through web services.

When an interface on a COM+ component is exposed as a web service, the specification and contract of that service are determined by an automatic mapping to be performed at application initialization time. The conceptual model for this mapping is as follows:

The authentication and authorization requirements of the COM+ application and its components continue to be enforced when used as a web service. If the caller initiates a web service transaction, components marked as transactional enlist within that transaction scope.

The steps that are required to expose a COM+ component’s interface as a web service without modifying the component are as listed here:

The mechanism used to configure COM+ interfaces to be exposed as web services is the COM+ Service Model Configuration command-line tool (ComSvcConfig.exe). This tool will be used in this exercise to expose a COM+ business object.

The calling convention and command-line switches for ComSvcConfig are as shown here:

ComSvcConfig.exe /install | /list | /uninstall [/application:<ApplicationID | 
ApplicationName>] [/contract<ClassID | ProgID | *,InterfaceID | InterfaceName | *>] [/
hosting:<complus | was>] [/webSite:<WebsiteName>] [/webDirectory:<WebDirectoryName>] [/mex]
 [/id] [/nologo] [/verbose] [/help]

Table 11.1 describes the modes that can be used with ComSvcConfig.exe.

Table 11.2 describes the option flags that can be used with ComSvcConfig.exe.

This series of exercises will focus on a scenario in which a school has an application for registering students. The business logic for this application resides within an Enterprise Service component hosted in COM+. The goal is to expose that component as a web service that can be consumed both by the school’s web-based management application and from a Windows Forms-based smart client application.

This exercise involves taking a legacy COM+ component and exposing it as a Windows Communication Foundation service that is consumed in the smart client application. To begin, examine the COM+ component to understand its functionality.

Because this component is being placed within COM+, it contains several attributes. The ApplicationName attribute identifies the name for the COM+ application this class will be installed into. Also note that the interface and the class are attributed with GUIDs, and the class is attributed with a ProgID. Even though this was written in .NET, the component will live in COM+ with the attributes providing the information necessary for consistent Interop registration.

This class provides methods to the user interface for additions, updates, and retrieval of basic student information. For additions and updates, the changes are sent to an MSMQ using the System.Messaging libraries. In this exercise, only the Add method will be invoked.

using System;
using System.Collections.Generic;
using System.Text;
using System.Messaging;
using System.Data;
using System.Data.SqlClient;
using System.EnterpriseServices;
using System.Runtime.InteropServices;


[assembly: ApplicationName("StudentManagement")]
[assembly: ApplicationID("2C9BFEA5-005D-4218-8C69-A03F6B9037BA")]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationAccessControl(false, AccessChecksLevel = AccessChecksLevelOption
.Application)]

namespace WCFHandsOn
{
    [Guid("1C5677EC-8046-4c5b-B361-BA354CFA3DB3")]
    public interface IStudents
    {
        string Add(string FirstName, string LastName, string PhoneNumber);
        bool Update(string ID, string FirstName, string LastName, string PhoneNumber);
        bool Delete(string ID);
        System.Collections.ArrayList GetAll();

    }

    [Guid("E4A5D9FD-3B5F-4598-9E42-EC8D1329EE9D")]
    [ProgId("StudentManagement.Students")]
    public class Students : ServicedComponent, IStudents
    {
        public Students() {}

        string qPath = @"FormatName:DIRECT=OS:w2k3eeprivate$school";
        public string Add(
            string FirstName,
            string LastName,
            string PhoneNumber)
        {
            //For any modifications to the data, we place the
            //request on a queue.

            //First we generate a System.Messaging.Message for the queue.
            try
            {
                string ID = Guid.NewGuid().ToString();
                Student student = new Student(ID, FirstName, LastName, PhoneNumber);
                System.Messaging.Message msg = GenerateAddMessage(student);

                //Now we place it to the queue
                PlaceMessageOnQueue(msg);

                //This is a new student, return the GUID
                return ID;
            }
            catch (Exception e)
            {
                //Debug.WriteLine(e.ToString());
                throw e;
            }
        }

In the next few steps, the IStudents interface is to be exposed from the COM+ application as a web service using the Windows Communication Foundation. That will enable it to be used as a WS-*–compatible service from clients on any platform. To expose this as a Windows Communication Foundation service, the ComSvcConfig utility will be used. To use that utility, one will need to create a virtual directory to house the service:

Now the ComSvcConfig utility can be used:

To test the service, open the service file in your web browser. Navigate to http://localhost/WCFHandsOn_StudentMgmt/Service.svc. If the service is functioning properly, a page is displayed that identifies the location of the WSDL and how to consume the service, as in Figure 11.1.

Figure 11.1. Web page generated from the metadata of the new Windows Communication Foundation service.

Record the address of the WSDL specified in the first box on this screen because it is used in the next part of the exercise.

In addition to exposing COM+ applications as Windows Communication Foundation services, there’s also a need to expose Windows Communication Foundation services to legacy COM applications. Whether it’s a legacy application such as Lotus Notes, a custom application written in Visual Basic 6 or VBScript, there are a number of COM centric scenarios where the ability to call Windows Communication Foundation services from COM clients could prove useful.

In this next exercise, a Windows Communication Foundation service will be exposed via COM and consumed by a VBScript component.

The next exercise will be to create a Windows Communication client for a System.Messaging service. The client application will use the Windows Communication Foundation to send messages to an MSMQ queue. The service uses the facilities of System.Messaging to detect and retrieve the incoming messages. In scenarios like this one, in which the Windows Communication Foundation is used to exchange messages via MSMQ with non-Windows Communication Foundation applications, the Windows Communication Foundation’s MsmqIntegrationBinding is used to transmit the messages.

The client Windows Communication Foundation application has a dummy contract to mimic invoking a service operation, but, in reality, the message is consumed by an MSMQ service. The service contract is IStudent, which defines a one-way service that is suitable for use with queues. An MSMQ message does not have an Action header. It is not possible to map different MSMQ messages to operation contracts automatically. Therefore, there can be only one operation contract. If more than one operation contract is to be defined for the service, the application must provide information as to which header in the MSMQ message (for example, the Label or correlationID) can be used to decide which operation contract to dispatch.

The MSMQ message also does not contain information about which headers are mapped to the different parameters of the operation contract. So, there can be only one parameter in the operation contract. The parameter is of type generic MsmqMessage (MsmqMessage<T>) and contains the underlying MSMQ message. The type T in the generic MsmqMessage (MsmqMessage<T>) class represents the data that is serialized into the MSMQ message body. In this exercise, a Student type is serialized into the MSMQ message body.

In this scenario, a Windows Communication Foundation service will be created that provides the capability to update student records. The first step will be to create a struct that will contain the student information used when adding or updating a record. That step will be followed by the creation of the service and client.

The result will be a Windows Communication client that posts a message to MSMQ that is later received by a non–Windows Communication Foundation application monitoring the queue. That receiving application will process the message in the appropriate way, modifying the student records as needed.

Testing

With the code completed, it is time to test the application.

1. Using Solution Explorer, right-click on the Client project and select Debug, New Instance.

2. Using Solution Explorer, right-click on the Service project and select Debug, New Instance.

The client and server consoles will be displayed. The information entered in the client’s Main method will send a message to the queue using the Windows Communication Foundation, which will be received by the waiting service using MSMQ.

To verify that the message was transferred, check the window of the Service application. The information provided should be displayed as in Figure 11.3.

Figure 11.3. Service output indicating that a student has been added.

Very few enterprises start from scratch; they’ve evolved over time and have multiple legacy systems in place. Leveraging the information and business processes in these legacy applications is of keen interest to the enterprise. This chapter demonstrated how well the Windows Communication Foundation works with two of the most popular types of legacy applications, those that utilize COM+ and MSMQ.