探索SOA中服务的开发、接口和操作语义

　　本部分将讨论以下操作签名语义：

• 　　同步接口与异步接口的比较
• 　　有状态设计与无状态设计的比较
• 　　错误的使用
• 　　Header 与有效负载的比较

　　此部分中的最佳实践指导方针可以帮助您设计可供方便重用和包含到业务流程中的服务。

　　同步接口与异步接口的比较

　　WSDL 端口类型可以包含一个或多个操作。操作可以为单向的，也可以为请求-响应。单向操作可以定义请求消息，但不能定义响应消息。不可能为单向操作定义错误消息。(有关 WSDL 的更多信息，请参见参考资料。)

　　只要客户机应用程序调用单向操作(例如使用符合 JAX-RPC 标准的 Java 代理)，会立即将控制返回给调用客户机应用程序线程。客户机应用程序没有办法知道消息是否成功交付(甚至不能知道是否成功发出)。

　　调用应用程序对此可能接受，也可能不接受。如果可接受，则应用程序可以调用单向操作，并依赖于面向消息的中间件(如 SIBus 或 WebSphere MQ)来确保将消息交付到预期的目的地。如果不能接受，则应用程序可以使用同步调用技术来实现异步语义(将在稍后对此进行说明)。

　　请求-响应操作可以定义一条请求消息、一条响应消息和任意数量的错误消息。当客户机使用异步协议(如 HTTP)发送请求消息时(例如，符合 JAX-RPC 标准的 Java 代理)，代理将阻止调用线程，直到从服务接收到响应或错误为止。

　　错误将提供有关在服务调用期间出现的故障的错误信息。在很多处理方案中，此信息与成功调用期间返回的数据一样重要。

　　服务通常由面向最终用户的应用程序(需要向最终用户提供关于错误的信息)调用。很多业务流程需要直接对使用同步绑定调用的服务返回的错误信息进行分析，以便恰当地定向后续处理。在这种情况下，应该始终尽量利用使用错误的请求-响应操作设计接口。(将在本系列的后续文章中更详细地对错误和错误处理进行讨论。)使用采用请求-响应交互模式的同步协议，并定义最终用户可理解的错误。

　　最佳实践： 在服务接口中定义错误，并在服务实现中进行使用。

　　可以采用两种不同的方式进行异步调用：

• 　　单向调用

　　服务请求者并不等待或需要响应。应用程序或业务流程直接发出要交付给预期的目的地的消息并继续进行处理。

• 　　采用延迟响应的异步请求

　　服务请求者发出请求消息，并随后向服务轮询响应，或者向请求者发出回调。

　　最佳实践：设计新服务时，不要在单个接口(WSDL 端口类型)中混合使用同步调用和异步调用语义。如果同时支持两个语义具有优势，则请为同步调用和异步调用定义独立的接口。

　　清单 1 显示了使用同步操作来实现异步调用语义的示例。事务 debitAccount 不必返回值。通过向操作添加返回值，可以在客户机应用程序中进行错误处理。

　　清单 1. 使用同步操作来实现异步调用语义

String transNumber;

Try
{
transNumber = debitAccount(amount);
}
catch (SystemFault sysFault)
{
	System.out.println(sysFault.getError());
	// React to system level fault
}
catch(BusinessFault busFault)
{
	System.out.println(sysFault.getError());
	// React to business level fault
}

　　在上面的示例中，调用应用程序使用将事务数量作为响应消息返回的请求-响应操作发出请求消息。调用线程将阻止，直到接收到确认信息，表明消息已经成功交付到其预期目的地。如果遇到了问题，将可能由服务提供者或 Web 服务调用引擎引发系统级别和业务级别的错误，并由调用应用程序捕获(同步行为)。

　　调用应用程序会稍后使用事务数量来轮询服务提供者接口，以获取业务响应消息(异步行为)。当调用应用程序对响应不感兴趣时，还可以返回 Boolean 值来直接指示是否成功，从而说明请求消息是否成功交付。

　　有状态接口与无状态接口的比较

　　服务之间的交换可以为有状态，也可以为无状态。当服务提供者保留关于在之前的操作调用期间服务使用者和服务提供者之间交换的数据的信息时，则服务之间进行的是有状态(或对话型)交换。

　　例如，服务接口可以定义名为 setCustomerNumber() 和 getCustomerInfo() 的操作。在有状态交换中，服务请求者将首先调用 setCustomerNumber() 操作，并同时传入客户编号。服务提供者在内存中保留客户编号。接下来，服务请求者调用 getCustomerInfo() 操作。服务提供者将随后返回与之前调用中设置的客户编号对应的客户信息响应。

　　在无状态交换中，服务提供者定义 getCustomerInfo() 操作，使其接受客户编号作为输入参数。服务提供者并不需要定义 setCustomerNumber() 操作，服务请求者也不需要对其进行调用。每个操作调用代表一个独立的事务，该事务具有相关请求消息(包含完成此操作所需的所有必要信息)。

　　在构建 SOA 的过程中，将无状态接口视为最好的选择。无状态接口可以方便地供很多服务使用者应用程序重用，可以采用最适合每个应用程序的方式管理状态。

　　最佳实践：设计采用无状态交互的服务接口。传入操作的请求消息应该包含完成该操作所必要的所有信息，而不受到调用其他接口操作的顺序的影响。

　　Header 与有效负载的比较

　　请求消息包含将由服务用于执行操作的业务逻辑的数据。这些消息也可以包含与事务关联的系统级别处理(而非事务执行的业务逻辑)相关的数据。此类数据的示例包括：

• 　　服务请求者应用程序的标识
• 　　服务实现版本
• 　　发送时间戳与接收时间戳

　　类似地，服务操作发出的响应消息可以包含系统级别的数据，如：

• 　　响应应用程序(服务提供者)的标识
• 　　接收时间戳和发送时间戳

　　计算响应时间

　　这些系统级别的数据必须由服务提供者应用程序(除了负责处理业务级别的数据外)或企业服务总线(Enterprise Service Bus，ESB)基础设施进行处理。在构建 SOA 解决方案的过程中，较好的做法是，恰当设计服务接口的结构，以将系统相关的数据与业务相关的数据分开处理。

　　SOAP 规范规定，SOAP 消息可以包含 SOAP Header、主体以及任意数量的用户定义 Header。应该定义和使用自定义 Header，以用于承载特定于您的业务或项目的系统相关信息。避免将系统相关的信息放置到消息主体中。这样就允许 ESB 基础设施在不用解析消息主体的情况下处理消息(性能密集型操作)。

　　最佳实践：定义和使用自定义 Header，以用于承载特定于您的业务或项目的系统相关信息。避免将系统相关的信息放置到消息主体中。

　　总结

　　SOA 允许企业以灵活的方式发展其 IT 基础设施。Web 服务提供用于实现 SOA 的理想技术。设计良好的服务接口可以对 SOA 的实现起到促进作用，而设计糟糕的接口则会极大地使得工作复杂化。在本文中，我们了解了服务接口高级设计的最佳实践。

查看本文来源