Open your thoughts

计划写一篇介绍性文章。。。

dateTime 类型的形式为：’-'? yyyy ‘-’ mm ‘-’ dd ‘T’ hh ‘:’ mm ‘:’ ss (’.’ s+)? (zzzzzz)?，其中：

• ‘-’? yyyy 是一个4位或者更多位数的可使用负号的数字，表示年份；如果多于4位数字，则打头数字不能是0， ‘0000′ 也是禁止的；同样需要注意的是+号也不允许使用;
• 剩下的 ‘-’ 是时间中各部分的分隔符;
• 第一个 mm 是一个2位数字，表示月份;
• dd 是一个2位数字，表示日期;
• ‘T’ 是一个分隔符，指明后面是日期中的时间;
• hh 是一个2位数字，表示小时；如果分钟和秒是 0，那么使用 ‘24′ 是允许的, 这个如此表示的 dateTime 值马上转为下一天的值(the dateTime value so represented is the first instant of the following day);
• ‘:’ 是一个时间中各部分的分隔符;
• 第二个 mm 是一个2位数的数字，表示分钟数;
• ss 是一个2位整数数字，表示完整的秒数;
• ‘.’ s+ (如果有) 表示秒数的小数部分;
• zzzzzz (如果有) 表示时区 (如下面所描述的).

例如，2002-10-10T12:00:00-05:00 是 2002-10-10T17:00:00Z，比 2002-10-10T12:00:00Z 晚 5 个小时.

For further guidance on arithmetic with dateTimes and durations, see Adding durations to dateTimes (§E).

关于 TimeZone：

时区中的小时数上限是14，分钟数上限是59，除非小时数是 14，而分钟数必须是 0。

时区的形式是 ((’+’ | ‘-’) hh ‘:’ mm) | ‘Z’，其中：

• hh 是一个2位数字 (必要情况下打头数字是0)，表示小时数
• mm 是一个2位数字，表示分钟数
• ‘+’ 指明是一个正的时间段
• ‘-’ 指明是一个负的时间段

‘+00:00′, ‘-00:00′, 和 ‘Z’ 都表示相同的 0 时区，即UTC; ‘Z’ 是它的规范表现方式.

当将一个时区加到一个 UTC dateTime 中，结果是该日期和时间“位于这个时区中”。例如，2002-10-10T12:00:00+05:00 是 2002-10-10T07:00:00Z，2002-10-10T00:00:00+05:00 是 2002-10-09T19:00:00Z.

原文：http://www.xml.com/pub/a/ws/2004/05/19/wsdl2.html?page=1

by Arulazi Dhesiaseelan
May 20, 2004

W3C 的 Web Services Description Working Group, Web Services Activity 的一个子组织, 已经为描述 web service 定义了一种语言, 也定义了与他们交互的可能方式. The WG 于 26 March 2004 发布了 WSDL 2.0 工作草稿. 这是 WSDL 进化史上的一个重要里程碑. 本文中, 我讨论了相对于 WSDL 1.1 规范所作出的修改以及其它对 web 服务描述语言的主要改进.

W3C WSDL 2.0 工作草稿

W3C 已经公布了下列核心工作草稿作为该工作组交付物一部分:

• Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language
• Web Services Description Language (WSDL) Version 2.0 Part 2: Message Patterns
• Web Services Description Language (WSDL) Version 1.2 Part 3: Bindings

其它相关工作草稿包括需求和使用场景.

• Web Services Description Requirements
• Web Services Description Usage Scenarios

W3C XML Schema definition for WSDL 2.0 specification 可见于 http://www.w3.org/2003/11/wsdl/.

The editor’s copies of these documents provide updated information about the progress of these specifications.

Changes from the WSDL 1.1 Specification

WSDL 1.2 重命名为 WSDL 2.0 因为它相对 WSDL 1.1 有很大不同. 这其中的一些改变包括:

• 进一步加强了 WSDL 的语义. 这是在 WSDL 2.0 中要求 targetNamespace 是 definitions element 的一个必需属性的原因之一.
• 去掉了 message 结构.
• 不再支持操作重载.
• PortTypes 重命名为 interfaces. 支持 interface 使用 extends 属性实现继承.
• Ports 重命名为 endpoints.

节选自IBM developerWorks《Web 服务的体系结构和最佳实践》

关于“编码样式”：

SOAP 规范指定了一个名为“encodingStyle”的模式，它可以取两个值，“encoded”和“literal”。

编码的（encoded）：指的是 SOAP 规范的第5节，这一节定义了将编程语言的类型映射到 XML 的基本机制。

文字的（literal）：意味着您不用做这些工作。取而代之的是，这些类型信息是由外部机制提供的，更像使用 XML schema来确切地定义 SOAP 消息中使用的类型的 WSDL 文档。

这其中的缘故是因为 SOAP 规范是在采用 XML Schema 规范之前编写的。因此，原始的 SOAP 规范必须提供一种方法来指明编码类型信息。与 XML Schema 完全不同的地方是数组。SOAP 规范的5.4.2节指定了一种特别的机制来表示 XML 中的编程语言数组，它使用一种特别的 SOAPEnc:ArraySchema 类型。同时，编码信息（比如 <item xsi:type=”xsd:string”>）通常与用 SOAP 编码标准的 SOAP 消息体元素相关联。

然而，自从采用 XML Schema 之后（您会记得，WSDL用来表示它的类型），大多数语言使用自己的从 XML Schema 到编程语言类型之间的映射（或序列化规则），这使得 SOAP 编码变得过时。因此，推荐不要采用SOAP 编码，而是采用使用文字编码，在文字映射中由 XML Schema 文档（通常是 WSDL 文档的形式）从外部指定映射。

关于“绑定样式”：

WSDL 规范在它的 SOAP 绑定中指定了两种不同的“绑定样式”。绑定样式属性的值是“RPC”和“Document”。其含义是，如果一个WSDL文档指定了一种绑定样式属性设置为“RPC”的操作，那么接收者就必须要用 SOAP 规范第7节中的规则来解释消息。这意味着，例如，在 SOAP 体中的 XML 元素（称为“包装的元素”）必须具有一个与将要调用的对应编程语言操作名称相同的名称。在这个元素中的每个消息部分必须（在名称和次序方面）严格地对应于该编程语言操作的参数。最后，必须只有单个的元素返回（这个元素必须命名为 XXXResponse，其中，XXX 是语言中对应的操作的名称），返回元素中严格地只包含一个元素，那是操作的返回值。

“Document”绑定样式较为宽 松。文档绑定样式中的消息必须仅仅由形式良好、名称空间限定的 XML 组成。由接收它的 SOAP 引擎来决定如何解释它。使用“Document”绑定样式和“Literal”编码来表示 RPC 也是很常见的（例如在 Microsoft 的工具中）。在这样的情况下，发送者将还要遵循 SOAP 规范的第7节中的许多或所有的规则来描述消息，但是要由接收者来决定如何处理这些消息，要么作为一个 RPC 调用，要么作为需要处理的文档。特别地，还有一个外部元素来表示（和命名）操作，而这个元素包括表示消息参数的元素。

推荐在 WSDL 中使用“Document”绑定样式和“Literal”编码。

XML Schema 允许将一个XSD文件分为几个文件存放，在必要时使用 import 或者 include 进行导入。这二者的区别是：

• import：只能导入不同命名空间的XSD
• include：只能导入相同命名空间的XSD，或被导入的XSD未声明命名空间

例子：

本节定义 UDDI Custody and Ownership Transfer API Set. 通过创建一个实体, 一个发布者可以拥有该实体的所有权, 称他为这个实体的所有者. 一个保管节点必须通过授权机制维护一个实体和它的发布者的所有权关系. 多节点注册中心的每个节点必须保证集成了实体保管功能. 同样, 一个节点务必不可允许改变一个实体, 除非这个节点已经保管了这个实体.

Custody and Ownership Transfer API Set 使得一个注册中心的任意节点能够相互间从一个节点向另一个节点转移一个或多个 businessEntity or tModel 的保管关系, 也允许从一个发布者向另一个发布者转移这些数据的所有权. 一个 businessEntity 所包含的实体例如它的 businessService, bindingTemplate, 和 publisherAssertion 结构作为这个 businessEntity 保管关系转移的一部分进行转移.

从保管转移的视角来说, 参与这种转移的发布者总是不同的人, 尽管可能具有这种情况: 这些发布者都是同一个人. 这两个节点可能是不同的节点, 也可能是相同的节点; 两者发布者间的节点内(intra-node)转移简单退化为节点保管关系没有变化这种情况. 因而, 在节点内(规范上为inter-node, 注:这里应该是规范笔误)转移的情况下, 暗含的是所有权转移. 在节点内(intra-node)转移时, 这种转移使得两个发布者间进行所有权转移.

例如, 一个 UDDI 注册中心, UDDI-1, 可能允许每个节点(由节点1A, 1B and 1C组成)定义节点自己的注册, 认证, 授权策略. 在这种情况下, 一个”人(person)”, (P1) 会需要审视一下所有3个节点的策略, 决定注册到哪个节点上. P1 可能选择注册了多个节点. P1 注册了 node1A. Node1A 也指定了怎样验证 P1. 如果 P1 成功通过认证, 然后发布了一个 business entity (BE1), 这样 P1 成为 BE1 的 “owner”. Node1A 称之为 BE1 的 “保管人(custodian)”. P1 也可能注册到了 node1B. 如果成功通过认证并发布了一个 business entity (BE2), 这样 P1 成为 BE2 的 “owner”. Node1B 称之为 BE2 的 “保管人(custodian)”. 注册中心 UDDI-1 或者它的节点(node1A and node1B)不会意识到 P1 其实是同一个人.

另一个 UDDI 注册中心, UDDI-2, 可能需要它的每个节点(node2-1, node2-2 and node2-3)使用相同的注册, 认证和授权机制. 在这种情况下, 这些策略在所有节点中都是一样的. 它们的注册, 发布和所有权关系都保持相同. 如果 P1 想要注册到 UDDI-2 中的不同节点, 那就需要在这些不同的节点中区分这些注册关系, 因为在已经注册到了 node2-1 后又试图注册到 node2-2, 将会遭遇 “已经注册过(already registered)” 错误 (因为根据策略, 这些节点共享相同的注册, 认证和授权).

当在 save_xxx 操作中使用到 keyedReference 时, 它可能会被检查是否是有效的. 类似的, 在 save_xxx 操作中使用到一个 keyedReferenceGroup element 可能也要接受检查确定其是否有效. 检查针对那些被 UDDI 注册中心认为是 “checked” 的 tModels.
UDDI 提供了让第三方注册 value set 的能力, 然后控制检验过程(由 UDDI 使用)去执行这种检查. UDDI 注册中心可能支持缓存这些外部 value sets. UDDI 注册中心也可能支持外部校验. 由节点和注册中心策略确定使用哪种校验方式去执行对外部值集引用的检查. 这一系列 APIs 能够供 UDDI 注册中心和节点用在它们的校验策略中.
想提供一个外部检验能力的第三方实体可能需要使用跟 UDDI 一样的方式去实现一个 Web service(举例来说, 使用 literal encoding SOAP 作为消息传递机制), 这个 Web service 只暴露一个方法 validate_values. validate_values 接口将在随后描述.
在某些情况下, 一个节点可能希望消除或者减少对外部校验 Web service 的调用次数. 它能够通过缓存那些 允许缓存的外部值集 的有效值来达到这一目的. 一个节点有两种标准选项用于获得有效值的集合. 一个是周期性从那些实现了 get_allValidValues API Web service 的值集提供者那里获得有效值集合. 另一种获得有效值缓存的方式是累积每次从 validate_values 成功获得的有效值.

Value Set 编程接口

本系列的 APIs 提供了一种能力: UDDI registry 可能使用这种能力对值集的引用进行校验. 注册中心策略确定哪个外部值集是受支持的, 如何支持.
公共可访问的用于支持外部值集校验的 APIs 如下:

· validate_values: 由节点使用, 允许外部值集校验 Web service 的提供者评估 keyedReferences or keyedReferenceGroups 是否是有效的. 返回一个 dispositionReport 结构.
· get_allValidValues: 由支持从可缓存检查型值集缓存有效值的节点使用, 用于获得有效值的集合. 返回一个空消息或者一个 dispositionReport 结构.

注册中心策略可能需要提供其中一种 Web service 的值集提供者通过特定方式为这个 service 发布 bindingTemplate, 为该值集发布 tModel, 这样才能够找到正确的 Web service. 当一个值集提供者提供了其中一种 Web service, 应该在任何该提供者想要提供该值集的注册中心中为该检查型值集发布一个 tModel, 为值集提供者为该检查型值集提供的 Web service 发布一个 bindingTemplate. 该 tModel 应该具有 uddi-org:types category system 的分类, 表明值集类型(categorization, identifier, relationship, categorizationGroup), 是检查型的(checked), 并且, 如果该值集提供者允许根据节点对有效值的缓存进行校验, 也应该标明是 cacheable 类别.
为了让一个值集成为检查型的, 该 tModel 必须首先引用 uddi-org:types category system 使用 checked 值将其划为 checked 的.  检查这样的值集是由注册中心和节点策略决定的.
如果一个值集 tModel 被划分为 checked, 那么在试图发布一个使用到这个 checked tModel 的 keyedReference 时, 节点必须或者执行必要的校验, 或者返回 E_unsupported.
该 tModel 也应该具有一个到 get_allValidValues or validate_values Web service 的 bindingTemplate 的分类引用, 这需要使用 uddi-org:validatedBy category system.
get_allValidValues or the validate_values Web service 的 bindingTemplate 应该在它 tModelInstanceDetails 中引用适当的值集 tModel, 和其它该服务所适用的所有的值集 tModels.

security API 包括下面 APIs:

· discard_authToken: 用于通知节点以前得到的某 authentication token 不再需要了, 如果在接收到这个消息之后还有使用它的, 应该认为它是无效的.
· get_authToken: 用于从一个节点请求一个使用 authInfo element 样式的 authentication token. 在使用 Inquiry API Set, Publication API Set, Custody and Ownership Transfer API Set, 和 Subscription API Set 中的 API 时, authInfo element 可能是必需的.

API 是否需要 authInfo elements 是由节点策略决定的. 如果一个 authInfo element 最后并没有被丢弃, 节点可能会选择使这个 authentication token 过期, 这样可以让它不再有效. 如果一个过了期的 token 被传递给一个 API, 除了 discard_authToken 外, 将返回错误 E_authTokenExpired.
如果一个 UDDI 节点不支持在 API set 中使用 authInfo element, 通常它也不支持 Security API set. 如果节点支持在该节点所提供的任何 API set 中使用 authInfo element, 它应该也支持 Security API set. 一个节点可能提供另一种可替代(security api的)机制用于获得 authInfo elements.

discard_authToken：

参数：

· authInfo: 这个必需的参数包含一个 authentication token. Authentication tokens 可使用 get_authToken API 获得.

行为：

Discarding an expired authToken is processed and reported as a success condition.

返回值：

完全成功的话, 返回一个空消息(return null).

错误警告：

如果在处理这个 API 调用时发生错误, 将在 SOAP Fault 中返回一个 dispositionReport 结构给调用者.

get_authToken：

get_authToken API 用于获得一个 authentication token. 在使用 Inquiry API Set, Publication API Set, Custody and Ownership Transfer API Set, 和 Subscription API Set 中的 API 时, 一个 authToken element 可能是必需的.

参数：

· userID 属性: 这个必需的属性是 UDDI 节点分配给一个已授权过用户的标识符. 节点应该提供一种方式供用户获得一个在给定节点有效的 userID and password 认证信息.
· cred 属性: 这个必需属性是密码或者与该用户相关联的 credential.

返回值：

这个 API 调用完全成功后会返回一个 authToken 结构, 包含一个有效 authInfo element, 这个 authInfo element 就可以在接下来的请求中使用.
authToken element 包含一个 authInfo element. authToken element 总是作为对 get_authToken 调用的同步响应而返回.

错误警告：发生错误时, 必须返回一个 dispositionReport element.

· E_unknownUser: UDDI node 不接受和认可请求所传递的 userID and/or cred 参数值为有效认证信息.

save_binding：

save_binding API 用于保存或更新一个完整的 bindingTemplate element. 它可以用于添加或更新一个或多个 bindingTemplate elements, 也可以用于调整与某 businessService element 的包含关系. 每个 bindingTemplate 可能(MAY) 被签名, 可能(MAY)使用 publisher-assigned keys.

参数：

· authInfo: 略.

· bindingTemplate: 必需的. 可有1个或多个 bindingTemplate. 如要保存一个新的 bindingTemplate, 则提供一个 bindingTemplate element,
或者 bindingKey 属性值为空, 或者使用 publisher-assigned bindingKey.

每个新的 bindingTemplate 必须(MUST)包含一个 serviceKey 值, 该 serviceKey 所对应的 businessService 也是由该发布者所控制的. 一个已存在的 bindingTemplate 可能(MAY)包含一个 serviceKey 值, 对应于该同一发布者所控制的 businessService. 调用这个 API 将影响到每个 bindingTemplate 参数的父 businessService(即其父businessService可能会更改为其它businessService). 如果同一 bindingTemplate (由 bindingKey 值决定是否相同) 出现多次, 它的上级 businessService 具体是哪个将由处理顺序确定, 即决定于从第一个到最后一个(该相同的) bindingTemplate 的位置.
如果一个 bindingTemplate element 的 bindingKey 缺失或是一个空值, 这表示 bindingTemplate 首次被插入. 当出现这种情况的时候, node 必须(MUST) 自动为该没有 key 的 bindingTemplate 生成一个新 key. 新的 bindingTemplate 结构也可以使用 publisher-assigned keys.
使用这个 API, 可以将一个已存在的 bindingTemplate 从一个 businessService 移动到另一个 businessService, 只需要简单地为该 bindingTemplate 指定一个另一个不同的父 businessService 的 serviceKey. 通过这种方式改变父 businessService, 将对这两个 businessService 结构都产生影响. The net result of such a move is that the bindingTemplate still resides within one, and only one businessService based on the value of the serviceKey passed. 如果一个发布者尝试通过这种方式移动一个 bindingTemplate, 但并非该 bindingTemplate 中 serviceKey 所对应 businessService 的所有者, 那么该操作请求必须(MUST)被拒绝, 并返回一个 E_userMismatch 错误.
当一个 bindingTemplate 被保存, 且使用了 categoryBag 关联到一个 checked value set 或 category group system tModel, 这些 references 必须(MUST)先于保存操作完成之前接受有效性检查, 或者 node 必须返回 E_unsupported 指出它并不支持引用 checked value set 或 category group system.

Publisher API 概要：

• add_publisherAssertions: 用于向已存在的断言集合中添加关系断言.
• delete_binding: 用于从 registry 中移除一个已有的 bindingTemplate.
• delete_business: 用于删除已有的 businessEntity 信息.
• delete_publisherAssertions: 用于从一个特定发布者所控制的断言集合中删除该特定发布者的断言. 从断言集合中删除断言影响到商业实体关系的可见性. 删除一个断言导致任何基于那个断言的关系都将成为不完整的.
• delete_service: 用于删除一个已有的 businessService.
• delete_tModel: 用于隐藏已有的 tModel 的信息. 任何使用这个方式隐藏掉的 tModel, 对于引用来说, 仍将是可用的, 并且可以通过 get_tModelDetail API 访问, 但从 find_tModel 结果集中是看不到的(即被hidden). 没有任何方式可以(真正、物理)删除一个 tModel.
• get_assertionStatusReport: 用于获得包含发布者断言和状态信息的状态报告. 这种报告对于帮助管理员管理发布者断言来说是非常有用的. 返回的 assertionStatusReport 包括发起该请求的发布者所控制的任何 businessEntity 构成的所有断言的状态.
• get_publisherAssertions: 用于获得一列由某发布者控制管理的发布者断言. 返回的 publisherAssertions 结构包含所有与这个发布者有关联的发布者断言.
• get_registeredInfo: 用于请求一个给定发布者当前所管理的 businesses 和 tModels 的简要列表.
• save_binding: 用于注册新 bindingTemplate 信息或更新已有的 bindingTemplate 信息. 使用这个 API 去管理某注册商业实体所暴露出来的技术能力信息.
• save_business: 用于注册新 businessEntity 信息或更新已有的 businessEntity 信息. 使用这个 API 去管理整个商业实体的全部信息集合, 包括它的 businessService 和 bindingTemplate 结构. 这个 API 在所有 save_xx APIs 中有最广泛的影响.
• save_service: 用于注册或更新一个 businessService 的完整信息.
• save_tModel: 用于注册或更新一个 tModel 信息.
• set_publisherAssertions: 用于保存一个发布者的发布者断言的全部集合. 这个 API 将替换任何已有断言, 导致任何的没有被重新 reasserted 的旧断言被删除掉.