soa设计原则:解析SOA十大设计原则

　    、明确边界 　　通过跨越定义明确边界进行显式消息传递服务得以彼此交互有时候跨越服务边界可能要耗费很大成本这要视地理、信任或执行原因而定边界是指服务公共接口和其内部专用实现的间界线服务边界通过 WSDL 发布可能包括介绍说明特定服务的期望声明

　　 2、服务共享和约和架构不是类

　　服务交互应当只以服务策略、架构和基于合约行为为基础服务合约通常使用 WSDL 定义而服务聚合合约则可以使用 BPEL 定义(进而对聚合每个服务使用 WSDL)服务使用者将依靠服务合约来服务及和服务交互鉴于这种依赖性服务合约必须长期保持稳定在利用 XML 架构 (xsd:any) 和 SOAP 处理模型(可选标头)可扩展性同时合约设计应尽可能明确

　　 3、策略驱动

　　尽管它往往被认为是最不为人所了解原则但对于实现灵活 Web 服务它或许是最有力单纯依靠 WSDL 无法交流某些业务交互要求可以使用策略表达式将结构兼容性(交流内容)和语义兼容性(如何交流消息或者将消息交流给谁)分隔开来

　　 4、自治

　　服务是独立进行部署、版本控制和管理实体开发人员应避免对服务边界的间空间进行假设此空间比边界本身更容易改变

　　 5、采用可传输协议格式而不是API

　　通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另种区别协议(比如MQ)通信因此也许需要在服务提供商和消费者的间建立座异步起动同步运行连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲Java Messaging Service消息服务(JMS)并不是种传输协议,而是组供应商中立(vendor-neutral)通信APIs

　　 6、面向文档

　　消息被构造为“纯文本”XML文档(换句话说数据格式只对XML有意义) 消息通常用于传输业务文档比如购买订单、发票和提单这种交互类型和同步消息排队系统兼容性很好比如MQ Series、MSMQ、JMS、TIBCO、IMS等等

　　 7、松偶合

　　服务的间要求最小依赖性只要求它们的间能够相互知晓

　　 8、符合标准

　　当通过Web服务实现时最原始(基本)面向服务架构(SOA)模型仅仅提供了很低程度上有关可靠性、安全性以及事务管理标准化机制第 2代技术条件和框架如WS-ReliableMessaging规范标准、 WS-Security规范标准和WS-Coordination规范标准 (和WS-AtomicTransaction规范标准和WS-BusinessActivity规范标准相联系)它们试图以工业标准方式定位存在缺陷

　　 9、独立软件Software供应商

　　向SOA转变正在深刻改变了经济现实客户们会期待更合理费用以及不必重新进行投资就能改进业务能力因此独立软件Software供应商没有选择只能使自己业务更加灵活以期让自己客户也变得同样灵活于是面向服务不仅是简单在现有、紧耦合、复杂、不灵活以及非组件化业务功能上添加基于标准接口更重要是为了兑现SOA承诺独立软件Software供应商必须改变他们构建、打包、销售、交付、管理和支持自身产品方式

　　十、元数据驱动

　　开发元数据本身并不是元数据驱动应用本意使用元数据来驱动服务在系统边界传播是个更为正确思路方法

延伸阅读