Apusic ESB特性（下）——面向服务功能特性

之前提过， ESB 应该具有可高度分布部署的能力。那么在应用集成方面， ESB 具有三个最为鲜明的特征：面向服务、面向消息，面向驱动。

在这里还得提提 SOA 。到底什么是 SOA ： SOA 是一个非常伟大的思想，它试图定义一个大家，各个软件厂商各个开发人员甚至于各个自然人，都 “ 认可 ” 的、都 “ 遵循 ” 的法则，大家都使用这样的方法来进行互通互联，从而实现无界限的 “ 联通 ” 和 100% 的复用，解放无效和重复劳动。想象一下，如果这个星球上的人都使用一种语言交流，将是一件多么 “ 可怕 ” 的事情！通天塔将早就已经被修建起来，所有的人都快乐的在天堂生活。

那么根据这个理解，服务本身就是在各种软件的中间件之上的另一层包装，以大家都认可的标准的姿态出现，是一种跨技术架构的元数据和业务逻辑。但是落到技术是处上，什么样的技术封装才能实现 “ 服务 ” 的目的？

Web Service 是现在目前大家都用来表述 “ 服务 ” 这个概念的一个普遍的实现。 Web Service 主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。 Web Service 所使用的是 Internet 上统一、开放的标准，如 HTTP 、 XML 、 SOAP （简单对象访问协议）、 WSDL 等，所以 Web Service 可以在任何支持这些标准的环境（ Windows 、 Linux 、 AIX 、 AS400 等）中使用。 Web Service 将一个业务方法的声明和实现进行了剥离，声明部分基于国际标准的协议，而实现部分基于具体的平台和具体的编程语言。但是用户在调用 Web Service 的时候，只需要关心它的声明就可以了，而不需要关心其具体的实现。

Apusic ESB 就是面对 Web Service 方式的服务的，借助于 Web Service 的包容性的结构，解决包容性的结构解决 M 种调用协议和 N 种数据格式相互组合出现 M*N 中场景的问题。 Apusic ESB 提供了一个实现 UDDI 标准的服务仓库，实现个体、企业将自身的 Web Service 的相关 “ 地址 ” 和业务信息添加到服务仓库中，通过根据业务请求查找和发现 Web Service 的方式，使一个请求者能够从服务仓库中拿到自己想要的，能够完成自身业务需求的 Web Service 。

借助这样的方式， Apusic ESB 实现了 ESB 的面向服务的普遍性，基于标准等特性。同时 Apusic ESB 的设计，使得在 Apusic ESB 服务仓库中的服务是一个无状态的原子单元，也就意味着，服务本身不关心数据从哪里来，自己处理完数据之后，将发送到哪里。服务只完成一件事情：自总线中获取数据，完成业务功能。

那么在数据中介方面，在 Apusic ESB 中，所有传输的消息都会被封装成统一的 XML 格式，在服务和服务之间传输的时候，基于 Apusic 消息中间件，保障数据的可靠、安全、稳定传输。同时，当数据从一个服务传输到另一个服务，将要被第二个服务消费的时候，可以通过标准的 XSLT 来进行数据的转换。

同时， Apusic ESB 通过一个符合 BPEL 标准的流程引擎，实现服务和服务之间的串联，使不同部门、不同企业的服务，根据业务场景有机的结合起来，完成集成的业务功能。同时，流程引擎的引入，也使得在 SOA 的体系下，业务逻辑和功能逻辑分离开来，使得业务系统具备更好的扩展性。

另外，对于遗留系统， Apusic ESB 提供了多样的适配器，来完成遗留系统和总线之间的介入。适配器也是以 Web Service 的形式描述的，并且也可以注册到 Apusic ESB 服务仓库，并且被 Apusic ESB 流程引擎所引用。