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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC