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如何保证单点故障问题
如何做到热部署
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐