[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