Introducing the RAMP Profile

The profile formerly known as the IBM Basic B2B Profile


In April of 2005, IBM published the first public draft of the IBM Basic B2B Profile. At that time, I wrote a paper (see Resources) that provided some background on the motivation behind this work and indicated that, as we continued to receive feedback from our customers and the public, we would revise the profile as needed.

We have indeed received lots of valuable feedback on the initial draft, and we have incorporated that feedback into a second, renamed revision; the Reliable Asynchronous Messaging Profile (RAMP) 1.0 (see Resources).

As I indicated in my previous paper, we began this initiative in order to better understand how our customers intend to leverage web services standards. We have been working in close collaboration with our clients to better understand their requirements and to amend the profile accordingly. I am pleased at this time to note that as of this second revision of the RAMP 1.0 profile, one of the most significant changes, aside from the name change, is that Ford Motor Company and DaimlerChrysler have both been added as co-authors of the specification. This is an important milestone, as it clearly demonstrates support from key consumers of the technologies.

What was changed in this revision?

In addition to the recognition of DaimlerChrysler as a co-author, there have been some minor editorial changes reflected in the current draft, including the rewording of two of the requirements -- R0011 and R0012 -- to reflect the correct target (ENVELOPE versus DESCRIPTION) and the correction of the URL location of the feedback agreement.

What was changed in the second revision?

There have been a few other changes made in the technical aspects of the profile. Most notably, we have added support for use of the WS-Secure Conversations specification (WS-SC) (see Resources) for the performance benefits and for the more robust degree of security that it enables for reliable messaging sequences. There is still work to be done to develop requirements related to the use of this technology, but we felt it important that we include the WS-SC specification in the scope of the profile now in order to clearly signal the direction that the profile will take, rather than wait until we had worked out all the interoperability details.

Additionally, we made a few less radical changes to certain requirements. Each of these changes, aside from obvious editorial tweaks, has been discussed in our Google Group discussion forum (see Resources). Among the changes made, we aligned the requirement for the cardinality of wsa:To header blocks with technical resolutions made by the W3C WS-Addressing WG. Previously, the profile had permitted at least one wsa:To header block. The technical resolution taken by the W3C WS-Addressing WG was to constrain the cardinality of this SOAP header block to a single occurance.

Industry support for the profile

Through discussions with clients such as Ford Motor Company, it became clear that the RAMP profile has applicability within the automotive industry, particularly, but not exclusively, within the supply chain integration space. All three clients explained to us their need to improve integration, both within their businesses and between their business and their partners. We see the RAMP profile as a solid step toward addressing these requirements. We believe that its applicability will extend beyond the automotive industry into finance, healthcare, and many other industries, and we believe it is designed such that other more comprehensive and domain-specific profiles can be developed that reference the RAMP profile, either extending or constraining its scope.

What is a profile?

A profile is a named set of web services specifications that are composed to achieve a specific functional scope. In an ideal world, where specifications contain no optionality or ambiguity, a profile would be just a list of specs that compose together to achieve a given function. However, as we all know, we don't live in an ideal world. Hence, it is necessary that the profile provide constraints and guidance in the form of requirements as to the interoperable usage of the underlying specifications in the scope of the profile. The guidance and additional constraints are typically based upon implementation experience. In the case of the RAMP profile, that experience has been in the form of interoperability testing between the specification authors (IBM, Microsoft, BEA, Tibco and others) as well as others who have implementations of the referenced specifications such as Apache, Sonic, Systinet, BlueTitan, SAP, and others.

The profile is organized around base specifications referenced within it. Each specification has its own section that includes the requirements related to the conformance targets relevant to that specification (such as MESSAGE, ENVELOPE, DESCRIPTION, and so on).

In all cases, the base specifications are normative unless the profile specifically states otherwise. That means that the profile does not, typically, restate the underlying requirements of a given specification unless there is some ambiguity that needs clarification. The underlying specification is taken at face value and must be implemented exactly as the underlying specification declares.

Within each section, one or more subsections are included. Each contains a statement in English prose that places the related requirements into context. The statement is followed by a set of requirement(s), that are written in a rather precise format and that articulate some form of constraint or clarification of the underlying specification in regards to identified conformance target (MESSAGE, ENVELOPE, DESCRIPTION, and so on) qualified by an imperative level based on RFC2119 language (MUST, SHOULD, and so on) By way of example: R1001 In an ENVELOPE, the value of the wsrm:Expires element MUST NOT be 'P0S'.

The requirements are typically followed by an explanation as to why the decision was taken. Where practical (and resource permitting), the profile provides examples of both incorrect and correct usage related to the requirement(s) in that section.

Philosophy of the profile

The RAMP profile is being developed using the same set of guiding principles that are being used for the WS-I profiles. The primary motivation is to improve the potential for interoperability by constraining optionality of the underlying specifications and providing guidance as to how the various specifications compose with each other.

Scope of the profile

Just as with the WS-I profiles, the RAMP profile has a scope that is defined by the set of referenced specifications. The profile attempts to improve interoperability within its own scope by constraining optional features of the referenced specifications, clarifying ambiguities in the referenced specifications, and providing guidelines for use of the referenced specifications, especially in conjunction with one another. The profile does not impose constraints on that which is out of the scope of the profile.

The scope of the Basic B2B Profile is as follows:

  • Basic Profile 1.1
  • Simple Soap Binding Profile 1.0
  • Basic Security Profile 1.0

In the case of the RAMP profile, three of the referenced specifications in its scope are, in fact, profiles themselves: the WS-I Basic Profile, Simple SOAP Binding Profile, and Basic Security Profile. These provide the underlying messaging, description, and discovery framework basic to all web services and the message-level security characteristics necessary for many B2B integration scenarios.

The WS-Addressing specification adds functionality necessary to enable the types of message exchange patterns demanded by B2B integration scenarios. The WS-Reliable Messaging specification adds the reliable delivery semantics required for many B2B integration scenarios.

The WS-Secure Conversation specification adds support for session-based security tokens that enable higher performance than does the use of WS-Security and one or more of the security token profiles included in the scope of the WS-I Basic Security Profile alone. Additionally, use of WS-Secure Conversation enables more robust security for the WS-Reliable Messaging Sequences, especially in situations where there might be intermediaries involved in the exchange.

Constraining the underlying profiles

In developing the Basic B2B Profile, we had initially intended to leverage the referenced WS-I profiles "as-is." However, as we analyzed the client requirements, it became clear that the derivative profile might improve interoperability by further constraining the underlying profiles.

Constraining the basic profile

One of the complaints that has been raised by some with regards to the WS-I Basic Profile is that it didn't go far enough in reducing choice. Specifically, that it permitted use of either rpc-literal or document-literal style web services. Many have suggested that it should be one or the other, and more specifically, that it should have chosen document-literal as the exclusive style of describing a web service.

The client requirements for use of web services in the context of B2B interactions within the automotive community are for use of document-literal style, using the Open Applications Group (OAGi) Business Object Documents (BODs). Thus, the profile constrains the referenced WS-I Basic Profile by eliminating the option of using the rpc-literal WSDL authoring style. It is hoped that this constraint of the Basic Profile will help improve interoperability.

Although the profile constrains against use of the rpc-literal style, the profile does provide a definition for the "document-wrapped" WSDL style; a commonly used pattern for describing what amounts to an RPC, but using the document-literal style.

Constraining the Basic Security Profile

Although WS-I is still working on finalizing the Basic Security Profile, there is one aspect of the BSP that we felt needed to be further constrained -- the choice of encryption algorithm. The BSP permits use of either RSA 1.5 or RSA OAEP algorithms. The Basic B2B Profile constrains that choice to the more widely implemented RSA 1.5.

As we get more experience and feedback, we might find it necessary to further constrain the BSP.

Overriding the Basic Profile

While every effort was made to abide by the guidance of the underlying referenced profiles, the fact remains that certain requirements of the Basic Profile proved too constraining. Specifically, WS-I Basic Profile requirements R2714 and R2750 state that the HTTP response message to a one-way operation must have an HTTP response code of "2xx" with an empty entity body, and that the receiver must ignore any SOAP envelope present in the entity body of an HTTP response message. In the context of web services using WS-Reliable Messaging, certain usage patterns might require a SequenceAcknowledgement to be returned in the HTTP response message (for example, when the RM Source is hidden behind a firewall). In the context of a one-way message, the practice of returning a SequenceAcknowledgement would normally be disallowed by the WS-I Basic Profile. Thus, it was necessary that the RAMP profile explicitly permit this, overriding the constraints imposed by the Basic Profile.

Adding support for asynchronous messaging

While the WS-I Basic Profile enables certain forms of asynchronous message exchange patterns, such as defined in the basic callback usage scenario, it does not specify the means by which the addressing information must be expressed, leaving that to be done using extensibility points.

With the submission of the WS-Addressing specification to the W3C last summer, the industry seems to be coming to consensus as to the means by which addressing information will be expressed as SOAP header blocks. Thus, the choice of which web services specification to include in the scope of the profile to address the functional requirements related to asynchronous message exchange patterns was fairly straight-forward.

The profile specifies requirements as to which of the WS-Addressing elements are required to be present in every message (wsa:To, wsa:From, wsa:Action, wsa:MessageId), and which messages must have a soap:mustUnderstand attribute with a value of '1' (wsa:ReplyTo). Additionally, it specifies when it is appropriate to include a wsa:ReplyTo SOAP header block.

An additional requirement has been added that clarifies the expectations in the context of a request message with a wsa:ReplyTo. Specifically, the HTTP response message might be empty (because the response message is intended to be sent to the endpoint specified in the wsa:ReplyTo instead of being carried in the HTTP response message) and carry a 202 HTTP response code.

Finally, the profile addresses the composition of WS-Addressing and WS-Security (BSP) by indicating which of the WS-Addressing SOAP header blocks should be digitally signed to protect the integrity of the message.

What about the W3C WS-Addressing specification?

As the work of the W3C web Services Addressing Workgroup progresses towards Recommendation status, we intend to replace the reference to the WS-Addressing Member Submission with the specification(s) produced by the W3C once they reach either Candidate or Proposed Recommendation status.

Adding support for Reliable Messaging (WS-RM)

The choice of specification to satisfy the reliable messaging requirements for B2B supply chain integration was not as easy, because there are at least two notable specifications from which to choose. The WS-Reliability OASIS Standard, and the WS-Reliable Messaging specification. Ultimately, the decision was made to go with WS-Reliable Messaging because it has been specifically designed to compose with WS-Addressing and WS-Security (as well as a number of other WS-* specs) and because IBM is one of the principle authors of the specification (in all candor, I am the IBM technical lead and co-editor of the WS-Reliable Messaging specification, so I may be a little biased).

As with WS-Addressing, the profile provides guidance as to which of the WS-RM elements must include a soap:mustUnderstand attribute with a value of '1' (wsrm:Sequence). It also provides guidance as to how the specification should be used in composition with WS-Addressing by constraining against the use of the WS-Addressing Anonymous Uniform Resource Identifier for the value of the wsa:ReplyTo SOAP header block in the context of an input (request) message of an operation that is using WS-RM for both the request and response messages of the operation.

Finally, the profile adds guidance in regards to composition with WS-Security (BSP) by specifying which of the WS-RM elements needs to be digitally signed along with the contents of the SOAP Body to ensure the integrity of the Sequence (wsrm:Sequence, wsrm:SequenceAcknowledgement).

What's next?

The RAMP 1.0 profile, published on August 4, 2005, represents the second public draft of what had previously been labeled the RAMP profile. We fully expect that as we continue to work with our clients to develop usage patterns for the profile, as we receive feedback from the pubic, and as we gain implementation experience through proof-of-concept demonstrations and interoperability testing, that the profile will evolve further. For instance, there has been some discussion regarding the addition of support for SOAP attachments. Additionally, there is still much work to be done with regards to fleshing out the requirements related to the recent addition of the WS-Secure Conversations specification. We invite anyone in the web services community to participate in the further development of the RAMP profile by participation in our Google Group discussion forum.

Ultimately, we hope that the RAMP 1.0 profile and the usage patterns which are developed to supplement it are taken up by WS-I, revised as needed, and published in Final form by WS-I. We are eager to see others working on the adoption of web services use this work as the basis for their own (we are eager to see the Open Applications Group (OAGi), the Automotive Industry Action Group (AIAG), and other industry sector organizations referencing the profile and usage scenarios in their work the same way organizations such as HR-XML have begun referencing the WS-I Basic Profile). Finally we hope this effort will contribute to web services becoming a useful integration technology, and to that end, we encourage all parties to contribute to this work, and adopt it, and use it in your products and solutions.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=SOA and web services
ArticleTitle=Introducing the RAMP Profile