集成ESB实现SOA

soa初步设想：
  服务消费者，服务提供者， 服务注册中心（UDDI模型）。由于UDDI模型过于复杂，而服务提供者与消费者点对点的进行协作依赖性大大增强，因此产生演变。
soa演进：
   服务代理 -- ESB
   基于ESB总线，使得服务请求者统一入口，而ESB管理服务，使得耦合降低，由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改。

目前能想到的方案：
    使用esb（初步想法是mule的免费版本），进行路由，编排，转换等工作。
    将端点地址与命名、组织、版本等配置在DB。
    每个端点编排或者代理一个现有的webservice
   
    服务消费者访问端点地址，访问传输日志保存在ESB db中
    ESB进入端点后，查找服务注册表来确定服务地址
    通过服务地址可以决定动态访问哪个已经配置或者代理在ESB的服务
   

所以开发分两部分。
1.ESB中配置 需要代理的webservice，并规约address（包括仅代理的服务或者是经过编排的服务）
2.将代理的webservice信息配置在路由表中
3.服务消费者访问统一入口，请求头部信息带有服务名称或者服务编号类似的字段
4.ESB配置DB查询路由表，查找服务地址等内容。如不存在，访问失败。
5.查询到服务后进行调用。
6.返回payload
7.记录调用日志

再进一步思考：

是否可以通过调用日志记录，来分析各个服务的稳定性？
如何测试服务连通性并且及时预警
是否可以将所要进行代理的服务相关配置也通过DB 进行动态的管理

服务的版本如何控制（如部分系统需要调用1.0，而其他系统需要调用服务的2.0）
服务调用失败如何进行重新连接？


如何对服务进行负载均衡？
esb如何保证单点故障问题

如何做到热部署

----------------------------------------------------------------
关于治理服务又看了一天
觉得简单的配置不能满足治理需求

首先应该对服务版本进行管理
对服务依赖管理
对服务组织机构管理
对服务生命周期进行管理

所以需要一个基于UDDI的服务注册中心来治理服务


疑问
发布一个服务之时， 一定也是需要在ESB进行配置后， 将暴露的服务地址注册到服务中心的。
因为如果做到动态注册发布服务，ESB不做任何配置，实在想不出来怎么做到，除非修改源码。



------------------------------------------------------------------
最新调研想法

SOA =  服务 + ESB + 治理

1.服务治理： 服务的注册，发布，生命周期管理，依赖管理，监控等

2.ESB ：服务编排， 服务协议转换， 服务路由，加工等


ESB与服务注册中心的关联
使用ESB 代理已经注册的服务，使用proxy模式通过请求消息获取的UUID动态查找服务地址信息，进而暴露出代理服务地址。

开发流程概要：

审核需要不需要开发新的服务

服务提供方开发新服务

服务注册中心 注册服务相关信息 可以通过WSDL地址获取相关信息。填写组织结构，版本，描述等内容。具体参考http://www.doc88.com/p-599934666516.html。

ESB入口代理服务，服务消费者统一访问入口，通过传递的消息中的服务UUID， 到服务注册库查找对应的服务， 注意版本与服务状态（是否有效）。

如果需要服务组合，那就在服务中心注册一个新的服务， 使用ESB编排成为新的服务。在注册中心填写服务信息。仍然使用ESB服务代理来调用。

可以开发几套协议作为入口代理，如http，soap，等
也可以开发几套最终数据传输格式 如xml  json等。