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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Comments on section 1.6 of Multi-hop Section Draft 0.11 (ebMS3-Multihop V11-SF.doc) uploaded


Lines 299 - 314, for forward routing, why do we need this new Refparam

When there is a need to create a WS-A reference parameter to route e.g. a
wsrm:CreateSequence message, the content of the parameter could be a copy of
the first eb3:UserMessage that wants to use the reliable sequence that is to
be established.   This works both in situations where these sequences are
created "just-in-time" and where they are created "ahead-of-time":  
- In the "just-in-time" case, the MSH is creating this UserMessage anyway.
If there is no(t yet or no longer any) sequence that the message can use, a
wsrm:CreateSequence can be sent with the UserMessage stored in the reference
- In the "ahead-of-time" case, the MSH could create sequences for all Pmodes
that require reliability, using the regular Pmode parameter values.  

If the values for Party, Role, Service, Action etc. that would be used in
the reference parameter are specified separately from the values for the
UserMessage element,  we also suggest that (or have to explain the meaning
of situations where) the values can be inconsistent, which I think is

For reverse routing, there is a valid question how the content of the
reference parameter in the wsa:AcksTo element is set. In a Two-Way MEP, it
could use the values for From, To, Service, Action etc. that would be used
in a business response message. When using ebBP, such values can be taken
from the RespondingBusinessActivity definition.  In many cases the values
are predictable e.g. the From/PartyId becomes the To/PartyId (see section
1.5 of
_id=28337 for discussion), but the value of eb:Action depends on the
business collaboration.  It also does not work for collaborations that are
always One Way from one party to the other (i.e. where there never is a
response business message that we could the header metadata values from).

Line 323-325

The text refers to the "RefToMessageId" attribute, for ebMS errors this
should be "RefToMessageInError". For eb:Receipt, presumably the
ebbp:OriginalMessageIdentifier if using ebBP receipts. 

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