ESB Web 服务适配器
webservice适配器的功能是让不同的webservice（例如http/jms）可以互相调用吗？它是否像一个代理，例如将soap/http webservice转换为soap/jms webservice？
图中存在三个网络服务、webservice-1 和webservice-1由第三方发布，adaptor-A和adaptor-B用于调用它们，webservice-3由adaptor-c发布。首先，当有人调用webservice-3时，adaptor-c拦截soap请求并发送到esb，esb有一个广播路由器，路由器将其发送到adapter-A &适配器-B、适配器-A &然后适配器-B 分析该消息并调用 webservice-1 和 webservice-2。适配器-B将webservice响应发送到esb，esb中也有一个聚合器，然后聚合器组装这两个响应并将其发送给适配器-c，最后适配器-c将最终结果发送给webservice-3用户！
我想问这个流程是否可行？如果可行的话，如何设计adapter-A、adapter-B和adapter-c？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，这非常适合 ESB 的场景。当您的适配器不实现特殊的业务逻辑并且仅负责“说出”Web 服务所需的协议时，您可能可以将服务直接连接到 ESB。这种“协议虚拟化”基本上是由各种 ESB 提供的，甚至像 Axis2 或 CXF 这样的普通 Web 服务堆栈也可以处理大量的传输协议。
关于业务逻辑有不同的可能性。对于简单的场景，您可以考虑使用 Apache Camel 等 EIP 感知框架和链企业集成模式 (EIP) [Hohpe 等人] 来实现所需的集成。对于更复杂的场景，您可以考虑使用 BPEL（业务流程执行语言）。 BPEL 是描述性并行编程语言，专注于以事务性、长期运行的方式编排 Web 服务。 BPEL 可以由 Apache ODE 等执行。
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.