RE: Motivation for sub-service choreography?

[David Burdett <david.burdett@commerceone.com>]

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.

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
2. Support notification of the arrival or errors/acks if requested.

The default should probably be: never notify acks and always notify errors.

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