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: RE: [wsrm] detailed proposal to remove Message Header from Poll message and to merge MessageHeader and Request elements


Title: RE: [wsrm] detailed proposal to remove Message Header from Poll message and to merge MessageHeader and Request elements

It seems that the original reason for keeping in a separate/external header (MessageHeader) elements  that could possibly be "reused" from other SOAP extensions(like message ID) does no longer hold, as all elements inside MessageHeader need be under control of the RMP and have very specific meaning for RM.

In that case I have no problem merging MessageHeader  with RM Request.

Also OK with the rest of the proposal, except for one more renaming I suggest:

Collapsing MessageHeader into RM:Request emphasizes the term "Request":
I find the name RM:Request a bit confusing.
A request usually expects a "response". But RM requirements don't always
ask for responses such as an Ack.
Plus, "Request" and "Response" are quite overloaded terms, and when used with an RM meaning, they seem to imply a "binding" with a similar MEP (WSDL), where in fact they should remain orthogonal. An RM:Request could apply to a WSDL "response" as well.

I propose to rename RM:Request into RM:Requirement.

Jacques



-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com]
Sent: Friday, February 20, 2004 1:43 PM
To: wsrm
Subject: [wsrm] detailed proposal to remove Message Header from Poll
message and to merge MessageHeader and Request elements


Proposal to resolve New issue on need for MessageHeader in Poll Request:

If a poll request is not piggybacked on a reliable message request., it
does not need a message header. There is no meaning to expiry time for
the poll request, and there is no need for a message id for the poll
request itself.

It would simplify the protocol if the poll request message, which is not
itself piggybacked on a new reliable message request, does not include
the request header.

In addition, this change would allow the Request header to be merged
with the MessageHeader, so further simplify the protocol processing.

<JD>I was fine with removing the Message Header from Poll / Ack / Fault,
but merging MessageHeader with Request is going far beyond that...
In any case, it seems that we need to keep a "request-response - neutral" element
to hold values that are common to all reliable messages (expirytime, ID, seqnum)
Also I thought we had decided to

Detailed Changes Required:

Lines 873 and 874 have the following Sentence:


A RMP MUST include a MessageHeader element in a Reliable Message, a
PollRequest
message, an Acknowledgment message, or a Fault message.

Change this to the following:


A sending RMP must include a MessageHeader element in a Reliable message.

lines 900 and 901 state the following:


The RMP MUST include the MessageId element for Reliable Message,
Acknowledgment
message, Fault message and PollRequest message.

This needs to be changed to the following:


The sending RMP must include the MessageID element for a reliable message.

Merge the existing section 3.2 into Section 3.1. add the three child
elements “ack requested”, “DupicateElimination”: and “MessageOrder” at
the end of the MessageHeader.

Rename the new merged section 3.1 to be “Request Element”

Change all occurences of “Message Header” to “Request Element in the
entire document.

<JD> Isn't that too much? Isn't that just intended to mean the ReplyPattern element
will now be included in Request Element (for requests) and Response element (for responses)?
</JD>

Remove the “InvalidMessageHeader” fault from the tables in section 3.1
before line 954

Merge the explanatory text after line 1266 in table 18 from the
InvalidMessageHeader fault into the InvalidRequest fault: as follows:


InvalidRequest -
This fault is sent when the Request element is wrong or invalid.
Examples are:
1.When any of the mandatory elements such as MessageId, ExpiryTime,
ReplyPattern are missing
2.SOAP:mustUnderstand attribute is missing
3.When AckRequested, DuplicateElimination or MessageOrder elements
appear twice
4.SOAP:mustUnderstand attribute is missing

.Change the message format pictures in Section 3 to take MessageHeader
out of the poll response message.

Change the message format pictures in Section 3 to merge MessageHeader
and Request element into a new Request element.

Lines 1099 thru 1101 , in the existing section 3.3 state the following:


A sender MUST include the PollRequest element only in the PollRequest
message as shown in
the Figure6. The PollRequest message contains two direct child elements
for SOAP Header
element. The one is MessageHeader element, and the other is the
PollRequest element.

change this to the following:


A sender MUST include the PollRequest element only in the PollRequest
message as shown in
the Figure6. The PollRequest message contains the PollRequest element.






--
----------------------------------------------------
Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133





To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



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