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

 五、采用可传输的协议格式，而不是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的承诺，独立软件供应商必须改变他们构建、打包、销售、交付、管理和支持自身产品的方式。

　　十、元数据驱动

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