Web Services中的设计问题及模式

来源: BlogBus 原始链接: http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=400690 存档链接: https://web.archive.org/web/20041026160603id_/http://www.blogbus.com:80/blogbus/blog/diary.php?diaryid=400690 作者: wuhaixing

人生架构人生是一个系统，越来越多的人展示他们的生活如何运行。而明天的你如何运转，执行者只能是你自己，面临的无非是任务和执行。构建一段人生需要作出很多的选择，积累不同的组件，确定良好的结构和机制，经历不同阶段的实现.... analysis,architecture,design,developer .: 发表评论 :. .: 最后更新 :. 又发现了sun的优惠活动实在不想干活，做了一上午IQ题 (值)类型的实现-flyweight 设计模式 Resin初体验 good news forget login password? 什么是对象类型？什么是值类型？单音爱情故事 Axis系列-userGuide-Maybe most useful FAQ for newbie 开源的Rollerwebbloger :: <<<用Eclipse,Axis和Tomcat构建Web Services | 首页 | Axis系列--Architecture Guide(1.1)-WSDL Tools Subsystem>>> Web Services中的设计问题及模式 from http://www.devx.com/enterprise/Article/10397 Web Services设计中涉及如下几个基本方面，掌握了这些问题，就可能创建一个成功的项目: 协作能力的管理理解底层通讯模型提供恰当的安全性在设计中计划好部署问题 Standards Improve Interoperability Web services要解决的最基本问题就是协作能力。作用于Internet 应用上的Web services要与内部和外部（合作伙伴、供应商、客户）实现无缝交互，但这些实体都有各自的业务环境，含义相同数据很可能出现各种不同的XML表述。在设计Web services应用的体系结构时，你必须要考虑到这一点。 WSDL是协作能力管理的关键！因为是它描述了各个应用接口之间的协议，不同的组织可以根据它所描述的服务协议标准化他们的应用接口。另外，目前市场很多工具都提供了根据WSDL文件生成客户端代码的功能，开发人员可以不必手工编写处理SOAP消息的代码。管理协作能力另一个要考虑的问题是SOAP，虽然他是不同Web services组件之间的消息传输协议，对于协作交互来说应该是透明的。但由于SOAP有各种各样的实现，某些对标准进行了扩展，有些只实现了部分标准；而且对标准的理解又是多种多样的，所以在不同的平台之间进行协作也成为了一个问题。虽然目前已有一些工作组( SOAP Builders 和 WS-I )开始解决标准制定的问题，但现在还是要考虑不同平台给协作能力带来的负面影响。 SOAP所引发的问题可以采用下面两种方式进行缓解: 1.尽量采用基本数据类型，因为某些客户端无法识别复杂的数据类型； 2.为XML文档提供schema定义，schema机制提供了文档结构和内容的定义。 Understanding Transport Models SOAP并不是一个完整的传输方案，作为Web services的开发人员，必须了解支撑SOAP的底层传输机制、模型以及实现。在简单的应用中，通常可以用平台自动产生的SOAP消息结构和代码来实现Web services。但有时也需要对服务进行定制，这就需要开发人员编写代码直接处理SOAP协议甚至XML文档。因此，开发人员还需要了解SOAP和XML层。在设计Web services接口的时候，一定要记得XML本身并不能保证协作的顺利进行，XML不是解决集成问题的银弹。我们仍然需要对Web services交互过程中所采用的词汇达成一致意见，并用它们进行通信。很显然，仅仅把XML引入到你的体系结构中做不到这一点。XML仅仅是一种描述数据的语言，或者说语法，它没有提供理解这些数据所需的语义。相同结构的数据可能代表不同的含义，含义相同的数据也可能采用了不同的结构。很显然你不能强迫所有人和你用同样的schema，那么怎样才能解决这种耦合性呢？你可以考虑在内部采用一个通用的schema，在需要的时候再把它们翻译或者说转换为外部所需的格式。XSLT技术可以用来实现这种转换。一些Web services平台就提供了这种机制，它允许你在网关、web服务器或应用服务器上设置XML映射规则，用以将收到的XML文档转换为内部的表现形式。 DOM versus SAX 对于需要自己编写代码来处理XML文档的开发人员来说，选择DOM还是SAX解析模型是一个非常重要的设计决策。 DOM采用建立树形结构的方式访问XML文档，而SAX采用的事件模型。 DOM解析器把XML文档转化为一个包含其内容的树，并可以对树进行遍历。用DOM解析模型的优点是编程容易，开发人员只需要调用建树的指令，然后利用navigation APIs访问所需的树节点来完成任务。可以很容易的添加和修改树中的元素。然而由于使用DOM解析器的时候需要处理整个XML文档，所以对性能和内存的要求比较高，尤其是遇到很大的XML文件的时候。由于它的遍历能力，DOM解析器常用于XML文档需要频繁的改变的服务中。 SAX解析器采用了基于事件的模型，它在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，它可以激活一个回调方法，告诉该方法制定的标签已经找到。SAX对内存的要求通常会比较低，因为它让开发人员自己来决定所要处理的tag。特别是当开发人员只需要处理文档中所包含的部分数据时，SAX这种扩展能力得到了更好的体现。但用SAX解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。 Document Exchange vs. RPC models 使用 RPC-encoded 还是 document-style 进行交互是在创建体系结构的过程中首先要决定的事情之一。这个选择会影响到体系结构中的耦合级别。 RPC (remote procedure call)实际上是对一个远程方法的调用，尽管Web services是基于XML的，但你仍然可以采用类似RPC的方式来与后台服务进行交互。这种交互通常是一个简单的请求/响应过程。客户端发送一个包含方法调用的SOAP消息，应用服务器接收这个请求，转换后传递给后台对象(比如，Java object, EJB method, 或者 C# method)。创建基于RPC的Web services 几乎不需要开发人员做任何工作，因为所需的工作仅仅是创建映射关系而已。注意，即使采用这种方式，XML文件也仅仅是作为调用请求的载体。采用document-style，"business documents"以XML格式通过网线传输。，"business documents"不是被直接映射为后台方法调用，因为它们实际上是完整的、自包含的业务文档。Web services接收到XML文档之后，可能先对它进行预处理，执行一些任务，然后创建响应返回。在XML文档和后台对象之间通常没有直接的映射关系，实际上，一个请求很可能会激活几个后台组件完成服务任务。开发人员必须自己完成很多工作来实现XML数据的处理和映射，而且市场上基本没有能够自动完成这种工作的工具。document-style经常会与异步通讯协议一起来搭建一个稳定的、松散耦合的体系架构。你可以把RPC vs. document style类比为打电话和发送电子邮件。一个是同步的请求响应模式，一个是异步的事件队列处理模式。一般的情况下你都应该在系统架构中采用document style消息。尽管RPC模式可以让你迅速实现Web services，但当你要与超出你控制范围之外的客户、供应商和合作伙伴进行协作的时候，这种模式往往不能提供足够的支持。你需要一个体系结构来把你（还有你的客户端应用）保护起来，使你不受远端服务的具体实现的影响。 Document style消息具有如下优点：你可以充分利用XML的能力来描述和验证业务数据，而采用RPC方式的时候，XML描述的仅仅是调用的方法及其参数。客户端和服务提供者之间无需采用紧密耦合的服务协议，RPC通常是静态的，当所调用的方法的signature改变的时候，客户端也需要跟着改变。而document style就不会有这么严格的要求。因为是自包含的，document style 更适合于异步处理。 document style 最大的缺陷就是实现起来比较困难，尽管如此，它所带来的灵活性使得实现所付出的代价显得物有所值，而且越来越多的平台提供商开始为这种方式提供支持。诸如WS-I这样的组织也在倡导采用该方式。 Leveraging Well-Known Design Patterns Adapter or Wrapper: Used to expose internal application functionality with a different interface Façade: Used to encapsulate complexity and provide coarse-grained services Proxy: Used as a surrogate for another object or service. The Wrapper pattern leverages the popular Adapter pattern. The basic idea is to convert a component's interface into another interface that the client expects. This would typically be used to provide some compatibility with the client. The adapter pattern can be used to expose existing technologies as Web services. The Façade pattern is a familiar approach to building coarse-grained services.The idea is to take existing components that are already exposed and encapsulate some of the complexity into high-level, coarse-grained services that meet the specific needs of the client. In using this approach, you can enhance overall performance of the Web services interactions and centralize infrastructure services such as security and transactions。 In the Proxy pattern one object can be used as a surrogate for another, often to offload processing from one component to another. This pattern has been frequently used to hide complexity of the SOAP messaging constructs. It can also be used in the development of mock objects, which have been around for quite some time. Levels of Security 如你所知，Web services为hacker窃取资源开辟了新的途径。掌握Web services 安全层的技术细节并充分利用它们可以让你显著改善系统架构的安全性。这篇文章关注的是目前所能获得的安全特性，并没有对各种正在展开的Web services安全标准进行讨论。目前Web services 可以采用以下三种安全级别： 1.传输层：SSL/HTTPS-对连接而不是数据进行加密； 2.消息层：数据加密(XML Encryption) /数字签名(XML-DSIG) 3.基础设施层：运用应用服务器的安全机制。传输层的安全可能是最容易介入到你的系统架构中的安全机制了，它利用已有的安全机制来保护客户端与服务端的连接。在传输层中，你可以采用SSL和HTTPS来对通讯管道中的数据进行加密。然而，这种方式有两种缺陷。首先，被加密的是连接，而不是数据。也就是说，数据在传输过程中是安全的，但当它到达目标节点或任何中间结点的时候，信息就没有任何保护了。对于Web services来说，对数据提供一直到目标节点的保护非常重要，因为传输过程中经过的很多中间结点都可以对数据进行处理。另一个缺陷就是它提供的基本上是all-or-nothing 的保护，你不能有选择的对特定的数据进行加密和授权。第2级别的安全保护的是信息本身。这一级别的安全机制利用已有的XML标准来协助完成数据的加密和签名。XML数字签名通常用来确保数据的完整性、认证和身份确认。你可以用消息级别的安全来验证给定的SOAP消息来自特定的组织，并且传输过程中没有被修改过。 XML加密还实现了机密性，可以用以判断接收者是否能够察看数据。这些XML安全标准已经相当稳定了，可以在项目中采用。另外，行业中还在制定一些其他的Web services安全标准，比如 SAML 和 WS-Security 。最后，你可以利用Web services所在平台的安全基础设施提供的一些安全特性。就J2EE Web services而言，也就是利用应用服务器固有的安全机制。基础设施级的安全包括利用中间件和OS，以及一些其他服务来实现安全性。 Issues of Deployment 很多IT团队都已经被计算技术的快速改变搞得精疲力尽。然而，还是不断有新的服务要开发和部署。这些服务需要测试，安装，管理和维护。当问题出现的时候，开发人员又必须介入。严重的bugs会导致服务彻底失效或性能下降，使得客户无法获得所需服务，可能因此中断服务协议（service-level agreements-SLA）。鉴于这些部署问题的成本较大，开发人员应该意识到这些问题，并在设计的时候加以考虑。但在Web services 领域，这意味着什么呢？对于要部署的Web services所需考虑的主要设计问题是可控性、可用性、安全、性能以及伸缩性。由于不同的运行时环境和客户需求，你的Web services可能还有其他的问题。但关键问题是在部署和开发之间建立关联，实际上就是建立一种机制，使运行时（部署）数据交回到开发人员、分析师、业务规划人员手中，这样他们就能合理的利用资源。为了更好的解决可用性、性能、伸缩性等问题，需要运行时组件和工具来捕获数据并测量Web services的状况。最好还有工具能让开发人员和分析师审阅这些数据。有些时候，还需要在Web services中使用仪器来获取更精确的数据和运行状况。 wuhaixing 发表于 2004-09-21 -- 10 : 26 : 28 | 引用(trackback0) | 编辑 □ 评论