ActiveMqWebRequestCreate
ActiveMqWebRequestCreate is a class that is used to create instances of our objects instead of the built-in ones for a particular URI prefix. We'll see how this is used in the client application.

public class ActiveMqQueueWebRequestCreate : IWebRequestCreate
{

This has the same properties that are on the ActiveMqWebRequest so it can set them when it instantiates the requests.

    ...
    public WebRequest Create(System.Uri uri)
    { ActiveMqQueueWebRequest request =
new ActiveMqQueueWebRequest(
uri, _queueAddress, _queueName,
_username, _password);
    return request;
} }

The .NET Client
In the client, we generate web service proxies exactly the same as if they were HTTP, only we don't necessarily have the option to hit a url that generates/serves a wsdl, so we use a file wsdl. We don't have to do anything special with the proxies. In this example, ShippingService is the service, and GetDistance() is its only operation. It accepts a GetDistanceRequest and returns a GetDistanceResponse. Before we call an operation on our service, we register our protocol to use our ActiveMqWebRequestCreate for a custom URI prefix.

Once this protocol is registered, it's available from that point forward within the application domain.

    // Create a dummy URI
    System.Uri urlRequest = new System.Uri(
"activeJms://ftp.momentum.com/activeJmsUri/I/do/not/exist.txt");
    // Register it
    bool isGood = WebRequest.RegisterPrefix("activeJms",
new ActiveMqQueueWebRequest.ActiveMqQueueWebRequestCreate(
"tcp://localhost:61616", "myQueue", "un", "pw"));

We call our services the same way we would if it were HTTP. The only difference is that the URI uses a different prefix.

    ShippingService.ShippingService svc = new ShippingService.ShippingService();
    svc.Url = "activeJms://localhost:61616";
    ShippingService.GetDistanceRequest req = new ShippingService.GetDistanceRequest();
    req.startZipCode = "78728"; req.endZipCode = "50158";

    ShippingService.GetDistanceResponse resp = svc.GetDistance(req);

In this specific implementation, each prefix has a fixed address and queue. Fancier implementations could support extra information in the URI query string similar to the Tibco one mentioned in the URL-based JMS transport section.

.NET Consumer Summary
The components above can be created once, and then leveraged for any number of services. Once the protocol is registered, we don't have to change the way we work with services, and for all the talk of SOAP, we didn't have to see any! There's nothing to prevent us from using both the JMS and HTTP web service implementations in the same application or integration tests.

Conclusion
We made our service consumers talk directly to the MOM layer. No extra hubs are involved, so the SOAP requests reach the middleware as quickly as possible. With appropriate JMS adapters and knowledge, you can easily implement a consumer in almost any language. Most important, we kept untouched the generated stubs and proxies at the consumer and reused the service engine on the server side. So in addition to the highly scalable and reliable, this approach is also fast and easy to implement.