Apusic_ESB介绍.docVIP

Apusic ESB 下一代的企业集成中间件，让SOA真正落地! 序 您，可能是一家集团企业的CIO，为了维持企业业务正常运转，您可能已经部署了几个，十几个，甚至是几十个不同的IT系统。这些IT系统在运行初期，为提升企业的执行效率发挥了很大的作用，但随着业务内容的不断深入，您发觉，这些业务系统之间是离散的，是孤立的，您渴望将这些系统进行整合，更进一步的，您希望有一种神奇的魔力，不仅能够有效整合遗留系统，新建的IT系统也能够在这种魔力下获得一体化的支持，您渴望你所掌管的IT系统能够真正做到随需应变，按需扩充。 您，可能是一家IT公司的CTO，您所带领的团队正在开发一种新的IT应用，您渴望用SOA理念来指导这个新应用的架构设计，但您又不知如何才能使SOA落地；您被灌输了太多的SCA、SDO、BPEL等等的标准与规范，但您却不知这些标准与规范又该如何运用到具体的项目；您同样希望有一种神奇的魔力，能够让您的团队多年积累下来的业务逻辑形成跨基础架构、跨技术平台的真正可重用的组件库，而这些组件库在流程编排下形成具体的功能模块，解决具体的业务场景。 您，找到问题的解决方案了吗？ Apusic ESB，下一代的企业集成中间件，基于SOA理念，让SOA真正落地。 是这样的吗？现在，让我们一起开始Apusic ESB之旅...... 企业集成软件的发展史 在企业信息化进程的最初，一个应用软件的使用范围可能仅限于某一个部门或某一种业务，由此而导致的情况是：一个大型的企业可能存在多个大小不一且支撑技术不同的应用软件系统，这些系统可能基于不同的编程语言，运行在不同的上，有着不同的系统平台。但随着企业的壮大，业务的发展，个应用软件之间的信息交互也越发频繁，同时，企业与上下游合作伙伴之间，数据共享、流程整合的需求也不断催生，在这样的背景下，企业应用集成软件应运而生。至今为止，企业集成软件的发展，可以分为三个阶段： 基于标准协议的代码定制 种集成方式的缺陷不言而喻：缺乏可靠的数据传输保障；系统毫无弹性可言；数据交换时双方必须同时在线；部署模型是非常复杂混乱的网状结构等等。 基于消息的代码定制 基于消息的异步编程模型，则为企业集成提供了一种新颖的解决方案。传统的消息中间件，能够有效解决数据传输的可靠性、稳定性与安全性，并且，消息提供的异步编程模型，避免了集成双方必须同时在线的问题，于是，人们在原先方式中的数据载体由通过标准协议，换成基于消息，大大提高了数据的可靠性，以及部署上的分布性。但是缺点还是同样明显：路由逻辑和业务逻辑没有分离，系统基本没有扩展性，部署上还是网状结构等等。 集线器模式 集线器模式在基于消息的基础上，引入了“前置机-服务器”的概念，使用一种集线器/插头（hub-and-spoke）的架构，将消息路由信息的管理和维护从前置机迁移到了服务器上，巧妙的把集成逻辑和业务逻辑分离开来，大大增加了系统弹性。由于前置机和服务器之间不再直接通信，每个前置机只通过消息和服务器之间通信，将复杂的网状结构变成了简单的星型结构。 集线器模式在企业集成的过程中取得了很大的成功，但是集线器模式的模型自身存在不足：中央服务器的存在导致部署上无法分布开来，同时，中央服务器承担了太多的工作和责任，往往会带来压力瓶颈以及硬件投资上的巨额付出。随着基于集线器模式的EAI系统的广泛使用，更多的不足逐渐暴露出来： 依然是一种紧密耦合的方式，一方所暴露的业务接口，只能在当前的集成环境下使用，无法提供可复用的业务价值。 业务系统之间的协议都是基于消息的，有时候很难跨越企业的防火墙。 当集成的需求越来越多的时候，不断添加的功能使得集成系统日趋庞大，缺乏灵活性且难于管理。 那么有没有一种更好的架构可以解决这些问题，并且能够在完成企业集成的同时，带来更大的业务价值？ 下一代的企业集成解决方案：Enterprise Service Bus 当人们正在为集线器模式的企业集成架构所表现的不足寻求解决方案时，SOA的思想被提出来了。 划时代的体系思想：SOA SOA（Service-Oriented Architecture），指的是面向服务的架构，意指将软件按照功能设计成一个个独立封装、支持异步处理的服务，这些服务用标准的方式定义接口，并可以通过标准的协议进行调用。重要的一点是，SOA所定义的接口和调用方式是独立于编程语言和运行平台的。 服务和SOA SOA的思想试图定义一个业界都“认可”、都“遵循”的法则，大家都使用同样的方法来进行互通互联，从而实现无界限的“联通”和最大可能的复用。 SOA是一个具有非常意义的体系思想，是所有软件人员的一个梦想：将中间层再进行抽象，通过一个跨技术架构的元数据和业务逻辑，也就是服务，使之成为可跨企业使