8 Replies Latest reply on Jul 29, 2009 4:55 PM by dward

    SOAPProxy Enhancements

    dward

      In 4.6, the SOAPProxy class was added, which is an easy mechanism to proxy an external web service via the bus. All that is required is the original wsdl location, whose endpoints get transformed so consumers go through the bus. Further wsdl transformation can be configured via Smooks, and you can also optionally transform the soap envelope before and after the proxying, via the new XsltAction, or via the SmooksAction. Also, for soap-over-http, any of the HttpRouter properties can be set as properties on the SOAPProxy.

      For 4.7, I would like to propose a few enhancements:

      a) Support Basic Auth. This was an oversight on my part, and is documented in this Jira:
      https://jira.jboss.org/jira/browse/JBESB-2759

      b) (a) is the minimal requirement. I'm wondering if we might want to do more with this, maybe introduce the notion of a "runAs"?

      c) HttpRouter property overrides per endpoint address. Currently, any HttpRouter properties can be set as properties on the SOAPProxy, since SOAPProxy (actually HttpSOAPProxyTransport) wraps usage of HttpRouter, setting sensible HttpRouter defaults. A distinct HttpSOAPProxyTransport is created per endpoint address, however any HttpRouter overrides set at the SOAPProxy level are shared for each endpoint address. This is a bad assumption, as what if you wanted different overrides per endpoint address? I propose keeping having the notion of a 3-tier property configuration:

      1. If no HttpRouter properties are set on SOAPProxy, the default HttpRouter properties coded inside HttpSOAPProxyTransport take effect. This is current behavior and would remain.

      2. If HttpRouter properties are set on SOAPProxy, they can override those coded inside HttpSOAPProxyTransport, however across all wsdl-defined endpoint addresses. This supercedes #1. This is also current behavior and would remain.

      3. NEW: Add the ability to override HttpRouter properties per endpoint address, as nested properties. This supercedes #2 and #1. The question is, "What should the property names be / how can they be distinguished?" I thought of a couple options, first being the binding QName:

      <property name="{http://foo/oof}FooBinding">

      second, being the actual soap:address location:
      <property name="http://host1/foo/FooWS">


      I like the second option best, as that is really most about the transport itself, so here's what it would look like:
      <action name="..." class="...SOAPProxy">
       <property name="wsdl" value="...?wsdl"/>
       <!-- per-wsdl (global) HttpRouter overrides are at this level (tier 2) -->
       <property name="method" value="POST"/>
       <property name="http://host1/foo/FooWS">
       <!-- per-endpoint HttpRouter overrides are at this level (tier 3) -->
       <property name="responseType" value="STRING"/>
       </property>
       <property name="http://host2/bar/BarWS">
       <!-- per-endpoint HttpRouter overrides are at this level (tier 3) -->
       <property name="responseType" value="BYTES"/>
       </property>
      </action>

      In code, I would just find all properties starting with "http" to give to the HttpSOAPProxyTransport for it's HttpRouter overrides. In the future (when a JmsSOAPProxyTransport gets added, for example), I might look for properties starting with "jms" for overrides. Or SmtpSOAPProxyTransport...

      Also note the tier 3 elements are still called "property". This is a free-form content section (xsd:any), so this could have been "transport-property" or similar, however I would prefer just "property" for consistency at either tier.

      Thoughts? Opinions? Questions? Concerns?

        • 1. Re: SOAPProxy Enhancements
          dward

          d) Integration with http-provider. http-provider is being re-worked in 4.7:
          http://www.jboss.org/index.html?module=bb&op=viewtopic&t=157057&start=32

          I respect Kev's comment:

          "Kevin.Conner@jboss.com" wrote:
          can we please get the http gateway working first before we go off track and implement other features?

          , however I just want to make sure we don't implement anything that would preclude the following two enhancements, based on a URL that looks something like:
          http://host/context/http/${service.category}/${service.name}


          1. Possibly introduce a new property on SOAPProxy, like:
          <property name="publish" value="true"/>

          , similar to EBWS's ability to auto-publish an endpoint. This way you don't have to define an http-provider or http-listener. The default for this would be false, but if true, it would go with some sensible defaults.

          2. Make sure that wsdl is available via the http-provider for published SOAPProxy endpoints via the "?wsdl" suffix convention:
          http://host/context/http/${service.category}/${service.name}?wsdl

          This could be implemented via a simple servlet/filter that just request-dispatches to the wsdl already exposed via the contract app.

          • 2. Re: SOAPProxy Enhancements
            kconner

             

            "dward" wrote:
            1. Possibly introduce a new property on SOAPProxy, like:
            <property name="publish" value="true"/>

            , similar to EBWS's ability to auto-publish an endpoint. This way you don't have to define an http-provider or http-listener. The default for this would be false, but if true, it would go with some sensible defaults.

            This is definitely out of scope for 4.x.

            Kev

            • 3. Re: SOAPProxy Enhancements
              ammppp

              One customer requirement we've had related to this is to be able to dynamically provide the SoapProxy endpoint. Essentially, this would allow SoapProxy to be used as a load balancer. Here are two specific needs I've seen:

              1.) Client is exposing a web service via the ESB that has 400 internal endpoints that the ESB can route to. Client is storing the endpoints in a registry and each endpoint has an associated "available" flag. Client wants the WS request to come to the ESB and then have the ESB route it (after potential authentication, authorization, transformation, auditing, etc.) to one of the "available" endpoints - where the list of "available" endpoints is not known when the ESB deployment is done (so can't be listed in jboss-esb.xml).

              2.) Client is exposing a web service via the ESB that has 100 internal endpoints that the ESB can route to. Client is using JON, JMX, or some other mechanism to determine average response time of each internal endpoint and wants requests routed to less busy (defined by low response time) endpoints.

              I don't think the implementation of this has to be too complicated - don't think we necessarily need to make SoapProxy a complex load balancer. But, if SoapProxy could accept an endpoint that is passed into it as a parameter on the ESB message, that would allow clients to write a preceding action that used whatever mechanism they desired to determine where that particular message should be routed to by storing the desired endpoint in the ESB message prior to the SoapProxy action being executed.

              • 4. Re: SOAPProxy Enhancements
                ammppp

                One other request related to this area - and I think HttpRouter already supports it (so SoapProxy probably does as well), though I don't think it is documented.

                In some cases, SoapProxy may be used within the ESB action chain for more than just serving as THE internal endpoint for the ESB service.

                For example, consider a case in order for the ESB to transform the incoming client request to the request needed by the endpoint WS, the ESB needs to get additional information from a different auxiliary web service (maybe to get defaults, maybe to check authorization, maybe to check system load, maybe something else). In this case, the client sends request to the ESB, the ESB invokes a check authorization web service or get defaults web service, augments the original client's message and forwards to the internal WS endpoint.

                In this case, it would be nice if the SoapProxy could send a message and store back a response in some ESB location other than the default message body because the default message body is storing the main ESB service message that is going to be augmented.

                One could write some custom actions to move ESB message parameters around before/after invoking the auxiliary web service, but would be nice if the SoapProxy could just specify that message to be sent is coming from a different location than the default message body and the auxillery SoapProxy response could be stored in a different location than the default message body. Probably wouldn't want the HTTP parameters and such to be set on the ESB message default locations either since it's not the "real" service being invoked.

                Hope that makes sense.

                • 5. Re: SOAPProxy Enhancements
                  dward

                   

                  "ammppp" wrote:
                  One other request related to this area - and I think HttpRouter already supports it (so SoapProxy probably does as well), though I don't think it is documented.
                  ...
                  In this case, it would be nice if the SoapProxy could send a message and store back a response in some ESB location other than the default message body because the default message body is storing the main ESB service message that is going to be augmented.
                  ...


                  This is current functionality. SOAPProxy uses SOAPProxyTransports per endpoint, the HttpSOAPProxyTransport wraps HttpRouter (setting sensible defaults - minus Authorization ;) ), and HttpRouter uses MessagePayloadProxy to store the payload in the Message.

                  If you look at MessagePayloadProxy.java, you'll see:
                  public MessagePayloadProxy(ConfigTree config) {
                   AssertArgument.isNotNull(config, "config");
                   setDataLocations(new String[] {config.getAttribute(GET_PAYLOAD_LOCATION, Body.DEFAULT_LOCATION)},
                   new String[] {config.getAttribute(SET_PAYLOAD_LOCATION, Body.DEFAULT_LOCATION)});
                   }


                  those constants are:
                  GET_PAYLOAD_LOCATION = "get-payload-location"
                  SET_PAYLOAD_LOCATION = "set-payload-location"
                  Body.DEFAULT_LOCATION = "org.jboss.soa.esb.message.defaultEntry"


                  So, all you should have to do is specify:
                  <action name="..." class="...SOAPProxy">
                   <property name="get-payload-location" value="..."/>
                   <property name="set-payload-location" value="..."/>
                  </action>


                  Make sense? Some of the actions document these, some don't. I thought this was somewhere more global in the documentation also, though...

                  • 6. Re: SOAPProxy Enhancements
                    dward

                     

                    "ammppp" wrote:
                    One customer requirement we've had related to this is to be able to dynamically provide the SoapProxy endpoint.


                    Kev and I discussed this briefly this morning. It's not on my plate just yet. ;)

                    • 7. Re: SOAPProxy Enhancements
                      kconner

                       

                      "dward" wrote:
                      "ammppp" wrote:
                      One customer requirement we've had related to this is to be able to dynamically provide the SoapProxy endpoint.


                      Kev and I discussed this briefly this morning. It's not on my plate just yet. ;)

                      If these are hard customer requirements then they must come through PM etc so that they can be tracked and prioritised appropriately.

                      At the moment we are trying to nail down some requirements for accessing the endpoint through UDDI, but something like this may also be added. Having said that there are no guarantees that any of this will make it into the next release as it depends on the rest of the workload.

                      Kev

                      • 8. Re: SOAPProxy Enhancements
                        dward

                        FYI: BASIC Auth and/or SSL are now supported by SOAPProxy, and is documented in the javadoc as well as in the Programmer's Guide:
                        http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/docs/ProgrammersGuide.odt

                        I also added a quickstart which demonstrates the functionality: "webservice_proxy_security". It features a simple JBossWS endpoint that is protected by both BASIC Auth + SSL, and a SOAPProxy which fronts it (which one would also consume via BASIC Auth + SSL):
                        http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/samples/quickstarts/webservice_proxy_security/

                        This was committed in svn revision 28581:
                        https://jira.jboss.org/jira/browse/JBESB-2759