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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: Receipt Messages for the demo!!


I am "reply to all" on this message because I am not sure
I am signed up properly for the Poc list (next message, if any,
will be trimmed).

The ebXML-BP team is following this discussion with great
interest.  (I have forwarded some messages to the BP list,
and we discussed the issue in today's conference call.)

We agree with the distinction between transport level
acks and business acks.  Simon Johnston said the 
terminology used in one of his past projects was
"syntactically complete" vs "semantically complete".
Some protocols also distinguish a further level,
"business acceptance" - as in "we commit to fulfill this
purchase order in the required quality, quantity and time
for the specified price".

We want to discuss this topic in alignment sessions in
San Jose.  We are thankful for this useful clarification of
issues.

Regards,
Bob Haugen
Logistical Software LLC

-----Original Message-----
From:	Marc Breissinger [SMTP:marcb@webmethods.com]
Sent:	Monday, July 31, 2000 11:34 AM
To:	Patil, Sanjay; 'Prasad Yendluri'
Cc:	Ebxml-Poc (E-mail); Askary, Sid
Subject:	RE: Receipt Messages for the demo!!

This is exactly what we are targeting and it is the one specified in the POC
proposal document.  I have added some more verbage in the latest revision
explaining the *very important* difference between transport level acks and
business level acks.  The ebXML TR&P Reliable Messaging specification (first
draft has been distributed) will lay out the transport level ack
choreography required of TR&P service providers.  In essence, the transport
level ack will acknowledge receipt and, optionally, hardening of the message
(depending upon the QOS required by the message as specified in the TPA).
Note that the RosettaNet ACK message goes far beyond this level to include
validation of the document itself, requiring knowledge of the structure of
the payload itself.  Therefore, the RosettaNet ACK message is a business ack
above the transport ack.

The intent of the demo is to borrow both the business documents and the
business process from PIP3A4.  Without the business level acks, we don't
have PIP3A4.  We want to be able to demonstrate a "full" business process.
When the reliable messaging specification is more complete, we can add the
additional transport level acks to the scenario as required by the current
level of the TR&P specification, rather than making up a "smoke and mirrors"
style substitute for next week.

marc


----------------------------------------------------------------------------
----

      Marc Breissinger
     voice (W): 703-460-2504

      Director, Product Strategy - webMethods, Inc
     voice (C): 703-989-7689

      email:    marcb@webmethods.com
     We're hiring!!!

      email2:  breissim@earthlink.net
     URL: http://www.webmethods.com



----------------------------------------------------------------------------
----





[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