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:chris.ferris@east.sun.com]
>Sent: Friday, July 21, 2000 2:09 PM
>To: Joe Lapp
>Cc: ebxml-transport@lists.ebxml.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
Powered by
eList eXpress LLC