Subject: RE: Motivation for sub-service choreography?
At 03:15 PM 8/4/00 -0700, David Burdett wrote: >Folks > >Catching up on old email I missed whilst away so apologies for the delay in >responding. Basically I agree with Chris/Joe's comments but with one >proviso. Chris says ... > > >>>We have been trying to carefully distinguish between an error/ack which >is transport related with a business level error/ack which is transparent to >the transport layer (e.g. it is simply another message to be routed to its >apropriate service interface handler)<<< > >Whilst this is true, I think that delivery of a message is actually a >business event that, in some circumstances, could be important, e.g. for >non-repudiation. This is particularly the case if, the ack is digitally >signed. > >This means that the existence of a transport level ack (i.e. ebXML Trp) is >something that a business service/application might need to know about. Your parenthetical naming remark also shows that we must be precise in our terminology. I assume that when we say "transport" we mean the underlying transport, below ebXML... and of course we are transport neutral. Here, you're talking about "ebXML-transport" ("eTransport"?) and we need to be careful of the distinction. >I therefore think that the service interface we create should: >1. Allow an application to specify which acks/errors it wants to know about >when sending a message I picture a hierarchy of ack/error messages: business/application level, TPA level, eTransport level, transport level (maybe). We need some amount of eTransport level ack/error for Reliable Messaging, at least, but we need to discuss whether these messages (and others) are visible to or specifiable by the application. >2. Support notification of the arrival or errors/acks if requested. > >The default should probably be: never notify acks and always notify errors. ...as long as the ack/error is destined for the application layer. >David > > > >-----Original Message----- >From: Christopher Ferris [mailto:email@example.com] >Sent: Friday, July 21, 2000 2:09 PM >To: Joe Lapp >Cc: firstname.lastname@example.org >Subject: Re: Motivation for sub-service choreography? > > >Joe, > >Thanks for the feedback. Please see below. > >Cheers, > >Chris > >Joe Lapp wrote: > > > > I just read the ebXML TR&P spec dated 5/26/2000. I'm curious about the > > motivation for the "sub-service" and "Multiple Round Trip Document > > Exchange" approach. This seems to contrast with an approach that layers > > business process protocol strictly above the delivery protocol. The spec > > proposes multi-document exchanges would be alternatives to the "one-way" > > and "simple" document exchanges instead of layering above these latter two > > exchanges. Wouldn't this approach require that business process designers > > have smarts about reliable messaging? > >In fact, our approach is layered. We should clear this up in the >requirements/overview document (IMHO). > > > > > Maybe you can help me by shooting holes in the alternative that I have in > > mind. TR&P would define protocols for synchronous and asychronous > > messaging with reliability and error recovery in mind. The result is an > >This is our primary focus. > > > abstraction layer that, from the outside, provides for the reliable > > delivery of messages, for the provision of responses, and for the >reporting > > of failures. Neither acknowledgements nor errors are directly exposed. >If > >This has been our approach. We have been trying to carefully distinguish >between an error/ack which is transport related with a business level >error/ack >which is transparent to the transport layer (e.g. it is simply another >message to be routed to its apropriate service interface handler). > > > ackknowledgements are not received or errors cannot be recovered, only >then > > are failures reported above this abstraction layer. Business processes >are > > then designed as a higher level protocol that is concerned only with the > > choreography of business level messages. > >Again, this is our intent. We'll make every effort to express this >more clearly. > > > > > Also, to clarify my question, I'm aware that in choreographing a sequence > > of messages, you need to give the action of the sequence a name >("service") > > as well as the action of each message ("sub-service"). Given these > > definitions there will always be a "sub-service choreography." My >question > > regards the particular approach taken. > > > > Please accept my apologies for being so ignorant about TR&P. I haven't > > been following along. Thanks! > >No problem, we appreciate the feedback. If the documents don't reflect >our approach, then they should be modified accordingly. > > > > > - Joe > >-- > _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect > _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 > _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM > _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 >_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
eList eXpress LLC