无状态的服务设计

    服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件（比如会话密钥）。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。

    这里有一个定义会话的错误方法的示例：

　    ﹡Requester: “What is Bruce’s checking account balance?"
　　　﹡Provider: “$x"
　　　﹡Requester: “And what is his credit limit?"
　　　﹡Provider: “$y"

    提供者被要求记住请求之间 Bruce 的帐号，这就在服务实现中引入了复杂性。无状态的服务设计将重新定义会话，如下所示：

　    ﹡Requester: “What is Bruce’s checking account balance?"
　　　﹡Provider: “$x"
　　　﹡Requester: “What is Bruce’s credit limit?"
　　　﹡Provider: “$y"

    服务粒度

    操作的粒度是一项重要的设计要点。对于外部的消耗推荐使用粗粒度的接口，而细粒度的接口可能用于企业内部。粗粒度接口可能是特定服务的完整处理，例如 SubmitPurchaseOrder，在这里消息包括定义订购单所需的所有业务信息。细粒度接口可能具有用于以下方法的不同操作：CreateNewPurchaseOrder、SetShippingAddress、AddItem，等等。

    虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构（SOA）不要求使用粗粒度接口，但是推荐使用它们作为外部集成的非常好的实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

    服务质量需要考虑的问题

    面向服务的体系结构（SOA）设计将跨越计算机系统，并且还可能跨越企业边界。您不得不考虑在使用 Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计，但是您不得不确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

    例如，您可能需要考虑您所部署服务的度量、可靠性以及响应时间，以便确保它们在承诺的范围之内。当您设计使用来自其他业务伙伴的服务的系统时，您就不得不考虑面向服务的管理来以协作方式管理伙伴之间的服务。