Hello,
It's a bit unclear to me how to implement a web service proxy in Sonic ESB. It seems that other ESB products have the notion of creating proxies for service endpoints to allow for message mediation. However, I do not see a clear way to do this in Sonic's workbench.
I have a set of web services that I would like to create proxies for in order to mediate messages that flow to them. I need to capture the incoming message and apply a VET(R)O patter to it and return the response back to the caller as if it came from the ultimate receiver.
Can anyone suggest how this is done using the workbench? I'd appreciate any documents that you could point me to.
Thanks!
Alejandro
If you're using Sonic Workbench 7.6, the New ESB Process give you the option (on the second page) to Create Process using Process Template. One of the options it VETO. Perhaps this helps?
Hello,
Thanks. I probably didn't phrase this properly.
Other ESBs address this scenario explicitly by providing a "proxy" concept (Synapse, Aqualogic) where:
- An endpoint (in this case a web service) is be proxied by fetching or referencing a wsdl.
- The ESB hosts the service interface
- The client binds to the instance of the ESB's proxied interface
- The client sends to the ESB where the message is mediated before its sent to the ultimate receiver.
- The ESB sends to the ultimate receiver.
- The ESB returns the response to the client.
I don't see this concept in Sonic ESB. There may be a way to do this, but the docs do not make it clear on how to accomplish this. I do see how to generate a wsdl from a process, but this is not quite what I want. This would also allow to switch between transports. For example, I am also interested receiving via web service and switching transports to JMS.
Thanks!
Alejandro
Knowing that you have experience with other ESB's, I can now understand some of the uncertainty regarding terminology, user experience, etc.
The way I would approach this would be to have an ESB process that calls the required service (ultimate receiver, proxied service or whatever you want to call it). If the required service is a web service call, the step in the ESB process would be a web service callout. If it's a JMS destination, the step would be a JMS Endpoint. ...and so on...
The ESB process will typically have a JMS entry endpoint, so the client call access the process from JMS. To enable the client to access the process as a web service, you need to wrap the process as a web service. (see http://www.psdn.com/library/entry.jspa?externalID=5311)
You would also be able to take the same wrapping approach for any other kind of entry transport required for different clients.