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


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;-)
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard


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


Powered by eList eXpress LLC