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.
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 "
ReplyTo. MSDTC enforces the request to send a
ReplyTo with a valid URL and the Microsoft implementation calls back to that URL with 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).
- 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
- [JBTM-2928] Provide WS-AT Integration with .NET
- [WFLY-9818] XTS integration of Narayana fixes for providing WS-AT Integration with .NET
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)
Ricardo Martin Camarero - firstname.lastname@example.org
Ondra Chaloupka - email@example.com