Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment andthelayering mishmash (was jumbled into: reliable messaging - hop by hop)

[Scott Hinkelman <srh@us.ibm.com>]

Chris,
>........ I have no problem with this base
level functionality remaining in the MSH for use
in cases where the BPSS isn't used. However,
the likes of RosettaNet, when mapping to ebXML,
would not make use of this feature since the
business process (PIP) defines the business signals
that must be exchanged. ........

One thing that we would like is a industry standard messaging service
that relieves upper level of doing things like business signals
that need inventing to address RM functioanlity. I would assume
that it this was standardized, and had traction, then I would
not think upper frameworks would continue to ramain the same in
order to align with wider interoperability. I would hope that
Rosettanet would throw away OASIS Messaging would do - but all
of this said without detail involvement with the Rosettanet
mapping.


Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 08/31/2001
11:27:18 AM

Sent by:  Chris.Ferris@Sun.COM


To:   ebxml-cppa@lists.oasis-open.org, ebxml-msg@lists.oasis-open.org
cc:
Subject:  Re: Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment and
      thelayering mishmash (was jumbled into: reliable messaging - hop by
      hop)



Dlae,

Some comments below.

Cheers,

Chris

Dale Moberg wrote:
>
> David,
>
> I read one of your recent notes in which
> you present some interesting alternatives,
> and I would like to comment on these in the
> hopes of aligning BPSS, MSG, and CPPA on
> the NRR issues.
>
> David Burdett says, almost as an aside:
> "The other alternative would be to provide
> two variations of the Delivery
> Receipt, one which indicated that the
> To Party MSH had received and the
> second that the To Party Application
> had been notified of the message, but I
> don't really want to go there as it
> is definitely additional functionality."
>
> Despite your disclaimer, I think this is
> an area we should discuss so that we
> can align BPSS CPPA and MSG on NRR.
> (Maybe pretty soon I can write a
> sentence consisting entirely of
> acronyms.)
>
> I think that there _could_ be one DeliveryReceipt
> with an extension mechanism
> that could be used for all the additional
> conditions that tend to get
> tacked on to the DeliveryReceipt:
> One condition would be that the To Party
> Application was notified, another would be
> that the syntax had been checked,
> a third, that the syntax had been checked
> and the data typing had been
> checked and the values were in
> allowed ranges, and so on. We would in CPPA
> need an enumeration for the main
> different extensions, and a general
> "namespace supported" element to gesture at
> yet unthought of extensions (or whatever
> is the extension mechanism du jour).

This is what the BPSS signals (which are derived
directly from RNIF) are supposed to handle. There
are a set of predefined patterns for these signals.
A business transaction (I think that's the right
term) adopts one of the selected patterns as defined
by the identified attributes on that Business Transaction.

>
> But strictly speaking,
> the functionality in these NRR
> extensions is beyond what
> a MSH needs to carry out its main
> jobs, even when that job includes
> supporting NRR. Let me briefly
> expand on this.

Agreed, because the business signals (one of which
is the ReceiptAcknowledgment which contains an
element for NonRepudiationInformation) necessarily
involve application level processing such as
verifying that the message is processable (e.g.
it can be parsed/processed).

>
> NRR is something that
> rarely ends up getting uniquely
> characterized in terms of what needs
> to be _implemented_. We know what we
> want to obtain more or less, but can rarely agree
> upon what will always be sufficient
> to attain it. Because any processing
> exception that occurs after the MSH
> finishes its work may provide the To-Party
> a legal "way out," NRR always seems to be falling
> short of removing all wiggle room.

Agreed.

>
> I seriously doubt that we will remove
> all the wiggle room, and that there will always
> be some exceptional condition after receipt
> and after sending a DeliveryReceipt, that
> would result in a processing failure on
> the ReceivingParty side (bad syntax,
> semantics, and so on). To try to rule out
> each of these conditions by checking each of them
> before sending a DeliveryReceipt, leads to
> endlessly bloating DeliveryReceipt functionality, and
> finally a need to be in the position of being able
> to produce the Business Response before issuing
> a DeliveryReceipt. Clearly this drift leads to a layering
> mish-mash.

Precisely, this is a layering problem.

>
> In EDIINT we had very similar requirement
> flux. Eventually we just left an open extension
> mechanism for receipts, in terms of what
> can be added by industry groups. RosettaNet
> went through similar struggles in working
> out its private/public division.
>
> I personally think it would
> be good just to draw a line and say that
> "Receipt is obtained when the MSH has persisted the
> message payload off the wire," and let the MSH
> handle sending the DeliveryReceipt, signed
> and including an appropriate hash for the
> original message. Nevertheless, adding on an

Whether this signed DeliveryReceipt can be used for
NRR is questionable. I have no problem with this base
level functionality remaining in the MSH for use
in cases where the BPSS isn't used. However,
the likes of RosettaNet, when mapping to ebXML,
would not make use of this feature since the
business process (PIP) defines the business signals
that must be exchanged. It would be redundant to
have a DeliveryReceipt and a ReceiptAcknowledgment.

> extension mechanism may appease others (especially
> in the BPSS side of things) enough
> that we can get all three main groups
> (BPSS, CPPA, and MSG) to agree that NRR has been
> implemented OK. The problem then will be
> in documenting this extension mechanism
> so that we can capture publication of and
> agreements upon extensions within CPPs and CPAs.
> We can then let the CPA adjudicate just how
> much "creep" into the application realm occurs
> (syntax check on payload, etc).

None of the creep cited should be a function of
the MSH which should be concerned with sending, receiving
and dispatching of messages securely and reliably.
It should not be in the business of parsing payload,
verifying schema validity or checking whether value
ranges are within limits, etc. This functionality
is clearly out of scope for the MSH.

>
> So, David B's compromise might be a good way
> to proceed if the MSH is to provide
> NRR functionality.

I'm not so certain.

>
> An alternative would
> be to follow Chris Ferris general preference
> to push all NRR all the way back up to the application.

Woo hoo!

> (At least I hope I am not misrepresenting Chris here.)

Not at all. Just to clarify the term "application" by which
I mean only "not the MSH". An implementation of an MSH
may choose to bundle with it software that performs
functionality that is not specified for the MSH (e.g. some
manner of application adapter) is free to do so.

> I think, though, that would make the MSH far less
> interesting as a middleware component module.

See above. Our goal was not to specify a B2B middleware
server. It was to define a protocol and required
behaviour so as to enable interoperable, secure and reliable
transport, routing and packaging of messages.

> Pragmatically, NRR is not something that anything
> but new applications would be able to provide and even
> then, it might be difficult to ensure access to the
> data elements needed to compute the hash to indicate
> being in posession of the original message/payload/whatever.

Regardless, none of the same "applications" can speak
to an ebXML MSH either without modification. Some degree of
middleware/glue/adapter is almost certainly needed in all
cases. I consider this stuff to be in the "application" layer.

>
> Moving on, David B. later says:
>
> "I actually think that the second one
> [involving an application notification assurance]
> is really an application level acknowledgement."

I agree. I think that this is covered by the business
signals. Not our space.

>
> I think we need to wonder why the application
> layer needs an acknowledgement, or why
> it needs to get involved in NRR issues.

Again, maybe "application layer" is too loaded a
term. More importantly, NRR is a business concern,
not a technical/protocol concern. It involves archival of messages
or message artifacts, legal agreements and more.
When an NRR receipt can be generated depends upon
what the parties have agreed/specified. The BPSS spec,
and I'm certain anyone who was involved in RNIF can tell
you that one-size does not fit all.

>
> What is an application level acknowledgement
> as opposed to the application
> level response? Why should an application
> need to get involved in producing a
> receipt instead of its defined application level response?

According to the BPSS and RNIF, the response patterns
and timing are all part of the business process.
The "application" (e.g. the ERP system) might not be
directly involved in producing the business signals
(receiptAcknowledgment or acceptanceAcknowledgment).
Rather, some middleware (a business process orchestration
component) might assume this responsibility, never
involving the ERP system.

My point is that MSH != BPS however, a BPS may indeed
have as a component an MSH node. However, not all MSH
nodes necessarily need to provide full BPS functionality
which would include NRR, choreography, preparsing, transformation
and all manner of bells and whistles.

> This seems to be forcing applications to get involved
> in detailed delivery related issues, when an application
> may only know only about its tasks to be performed
> and what do with its results (regardless of how the task got
> queued up to it...).

Again, see above.

>
> I think that the BPSS group needs to explain
> why business applications should at all be in the
> business of worrying about generating acknowledgements
> or receipts. This is a source of layering conflict that is
> causing both CPPA and MSG difficulties in understanding
> how to finish their own tasks. If there is a
> BPSS requirement for NRR, does that mean that
> the lower layers are to provide an implementation
> supporting NRR? Or is it an indication that the design
> of the business data structures in Requests and
> Responses support NRR functionality? Or is something
> else meant? CPPA has, I think, mainly been thinking
> that a BPSS requirement of NRR was a request that
> the underlying layers provide an implementation for
> NRR (an implementation that can be a basic or
> a more enriched implementation).

I think that security should also be party to this
discussion since NRR of necessity involves signing.

>
> Is an application level acknowledgement
> an application response in addition to the real
> application business response or perhaps instead of a
> business response? I think that if a business

It may depend. A process that can generate a response
quickly (mseconds) may not need any signals. Typically,
the signals are provided for long-running transactions
(such as a request that is processed in batch-mode
only once per day, etc.) so that the sender can have
some assurance that the business transaction wasn't
simply "lost in the sauce".

As we get to a more message-driven, realtime processing
of business transactions, these artifacts will likely
have their importance and use diminished. IMO, there's
no reason why an NRR couldn't be piggy-backed with the
business-level response. Of course, once the business-level
response is received, an NRR may be totally meaningless
because there's nothing to repudiate!

> layer process thinks it needs such an
> acknowledgement for its own purposes,
> then that function should be built into BPSS
> specifications as requirements concerning the
> detailed algorithms, hashes, etc in the structured data
> exchanged in requests and responses. In this
> case, NRR will be opaque to the MSH layer,
> and there will need to be no agreement on how
> NRR is to be achieved/implemented (so DeliveryChannel
> characteristics do not need to be assessed
> to see whether NRR is supported on a channel.)
> This may be consistent with the Chris Ferris option
> discussed above; I personally would like to see
> a POC demonstrating this approach working interoperably
> before allowing it in an approved spec.
>
> Dale Moberg
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>