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

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Marty,

	yes, this is actually what I meant.
I have also misused the terms and acronyms, probably. What I meant is
that the CPA, via the information on the QoS it contains and the
specific Business Process it points to, specifies the rules and
the situations and the conditions according to which some messages
may be persisted for "business reasons""

Thanks a lot for your comment

/stefano

> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 23 October 2001 06:04
> To: Stefano POGLIANI
> Cc: Christopher Ferris; David Fischer; Tony Weida; CPPA
> Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
>
>
>
> 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>
>
>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>