Web服务体系结构原则

一、        一般原则

原则1 如果随着对系统和集成容量的深入理解，用户的需求有可能发展变化时，为了满足客户的需求传递，应构造一个基于Web服务的解决方案。应使用回归需求分析技术来避免对需求的片面理解。必须从业务视图的角度看待集成和互操作性。与其从技术角度考虑实现问题，不如将重点放在更宽的体系结构和系统可重用性上。

 

原则2 通过将大型高风险的原始系统分解为一系列小型易管理的部分来达到商业目的。第二，设计师希望在做局部功能改进的情况下，不必对整个业务过程进行重新构造。大家可以将重点放在业务改变上。

 

原则3 使用可重用原型来转移业务和技术风险。在原型构建出来以前，传统开发方法需要冗长的必要条件和设计过程。可以选用交互式开发过程，取得相应的用户回馈。

 

基本规则1 Web服务解决方案发布版本必须传递可计量的业务数值。

 

基本规则2 Web服务基础设施和集成实现的开销不应该超出其业务总价值。这应当扩展到业务案例分析中。

 

基本规则3 设计师应避免在现在状态和互操作性限制方面的分析上消耗过多时间。因为Web服务实现并不打算重新设计实现整个企业体系结构。Web服务技术适合于从遗留系统展示业务服 和系统功能，而不进行再加工。这就使得可以快速实现。

 

基本规则4 将任何Web服务限制到3-5个月的交货时间内。

 

基本规则5 开发可重用的原型来转移业务和技术风险。

 

二、        下层平台层面

原则4  Web服务技术独立于操作系统或下层下台层面运转。但Web服务的可用性却取决于下层下台层面的可靠性和可用性。

基本规则6 在Web服务的实现过程中，硬件和软件层的可靠性和可用性应当始终作为重点来考虑。典型地，UDDI或ebXML服务注册和SOAP设备等服务组件都是需要重点考虑软硬件可靠性和可用性的。

 

三、        上层平台层面

原则5  Web服务解决方案可以在任何Web或servlet容器上运行，并非必须在基于EJB容器上运行。但是，在体系结构上厂商的servlet容器还是应当和操作环境相同。大多数基于RPC的SOAP调用不管理会话和状态。出于性能方面的考虑，对一些基于RPC的Web服务，没有必要跟踪每个调用式子进程的状态。

 

基本规则7 许多Web服务调用是产生RPC调用的无状态Bean。在发起一个SOAP调用时，为了支持单点登录和身份管理，可能希望保存会话信息。这将使安全基础设施跟踪每个安全会话和Web服务管理工具来度量远程业务服务的业务量并进行性能监控。

 

基本规则8 如果Web服务横跨了不同的遗留系统式多个节点，就不应该保存Web服务的状态。因为这需要极其复杂的应用设计来支持多阶段提交和回滚处理。例如，如果开发人员希望通过同步Web服务从多个银行系统汇集账户余额灰提供统一的投资资料集，则不应该保有到每个银行系统的连接状态。否则，只要有一个连接断掉，账户余额汇集服务就会将整个应用挂起。如果一个银行系统组件需要进行第二次RPC调用来完成业务处理，需这个第二次RPC调用又从异常中退出了，此时，开发人员是否应该滚动处理呢？如果每个连接或RPC调用都被保留或跟踪，将会使设计变得复杂。

 

四、        虚拟平台层面

原则6  SOAP服务提代者和SOAP客户之间的消息传递，根据数据传递方式如HTTP、SMTP、JMS等的不同，可以是异步或同步的。同步消息机制适用于RPC应用模型。异步消息机制适用于发送和接收XML文档，并且可采用SOAP-JMS绑定来保证消息传递。业务事务处理和业务过程编排通常要求基础设施支持可靠的消息传递。没有可靠的消息传递机制，服务请求者就不知道请求已被服务提供者接受并处理。

 

基本规则9 如果要求有保证的消息传递，就采用带SOAP-JMS绑定的异步SOAP调用。这是一个在HTTP上的SOAP消息传递机制可靠性问题。

 

五、        应用平台层面

原则7 使用一个SOAP 客户代理包装遗留系统是比较容易的。但这样做粒度较粗，并且没有包装所有的功能调用。如果数据在一个预先定义的时间段内相对处于静态的情况下，可以将一些SOAP调用在该时间段内缓存起来。

 

基本规则10 从一个现有系统定义一个新业务服务时，Web服务调用应被粗粒度化。例如，一个EJB有100个查询客户账号的方法，但不能将这100种方法全部展示为Web服务。将业务功能展示为Web服务粗粒度方法建议使用3~5个Web服务调用，相似的账户信息可以封装到一个Web服务调用中.