SOA架构十大设计原则 服务共享和约架构.txt

SOA架构十大设计原则 服务共享和约架构[1] 　作者：金笛　来源：支点网　2008年8月13日　发表评论　进入社区 　　日前国外网站报道介绍了面向服务架构(SOA)的基本原则，提出了公共接口与内部实现要有明确界限等原则。虽然这些原则并不是绝对的真理，但可作为一个应用开发参考。 　　一、明确的边界 　　通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时候，跨越服务边界可能要耗费很大的成本，这要视地理、信任或执行因素而定。边界是指服务的公共接口与其内部专用实现之间的界线。服务的边界通过 WSDL 发布，可能包括说明特定服务之期望的声明。 　　二、服务共享和约和架构 　　服务交互应当只以服务的策略、架构和基于合约的行为为基础。服务的合约通常使用 WSDL 定义，而服务聚合的合约则可以使用 BPEL 定义(进而，对聚合的每个服务使用 WSDL)。服务使用者将依靠服务的合约来调用服务及与服务交互。鉴于这种依赖性，服务合约必须长期保持稳定。在利用 XML 架构 (xsd:any) 和 SOAP 处理模型(可选标头)的可扩展性的同时，合约的设计应尽可能明确。 三、策略驱动 　　尽管它往往被认为是最不为人所了解的原则，但对于实现灵活的 Web 服务，它或许是最有力的。单纯依靠 WSDL 无法交流某些业务交互要求。可以使用策略表达式将结构兼容性(交流的内容)与语义兼容性(如何交流消息或者将消息交流给谁)分隔开来。 　　四、自治 　　服务是独立进行部署、版本控制和管理的实体。开发人员应避免对服务边界之间的空间进行假设，因为此空间比边界本身更容易改变。 　　五、采用可传输的协议格式，而不是API 　　通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。因此，也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲，Java Messaging Service消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。 六、面向文档 　　消息被构造为“纯文本的”XML文档(换句话说，数据的格式只对XML有意义)。 消息通常用于传输业务文档，比如购买订单、发票和提单。这种交互类型与同步消息排队系统的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。 　　七、松耦合 　　服务之间要求最小的依赖性，只要求它们之间能够相互知晓。 　　八、符合标准 　　当通过Web的服务实现时，最原始的(基本的)面向服务的架构(SOA)的模型仅仅提供了很低程度上的关于可靠性、安全性以及事务管理的标准化机制。第二代的技术条件和框架，如WS-ReliableMessaging规范、 WS-Security规范和WS-Coordination规范 (与WS-AtomicTransaction规范和WS-BusinessActivity规范相联系)，它们试图以工业标准的方式定位存在的缺陷。 九、独立软件供应商 　　向SOA的转变正在深刻改变了经济现实。客户们会期待更合理的费用以及不必重新进行投资就能改进业务的能力。因此，独立软件供应商没有选择，只能使自己的业务更加灵活，以期让自己的客户也变得同样灵活。于是，面向服务不仅是简单的在现有的、紧耦合的、复杂的、不灵活的以及非组件化的业务功能上添加基于标准的接口。更重要的是，为了兑现SOA的承诺，独立软件供应商必须改变他们构建、打包、销售、交付、管理和支持自身产品的方式。 　　十、元数据驱动 　　开发元数据本身并不是元数据驱动应用程序的本意。使用元数据来驱动服务在系统边界的传播是一个更为正确的方法