java 中间件和 SOA 示例

Middleware & SOA by Example

提问by IAmYourFaja

I am an inexperienced Java developer trying to wrap my head around some fundamental middleware/SOA concepts and technologies, specifically:

我是一名经验不足的 Java 开发人员，我试图围绕一些基本的中间件/SOA 概念和技术进行思考，特别是：

• Service-Oriented Architecture (SOA)
• Message-Oriented Middleware (MOM)
• Message Queue
• Apache Camel
• Mule
• EJBs
• Endpoints & Routes
• Service Bus/ESB
• JMS

• 面向服务的架构 (SOA)
• 面向消息的中间件 (MOM)
• 消息队列
• 阿帕奇骆驼
• 骡子
• EJB
• 端点和路由
• 服务总线/ESB
• 联合管理系统

After looking each of these up online/on Wikipedia, I was able to get (for the most part) decent definitionsfor each of these. What I am not understanding is how all of these technologies/concepts work togetheron the backend to provide a 2nd/business tier solution.

在在线/在 Wikipedia 上查看这些内容后，我能够（在大多数情况下）为每个内容获得合适的定义。我不明白的是所有这些技术/概念如何在后端协同工作以提供第二层/业务层解决方案。

Can someone please give an example of an architecture that would use all of these technologies/concepts, and explain what roleeach of them play in the overall solution? Once I see a working example I'm sure it will help me connect most of the dots.

有人可以举一个使用所有这些技术/概念的架构的例子，并解释它们在整体解决方案中扮演的角色吗？一旦我看到一个有效的例子，我相信它会帮助我连接大部分的点。

Edit: Since I added the bounty, I've had several answers that suggest reading books. Although I appreciate all feedback here, I simply can't part ways with 300 reputation points for an answer that, essentially, boils down to "RTM" (especially when I'm flat broke and can't affordthe manual!) To reiterate, the bounty and definitive answer will go to someone who can hit all of these bullets in a meaningful, practical example. This does not have to be a middleware compendium!!!Just a paragraph or two that shows how all these can be used together in harmony to produce a Java business-tier solution. Thanks again.

编辑：自从我添加了赏金，我有几个建议阅读书籍的答案。虽然我很感谢这里的所有反馈，但我根本无法用 300 点声望点来回答，这个答案基本上归结为“RTM”（尤其是当我破产并且买不起手册时！）重申，赏金和明确的答案将交给能够在一个有意义的、实际的例子中击中所有这些子弹的人。这不一定是中间件纲要！！！只需一两段内容就可以展示如何将所有这些和谐地结合使用以生成 Java 业务层解决方案。再次感谢。

采纳答案by Aravind Yarram

SOA main principles: Build systems as set of services where each service is

SOA 主要原则：将系统构建为一组服务，其中每个服务

• Coarse-grained
• Interoperable
• Loosely coupled

• 粗粒
• 可互操作
• 松散耦合

A company offers a lot of business services (coarse-grained) developed over many years and exposed to the users (human or other systems) in some form. There are more chances that each of these features have been designed and developed not keeping the above three principles in mind. Moreover, each of those features might be running on disparate heterogeneous platforms, using different technologies etc.

一家公司提供大量的业务服务（粗粒度），这些服务经过多年开发并以某种形式暴露给用户（人类或其他系统）。在设计和开发这些功能时，更有可能没有牢记上述三个原则。此外，这些功能中的每一个都可能运行在不同的异构平台上，使用不同的技术等。

What if you want to integrate these disparate features thus creating new solutions (For e.g. Amazon store front is a new service composed of their catalog service, shopping cart service etc)?

如果您想集成这些不同的功能从而创建新的解决方案（例如，亚马逊店面是一种由目录服务、购物车服务等组成的新服务），该怎么办？

You have two choices:

你有两个选择：

1. Building the new feature from scratch keeping the 3 principles in mind. But it is a very costly endeavor, and one that's almost never successful.
2. An effective and less risky alternative is to assemble/compose it from existing, proven (well tested) services.

1. 牢记 3 条原则，从头开始构建新功能。但这是一项非常昂贵的努力，而且几乎从未成功。
2. 一种有效且风险较小的替代方案是从现有的、经过验证的（经过良好测试的）服务中组装/组合它。

Option 2 is where ESBscan help with their support for routing, transformation, monitoring etc. Apache Camel, Muleare open-source ESB's. Endpoints & Routes are the terminology used in EIP (Enterprise Integration Patterns) that these ESB's implement. ESB's can take help of MOM's(Message-Oriented-Middleware) when they want to route/integrate services that are running on heterogeneous platforms (For e.g. the catalog service might be running on a mainframe system but the shopping cart is implemented using stateful EJBsrunning in a Java Application server). Message queueis a concept in MOM that acts a temporary storage of the message between the sender and receiver. This temporary storage provides lot of benefits like asynchronous delivery, guaranteed delivery etc. There are several different MOM vendors like IBM (WebSphere MQ), open-source ActiveMQ etc. We can use JMSto keep your code independent of the vendor.

选项 2 是ESB可以帮助他们支持路由、转换、监控等的地方。Apache Camel、Mule是开源 ESB。端点和路由是这些 ESB 实现的EIP（企业集成模式）中使用的术语。当 ESB想要路由/集成在异构平台上运行的服务时（例如，目录服务可能在大型机系统上运行，但购物车是使用运行的有状态 EJB实现的），ESB 可以借助MOM（面向消息的中间件）在 Java 应用程序服务器中）。消息队列是 MOM 中的一个概念，用于临时存储发送方和接收方之间的消息。这种临时存储提供了很多好处，如异步交付、保证交付等。有几个不同的 MOM 供应商，如 IBM (WebSphere MQ)、开源 ActiveMQ 等。我们可以使用JMS使您的代码独立于供应商。

I tried to relate all the concepts with an example. I also tried to keep it short. Please ask follow up questions to gain more understanding.

我试图将所有概念与一个例子联系起来。我也尽量保持简短。请提出后续问题以获得更多理解。

MOM is not a requirement to implement SOA. For e.g. if all of your services are exposed over SOAP via HTTP then you don't need a MOM in this case.

MOM 不是实现 SOA 的必要条件。例如，如果您的所有服务都通过 HTTP 通过 SOAP 公开，那么在这种情况下您不需要 MOM。

回答by neo

Java classes/example for every tech. might not be possible in single post because what you asked is evolution industry went through in last decade and still evolving. So, what happened over last decade can not be covered in one post. However, its good to understand how it went through this phase and why new technology stack required and what kind of problem it solves.

每种技术的 Java 类/示例。可能无法在单个帖子中实现，因为您问的是进化行业在过去十年中经历了并且仍在不断发展。因此，过去十年发生的事情无法在一篇文章中涵盖。然而，了解它如何经历这个阶段以及为什么需要新技术堆栈以及它解决什么样的问题是很好的。

• EJBs Enterprise Java Beans serverside component architecture. It enables rapid and simplified development of

  1) distributed(where multiple application server talks to each other, server components(e.g. service calling other service hosted on different server).

  2) transactional - persistance bean (DB TXNs), most important part of any simple/web/distributed application. Easy development e.g configuration base. Write XML which takes care of the transaction e.g. when to commit, when to roll back(on exceptions) etc. JPA Java Persistance APIs provide object relationship maping. Such as your table row is mapped to your java object through the xml configuration.

  3) secure - authentication(uid/pwd) and authorization(role based- who is logged in user and what all task he can do?).

• EJBs Enterprise Java Beans 服务器端组件架构。它支持快速和简化的开发

  1）分布式（其中多个应用程序服务器相互交谈，服务器组件（例如服务调用托管在不同服务器上的其他服务）。

  2) 事务性 - 持久性 bean (DB TXN)，任何简单/网络/分布式应用程序中最重要的部分。易于开发，例如配置基础。编写处理事务的 XML，例如何时提交、何时回滚（异常）等。 JPA Java 持久性 API 提供对象关系映射。比如你的表行通过xml配置映射到你的java对象。

  3）安全 - 身份验证（uid / pwd）和授权（基于角色 - 谁登录用户以及他可以做什么所有任务？）。

This looks good at one point to develope any enterprise application however it has got some disadvantages e.g. its very heavy (all jars included in it.). Classes used as bean should confirm to EJB standards (classes should have implemented certain interface for EJB engine to understand which type of bean it is).

这在某一点上看起来很适合开发任何企业应用程序，但是它有一些缺点，例如它很重（所有 jars 都包含在其中。）。用作 bean 的类应符合 EJB 标准（类应为 EJB 引擎实现某些接口以了解它是哪种类型的 bean）。

To overcome such scenarioes, there are many alternatives are available in industry for EJBs e.g Hibrnate does same things such as OR mapping, TXN handling same provided by persistance bean in EJB. Spring, light weight framework and simplifies business logic (you can use your already build class which need not to implement any interface, checked exceptions or extends some of the mandatory abstract classes).

为了克服这种情况，工业上有许多 EJB 的替代方案，例如 Hibrnate 做同样的事情，如 OR 映射，TXN 处理由 EJB 中的持久性 bean 提供。Spring，轻量级框架并简化业务逻辑（您可以使用您已经构建的类，不需要实现任何接口、检查异常或扩展一些强制性抽象类）。

Now a days, most of the compnies realy on the light weight frame work such as Spring, Hibernate, IBatis, Axis-2.

现在，大多数公司都在轻量级框架上工作，例如 Spring、Hibernate、IBatis、Axis-2。

• Service-Oriented Architecture (SOA) Service Oriented Architecture is an answer to the platform independence at the enterprise level. OR To integrate your application faster, to communicate between different application server.

  Just think that you want to implement solution where you are providing option for hotel booking all over the world. Your requirement is to check availability of rooms in those hotels. Now, it means that you need to interact with multiple hotel applications at a time. It's not necessary that every hotel is using same standard or their application(server, programming language) may be deployed on the different application servers. At a same time, its not practical to write different applications which can talk to all different type of the application server. We need some standard based solution which can solve this problem. It's possible through the Web services.

• 面向服务的体系结构 (SOA) 面向服务的体系结构是对企业级平台独立性的回应。或 为了更快地集成您的应用程序，在不同的应用程序服务器之间进行通信。

  试想一下，您想实施解决方案，为世界各地的酒店预订提供选项。您的要求是检查这些酒店的房间供应情况。现在，这意味着您需要一次与多个酒店应用程序进行交互。没有必要每个酒店都使用相同的标准，或者他们的应用程序（服务器、编程语言）可以部署在不同的应用程序服务器上。同时，编写可以与所有不同类型的应用服务器通信的不同应用程序是不切实际的。我们需要一些基于标准的解决方案来解决这个问题。这可以通过 Web 服务实现。

It is possible because web services are sending message in the SOAP(Simple Object Access Protocol), based on the XML. XML is used to interchange data across any language, platform or network protocol.

这是可能的，因为 Web 服务正在基于 XML 的 SOAP（简单对象访问协议）中发送消息。XML 用于跨任何语言、平台或网络协议交换数据。

Web services can be classified SOAP Based and REST. SOAP based service JAX-RPC and JAX-WS (http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html)

Web 服务可分为基于 SOAP 的和 REST 的。基于 SOAP 的服务 JAX-RPC 和 JAX-WS ( http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc/index.html)

Web services can be developed contract first - first write WSDL. code first - first write code.

Web 服务可以先开发契约——先写 WSDL。code first - 首先编写代码。

Now, lets talk how to start for the web services practically.

现在，让我们谈谈如何实际开始 Web 服务。

Simplest web service or hello world(JAXWS) can be written as follows:- http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

最简单的 Web 服务或 hello world(JAXWS) 可以写成如下：- http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/samples/java_first_jaxws/

• Message-Oriented Middleware (MOM)
• JMS

• Message Queue (Point-to-Point)

  MOM is required to over come disadvantages of request-response style communication. Server need to be alive when client sends response. Client wait for response till server executes and respond back.

  Request response - application will fail if server or client is down. MOM - Either of the end point is not required to be on time you send the request message for the processing.

  MOM is concept and JMS is specification on this concept. Many vendors have implementation of this specification e.g IBM has MQ, OpenJMS open source implementation, EMS from Tibco etc.

• 面向消息的中间件 (MOM)
• 联合管理系统

• 消息队列（点对点）

  MOM 需要克服请求-响应式通信的缺点。当客户端发送响应时，服务器需要处于活动状态。客户端等待响应，直到服务器执行并响应。

  请求响应 - 如果服务器或客户端关闭，应用程序将失败。MOM - 任何一个端点都不需要按时发送请求消息进行处理。

  MOM 是概念，JMS 是对这个概念的规范。许多供应商已经实现了这个规范，例如 IBM 有 MQ、OpenJMS 开源实现、来自 Tibco 的 EMS 等。

JMS specification has majorly two patterns. Pub/sub and ponin-to-point.

JMS 规范主要有两种模式。Pub/sub 和 ponin 到点。

Pub/subis topic, your application want to publish certain information to all the interested parties. e.g. dash board. (Stock application want to notify certain message to all the registered listeners).

发布/订阅是主题，您的应用程序希望向所有感兴趣的各方发布某些信息。例如仪表板。（Stock 应用程序希望将某些消息通知给所有已注册的侦听器）。

Point-to-Pointcommunication is done through message queue.

点对点通信是通过消息队列完成的。

Business use case- think you have application e.g customer request to the customer care. Other side you have multiple customer care representatives and other side customers sometimes more than customer care representatives, at a time one and only one representative will get the request to be processed and he/she will not get next request until finishes the task. (Same one queue multiple windows and which ever window is free will process the request). You can think of other complexity in this e.g what if one of the node is failed, request not processed and particular type of request needs to be process by particular node. etc.

业务用例 - 认为您有应用程序，例如客户对客户服务的请求。另一方您有多个客户服务代表，而另一方客户有时会超过客户服务代表，一次只有一个代表将获得要处理的请求，并且在完成任务之前他/她将不会收到下一个请求。（同一个队列多个窗口，哪个窗口空闲将处理请求）。您可以考虑其他复杂性，例如，如果其中一个节点发生故障、请求未处理以及特定类型的请求需要由特定节点处理会怎样。等等。

Produce code:- http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

生成代码：- http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.java

Consumer synchronous code:- (POJO classes) http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

消费者同步代码：-（POJO 类） http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleSynchConsumer.java

http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

Consume asynchronous code:- (Spring by example - reads message from destination till program will not be stopped.) http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

使用异步代码:- (Spring by example - 从目标读取消息直到程序不会停止。) http://www.springbyexample.org/examples/simple-spring-jms-listener-config.html

Though, its just basic there are many aspects to be covered in this MOM e.g. what's fail-over mechanism, what is selector, durable message, message acknowledgement modes etc...

尽管如此，它只是基本的，在这个 MOM 中有很多方面要涵盖，例如什么是故障转移机制，什么是选择器，持久消息，消息确认模式等......

• Service Bus/ESB
• Endpoints & Routes
• Apache Camel
• Mule

• 服务总线/ESB
• 端点和路由
• 阿帕奇骆驼
• 骡子

Now, lets say you have adopted SOA and MOM long back and you have bunch of services which talks to each others to accomplish enterprise wide task. Imagine to manage logic such as multiple destination whom should be redirected from where will be very cumbersome. Some people call this application logic. Service buses will be used to reduce application logic and focus more on the business logic(functionality provided by app).

现在，假设您很久以前就采用了 SOA 和 MOM，并且您有一堆服务可以相互通信以完成企业范围的任务。想象一下，管理应该从哪里重定向的多个目的地的逻辑将非常繁琐。有些人称之为应用逻辑。服务总线将用于减少应用程序逻辑，更多地关注业务逻辑（应用程序提供的功能）。

In Simple words, consider End pointas URL exposed on server. You will use this url/end point to invoke your service.

简单来说，将端点视为服务器上公开的 URL。您将使用此 url/端点来调用您的服务。

e.g. http://localhost:8888/Context/MyService?wsdl

例如 http://localhost:8888/Context/MyService?wsdl

in code:-

在代码中：-

    String endpointAddress = "http://localhost:8080/jaxws/services/hello_world?wsdl";

    // Add a port to the Service
    service.addPort(PORT_NAME, SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);

    HelloWorld hw = service.getPort(HelloWorld.class);
    System.out.println(hw.sayHi("World"));

RoutesWhen service bus receives particular message, it will route it through no of services/broker destinations such as queue/topics. This path is known as route.

路由当服务总线接收到特定消息时，它将通过任何服务/代理目的地（例如队列/主题）路由它。这条路径称为路由。

E.g your stock application has got some input by analyst, it will be processed through the application/web component and then result will be published to all the interested/registered members for particular stock update.

例如，您的股票应用程序获得了分析师的一些输入，它将通过应用程序/网络组件进行处理，然后将结果发布给所有感兴趣的/注册成员以进行特定的股票更新。

Apache Camel and Muelhttp://camel.apache.org/how-does-camel-compare-to-mule.htmlprovides solution for the enterprise integration.

Apache Camel 和 Muel http://camel.apache.org/how-does-camel-compare-to-mule.html为企业集成提供了解决方案。

回答by andrew cooke

Enterprise Integration Patternscan help you understand how everything fits together.

企业集成模式可以帮助您了解所有内容如何组合在一起。

[update:] Your follow-up question on another answer made me realise that you're confused about specific products. That's partly because software in practice tends to map to more than one concept and partly because different companies argue that they provide "everything", when really they don't.

[更新：]您对另一个答案的后续问题让我意识到您对特定产品感到困惑。这部分是因为实践中的软件往往映射到多个概念，部分是因为不同的公司争辩说他们提供“一切”，而实际上他们没有。

The ESBs are toolkits / libraries that let you connect everything together. They are neither the services themselves, nor the messaging implementations, but the goo that fills the odd little gaps in-between. If you were writing everything from scratch you might not even need one, because what they are best at is fixing the mismatch between a whole pile of different technologies, and if you are starting from scratch you can avoid that mess.

ESB 是工具包/库，可让您将所有内容连接在一起。它们既不是服务本身，也不是消息传递的实现，而是填补两者之间奇怪的小差距的粘性物质。如果您从头开始编写所有内容，您甚至可能不需要一个，因为它们最擅长的是修复一大堆不同技术之间的不匹配，如果您从头开始，则可以避免这种混乱。

The services are, well, the services. You might use some EJBs when implementing one (I only mention this because for some reason you include them in your question).

服务就是服务。在实现 EJB 时，您可能会使用一些 EJB（我之所以提到这一点，是因为出于某种原因您将它们包含在您的问题中）。

The messaging middleware is software that gets messages from A to B. That's extremely useful, but also complex, and everyone and their brother has invented their own. So you need some abstraction that lets you avoid lock-in. That can be an ESB or, if you are all-Java then it can be JMS. But even when you are all-Java with JMS you may still want to use an ESB because they are libraries of all the bits of Java code you would still need to write (random bits of routing logic, message reformatting, etc etc).

消息中间件是从 A 到 B 获取消息的软件。这非常有用，但也很复杂，每个人和他们的兄弟都发明了自己的。所以你需要一些抽象来避免锁定。那可以是 ESB，或者，如果您全是 Java，那么它可以是 JMS。但是，即使您使用 JMS 全是 Java，您可能仍然希望使用 ESB，因为它们是您仍然需要编写的所有 Java 代码位（路由逻辑的随机位、消息重新格式化等）的库。

Hope that helps. My original answer is more about the abstract patterns that you build with these tools - when you're wiring things together the same problems come up again and again.

希望有帮助。我最初的答案更多是关于您使用这些工具构建的抽象模式 - 当您将事物连接在一起时，同样的问题会一次又一次地出现。

回答by Axel Podehl

Endpoints & Routes: where the information comes from and goes to. Message Queue is one type of endpoint. The other type is a Message Topic.

Endpoints & Routes：信息从哪里来，去哪里。消息队列是一种类型的端点。另一种类型是消息主题。

An endpoint is a 'logical name for a thing', e.g. PRICE.MSFT, that is used by a publisher or consumer application to get things from or send to. Topics deliver information to everyone subscribed (one-to-one or one-to-many), queues deliver messages to the first one that gets it (usually one-to-one). Forget about Queues, everything can also be done with Topics and topics have several advantages.

端点是“事物的逻辑名称”，例如 PRICE.MSFT，发布者或消费者应用程序使用它来从事物中获取事物或向其发送事物。主题将信息传递给订阅的每个人（一对一或一对多），队列将消息传递给第一个收到它的人（通常是一对一）。忘记队列，一切都可以用主题来完成，主题有几个优点。

Message-Oriented Middleware (MOM): the software infrastructure that delivers information between topics or queus. It is 'message-oriented' not 'packet oriented' as TCP is. So each information blob is delivered in one, hopefully self-describing, message. The implementation of your MOM then gives you an API where you can do things like msg.get("bid")

面向消息的中间件 (MOM)：在主题或队列之间传递信息的软件基础设施。它是“面向消息的”而不是像 TCP 那样的“面向数据包”。因此，每个信息 blob 都在一个消息中传递，希望是自我描述的消息。然后，您的 MOM 的实现为您提供了一个 API，您可以在其中执行诸如 msg.get("bid") 之类的操作

JMS and AMQP are examples of a MOM specifications. MOM implementations are the real products that implement these specs: TIBCO EMS, Websphere MQ, MSMQ, Solace, and many, many others

JMS 和 AMQP 是 MOM 规范的示例。MOM 实现是实现这些规范的真正产品：TIBCO EMS、Websphere MQ、MSMQ、Solace 等等

Apache Camel - very interesting approach on how to configure workflows in this MOM world. But a more advanced concept.

Apache Camel - 关于如何在这个 MOM 世界中配置工作流的非常有趣的方法。而是一个更高级的概念。

Service-Oriented Architecture (SOA), Service Bus/ESB are just new buzzwords words for what used to be called EAI (Enterprise Application Integration). They are recommendations on how to use 'MOM's and a way to pay high-priced consultants. What 'ESB' adds to a MOM is the idea of thinking of your publishers as 'services' providing a service. In other words: don't think too much about what one consumer wants right now. There might be 5 consumers in the future and that publisher should provide a service, not 'create information that consumer A wants'. (It'll become clearer once your architecture has grown to 5+ applications). Also you should have some common object model, maybe in XML to make things simple between applications.

面向服务的架构 (SOA)、服务总线/ESB 只是过去称为 EAI（企业应用程序集成）的新流行词。它们是关于如何使用“MOM”的建议以及支付高价顾问的一种方式。“ESB”添加到 MOM 的想法是将您的发布者视为提供服务的“服务”。换句话说：不要过多考虑消费者现在想要什么。未来可能有 5 个消费者，发布者应该提供服务，而不是“创建消费者 A 想要的信息”。（一旦您的架构增长到 5 个以上的应用程序，它就会变得更加清晰）。此外，您应该有一些通用的对象模型，也许是 XML 格式，以使应用程序之间的事情变得简单。

Mule - one form of ESB, but its' not exactly main-stream. In 5 years, most middleware action might have been moved to AMQP or something else entirely.

Mule - ESB 的一种形式，但它并不完全是主流。5 年内，大多数中间件操作可能已经完全转移到 AMQP 或其他地方。

EJBs: Sun's idea of sophisticated Java classes that run in a container. Supposed to make application development easier. But in many cases it made things more complex. A better alternative would be 'Spring' - but EJB's are about something else (not just MOM). Its more about how to develop bigger applications (see IoC pattern).

EJB：Sun 提出的在容器中运行的复杂 Java 类的想法。旨在使应用程序开发更容易。但在许多情况下，它使事情变得更加复杂。更好的选择是“Spring”——但 EJB 是关于别的东西（不仅仅是 MOM）。它更多地是关于如何开发更大的应用程序（参见 IoC 模式）。

If you are looking on where to start: I would recommend learning about JMS (all other MOM's are simliar and JMS is the basis of EJB's/ Mule, ...) and, unless you have super-high performance requirements, consider messages to be a TextMessage containing XML. Most tools are available in that area. Or even simpler but less sophisticated, a MapMessage with key/value pairs.

如果您正在寻找从哪里开始：我建议您学习 JMS（所有其他 MOM 都是类似的，JMS 是 EJB/Mule 的基础，...）并且，除非您有超高的性能要求，否则请考虑将消息作为包含 XML 的 TextMessage。大多数工具都在该区域可用。或者甚至更简单但不那么复杂，带有键/值对的 MapMessage。

回答by MrGomez

Taking all of your requirements and packaging them into a query, I came across an excellentcase study that should meet your needs:

将您的所有需求打包成一个查询，我发现了一个很好的案例研究，应该可以满足您的需求：

• Service Oriented Architecture: An Integration Blueprint

• 面向服务的架构：集成蓝图

I went ahead and fulltext searched the book using Amazon's "Search Inside This Book" feature. It covers all of the integration cases you've discussed, appears to be thorough, and steps you through the entire design and implementation process.

我继续使用亚马逊的“在本书中搜索”功能对这本书进行全文搜索。它涵盖了您讨论过的所有集成案例，看起来很全面，并引导您完成整个设计和实施过程。

I'm embarrassed to state I haven't read through this myself, but I highly recommend using the same tools I did to see if it fits your needs before investing in a copy. It seems more thorough, more complete, and more helpful than simply foisting you on a whole lot of incomplete documentation or spooling out content into an answer here.

我不好意思说出我没有通过这一读我自己，但我强烈建议使用我一样的工具，看看它是否在复制之前的投资适合您的需要。与简单地将大量不完整的文档强加给您或将内容拼凑成一个答案相比，它似乎更彻底、更完整、更有帮助。

回答by ChrLipp

You mix a lot of different concepts and technologies with different abstraction levels. But all of your concepts have something to do with (enterprise) application integration. I will try to comment your definitions:

您将许多不同的概念和技术与不同的抽象级别混合在一起。但是您的所有概念都与（企业）应用程序集成有关。我将尝试评论您的定义：

• Service-Oriented Architecture (SOA)
  SOA provides a set of principles and methodologies to integrate existing applications as loosely coupled units. From the Enterprise Integration Patterns (see below): "SOAs blur the line between integration and distributed aplications".
• Service Bus/ESB
  The ESB is a main concept of SOA to reduce the dependencies within the applications in a SOA. Instead of a lot of dependencies between the applications each application is connected to the ESB.
• Message-Oriented Middleware (MOM)
  MOM is a infrastructure for sending and receiving messages between distributed systems. This is used to integrate applications. MOM was the golden hammer before the SOA hype came up. Since both are useful, big integration suites provides both ESB and MOM (or use MOM inside their ESB).
• Message Queue
  A message queue is just a technical detail aspect in MOM architecture. When message sending/receiving is decoupled, message are stored in queues until the recipient is ready.
• Apache Camel
  When the book Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutionshit the market, some software solutions have been created which provides implementation for the patterns in this book. Apache Camel is one of them. Camel is also a part of Apache ServiceMix which is also an open source ESB. FuseSource and Talend are packaging Apache ServiceMix, Apache Camel and Apache Active MQ (MOM) to bundles with commercial support.
• Mule
  Mule is also an open source ESB and integration platform.
• EJBs
  From Wikipedia: Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.This means EJB is a component within an application and has primary nothing to do with integrating applications.
• Endpoints & Routes
  When you work with Apache Camel you are designing routes between endpoints, see a tutorial. In short, message are entering/leaving your system via endpoints and are processed in a flow defined by a route.
• JMS
  JMS or Java Message Service is a Message Oriented Middleware (MOM) with an standardized Java API.

• 面向服务的体系结构 (SOA)
  SOA 提供了一组原则和方法来将现有应用程序集成为松散耦合的单元。来自企业集成模式（见下文）：“ SOA 模糊了集成和分布式应用程序之间的界限”。
• 服务总线/ESB
  ESB 是 SOA 的一个主要概念，用于减少 SOA 中应用程序内的依赖性。每个应用程序都连接到 ESB，而不是应用程序之间存在大量依赖关系。
• 面向消息的中间件 (MOM)
  MOM 是用于在分布式系统之间发送和接收消息的基础结构。这用于集成应用程序。在 SOA 炒作出现之前，妈妈是金锤。由于两者都很有用，大型集成套件同时提供 ESB 和 MOM（或在其 ESB 中使用 MOM）。
• 消息队列
  消息队列只是 MOM 体系结构中的一个技术细节方面。当消息发送/接收解耦时，消息将存储在队列中，直到接收者准备就绪。
• Apache Camel
  当《企业集成模式：设计、构建和部署消息传递解决方案》一书上市时，已经创建了一些软件解决方案，它们为本书中的模式提供了实现。Apache Camel 就是其中之一。Camel 也是 Apache ServiceMix 的一部分，它也是一个开源 ESB。FuseSource 和 Talend 正在将 Apache ServiceMix、Apache Camel 和 Apache Active MQ (MOM) 打包成具有商业支持的捆绑包。
• Mule
  Mule 也是一个开源 ESB 和集成平台。
• EJB
  来自维基百科：Enterprise JavaBeans (EJB) 是一种托管的服务器端组件架构，用于模块化构建企业应用程序。这意味着 EJB 是应用程序中的一个组件，与集成应用程序无关。
• 端点和路由
  当您使用 Apache Camel 时，您正在设计端点之间的路由，请参阅教程。简而言之，消息通过端点进入/离开您的系统，并在由路由定义的流中进行处理。
• JMS
  JMS 或 Java 消息服务是具有标准化 Java API 的面向消息的中间件 (MOM)。

回答by Rashod Chamikara Bandara

Enterprise Application Integration (EAI)is key to connecting business applications with heterogeneous systems. Over the years, architects of integration solutions have invented their own blend of patterns in a variety of ways. But most of these architectures have similarities, initiating a set of widely accepted standards in architecting integration patterns. Most of these standards are described in the Enterprise Integration Patterns Catalog available at: http://www.eaipatterns.com/toc.html.

企业应用程序集成 (EAI)是将业务应用程序与异构系统连接起来的关键。多年来，集成解决方案的架构师以各种方式发明了他们自己的模式组合。但是这些架构中的大多数都有相似之处，在架构集成模式中启动了一套被广泛接受的标准。大多数这些标准都在企业集成模式目录中进行了描述：http: //www.eaipatterns.com/toc.html。

WSO2 ESB

WSO2 ESB

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentation! WSO2 ESB is a fast, lightweight, 100% open source, and user-friendly ESB distributed under the Apache Software License v2.0. WSO2 ESB allows system administrators and developers to conveniently configure message routing, mediation, transformation, logging, task scheduling, failover, load balancing, and more. It supports the most commonly used Enterprise Integration Patterns (EIPs) and enables transport switching, eventing, rule-based mediation, and priority-based mediation for advanced integration requirements. The ESB runtime is designed to be completely asynchronous, non-blocking, and streaming based on the Apache Synapse mediation engine.

WSO2 企业服务总线 (ESB) 4.7.0 文档！WSO2 ESB 是一种快速、轻量级、100% 开源且用户友好的 ESB，在 Apache 软件许可证 v2.0 下分发。WSO2 ESB 允许系统管理员和开发人员方便地配置消息路由、中介、转换、日志记录、任务调度、故障转移、负载平衡等。它支持最常用的企业集成模式 (EIP)，并支持传输交换、事件、基于规则的中介和基于优先级的中介，以满足高级集成需求。ESB 运行时被设计为基于 Apache Synapse 中介引擎的完全异步、非阻塞和流式传输。