esb集成总线_与ESB的演进式集成

最新推荐文章于 2024-07-08 16:21:46 发布

cunfu6353

最新推荐文章于 2024-07-08 16:21:46 发布

阅读量1.8k

点赞数

文章标签：大数据编程语言人工智能 java python

原文链接：https://www.infoq.com/articles/Evolutionary-integration/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

版权

esb集成总线

介绍

如果我们仔细研究给定组织中的大多数应用程序，则集成是临时完成的。随着时间的流逝和应用程序组合的增加，系统和应用程序之间的互连开始看起来像珊瑚礁：内部坚硬，外部有些生命。弄混紧密耦合的积分点可能会产生一系列副作用，从而导致没人敢纠正问题的根本原因。通常，人们只是通过在高度耦合的系统和应用程序的珊瑚礁上添加新层来修复症状。

为了避免这种情况，我们需要改变思维方式。我们需要接受IT系统的发展，并且这些系统在组织中的使用方式也会发生变化。这只能通过选择与其IT设施的发展相辅相成的集成策略来实现。

本系列文章将向您展示如何使用著名的集成模式和开源集成平台Mule来实现这一目标。

案子

Kjetil和Rune厌倦了IT专业人员，因此决定辞职并开始在挪威的高山度假胜地Trysil从事滑雪运动。

他们以某种方式谋生，并决定创建PowderAlert，这是一个在线应用程序，可为其他滑雪狂者提供有用的滑雪信息。

PowderAlert＃1

PowderAlert的第一个版本非常简单。该应用程序的主要目标是测试Kjetil和Rune的商业理念的主要原理。根据要求提供滑雪信息，并以电子邮件作为通信渠道。如何实际获得信息报酬仍然是一个未解决的问题。

下面的图1描述了应用程序的流程。

图1：PowderAlert的用法和主要成分

最终用户将包含关键字“ powder”的电子邮件发送到特定的电子邮件地址。
PowderAlert应用程序以固定的时间间隔轮询电子邮件帐户，并在收件箱中弹出邮件，并存储用户的邮件地址。
PowderAlert从公共站点收集有用的滑雪信息。滑雪信息将作为电子邮件发送到PowderAlert应用程序。
PowderAlert定期提取包含滑雪信息的电子邮件。
包含该信息的电子邮件将发送回用户。
最终谁会读。

当前实施

在特吕西尔（Trysil）著名的后滑雪场所'Laaven'举行了漫长的聚会之后，小雪人决定编写一个快速又肮脏的PowderAlert应用程序。由于他们主要专注于巡查炸药而不是进行举报，因此他们不得不寻找某种方式来自动提供这些信息。他们在网上搜索了提供此类信息的网站，最后找到了名为Skiinfo的挪威网站。 Skiinfo提供粉末警报电子邮件和SMS消息，以及每日降雪深度信息。

Snowdesdes开始使用Spring框架在真正简单的应用程序上进行破解。 Spring很好地支持通过JavaMailSender和SimpleMailMessage发送电子邮件。他们还需要一个重量轻的数据库来存储用户，因此决定从Hypersonic SQL开始。 SQL肯定不是最喜欢的语言之一，因此它们将Hibernate和Annotations混合在一起。也就是说，如果没有Java 5的新语言功能，就不可能完成2006年开发的Java程序。

当然，他们还想深入研究Maven 2，并决定根据最佳实践和标准来设置他们的项目。这些实践之一当然是“测试驱动开发”，当邮件服务器成为应用程序中的中心点时，这很难在营员中离线进行。傻瓜来救援！ Dumbster是一种非常简单的伪造SMTP服务器，专门用于单元测试。

该应用程序包含两个模块，核心和Web。核心包含域模型和所有用于轮询邮件服务器，查询数据库以及向吸毒者发送电子邮件的服务。该Web部件主要由处理轮询和用户界面的自举servlet组成。

下图显示了PowderAlert v.1的主要功能。

图2：主要用例PowderAlert＃1

如图2所示，参与的参与者是订阅Powder Alerts，邮件服务器的用户，最后是向PowderAlert提供滑雪信息的Ski Info网站。

为简单起见，PowderAlert包含四个用例：

注册粉末警报用户
发送火药警报
在位置获取粉末警报用户
接收粉末警报

粉末警报用例

上面列出的Powder Alert用例值得详细描述系统的实际工作方式。我们使用了一种系统序列图来对此进行记录。实际的UML表示法不是很正确，因此请Craig Larman先生，这次不要以超过二十根的鞭打惩罚我们，因为这违反了您出色的《应用UML和模式》一书中的准则。

图3：注册过程

上面的图3显示了详细说明注册过程的序列图。这里没有什么令人兴奋的，但值得一提的是用户向感兴趣的滑雪地点注册。从滑雪信息网站收到粉末警报后，将使用此信息。

接收粉末警报的详细信息如下图4所示。

图4：发送粉末警报

粉末警报系统从每个位置的外部系统接收粉末信息。如图4所示，检索了在给定位置预订粉末信息的用户，并将滑雪信息作为粉末警报转发。

剩下的两个用例非常简单：“在现场获取粉末警报用户”和“接收粉末警报”。我们或多或少添加了时序图（图5和图6 ）以完成图片。

图5：从滑雪信息中检索粉末警报

图6：让用户订阅粉末位置

编码

域类

首先，系统需要一些域类，唯一明显的域类是USER和POWDERPLACE。但是，还需要一些帮助程序来传输数据，一种用于来自用户的订阅电子邮件，另一种用于Skiinfo警报电子邮件。目前，info.powderalert.domain包仅包含实际的域类，而其他类则保留在基础结构包中，稍后再介绍。

@Entity
 @Table(name="user_table")
 public class User implements Serializable {
     @Id @GeneratedValue(strategy=GenerationType.AUTO)
     @Column(name="userId")
     private Long id;
     private String email;
     private String firstName;
     private String lastName;
     @ManyToMany (fetch=FetchType.EAGER)
     private List<powderplace> powderPlaces;
     .. } @Entity
 @Table(name="powderplace_table")
 public class PowderPlace {
     @Id @GeneratedValue(strategy= GenerationType.AUTO)
     @Column( name="powderPlaceId")
     private Long id;
     private String name;
     private List<user> users;
     .. }

服务

分析了这些图之后，确定了四个服务。

邮件服务

负责与邮件服务器之间收发电子邮件，并将其转换为其他服务的可读POJO。

public interface MailService {
     void sendMail(User user, MailMessage message);
     List<mailmessage> getMail();
 }

管理员服务

它将管理功能添加到系统，负责添加，删除和列出用户和PowderPlaces。

public interface AdminService {
      User addUser(User user);
      User modifyUser(User user);
      User getUser(Long id);
      User getUser(String email);
      boolean removeUser(User user);
      List getUsers();
       List<PowderPlace> listPowderPlaces();
      void addPowderPlace(PowderPlace place);
      PowderPlace getPowderPlace(Long id);
      PowderPlace getPowderPlace(String name);
      void removePowderPlace(PowderPlace place);
      void modifyPowderPlace(PowderPlace place);
 }

PowderAlertService

它负责将Powderalert发送给注册用户。

public interface PowderAlertService {
      void powderAlert(PowderPlace place);
}

用户服务

负责系统中的警报订阅。

public interface UserService {
   void subscribe(User user);
      void unsubscribe(User user);
}

资料存取

好吧，不幸的是，数据必须存储起来总是很麻烦。幸运的是，Spring，Hibernate和Annotations使它变得更容易，您可能已经注意到带注释的域类;）。当前有两种DA类，一种用于处理用户，另一种用于粉末场所。

public interface UserDAO {
      void addUser(User user);
      void updateUser(User user);
      void removeUser(User user);
      User getUser(Long id);
      User getUser(String email);
      List<user> getUsers();
      List<user> getUsers(String location);
 } public interface PowderPlaceDAO {
      void addPowderPlace(PowderPlace place);
      void updatePowderPlace(PowderPlace place);
      void removePowderPlace(PowderPlace place);
      PowderPlace getPowderPlace(Long id);
      PowderPlace getPowderPlace(String name);
      List<PowderPlace> getPowderPlaces();
 }

基础架构组件

Spring正在帮助我们以及一些基础设施，例如接线，查找以及对Java Mail API的更轻松访问。但是，我们仍然需要大量代码才能使工作正常。例如，我们需要一个Servlet引导整个过程，一些计时器用来轮询邮件服务器，并且如前所述，在将电子邮件转换为POJO时，我们需要一些数据帮助程序类，最后需要一些属性类来存储诸如用户名和密码之类的杂项。目前，这些组件已被省略，并提供给您下载（请参阅参考资料部分）。上面列出的所有接口的实现也是如此。

珊瑚礁的第一个G

PowderAlert＃1没什么错。它组织得很好，它使用Spring进行布线，使用了一些设计模式等。因此，当我们查看Powder Alert＃1的分层时，它是一个不错的应用程序。但是，在与其他系统的集成，不断发展的新服务以及扩展规模方面变得更加灵活时，它似乎就像是珊瑚礁的开端。

这是非常典型的情况，我们已经在许多正在与其他系统进行某种集成的项目中发现这种情况。涵盖系统专栏的能力非常好，但是由于分布式计算和集成而导致的必需资源不存在或被忽略。

为了能够创建能够应对不断变化的需求和不断发展的服务组合的应用程序，我们需要一个平台或工具作为可以应对这些挑战的基础。

更准确地说，最好使用工具集，更像LeathermanTM 。让我们看看我们的两位英雄可以从Afterski学到什么。

在Afterski与Ross会面

女士们，先生们，让我们自豪地介绍... ule子！

我们一直在寻找IT版本的LeathermaTM工具，我们做到了！我们掌握了由Mule项目实现的OpenSource Enterprise Service Bus。

Mule是基于ESB架构思想的消息传递平台。简而言之，它是一种轻量级消息传递框架，它使用您现有的技术基础结构（Jms，Web服务，电子邮件等）来构建复合服务应用程序。

Mule设计的一个关键特征是要尽可能灵活和可扩展，可以将其视为用于集成的Spring框架。

Mule框架提供了高度可扩展的服务环境，您可以在其中部署业务组件。它可以透明地管理组件之间的所有交互，无论它们是存在于同一VM中还是通过Internet存在，而与所使用的基础传输无关。它是非侵入性的，这意味着任何对象都可以由容器管理，并且不需要扩展任何类或实现任何接口。您的服务和逻辑不会被感染，也不会遭受框架锁定。这意味着它非常适合在开发过程中进行测试和缩减规模。

这就是我们所说的环境透明性 ，并且是Mule的主要功能之一。它使snowdudes能够在上山的路上在笔记本电脑上开发整个应用程序，并且当他们最终上网时，只需将新开发的代码放到服务器上，更改部署配置并在需要时在分布式环境中运行即可。

框架的其他核心功能是JBI集成，WebService集成（使用Axis，Glue或XFire），Spring框架集成，基于SEDA的处理模型，REST支持，包括XA支持的声明性和编程事务支持，对路由的端到端支持，事件的传输和转换。

在Mule网站上可以找到完整的功能列表和大量入门材料。

M子

好的，我们拥有大量的工具，但是现在我们需要的是某种用户手册，实际上可以告诉我们哪种工具最适合工作。我们需要知道，从字面上看，我们并不是用大锤锤打钉子。

像其他计算机科学学科一样，以前有人遇到过同样的挑战，并且已经以模式的形式收集了这些最佳实践，这也就不足为奇了。因此，为了帮助我们解决这些集成问题，我们提供了（屏住呼吸） 集成模式 。

如果将Gregor Hohpe的书“ Enterprise Integration Patterns”的内容与图7所示的Mule体系结构概述进行比较，我们实际上可以识别出所描述的许多模式。强烈建议您阅读本书。真的很好我们认为有义务对这本书提出一点警告；它不适合睡前阅读，因为它不会让您睡着。

另一个非常有用的资源是Gregor的企业集成模式（EIP）网站。它列出了本书中的所有模式，以及其他有用的信息，例如博客和文章。

图7：架构概述

无论如何，回到Mule架构和企业集成模式的使用。在“架构概述”图的两端，我们在这两个“应用程序”气泡之间排列了集成模式。

首先，我们有一个叫做“频道”的东西。该组件的主要目的是在两个端点之间通信数据，我们可以在Message Channel的化身中的Gregor站点上找到使用的模式。

对于那些可以横向阅读的人，下一个出现的模式隐藏在“消息接收器”名称中。消息接收器用于从应用程序读取或接收数据。在Mule中，Receiver只是传输提供程序的一个元素，而Mule提供许多传输，例如jms，soap，http，tcp，xmpp，smtp，文件等。

在消息接收器的情况下，相关的EIP是消息端点。消息端点的主要目的是将应用程序连接到消息传递通道。因此，消息端点模式封装了来自应用程序的消息传递系统，并针对特定应用程序的界面定制了通用消息传递API。通过执行这种封装，我们实现了消息传输的透明性。消息端点是专用的通道适配器，已针对其定制开发并集成到其应用程序中。

接下来出现的是“连接器”。消息接收器与此组件耦合，以便能够以行走和交谈的M子方式进行通信。该连接在一端接收通道特定的请求，并在另一端通过UMOEvents连接到Mule组件。

同样，对于那些可以横向阅读的人，我们获得了“变形金刚”框。在这种情况下，相关的EIP是消息转换器。消息转换器的主要目的是使使用不同数据格式的系统能够使用消息传递相互通信。如果您正在研究翻译消息有效负载，请查看Gregor网站上的“消息转换简介” 。通过阅读本介绍获得的知识可作为问题领域的良好入门。

回到M子，变形金刚用于将消息或事件的有效负载与不同类型之间进行转换。 Mule没有定义标准消息格式（尽管Mule可以支持标准业务流程定义消息类型）。因此，开箱即用的转换是“类型转换”，例如JMS消息到对象，标准Xml转换器和标准协议转换器。数据转换对应用程序非常主观，Mule提供了一个简单而强大的转换框架。

接下来的是“入站路由器”。在这里，我们有另一个企业集成模式实例；消息路由器。消息路由器的主要目的是消耗一个消息通道中的消息，然后根据一组条件将它们重新发布到不同的消息通道中。

当涉及到消息路由器，入站路由器的具体实现时，它可以用于控制和操作组件接收的事件。通常，入站路由器可用于过滤传入事件，在收到传入事件或重新排序事件时对其进行汇总。

现在，我们已经或多或少地完成了所有的秘密握手，以期达到M子的灵魂： UMO组件 。

为确保UMO组件获得适当的尊重（嘿，我们在谈论某人的灵魂...），它拥有自己的标题。它来了：

UMO组件

Mule体系结构的核心是单个自治组件，这些组件可以进行交互而不受数据源，传输或传递的限制。这些组件称为UMO组件，可以安排为以各种方式相互配合。可以将这些组件配置为接受许多不同来源的数据，并将数据发送回这些来源。

图8：UMO组件

上面指定的“ UMO Impl”实际上是指一个对象。该对象可以是任何东西，JavaBean，EJB或其他框架中的组件。这是您的客户端代码，实际上对收到的事件有作用。 Mule对您的对象没有任何限制，除非直接由Mule配置，它必须具有默认构造函数（如果通过Spring或Pico配置，则Mule对其管理的对象不施加任何约定）。

很明显，UMO组件是功能强大且灵活的东西。真的很像孩子。充满活力，创造力和速度...想像一下，您在工作时必须把孩子带到装满17世纪威尼斯玻璃杯的商店里。没有监督。猜猜那时您会有点紧张...因此，作为孩子们的UMO组件，幼儿园可能是个好主意。 Mule容器是UMO组件的幼儿园，保姆是Mule Manager和The Model 。它们显示在下面的图9中。 ule子管理器会确保所有UMO组件都在那里共享资源，并确保它们之间不会发生争斗。

图9：Mule服务器组件

在这两个保姆中，M子经理的行为就像首席保姆。它管理幼儿园的进行方式，每个部门有多少个孩子，营业时间等。以Mule而言，Mule Manager管理该模型的所有核心服务的配置以及它再次管理的组件。哇，伙计们！

我们一定不要忘记the子幼儿园的另一个保姆， 模特儿 。该模型每天与我们的UMO孩子打交道。它可以安慰他们，喂养他们，保护他们免受幼儿园周围的敌对环境的影响，并确保每个UMO孩子都在玩平等游戏。

该模型具有三种控制机制来确定Mule如何与其UMO孩子互动。第一个控制机制是入口点解析器 。入口点解析器用于确定在接收到用于其消耗的事件时在UMO组件上调用哪种方法。

生命周期适配器是Mule模型使用的第二种控制机制。它负责将m子组件的生命周期映射到基础组件。

作为最后一种控制机制，我们获得了组件池工厂 。该机制负责为给定的UMO组件创建适当的组件池。因此，我们的UMO孩子的部门...

好的！支持我们的两个懒惰英雄。他们应如何以及在何处将Mule应用于PowderAlert应用程序？

向M子的转变

图10：ule子的PowderAlert，第一个版本

上面的图10显示了简化版本的PowderAlert在Mule服装中的外观。在此版本中，我们将Mule中的VM选项用作一种简单的通信策略。尚无消息传递...。本系列后面的文章还将介绍消息传递。

因此，要解释如何将Mule应用于PowderAlert，我们需要仔细研究构成应用程序的体系结构和组件。

最初，您需要确定应用程序提供和使用的服务，以及这些服务可以归类为外部还是内部。进行此练习的原理是确定如何将特定服务集成到Mule中的可用选项。

在这种情况下，服务的分类确定可以在多大程度上更改体系结构中的服务。规模的一端，我们拥有您自己开发的内部服务 ，可以对其进行更改而不会影响其他服务。另一个极端是外部服务具有给定的接口，这些接口必须按原样接受，而且绝对不可能更改。

通过将此定义应用于Mule，可以笼统地说，内部服务比外部服务具有更多的如何将给定服务与Mule集成的集成选项。因此，内部服务可以与Mule紧密集成在一起，如果您填写正确的申请表，它很可能是Mule幼儿园中的UMO孩子！

好的！如果我们退后一步，再看一下上面的图1 ，一般来说，我们可以将PowderAlert应用程序分为三个粒度过程服务：

邮件服务器
SkiInfo网站
PowderAlert核心服务

我们对邮件服务器和SkiInfo网站没有任何影响。他们说话和走路的方式是固定的。因此，它们可以被归类为外部服务 ；因此，与Mule进行非常紧密的集成并不能真正满足我们的需求。我们需要可以连接到服务接口的东西，并且能够将有效负载从特定于组件的信息元素转换为UMO信息对象。

如果我们仔细看一下上面的图7 ，则Endpoint组件是候选者，它是将邮件服务器和SkiInfo站点集成到Mule的候选对象。如图所示，SkiInfo站点通过发送电子邮件与PowderAlert进行通信，因此只需要一个传输即可处理与PowderAlert用户和SkiInfo站点的通信。在这种情况下，我们有一个技术集成点（Email），但是有效载荷中的语义对于SkiInfo和PowderAlert消息是不同的。这将由两个不同的电子邮件终结点处理，每个终结点上都有Transformers ，它们负责将给定的SMTP消息转换为相应的UMOEvent对象。

左边是PowderAlert核心服务集（PowderAlertService和UserService）。这是应用程序中的实际业务逻辑，并且由于服务是由滑雪者自己开发的，因此有可能更改服务。因此，PowderAlert可以分类为一组内部服务，并且可以确保我们可以训练该组件实际上是UMO的孩子。您会知道擦鼻子，摆脱麻烦，学习ule子歌曲等等等，然后我们可以将它们送到to子幼儿园，供by子保姆看。

然后，我们剩下以下任务：

创建Mule端点，连接邮件服务器。
将PowderAlert核心服务转换为真正的UMO组件。
创建转换器将电子邮件转换为适当的UMOEvent对象。

创建端点

创造？配置将是正确的术语。由于Mule具有所有这些出色的即用型端点，因此我们仅需深入研究文档并开始从那里进行复制。

在PowderAlert 1.0中，我们已经创建了两个邮件帐户，一个用于希望在给定粉末位置注册警报的用户，另一个用于从Skiinfo网站接收信息的用户。在第一个版本中使用commons-net库轮询邮件服务器是很容易的，它需要很多代码。输入Mule的POP3端点！

现在我们可以扔掉所有代码，并用以下配置替换它：

<端点地址=“ pop3：// subscribe：password@powderalert.info”>

由于我们必须通过电子邮件发送帐户，因此如果该端点需要两个实例，则唯一的区别是URI中的用户名。

至于发送电子邮件，我们使用Spring提供的功能很容易，但是确实需要一些代码和一些配置。我们也将其丢弃，并替换为：

<端点地址=“ smtp：// powderman：password@powderalert.info”>

端点就是这样！现在，我们开始研究已经在第一个版本中编码的服务。而且如前所述，我们有一些很强的候选人竞选UMO头衔。

将PowderAlert核心服务发送到幼儿园

当查看第一个版本时，我们看到两个服务在应用程序中是真正的工人。

处理用户注册的UserService
PowderAlertService将警报发送给用户

这些将是我们的UMO。听起来这是一个漫长的过程，将这些服务转换为真正的Mule UMO。不挂断！ UMO又是什么？可能是普通的JavaBean，不是吗？我们将看一下实现：

PowderAlertService：

public class PowderAlertServiceImpl implements PowderAlertService {
     ...(getters/setters)...
     public void powderAlert(PowderPlace place) {
         List<user> users = userDAO.getUsers(place.getName())
         for (User u : users) {
             MailMessage msg = new PowderAlertMessage();
             msg.setBody("Powder alert! "+ place.getName() 
              + "has " + place.getCurrentSnowDepth() 
             + " of FRESH snow!!!");
             mailService.sendMail(u, msg);
         }
     }

UserService：

public class UserServiceImpl implements UserService {
     ..(getters/setters)..
     public void subscribe(User user) {
         // lookup powderplace
         String place = user.getPowderPlaces().get(0).getName();
         PowderPlace pp = powderPlaceDAO.getPowderPlace(place);
         //check if user exist, in that case update user
         User u = userDAO.getUser(user.getEmail());
         if (null != u) {
             u.getPowderPlaces().add(pp);
             userDAO.updateUser(u);
         } else {
             List<PowderPlace> pps = new 
             ArrayList<PowderPlace>();
             pps.add(pp);
             user.setPowderPlaces(pps);
             userDAO.addUser(user);
         }
     }
 }

这些服务是完美的UMO，我们实际上可以按原样使用它们，我们唯一需要做的就是添加一些转换器，将电子邮件转换为服务可以理解的域对象。首先，我们将看一下整个配置，以了解其工作原理。

<mule-configuration id="PowderAlert" version="1.0">
   <transformers>
         <transformer name="PowderAlarmToPowderAlert"
className="info.powderalert.mule.PowderAlarmToPowderAlert"
             returnClass="info.powderalert.domain.PowderAlert"/>
         <transformer name="SubscriptionMailToUser" 
className="info.powderalert.mule.SubscriptionMailToUser"
             returnClass="info.powderalert.domain.User"/>
  </transformers>
    	<!--   The Mule model initialises and manages your UMO components -->
     <model name="PowderUMO">
         <mule-descriptor name="PowderAlertUMO" 
implementation="info.powderalert.service.impl.PowderAlertServiceImpl">
             <inbound-router>
                 <endpoint address="pop3://alert:password@powderalert.info" 
transformers="SkiinfoAlertToPowderAlarm"/>
             </inbound-router>
             <outbound-router>
                 <router 
className="org.mule.routing.outbound.OutboundPassThroughRouter">
    <endpoint address="smtp://powderman:password@powderalert.info" 
 	transformers="org.mule.providers.email.transformers.ObjectToMimeMessage"/>
                 </router>
             </outbound-router>
         </mule-descriptor>
          <mule-descriptor name="UserUMO" 
implementation="info.powderalert.service.impl.UserServiceImpl">
             <inbound-router>
               <endpoint address="pop3://subscribe:password@powderalert.info"
 transformers="SubscriptionMessageToUser"/>
             </inbound-router>
         </mule-descriptor>
     </model>
 </mule-configuration>

这是配置的图形表示。该图形是通过随“ Mule”分布一起提供的“ Config grapher”生成的。

转换器未在图中显示，但是如果您查看XML中的<transformers>部分，则会看到我们定义了两个转换器：

PowderAlarmToPowderAlert
SubscriptionMailToUser

名称很容易解释。两个转换器都从POP3端点接收邮件消息，并将它们转换为再次定义的UMO接收的域对象。

对于SMTP终结点，我们使用提供的ObjectToMimeMessage转换器来转换我们的消息，以便可以由终结点发送它。

结语

在本文中，我们认为进行点对点集成最终将创建计算机化的珊瑚礁化身。内部坚硬，外面有些生命。最终将不可能改变不同的积分点，而不会带来不可预见的副作用。

为了说明这一点，我们介绍了一个简单的应用程序PowderAlert，其第一个版本设计得很好。但是，正如本文所示，该应用程序的体系结构还不够灵活，无法应对与新集成点和扩展有关的未来。

为了应对这些挑战，我们引入了Mule，它是一个基于ESB架构思想的消息传递平台。简而言之，这是一个轻量级的消息传递框架，旨在尽可能灵活和可扩展。 Mule可以看作是Spring的集成框架。

本文使用Mule使与其他系统的集成对主要应用程序PowderAlert透明。这样，可以与PowderAlert应用程序本身产生最小影响的新系统集成。

在下一篇文章中，我们将详细研究如何使用Mule来扩展应用程序，以粉末状极客的形式处理更多的请求，这些信息需要更新的降雪信息，以及由于需要对其他分销渠道（例如SMS）的支持，其中。

下一篇文章还将介绍Mule IDE，这是ESB繁华世界的一种令人愉快的香料。

代码免责声明

您可能已经注意到，此处描述的代码中存在一些漏洞，请尝试着重于概念而非实际代码，它仅作为参考。您将很快有机会下载代码并将其拆开。

资源资源

翻译自: https://www.infoq.com/articles/Evolutionary-integration/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

esb集成总线

cunfu6353

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
esb集成总线_与ESB的演进式集成

esb集成总线介绍如果我们仔细研究给定组织中的大多数应用程序，则集成是临时完成的。随着时间的流逝和应用程序组合的增加，系统和应用程序之间的互连开始看起来像珊瑚礁：内部坚硬，外部有些生命。弄混紧密耦合的积分点可能会产生一系列副作用，从而导致没人敢纠正问题的根本原因。通常，人们只是通过在高度耦合的系统和应用程序的珊瑚礁上添加新层来修复症状。为了避免这种情况，我们需要改变思维方式。...
复制链接

扫一扫