Does the webservice adaptor’s function is let different webservice(eg,http/jms) can call each other?Does it like a proxy such as transform soap/http webservice to soap/jms webservice?
In the picture there exist three webservice,webservice-1 and webservice-1 are published by third part,adaptor-A and adaptor-B are used to call them,webservice-3 is published by adaptor-c.first,when someone call webservice-3,the adaptor-c intercept the soap request and send it to esb ,the esb have a broadcast router and the router send it to adaptor-A & adaptor-B,adaptor-A & adaptor-B then analyse the message and call webservice-1&webservice-2.after that adaptor-A & adaptor-B send webservice response to esb,esb also have a aggregator in it,then aggregator assemble these two response and send it to adaptor-c,At last,adaptor-c send the final result to webservice-3 user!
I want to if this flow is feasible?if feasible,how to design the adaptor-A and adaptor-B and adaptor-c?
yes, this is well suited scenario for an ESB. When your adapters don’t implement a special business logic and are only responsible for “speaking” the protocol expected by the Web service, you can probably connect the services directly to the ESB. This kind of “protocol virtualization” is basically provided by all kinds of ESBs, even plain Web service stacks like Axis2 or CXF can deal with a large set of transport protocols.
Regarding the business logic there are different possibilities. For simple scenarios you can consider using a EIP-aware framework like Apache Camel and chain Enterprise Integration Patters (EIP) [Hohpe et al] to achieve the desired integration. For more complex scenarios you can consider using BPEL (Business Process Execution Language). BPEL is descriptive parallel programming language with focus on orchestrating Web services in a transactional, long-running fashion. BPEL can be executed e.g. by Apache ODE.