8 Replies Latest reply on May 22, 2008 4:54 AM by jim.ma

    Support  marshaling or unmarshaling the soap  message using

    jim.ma

      This feature will help use make publishing the esb services as web services more easily .

      Publishing esb services as web services can be achieved through two steps:

      1. publish contract info for the esb service .

      2. convert the request soap message to a esb aware message and deliver it ActionPipeLineProcess to process, finally convert the response esb message to soap message and send back .

      For 1 step , we can use pojo classes to give the in/out and fault information for the esb service, for example

      <actions inClass="com.foo.Request" outClass="com.foo.Response", faultClass="com.foo.Fault" jaxbAnnoIntro="anno.xml">
      </actons>


      Use JAXB and JAXB Annotaion Introduction , we can generate the schema files from these classes defined in actions attributes. Use these schema and esb service name and category information , wsdl contract can be constructed.

      For 2 step: Use the JAXB and JAXB Annotation Introduction , we also can easily
      unmarshal the soap message as a request object and put it in Esb message payload to run the ActionPipeLineProcessor.

      Does XStream can do this also ?

      Appreciated your thoughts and comments .









        • 1. Re: Support  marshaling or unmarshaling the soap  message us
          jeffdelong

          For 1) can you describe what the rest of the configuration would look like, i.e. the provider and listener? What would com.foo.Request and com.foo.Response look like?

          For 2) what would be supported from the SOAP Header, e.g. ws-security or ws-transaction information?

          • 2. Re: Support  marshaling or unmarshaling the soap  message us
            jim.ma

             

            "jeffdelong" wrote:
            For 1) can you describe what the rest of the configuration would look like, i.e. the provider and listener? What would com.foo.Request and com.foo.Response look like?

            When publish a ESB service to Web service , we can just simply keep the provider and listener as is and add the inClass/outClass and faultClass attribute to
            Actions element , for example this is the configuration for publish helloworld esb service:
            <?xml version = "1.0" encoding = "UTF-8"?>
            <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd" parameterReloadSecs="5">
            
             <providers>
             <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
             <jms-bus busid="quickstartGwChannel">
             <jms-message-filter
             dest-type="QUEUE"
             dest-name="queue/quickstart_helloworld_Request_gw"
             />
             </jms-bus>
             <jms-bus busid="quickstartEsbChannel">
             <jms-message-filter
             dest-type="QUEUE"
             dest-name="queue/quickstart_helloworld_Request_esb"
             />
             </jms-bus>
            
             </jms-provider>
             </providers>
            
             <services>
             <service
             category="FirstServiceESB"
             name="SimpleListener"
             description="Hello World">
             <listeners>
             <jms-listener name="JMS-Gateway"
             busidref="quickstartGwChannel"
             maxThreads="1"
             is-gateway="true"
             />
             <jms-listener name="helloWorld"
             busidref="quickstartEsbChannel"
             maxThreads="1"
             />
             </listeners>
             <actions inClass="com.foo.Request" outClass="com.foo.Response">
             <action name="action1"
             class="org.jboss.soa.esb.samples.quickstart.helloworld.MyJMSListenerAction"
             process="displayMessage"
             />
             <action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
             <property name="printfull" value="true"/>
             </action>
             <!-- The next action is for Continuous Integration testing -->
             <action name="testStore" class="org.jboss.soa.esb.actions.TestMessageStore"/>
             </actions>
             </service>
             </services>
            
            </jbossesb>


            com.foo.Request and com.foo.Response can be like this :

            public class Request implements Serializable {
             public String msg ;
            }
            
            public class Response implements Serializable {
             public String msg;
            }


            If the "inClass" attribute is defined , Request and Response class will be used to generate schema and generate wsdl during the service starts up . Other artifacts will also be generated , for example endpoint
            implementation class used to publish web service to jbossws stack .

            "jeffdelong" wrote:

            For 2) what would be supported from the SOAP Header, e.g. ws-security or ws-transaction information?

            We can support them. And the extra effort we need to do is writing our own processor or translator to convert the soap header to our esb message header format.


            • 3. Re: Support  marshaling or unmarshaling the soap  message us
              tfennelly

              Stefano Maestri has done some interesting stuff re a new SOAPClient using WISE. If Jim and Stefano haven't already talked about possible cross-overs, then it might be a good idea for them to get in touch. It would probably be good to have consistency between both sides of this WS equation.

              Maybe Stefano could contribute his comments here?

              • 4. Re: Support  marshaling or unmarshaling the soap  message us
                marklittle

                Stefano is usually on the ESB IRC as well.

                • 5. Re: Support  marshaling or unmarshaling the soap  message us
                  maeste

                  Hi,
                  I'm really very very busy in these days and I would give contributions only after I would have a chance to put seriously my mind on the problem (and maybe wrote some proof of concept code with wise).
                  Just give me some days

                  • 6. Re: Support  marshaling or unmarshaling the soap  message us
                    tfennelly

                     

                    "maeste" wrote:
                    Hi,
                    I'm really very very busy in these days and I would give contributions only after I would have a chance to put seriously my mind on the problem (and maybe wrote some proof of concept code with wise).
                    Just give me some days


                    Stefano... just in case we're getting our wires crossed... we were just wondering if you had any comments re the work that Jim's been doing and how it might compare with what you've been doing on the other side of the equation with WISE i.e. WS invocation. We didn't want you to investigate anything more than you've already done. Maybe I'm misreading you :-)

                    • 7. Re: Support  marshaling or unmarshaling the soap  message us
                      maeste

                       

                      "tfennelly" wrote:

                      Stefano... just in case we're getting our wires crossed... we were just wondering if you had any comments re the work that Jim's been doing and how it might compare with what you've been doing on the other side of the equation with WISE i.e. WS invocation. We didn't want you to investigate anything more than you've already done. Maybe I'm misreading you :-)

                      Well, the Jim's works is very similar, on the other side, to what wise do. What I meant is that is so similar that I would like to understand what can be done inside wise.
                      Anyway, it seems good the general idea to expose messages as ws. My doubts is about how the configuration can become pain if you would expose objects more and more complex than a class containing a string.
                      The other question is: are you thinking only at a marshal/unmarshal feature, or are you planning also some logical mappings between what is exposed as ws and internal data?
                      It's jut my 2c about, even if I'd like to investigate this idea a little more to give some more precise ideas about.

                      • 8. Re: Support  marshaling or unmarshaling the soap  message us
                        jim.ma

                         

                        "maeste" wrote:
                        My doubts is about how the configuration can become pain if you would expose objects more and more complex than a class containing a string.

                        Yes. That's correct. We need to add some complex annotation configuration file(jaxb annotation introduction) for a complex type. If jbossws native only supports the jaxb databinding , that's the only option.
                        I will look at the jbossws native and find out if it has its own databinding to handle the pojo class(class without annotation).
                        "maeste" wrote:

                        The other question is: are you thinking only at a marshal/unmarshal feature, or are you planning also some logical mappings between what is exposed as ws and internal data?

                        Are you asking if I plan use OGNL framework or something to map the soap message to internal ESB message and payload conversion ? If the marshal/unmarshal feature can handle all the cases, I'd prefer to add marshal/unmarshal feature. It's straightforward. What do you think?