.NET 3.5 interop problem (possibly not bridging the JTA tx w

[gllambi]

Hi! I'm doing some ws-atomic transaction interop tests between WCF (.NET Framework 3.5) and JBoss using JBossTM 4.7 and AS 5.1.

I've developed my own example using Stateless Session Beans, Web Services, XTS, and the txBridge, similar to the bistro sample. The example is working well when I have clients and servers implemented in JEE, but when I try to interop using a .NET client, I'm having some problems.

After looking at each platforms logs files, I think that the ws-at protocol is working ok and the error occurs while binding the WS-AT tx with the JTA tx. Any idea of what I'm doing wrong?

Here's the log of the execution.

Thanks in advance
Guzman

2009-10-02 15:01:17,921 TRACE [org.jboss.jbossts.txbridge.JaxWSTxInboundBridgeHandler] (http-192.168.244.130-8080-1) handleMessage()
2009-10-02 15:01:17,921 TRACE [org.jboss.jbossts.txbridge.JaxWSTxInboundBridgeHandler] (http-192.168.244.130-8080-1) handleInbound()
2009-10-02 15:01:17,937 TRACE [org.jboss.jbossts.txbridge.InboundBridgeManager] (http-192.168.244.130-8080-1) getInboundBridge()
2009-10-02 15:01:17,937 TRACE [org.jboss.jbossts.txbridge.InboundBridgeManager] (http-192.168.244.130-8080-1) createMapping(externalTxId=Unknown)
2009-10-02 15:01:17,953 TRACE [org.jboss.jbossts.txbridge.BridgeDurableParticipant] (http-192.168.244.130-8080-1) BridgeDurableParticipant(TxId=Unknown, Xid=< 131075, 27, 64, 1--3f570b7e:6d9:4ac64db1:69, null null null null >)
2009-10-02 15:01:18,171 ERROR [org.jboss.jbossts.txbridge.JaxWSTxInboundBridgeHandler] (http-192.168.244.130-8080-1) com.arjuna.wst.UnknownTransactionException
2009-10-02 15:01:18,187 TRACE [org.jboss.jbossts.txbridge.JaxWSTxInboundBridgeHandler] (http-192.168.244.130-8080-1) close()

[gllambi]

I've been looking at the code of the InboundBridgeManager of the txBridge for some answers and found that this operation returns null. If this is so, then the transaction is not obtained very well from the .NET client.

String externalTxId = UserTransactionFactory.userTransaction().toString();

Here's the soap message from the .NET client.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
 <s:Header>
 <ActivityId CorrelationId="e9aa94c6-b91b-49dd-b023-63c70aabd083"
 xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">65795ba0-e5bd-4dcd-b124-1739c1b0cf5e</ActivityId>
 <CoordinationContext s:mustUnderstand="1"
 xmlns="http://docs.oasis-open.org/ws-tx/wscoor/2006/06" xmlns:mstx="http://schemas.microsoft.com/ws/2006/02/transactions">
 
 <wscoor:Identifier xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">urn:uuid:3c80ef0b-5430-48ca-b8ce-9c7518f280b5
 </wscoor:Identifier>

 <Expires>57344</Expires>
 <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06
 </CoordinationType>
 <RegistrationService>
 <Address xmlns="http://www.w3.org/2005/08/addressing">https://server-2003/WsatService/Registration/Coordinator11/
 </Address>
 <ReferenceParameters xmlns="http://www.w3.org/2005/08/addressing">
 <mstx:RegisterInfo>
 <mstx:LocalTransactionId>3c80ef0b-5430-48ca-b8ce-9c7518f280b5
 </mstx:LocalTransactionId>
 </mstx:RegisterInfo>
 </ReferenceParameters>
 </RegistrationService>
 <mstx:IsolationLevel>0</mstx:IsolationLevel>
 <mstx:LocalTransactionId>3c80ef0b-5430-48ca-b8ce-9c7518f280b5
 </mstx:LocalTransactionId>
 <PropagationToken xmlns="http://schemas.microsoft.com/ws/2006/02/tx/oletx">AQAA....AA=
 </PropagationToken>
 </CoordinationContext>
 </s:Header>
 <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <extraer xmlns="http://services.lins.fing.edu.uy/">
 <idCuenta xmlns="">1</idCuenta>
 <monto xmlns="">1000</monto>
 </extraer>
 </s:Body>
</s:Envelope>

Any idea of what of what's going wrong? As far as I can say, it seems to me that the txBridge cannot obtain the transaction context from a .NET client, but I don't have enough info to confirm it. Any help is appreciated

Regards
Guzman

[adinn]

Any idea of what of what's going wrong? As far as I can say, it seems to me that the txBridge cannot obtain the transaction context from a .NET client, but I don't have enough info to confirm it. Any help is appreciated

Hi Guzman,

The context looks fins and XTS should be able to use it. The problem is that MS .NET uses the https protocol -- look at the address for the registration coordinator in the context

 <RegistrationService>
 <Address xmlns="http://www.w3.org/2005/08/addressing">https://server-2003/WsatService/Registration/Coordinator11/
 . . .

XTS will happily use https comms but the underlying HTTP comms need to be configured so that secure comms are enabled. So, you need to install certificates in the trust stores on both the .NET host and the AS host. As part of XTS testing I have verified that secure communications works between AS and AS wit a self-signed certificate in th etrust store. I have not personally confirmed that it works when the client is .NET but we have had people report success with https and .NET clients in the past.

If you want to read about how to configure your trust store on the AS side

http://www.jboss.org/community/wiki/SSLSetup

describes creation and installation of a self-signed certificate (and some other use cases). The keystore should be located in the AS server conf directory. A simpler summary of the certfiicate generation process is included in

http://www.jboss.org/community/wiki/GeneratingSelfSignedCertificatewithKeytool.

I don't know whether a self-signed certificate will be ok on the .NET side (you may need to obtain a CA signed certificate) nor how to install the certificate so that .NET employs it. You will have to read up on this in the M$ documentation.

[gllambi]

Hi Adinn! Thanks for the answer and specially the security tip, but the problem occurs before enlisting the jboss participant.

I ran my WS-AT (100%) JEE example and found that the soap messages from the jee client and wcf client are different and it explains why the JaxWSHeaderContextProcessor cannot process well the message.

Here's the JEE client soap message:

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
 <env:Header>
 <wscoor:CoordinationContext
 env:mustUnderstand='1' xmlns:wscoor='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'>
 <wscoor:CoordinationContext xmlns:ns3='http://www.w3.org/2005/08/addressing'>
 <wscoor:Identifier>urn:-3f570b7e:d61:4ad386e0:73</wscoor:Identifier>
 <wscoor:CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06
 </wscoor:CoordinationType>
 <wscoor:RegistrationService>
 <ns3:Address>http://vmxp.localdomain:8080/ws-c11/RegistrationService
 </ns3:Address>
 <ns3:ReferenceParameters>
 <wsarj:InstanceIdentifier
 xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>-3f570b7e:d61:4ad386e0:73</wsarj:InstanceIdentifier>
 </ns3:ReferenceParameters>
 <ns3:Metadata />
 </wscoor:RegistrationService>
 </wscoor:CoordinationContext>
 </wscoor:CoordinationContext>
 </env:Header>
 <env:Body>
 <ns1:depositar xmlns:ns1="http://services.lins.fing.edu.uy/">
 <idCuenta>1</idCuenta>
 <monto>5000.0</monto>
 </ns1:depositar>
 </env:Body>
</env:Envelope>

and here is the wcf soap message for the same call:

<s:Envelope xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'>
 <s:Header>
 <ActivityId CorrelationId='d4deb880-8826-4d4f-ada7-2263a986c551' xmlns='http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics'>6b87302b-6fed-4bb1-84e5-975e3f26730c</ActivityId>
 <CoordinationContext
 s:mustUnderstand='1'
 xmlns='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'
 xmlns:mstx='http://schemas.microsoft.com/ws/2006/02/transactions'>
 <wscoor:Identifier xmlns:wscoor='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'>urn:uuid:f8370ff6-cf9e-425f-b1ab-402e99c3fcab</wscoor:Identifier>
 <Expires>58368</Expires>
 <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType>
 <RegistrationService>
 <Address xmlns='http://www.w3.org/2005/08/addressing'>https://server-2003/WsatService/Registration/Coordinator11/</Address>
 <ReferenceParameters xmlns='http://www.w3.org/2005/08/addressing'>
 <mstx:RegisterInfo>
 <mstx:LocalTransactionId>f8370ff6-cf9e-425f-b1ab-402e99c3fcab</mstx:LocalTransactionId>
 </mstx:RegisterInfo>
 </ReferenceParameters>
 </RegistrationService>
 <mstx:IsolationLevel>0</mstx:IsolationLevel>
 <mstx:LocalTransactionId>f8370ff6-cf9e-425f-b1ab-402e99c3fcab</mstx:LocalTransactionId>
 <PropagationToken xmlns='http://schemas.microsoft.com/ws/2006/02/tx/oletx'>AQAAAAMAAAD2Dzf4ns9fQrGrQC6Zw/yrAAAQAAAAAACIAAAAAMToedzE6Hk0W6xnROSeBS/M+Xk0W6xniOWeBRAwXgXY1qMAzOSeBTk3YWVhMmEwLTU5ODQtNGVjOC04ZWNiLWFlZDdhNzVjYjBmMAAALwALAAAAZM1kzSEAAABTRVJWRVItMjAwMwAYAAAAUwBFAFIAVgBFAFIALQAyADAAMAAzAAAAAQAAAAAAAAAeAAAAdGlwOi8vc2VydmVyLTIwMDMubG9jYWxkb21haW4vAAA=</PropagationToken>
 </CoordinationContext>
 </s:Header>
 <s:Body xmlns:xsd='http://www.w3.org/2001/XMLSchema' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
 <extraer xmlns='http://services.lins.fing.edu.uy/'>
 <idCuenta xmlns=''>1</idCuenta>
 <monto xmlns=''>1000</monto>
 </extraer>
 </s:Body>
</s:Envelope>

If you see both messages, wcf has one CoordinationContext header while jboss has two. This may explain why the JaxWSHeaderContextProcessor cannot get the CoordinationContextType, which actually in the interop scenario is has null values for the identifier and coordinationType attributes. In the JEE scenario this attributes aren't null. Is there a problem in how xts process the message or how wcf creates the message?

Thank you very much for an answer
Regards
Guzman

[adinn]

If you see both messages, wcf has one CoordinationContext header while jboss has two. This may explain why the JaxWSHeaderContextProcessor cannot get the CoordinationContextType, which actually in the interop scenario is has null values for the identifier and coordinationType attributes. In the JEE scenario this attributes aren't null. Is there a problem in how xts process the message or how wcf creates the message?

Hmm, the header in the JBoss message is clearly incorrect. Looking at the outbound SOAPhandler code I think it is serialising the context into a header element rather than into the header itself which is why the wscoor:CoordinationContext elements are nested. I suspect the inbound side has a corresponding error which allows it to work but breaks interoperability. I'll get back to you when I have had a further look.

[adinn]

Hi Guzman,

You are correct that the handler is encoding the context wrongly. This only shows in interop because the handler is consistently wrong at both client end and server end. I have raised JIRA https://jira.jboss.org/jira/browse/JBTM-625 for this issue and have committed the fix into trunk. It will appear in JBossTS release 4.9.0.

The patch is very small (it affects only two methods of a single class) and relatively simple (although it's still a bit of a pig thanks to the way JAXB works) . So, if you want to try it out you can grab the affected file and patch/rebuild your own release. You will need to grab:
http://anonsvn.jboss.org/repos/labs/labs/jbosstm/trunk/XTS/WSTX/classes11/com/arjuna/mw/wst11/common/CoordinationContextHelper.java

[gllambi]

"adinn" wrote:
Hi Guzman,

You are correct that the handler is encoding the context wrongly. This only shows in interop because the handler is consistently wrong at both client end and server end. I have raised JIRA https://jira.jboss.org/jira/browse/JBTM-625 for this issue and have committed the fix into trunk. It will appear in JBossTS release 4.9.0.

The patch is very small (it affects only two methods of a single class) and relatively simple (although it's still a bit of a pig thanks to the way JAXB works) . So, if you want to try it out you can grab the affected file and patch/rebuild your own release. You will need to grab:
http://anonsvn.jboss.org/repos/labs/labs/jbosstm/trunk/XTS/WSTX/classes11/com/arjuna/mw/wst11/common/CoordinationContextHelper.java

Thanks addin!! I'll try it and give you feedback of my results

Regards
Guzman

[gllambi]

Hi Addin!! I continued doing some test with the fixed code and now the msdtc can partially parse the register message. Partially, because the previous error disappeared but another appeared. The msdtc has some problems with the empty metadata tag. The XTS adds this tag but empty so the msdtc cannot treat it well. I modified the xts code to add some dummy metadata and now the msdtc parsed it well. Here's the message:

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
 <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
 <wsa:To>https://server-2003/WsatService/Registration/Coordinator11/</wsa:To>
 <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register</wsa:Action>
 <wsa:MessageID>urn:3dbed0d84e3d4aab:1f4d8ab5:1245e87b217:-7d30</wsa:MessageID>
 <mstx:RegisterInfo wsa:IsReferenceParameter='true' xmlns:mstx='http://schemas.microsoft.com/ws/2006/02/transactions'>
 <mstx:LocalTransactionId xmlns:mstx='http://schemas.microsoft.com/ws/2006/02/transactions'>7ddeba7f-4f87-48d6-b115-af68c83df3b0</mstx:LocalTransactionId>
 </mstx:RegisterInfo>
 </env:Header>
 <env: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://vmxp.localdomain:8443/ws-t11/ParticipantService</ns2:Address>
 <ns2:ReferenceParameters>
 <wsarj:InstanceIdentifier xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>BridgeParticipantAT_-3f570b7e:f14:4ad8b6ce:178</wsarj:InstanceIdentifier>
 </ns2:ReferenceParameters>
 <ns2:Metadata>
 <Metadata wsdlLocation='http://greath.example.com/2004/wsdl/resSvc http://greath.example.com/2004/reservation.wsdl' xmlns='' xmlns:ns3='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'>
 <InterfaceName>ghns:reservationInterface</InterfaceName>
 </Metadata>
 </ns2:Metadata>
 </ParticipantProtocolService>
 </Register>
 </env:Body>
</env:Envelope>

Looking at the ws-addressing xmlSchema (http://www.w3.org/2006/03/addressing/ws-addr.xsd), I found that this tag is optional, it can appear empty. Here's part of the addressing xsd:

<xs:complexType name="EndpointReferenceType" mixed="false">
 <xs:sequence>
 <xs:element name="Address" type="tns:AttributedURIType" />
 <xs:element ref="tns:ReferenceParameters" minOccurs="0" />
 <xs:element ref="tns:Metadata" minOccurs="0" />
 <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
 </xs:sequence>
 <xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>

<xs:element name="Metadata" type="tns:MetadataType" />
<xs:complexType name="MetadataType" mixed="false">
<xs:sequence>
 <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax" />
</xs:complexType>

Although, this seems to be a MSDTC bug because it doesn't respect the addressing schema, maybe you can change the code to not add the metadata tag in case it is empty and achieve a rapidly interoperability.

Besides this, now I'm facing a problem with the register response message. For some strange reason there's an error with the ssl connection. The error message in the exception is: El certificado remoto no es válido según el procedimiento de validación (In english: the remote certificate is not valid according to the validation process). This is strange because the request message was sent correctly using the same certificates. I know that this is MS stuff, but if you got any idea of what's wrong, I would appreciate any tip?

Here's the link to the MS forum with this problem: http://social.msdn.microsoft.com/Forums/en/windowstransactionsprogramming/thread/85d8c005-d76e-4d3d-8d3d-c901d56cbe55?prof=required

Regards
Guzman

[adinn]

The msdtc has some problems with the empty metadata tag. The XTS adds this tag but empty so the msdtc cannot treat it well.

maybe you can change the code to not add the metadata tag in case it is empty and achieve a rapidly interoperability

XTS doesn't explicitly add this tag. The only place where metadata is processed in the XTS code is in conversion of wire format (W3CEndpointReference) endpoints to/from internal endpoints. This is done using class NativeEndpointReference which relies on JAXB to do the marshalling of data. This ought not to add an empty metadata tag but tt may be that JAXB is adding a metadata element to the XML even if the metadata elements list is empty or null.

Apart from this endpoint conversion code, XTS relies on JBossWS to add/process the required metadata for communicating over a secure connection.

Can you explain what code you modified in order to add metadata to your messages?

Besides this, now I'm facing a problem with the register response message. For some strange reason there's an error with the ssl connection. The error message in the exception is: El certificado remoto no es valido segun el procedimiento de validacion. This is strange because the request message was sent correctly using the same certificates.

I am not at all sure about this but I think your last point may be incorrect. The registration request is sent from JBoss to M$ and the registration response is sent from M$ to JBoss. These should be sent over the same connection (JBoss expects registration to be implemented using an RPC message protocol). This ought to mean that the reply does not need validation. However, if M$ is implementing the communication using one way messages validation might be done in each direction using the trust store on the receiving end of the communication. Are you sure you have a certificate in both the M$ and JBoss trust stores which allow the agent on the other side to access the services? You will need this anyway in order for the subsequent 1-way messages (PREPARE, PREPARED, COMMIT, COMMITTED, ROLLBACK, ABORTED) to work.

[gllambi]

"adinn" wrote:

XTS doesn't explicitly add this tag. The only place where metadata is processed in the XTS code is in conversion of wire format (W3CEndpointReference) endpoints to/from internal endpoints. This is done using class NativeEndpointReference which relies on JAXB to do the marshalling of data. This ought not to add an empty metadata tag but tt may be that JAXB is adding a metadata element to the XML even if the metadata elements list is empty or null.

Apart from this endpoint conversion code, XTS relies on JBossWS to add/process the required metadata for communicating over a secure connection.

Can you explain what code you modified in order to add metadata to your messages?

Yes, I used the JBossWS and JAXB to add dummy metadata to test this. I modified the getParticipant method of the TransactionManagerImple class like this:

private W3CEndpointReference getParticipant(final String id, final boolean isSecure)
 {
 final QName serviceName = AtomicTransactionConstants.PARTICIPANT_SERVICE_QNAME;
 final QName endpointName = AtomicTransactionConstants.PARTICIPANT_PORT_QNAME;
 final String address = ServiceRegistry.getRegistry().getServiceURI(AtomicTransactionConstants.PARTICIPANT_SERVICE_NAME, isSecure);
 W3CEndpointReferenceBuilder builder = new W3CEndpointReferenceBuilder();
 builder.serviceName(serviceName);
 builder.endpointName(endpointName);
 builder.address(address);
 InstanceIdentifier.setEndpointInstanceIdentifier(builder, id);

 //Begin Code by Llambi. Metadata interop bug with .NET
 DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
 DocumentBuilder docBuilder;
 try {
 docBuilder = builderFactory.newDocumentBuilder();
 Document document = docBuilder.parse (new InputSource("metadata.xml"));
 Element metadataElement = document.getDocumentElement();
 builder.metadata(metadataElement);
 } catch (ParserConfigurationException e) {
 e.printStackTrace();
 System.out.println("[AppendedCode] Error in the interop metadata code");
 } catch (SAXException e) {
 e.printStackTrace();
 System.out.println("[AppendedCode] Error in the interop metadata code");
 } catch (IOException e) {
 e.printStackTrace();
 System.out.println("[AppendedCode] Error in the interop metadata code");
 }
 //End Code by Llambi
 return builder.build();
 }

It's not a neat code, I know. It was just for testing purpose :)

I am not at all sure about this but I think your last point may be incorrect. The registration request is sent from JBoss to M$ and the registration response is sent from M$ to JBoss. These should be sent over the same connection (JBoss expects registration to be implemented using an RPC message protocol). This ought to mean that the reply does not need validation. However, if M$ is implementing the communication using one way messages validation might be done in each direction using the trust store on the receiving end of the communication. Are you sure you have a certificate in both the M$ and JBoss trust stores which allow the agent on the other side to access the services? You will need this anyway in order for the subsequent 1-way messages (PREPARE, PREPARED, COMMIT, COMMITTED, ROLLBACK, ABORTED) to work.

I have the .NET certificate on the truststore and the JBoss certificate on the MS Truststore. Maybe I'm missing something else.

Regards
Guzman

[gllambi]

Hi Adinn!!! I saw that this fix is only for JBoss Transactions 4.9. Are there plans to add it to version 4.7 that works with JBoss 5.x?

Thanks

Guzman

[adinn]

gllambi wrote:

Hi Adinn!!! I saw that this fix is only for JBoss Transactions 4.9. Are there plans to add it to version 4.7 that works with JBoss 5.x?

Thanks

Guzman

Hi Guzman,

We are not backpatching anything to 4.7 as it is a community only release.

We may backpatch the fix to 4.6.1 (i.e. to our product branch) if a client needs the fix. We try to avoid patching a product release until a client requires it because patches may have unintended consequences and we don't want to inconvenience anyone without a good reason.

So, if you want this fix I suggest you either apply the patch to your 4.7 (just copy the 4.9 version of CoordinationContextHelper into your release and recompile 4.7) or else upgrade to AS 6 and use 4.9.

regards,

Andrew Dinn

[gllambi]

Adinn, thanks for the answer and quickness!

Regards

Guzman