之前提过，
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
流程引擎所引用。
