OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: SOAP extensions best practices: a Reliability container element?


Title: SOAP extensions best practices: a Reliability container element?

This can be seen as an editorial comment for the schema:

There seems to be a best practice pattern in using SOAP header extensions, that we don't follow in WS-Reliability: If you look at several WS specs (either open or not), you'll find that they package all their extension material in a single Header block. This is wise as there may be many header blocks related to various specs. Using a single element makes it easier to refer to it in always the same way (e.g. with XML Dsig).

E.g. WS-Security uses a unique <wsse:Security> header child element to contain all possible security options and subelements. The content may vary widely from a message to the other, depending on security features being used, but everything that relates to Security in the message is withing this container element.

 
So Hamid and I propose for WS-R to always embed any RM-related header that may
appear in a message, (a request, a response, a Poll request...) within a "Reliability" container element.
We would have for example:

<soap:Header>
<RM:Reliability>
<Request>
...
</Request>
</RM:Reliability>
</soap:Header>

In case of piggybacking a Response with another reliable message:

<soap:Header>
<RM:Reliability>
<Request>
...
</Request>
<Response>
...
</Response>
</RM:Reliability>
</soap:Header>

Same for PollRequest.

Having discussed with Sunil, that would reduce the concerns he had on the naming of our header elements. In other words, using general names like Request, Response, would not be an issue within a Reliability container.

I know there is not much time for resolving this, so if it appears to be contentious I would not insist. I submit this because we believe the change is mostly editorial. It affects the schema of course, but mostly as a minor extension, no impact on how we treat it in the spec.

Let me know if you see this as "reasonable" enough to agree on by next week.

Jacques



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]