|
Reading this over I see at least one lingering lack of precision. When I said So business applications always send business signals, and MSH send the (MSH) signals. I should have said: So business applications always originate/consume business signals, and MSHes generate/consume the (MSH) signals. The module that actually engages in the transfer protocol is normally a MSH, and will do transfer operations for MSH, business signals, errors, and/or user
messages. From: Dale Moberg [mailto:dmoberg@axway.com]
ebBP 2 was finished and approved as an OASIS standard well before the ebMS Messaging version 3 work. In the generation of ebMS v 2 there were both MSH signals
and business signals. In ebMS 3 the signals specified and discussed correspond to the ebMS 2 MSH signal layer. Even in ebMS 2, business signals could be treated as business messages.
So yes the business layers should handle the ebBP Acceptance, Receipt, and their Exception signals, for the most part. For AS4, however, the conformance profile needed a signed inventory of hashes of messages that had been sent in order to capture the evidence needed to support
non repudiation of receipt. Since ebBP had already defined such an object (using XMLDsig mechanisms) AS4 re-purposed this pattern to use in its NRR. So the pattern is reused in something sent by a MSH!
I think your comments indicate that the MSH and business signal boundary is both conceptual and operational, but that what software module is responsible for
the handling (production or consumption) is definitive. So business applications always send business signals, and MSH send the (MSH) signals.
It is indeed possible that a business and a MSH receipt signal both be sent. Usually no one does this, letting the MSH receipt suffice for the alignment overall
between the parties. Separate layers of distinct communicating participants could be aligned independently, but in practice this is rarely done. Pim may wish to elaborate on this also. The issue you raise is a more “theoretical” problem of ebXML involving protocol layering, software modularity, state
alignment, and message processing complexity! I hope we have reduced the confusion, but we might need a virtual white board to straighten out all involved elements! Dale Moberg From: Denis Nikiforov [mailto:denis.nikif@gmail.com]
If I understand you correctly, the Acceptance and Receipt business signals should be sent as UserMessages? And receipt signal defined in ebMS 3 is a completely different type of signal? Business applications shouldn't send it? 2013/6/12 Pim van der Eijk <lists@sonnenglanz.net> Hello, The component that generates the Acceptance Signal (typically some business application or middleware) can submit this signal with a
RefToMessageId referencing the
UserMessage that is being accepted. The MSH will then package this signal in a
UserMessage in an ebMS response message, which will be delivered again to some component outside the MSH.
The receipt signal defined in ebMS 3.0 is generated and handled in ebMS 3.0 message handlers.
Pim From: Denis Nikiforov [mailto:denis.nikif@gmail.com]
Sent: 11 June 2013 08:00
Hello! It's seems that ebMS 3.0 supports only Receipt Acknowledgement Business Signal. How to send an Acceptance Acknowledgement Business Signal? Thanks! |