架构模型图4

基于esb的面向服务架构实施开发的要求

客户端

2、松散耦合

SOA架构的一个特性就是SOA架构中所有服务的具体实现、位置和传输协议对调用者来说都是透明的，之前提出的SOA架构利用企业服务总线技术来实现这一特性。 传统的服务调用方法是客户端直接向服务提供者发出请求。所有服务提供者的服务地址和传输协议都是所有客户端的应用程序需要单独处理的 假设有m个服务客户端，n个服务提供者，那么服务客户端对服务的调用路径最多可达m*n条，这也是点对点交互的典型示例。如果因为业务需求要用新的服务实现替换已有的n个服务，或者发布这个n个服务的服务器地址发生变化，那么将使可能多达m*n条调用路径必须重写。 前文提出的SOA架构中启用了企业服务总线，服务对客户端来说是完全透明的，因为客户端只和服务总线打交道，服务总线将真正的服务提供者的地址、传输协议以及服务的具体实现隐藏起来了。下面是引用企业服务总线前后服务调用的对比，如下图所示：

在面提出的SOA架构中，服务调用者只把SOAP请求发给服务总线，并与服务提供者进行直接、同步的交互，服务总线会把包含结果的SOAP响应传送给服务的调用者。而SOAP协议，正是一种以数据为中心的XML消息格式。 外勤管理软件每个版块有多个子系统，按照上面提出的架构来构造时，子系统将都是由服务构成的。子系统之间的交互是通过服务间的调用来实现的，同时这些服务是松散耦合的，从而实现子系统之间的松耦合，也就实现了整个系统的松耦合。 为了说明随便简单举个例子，比如：某企业某员工创建订单时，需要判断某一仓库中此货物库存否足够，这就产生了库存管理子系统与订单子系统之间的交互，实现此功能有多种方法

服务提供者

如果使用方法一，将使两个子系统变得紧密耦合，使用这种方法的提前是两个子系统处于一个JVM中，有一种情况是当因为业务需要，把其中一个子系统的服务器移到外地，那系统就不能工作

我们仍然假设有m个服务客户端，n个服务提供者，使用服务总线后，服务客户端通过服务总线来对服务进行访问。这时，无论服务提供者发生了什么变化，我们只需要维护发布到服务总线上的n个服务即可，m个服务端的调用代码不需要有任何的变化，同理也适用于服务之间的交互

耦合是指软件组件之间的依赖程度。对于一个SOA架构来说，松散耦合的标准主要有以下几点：1）、异步通信2）、以数据为中心的交互模式3）、动态绑定服务4）、独立于编程语言

实际上，SOA架构的应用绝不会局限于J2EE的技术上，而ESB也不仅仅作为J2EE企业应用的中介，这种架构是各种信息资源整合的架构。所以，有必要对其进行扩展，SOA是独立于技术之上，独立于协议之上，以业务驱动服务，以服务驱动技术的体系架构。企业服务总线的概念就是从面型服务体系架构发展而来的。SOA描述了一种IT基础设施的应用继承模型，其中的软构建集是以一种定义清晰的层次化结构相互耦合，其中，一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。

企业服务总线

1、服务透明化方面

//方法二：//架构中采用的方法：子系统接口以服务的形式发布，子系统间的交互就是服务间的调用，服务被发布到服务总线，服务调用者从服务总线导出服务的WSDL文件，根据WSDL文件内容调用服务public void createOrder(......){// goodsid :货物ID//GoodsServiceLocator、GetGoodsService等是根据从服务总线导出的GoodsService的WSDL文件生成的客户端调用代码GoodsServiceLocator locator= new GoodsServicelocator( );GetGoodsService userService= locator.getGoodsService( );//调用服务对外发布的方法，得到货物当前库存量int inventory=goodsService.getGoods(goodsid).getInventory( );//比较数量。。。。} 方法2中，通过调用服务总线发布的服务来实现子系统间的交互，从而实现服务位置的透明化，同时也摆脱了对技术的依赖，任何服务，不论它是由什么技术开发的，只要把它加入服务总线，都可以被访问。采用这种方法，成功实现了子系统之间的松耦合

引用企业服务总线前后服务调用对比图