RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001

[Martin W Sachs <mwsachs@us.ibm.com>]

Stefano,

What you say makes a lot sense except for this: "the CPA should be able to
persist messages based on the "business" properties (compensation,
exceptions)".  The CPA is a static document which gives rise to static
configuration properties when deployed.  The CPA can't persist anything.  I
believe that you intended to say "the CPA should be able to specify that
messages be persisted based on..."

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Stefano POGLIANI <stefano.pogliani@sun.com> on 10/22/2001 01:03:34 PM

To:    Christopher Ferris <chris.ferris@sun.com>, David Fischer
       <david@drummondgroup.com>
cc:    Tony Weida <rweida@hotmail.com>, CPPA
       <ebxml-cppa@lists.oasis-open.org>
Subject:    RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001



I think that one source of confusion in this thread, and
certainly one source of confusion in my mind often when
dealing with architectural topics around ebXML, is the
fact that ebXML comprises many specs which are supposed
to work all together but also separately.

In this last mail, you say that the MSH is an "abstraction"
and not a "technical spec". I think that this goes in the
direction of clarifying the source of confusion, but it
would probably need more meat.

What I want to say is that for situations in which the MSH
could be used "outside" of the ebXML framework, it does not
need to be simply an abstraction but it needs to be as
concrete as possible in order to properly address the
implementation (something that allows the creation of
a Java implementation or a dll or a shareable image).

When it is going to be used "inside" the ebXML framework
(specifically, together with the CPP/CPA and, in
an extended way, with the BSI) the scenario changes a bit
IMHO. The software implementing the BSI is actually
an agent (logically), i.e. a self-consistemnt piece
of software that runs (it is, logically, an executable
whilst the MSH is logically a library, in my understanding).
So, in this situation, the executable will use the
library and will delegate to the library a lot of things
that the library (MSH) is very well able to do.

Now, the use of the library is, in this case, fully
under the control of the executable; this means that
the executable decides what to use of such library,
how to use and when to use. In this sense, the
library is as transparent as the executable wants
(or as opaque...). For stand-alone implementations
of the MSH (i.e. the library playing the role of
the executable) "outside" the ebXML framework,
the library must be able to autonomously and
consistently deal with a lot of things (including,
for instance, NRR). When "inside" the ebXML
frameowrk, the library can be used BY the executable
(BSI) in order to accomplish things that are actually
required by the executable itslf.

I think that some architectural considerations on
the runtime would greatly benefit the discussions;
something like:
 - these things are dealt with exclusively
   by the MSH
 - these other things are dealt exclusively
   by the BSI
 - these other again are dealt by the MSH
   under the control of the BSI.

I raised several times an issue that can be
read in the same thread:
 - the MSH should be able to autonomously
   persist messages (for reliability).
   This implies that the MSH uses a sort
   of db
 - the CPA should be able to persist
   messages based on the "business"
   properties (compensation, exceptions)
   and this would imply that the BSI has
   a sort of db
obviously, in a real implementation, these two dbs
should be one... under the control of who?

Does this all make any sense ?

Respectfully

/stefano


> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@Sun.COM]
> Sent: 22 October 2001 15:39
> To: David Fischer
> Cc: Tony Weida; CPPA
> Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
>
>
> David,
>
> Again, you are making an assumption that the "application"
> or more specifically the NRR function doesn't have access
> to the unadulterated message contents. I think that this is
> a false assumption. The specification makes no claims whatsoever
> as to what the "application" gets, nor what form that should
> take.
>
> You also say:
>
>  > <<Not a problem!  The Application may pass anything it wishes
> to the MSH.>>
>
>
> I would respond that the MSH may pass anything to the "application"
> that it wishes. We say nothing about the implementation of
> the software stack that manifests itself as an MSH + "application"
> nor should we, IMO.
>
> The MSH is an abstraction, not a technical specification for an
> implementation.
>
> Cheers,
>
> Chris
> David Fischer wrote:
>
> > Hi Tony,
> >
> > <<comments in-line>>
> >
> > Regards,
> >
> > David.
> >
> > -----Original Message-----
> > From: Tony Weida [mailto:rweida@hotmail.com]
> > Sent: Sunday, October 21, 2001 8:05 PM
> > To: David Fischer; CPPA
> > Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> >
> > David,
> >
> > I've embedded a couple comments below, prefixed with my initials.
> >
> > Cheers,
> > Tony
> >
> > ----- Original Message -----
> > From: David Fischer
> > To: CPPA
> > Sent: Sunday, October 21, 2001 6:32 PM
> > Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> >
> > Sorry I missed the meeting, it didn't make it onto my calendar.
> >
> > Comments:
> >
> > If end-to-end, signed Acknowledgment is requested, it provides
> NRR -- in the
> > same way DeliveryReceipt does.  NRR cannot be provided at the
> > BPSS/Application level since MSH does not pass the entire
> message and thus
> > the Application cannot generate the required Digest(s).
> >
> > TW: That seems like a strong statement.  Signing the entire message is
> > sufficient, but is it always necessary?  I understand that messaging
> > elements may convey information relevant for non-repudiation, e.g., a
> > timestamp.  Such information may also appear in a particular type of
> > business payload.
> >
> > <<In order for NRR to work, it must EXACTLY match the original
signature
> > digests -- which includes the MSH headers.  Since the
> Application doesn't have
> > those headers, it cannot generate those digests.  This does not
> mean that the
> > Application might not do something similar with only the
> payload.  Messaging
> > does not stipulate what can be in the payload.  If the
> Application wants to do
> > something like sign/encrypt the payload prior to passing to the
> MSH, it can.
> > However, this is not NRR.  This is more like some subset of the
original
> > digests/ds:Signature, so the original signature will not match.
>  In any case,
> > the Application can do whatever it likes and the MSH will
> provide NRR, if a
> > signed Acknowledgment is requested.>>
> >
> >
> > Since the MSH does not do any application parsing, any Business Level
> > receipts cannot be done at the MSH level.  While the
> Application cannot do
> > NRR, it can/must provide anything along the lines of "Message
> verified/being
> > processed" (i.e. Delivery Receipt).  The Application would pass
> this signal
> > to the MSH with a flag which says "sign this".  While it would not be
> > illegal for the Application to send a signed/encrypted payload
> to the MSH
> > (would this be S/MIME?), it is not within our model to do so.
> >
> > TW: I expect that some security-sensitive applications will call for
> > transmitting encrypted content between authorized persons or
> applications,
> > not just between their respective MSHs.  The latter is more likely to
> > compromise security, for example by exposing confidential information
to
> > unauthorized persons within an enterprise.
> >
> > <<Not a problem!  The Application may pass anything it wishes
> to the MSH.>>
> >
> > An Acknowledgment can be requested separately from Reliable Messaging
> > although the only difference is duplicateElimination.
> >
> > I think/agree that MSH signals should be returned synchronously
> for HTTP.
> > This should be the default.  Maybe we don't need a flag, just
> make this a
> > requirement (Why would this ever be done asynchronously for
> HTTP?)  I think
> > I agree with Dale.  This should match the transport method
> (sync for HTTP,
> > async for SMTP) and should not change per message.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Tony Weida [mailto:rweida@hotmail.com]
> > Sent: Saturday, October 20, 2001 5:05 PM
> > To: CPPA
> > Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> >
> > Draft minutes of the October 18 teleconference are attached.
> Please send me
> > any additions or corrections.
> >
> > Cheers,
> > Tony Weida
> > Independent CPPA Fan :-)
> >
> >
> > ----------------------------------------------------------------
> > 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>
>


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