Hi All,
In a layered architecture, messages sent from a particular layer are intended to be handled at the equivalent layer on the receiving end. It would be inappropriate for a lower layer to take action based upon the content of a higher layer message. And a higher layer processor might never be aware of a failure at a lower layer, and so cannot be expected to 'handle' a lower layer failure condition.
If there is a need to communicate status at a given layer, there must be a layer specific protocol design to support that communication. And generally, there is a need for such communication at each layer, to report success/failure at that layer.
Cheers,
Bob
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Thursday, October 23, 2003 12:32 PM
To: 'Dick Brooks'; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Interesting, Dick!
I wonder about the business justification for using an extra business
signal.
Non-repudiation is already covered by signals 2/3 (normally, syntax
verification of the envelope is done before 2/3 is sent). It seems
superfluous to me to send an additional business signal just to indicate
payload syntax verification, whereas a business message
with a response can be sent just as quick, saying "Accept" or "Reject."
Possibly, this is a grey area in the spec that needs to be fixed? Just fell
between the cracks of MS and BPS.
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Thursday, October 23, 2003 10:58 AM
To: Damodaran, Suresh; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Suresh,
Exchange 2 is frequently seen when trading partners utilize X12 to represent
business data. ERCOT's ebXML implementation (www.ercot.com) follows the MEP
outlined in Exchanges 1-2-3.
The Ontario Energy Markets, which use XML to represent business data, also
send a Functional Acknowledgement(in XML) following the same MEP.
Regards,
Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Thursday, October 23, 2003 11:36 AM
To: 'Dick Brooks'; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
Exchange 2, below, is not something I have seen.
(granted, in theory, it looks very plausible)
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Dick Brooks [mailto:dick@tech-comm.com]
Sent: Thursday, October 23, 2003 6:24 AM
To: Damodaran, Suresh; 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
I've seen 4 used as a "functional acknowledgement" to indicate that received
data is syntactically good/bad. A typical scenario is as follows:
Exchange 1
{
A sends data (PO) to B.
B sends 1,(2/3) in a single response message to A indicating reliable
delivery complete of (PO).
}
Exchange 2
{
B sends 4 (functional acknowledgement) to A indicating successful syntax
validation of (PO).
A sends 1,(2/3) in a single response message to B indicating reliable
delivery complete of 4.
}
Exchange 3
{
B sends Business level response indicating the results of processing (PO)
(e.g. PO accepted - POA) to A.
A sends 1,(2/3) in a single response message to B indicating reliable
delivery complete of (POA).
}
The above scenario can also be completed in a single exchange (classic RPC),
as follows:
{
A sends data (PO) to B.
B sends 1,(2/3) and a Business level response (e.g. PO accepted - POA) to
A in a single response message indicating reliable delivery and processing
of (PO) complete.
}
Dick Brooks
B2B Integration and Cyber Security Consultant
http://www.tech-comm.com/dbc
Mobile:602-684-1484
eFax:240-352-0714
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
Sent: Wednesday, October 22, 2003 11:17 PM
To: 'Duane Nickull'; Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] MSH vs BSI acknowledgement messages
yes, 2 and 3 are same, and 4 is not used typically in practice (when there
is a business response
message, then that serves the same purpose, and when it is only one-way,
i.e., notification, usually nobody cares to send a business ack).
Regards,
-Suresh
Sterling Commerce (on loan to RosettaNet)
469 524 2676 (O), 469 323 0234 (Cell)
-----Original Message-----
From: Duane Nickull [mailto:duane@yellowdragonsoft.com]
Sent: Monday, September 15, 2003 9:41 PM
To: Anthony Ellis
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] MSH vs BSI acknowledgement messages
Yes - 2 and 3 are the same.
Duane
Anthony Ellis wrote:
>Thanks,
>
>I wasn't thinking about the http level ack at first but now I think the
spec
>can have up to 4 messages.
>
>Level 1 - Transport level. HTTP response
>Level 2 - MSH reliable messaging acknowledgement (as defined in the ebMSS)
>Level 3 - BSI ReceiptAcknowledgement message (as defined in the BPSS)
>Level 4 - BSI (or BPM) AcceptanceAcknowledgement message (as defined in the
>BPSS)
>
>Although I still think that Level 2 and Level 3 could be sent together as
>they really do the same thing. Although I come from a technical approach,
>not a business approach :)
>
>I know that the MSH and BSI layers should be seperate but I think there
>should be some overlap for simplicity's sake...
>
>
>-----Original Message-----
>From: Duane Nickull [mailto:duane@yellowdragonsoft.com]
>Sent: Tuesday, September 16, 2003 10:23 AM
>To: Anthony Ellis
>Cc: ebxml-dev@lists.ebxml.org
>Subject: Re: [ebxml-dev] MSH vs BSI acknowledgement messages
>
>
>Anthony:
>
>Almost. You are correct in asserting that there may be three levels of
>acks. First one couldbe an http ack (a basic 200 - ok).
>
>Second ack could be a message layer specific ack that says - yes - the
>message content is validated and received. If specifically requested
>within the Message, must be delivered (timneouts etc apply to this).
>
>The third is a potential business level acknowledgement. This is to say
>"Yes - we accept the terms of your business proposition". It would be
>foolhardy to say that any communication received indicates acceptance of
>the business intent without checking it against the business rules
>(credit limits, shipping to constraints etc.).
>
>Want to have some real fun? Try to imagine what happens if the business
>level acknowledgement gets sent back before the http level ack (Actually
>don't - we've been down this rathole before ;-)
>
>Duane
>
>Anthony Ellis wrote:
>
>
>
>>I have a question regarding the link between the ebXML MSH and BSI and
>>regards to acknowledgement messages and was hoping to clear things up
>>a bit.
>>
>>MSH specifies reliable delivery, and this can be performed with ebXML
>>acknowledgment messages.
>>The BPSS spec then specifies another layer of acknowledgement
>>messaging, ie Receipt Acknowledgement and Acceptance Acknowledgement.
>>
>>Does this mean that there can be up to 3 acknowledgement messages sent?
>>
>>Firstly a MSH acknowledgement, which is simply an acknowledgement
>>attribute in the header of a message, sent once the message has been
>>delivered to the receiving application. There is no business document
>>(ie payload) associated with this message (or there doesn't have to be).
>>
>>Then a BSI, ReceiptAcknowledgment if the BSI can determine a message
>>is legible. This is a ebXML message with a payload containing an XML
>>ReceiptAcknowledgement document.
>>
>>Then a BSI, AcceptanceAcknowledgement if the BSI can determine
>>a payload document is legible and is successfully sent to the
>>Application. This is a ebXML message with a payload containing an XML
>>AcceptanceAcknowledgement document.
>>
>>It seems to me that the MSH acknowledgement message and the first BSI
>>ReceiptAcknowledgement message are a little redundant, as they
>>both signal that the original request message was succesfully
>>received. The MSH should not be sending it's acknowledgement if the
>>original message was not legible either.
>>Is this understanding correct?
>>
>>It just seems to me that there is very little coherence between the
>>MSH spec and the BPSS spec - or it could just be my understanding :)
>>
>>Thanks in advance..
>>
>>
>>Anthony Ellis
>>Red Wahoo
>>-----------------------------
>>Tel: +61 438 878 003
>>www.redwahoo.com
>>
>>
>>
>
>
>--
>***************************************************
>Yellow Dragon Software - http://www.yellowdragonsoft.com
>Web Services & ebXML Messaging / Registry Downloads
>UN/CEFACT eBusiness Architecture/ ebXMl Technical Architecture
>Phone: +1 (604) 738-1051 - Canada: Pacific Standard Time
>Direct: +1 (604) 726-3329
>
>
>
>
>
>
>
>
--
***************************************************
Yellow Dragon Software - http://www.yellowdragonsoft.com
Web Services & ebXML Messaging / Registry Downloads
UN/CEFACT eBusiness Architecture/ ebXMl Technical Architecture
Phone: +1 (604) 738-1051 - Canada: Pacific Standard Time
Direct: +1 (604) 726-3329