3 Replies Latest reply on Jul 20, 2009 12:36 PM by David Ward

    WS Proxy Scenarios

    Burr Sutter Master

      We have heard that "proxying" a WS endpoint through the JBossESB is difficult and somewhat painful. The goal of this thread to try to describe the scenarios where people consume a web service, mediate it and provide a web service.

      A simple diagram to set the terminology:
      PHP Client -> ESB receive SOAP, host WSDL -> ESB consume external service -> .NET WS
      In this case the ESB is both a consumer and a provider. Some refer to this concept as the ESB hosting a virtual service to hide the actual service.

      Feel free to add to or modify this list of scenarios:
      - Basic: The ability to provide location abstraction, the ultimate consumer/client is unaware of where the ultimate service provider is as the ESB sits in the middle. In this case the whole of the SOAP request/response should be available in the action chain and passed from the consumer to the service provider. The original WSDL is hosted by the ESB with a simple modification to the soap:address.
      - Versioning: The ESB could host two virtual proxy services (v1 and v2) that have slightly different WSDLs with routing to the appropriate service provider endpoint.
      - Transformation: Hundreds of deployed consumers clients produce a particular SOAP request, the service provider has since modified the WSDL of the endpoint (e.g. they previously wanted fullName and now want firstName and lastName), the ESB can provide a transformation before and after as a wrapper.
      - Routing: The ESB can publish a common WSDL as an entry-point, intake service, the SOAP Header/Body are evaluated to determine which external WS service provider will fulfill the request and provide the response.
      - Service Chaining: Multiple ESB hosted virtual services can be routed through before hitting the external service provider that will provide the synchronous response.
      - Orchestrated: A ESB hosted service starts either a BPEL or JPDL process flow that will drive which external WS endpoint(s) are invoked to fulfill the request.