Archives

Archives / 2006 / January
  • WS-Polling implementation for WSE

    I used some of free time last week to write a prototype of WS-Polling for WSE 3.0.
    Unfortunately, I couldn't finish the complete specification but it is enough to execute web services asynchronously.
    If you haven't read anything about WS-Polling before, it is basically a specification to execute web services asynchronously and poll to the server later in order to get the response.
    If you take a look to this specification, you probably will able to see three main parts:

    1. A mechanism to execute web services and store the response for later retrieval
    2. Some headers to query information about the status of an execution
    3. A mailbox implementation

    For the moment, I only implemented the first part and I'm trying to finish the second one.

    Implementation structure

    The diagram below illustrates the classes used by this implementation.



    I defined a abstract class PollingService that declares a method to get messages. This class also uses an IMessageStore provider to store and retrieve the request and response messages for the concrete service.
    The concrete service is a normal service that implements different business methods and inherits from the base class PollingService. e.g. MyHelloWorldService
    The IMessageStore is an interface that declares methods to store and retrieve messages from an specific store such as Database, MSMQ or a file.
    PollingClient and ConcreteProxy are both proxies to invoke methods in the Concrete service, but the last one was created by the tool WSEWsdl3.exe and it doesn't know how to invoke the service asynchronously.
    I had to develop a custom PollingClient since the proxy created with WSEWsdl3.exe does not offer the following features:

    1. Access to the WS-Addressing headers. For this implementation, the client must change the wsa:ReplyTo header and get access to others headers
    such as wsa:MessageID and wsa:To.
    2. Make a one-way call. The proxy created by the tool waits for an answer from the service in most of the cases.