5 Replies Latest reply on Nov 30, 2005 7:34 AM by Thomas Diesler

    Using addressing accross different services


      Making use of the current addressing impl. (org.jboss.ws.addressing.*) accross different services raises several problems:

      - The current binding classes dont seem to be JAXB compatible
      - How should the type mapping be provided?

      Should there be JAXB support for the current artefacts, so that one can use them in custom service implementations? If so, does the developer need to provide the jaxrpc-mapping or is there a way to preregister the mapping globaly, which makes it possible to use addressing transparently?

        • 1. Re: Using addressing accross different services
          Thomas Diesler Master

          I think the developer should work with the JSR-261 API for addressing. What is the background of this question? Can you give a specific use case?

          JAXB compatible in jboss currently has little meaning because we don't have a JAXB implementation yet.

          • 2. Re: Using addressing accross different services

            Well, i think my question was a little bit misleading.
            I did mean JBXB, not JAXB.

            Services, like eventing, do rely on addressing.
            In this case it uses endpoint references within the eventing specific protocol parts.
            In order to implement the eventing soap layer, i need the type binding classes and the jaxrpc mapping.

            The first idea was to reuse the existing addressing classes,
            but then i realized that they cant be (un)marshalled by JBXB.

            Eventing wouldn't be the only implementation that makes uses of addressing protocol parts. So, i was wondering, if we should offer a general addressing impl. that can be used by various services.

            • 3. Re: Using addressing accross different services
              Thomas Diesler Master

              Have a look at

               * A server side handler that reads/writes the addressing properties
               * and puts then into the message context.
               * @author Thomas.Diesler@jboss.org
               * @since 24-Nov-2005
              public class SOAPServerHandler extends GenericHandler

              The idea is that ant endpoint can include this handler in its handler chain and access the javax.xml.ws.addressing.AddressingProperties
              object from the message context.

              The endpoint then works with this JSR-261 object and the same handler marshalls it into SOAP headers again.

              In other words, marshalling/unmarshalling of addressing headers is handled by

              public interface SOAPAddressingProperties extends AddressingProperties
               public void readHeaders(SOAPMessage message) throws AddressingException;
               public void writeHeaders(SOAPMessage message) throws AddressingException;

              • 4. Re: Using addressing accross different services

                Your approach works well, as long as the actual service payload doesn't refer to addressing elements.

                Look at the following example:

                <xs:element name="Subscribe">
                 <xs:element name="EndTo" type="wsa:EndpointReferenceType"
                 minOccurs="0" />
                 <xs:element name="Delivery" type="tns:DeliveryType" />
                 <xs:element name="Expires" type="tns:ExpirationType"
                 minOccurs="0" />
                 <xs:element name="Filter" type="tns:FilterType" minOccurs="0" />
                 <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded" />
                 <!--xs:anyAttribute namespace="##other" processContents="lax" /-->

                Addressing header information can be easily added through the SOAPServerHandler, but in this case a payload element (EndTo) refers to an addressing endpoint reference.

                • 5. Re: Using addressing accross different services
                  Thomas Diesler Master

                  Ok, ideally we would be able to point wstools to a wsdl that contains these type definitions and wstools would generate the corresponding java types + jaxrpc-mapping.xml.

                  If that fails, in which case a jira issue needs to be created for the wstools component, we could try the fallback to wscompile or wsgen.