mule in action翻译3 : 1.1 企业应用集成方式和面向服务架构

 1.1 企业应用集成方式和面向服务架构

 

    在过去十年左右已经看到了应用集成的复兴。专有的通讯协议栈和封闭的API ，一去不复还。

开放的平台，协议和服务一统江山。更明显的证据是，近年来随着企业、政府组织竞相的公开

数据而暴露越来越多的API。 REST，JSON和轻巧的消息代理成为领头羊，但是，原有的东西

你仍然不能抛弃。这些灵活的新技术仍没解决最终的大问题：如何将这些服务组合成分布式应用程序。

 

    直到 Until Hohpe 和 Woolf’s 开创性的出版《Enterprise Integration Patterns》(addison - wesley,2003年11月),几乎没有方案来解决这些应用集成面临的挑战。后来集成应用程序开发人员终于发明了目录的模式,

但其实现方式还是很少。mule和许多其他开源商业集成框架从中受到启发。现在集成开发人员不必再纠缠于实现方式， 而将精力再次集中在解决方案。

 

 

    和《Enterprise Integration Patterns》同时出现的是面向服务架构。面向服务的架构（SOA），

是一种软件架构风格 ，它认为对之前的应用系统需要提供 设计良好的、统一且规范的方式来进行应用集成。起初SOA由重量级的SOAP来规范体现，最近由广泛采用REST和JSON来重新定义， 在现代软件领域SOA

已无处不在。

 

 

    早期实现SOA的技术多是重量级的集成技术，如SOAP，冗长的XML，以及随着这些技术的发展出现的复杂基础设施和工具。不幸的是进行集成开发是复杂的，且将现有基础设施 “转化”为SOA需要相当长的时间。

许多这类项目的命运是不幸的，本书读者更能体会这点。 

 

 

    SOA 是 Jim Webber（(www.infoq.com/interviews/jim-webber-qcon-london)）引入的一个概念，

他的观点是面向服务的架构中可以引入一个精干，增量和敏捷的方式。我们将在这本书将看到mule

是如何随着轻量消息模式，来缓解将你的应用引入SOA的痛苦。我们将在第7章介绍SOA以及其他的

架构方法。

 

 

 

    有一种原始的集成应用程序方式，但不幸的是这种倾向是非正式的不规范的。 

这往往导致应用的关系如一团乱麻，如所示图1.1。

 

    这种方式下应用直接以“点对点”方式互联。如果应用数量不多，这可能还好。

但是随着集成点的数量增长，疼痛将很快出现。应用程序变成了关键任务， 你的远程系统开始改变。

 

 

《Enterprise Integration Patterns》中描述的一种模式，解决了这个问题 ：消息总线，或一般称为企业服务总线，或ESB。

 如图1.2中所示， ESB提供了一种解决的点至点的集成的问题。

 

 

 基于ESB的架构方式规定要在所有的集成点之间放置一个专用的集成应用程序，称为总线。

 原来点至点的集成变为都只面向总线交互，这样降低了各应用间的耦合度。

 

 

 

    这种解耦是通过协议适配和规范的数据格式来实现的。 

    协议适配是指总线可以采用不同的传输协议进行通信，如HTTP或FTP。

 

    规范的数据格式是一种常见的格式，所有的消息都转化为此格式，在java方面通常是java对象模型或XML模式。这使你在ESB框架集中关注，如安全，审计和路由等，而不需要纠缠于数据格式。这实际是在你的客户端应用和远程应用间添加了个隔离层，客户端可以采用多种数据格式来访问后台服务。同时这提供了灵活性，比如你更换服务算api时，你再也不需要修改每下游应用了，只需要调整ESB就可以了。

 

 

虽然mule通常标榜为一个ESB，值得注意的是，一个ESB是一种架构而不是一个产品。

我们将在第7章讨论Mule的作为ESB的使用。