ebxml-transport message


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

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC