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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: Re: message routing


Arvola,

Hmmm. you're correct. I had forgotten that we removed the any from
MessageHeader since the SOAP:Header could already carry namespace qualified
extensions. Is there a problem with having the InReplyTo included
as a separate SOAP header block?

Cheers,

Chris

> Arvola Chan wrote:
> 
> Chris:
> .
> My responses are inline are bracketed by <arvola> and </arvola>.
> 
> Regards,
> -Arvola
> 
> ----- Original Message -----
> From: "christopher ferris" <chris.ferris@east.sun.com>
> To: "Arvola Chan" <arvola@tibco.com>
> Cc: "Martin W Sachs" <mwsachs@us.ibm.com>; <ebxml-cppa@lists.oasis-open.org>; "ebXML Msg"
> <ebxml-msg@lists.oasis-open.org>
> Sent: Thursday, July 26, 2001 10:33 AM
> Subject: Re: message routing
> 
> Arvola,
> 
> Please see below.
> 
> Cheers,
> 
> Chris
> 
> > Arvola Chan wrote:
> >
> > Chris and Marty:
> >
> > The RosettaNet message header currently carries a lot of redundant information that can
> > potentially be derived from the local software configuration (i.e., the implicit bilateral
> trading
> > partner agreement that has been configured into the software). For example, David Fischer
> earlier
> > asked if there should be a place in the ebXML message header to carry the PIP process identifier
> > (e.g., PIP 3A4 Request Purchase Order). I believe RosettaNet PIP actions have unique
> > GlobalBusinessActionCodes, so if we use the Action element to carry a GlobalBusinessActionCode,
> it
> > should be possible to do a table lookup using the Action element to determine the RosettaNet PIP
> > process identifier. Even if my uniqueness assumption turns out to be false, it is still possible
> > to encode the PIP process identifier information into the Action element (perhaps using it as a
> > prefix).
> >
> > To ease solution providers' migration from the existing RosettaNet Implementation Framework to a
> > future version that takes advantage of the ebXML messaging infrastructure, it will be highly
> > desirable if all existing RosettaNet message header elements can be mapped to equivalent ebXML
> > header elements, or carried as namespace specific extension elements, rather than requiring
> > convoluted lookups.
> 
> I probably wouldn't characterize the look ups as convoluted.
> 
> <arvola>
> Convoluted may have been an inappropriate characterization. Still it is going to impose additional
> implementation requiremenets that may slow adoption.
> </arvola>
> 
> >
> > Appendix A (ebXML SOAP Extension Elements Schema) in the messaging service spec shows that the
> > MessageHeader can take wildcard attributes. It may be useful to also allow an arbitrary number
> of
> > namespace specific wildcard elements to be included. Similarly, the MessageData element
> currently
> > carries a RefToMessageId element that can be used for correlation purposes. In the RosettaNet
> > case, an equivalent InReplyTo element carries both a messageTrackingID as well as a
> > GlobalBusinessActionCode. The latter information while redundant helps the recipient to properly
> > route the response message. Therefore, it will be helpful if either the MessageData element or
> the
> > RefToMessageId can carry additional wildcard sub-elements.
> 
> Is the messageTrackingId equivalent to the MessageId or is it something else entirely?
> Couldn't you simply add the InReplyTo header as a separate SOAP block, namespace
> qualified to the RosettaNet namespace? Either that, or it could simply be added
> as a namespace qualified extension to the MessageHeader element. I see no explicit need
> to have the MessageData element explicitly extensible.
> 
> <arvola>
> Yes, the messageTrackingId is equivalent to the MessageId. It is possible to add information from
> the InReplyTo header as a separate SOAP block. It is also possible to add as a namespace qualified
> extension to the MessageHeader element provided we allow namespace qualified extension elements in
> the MessageHeader. I was thinking that keeping information from the InReplyTo element in close
> proximity to the RefToMessageId would make logical sense.
> </arvola>
> 
> >
> > Rather than tailoring the ebXML message header to meet RosettaNet's requirements (and to the
> > exclusion of all others), I would advocate making the ebXML message header sufficiently
> extensible
> > so that it can meet the needs of different industry specific standards.
> 
> I believe that it already is sufficiently extensible. Some would argue that it is too
> much so (although I am not one of them).
> 
> >
> > Regards,
> > -Arvola
> >
> > Arvola Chan (arvola@tibco.com)
> > TIBCO Software (on loan to RosettaNet)
> > +1-650-846-5046 (US-Pacific)
> > ----- Original Message -----
> > From: "christopher ferris" <chris.ferris@east.sun.com>
> > To: "Martin W Sachs" <mwsachs@us.ibm.com>
> > Cc: <ebxml-cppa@lists.oasis-open.org>
> > Sent: Thursday, July 26, 2001 5:15 AM
> > Subject: Re: message routing
> >
> > > Marty (or possibly more correctly Arvola),
> > >
> > > Please see below.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > Martin W Sachs wrote:
> > > <snip/>
> > > >
> > > > I agree that it deserves attention, the larger question in my mind is what
> > > > manner of attention?
> > > >
> > > > MWS:  The specific goal should be to satisfy the RosettaNet needs.  If we
> > > > can come up with a generalization that will accomplish a larger set of
> > > > needs, so much the better. For example, perhaps some routing URI that
> > > > contains
> > > > terms for all the routing levels
> > > > would be the way to go.  The critical point is that each of those levels
> > > > must
> > > > be visible in the BPSS instance document so that the BPSS instance document
> > > > continues to express the routing agreement that enables each party to send
> > > > a message with the routing information needed at the destination.  For
> > > > RosettaNet, it means that the BPSS instance document must include
> > > > surrogates
> > > > for all the levels that Arvola needs.
> > > >
> > > <snip/>
> > >
> > > I would agree that we should be striving to satisfy RosettaNet's needs,
> > > but IMHO, not to the exclusion of all others.
> > >
> > > I take it that these needs are not satisfied with what is currently
> > > available? I would like to understand the issues more thoroughly.
> > >
> > > First off, what is the issue with regards to routing that cannot be
> > > adequately expressed with CPAId, ConversationId, Service, Action
> > > AND state? If it is Role, which is absent from the Message, then
> > > this can be easily derived. Admittedly, it gets a little complicated
> > > when both parties can act in either role and this is expressed in
> > > the same CPA, but it is still possible if you are willing to assume
> > > that the first message of a new conversation is always what
> > > it appears to be (the first message of a new conversation) as opposed to
> > > a message with the wrong service/action and conversationId.
> > >
> > > In any event, you can derive role by working out which role in the CPA
> > > has service/action as its first message in the choreography. From
> > > there on, it is merely state information about the conversation.
> > >
> > > I suppose that we could add it to the message as long as the MS TC
> > > agreed. It seems overly redundant to me to be passing this around
> > > as the information IS in the CPA. Of course, if you're flying
> > > without a net, er... CPA, then all bets are off;-)
> > >


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


Powered by eList eXpress LLC