|
以文本方式查看主题 - 计算机科学论坛 (http://bbs.xml.org.cn/index.asp) -- 『 Web Services & Semantic Web Services 』 (http://bbs.xml.org.cn/list.asp?boardid=10) ---- Web服务架构及其规范入门 (http://bbs.xml.org.cn/dispbbs.asp?boardid=10&rootid=&id=37666) |
|
-- 作者：flyfoxs -- 发布时间：9/7/2006 10:17:00 AM -- Web服务架构及其规范入门 来源：不详 作者：Luis Felipe Cabrera、Christopher Kurt、Don Box [摘要]本Web服务架构入门阐述了Web服务架构的基础设计原则和Web服务的基础技术。此外还对其功能进行了介绍，并提供了对其进行正式定义的规范链接。本文也是该架构所有规范的参考指南。 XML和Infoset Infoset根据一组‘信息项（Information Items）’对XML文档进行建模。这组可能的信息项一般会映射到XML文档的不同功能部件上，如元素、属性、命名空间和注解。每一信息项都有一个关联属性集，用于提供该项的更完整描述。附录B描述了XML文档中的11类信息项。每一个结构严谨的XML文档都会包含一个文档信息项和至少一个元素信息项。 除了基于纯文本的Infoset编码技术以外，Web服务架构还支持另外一种Infoset编码技术——即允许不透明的二进制数据与传统的基于文本的标记交织在一起。W3C XML-binary Optimized Packaging（即XOP）格式使用多部分MIME将原始二进制数据引入到XML 1.0文档中，而不采用base64编码。其配套规范——SOAP 消息 Transmission Optimization Method，即MTOM，则指定如何将该格式绑定到SOAP。XOP和MTOM是将原始二进制数据与基于文本的XML混合在一起的首选方法，它们取代了目前普遍遭到反对的SOAP with Attachments（SwA）和WS-Attachments/DIME。 SOAP Envelope是SOAP消息的根元素，它包含一个可选的Header元素和一个必需的Body元素。Header元素是以分散方式增加SOAP消息功能的一种通用手法。Header的每个子元素都被称为一个Header块（Header Block），SOAP定义了几个知名的属性来指示应该由谁来处理Header块（role）以及这种处理是可选的还是必需的（mustUnderstand），下文中对这两个属性进行了介绍。目前，Header元素总是Envelope的第一个子元素；Body元素总是Envelope的最后一个子元素，也是供最终消息接收者使用的“有效负载”的容器。SOAP本身没有定义内置的Header块，且只定义了一个有效负载，那就是用于报告错误的Fault元素。 所有的Web服务消息都是SOAP消息，它们充分利用了XML Infoset。消息有效负载和协议头都使用同一个模型，可以确保基础架构头Header和应用程序体的完整性。应用程序发送消息时可能会同时考虑Header的内容和消息中的数据。为XML数据模型开发的工具可以用于检查和构建完整的消息。过去，这些益处在某些架构中是没有的，如DCOM、CORBA和RMI，它们之中的协议头是一些对应用程序不透明的基础架构细节。 SOAP消息是从发送者向接收者单向传送的。多个单向消息的组合可以形成较为复杂的模式。例如，比较常见的模式是同步请求/响应消息对。发送或接收消息的任何一个软件代理都被称为一个SOAP节点（SOAP Node）。启动消息传输的节点称为原始发送节点。使用和处理消息的最后一个节点称为最终接收节点。在原始发送节点和最终接收节点之间处理消息的任一节点都叫做中介（Intermediary）。中介用于模拟单个消息的分布式处理。消息经过的所有中介节点和最终接收节点统称为消息路径（Message Path.）。 为了能够识别消息路径的各个部分，每个节点都担任一个或多个角色。SOAP角色是一种分类模式，它将一个基于URI的名称与某些抽象功能（如缓存、验证、授权）关联在一起。基础SOAP规范定义了2个内置角色：Next和UltimateReceiver。Next是一个通用角色，因为除了发送节点之外的每一个SOAP节点都属于Next角色。UltimateReceiver是消息路径中终端节点所扮演的角色。它通常就是应用程序，或在某些情况下是代表该应用程序执行任务的基础架构。 SOAP envelope的Body总是针对最终接收节点。而SOAP header则可以针对中介，也可以针对最终接收节点。为了提供一个安全且版本可控的消息处理模型，SOAP定义了3个属性，用于控制中介和最终接收节点处理某一指定Header块的方式——role、relay和mustUnderstand。角色属性用于确定Header块所针对的节点。mustUnderstand属性用于指示在Header块未被认出的情况下该节点是否可以忽略该Header块。带有mustUnderstand="true"标记的Header块叫做强制Header块（Mandatory Header Block）。标记为mustUnderstand="false"或没有mustUnderstand属性的Header块叫做可选Header块。relay属性指示该节点是发送还是放弃未被认出的可选header。 每一个SOAP节点都必须使用这3个属性来实现SOAP处理模型。以下步骤详细说明了该模型： 使用角色属性（缺省该属性表示Header块针对最终接收节点）确定将用于当前SOAP节点的SOAP消息的所有Header块。 消息交换模式 广播传输（Broadcast Transport）使一对多消息传输得到了普及。原始发送者将其消息强行发送给接收者的模式称为推模式（Push Model）。尽管这种模式在局域网里很有效，但在广域网中则不太适用，接收者也无法调控消息流。另一个有用的模式是以应用程序表达对某些特定消息类别的兴趣的能力为基础的，它使发布/订阅模式大行其道。通过显式订阅消息源（或主题），应用程序可以更好地控制相关信息流。接收者从消息源显式请求消息时使用拉模式（Pull Model）。在这种模式下，消息流是由接收者驱动的。拉模式也可以与发布/订阅模式结合使用。这非常适合于接收者可能要与消息源间歇地断开连接的情况。 传输的独立性 既然Web服务协议完全独立于底层传输之外，适当机制的选择可能就要延迟到运行时。这就为Web服务应用程序提供了在发送消息时确定相应传输机制的灵活性。此外，底层传输机制可能会随着消息在节点之间的发送而变化，相应地，针对每一网段而选择的传输机制也会随需发生变化。 尽管存在着这种一般的传输的独立性，大多数第一代Web服务都使用HTTP来进行通信，因为这是SOAP规范内所包含的一种主要绑定协议。HTTP以TCP作为其底层传输协议。但是，TCP在设计时引入了不必要的处理开销。有些应用协议模式与用户数据报协议（即UDP， User Datagram Protocol）的语义学比较匹配，这些模式对于受设备及其他资源约束的系统特别有用。UDP不像TCP那样具有传输保证；它提供最大限度的数据报消息传递。与TCP相比，它需要的实施资源较少。此外，UDP还提供了多路广播功能（Multi-cast Capabilitiy），使一个发送者可以将消息同时发送给多个接收者。 寻址 Action Header块用于说明消息的预期处理。该Header块包含一个URI，最终接收者通常用它来分派要进行处理的消息。 引用属性和引用参数之间的区别在于它们如何关联服务元数据。Web服务策略和契约仅基于其基地址和引用属性。通常，基地址和引用属性用于识别某一给定的已部署服务，引用参数用于识别该服务所管理的特定资源。 引用属性和参数是那些预期只被最终接收者处理的简单的不透明XML元素。它们有助于确保可用于分派、发送、索引或其他发送端处理活动的信息被包含在给定的消息中。尽管中介预期不会对该信息进行处理，但某些中介（如防火墙或网关服务程序）却有可能使用某些引用属性或参数来进行消息发送、消息处理。引用属性有很多用途。服务类（Classes of Service）和专用实体标识符（Private Entity Identifier）就是两个例子。在服务等级例子中，引用属性可以用于区分针对标准客户的Web服务和针对“黄金”客户的Web服务，后者提供了更高的服务质量和增强功能——可能是通过附加的操作或附加的绑定——在逻辑上形成两个不同的端点。这些属性只在一个会话中设置一次，然后便在交互的其余所有部分重复使用。引用属性另一个用途的例子是以一种对系统不公开发送消息的方式来识别客户的机制。这两种引用属性的组合可以高效地将消息发送给一组适当的服务器，并高效地确定与某一特定用户有关的应用状态。这些例子还展示了引用服务实例的数据和引用用户实例的数据如何用引用属性来表示。 需要特别指出的是，引用属性还有助于对共享一个共同的URL和作用域的WSDL实体集合进行寻址。WSDL是将Web服务描述为操作消息的一组端点的XML格式，它首先抽象地指定其实体，然后将其具体地绑定到特定实例。具体而言，消息和操作经抽象定义之后，被绑定到带有网络传输和消息格式信息的一个端点。因此，从WSDL的角度来看，当针对不同的具体实体（如输入或输出消息、portType绑定、端口或Web服务中使用一个共同URL的服务）时，对应端点引用的引用属性应该不同。 使用引用参数的两个例子是基础架构和应用水平。引用参数的基础架构例子可以是发送给某一事务处理监视器的事务/征募ID（Enlistment ID）。在一个购书的场景中，书的ISBN号可能就是一个引用参数应用水平例子。 元数据（Metadata） Web服务描述语言，即WSDL——Web Service Description Language，它是被广泛用于描述Web服务基本特征的第一种手段。用WSDL描述的消息被归并为定义基本消息模式的若干操作。这些操作被归并为称作端口的若干个接口，它们详细说明了抽象的服务契约。端口和绑定则用于将portTypes与具体传输和physical 部署信息关联在一起。WSDL描述是自动识别目标服务的所有特征和启用软件开发工具的第一步。WSDL指定请求消息必须包含什么以及响应消息在使用无歧义符号时的显示会是怎样。WSDL文件用于描述消息格式的符号是基于XML模式的。这意味着它既是编程语言中立的又是基于标准的，这使得它很适合于描述可通过多种平台和编程语言来访问的服务接口。除了描述消息内容以外，WSDL还可以定义服务在何处是可用的，以及哪些通信协议被用于与该服务交谈。这意味着WSDL文件可以指定用于编写与某一Web服务进行交互的程序的基本元素。有几种工具可用于读取WSDL文件，以及为编制句法正确的Web服务消息生成所需代码。 尽管WSDL是一个不错的起点，但它并不足以描述Web服务的方方面面，WSDL只能表示较少的一组属性。Web服务所必需的更详细信息包括： 操作特征：支持SOAP 1.2。 策略断言使编程人员要么在开发时、要么在运行时向服务信息中添加适当的元数据。开发时策略的例子包括消息大小的最大允许值或所支持规范的确切版本，运行时策略的例子包括宕机时的必备服务或某一给定的管理过程（定期的硬件维护）期间Web服务的不可用性。可以对单个的策略断言进行分组，以形成策略选项（Policy Alternative）。策略是策略选项的集合。为了便于进行互操作，策略是根据其XML Infoset表示形式来定义的。为了在保持互操作性的同时减小策略文档的大小，又定义了策略的紧凑形式。 策略用于传达两个Web服务端点之间的交互条件。满足策略中的断言通常会引发反映这些条件的行为。因此，策略断言评估是识别兼容行为的中心。当且仅当请求者满足要求，即提供了这一功能、与该断言相符时，请求者才支持策略断言——策略的构造块。一般而言，这种决定要使用特定领域的知识来做出。请求者支持策略选项的条件是当且仅当请求者支持选项中的所有断言时，这种决定是使用策略断言的结果机械性地做出的。同样，当且仅当请求者至少支持策略中的一个选项时，请求者才支持策略。一旦策略选项经过评估，该决定也是机械性地做出的。请注意，虽然策略选项是互斥的，但一般来说要确定多个选项是否可以同时得到支持也是不太可能的。 为了以互操作的形式传达策略，策略表达式（Policy Expression）采用策略的某种XML Infoset表示形式。普通形式的策略表达式是最简单的Infoset；同样，可选的Infoset允许通过大量构造来简洁地表达策略。策略表达式是策略的基础构造块。有两个运算符用于表达断言：All和ExactlyOne。All运算符表示策略选项集中的所有断言都必须适用于要满足的策略断言。ExactlyOne运算符表示策略选项集中只有一条断言必须适用于要满足的策略断言。 策略层位于WSDL描述之上，并对它进行了扩充。策略与Web服务元数据（如WSDL定义或UDDI实体）的关联是通过使用WS-PolicyAttachment来实现的。策略可以作为其定义所固有的一部分或独立地与资源关联在一起。机制就是针对这些不同目的而定义的。需要特别指出的是，策略也可以与单个的SOAP消息一起使用。如果为某一实体制作了多个策略附件，它们会共同确定该实体的有效策略（Effective Policy）。在WSDL层次结构的不同层次上选用策略时一定要小心，因为层次结构每一层次的最终结果就是一个有效策略。作为自我描述和人所能理解的明确性的一般规则，在策略断言所适用的层次结构的每一层次上详细地重复该策略断言，比简单地依赖于计算有效策略的机制更可取。在一个WSDL文档中，与部署端点的消息交换可以同时包含所有4类主题的有效策略。WS-Policy和WS-PolicyAttachment相结合可以提高应用程序来发现和推出其他服务所支持的策略的能力。添加策略的灵活性是对描述消息交互的WSDL信息的一个重要补充。 WSDL和WS-Policy都定义了元数据格式，但都没指定某一给定服务获得或访问元数据的机制。一般来说，服务元数据可以通过使用许多方法来获取。为了支持服务的自我描述，Web服务架构在WS-MetadataExchange中定义了基于SOAP的元数据访问协议。GetMetadata操作用于检索在请求的端点引用中找到的元数据。Get操作类似，但用于检索不同的元数据：在元数据部分引用，并要在存储它的端点引用中检索的元数据。 使用WS-MEX来交换的元数据可以描述为资源。资源即可由某一端点引用寻址的任何实体，并且在该端点引用中，该实体可以提供一种其自身的XML表示形式。资源构成了构建Web服务中的状态管理所需的基础。 什么是互操作性概要（Interoperability Profile） WS-I基本概要 安全性 安全性是计算机系统的一个基本方面，尤其是那些由Web服务组成的系统。安全性必须是健壮而有效的。因为系统只对消息格式和合法的消息交换作出硬件假设，因此安全性必须基于一致通过的明确机制和假设。安全基础架构还应该具有足够的灵活性，以支持不同组织所需的不同安全策略。 当安全传输可用于通信Web服务，如安全套接层（SSL）和传输层安全性（TLS）之间时，构建安全性解决方案就得到了简化。有了安全传输，这些服务就不需要参与单个消息的完整性和机密性的维护；它们可以依赖于底层传输。不过，现有的传输级安全性是一个仅限于点对点消息传递的解决方案。如果在使用安全传输时存在中介，则最初发送者和最终接收者需要相信这些中介能够帮助提供端到端的安全性，因为每个网段都是安全的。除了要明确地信任所有中介外，还必须考虑到其他风险，如消息的本地存储和中介受到损害的可能性。 为了最大限度地扩大Web服务的作用范围，当通信端点不相信中介时，必须提供端到端的安全性，那就需要更高级别的安全协议。作为另一种选择，端到端消息安全性比点对点传输级安全性具有更丰富的内涵，因为它支持Web服务所需的基于SOAP的松耦合、联合、多传输和可扩展环境。这种功能强大而又灵活的基础架构可以通过现有技术和Web服务协议的组合来开发，同时还可以缓解与点对点消息传递相关联的许多安全风险。 尽管Web服务的安全需求很复杂，但人们还没有发明新的安全机制来满足基于SOAP的消息传递的需要。现有的分布式系统安全性方法，如Kerberos票、公钥加密技术、X.509证书等已经够用了。只有应用现有的SOAP安全方法时，新机制才是必需的。这些新安全协议的设计充分考虑了可扩展性，以便将来能够加入新的方法。一个主要的设计目标是要提供自我描述安全性属性（为包括SOAP在内的Web服务架构而设计）机制。 Web服务安全性的基础是输入消息要证实一组关于发送者、服务或其他资源的断言这一需求。我们称之为断言或安全性断言。典型的安全性断言包括身份、属性、关键财产、权限或功能。这些断言是用包裹在XML中的二进制安全性令牌编码的。在传统的安全性术语中，这些安全性令牌表示功能和访问控制的混合。很多方法都被用于创建安全性令牌。Web服务可以从本地信息构建定制的安全性令牌。反过来，安全性令牌也可以从X.509认证机构或Kerberos域控制器等专业服务检索。为了实现服务之间的通信自动化，需要一个表达安全需求的方法。 服务可以使用WS-SecurityPolicy中所指定的策略断言来表达其安全需求。通过检索这些策略断言，应用程序可以构建符合目标服务需求的消息。断言、安全性令牌和策略所提供的这组特性以及从Web服务检索它们的能力非常强大。这种普通的Web服务安全模式支持一些更具体的安全模式，如基于身份的授权、访问控制列表和基于功能的授权。它允许使用现有技术，如X.509 公钥证书、基于XML的令牌、Kerberos共享的秘密票和密码摘要。这种普通模型对于构建使用更复杂的方法来进行更高级别的密钥交换、身份验证、基于策略的访问控制、审核和处理复杂的信任关系的系统已经足够。也可以使用代理和中继服务。例如，可以构建中继服务来加强位于信任边界的安全策略；出界的消息被加密，而界内的消息不加密。以前的解决方案没有提供这种灵活性和完善程度。附录C中所描述的常见安全攻击包含了系统威胁的基本分类，而这些系统威胁是在选择Web服务安全特性时应认真加以考虑的。 本节的余下部分将探讨Web服务安全模式的应用。两个重要主题是安全通信和安全应用。没有假定安全的消息传输，这也不是安全的Web服务所必需的。 消息完整性和机密性 完整性、身份验证和机密性机制将初始消息（或该消息的某些部分）作为输入，将生成的数据（如校验和）作为输出。例如，在某种简单情况下，XML元素的签名可能会作为XML元素所有字符的散列的非对称加密来实现。然后该加密散列可以存储在该消息中，并在该消息中传送。可以将XML文档看作字符串。就像XML签名一样，逐字符地比较也是非常重要的安全性操作。一字之差会导致不同的结果。串行化是用于表示“在线”对象的方法。例如，串行化可用于创建SOAP消息的XML表示。不同串行化软件所导致的任何无关紧要的排字差异都会被消息处理软件忽略，但会对安全性软件产生很大影响。XML消息的Infoset表示形式改进了这一问题。要使XML签名生效，消息必须转换成一个对所有方都是一致的XML表单。规范化是一个术语，来描述用于生成一致的换行符、制表间隔、属性排序和结束标签样式等非关键信息视图的方法。签名包含了用于使消息接收者能够完全像发送者那样处理安全信息的规范化方法。某一服务所使用的特定的规范化方法是要放置在一个WSDL portType绑定或WSDL端口的有用的策略断言。 WS-Security指定了消息完整性和机密性机制以及单一的消息身份验证。对于消息完整性，该规范详细描述了加密签名是如何表示并与SOAP消息的特定部分关联的。该方法允许任意格式良好的消息片段拥有单独的签名。与之类似，机密性是通过结构良好的消息片段的加密来实现。身份验证是使用数字签名来实现的。WS-Security规范描述了当前常用的安全机制，也没有排除将来添加新机制的可能性。因为SOAP处理模型使用Header元素来作出处理决定，所以是决定SOAP消息中的哪些元素需要加密时一定要多加小心。 在决定要对哪些元素进行加密以及要使用哪些加密算法时，Web服务设计人员一定要清楚消息是如何处理的。当某些特定的Header元素需要由第三方或中介来处理时，这些决定就更为重要了。如果这些参与者对适当的解密数据或对在加密XML元素时所使用的约定毫无所知，它们将无法实现正确操作。此外，每个处理节点对消息中包含的安全信息都必须有个一般的了解。加密某一Header中XML元素的一个自然选择就是对它进行完全加密，用初始元素替代加密数据类型的元素。这种简单的方法有些缺点。例如，中介不太好确定必须处理哪些元素（带有mustUnderstand="1"属性的元素）。另外，当元素类型发生变化时，确定其初始类型比较困难。另一种方法是对元素进行转换，使得进行正确的SOAP处理所需的所有关键属性都保持不变，且对初始元素进行了加密，并放在一个特殊的子元素中。这种方法的优点是即使不知道如何解密元素的中介也能实现正确的处理。这种方法的一个缺点是它要求所有参与者都了解用于表示初始元素的约定。尽管WS-Security目前没有对这种方法提供指导，但我们预期将来会提供的。相比之下这种方法更好一些，因为它可实现所有SOAP Header元素的正确处理。 WS-Security的概要规范中描述了几种安全性令牌。针对表示用户名的令牌、X.509证书和基于XML的安全性令牌的概要都已经开发出来。基于XML的安全性令牌包括安全性断言标记语言（SAML，Security Assertion Markup Language）和可扩展权限标记语言/权限表达语言（REL，Rights Expression Language）。Kerberos票的使用规范还未成型。 WS-I基本安全概要 基于安全令牌的信任 WS-Trust以用于请求、发出和代理安全性令牌的协议对WS-Security进行了补充。需要特别指出的是，其中定义了用于获取、发行、更新和验证安全性令牌的操作。该规范的另一个新特性是建立新信任关系的机制。IPsec或TLS/SSL之类的网络和传输保护机制可以与WS-Trust结合，以适应不同的安全性需求和情况。 安全性令牌可以直接从某一适当的发行者处申请获得，或者通过委托某一受信任的第三方来获取。令牌还可以出乎意料地获得。例如，令牌可以从某一安全权威机构发送到一个并未明确申请该令牌的某一方。为此，系统管理员要确定初始信任关系，如将某一给定服务指定为信任的根服务。这种方法类似于目前Web上用于自展安全性的方法。从该服务获得的所有令牌受信任的程度与受信任的根服务本身相同。例如，如果某根服务只有断言A和B得到信任，且某一消息包含断言A、B和C，则该消息中只有断言A和B得到信任。配置灵活性是通过信任关系授权提供的。为了处理在退回或发出安全性令牌之前需要各方之间的一个交换集的情况，定义了用于验证、协商和交换的方法。一种称为“challenge”的特殊形式的交换为某一方证明它拥有与某一令牌关联的密钥提供了一种方法。交换的其他类型包括传统的协议隧道。WS-Trust详细说明了如何扩展该规范，以支持更多的令牌交换协议，而不仅仅是所给出的这两个例子。 表示安全性断言的安全性令牌是由一个受信任根或一个通过一个授权链的根发行的。这些安全性断言用于验证消息符合正在施行的安全策略。它们还验证断言者的属性是通过签名来校验的。在代理的信任模式中，即由受信任的中介分配安全性令牌的模式中，签名可能不验证断言者的身份，而验证中介的身份。该中介可能只断言者的身份。 安全会话 WS-SecureConversation在基于共享密钥（如对称加密）的两个通信方之间定义了一个安全上下文。在整个会话期内，安全上下文在各通信方之间始终是共享的。会话密钥由共享密钥派生而来，用于解密在会话中发送的单个消息。安全上下文在线表示为一个新的安全性令牌类型（即SCT ，Security Context Token）。 规范为建立安全会话各方之间的安全上下文定义了3种不同方法。第一种，由安全性令牌服务创建，且必须由会话发起方提取并传送。第二种，通信一方创建安全上下文并通过消息传递给另一方。第三种，通过协商和交换创建安全上下文。Web服务会选择最能满足其需要的方法。必要时可以对安全上下文进行修正。更新安全上下文的一个典型例子是延长安全上下文的截止时间。安全上下文令牌隐含或包含了一个共享密钥。该密钥用于签名、加密消息。当使用共享密钥时，通信各方可以选用不同的密钥派生模式。例如，可以派生出4个密钥，这样双方便可以使用单独的密钥来签名和加密消息。为了保证密钥未曾用过和保持高度的安全性，应使用后续的派生密钥。使用这种方法来保证会话的安全性是一种更好的选择。WS-SecureConversation规范定义了一种方法来指示给定消息正在使用哪些派生密钥。所有派生算法都是通过URI来识别的。 安全策略 系统联盟 通过身份联盟，很多要求都可以得到满足。就拿将一名员工与其雇主关联起来的例子来说，公司A的Jane从OfficeSupplyStore.com进行采购，公司A和OfficeSupplyStore.com之间有一个采购合同。因为Jane的身份是与公司A关联的，所以可以让她来依据该合同来进行采购。第二个例子是将一个人映射到多个笔名。大家可能只知道Joe使用joe@companya.com工作。他还可能有其他身份，如joe_bloggs@hotmail.com和josephb@cornell.edu。通过身份联盟，系统可以确定这些身份都是同一个Joe。 Web服务联合安全架构中定义了两个一般的请求者（消息发送者）类：被动和智能（活动）。被动请求者是只使用HTTP且从来不发出安全性令牌的服务。智能请求者是能够发出包含诸如WS-Security和WS-Trust中所描述的那些安全性令牌的消息的服务。传统的基于HTTP的Web浏览器就是被动请求者的一个例子。定义这两种请求者的行为的概要规范现已开发出来。对于智能请求者，active请求者概要详细说明了单点登录、退出和笔名是如何通过使用SOAP消息而整合到Web服务安全模型中的。实际上，该概要描述了在智能请求者上下文中实现WS-联盟中所描述的模式的方法。它详细说明了各种安全性令牌的要求。作为这些安全性令牌要求中之一的一个例子，当不使用安全通道时，X.509证书的整个令牌必须包含权威机构的名称和签名。该概要还要求X.509令牌包含主题标识符，以唯一地识别授之以该令牌的主题。 发现（Discovery） 目录（Directory） 对于如何部署UDDI注册表，Web服务提供商有很多不同的选择。部署方案不外乎3个类别：公共、企业外和企业内。为了支持公共部署，以Microsoft、IBM和SAP为首的一组供应商主持推出了UDDI企业注册表[UBR，UDDI Business Registry]。UBR是一个可跨多个主持企业复制的公共UDDI注册表，它既是基于Internet的Web服务资源，又是Web服务开发者的一个试验台。尽管目前公共UDDI实施已经受到了最大关注，但UDDI的早期采用者仍更倾向于使用企业外和企业内方法。在这两种部署情况下，企业要部署一个专用注册表，而且更严密地控制注册信息类型也是可能的。这些专用注册表可能只供一个企业使用，也可能供若干组业务合作伙伴使用。UDDI还为注册表间的复制和跨部署的信任联盟定义了协议。使用这些协议进一步增加了可用于实施者的部署方案数量。对于所有的部署方案，UDDI目录都包含了Web服务及其托管地的详细信息。UDDI目录项有3个主要部分——服务提供商、所提供的Web服务和实施绑定。其中的每一部分都逐渐提供有关Web服务的更详细信息。 大部分的一般信息都描述服务提供商。该信息不针对Web服务软件，而是针对直接负责该服务的开发者或实施者。服务提供商信息包括名称、地址、联系人及其他管理细节。所有的UDDI项都有多个元素来支持多语言描述。可用的Web服务列表存储在服务提供商项中。这些服务可能是根据它们的预定用途来组织的：它们可能被分成不同的应用领域、地区或任何其他适用的模式。存储在UDDI注册表中的服务信息只包含服务描述和一个指向它所包含的Web服务实施的指针。由其他提供商托管的服务链接称为‘服务映射（Service Projection）’，也可能被注册。 UDDI服务提供商实体的最后部分是实施绑定。该绑定将Web服务项与确切的URI关联起来，以确定在何处部署服务，它还指定了访问协议，并包含所实施的确切协议的参考资料。这些细节对于开发人员编写调用Web服务的应用程序已经足够。详细的协议定义的是通过一个称为“类型模型（即tModel，Type Model）”的UDDI 实体提供的。在许多情况下，tModel都会引用一个描述SOAP Web服务接口的WSDL文件描述，但tModel的灵活性也几乎可以描述任何种类的资源。对于在UDDI中注册的每一个提供商或服务来说，来自标准分类学（如NAICS和较古老的美国标准行业代码）或其他身份识别方案（如Edgar Central Index Key）的元数据都可用于分类信息和提高搜索准确性。可用的分类学和标识符方案集作为任何实施的一部分，是可轻松扩展的，因此可以对其进行定制以支持任何特定的地域、行业或企业需求。 动态发现（Dynamic Discovery） 因为发现代理自身也是Web服务，它们可能会用自己专用的Hello消息来声明它们的到场。接收该消息的Web服务然后可以利用该代理的服务，而无需再使用干扰较多的一对多发现协议。当服务离开网络时，WS-Discovery会指定一个Bye消息以发送给网络或发现代理。该消息通知网络上的其他服务离开的Web服务不再可用。 为了完善这种服务声明和离开的基本方法的不足，WS-Discovery定义了两个操作——Probe和Resolve，以定位网络上的Web服务。对于自组织网络，Probe消息被发送给多路广播组，并且与该请求匹配的目标服务会将响应直接反馈给请求者。对于利用发现代理的托管网络，Probe消息则以单路广播方式发送给发现代理。如果按名称定位Web服务，则使用Resolve消息。Resolve消息只以多路广播模式发送。Resolve 类似于地址解析协议，即ARP，它将IP地址转换成其对应的物理网络地址。WS-Discovery规范还支持这样的系统配置：将Probe消息发送给一个已经通过其他管理方法建立起来的发现代理，如通过使用众所周知的DHCP记录。 动态发现服务的能力实现了Web服务管理的自举。与WS-Eventing及其他协议相结合，更复杂的管理服务也可以通过使用这种动态发现基础架构来构建。动态发现还将Web服务架构扩展到设备，如那些目前可能实施通用即插即用（UPnP）协议的系统——这是使该架构真正实现通用的重要一步。例如，借助WS-Discovery和WS-Eventing，打印机或存储介质等设备可以作为Web服务纳入到系统中，而且无需专门的工具或协议。 Web服务设备概要规范 一致性协议——可靠的消息传递和事务 当多个Web服务必须完成工作的某一共同单元或依照某种共同的行为进行操作时，对于使用哪个协议必须达成共识。Web服务之间这种最低限度的协调是不可避免的。协调协议还必须能够确定并同意已达成一个共同目标。Web服务之间的每一个交互都可以看作一种协调。一致性协议为该架构提供了一个改进的机会，即参与者服务在它们准备共同完成的任务方面将获得成功。在传输丢失了消息和服务失常时，Web服务架构仍然能够正常工作。 任何多方协调都可以通过接连地随需加入更多参与者从两方协调逐步发展而成。两方协调可能是自发的，也可能需要一个指定的协调者。广泛使用的自发协调协议的一个例子是同步请求—响应消息传递模式。这是一致性协调的最简单形式之一；对于每个工作请求，接收方Web服务必须完成所有预期工作之后才能向请求者返回数据。双方都遵循这种严格的模式，无需显式协调服务。 可靠的消息传递 At-Least-Once Delivery（至少一次传送）：每条消息至少传送一次。 可靠的消息传送不需要显式协调者。当使用WS-ReliableMessaging时，参与者必须根据SOAP消息Header中所发送的信息识别协议。作为一个组传输的消息集合称为消息序列（Message Sequence）。消息序列可以由发起者/发送者或Web服务创建，当建立一种双向关联时通常由它们共同创建。序列是使用CreateSequence和CreateSequenceResponse消息显式创建的。当想要的最终结果是用两个单向序列来充当一个双向序列时，发起者将提供Web服务所要使用的序列。该序列的ID由发起者包含在CreateSequence消息中。 WS-ReliableMessaging中定义了几个策略断言。这些策略断言用WS-Policy中定义的方法来表示。 可靠的消息传递协议简化了开发人员为在传输不断变化的情况下传输消息而必须编写的代码。也就是说，底层基础架构可以对消息在端点之间的正常传输进行验证，必要时还会转发消息并检测重复。应用程序不需要任何附加逻辑来处理提供传送可能需要的消息转发、重复消息的消除、消息重新排序或消息确认。WS-ReliableMessaging的实施是跨发起者和服务分布的。那些非‘在线’可见的特征，如消息传送顺序，是通过实施WS-ReliableMessaging规范来提供的。虽然由传输损失导致的消息重发等特征是通过不为应用程序所知的消息传递层来处理的，其他端到端特征（如依次传送）都要求消息传递基础架构和接收应用程序相互协作。当发送者希望按发送顺序提供消息排序时，在接收者一方却按接收顺序提供消息排序的情况是依次传送的一种不正确实施——注意到这一点是很有趣的。当发送者希望按接收顺序提供消息顺序时，在接收者一方按发送顺序提供消息顺序的情况，是依次传送的一种正确实施。 指定的协调者 WS-Coordination规范定义了一个可扩展的协调框架来支持需要显式协调者的情况。该协议引入了一个称为协调上下文（Coordination Context）的SOAP头块，用以唯一地识别联合工作中将要着手进行的部分。为了启动工作的接合部分，Web服务会向一个或多个目标服务发送协调上下文。收到协调上下文后，接收方服务会得到提示，说有联合协作请求提出。协调上下文中包含了足够的信息，请求接收者可以利用这些信息来确定是否参与该工作。协调上下文中包含的确切信息根据被请求工作的种类的不同而变化。 协调类型集是可扩充的。只要参与该联合工作的每个服务对所需行为都有个一般的了解，新类型就可以通过实施来定义。例如，原子事务是Web服务架构中已经定义了的几个初始基础协调类型之一。如果被请求的协调类型被理解并被接受，Web服务就会使用WS-Coordination注册协议来通知协调者并参与该联合工作。协调上下文中包含了协调者的一个端点引用和可能行为的可选标识符。注册操作指定该多方参与的Web服务所支持的行为。一旦注册消息发送到协调者，Web服务就会依照它们所预订的协议参与该工作。注册是协调框架中的关键操作，它允许意欲协同配合以完成工作的共同单元的不同Web服务相互连接在一起。 WS-AtomicTransaction为Web服务指定了传统的ACID事务，并为原子事务协调类型定义了3个协议：完成协议（Completion Protocol）和两阶段提交协议（Two-Phase Commit Protocol）的两个变体。完成协议用于启动提交处理。为完成而注册的Web服务能够通知指定的协调者何时开始提交处理。该协议还详细说明了用于通知启动者事务最终结果的消息。不过，该协议不要求协调者确保启动者对结果进行处理。相反，WS-AtomicTransaction中的其他行为则要求协调者确保参与者对协调消息进行处理。 两阶段提交（2PC）协议为所有已注册的参与者提供了一个公共的提交或中止决定，确保了所有参与者都能得到最终结果通知。顾名思义，它使用两轮通知来完成该事务。该协议的两个变体是：易失2PC（Volatile 2PC）和持久2PC（Durable 2PC）。这两个协议在线上使用相同的消息（对应于Prepare、Commit和Abort操作），但易失2PC没有持久性要求。易失2PC协议供管理易失资源的参与者使用，如缓存管理器或窗口管理器。这些参与者在第一轮通知中不与协调者发生联系，且不需要第二轮的通知。持久2PC协议供管理数据库和文件等持久资源的参与者使用。当某一提交处理已经启动时，在所有易失2PC参与者被联系过之后这些参与者会第一次被联系。这使缓存能够被刷新。持久2PC参与者需要完整的两轮通知来实现协调者所要求的全有或全无行为以及完成该事务。这些行为最适合于可以在整个事务期内持有资源，且该事务通常为非常短暂的事务的情况。该协议保证在正常处理的情况下，协调者提供第一阶段结果的同时将联系所有参与者。对于完成时间预计将比较长的事务，或当资源（如锁）无法持有时，其他协调协议就会定义替换行为。 WS-AtomicTransaction中定义了若干策略断言，这些策略断言使用WS-Policy中定义的方法来表示。 排队系统（Queued System） 持续时间长的活动（Long Duration Activities） 三方握手 解除协议类似。一方向另一方发送一个会话解除请求。接收者以对解除消息的确认消息作为响应。接收到该确认消息之后，发出解除消息的一方通过再对该确认消息发送一条确认消息结束消息交换。 枚举、传输和事件 枚举（Enumeration） WS-Enumeration指定了用于建立枚举会话和检索数据序列的协议。枚举协议允许数据源向正在使用的服务提供一个叫做枚举上下文的会话抽象。该上下文通过一个数据项序列来表示逻辑光标。然后，请求者将该枚举上下文用于一个或多个SOAP消息的某一区间以请求数据。枚举数据表示为XML Infoset。该规范还允许数据源提供一种自定义机制来开始新的枚举。既然枚举会话可能需要若干个消息交换，那么会话状态必须保持稳定。 关于迭代进度的状态信息可以由数据源或正在使用的服务在请求间维护。WS-Enumeration允许数据源一个请求一个请求地决定哪一方将负责维护下一个请求的状态。这种灵活性实现了若干种优化。例如，使服务器能够避免对调用之间的任何光标状态进行保存。由于消息潜伏时间对于支持若干个同时枚举的服务来说可能会很长，不保存状态可能会使必须维护的信息总量大大减少。资源受限设备（如移动电话）上的服务实现可能根本无法维护任何状态信息。 传输（Transfer） WS-Transfer的创建、更新和删除操作扩展了WS-MetadataExchange中的只读操作功能。检索操作与WS-MetadataExchange中的Get操作完全相同。Create请求发送给工厂。然后，工厂创建被请求的资源并确定其初始表示形式。工厂被假定与所创建的资源不同。新资源被分配给一个在响应消息中返回的，由服务决定的端点引用。Put操作通过提供一种替换表示形式来更新资源。资源表示形式的一次性快照与WS-MetadataExchange中的Get操作一样，也可以通过WS-Transfer中的Get操作来检索。Delete操作成功后，资源将无法再通过端点引用来使用。这4个元数据管理操作构成了Web服务中状态管理的构建基础。 事件（Eventing） WS-Eventing详细说明了实现下面4个实体交互的机制：订户、订阅管理器、事件源和事件接收。这使某一Web服务在作为一个订户时能够登记它对另一个Web服务（事件源）所提供的特定事件的兴趣。这种注册叫做订阅。WS-Eventing定义了某一服务可以提供的支持订阅创建和管理的操作。当事件源判定有事件发生时，它就会将此信息提供给订阅管理器。订阅管理器然后可以将该事件传送给所有匹配的订阅，这类似于传统的发布/订阅事件通知系统中的发布主题。Web服务架构提供了主题定义、组织和发现方式的全面灵活性；它为在很多不同的应用场合中可能会用到的订阅提供了一个通用的管理基础架构。也可以订阅出租的资源，但最终都必须收回。用于收回资源的主要机制是各个订阅的到期时间。查询订阅状态同样也有一种机制，帮助订户管理其若干订阅事项（包括续订、通知和取消订阅的请求）的附加操作规范中也有详细说明。当然，任何服务都可以随时自由地终止订阅，这与所有Web服务的自主原则一致。订阅终止消息可供事件源通知订户订阅终止过早。 虽然基于事件的异步消息的一般模式很常见，但不同的应用通常都要求使用不同的事件传送机制。例如，在某些情况下简单异步消息可能是最佳选择，但如果事件接收能够通过轮询控制消息流和消息到达时间，则其他情况可能会更适用。当接收无法从源头到达目的地时，如接收有防火墙阻拦的情况下，轮询也是必要的。WS-Eventing中所引入的传送模式概念就是用来支持这些要求的。传送模式被用作一个扩展点，以便为订户、事件接收和事件源建立定制的传送机制提供一种手段。下述管理规范利用了这种机制。 事件代理可用于聚合或重新分配来自不同来源的通知，代理还可以用作独立的订阅管理器。这两个方法都得到了WS-Eventing的支持。代理在系统中可以扮演若干个重要角色。主题可以按特定的应用类来组织使用。代理可以充当通知聚集器，用于整合来自多个来源的事件信息。它们也可以充当过滤器，这比用于其自己通知的过滤器所接收的消息要多。这种灵活性是部署健壮而可伸缩的通知系统所必需的。 管理（Management） WS-Management要求托管资源的引用使用带有特定附加信息的端点引用。该信息包含了对该资源提供访问的代理的URL、该资源所属资源类型的唯一标识符URI以及识别该资源的零个或更多个密钥。这些密钥被假设为名称/值对。该信息是这样映射到WS-Addressing端点引用的：资源的URL映射到地址属性，资源类型标识符映射到一个名为ResourceURI（在适当的XML命名空间中）的特定引用属性，各密钥分别映射到一个名为Key、属性为Name的引用参数。为了满足管理服务的消息传递需要，规范为操作定义了3个限定符。这些限定符的SOAP表示位于header元素中。operation timeout指定了一个截止时间，之后操作将不需要接受服务；locale元素在需要或期望转换底层信息时使用；freshness限定符用于请求最新的值并避免返回陈旧数据。对于使用WS-Transfer操作的数据访问，WS-Management指定了另外3个限定符。Get操作可用于SummaryPermitted header和NoCache header。如果可用，SummaryPermitted限定符允许传输简略表示形式。NoCache限定符要求传输最新数据，禁止信息缓存。对于Put和Create操作，ReturnResource限定符要求服务返回资源的新表示形式。ReturnResource使资源受限的Web服务能够在更新资源时不保留状态。 WS-Management为事件通知定义了3个自定义的传送模式：批、拉和捕获。这些模式都由URI来识别，这些URI在建立订阅时使用。批传送模式使订户能够接收捆绑在一个SOAP消息中的多个事件消息。订户可能还会要求捆绑某一最大数目的事件、服务收集事件可耗用的最长时间，以及应返回数据的最大量。拉传送模式使生成服务的数据能够维护事件的逻辑队列，以便订户能够按需轮询通知。该轮询是通过使用WS-Enumeration和返回时附带订阅响应消息的枚举上下文来完成的。最后，如果UDP多路广播是一种合适的消息传递方式，捕获传送模式便允许事件源使用它。在捕获模式下，事件源可以将其通知发送给某一预定义的UDP多路广播地址。 结束语 已经进行的大量细致入微的工作可以确保各种Web服务协议能够不加变动地相互组合；尽管是一起设计的，它们仍可以以非常多的组合方式来使用。和功能构造块一样，它们的使用方式与传统开发框架类似。必要时，如对于SOAP附件，我们已经开发了新的解决方案，而且不加变动它们就可以很好地用于该架构内。关注组合不是对丰富功能的威慑。 该架构的SOAP消息传递基础保证了 foundation assures wide reach。SOAP消息传递以一种传输独立的方式支持异步和同步模式。具有更高灵活性的基础架构不存在。为了加快Web服务架构的广泛采用，很多技术合作伙伴都参与了这些规范的制定。与这些重要技术提供程序的合作加快了设备和支持这些在线协议的编程环境的部署。实现广泛覆盖、广泛采用和与规模无关的构造是我们的3个核心目标。我们力争确保该架构能够在任何平台上用任何编程语言来实现。该架构基于消息的和基于协议的特性为此提供了便利。必要时，如只使用WS-Security来支持消息完整性、机密性和身份验证，以及只使用WS-Policy来表示元数据时，我们已经限定了用于提高互操作水平的技术方法的使用领域。理论上讲，只要实现切实遵守该架构的协议规范，它们就能与其他任何Web服务通信。 附录A：术语表 身份验证（Authentication）——验证安全凭证的过程。 授权（Authorization）——根据提供的安全凭证授权访问安全资源的过程。 规范化（Canonicalization）——将XML文档转换成符合每一方要求的格式的过程。在签名文档和解译签名时使用。 断言（Claim）——断言是对发送者、服务或其他资源（如名称、身份、密钥、组、特权、功能等）所作的陈述。 协调上下文（Coordination Context）——一组协调服务要完成的一组工作的唯一标识符。 反序列化（Deserialization）——从一个八位字节流构建XML Infoset的过程。它是用于从消息的有线格式创建消息的Infoset 表示形式的方法。 摘要（Digest）——摘要是八位字节流的加密校验和。 域（Domain）——安全域代表安全管理或信任的一个单元。 持久的两阶段提交（Durable Two Phase Commit）——用于文件或数据库等持久资源事务的协议。 有效策略（Effective Policy）——有效策略，针对某一给定的策略主题，是附加在包含该策略主题的策略范围上的策略组合。 交换模式（Exchange Pattern）——用于服务之间消息交换的模式。 工厂（Factory）——工厂是可以从XML表示形式创建资源的Web服务。 联盟（Federation）——联盟是已经建立相互信任的信任域的集合。信任级别可能变化，但通常都包括身份验证，并可能包括授权。 身份映射（Identity Mapping）——身份映射是创建身份属性之间关系的一种方法。某些身份提供程序可能会利用身份映射。 身份提供程序（IP，Identity Provider）——身份提供程序是为最终请求者提供身份验证服务的实体。身份提供程序还为服务提供程序提供数据源验证服务（这通常是安全性令牌服务的一种扩展）。 消息（Message）——消息是可由服务发送或接收的完整数据单元。它是信息交换的独立单元。无论何时消息都会包含SOAP信封，并有可能包含附加MTOM中指定的MIME部件、传输协议header。 消息路径（Message Path）——遍布在初始源和最终接收者之间的SOAP节点集。 被动请求者（Passive Requestor）——被动请求者是一个使用得到普遍支持的HTTP（如HTTP/1.1）的HTTP浏览器。 策略（Policy）——策略就是策略选项集。 策略选项（Policy Alternative）——策略选项就是策略断言集。 策略断言（Policy Assertion）——策略断言表示特定于域的单个要求、功能、其他属性或行为。 策略表达式（Policy Expression）——策略表达式是策略的XML Infoset表示形式，可以是正规形式，也可以是等同的压缩形式。 主体（Principal）——可以被授予安全权限或可以给出安全性或身份断言的任何系统实体。 协议组合（Protocol Composition）——协议组合是在保持技术连贯性的同时组合协议并避免任何非指定功能副作用的能力。 资源（Resource）——资源是可由端点引用寻址的任何实体，在该端点引用中，该实体可以提供其自身的XML表示形式。 安全上下文（Security Context）——安全上下文是一个抽象概念，指的是已建立的身份验证状态和可能具有与安全有关的附加属性的协商密钥。 安全上下文令牌（Security Context Token）——安全上下文令牌（SCT）是安全上下文抽象概念的有线表示形式，它使上下文能够被URI命名并和一起使用。 安全性令牌（Security Token）——安全性令牌用于表示一组断言的集合。 安全性令牌服务（Security Token Service）——安全性令牌服务（STS）发行安全性令牌的Web服务。更确切地说，它根据它所信任的证据来作出断言，并发送给信任它的任何一方（或特定接收者）。为了表明信任，服务需要证据（如签名），以证实安全性令牌或安全性令牌集提供的信息。服务本身可以生成令牌，也可以通过它自己的信任陈述依靠某一独立的STS发行安全性令牌（注意，对于某些安全性令牌格式，这只能是重新发行或联合签名）。这构成了信任代理的基础。 序列化（Serialization）——将XML Infoset表示为八位字节流的过程。它是用于创建消息的有线格式的方法。 服务（Service）——通过消息来与其他实体进行交互的软件实体。注意，服务不需要连接到网络。 签名（Signature）——签名是通过加密算法计算出来，并绑定到数据的一个值。而且经过绑定，数据的指定接收者可以使用该签名来验证数据没有改变并发自消息的签名者，从而提供了消息完整性和身份验证。签名的计算和验证可以通过对称或非对称密钥算法来进行。 退出（Sign-Out）——退出是这样一个过程：某主体表明它们将不再使用其令牌且该域中的服务可能会破坏该主体令牌缓存。 单点登录（SSO，Single Sign On）——单点登录是对身份验证序列的一种优化，旨在消除在请求者身上进行的反复操作负担。为了便于进行SSO，称为身份提供程序（Identity Provider）的元素能够以请求者的名义充当代理，将身份验证事件的证据提供给请求该请求者信息的第三方。这些身份提供程序（IP）是受信任的第三方，既需要得到请求者的信任（以维护请求者的身份信息，因为该信息的丢失可能会泄露请求者身份），又需要得到Web服务的信任，Web服务可能会根据该IP提供的身份信息的完整性提供对重要资源和信息的访问权。 SOAP中介（SOAP Intermediary）——SOAP中介是一个SOAP处理节点，它既不是原始消息发送者，也不是最终接收者。 对称密钥算法（Symmetric Key Algorithm）——一种加密算法，其中的消息加密和解密都使用相同的密钥。 系统（System）——实现某一特定功能的服务的集合。与分布式应用程序意思相同。 信任（Trust）——信任表示一个实体愿意依靠另一个实体来执行一组操作，对一组主题、范围作出一组断言。 信任域（Trust Domain）——信任域是一个得到有效管理的安全空间，在其中，请求的来源和目标可以确定来自某一来源的特定凭证集是否符合该目标的相关安全策略，并对此达成一致。目标可以将信任决定延期至第三方的加入（如果这已被确立为一致意见的一部分），从而将受信任的第三方包括在信任域中。 易失的两阶段提交（Volatile Two Phase Commit）——用于缓存或窗口管理器等易失资源事务的协议。 Web服务（Web Service）——Web服务是一种可重复使用的软件组件，它依据XML、SOAP和其他业界公认的标准通过网络实现交互式的消息交换。 附录B：XML Infoset信息项 文档（Document）：每个信息集里都有一个文档信息项。它用于引用所有的其他信息项。 附录C：常见的安全攻击 对主机的攻击 主机机密性或授权攻击企图泄露隐私或身份 对通信网路的攻击 对网络通信机密性的攻击企图在线泄露隐私 对网络通信授权的攻击企图泄露身份 |
|
-- 作者：softbaddog -- 发布时间：9/15/2006 12:00:00 PM -- 看了一段，是篇好文章，先收下了。 |
|
-- 作者：domino -- 发布时间：9/27/2006 9:30:00 AM -- 感谢楼主，我是新丁，好好学习，天天向上 |
|
-- 作者：qq45457876 -- 发布时间：10/8/2006 12:06:00 AM -- 楼主辛苦了 |
|
-- 作者：jhHenry -- 发布时间：10/16/2006 3:44:00 PM -- 这么多 慢慢看吧 |
|
-- 作者：myxiangrong2000 -- 发布时间：11/20/2006 1:36:00 PM -- 好文章! 谢谢!! |
|
-- 作者：wdls3008 -- 发布时间：2/26/2007 2:09:00 AM -- ding |
|
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
26,355.470ms |