之前提过,
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
的时候,只需要关心它的声明就可以了,而不需要关心其具体的实现。
![](https://p-blog.csdn.net/images/p_blog_csdn_net/apusicVK/clip_image001.jpg)
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
流程引擎所引用。
![](https://p-blog.csdn.net/images/p_blog_csdn_net/apusicVK/clip_image002.jpg)