中间件和SOA by Example

时间:2012-04-07 14:28:56

标签: java jms ejb-3.0 soa message-queue

我是一位缺乏经验的Java开发人员,试图围绕一些基本的中间件/ SOA概念和技术,特别是:

  • 面向服务的体系结构(SOA)
  • 面向消息的中间件(MOM)
  • Message Queue
  • Apache Camel
  • 的EJB
  • 终点&路由
  • Service Bus / ESB
  • JMS

在网上/维基百科上查看每一个之后,我能够获得(大部分)体面的定义。我不理解的是所有这些技术/概念如何在后端协同工作以提供第二/业务层解决方案。

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

编辑:由于我添加了赏金,我有几个答案建议阅读书籍。虽然我很欣赏这里的所有反馈,但我根本无法分享300个声望点的答案,基本上可以归结为“RTM”(特别是当我已经破产并且无法负担手册!)重申一下,赏金和明确的答案将发送给能够在一个有意义的实际例子中击中所有这些子弹的人。 这不一定是一个中间件概要!!! 只是一段或两段,展示了如何将所有这些协调一致地用于生成Java业务层解决方案。再次感谢。

7 个答案:

答案 0 :(得分:21)

SOA主要原则:将系统构建为每个服务所在的服务集

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

一家公司提供了许多商业服务(粗粒度),这些服务多年来开发并以某种形式暴露给用户(人类或其他系统)。设计和开发这些功能的可能性更大,而不考虑上述三个原则。此外,这些功能中的每一个都可能在不同的异构平台上运行,使用不同的技术等。

如果您想要集成这些不同的功能,从而创建新的解决方案(例如亚马逊商店前端是由他们的目录服务,购物车服务等组成的新服务),该怎么办?

您有两种选择:

  1. 从头开始构建新功能,牢记三项原则。但这是一项非常昂贵的努力,而且几乎从未成功过。
  2. 一种有效且风险较小的替代方案是从现有的,经过验证的(经过良好测试的)服务中组装/组合它。
  3. 选项2是 ESB 可以帮助他们支持路由,转换和监控等。 Apache CamelMule 是开源的ESB的。终点&路由是这些ESB实现的EIP(Enterprise Integration Patterns)中使用的术语。当他们想要路由/集成在异构平台上运行的服务时,ESB可以借助 MOM的Message-Oriented-Middleware)(例如,目录服务可能在大型机系统上运行但是购物cart是使用在Java应用程序服务器中运行的有状态EJB 实现的。 消息队列是MOM中的一个概念,用于在发送方和接收方之间临时存储消息。这个临时存储提供了许多好处,如异步传输,保证交付等。有几个不同的MOM供应商,如IBM(WebSphere MQ),开源ActiveMQ等。我们可以使用 JMS 来保持代码独立于供应商。

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

    MOM不是实施SOA的要求。对于例如如果所有服务都是通过HTTP通过SOAP公开的,那么在这种情况下你不需要MOM。

答案 1 :(得分:10)

每个技术的Java类/示例。可能不可能在单一职位上,因为你问的是进化产业在过去十年中经历了并且仍在不断发展。所以,过去十年发生的事情不能在一篇文章中介绍。但是,很好理解它是如何经历这个阶段的,以及为什么需要新的技术堆栈以及它解决了什么样的问题。

  • 的EJB Enterprise Java Beans服务器端组件体系结构。它可以快速简化地开发

    1)分布式(多个应用服务器相互通信,服务器组件(例如服务调用托管在不同服务器上的其他服务)。

    2)transactional - persistance bean(DB TXNs),是任何简单/ web /分布式应用程序中最重要的部分。易于开发,例如配置基础。编写负责交易的XML,例如什么时候提交,什么时候回滚(例外)等.JPA Java Persistance API提供对象关系maping。例如,您的表行通过xml配置映射到您的java对象。

    3)安全 - 身份验证(uid / pwd)和授权(基于角色 - 登录用户以及他可以执行的所有任务?)。

这在开发任何企业应用程序方面看起来都很好,但它有一些缺点,例如:它很重(包括在里面的所有罐子)。用作bean的类应该确认EJB标准(类应该为EJB引擎实现某些接口以了解它是哪种类型的bean)。

为了克服这种情况,业界可以为EJB提供许多替代方案,例如Hibrnate执行相同的操作,例如OR映射,处理EJB中的persistance bean提供的TXN。 Spring,轻量级框架并简化了业务逻辑(您可以使用已经构建的类,它不需要实现任何接口,检查异常或扩展一些必需的抽象类)。

现在有一天,大多数公司都在轻量级框架上工作,比如Spring,Hibernate,IBatis,Axis-2。

  • 面向服务的体系结构(SOA) 面向服务的体系结构是企业级平台独立性的答案。 要么 要更快地集成应用程序,以便在不同的应用程序服务器之间进行通信。

    只是想想要实施解决方案,为全世界的酒店预订提供选择。您的要求是检查这些酒店的房间可用性。现在,这意味着您需要一次与多个酒店应用程序进行交互。并非每个酒店都使用相同的标准,或者他们的应用程序(服务器,编程语言)可以部署在不同的应用程序服务器上。同时,编写可以与所有不同类型的应用服务器通信的不同应用程序是不实际的。我们需要一些基于标准的解决方案来解决这个问题。它可以通过Web服务实现。

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

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

可以开发Web服务         合同第一 - 首先编写WSDL。         代码优先 - 首先编写代码。

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

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

  • 面向消息的中间件(MOM)
  • JMS
  • 消息队列(点对点)

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

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

    MOM是概念,JMS是这个概念的规范。许多供应商都有这个规范的实现,例如IBM有MQ,OpenJMS开源实现,来自Tibco的EMS等。

JMS规范主要有两种模式。发布/发布和ponin-to-point。

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

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

商业用例 - 认为您有客户要求的客户要求等应用程序。另一方面,您有多个客户服务代表和其他方客户,有时候比客户服务代表更多,一次只有一位代表会收到处理请求,他/她在完成任务之前不会得到下一个请求。 (同一个队列中的多个窗口以及任何窗口都是免费的将处理请求)。您可以考虑其中的其他复杂性,例如,如果其中一个节点发生故障,请求未处理,特定类型的请求需要由特定节点处理。等

制作代码: - http://docs.oracle.com/javaee/1.4/tutorial/examples/jms/simple/src/SimpleProducer.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

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

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

  • Service Bus / ESB
  • 终点&路由
  • Apache Camel

现在,假设您已经采用了SOA和MOM,并且您拥有大量服务,这些服务可以相互通信以完成企业级任务。想象一下,管理诸如多个目的地之类的逻辑应该从哪里重定向,这将非常麻烦。有些人称之为应用逻辑。服务总线将用于减少应用程序逻辑,并更多地关注业务逻辑(应用程序提供的功能)。

简单来说,将端点视为服务器上公开的URL。您将使用此网址/结束点来调用您的服务。

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

代码中的

: -

    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"));

<强>路线 当服务总线收到特定消息时,它将通过没有服务/代理目的地(例如队列/主题)路由它。此路径称为路径。

例如,您的股票应用程序已经得到分析师的一些意见,它将通过应用程序/ Web组件进行处理,然后结果将发布给所有感兴趣/注册的成员以进行特定的股票更新。

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

答案 2 :(得分:5)

Enterprise Integration Patterns可以帮助您了解所有内容是如何组合在一起的。

[更新:]您对另一个答案的后续问题让我意识到您对特定产品感到困惑。这部分是因为实践中的软件倾向于映射到多个概念,部分原因是不同的公司认为它们提供“一切”,而实际上并非如此。

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

服务就是服务。在实现一个EJB时你可能会使用一些EJB(我只提到这个因为某些原因你将它们包含在你的问题中)。

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

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

答案 3 :(得分:3)

端点&amp;路线:信息来自和去往的地方。 Message Queue是一种端点。另一种类型是消息主题。

端点是事物&#39;的逻辑名称,例如PRICE.MSFT,由发布者或消费者应用程序用于从中获取或发送内容。主题向订阅的每个人(一对一或一对多)提供信息,队列将消息传递给获得它的第一个(通常是一对一)。忘记队列,一切都可以用主题完成,主题有几个优点。

面向消息的中间件(MOM):在主题或queus之间传递信息的软件基础架构。它是面向消息的&#39;不是面向分组的&#39;就像TCP一样。因此,每个信息blob都在一个有希望的自我描述的消息中传递。然后,您的MOM的实现为您提供了一个API,您可以在其中执行诸如msg.get之类的操作(&#34; bid&#34;)

JMS和AMQP是MOM规范的示例。 MOM实现是实现这些规范的真正产品: TIBCO EMS,Websphere MQ,MSMQ,Solace以及许多其他人

Apache Camel - 关于如何在此MOM世界中配置工作流的非常有趣的方法。但是更先进的概念。

面向服务的体系结构(SOA),Service Bus / ESB只是以前被称为EAI(企业应用程序集成)的新流行语。它们是关于如何使用“妈妈”以及支付高价顾问的方式的建议。 什么&#39; ESB&#39;添加到MOM的想法是将您的发布商视为&#39;服务&#39;提供服务。换句话说:不要过多考虑消费者现在想要什么。未来可能会有5位消费者,并且该发布商应该提供服务,而不是“创建消费者A想要的信息”。 (一旦您的架构已经发展到5个以上的应用程序,它就会变得更加清晰)。你也应该有一些通用的对象模型,也许是用XML来简化应用程序之间的事情。

骡子 - ESB的一种形式,但它的&#39;不完全是主流。在5年内,大多数中间件操作可能已经完全转移到AMQP或其他东西。

EJB:Sun关于在容器中运行的复杂Java类的想法。希望使应用程序开发更容易。但在许多情况下,它使事情变得更加复杂。一个更好的选择是&#39; Spring&#39; - 但是EJB是关于别的东西(不仅仅是MOM)。它更多的是关于如何开发更大的应用程序(参见IoC模式)。

如果你正在寻找从哪里开始:我建议学习JMS(所有其他MOM都是simliar,而JMS是EJB&s; / Mule的基础......),除非你具有超高性能要求,将消息视为包含XML的TextMessage。大多数工具都可以在该领域使用。或者更简单但不太复杂的是具有键/值对的MapMessage。

答案 4 :(得分:1)

考虑到您的所有要求并将其打包成查询,我发现了一个符合您需求的优秀案例研究:

我继续使用亚马逊的“在本书内搜索”功能,全文搜索了这本书。它涵盖了您所讨论的所有集成案例,看起来是彻底的,并指导您完成整个设计和实施过程。

我很尴尬地声明我没有读过这个我自己,但我强烈建议使用我所做的相同工具,看看它是否符合您的需求,然后才能投资副本。它似乎更简洁,更完整,更有帮助,而不仅仅是将大量不完整的文档强加给你,或者将内容整理成答案。

答案 5 :(得分:1)

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

  • 面向服务的体系结构(SOA)
    SOA提供了一组原则和方法,将现有应用程序集成为松散耦合的单元。从企业集成模式(见下文):“ SOA模糊了集成和分布式应用之间的界限”。
  • 服务总线/ ESB
    ESB是SOA的主要概念,用于减少SOA中应用程序内的依赖关系。而不是每个应用程序连接到ESB的应用程序之间的很多依赖关系。
  • 面向消息的中间件(MOM)
    MOM是用于在分布式系统之间发送和接收消息的基础结构。这用于集成应用程序。在SOA炒作出现之前,MOM是金锤。由于两者都很有用,因此大型集成套件同时提供ESB和MOM(或在其ESB中使用MOM)。
  • 消息队列
    消息队列只是MOM体系结构中的技术细节方面。当消息发送/接收解耦时,消息将存储在队列中,直到收件人准备就绪。
  • Apache Camel
    当这本书Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions上市时,已经创建了一些软件解决方案,为本书中的模式提供了实现。 Apache Camel就是其中之一。 Camel也是Apache ServiceMix的一部分,它也是一个开源的ESB。 FuseSource和Talend正在打包Apache ServiceMix,Apache Camel和Apache Active MQ(MOM)以捆绑商业支持。

  • Mule也是一个开源的ESB和集成平台。
  • 的EJB
    来自维基百科: Enterprise JavaBeans(EJB)是一种用于企业应用程序模块化构建的托管服务器端组件体系结构。这意味着EJB是应用程序中的一个组件,与集成应用程序无关。
  • 终点&amp;路线
    当您使用Apache Camel时,您正在设计端点之间的路由,请参阅tutorial。简而言之,消息通过端点进入/离开您的系统,并在路由定义的流程中处理。
  • JMS
    JMS或Java Message Service是一个带有标准化Java API的面向消息的中间件(MOM)。

答案 6 :(得分:0)

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

WSO2 ESB

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