Note: This article assumes the reader has a cursory knowledge of the WS-RM and WS-Polling specifications. See the resources section for some pointers to read up on the specs.

What problem is WS-RM trying to solve and why?

During the course of its work, the WS-RX Technical Committee (TC) ran into a problem that many people are also encountering: delivering SOAP messaging to an endpoint that, for any number of reasons, can't accept new incoming connections. For the WS-RM specification, this is particularly troublesome since a key component of its processing model is the ability for a sending endpoint to retransmit, at its own discretion, unacknowledged messages to the destination endpoint. We'll now look at a simple example to show how, without this ability, the WS-RM endpoint is unable do its job.

Take the case of a simple series of request-response messages being sent between two endpoints. Each request must be delivered reliably and in order to the service. And likewise each response to those requests must be delivered reliably and in order back to the requester. In an environment where the requester and the service can initiate new connections to each other, the WS-RM logic in each endpoint is free to transmit unacknowledged messages, as well as acknowledgements, to the other side as needed

However, we'll make the environment a little less "open" by adding a firewall. Assume the requester is sending its messages to a service outside the company's intranet. The odds of the service being able to asynchronously create new connections back to the requester through the firewall would drop to almost zero. This means that when the service tries to do its normal WS-RM logic of resending messages, or sending acknowledgements, it can't. The only way to create new connections between the two endpoints is if they are initiated by the requester. By doing so, the requester is asking if the service has any pending messages for delivery. Typically this is referred to as "polling" for messages. (For our purposes we will refer to endpoints that can't accept new incoming connections as "nonaddressable" endpoints).

In order to solve the problem of (re)transmitting messages to a nonaddressable endpoint, the WS-RX TC examined several possible solutions. However, all but a polling type of solution was rejected for one reason or another. The biggest problem the TC ran into with other solutions is that it involved a change to the normal WS-RM processing logic. For example, take a situation in which a request message was delivered (and acknowledged) but the response was lost. In this case, one proposed remedy would be for the requester to resend the request message, thus providing a backchannel on which to send the missing response. This is a bit of a change for the requester because under normal WS-RM processing rules, once a message is acknowledged, it would not need to be resent.

Another key issue the TC addressed was the ability for a WS-RM endpoint to continue to have the same freedom to choose which WS-RM sequence to use (if any) that it would have if it could initiate new connections. For example, in our scenario, the service would decide which WS-RM sequence to use for each response message. It may, for whatever reason, decide to place each one into its own sequence. Or, if the existing sequence appears to be running into problems, it could close it down and start a new one. These types of decisions are critical to a WS-RM endpoint's ability to do its job. Most non-polling types of solutions involved the destination of the messages (the requester in our scenario) being in control over the response sequence -- a job normally for the service side. Again, this would be quite a change to the normal WS-RM processing logic.

After hours of discussions, the TC decided that the best option available would be to keep the WS-RM logic separate from the actual transportation of the SOAP messages themselves. This means that they wanted to keep the WS-RM processing logic unchanged but still allow for the receiving endpoint (the one behind the firewall in our scenario) to initiate the new connections. Obviously, any kind of polling solution is a change to the endpoints but the change to the WS-RM logic itself should be minimal. This was viewed as a critical requirement.

While the problem of getting messages to a nonaddressable endpoint is one that many people encounter, it clearly is not a WS-RM-specific issue. So, why did WS-RM choose to solve this problem instead of letting some other specification (like WS-Polling) solve it?

There is no single or easy answer to that question. Many members of the TC were hearing from customers that this problem needed to be solved quickly; they had immediate needs for a standard (and interoperable) solution. Paying customers are always a good motivator.

Another factor in the TC's decision was that the purpose of the WS-RM specification, as the name suggests, is "reliable" delivery of messages. While before this issue arose, "reliable delivery" focused heavily on resending messages until they were acknowledged, it was argued that reliability could, and should, be extended to include the message delivery to nonaddressable endpoints.

And finally, another major reason the TC didn't avoid this issue (and this relates to the first one), is because several other specifications were already developing their own polling type of solution. This meant that there would not be one single way to solve this problem, but rather several. And worse, each one was solving the problem in their own domain-specific way. The industry would be much better served if there was a single solution that worked for all domains. With WS-RM becoming a core specification that most SOAP stacks will support, it was likely that the solution developed by the TC would be as widely adopted and supported as possible.

It is worth noting, as many people have, that because of the pervasive nature of this problem, this really should have been solved in the WS-Addressing specification. While a good argument could be made for that, the W3C's WS-Addressing Working Group had already closed down their specification. So if the community wanted a solution promoted within a short time frame, it would be up to WS-RM to provide it.

WS-RM's Solution

In the previous section we discussed how the receiving endpoint (the endpoint able to initiate connections) must be responsible for establishing each new connection. Normally, this is viewed as "polling" because that endpoint is asking the other endpoint for a message. While the WS-RM specification does define a mechanism by which the destination endpoint can establish new connections, it's important to understand that this action is not polling for a message. This important concept is crucial in understanding how WS-RM solves the problem.

Before we get into why the term "polling" isn't appropriate, we'll examine what the WS-RM specification defines. First, the WS-RM specification defines a new URI template:

http://docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id={uuid}

This URI is a "template" because when it's used, the "{uuid}" portion is meant to be replaced with a unique uuid, thus allowing this URI to be uniquely identifiable from other instances of this URI. However, the semantic meaning of this URI remains the same no matter what the uuid value is. This URI is defined to serve two purposes. First, it has the same semantic meaning as the WS-Addressing anonymous URI. In other words, when used in an Endpoint Reference (EPR) such as wsa:ReplyTo, it means that any response message should be sent back on the transport-specific back channel or, in the HTTP case, the HTTP response flow. This is typically used for synchronous request-response message exchanges.

The second semantic meaning of this URI applies when the original transport-specific back channel is not available (for example, the connection was broken). In those cases, this URI uniquely identifies the endpoint that created the original connection. Or, said another way, when the original transport-specific back channel is no longer available, the service can hold onto any messages targeted to this URI until a new connection from that same requesting endpoint is made and then return the message on that new connection's back channel. If the static WS-Addressing anonymous URI were used, there wouldn't be any uniquely identifying information in the URI to distinguish one "anonymous" endpoint from another.

Next, the WS-RM specification defines a new one-way operation that an endpoint can send to create new connections:

<soap:Envelope ...>
  <soap:Header
    <wsa:To> some service </wsa:To>
    <wsa:Action> http://...wsrx.../MakeConnection </wsa:Action>
  </soap:Header>
  <soap:Body>
    <wsrm:MakeConnection ...> 
      <wsrm:Address ...> xs:anyURI </wsrm:Address>
    </wsrm:MakeConnection>
  </soap:Body>
</soap:Envelope>

In our scenario, the endpoint behind the firewall (the requester) would use this message and specify a wsrm:Address element as a child of the wsrm:MakeConnection element that contains the URI that identifies the initiator of the message; in other words, it would normally contain a WS-RM anonymous URI template (as defined above). The endpoint that receives this message would then be free to use the transport-specific back channel to send any message that is targeted to this URI. While the result of this message exchange is that the requester has initiated a connection and the appropriate message has been sent back, it's again important to note that the requester did not poll for a message. Now we'll examine why this distinction is so important.

First, we need to understand why the MakeConnection operation is a one-way operation and not a request-response message exchange. Under normal WS-Addressing request-response processing rules, the request message in a request-response message exchange should contain a wsa:ReplyTo EPR (or it defaults to "anonymous"). This EPR is then used for two purposes: 1) as the [destination] EPR of the response message, and 2) the response message is sent to this EPR.

If the MakeConnection operation followed these rules, then any message sent "in response" to it MUST have its [destination] EPR set to the wsa:ReplyTo of the MakeConnection message, and not the wsa:ReplyTo of the original request message that caused the response message to be generated in the first place. If these two EPRs are not exactly the same, we run into the problem of either violating WS-Addressing rules if we don't change the message to match the MakeConnection's wsa:ReplyTo EPR; or if we do change it, we could end up routing the response message to the wrong location because it no longer uses the wsa:ReplyTo of the original request message. (Remember, reference parameters may be critical in routing the message). To avoid these types of issues, MakeConnection is defined as a one-way operation.

So, if MakeConnection is a one-way operation, we need to understand why the receiver of this message is able to use it at all and doesn't just send back something akin to an HTTP 202 Accept response. To understand this, we must examine how WS-RM uses the transport-specific back channel when the wsrm:AcksTo EPR is set to WS-Addressing's anonymous URI.

When an RM Source sends a CreateSequence to an RM Destination and specifies the WS-Addressing anonymous URI in the wsrm:AcksTo EPR, it means that acknowledgements must be transmitted on the transport-specific back channel. So in cases where there is no message to be sent back to the RM Source (for example, the wsa:ReplyTo of the request message was not anonymous), the RM Destination may create a new SOAP envelope for the sole purpose of transmitting an acknowledgement and send it on the back channel. And, in cases where the RM Source (for example, the requester) is not expecting anything on the back channel, it still must examine the response to see if there is a SOAP message that needs to be processed.

This is the same logic that the MakeConnection operation uses. In other words, the purpose of the MakeConnection message is to not ask (or poll) for a message, but instead it simply creates a new connection, identifies who initiated it, and at that point the receiver is free to use the empty response flow to carry a message targeted to that initiator. By doing this, we get the same result as with a traditional polling mechanism, but without having to then worry about violating WS-Addressing processing rules or incorrectly changing the message itself.

The use of MakeConnection, as described above, allows any message targeted to the specified URI to be transferred. This means that while this mechanism is being defined in WS-RM, it in no way requires that only WS-RM protocol messages, or application messages that are being transferred using WS-RM, be sent in response to a MakeConnection message. The receiver of this message can send any message targeted to that URI. This allows a synchronous environment to try to simulate an asynchronous one -- or said another way, the sender regains control over which message to send to any particular endpoint. The only aspect of the message exchange that it can't control is the establishment of the connection itself, which unavoidable due to the nature of nonaddressable endpoints.

The MakeConnection element allows for other identifying information other than a destination URI to be passed in. Following is the full pseudo-schema of the MakeConnection element:

<wsrm:MakeConnection ...> 
  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ?
  <wsrm:Address ...> xs:anyURI </wsrm:Address> ?
  ... 
</wsrm:MakeConnection>

Notice that it allows for a wsrm:Identifier to be passed in. This allows for the sender of this message to request that only messages related to the WS-RM Sequence specified be sent on the back channel. Unlike the wsrm:Address element, this restricts the types of messages that may flow on the back channel. It should be used only in cases where a tight coupling exists between the RM Source and RM Destination because the receiver of this message doesn't have the full flexibility of a traditional WS-RM endpoint.

For example, it will not be free to create new sequences as needed because the sender of the MakeConnection will never know that new Sequence identifier to specify in a MakeConnection message. Also, the use of the wsrm:Identifier element does not restrict the messages to a single target URI. Notice that any message related to the WS-RM Sequence in question may be transmitted regardless of where it is targeted.

And finally, notice the extensibility point in the MakeConnection that allows for other types of identifying information to be passed in (as I will discuss later) assuming the receiver of this message understands that data. If more than one type of data is passed in, they must be logically 'and'd together.

Other use cases

So far, we've focused on the simple request-response use case. However, it's important to point out that many other message exchange patterns require this feature and it was the desire to support these as well that drove the TC to adopt such a broad solution. Below we'll examine a few of the more prominent ones.

The WS-RM specification places no restriction on the scope of a sequence. This means one sequence can be used for messages that span multiple endpoints, and conversely, multiple sequences can be used when sending messages to a single endpoint. The WS-RM anonymous URI does not restrict this feature. In a truly asynchronous environment, the creator of an EPR is free to use any values it deems appropriate. For example, it may choose to use the same EPR for many sequences. Likewise, when using the WS-RM anonymous URI, the creator of an EPR may choose to use the same URI many times. This would have the effect of sending many different messages to the same endpoint

As previously mentioned, one solution to the resending of an unacknowledged response message involved resending the request message even if it's been acknowledged. This solution was rejected because it required a change to the normal WS-RM processing model. But there was also another reason. Take the case of a single-request/multiple-response message exchange pattern. In this scenario, it doesn't make sense to continue to resend the request message past the delivery of the first response. The requester may not know how many responses are to be sent, so it may be unnecessarily resending all request messages simply because some of them may generate more than one response. By sending just a single message that can be used to send back all possible messages (responses or any other message), a much more optimized interaction occurs.

Related to the previous use case is the out-only message exchange use. For example, take the case of a subscription manager -- one where there is no request message at all but the receiver of the events (being behind a firewall) still must initiate the connections. In this case, again, a generic operation like MakeConnection allows for a single message to be used to initiate the flowing of any appropriately targeted message. All the subscriber needs to do is use the RM anonymous URI in its subscription EPR. (See the MakeConnection example in the appendix of the WS-RM specification for more details.)

Note that the use of the WS-RM anonymous URI in an EPR can be used even when the rest of the WS-RM spec is not used or even supported. This means that the traditional "replay until acked" portion of WS-RM does not need to be used or even implemented by an endpoint that wishes to simply support this message retrieval mechanism.

One final use case is related to the previous one: as noted, MakeConnection can be used with or without WS-RM Sequences. This means that the endpoint trying to send the messages to the unreachable endpoint retains the choice of whether to use WS-RM's sequences or not. When reachable endpoints are used in EPRs, the endpoint trying to send messages to those EPRs is free to decide whether or not to place those messages inside a WS-RM sequence (leaving aside policy constraints for the purposes of our discussion).

So, because MakeConnection allows any message targeted to that URI to be sent, it doesn't require additional constraints (like the use of sequences) on the sending endpoint. Said another way, MakeConnection allows for both WS-RM- enabled and non-WS-RM-enabled messages to be returned, allowing the sender of those messages to retain that choice.

Other tidbits

One last feature of WS-RM's MakeConnection is the MessagePending SOAP Header:

<wsrm:MessagePending pending="true" />

This header may be included in any message to indicate that additional messages are waiting to be sent, thus allowing the receiver of this header (the sender of a MakeConnection) to send another MakeConnection right away instead of waiting for its normal delay.

One point is worth repeating. The WS-RM specification tried to split the mechanism by which messages are delivered from the generation of the messages themselves. This allows for all non-transport-related logic to remain virtually unchanged in these nonaddressable endpoint scenarios. One obscure implication of this is that when the messages are being sent within an RM sequence, receiving a MakeConnection does not necessarily mean that a message should be sent back on the back channel. In other words, the WS-RM logic that determines when a message should be sent (or resent) should not change simply because MakeConnection is being used. When a MakeConnection is received by an endpoint, it shouldn't go out of its way to construct a message. Nor should it resend an unacknowledged message if it wouldn't have done so at that time, had the target of those messages been an addressable endpoint.

One of the objectives of introducing MakeConnection is to limit its impact on nontransport code, thus relegating MakeConnection to simply another transport mechanism. See the next section for more information.

If the receiver of a MakeConnection does not have messages ready to be sent to the initiator of that connection, then an empty response should be sent back. For example, in the HTTP case, a HTTP 202 Accept should be returned.

Implementation impact

In order to support MakeConnection, as with many new features of any Web services specification, existing SOAP implementations will be impacted. While on the surface this type of message delivery mechanism may appear to be a radical change for implementations, it shouldn't be once WS-Addressing is implemented.

One of the most positive and significant impacts WS-Addressing had on SOAP implementations is that any existing synchronous request-response message exchange can become an asynchronous one by simply adding a wsa:ReplyTo header that contains an addressable URI. (Those not familiar with this concept should read the WS-Addressing specification for more details.)

The introduction of this ability now requires a Web service endpoint to support the idea that any response message that would have come back on the HTTP response flow can now come back on a completely different connection. This is an excellent development because it helps reinforce the notion that SOAP is nothing but a series of one-way messages. Any relationship between messages must be specified within the message itself and not tied to any implicit relationship that may be offered by the transport itself. In other words, simply because HTTP has a request and a response flow, the client can no longer assume that the message on the response flow is the response or is even related at all to the request message. Obviously, there are plenty of times when it will be, but WS-Addressing now allows for the possibility that it just as likely may not be. The SOAP endpoint must now examine the contents of the message to make any correlation between messages, thus implying that the transport mechanism (or protocol) used to move messages between endpoints is truly orthogonal to the content or relationship of the messages themselves.

Another way to view this change is that implementations should no longer assume that a message carried on an HTTP response flow is related to the message carried on the HTTP request flow. WS-RM takes advantage of this feature in its acknowledgement processing. When a new sequence is created, the RM Source specifies a wsrm:AcksTo EPR. This is the endpoint to which the RM Destination must send acknowledgements. If this EPR contains the WS-Addressing anonymous URI, the acknowledgements must be sent on the transport back channel, in other words, the HTTP response flow.

Take the case of a request message flowing on a HTTP request flow whose wsa:ReplyTo is set to an addressable endpoint. Any response message will be sent on a new connection to the wsa:ReplyTo EPR. If that request message is being sent using WS-RM, and the wsrm:AcksTo EPR contains the WS-Addressing anonymous URI, then instead of no SOAP message flowing back on the HTTP response flow, a new SOAP envelope will be created for the sole purpose of sending back the WS-RM acknowledgement. This is an example of a case where the message flowing on the HTTP response flow is not the response message the client was waiting for. It is totally unrelated to the application data that was sent in the request. Thus, implementations can no longer rely on any correlation between messages simply because of the implied correlation of the transport.

Once this type of support exists, support for MakeConnection becomes trivial. We'll examine the impact by first examining the impact on the client (the endpoint sending the MakeConnection). There are two changes the implementation would need to make. First, it must be aware that there may be an endpoint holding messages to be delivered to it. How it knows this is an implementation detail. Some options include: the application notifying the SOAP code that it needs to check for messages on a certain endpoint; or the SOAP code examines outgoing messages for the WS-RM anonymous URI and infers that it needs to use MakeConnection. There are many ways this could happen, but somehow the endpoint must determine that since it can not accept new connections, it must use MakeConnection to get incoming messages.

The second change that a client endpoint would need to make, and this should be obvious, would be to send the MakeConnection message. Supporting this should be trivial because once the MakeConnection is sent, any message sent back on the response flow should be treated like any other message that may have arrived through some asynchronous mechanism.

Let's explore why this should be easy to support by examining what happens when a message is delivered to an endpoint through a new connection. At a very high-level view, in those cases some transport specific code will wait for a connection to be established, read the SOAP message from the connection, and then hand it off to the rest of the SOAP engine for processing. There is a distinct split between the transport code and the rest of the SOAP engine. The implementation of MakeConnection can use this split. When a message flows back as a result of a MakeConnection, that message can be handed off to the SOAP engine the exact same way a new message was handed off to the SOAP engine in the asynchronous message delivery case. The receipt of a message using MakeConnection should be viewed as nothing more than another transport. By doing this, the impact to the client endpoint, with respect to its processing of new incoming messages, should be minimal.

We'll now examine the server side, or the endpoint needing to send messages to the non-addressable endpoint. Again, the impact here should not be major. At a high level, if the server endpoint views a MakeConnection message as a one-way message that does nothing then it would normally not send any message back at all. In the HTTP case it would just send back an HTTP 202 Accept response with no content. Right before the empty response is sent back, the server can simply use the correlation information in the MakeConnection message, find a message (if any) that is targeted to the client, and then send it back in place of the empty message. Notice this is not that different from how WS-RM uses empty response flows to send new SOAP envelopes to carry WS-RM acknowledgements. Only in this case, we're not sending acknowledgements, we're sending a SOAP envelope that had been previously created and was waiting to be delivered. But conceptually, it's really not any different. Like we saw with the client, the impact to the server should be minimal.

There is one more piece to the server-side implementation. It must hold onto the outgoing messages until the appropriate MakeConnection comes in. And depending on the implementation choice, this could be lightweight (for example, an in-memory persistent store), or a bit more heavy-duty (for example, use of DB2 to hold the messages). Either way, this persistent store should not impact the existing SOAP code itself.

Comparison with WS-Polling

WS-Polling was submitted to the W3C as a Member Submission in October 2005. At the time, it was being made available for consideration as a new specification or for incorporation into an existing standards group. Before a decision was made as to whether or not a new WG should be started, the WS-RX Technical Committee ran into this "nonaddressable" endpoint problem, and the decision of what to do with WS- Polling was put on hold until after the WS-RX TC resolved the issue. It was decided that if the WS-RX TC adopted a solution that satisfied the same requirements as WS-Polling, there would be no need to pursue a separate standards track.

From our discussion of the MakeConnection operation, it's clear that MakeConnection provides a near-duplication of function with WS-Polling. Both provide a means to tell a sending endpoint that it should "buffer" messages when the transport back channel is not available. Both provide a means to identify which messages should be sent back in response to the establishment of a new connection. And finally, both provide optimization headers that allow for a more effective delivery pattern. However, there are some differences between WS-Polling and WS-RM's MakeConnection that should be discussed.

WS-Polling has a true "polling" operation. In other words, its version of the MakeConnection operation (GetMessage) is modeled as a request-response message exchange which means that all the problems we discussed above about why MakeConnection is a one-way operation, are also present in WS-Polling. So, in this respect, WS-RM got it right and WS-Polling (if it entered a standards track) would need to change to be a one-way operation.

WS-Polling's GetMessage operation allows the requester to specify a WS- Addressing MessageID as part of the identification information, meaning the requester was looking for any response message to a request message with the specified MessageID. While this is an interesting feature, during the discussions around WS- RM's MakeConnection, it was determined that it was too much of an "edge case" and that the specification of the target URI was sufficient. However, since MakeConnection is extensible, implementations are free to define this type of identification element if they have a need for it.

The final significant difference between WS-Polling and WS-RM's MakeConnection is the WS-Polling wsp:To reference parameter. This reference parameter is designed to be included in an EPR so that it would then be included as a Header in messages targeted to that EPR. This header would then contain a URI identifying the true target URI of the message. Normally, because the [destination] EPR of these retrieved messages contains an anonymous EPR, it does not contain any routing information that would normally be there if the message was sent asynchronously. This wsp:To element was meant to be used to carry that information. Upon receipt of the polled messages, the initiator would examine this URI and use it instead of the wsa:To header to determine how to process the message.

WS-RM's MakeConnection does not have an equivalent concept. While the problem still exists, because the creator of the EPR is the same endpoint that will receive the messages targeted to that EPR, it is free to add whatever reference parameters necessary to successfully process the messages. This means that many implementations may still choose to add this type of reference parameter, and because it is not something the receiver of the MakeConnection message needs to understand or even process (except to follow the normal WS-Addressing rules), it wasn't viewed as a necessary part of the WS-RM specification.

The WS-Polling specification addresses an interesting use case that is worth mentioning -- the mailbox scenario. In this scenario, the service sends the messages to a mailbox endpoint rather than holding onto the messages. This is done by specifying the URI of the mailbox in the EPR provided to the service (for example, in the wsa:ReplyTo). The requester can then use WS-Polling's GetMessage operation to retrieve messages from the mailbox. The advantage of this scenario is that while the requester must still know that some type of polling mechanism is being used, the service itself doesn't. It simply follows the normal WS-Addressing rules. WS-RM's MakeConnection feature can be used the exact same way, meaning that it can be used to retrieve messages from a mailbox endpoint in a similar way that WS-Polling's GetMessage operation can. WS-Polling's GetMessage operation can. This allows the unreachable endpoint to use the same mechanism to retrieve messages from a mailbox as it would to retrieve them from a server.

Summary

So, what are the next steps for WS-Polling? In short, WS-Polling's "on hold" status will continue. Right now the WS-RM specification is under its public review cycle. When the specification is ratified as an official OASIS standard, and if the MakeConnection feature continues to fully satisfy all of WS-Polling requirements, then I expect WS-Polling to simply remain a W3C Member Submission, and no further work on it will be needed. For those who have supported WS-Polling, and for those who have actually implemented it, we recommended that you look toward WS-RM's MakeConnection feature for your needs.

I hope this extensive examination of the MakeConnection feature, along with the rationale behind some of its design decisions, and the possible impact on existing SOAP implementations, reinforces the idea that MakeConnection is not a polling feature, but rather simply another transport mechanism by which a SOAP message can be transferred between endpoints. And, given the impact that WS- Addressing has already had on SOAP implementations, support for MakeConnection shouldn't be as radical a change as it may initially appear.

Resources

• Find out about the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee.
  
  
• Learn more about the WS-RM specification .
  
  
• Read more about the WS-Polling spec.
  
  
• Read Doug Davis' article, on WS-Polling.
  
  
• Find more information about the WS-Addressing specification.
  
  

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• What problem is WS-RM trying to solve and why?
• WS-RM's Solution
• Other use cases
• Other tidbits
• Implementation impact
• Comparison with WS-Polling
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers