1 2 Previous Next 18 Replies Latest reply on Mar 8, 2010 9:57 AM by gllambi

    RegisterResponse interop issue with .NET 3.5

    gllambi

      Hi!!! while doing some interop test between .NET 3.5 and jboss using ws-at 1.1 and I'm having some problems during the registration phase. In particular, when JBoss creates the RegisterResponse message.

       

      Here's a register message made by the XTS

       

      <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
       <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
        <wsa:To>http://vmxp.localdomain:8080/ws-c11/RegistrationService</wsa:To>
        <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register</wsa:Action>
        <wsa:MessageID>urn:3dbed0d84e3d4aab:-56340795:1266668751d:-7ca8</wsa:MessageID>
        <wsarj:InstanceIdentifier wsa:IsReferenceParameter='true' xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>-3f570b7e:d22:4b5dcd91:12a</wsarj:InstanceIdentifier>
       </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>http://vmxp.localdomain:8080/ws-t11/ParticipantService</ns2:Address>
          <ns2:ReferenceParameters>
           <wsarj:InstanceIdentifier xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>BridgeParticipantAT_-3f570b7e:d22:4b5dcd91:12d</wsarj:InstanceIdentifier>
          </ns2:ReferenceParameters>
          <ns2:Metadata>
           <Metadata wsdlLocation='https://192.168.244.130:8443/ws-c11/RegistrationService?wsdl' xmlns='' xmlns:ns3='http://docs.oasis-open.org/ws-tx/wscoor/2006/06'>
            <InterfaceName>RegistrationService</InterfaceName>
           </Metadata>
          </ns2:Metadata>
         </ParticipantProtocolService>
        </Register>
       </env:Body>
      </env:Envelope>
      

       

       

      and here's the registerResponse message also made by the XTS:

       

      <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
       <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
        <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegistrationPortType/RegisterOperationResponse</wsa:Action>
        <wsa:RelatesTo>urn:3dbed0d84e3d4aab:-56340795:1266668751d:-7ca8</wsa:RelatesTo>
       </env:Header>
       <env:Body>
        <RegisterResponse xmlns='http://docs.oasis-open.org/ws-tx/wscoor/2006/06' xmlns:ns2='http://www.w3.org/2005/08/addressing'>
         <CoordinatorProtocolService>
          <ns2:Address>http://vmxp.localdomain:8080/ws-t11/CoordinatorService</ns2:Address>
          <ns2:ReferenceParameters>
           <wsarj:InstanceIdentifier xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>D-3f570b7e:d22:4b5dcd91:136</wsarj:InstanceIdentifier>
          </ns2:ReferenceParameters>
          <ns2:Metadata/>
         </CoordinatorProtocolService>
        </RegisterResponse>
       </env:Body>
      </env:Envelope>
      

       

       

      As you can see the WS-Addressing action in the response is http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegistrationPortType/RegisterOperationResponse. Is this action right? as far as I now it's http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse.

       

      I'm having an interop issue and I suppose the reason is this. If someone could answer this, I would appreciatte it a lot

       

      Thanks

      Guzman

        • 1. Re: RegisterResponse interop issue with .NET 3.5
          adinn

          gllambi wrote:

           

          . . . here's the registerResponse message also made by the XTS:

           

          <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
           <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
            <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
            <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegistrationPortType/RegisterOperationResponse</wsa:Action>
            <wsa:RelatesTo>urn:3dbed0d84e3d4aab:-56340795:1266668751d:-7ca8</wsa:RelatesTo>
           </env:Header>
           <env:Body>
              . . .
           </env:Body>
          </env:Envelope>
          

           

           

          As you can see the WS-Addressing action in the response is http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegistrationPortType/RegisterOperationResponse. Is this action right? as far as I now it's http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse.

           

          I'm having an interop issue and I suppose the reason is this. If someone could answer this, I would appreciatte it a lot

           

          Hi Guzman,

           

          Yes that is an illegal action. The spec says:

           

              Request and reply messages MUST include as the [action] property an action URI that consists of the
              wscoor namespace URI concatenated with the "/" character and the element name of the message. For
              example:
                           http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register


          I'm afraid I am not sure exactly where this action is derived from. The XTS code does not explicitly set this action on the response. That is done by the JaxWS code used by the 1.1 XTS. The implementation stub for this service is generated from the WS-C standard WSDL using a wsdl2java tool as follows:

           

              @WebMethod(operationName = "RegisterOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register")
              @WebResult(name = "RegisterResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
              public RegisterResponseType registerOperation(
                  @WebParam(name = "Register", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
                  RegisterType parameters);

           

          It looks like JaxWS is basing the reply action on the operation name rather than on the name in the @WebResult annotation. I'll have to check the JaxWS spec to see if that is what it is supposed to do and, if so, whether youcan override it (e.g. there may be something similar to the action tag for the @WebMethod annotation which ensures that the outgoing message has the correct action). I'd rather not edit the generated code by hand to rename the operation -- I'd prefer to be able to ensure that I can respond to any spec changes with a fully automated process -- but if I have to I will do that to ensure that the correct action is generated.  Could you please raise a JIRA for this issue and I will see try to provide a patch.

           

          What surprises me is that you have not seen the same  problem with the Activation Coordinator exchange. It is also an RPC based on similar generated code:

               @WebMethod(operationName = "CreateCoordinationContextOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext")
              @WebResult(name = "CreateCoordinationContextResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
              public CreateCoordinationContextResponseType createCoordinationContextOperation(
                  @WebParam(name = "CreateCoordinationContext", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
                  CreateCoordinationContextType parameters);

           

          The reply message for the context create should, by analogy with the registerOperation  call, have been supplied with action CreateCoordinationContextOperationResponse.

           

          Interestingly, this error did not give a problem in the interop tests conducted wth IBM. I guess most JaxWS RPC exchanges don't check for any action on the response since it is obvious what it must be a response to.If MS is implementing the RPC exchange as if it were two one way messages then this might explain why it is bothering to look at the action.

          • 2. Re: RegisterResponse interop issue with .NET 3.5
            gllambi

            What surprises me is that you have not seen the same  problem with the Activation Coordinator exchange. It is also an RPC based on similar generated code:

             

            Hi Adinn! As you suggested, the same problem occurs with the ActivationService while creating the coordination context.

             

            Here's the CreateCoordinationContext message:

             

            <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
             <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
              <wsa:To>http://vmxp.localdomain:8080/ws-c11/ActivationService</wsa:To>
              <wsa:Action>createCoordinationContextOperation</wsa:Action>
              <wsa:MessageID>urn:3dbed0d84e3d4aab:-56340795:1266668751d:-7caa</wsa:MessageID>
             </env:Header>
             <env:Body>
              <CreateCoordinationContext xmlns='http://docs.oasis-open.org/ws-tx/wscoor/2006/06' xmlns:ns2='http://www.w3.org/2005/08/addressing'>
               <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType>
              </CreateCoordinationContext>
             </env:Body>
            </env:Envelope>
            

             

            and here's the response:

             

            <env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
             <env:Header xmlns:wsa='http://www.w3.org/2005/08/addressing'>
              <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
              <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/ActivationPortType/CreateCoordinationContextOperationResponse</wsa:Action>
              <wsa:RelatesTo>urn:3dbed0d84e3d4aab:-56340795:1266668751d:-7caa</wsa:RelatesTo>
             </env:Header>
             <env:Body>
              <CreateCoordinationContextResponse xmlns='http://docs.oasis-open.org/ws-tx/wscoor/2006/06' xmlns:ns2='http://www.w3.org/2005/08/addressing'>
               <CoordinationContext>
                <Identifier>urn:-3f570b7e:d22:4b5dcd91:12a</Identifier>
                <CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</CoordinationType>
                <RegistrationService>
                 <ns2:Address>http://vmxp.localdomain:8080/ws-c11/RegistrationService</ns2:Address>
                 <ns2:ReferenceParameters>
                  <wsarj:InstanceIdentifier xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>-3f570b7e:d22:4b5dcd91:12a</wsarj:InstanceIdentifier>
                 </ns2:ReferenceParameters>
                 <ns2:Metadata/>
                </RegistrationService>
               </CoordinationContext>
              </CreateCoordinationContextResponse>
             </env:Body>
            </env:Envelope>
            

             

            As you can see the action in the response message seams to follow the same pattern you described above.Do you know if the spec specifies something about the action message property? I didn't find anything and if it's non maybe you can suggest Mark to add something about to avoid or clarify this scenarios.

             

            Interestingly, this error did not give a problem in the interop tests conducted wth IBM. I guess most JaxWS RPC exchanges don't check for any action on the response since it is obvious what it must be a response to.If MS is implementing the RPC exchange as if it were two one way messages then this might explain why it is bothering to look at the action.

             

            I my scenario the .NET app talks with the MSDTC and JBoss app with the JBossTM so this isn't a problem for me, as the createContextMessage is something internal. Which tests are you talking about? could you please tell me something about them?

             

            As far as my experience with .NET Web Services can tell, they are a bit jealous on how you interoperate with them. If you use WS-Addressing in the request, the response must come with it also. It happens the same with the action message property in the response.

             

            Just to comment, the MEP with the MSDTC is a request-response in one connection. See this for an MS answer http://social.msdn.microsoft.com/Forums/en-CA/windowstransactionsprogramming/thread/91bf5a65-4561-44d5-95b4-a66136dc1658

             

            Here's the JIRA reference. Sorry in advance if I made something wrong about the developers info. I realize late about it. https://jira.jboss.org/jira/browse/JBTM-689

             

            Regards

            Guzman

             

            El mensaje fue editado por: Guzman Llambias. Forgot to add JIRA reference

            • 3. Re: RegisterResponse interop issue with .NET 3.5
              adinn

              Hi Guzman

              gllambi wrote:

              Hi Adinn! As you suggested, the same problem occurs with the ActivationService while creating the coordination context.

               

                  . . .


              As you can see the action in the response message seams to follow the same pattern you described above.Do you know if the spec specifies something about the action message property? I didn't find anything and if it's non maybe you can suggest Mark to add something about to avoid or clarify this scenarios.

               

              That's covered by the text I quoted in my last post

               

                  Request and reply messages MUST include as the [action] property an action URI that consists of the
                  wscoor namespace URI concatenated with the "/" character and the element name of the message. For
                  example:
                               http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register


              So, the create request shoudl have action

               

                  http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext

               

              and the response shoudl have action

               

                  http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse

               

              Once again it  looks like the response has been derived from the operation name. But what is more weird is that the requuest action is also wrong. It looks like it too has been derived from the operation name. This is strange because the generated client specifies the action explicitly as follows:

               

              @WebService(name = "ActivationPortType", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06")
              @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
              @XmlSeeAlso({
                  ObjectFactory.class
              })
              public interface ActivationPortType {


                  /**
                   *
                   * @param parameters
                   * @return
                   *     returns org.oasis_open.docs.ws_tx.wscoor._2006._06.CreateCoordinationContextResponseType
                   */
                  @WebMethod(operationName = "CreateCoordinationContextOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext")
                  @WebResult(name = "CreateCoordinationContextResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
                  public CreateCoordinationContextResponseType createCoordinationContextOperation(
                      @WebParam(name = "CreateCoordinationContext", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
                      CreateCoordinationContextType parameters);

              }

               

              I don't really understand how request shown in your trace message has had its action set to createCoordinationContextOperation.

               

              gllambi wrote:


              I my scenario the .NET app talks with the MSDTC and JBoss app with the JBossTM so this isn't a problem for me, as the createContextMessage is something internal. Which tests are you talking about? could you please tell me something about them?


              Ah, this is probably true in my tests too. I am referring to two sets of interopability tests,. The first test was defined by the OASIS WS-TX committee and was used to gauge interoperability at a vendors workshop some years back. The second has been speced by the Web Services Test Forum. The code for both of our test implementations is in the JBossTS source tree in the interop directory.

               

              The public endpoints used to run the WSTX tests are no longer present but they were available briefly when I was develping the 1.1. implementation. We can still test JBoss against itself using this test. The endpoints for the WSTF tests are not currenlty public because not enough members in the WSTF have implemented the test scenario. However, we have tested JBoss WS-AT against IBM's implementation using these private endpoints.

               

              gllambi wrote:

               

              As far as my experience with .NET Web Services can tell, they are a bit jealous on how you interoperate with them. If you use WS-Addressing in the request, the response must come with it also. It happens the same with the action message property in the response.

               

              Just to comment, the MEP with the MSDTC is a request-response in one connection. See this for an MS answer http://social.msdn.microsoft.com/Forums/en-CA/windowstransactionsprogramming/thread/91bf5a65-4561-44d5-95b4-a66136dc1658

               

              Here's the JIRA reference. Sorry in advance if I made something wrong about the developers info. I realize late about it. https://jira.jboss.org/jira/browse/JBTM-689

               

               

              Not sure I follow what you are saying about using WS-Addressig? WSA headers are very clearly specified for each exchange in the WS-C protocol even when it is a request-reply (RPC style) exchange and provision of most headers is mandatory. Do Microsoft not provide the actions as defined by the bit of the spec I quoted?

               

              Thanks for the JIRA. It is on the to be processed pile :-)

               

              regards,

               

               

              Andrew Dinn

              • 4. Re: RegisterResponse interop issue with .NET 3.5
                gllambi

                Hi Adinn!

                 

                That's covered by the text I quoted in my last post

                 

                Thanks for the comments about the spec, I read it quickly and didn't realize about that.

                 

                 

                I don't really understand how request shown in your trace message has had its action set to createCoordinationContextOperation.

                 

                If you don't know, me it's worse

                 

                Not sure I follow what you are saying about using WS-Addressig? WSA headers are very clearly specified for each exchange in the WS-C protocol even when it is a request-reply (RPC style) exchange and provision of most headers is mandatory. Do Microsoft not provide the actions as defined by the bit of the spec I quoted?

                 

                Isn't too important... Just saying that if you use Addressing on MS, it is very strict with request-response attributes in the message and sometimes a bit extreme. It provides the spec actions.

                 

                Talking about the issue, I'll wait till appears the patch. If you get fixed soon, could you please let me know?

                 

                Thanks for all!

                 

                Regards

                Guzman

                • 5. Re: RegisterResponse interop issue with .NET 3.5
                  gllambi

                  Hi Adinn! How are you? I saw that you fixed this issue. Could you please tell me what should I do in order to use it with JBossTS 4.7.0 and see if works now?

                   

                  https://jira.jboss.org/jira/browse/JBTM-689

                   

                  Regards

                  Guzman

                  • 6. Re: RegisterResponse interop issue with .NET 3.5
                    adinn

                    Hi Guzman,

                     

                    You should be able to apply the 4.9 fixes to 4.7 and rebuild your XTS without any problem. If you click on the fisheye tab in the JIRA youcan see what needs modifying (3 simple one-liners if you discount the importstatements).

                     

                    The important fix is to add an @Action annotation to ActivationPortTypeImpl and RegistrationPortTypeImpl setting the output property to the action you want for the response message.

                     

                    You probably also ought to update configureRequestContext(Map<String, Object>, MAP,  String, String) in class AddressingHelper so that it calls map.setAction(action). This fixes the problem with the wrong client action on the  createCoordinationContext request. I know this did not cause you anty problem because you initiate the TX from the M$ side. However, it needs to be fixed if you want to initiate the TX from the JBoss side using a M$ coordinator.

                     

                    Good luck and let me know if you get interop with M$ working.

                     

                    regards,

                     

                     

                    Andrew Dinn

                    • 7. Re: RegisterResponse interop issue with .NET 3.5
                      gllambi

                      Thanks for the info and the quick answer! Unfortunatelly, I'm having some problems with the compilation scripts. It doesn't recognize the org.jboss.wsf.common.addressing.*. Do I have to add a library to build path?

                       

                      Regards

                      Guzman

                       

                      Here's the error:

                       

                      dev-compile11:
                          [javac] Compiling 60 source files to C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_
                      7_0_GA\XTS\WS-C\build\dev\classes11\classes
                          [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                      \arjuna\webservices11\wsaddr\AddressingHelper.java:11: package org.jboss.wsf.com
                      mon.addressing does not exist
                          [javac] import org.jboss.wsf.common.addressing.*;
                          [javac] ^
                          [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                      \arjuna\webservices11\wsaddr\AddressingHelper.java:23: cannot find symbol
                          [javac] symbol  : class MAP
                          [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                          [javac]     public static MAP createOneWayResponseContext(final MAP map, fin
                      al String messageID)
                          [javac]                                                         ^
                          [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                      \arjuna\webservices11\wsaddr\AddressingHelper.java:23: cannot find symbol
                          [javac] symbol  : class MAP
                          [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                          [javac]     public static MAP createOneWayResponseContext(final MAP map, fin
                      al String messageID)
                      
                      • 8. Re: RegisterResponse interop issue with .NET 3.5
                        adinn

                        Hi Guzman,

                         

                        Sory, I forgot that the MAP classes in 4.7 are still in the XTS code. By 4.9 where I did the fix they were migrated into the JBossWS implementation. In file AddressingHelper ou need to import the folowing package

                         

                        org.jboss.jbossts.xts.wsaddr.map.*

                         

                        This ought to fix the problem you are seeing.

                         

                        regards,

                         

                         

                        Andrew Dinn

                        • 9. Re: RegisterResponse interop issue with .NET 3.5
                          gllambi

                          Hi Andrew,

                           

                          That worked fine and I had to change also other clases like ActivationPortTypeImpl and RegistrationPortTypeImpl, although I still have trouble to compile it. It seems that the class MAPBuilderFactory is missing. I search the org.jboss.jbossts.xts.wsaddr.map.* package for this class and didn't find it. I found MAPBuilder but not MAPBuilderFactory. Do I have to add another class?

                           

                          Regards

                          Guzman

                           

                          Here's the error message:

                           

                          dev-compile11:
                              [javac] Compiling 60 source files to C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_
                          7_0_GA\XTS\WS-C\build\dev\classes11\classes
                              [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                          \arjuna\webservices11\wsaddr\AddressingHelper.java:27: cannot find symbol
                              [javac] symbol  : variable MAPBuilderFactory
                              [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                              [javac]         MAPBuilder builder = MAPBuilderFactory.getInstance().getBuil
                          derInstance();
                              [javac]                              ^
                              [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                          \arjuna\webservices11\wsaddr\AddressingHelper.java:62: cannot find symbol
                              [javac] symbol  : variable MAPBuilderFactory
                              [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                              [javac]         MAPBuilder builder = MAPBuilderFactory.getInstance().getBuil
                          derInstance();
                              [javac]                              ^
                              [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                          \arjuna\webservices11\wsaddr\AddressingHelper.java:92: cannot find symbol
                              [javac] symbol  : variable MAPBuilderFactory
                              [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                              [javac]         MAPBuilder builder = MAPBuilderFactory.getInstance().getBuil
                          derInstance();
                              [javac]                              ^
                              [javac] C:\jbossts-full-4.7.0.GA-src\JBOSSTS_4_7_0_GA\XTS\WS-C\dev\src11\com
                          \arjuna\webservices11\wsaddr\AddressingHelper.java:132: cannot find symbol
                              [javac] symbol  : variable MAPBuilderFactory
                              [javac] location: class com.arjuna.webservices11.wsaddr.AddressingHelper
                          
                          • 10. Re: RegisterResponse interop issue with .NET 3.5
                            adinn

                            Hi Guzman,

                             

                            It would be easier if you took the original 4.7 code and applied the same changes ot it as I did to the 4.9 code.t rather than trying to insert the 4.9 files into your build. The changes you need to make are trivial. Here is are the diffs form fisheye:

                             

                            AddressingHelper.java

                            332  332 public static void configureRequestContext(Map<String, Object> requestContext, MAP map, String to, String action)

                            333  333  {

                            334  334      configureRequestContext(requestContext, map);

                                 335+     map.setAction(action);

                            335  336      configureRequestContext(requestContext, to, action);

                            336  337  }

                             

                            ActivationPortTypeImpl.java

                             

                            13  13  import javax.xml.ws.WebServiceContext;
                                14+ import javax.xml.ws.Action;
                            14  15  import javax.xml.ws.handler.MessageContext;

                                . . .
                            39  40  @WebMethod(operationName = "CreateCoordinationContextOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext")
                            40  41  @WebResult(name = "CreateCoordinationContextResponse", targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters")
                                42+ @Action(input="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContext", output="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/CreateCoordinationContextResponse")
                            41  43  public CreateCoordinationContextResponseType createCoordinationContextOperation(


                            RegistrationPortTypeImpl.java

                             

                            9   9  import javax.jws.soap.SOAPBinding;

                                10+ import javax.xml.ws.Action;

                            10  11  import javax.xml.ws.handler.MessageContext;

                                . . .

                            42  43  @WebResult(targetNamespace = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06", partName = "parameters", name = "RegisterResponse")

                            43  44  @WebMethod(operationName = "RegisterOperation", action = "http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register")

                                45+  @Action(input="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register", output="http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse")

                            44  46  public org.oasis_open.docs.ws_tx.wscoor._2006._06.RegisterResponseType registerOperation(

                             

                            So, you just need to add a call to map.setAction(action) in the first fiile. In the second and third files you need to import class Action and annotate the web methods with @Action using the correct input and output properties.

                             

                            regards,

                             

                             

                            Andrew Dinn

                            • 11. Re: RegisterResponse interop issue with .NET 3.5
                              gllambi

                              Hi Andrew!! Good news!!! I could interoperate with .NET!!!

                               

                              The scenario is:

                                   1) Java client begins ws-at transaction

                                   2) Java client call Java Service

                                   3) Java client call .NET Service

                                   4) Java client commits transaction

                               

                              patches:

                                   - AddressingHelper.java

                                   - ActivationPortTypeImpl.java

                                   - CoordinationContextHelper.java

                                   - RegistrationPortTypeImpl.java

                               

                              Environment:

                                   - JDK 5

                                   - JBoss 5.1

                                   - JBossTS 4.7

                               

                              The rollback also worked!

                               

                              One thing I must say is that I had to make some further work besides the patches you sent me.

                               

                              Modifications:

                              1) .NET requires SSL comunications: I need to change manually the Web Service call so that the Address property to use ssl and remove the metadata tag. We talked about this previously in http://community.jboss.org/thread/145652

                               

                              Here's the correct soap header of the .NET Web Service call:

                               

                               <env:Header>
                                 <wscoor:CoordinationContext 
                              env:mustUnderstand="1" xmlns:ns3="http://www.w3.org/2005/08/addressing" xmlns:wscoor="http://docs.oasis-open.org/ws-tx/wscoor/2006/06">
                                   <wscoor:Identifier>urn:-3f570b7e:8e5:4b853492:b7</wscoor:Identifier> 
                              
                                   <wscoor:CoordinationType>http://docs.oasis-open.org/ws-tx/wsat/2006/06</wscoor:CoordinationType> 
                              
                                   <wscoor:RegistrationService>
                                      <ns3:Address>https://vmxp.localdomain:8443/ws-c11/RegistrationService</ns3:Address> 
                              
                              
                                      <ns3:ReferenceParameters>
                                          <wsarj:InstanceIdentifier 
                              xmlns:wsarj="http://schemas.arjuna.com/ws/2005/10/wsarj">-3f570b7e:8e5:4b853492:b7</wsarj:InstanceIdentifier> 
                              
                                      </ns3:ReferenceParameters>
                              
                              
                                   </wscoor:RegistrationService>
                              
                              
                                </wscoor:CoordinationContext>
                              
                              
                              </env:Header>
                              
                              
                              

                               

                              2) .NET doesn't understand an empty metadata property of WS-Addressing: I have to remove it manually in the Web Service call and in the RegisterResponse message.

                               

                              Here's the correct 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/7cdc7902-d26c-40b1-bbec-813e1575f0da</wsa:To>
                                <wsa:Action>http://docs.oasis-open.org/ws-tx/wscoor/2006/06/RegisterResponse</wsa:Action>
                                <wsa:RelatesTo>urn:uuid:2c722607-43bd-498c-95fb-46cefa76037e</wsa:RelatesTo>
                                <ChannelInstance wsa:IsReferenceParameter='true' xmlns='http://schemas.microsoft.com/ws/2005/02/duplex'>2</ChannelInstance>
                               </env:Header>
                               <env:Body>
                                <RegisterResponse xmlns='http://docs.oasis-open.org/ws-tx/wscoor/2006/06' xmlns:ns2='http://www.w3.org/2005/08/addressing'>
                                 <CoordinatorProtocolService>
                                  <ns2:Address>https://vmxp.localdomain:8443/ws-t11/CoordinatorService</ns2:Address>
                                  <ns2:ReferenceParameters>
                                   <wsarj:InstanceIdentifier xmlns:wsarj='http://schemas.arjuna.com/ws/2005/10/wsarj'>D-3f570b7e:8e5:4b853492:108</wsarj:InstanceIdentifier>
                                  </ns2:ReferenceParameters>
                                 </CoordinatorProtocolService>
                                </RegisterResponse>
                               </env:Body>
                              </env:Envelope>
                              

                               

                              Is there any chance that the JBossTS team could do something about them?

                               

                              Regards

                              Guzman

                               

                              El mensaje fue editado por: Guzman Llambias

                              • 12. Re: RegisterResponse interop issue with .NET 3.5
                                adinn

                                Hi Guzman,

                                 

                                Congratulations on getting as far as you have! Also,  thank you for reporting your progress and your bugs.

                                 

                                gllambi wrote:

                                 

                                The scenario is:

                                     1) Java client begins ws-at transaction

                                     2) Java client call Java Service

                                     3) Java client call .NET Service

                                     4) Java client commits transaction

                                 

                                I assume by Java client and Java client you mean a service and client running on JBoss. That is great. Do you plan to try other scenarios such as using a .NET client or .NET coordinator wiht JBoss services?

                                 

                                gllambi wrote:

                                Modifications:

                                1) .NET requires SSL comunications: I need to change manually the Web Service call so that the Address property to use ssl and remove the metadata tag. We talked about this previously in http://community.jboss.org/thread/145652

                                 

                                 

                                I am not sure I undertsand what your problem is. Is it that you want the context to contain a Registration service URL using the https scheme?

                                 

                                If so then you can achieve this by using https for the coordinator URL If the initial createContext request to the ActivationCoordinator is made using an https connection then all subsequent connections used by the XTS services for that transaction will also use https. One way to do this is to start JBoss AS with the folloiwng property defined on the JVM command line

                                 

                                -Dorg.jboss.jbossts.xts.coordinator.scheme=https

                                 

                                The coordinator will then be contacted using https and port 8443. So insert this command line option into JAVA_OPTS before calling run.sh or run.bat.


                                JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.jbossts.xts.coordinator.scheme=https"

                                 

                                Thread 145652 also refers to the problem with the CoordinationContext header being embedded twice. That has been fixed in 4.9 so it is already in later versions of the AS.


                                gllambi wrote:

                                 

                                2) .NET doesn't understand an empty metadata property of WS-Addressing: I have to remove it manually in the Web Service call and in the RegisterResponse message.

                                 

                                Can this be fixed by the JBossTS team? No.

                                 

                                By the JBossWS team? Maybe.

                                 

                                The problem is happening when JAXB is used to marshall a W3CEndpointReference into the SOAP message. It is using a plain old JAXB marshaller. When the marshaller sees a metadata field containing no metadata elements in the W3CEndpointReference it writes it into the SOAP meaaage as <ns:Metadata/>. This is, of course, perfectly valid XML. I don't know enough about JAXB to know if it is possible to inhibit writing of empty fields or to provide special case handling for this specific field. If it is then it woudl be possibel to patchthe WS code patched so that it created a JAXBContext which wrte nothing for empty Metadata lists. I'll ask Alessio (the WS lead) if this is possible but I wouldn't expect a quick fix (so, expect to have to keep applying your work around). This is really a M$ problem which they ought to fix.

                                • 13. Re: RegisterResponse interop issue with .NET 3.5
                                  gllambi

                                  Thanks Andrew! It was a very thought work but finally and luckily it worked out at last.

                                   

                                  I assume by Java client and Java client you mean a service and client running on JBoss. That is great. Do you plan to try other scenarios such as using a .NET client or .NET coordinator wiht JBoss services?

                                   

                                  Yes, you assume right. The client is a jsp page on JBoss and the service is a JBossWS Service using the txBridge component.

                                   

                                  I've been trying the .NET client and .NET coordinator but I get stucked with an internal error at MS without help and no $ for support, so that will have to wait for now. This result is quite well enough for us now

                                   

                                  I am not sure I undertsand what your problem is. Is it that you want the context to contain a Registration service URL using the https scheme?

                                   

                                  Yes, is exactly that. I'll give it a try.

                                   

                                  Thread 145652 also refers to the problem with the CoordinationContext header being embedded twice. That has been fixed in 4.9 so it is already in later versions of the AS.

                                   

                                  Yes, it was me that had problem. I put it just for completeness so everybody can know what you have to do in order to use it with version 4.7

                                   

                                  By the JBossWS team? Maybe.

                                   

                                  The problem is happening when JAXB is used to marshall a W3CEndpointReference into the SOAP message. It is using a plain old JAXB marshaller. When the marshaller sees a metadata field containing no metadata elements in the W3CEndpointReference it writes it into the SOAP meaaage as <ns:Metadata/>. This is, of course, perfectly valid XML. I don't know enough about JAXB to know if it is possible to inhibit writing of empty fields or to provide special case handling for this specific field. If it is then it woudl be possibel to patchthe WS code patched so that it created a JAXBContext which wrte nothing for empty Metadata lists. I'll ask Alessio (the WS lead) if this is possible but I wouldn't expect a quick fix (so, expect to have to keep applying your work around). This is really a M$ problem which they ought to fix.

                                   

                                  I know, but I post the problem some days before without answer and I though maybe you could "push" this issue a little bit I know that it's an MS bug but maybe if it doesn't take much time to change it, I would appreciate it and be very please if they could do so. Here's the post I wrote:

                                   

                                  http://community.jboss.org/message/528192#528192

                                   

                                  Thanks for all again! You where very helpfull with this hoooole issue

                                   

                                  Regards

                                  Guzman

                                  • 14. Re: RegisterResponse interop issue with .NET 3.5
                                    adinn

                                    Hi Guzman,

                                     

                                    It looks like Christmas has arrived a little early for you :-) JBWS-2942

                                     

                                    regards,

                                     

                                     

                                    Andrew Dinn

                                    1 2 Previous Next