Using WS-ReliableMessaging

Solutions are questionable without reliability. If a system is either unavailable or loses requests for processing, the users of that system will eventually demand explanations. For example, if you're buying a book on Amazon and you get through the order process, think you've purchased the book, and then wait weeks for its pending arrival, how many times do you think you'll shop at Amazon again before investigating alternative services?

The situation is even worse if you're booking a trade that could be worth a considerable amount of money and the message to the clearance system gets lost. If you have a trader who just purchased 100,000 shares of Microsoft (MSFT), what happens if that ticket never makes it to the back-office system?

Since the inception of web services, their attraction for loosely coupled platform interoperability has been amazing. Web services represent a neutral technology that no one vendor owns or controls at the expense of both competitors and clients. Vendors can't hold clients to a single platform. However, web services have one significant drawback that we view as critical for the further acceptance of web services in the enterprise. This limitation has held back web services as the enabling glue for tying applications together in a loosely coupled manner. That limitation is reliability.

What is reliability? Well, the analogy of buying a book on Amazon or losing a trade while being handed off between systems certainly sounds familiar. The foundation of web services, for many implementations, has been HTTP. SOAP over HTTP is generally considered the default mechanism for web services. However, HTTP doesn't guarantee reliability when dealing with duplication, ordering, or system outages.

The WS-ReliableMessaging^[] (WS-RM) specification was created to address the needs of reliability for solutions that span applications across heterogeneous platforms. With WS-RM, it is possible to interact across applications in a reliable manner but, to clarify, not with durability.

^[] http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWSSpecStatus

The WS-RM specification addresses reliability from within a session or more specifically a service exchange between a client and a server. What WS-RM provides is a guarantee through delivery assurance that a message sent is received. That leaves the implementation, not the WS-RM specification, to fulfill the delivery assurance or raise a SOAP fault.

The key delivery assurances that can be provided by each WS-RM implementation are as follows:

AtMostOnce

Delivered without duplication but does not deal with lost messages

AtLeastOnce

Delivered once, or more; otherwise, if not delivered, raises a fault

ExactlyOnce

Delivered only once; otherwise fault

InOrder

Delivered in sequence sent; does not address duplication or dropped messages

Durability of the message once it has been sent or system availability is not part of the WS-RM specification or currently available in WCF.^[] A suggestion on how to approach the durability and system availability aspect, which is out of the scope of the WS-RM specification, has been to leverage MSMQ in conjunction with reliable sessions, but that doesn't address the cross-platform issues. However, by using gateway technologies such as Host Integration Server (HIS) or other MSMQ to IBM MQSeries bridges, it is possible. But again, the limitations on the stack from each vendor on each side of the channel come into play. So, unless you have an extensible stack and you're prepared to develop customized bindings on the receiving end, the current shipping limitation is WCF in conjunction with MSMQ.

^[] http://specs.xmlsoap.org/ws/2005/02/rm/

Network availability is addressed by dealing with timeouts on acknowledgments. Inactivity timeout settings, when exceeded without acknowledgment, will result in failure. Therefore, if a session is interrupted by an unreliable network connection, the WCF stack and any WS-RM implementation that supports AtLeastOnce or ExactlyOne will raise a fault.

WS-ReliableMessaging Example

You'll now look at the WsReliableMessaging sample that's part of the Chapter 13 downloadable samples. Using the MTOM sample as a base, we've modified the bindings to indicate that we require reliable sessions on the service interface. Using the WCF Service Configuration Editor (SvcConfigEditor.exe) that's part of the Windows SDK (select Tools WCF SvcConfig Editor in Visual Studio), you can modify the App.config file for the WcfHost application in the sample, as shown in Figure 13-6.

Enabling WS-ReliableMessaging on WcfHost

This configuration translates to the application configuration file shown in Listing 13-13.

Example. WS-ReliableMessaging Enabled via Configuration

<system.serviceModel>
    <services>
      <service name="PracticalWcf.FileService">
        <endpoint
          binding="wsHttpBinding"
          bindingConfiguration="MyBinding"
          contract="PracticalWcf.IFileService" />
      </service>
    </services>
    <bindings>
      <wsHttpBinding>
        <binding
          name="MyBinding"
          messageEncoding="Mtom">
 <reliableSession
							            inactivityTimeout="00:05:00"
							           enabled="true" />
           <security>
            <message
              clientCredentialType="Windows"
              negotiateServiceCredential="true"
              establishSecurityContext="true" />
           </security>
        </binding>
      </wsHttpBinding>
    </bindings>
  </system.serviceModel>

The reliableSession element shown in Listing 13-13 enables WS-ReliableMessaging on all the service interface interactions that leverage WSHttpBinding. Note that the establishSecurityContext attribute is set to true (the default) for the binding. At this time, WCF requires a combination of WS-Security with reliable sessions. If you set the establishSecurityContext attribute to false, when starting the host, you will receive a System.InvalidOperation exception with the message "{"Cannot establish reliable session without secure conversation. Enable secure conversation."}."

Keeping with the WCF core ability to support both a declarative and a programmatic-driven implementation, it is also possible via code to enable reliable sessions, as shown in Listing 13-14.

Example. WS-ReliableMessaging Using Code

WSHttpBinding binding =
    new WSHttpBinding( SecurityMode.Message, true );

 myServiceHost.AddServiceEndpoint(
    typeof( IFileService),
    binding,
    baseAddress);

The code in Listing 13-14 uses the WSHttpBinding constructor override that accepts a SecurityMode value along with a Boolean value that enables reliable sessions on the binding. An alternate override is to specify a configuration name, which allows a mix of a programmatic-driven approach and a configuration-driven approach to development.

If you examine the HTTP traffic for the service exchange, you now see an overall increase (doubling) of the request-reply between the client and server for the same service interface call. What is happening is that with each request, additional acknowledgment messages are indicating success on each message. These additional messages are the delivery assurance mechanism as part of WS-ReliableMessaging. An example of one of these messages is contained in the Capture directory as the file Ack.txt. This message contains the CreateSequenceResponse as a reply to an initial CreateSequence initiation that establishes the reliable session. The full Ethereal capture is present in the file wsrm.log in the Capture directory. You can find full details of the exchange of messages in section 2.4 of the WS-ReliableMessaging specification.^[]

^[] You can find Shy Cohen's blog about demystifying reliable messaging at http://blogs.msdn.com/shycohen/archive/2006/02/20/535717.aspx.

Platform Support of WS-ReliableMessaging

Industry and platform support of WS-ReliableMessaging is a critical aspect of overall web service adoption in the enterprise. Prior to web services, applications were coupled using varied means, with some being file based and many using queued messaging technologies such as MQSeries or Tibco. Most of the time, the coupling was tighter than ideal.

As web services became more prevalent, the desire to connect systems both within an enterprise and outside the firewall has been a critical success factor to the technologies' overall adoption. However, the reliability of the underlying protocol, primarily HTTP, has left it for low-value and low-risk scenarios.

With WS-ReliableMessaging, you now have a means, theoretically, to connect these heterogeneous systems using orthogonal approaches that aren't incompatible "on the wire." Now, when dealing with varied application architects and organizations, you can converse in a language that is consistent across implementations. You can discuss the web service contract and not the details of how you plan to converse. You can publish your metadata on your services or consume the metadata of the partners you need to interact with, all using a common language.

The differences between each implementation, however, are stark at the time of thiswriting. IBM, for example, has indicated only a "statement of direction" in its 6.1 release of WebSphere Application Server,^[] with a target date of "early 2007." JBoss (now part of Red Hat) has not provided any support in its JBossWS 1.0 as of this writing. Also, given JBoss's stated direction away from Axis and that Red Hat has dropped its application server in favor of JBoss, it's not clear what target it has.^[] BEA Systems' WebLogic application server has no publicly announced support or a timeframe for it.

^[] http://specs.xmlsoap.org/ws/2005/02/rm/ws-reliablemessaging.pdf

^[] You can find the IBM WebSphere 6.1 software announcement from April 11, 2006, at http://www-306.ibm.com/common/ssi/rep_ca/6/897/ENUS206-076/ENUS206-076.PDF.

The two most notable implementations are the Sun Tango/WSIT project, previously mentioned, and Axis2. Both teams, along with the WCF teams, are working on platform interoperability tests to ensure that at shipping time (or close to it) there will be viable frameworks that support interoperability with WCF.