Service设计模式.docVIP

作者：linugb118 Web Service设计时考虑的几个要素 Encapsulation:封装：对Service来说，他封装了逻辑和具体处理过程，他封装后为client提供简单的参数进行调用，因此首先service要封装的设计要考虑满足多种client需求，另外service的未来内部的变化不要影响到client。 The Service Contract:服务订约：作为client和service直接交换的约定，他包括传输的协议，比如wsdl；也包括是否用户验证，数据安全等。需要注意的是，通常传输协议已经考虑到用户验证之类的常见约定了。 Autonomy:自治权：service 需要有自治权，简单的说不能因为client的调用或者其他问题，导致service被动或者失败。特别是在分布式事务的时候，会因为事务的锁导致service的不可用。所以我们在service设计时尽量避免分布式事务在使用，如果的确没办法，我们可以在设计service的时候，为他设计一对services，来避免某个service不可用是调用另外service；这个services表达的是同一个东西，但是角度不同，比如“debit” 和 “credit”。 Latency:等待时间：需要充分考虑client调用service后的反馈时间，这里包括返回的数据尽量精简，内部处理逻辑等。 Partial failures：错误信息：需要充分考虑各类异常或者错误，并能告知client。 Binary message encoding of text-based data:二进制传输：将response转化为二进制传输可以降低带宽，降低等待时间等，当然这个要求不是必须的。 Web service 通常有3种，RPC API；Message API；Resource API RPC API设计需要考虑的方面有: 灵活设计API参数：对service可以是多个参数进行设计，也可以将多个参数通过某种格式糅合成一个参数。一个参数的好处是能灵活的增加和删除参数而不需要修改原来service的api结构。 与Service服务相关的代理:代理和service服务自我描述。这个代理是指和service服务描述相对应的，也可以认为是service的client端，比如wsdl，他会自动通过工具生成一个proxy。而且这类proxy会跟着service服务的自我描述的变化而变化。 异步方式:Service应设计为应答方式，而不是request-response方式。Service接到client的请求，同步进行应答，而具体请求转到后台通过异步方式进行后续处理。 避免阻塞：通过使用Asynchronous Response Handler来避免client阻塞等待。 同样可以考虑压缩为二进制传输 Message API设计需要考虑的方面有： 获取Service的描述，包括使用的传输协议，格式等。 委托工作：对service的请求分两次，第一次发送一个command 调用指令来告诉service后续还有具体的数据消息过来或者具体数据消息资源在什么地方。 异步方式:Service应设计为应答方式，而不是request-response方式。Service接到client的请求，同步进行应答，而具体请求转到后台通过异步方式进行后续处理。 避免阻塞：通过使用Asynchronous Response Handler来避免client阻塞等待。 同样可以考虑压缩为二进制传输 后续绑定：service的response返回通常包含了client会用到的相关的地址信息。 Resource API设计需要考虑的方面有： 多client支持：本身Resouce API用于多个各种不同的client，比如Web browsers, feed readers, syndication services, AJAX controls, mobile applications等。特别可用于大的文件或消息的交换场景。因此要设计Resource API要考虑多client的支持。 可访问性：resource 通常通过URI就能很容易暴露，因此需要多考虑一些安全问题，防止不法分子获取URI后能进行非法的访问。 通常Resource API开发者不重视Service 描述，因此这方面的client自动生成的工具比Message API，RPC API要差 异步方式:Service应设计为应答方式，而不是request-response方式。Service接到client的请求，同步进行应答，而具体请求转到后台通过异步方式进行后续处理。 避免阻塞：通过使用Asynchronous Response