RAMP 概要简介
Reliable Asynchronous Messaging Profile (RAMP) 1.0 是一个 WS-I 概要风格的概要,可以通过使用 Web 服务技术实现基本的 B2B 集成方案等功能。本文的目的在于提供自该概要首次发布以来所做更改的更新内容。
Reliable Asynchronous Messaging Profile (RAMP) 1.0 是一个 WS-I 概要风格的概要,可以通过使用 Web 服务技术实现基本的 B2B 集成方案等功能。此概要是以前称为 IBM Basic B2B Profile 的第二个公开草案。来自分析人员、我们的客户和合作伙伴的反馈认为,该概要已经超出了 B2B 场景,应该更改其名称以反映这一事实,基于这个原因,我们对该概要进行了重新命名。本文的目的在于提供自该概要首次发布以来所做更改的更新内容。
引言
2005 年 4 月,IBM 发布了 IBM Basic B2B Profile 的第一个公开草案。
我们收到了对最初草案的很多宝贵的反馈意见和建议,综合这些反馈,我们形成了重新命名后的第二个版本,即 Reliable Asynchronous Messaging Profile (RAMP) 1.0。
正我们与客户紧密合作,以更好地了解他们的要求,从而据此对概要进行修订。在 RAMP 1.0 概要的第二版中,我非常高兴地发现,除了名称改变之外,另外的重大改变之一就是福特汽车公司 (Ford Motor Company) 作为规范的共同制定者参加了进来。这是一个重要的里程碑,因为它清楚地表明该规范得到了一个关键的技术使用者的支持。
在第二版中有哪些更改?
在此概要的技术方面有其他一些变化。其中最值得注意的就是,我们添加了对使用 WS-Secure Conversations 规范 (WS-SC)的支持,以获得其为可靠消息传递序列带来的性能优势和更可靠的安全水平。为了确定使用此技术的相关要求,仍然要进行很多工作,但我们认为,现在将 WS-SC 规范包含在概要中以清楚地确定发展方向,而不等到制定了所有互操作细节才进行这项工作,这一点非常重要。
此外,我们还对特定的要求进行了一些略微次要的更改。除了明显的编辑调整,每个更改都在我们的 Google Group 讨论论坛中进行了讨论。在所有更改中,我们结合了 wsa:To 标头块的 Cardinality 的要求与 W3C WS-Addressing WG 所给出的技术解决方法。以前,此概要至少允许一个 wsa:To 标头块。而 W3C WS-Addressing WG 采取的技术解决方法则是将此 SOAP 标头块的 Cardinality 限制为出现一次。
概要的行业支持
通过与福特汽车公司等客户讨论,我们得出结论,RAMP 概要适用于汽车行业,尤其适合(但不限于)供应链集成领域。三位客户均提出需要提高集成(公司内部的集成及公司与其合作伙伴间的集成)。我们将 RAMP 概要视为处理这些要求的坚实的一步。我们相信其适用性可以从汽车行业扩展到金融、医疗保健和其他行业,我们相信此概要的精心设计有助于其他更为全面且特定于各个领域的概要的制定,这些概要能够引用 RAMP 概要,从而扩展或约束其范围。
什么是概要?
概要是一组命名的Web服务规范的集合,通过这些规范的组合以实现特定的功能范围。在理想的情况下,规范没有可选性或多义性,概要应该是为实现给定功能而组合到一起的规范的列表。不过,我们都知道,我们并不是生活在理想的世界中。因此,概要有必要以概要范围内基础规范可互操作使用要求的形式提供约束和准则。准则和附加的约束通常基于实现经验。对于 RAMP 概要,这个经验来自于规范的作者(IBM、Microsoft、BEA、Tibco 等)以及其他具有引用规范的实现的厂商(如 Apache、Sonic、Systinet、BlueTitan、SA 等)之间的互操作性测试。
该概要根据其中的基本规范进行组织。每个规范都有自己对应的部分,其中包括与该规范相关的一致性目标(如 MESSAGE、ENVELOPE、DESCRIPTION 等)。
在所有情况下,基本规范均为标准化规范,概要中另有特别说明的例外。通常,这意味着概要不会重新声明给定规范的基本要求,除非有需要澄清的不明确之处。其中的基础规范均符合其原始定义,必须严格按照基础规范的声明进行实现。
每一节都包括一个或多个子节。每个子节都包含以平实的语言根据上下文提出相关要求的陈述。陈述之后为一组要求,采用相当简洁的形式对约束进行了阐述,或者根据 RFC2119 语言(MUST、SHOULD 等)的强制级别确定的一致性目标(MESSAGE、ENVELOPE、DESCRIPTION 等)。例如:R1001 在 ENVELOPE 中,wsrm:Expires 元素的值不能为“P0S”。
通常,要求之后有解释,以说明采取相应决策的原因。在可行(且资源允许)时,本概要提供了与该部分中要求相关的正确用法和不正确用法的示例。
- 本文关键词:

