1 2 Previous Next 15 Replies Latest reply: Aug 8, 2012 8:07 AM by Keith Babo RSS

Implementation recommendation for service using 3rd party SOAP service

Michael Daleiden Newbie

This post is related to another post I made in the forum (https://community.jboss.org/thread/203243), and I am struggling to understand how to implement the following service model:

 

We integrate with several third party SOAP-based web services that are hosted on the third party systems (not local). What we are trying to do is create a SY service that exposes a RESTEasy interface to our clients and routes the request to the third party web services. From what I have read on the forums and in the documentation, it should be possible to create a WSDL-based reference to a given third-party external SOAP service and not have to generate any Java client stubs for invoking the SOAP services. However, I cannot seem to fathom how that would be executed through the JBDS tooling and/or annotations. Also, per the referenced forum post, we need to be able to weave in some custom SOAP header elements for authentication with the third party web service and while I understand the concept behind using the SOAPContextMapper, it's difficult for me to wrap my brain around how to stitch it all together to form the required solution.

 

Can someone provide me with guidance on how to approach this?

 

Thanks.

  • 1. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

    Hey Michael,

     

    Let's walk through each bit separately for clarity:

    What we are trying to do is create a SY service that exposes a RESTEasy interface to our clients and routes the request to the third party web services.

     

    Definitely possible using a variety of implementation types for the router.  What do you want to implement the router using?  Camel, Java, BPEL, BPM, etc.  Camel would probably be the most appropriate choice if it's truly a router.  Independent of the service implementation, you can add a service binding using our REST gateway to expose the service over SOAP.

     

    From what I have read on the forums and in the documentation, it should be possible to create a WSDL-based reference to a given third-party external SOAP service and not have to generate any Java client stubs for invoking the SOAP services. However, I cannot seem to fathom how that would be executed through the JBDS tooling and/or annotations.

     

    The only time you would have to generate Java client stubs is if your service implementation from above is a CDI bean service.  If it's a Camel route, for example, you can use the WSDL alone to represent the contract for the reference.  Once I know the implementation type you want to use, I can give more detail on what the actual config and implementation would look like.  Generally speaking, you just need to add a reference to the service component and use the WSDL for the contract.

     

    Also, per the referenced forum post, we need to be able to weave in some custom SOAP header elements for authentication with the third party web service and while I understand the concept behind using the SOAPContextMapper, it's difficult for me to wrap my brain around how to stitch it all together to form the required solution.

     

    I can provide an example of including a context mapper and referencing it in your application.  To make sure it lines up with what you want, just let me know the service implementation type you want to use for the router.  I'm guessing CDI Bean or Java DSL based on your line of inquiry.

     

    cheers,

    keith

  • 2. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    What we are trying to do is create a SY service that exposes a RESTEasy interface to our clients and routes the request to the third party web services.

     

    Definitely possible using a variety of implementation types for the router.  What do you want to implement the router using?  Camel, Java, BPEL, BPM, etc.  Camel would probably be the most appropriate choice if it's truly a router.  Independent of the service implementation, you can add a service binding using our REST gateway to expose the service over SOAP.

    A simple router is all we need, so Camel would work nicely at this point. I imagine we could weave in a transformer to handle converting the SOAP response into a Java object that would then be returned by the REST gateway to the client? We currently do this mapping in our JBossESB implementation through custom code in our action class that uses generated CXF client code to interact with the external web service.

     

    From what I have read on the forums and in the documentation, it should be possible to create a WSDL-based reference to a given third-party external SOAP service and not have to generate any Java client stubs for invoking the SOAP services. However, I cannot seem to fathom how that would be executed through the JBDS tooling and/or annotations.

     

    The only time you would have to generate Java client stubs is if your service implementation from above is a CDI bean service.  If it's a Camel route, for example, you can use the WSDL alone to represent the contract for the reference.  Once I know the implementation type you want to use, I can give more detail on what the actual config and implementation would look like.  Generally speaking, you just need to add a reference to the service component and use the WSDL for the contract.

     

    I was hoping that was the answer you would come back with. One of the PITA portions of our current implementation is the generation of the client stubs via CXF, as it really complicates our overall build and test processes.

     

    Also, per the referenced forum post, we need to be able to weave in some custom SOAP header elements for authentication with the third party web service and while I understand the concept behind using the SOAPContextMapper, it's difficult for me to wrap my brain around how to stitch it all together to form the required solution.

     

    I can provide an example of including a context mapper and referencing it in your application.  To make sure it lines up with what you want, just let me know the service implementation type you want to use for the router.  I'm guessing CDI Bean or Java DSL based on your line of inquiry.

     

    Can we use the context mapper with a pure Camel route implementation, or do we need to look at a Java DSL Camel implementation. Either would work for us. The CDI Bean approach would put us back in the mode of generating client stubs, which we want to avoid if at all possible.

     

    Thanks.

  • 3. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

     

    A simple router is all we need, so Camel would work nicely at this point. I imagine we could weave in a transformer to handle converting the SOAP response into a Java object that would then be returned by the REST gateway to the client?

     

    Yep.  If the object in question contains JAXB annotations, then you can just define a JAXB transformation for that class and you're good to go.  If you don't want JAXB, then a Java transformer or Smooks would be the other options.

     

    Can we use the context mapper with a pure Camel route implementation, or do we need to look at a Java DSL Camel implementation. Either would work for us. The CDI Bean approach would put us back in the mode of generating client stubs, which we want to avoid if at all possible.

     

    The context mapper will work with the XML or Java DSL route definition.  The context mapper (and message composer) is really just a helper for the gateway bindings.  The SOAP gateway has a default processing option for dealing with SOAP headers and the context mapper allows you to introduce a class which customizes/replaces that default behavior.

  • 4. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    Thanks, Keith. Any chance you can throw together a quick sample that shows how to set this up? I will also try to put one together as well.

  • 5. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

    Yeah, no probs.  I'll crank something out this afternoon.

  • 6. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

    Had a bad day at the office with Eclipse Juno and our latest tools build.  Everything worked great up to the point of switchyard.xml getting saved - then it went poof.  Rob's having a look.  In the meantime, I'll go back to Indigo and bang this out tonight.  Sorry for the wait.

  • 7. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    No problem, Keith. Been a rough day here as well. Just started my latest attempt at this, as we were having weird production release issues and other office oddities today.

  • 8. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

    Quick update : looks like save functionality is not working with our nightly for Indigo as well.  This obviously puts a damper on my plans to share a project with you.  Rob is having a look again this AM and hopefully we'll get it fixed quickly.  I want the nightly because I'd prefer to use the REST gateway tooling in 0.6 to create the project.  If it looks like this wont' get solved by this afternoon, I'll just hack the REST stuff in manually and share the project.

  • 9. Re: Implementation recommendation for service using 3rd party SOAP service
    Keith Babo Master

    I created the following app with the latest tooling using a workaround for the save issue provided by Rob.  I'll post back when the fix is in place and the nightly editor is safe to use again.

    restsoap-example.jpg

     

    I think this should be enough to get the ball rolling.  I accepted a lot of defaults, so the WSDL is pretty basic/dumb at the moment.   Some notes:

     

    • I wasn't sure if your REST endpoint was accpeting JSON or XML.  This one accepts XML, but JSON won't be a problem if that's your pleasure.
    • The JAX-RS contract for the REST endpoint only supports POST for the sake of example.  It also uses a String as input/output types instead of a domain object.  Domain objects can be used if desired.
    • Implemented a basic transform between String and the XML type - this is basically a NOP and simply returns the existing String representation of the XML input.
    • The Camel route uses a WSDL contract and an XML route.  The routing to the SOAP endpoint has been commented out since I didn't package a SOAP endpoint with the example.
    • Note the reference to the "ThirdParty" service uses a WSDL contract as well.  It's actually the same as the contract for the routing service.  You could always use different contracts if required.
    • I have packaged a test class which can POST against the REST endpoint.  Just run "mvn exec:java" after deploying the app to a SY-enabled AS 7 runtime.

     

    hth,

    keith

  • 10. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    Thanks, Keith. Will take a look and come back with any questions or concerns. Appreciate all of your assistance.

  • 11. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    Thanks again. I have a couple of questions regarding the SOAP side, so here is a sample SOAP message from which my questions derive:

     

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

                                 xmlns:web="http://service.thirdparty.com/webservices"

                                 xmlns:dta="http://service.thirdparty.com/webservices/schemas/DTAuthHeader"

                                 xmlns:loc="http://service.thirdparty.com/webservices/schemas/LocationService">

       <soapenv:Header>

          <web:DTAuthHeader>

             <dta:username>some_username</dta:username>

             <dta:password>some_password</dta:password>

          </web:DTAuthHeader>

       </soapenv:Header>

       <soapenv:Body>

          >web:LocateDeviceRequest>

             <loc:ID>some_device_id_to_locate</loc:ID>

          </web:LocateDeviceRequest>

       </soapenv:Body>

    </soapenv:Envelope>

     

     

    Now the questions:

     

    1. How would I weave in a SOAP context mapper, so that I could insert custom the custom DTAuthHeader elements with specific values in the SOAP header?
    2. Assuming that the string that is passed in via the REST interface is the ID of the device to locate, what would the transformer implementation look like that inserts that ID in as the text content for the <loc:ID> tag in the SOAP request?

  • 12. Re: Implementation recommendation for service using 3rd party SOAP service
    David Ward Master

    Michael,

     

    Regarding #1, I'm curious where you would be getting "some_username" and "some_password" from?  If you've got app-specific code to do that, you could wire it into your route.xml, after the <from> but before the last <to>.  So you could introduce your own SwitchYard service (most easily a CDI bean) in the middle of the route to do this.  Then, inside the bean, modify the appropriate Context property as I had showed you in that other forum discussion.  Then, inside the reference <binding.soap> for your ThirdPartyService, add a <contextMapper includes="DTAuthHeader"/> to make sure that the DTAuthHeader Context property will make its way out to the SOAP service you're proxying.

     

    David

  • 13. Re: Implementation recommendation for service using 3rd party SOAP service
    David Ward Master

    Just an implementation note on the above... If you're curious how you can get access to the Context from inside your CDI bean service execution, please see the "SwitchYard Context Injection" section in the Bean Services docs.

  • 14. Re: Implementation recommendation for service using 3rd party SOAP service
    Michael Daleiden Newbie

    David -

     

    Thanks for the suggestions. WRT your question about the source of some_username and some_password, our current JBossESB implementation gets these from properties files.

     

    I can definitely insert a CDI bean into the Camel route before routing to the external web service. I will weave that into the example that Keith provided and take it for a spin.

     

    One other question (which just came up based on a new requirement from one of our 3rd party clients):

     

    1. Is it possible to weave in mutual SSL authentication?
1 2 Previous Next