Version 3
Created by ochaloup on Feb 16, 2018 4:37 AM. Last modified by ochaloup on Feb 19, 2018 4:46 PM.

    Analysis

     

    Summary

     

    This feature comes from user demand of integrating Windows MSDTC  WS transaction implementation with WildFly Narayana one. By our knowledge the Narayana implementation follows the WS-AT/WS-Addressing specification while the MSDTC interpretation of the spec is strict and thus it does cause issue of inter-operable communication. This feature provides an extension for Narayana WS-AT and provides opening some special endpoints which can be contacted from .NET in the MSDTC way and thus fixing the interoperability issue.

     

    Background

     

    When the WS-AT (XTS subsystem) is initiated in the Windows side, the Windows client creates a context with the Windows coordinator service and later it calls to the WildFly WS, the process fails at Registration operation.

     

    The WildFly side tries to execute the Registration operation as a client synchronously and windows just responds 202 (no content, no XML is returned) which throws a NullPointerException (NPE). The XML sent in the request is the following:

     

    <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:a632e947aaf3aca5:d586ffa:15edccdf0ca:-8000</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing">https://windows.sample.com/WsatService/Registration/Coordinator11/</To>
    <ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
      <Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
    </ReplyTo>
    <mstx:RegisterInfo xmlns="http://www.w3.org/2005/08/addressing" xmlns:mstx="http://schemas.microsoft.com/ws/2006/02/transactions"
          xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" wsa:IsReferenceParameter="1">
      <mstx:LocalTransactionId>edd12908-c2f4-427a-86d6-4fab6dde3d32</mstx:LocalTransactionId>
    </mstx:RegisterInfo>
  </soap:Header>
  <soap:Body>
    <Register xmlns="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:ns2="http://www.w3.org/2005/08/addressing">
      <ProtocolIdentifier>http://docs.oasis-open.org/ws-tx/wsat/2006/06/Durable2PC</ProtocolIdentifier>
      <ParticipantProtocolService>
        <ns2:Address>https://jboss.sample.com:8443/ws-t11-participant/ParticipantService</ns2:Address>
        <ns2:ReferenceParameters>
          <wsarj:InstanceIdentifier xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj" xmlns:wsa="http://www.w3.org/2005/08/addressing">restaurantServiceAT:f40f5b70-51c3-46f3-99c6-6052df7efa3f</wsarj:InstanceIdentifier>
        </ns2:ReferenceParameters>
        <ns2:Metadata>
          <wsam:ServiceName xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsat="http://docs.oasis-open.org/ws-tx/wsat/2006/06" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" EndpointName="ParticipantPortType">wsat:ParticipantService</wsam:ServiceName>
        </ns2:Metadata>
      </ParticipantProtocolService>
    </Register>
  </soap:Body>
</soap:Envelope>

     

    Windows implementation does not understand the "http://www.w3.org/2005/08/addressing/anonymous" as ReplyTo. MSDTC enforces the request to send a ReplyTo with a valid URL and the Microsoft implementation calls back to that URL with the RegisterResponse type.

     

    The anonymous behavior is covered by the standard. The RFC says that some endpoints cannot be located with a meaningful IRI; this URI (anonymous) is used to allow such endpoints to send and receive messages, the precise meaning of this URI is defined by the binding of Addressing to a specific protocol and/or the context in which the EPR is used. Under HTTP/SOAP it is commonly understood that it means synchronous execution and currently in Narayana the operations of the WS-Coordination, CreateCoordinationContext and Register, are executed synchronously when acting as a client. Windows implementation is an extreme interpretation of the specification that forces any call to be asynchronous (with that idea any partner, even an standalone application needs to have endpoints and be a web server too to interact using the WS-Coordination specification).

     

    Requirements

    Hard requirements

     

    • The WS-AT handling is feature fix for the Narayana codebase.
    • This behaviour should not be enabled by default as it brings a bit different behaviour. A new switch under XTS subsystem is expected.

     

    Goal is to provide the XTS WS endpoint being able to communicate back to the MSDTC during registration and thus fix interoperability issue which currently exists while .NET application wants to communicate with application in the WildFly and use the transaction propagation over WS calls (using WS-AT transactions).

     

    The WildFly XTS subsystem needs to define a new configuration option that manages the registration of the new .NET compatible WS endpoints and making them visible.

    • The configuration option is new xml element <async-registration/> as part of the XTS subsystem.
    • as CLI command it's /subsystem=xts:write-attribute(name=async-registration, value=true); reload

     

    Non-requirements

     

    None

     

    Design Notes

     

    None

     

    General

     

    Tracking Issues

     

     

    Developer Resources

     

    PR to Narayana codebase: https://github.com/jbosstm/narayana/pull/1272

    proposal of WFLY integration changes: [JBTM-2928] async registration wsat dotnet integration by ochaloup · Pull Request #75 · jbosstm/jboss-as · GitHub

     

    WS Addressing specification current: Web Services Addressing 1.0 - Core

    WS Addressing specification previous: Web Services Addressing (WS-Addressing)

     

    Developer Contact

     

    Ricardo Martin Camarero - rmartinc@redhat.com

    Ondra Chaloupka - ochaloup@redhat.com