OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call


One of the reasons the BPSS uses a compositional approach is for just this
situation.  All off the collaborations are reusable and can be nested.  This
allows similar but different collaborations to be constructed from the same
parts without having to mess with one created for another purpose.  If
collaborations are so un-coupled that they may not necessarily be used
together it is best to create these as independent collaborations and then
create another than combines them in the desired combinations.
Cory

> -----Original Message-----
> From:	Stefano POGLIANI [SMTP:stefano.pogliani@sun.com]
> Sent:	Monday, November 26, 2001 8:12 AM
> To:	bhaugen; Martin W Sachs; Dale Moberg
> Cc:	ebtwg-bps@lists.ebtwg.org; ebxml-cppa@lists.oasis-open.org
> Subject:	RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> 
> +1.
> 
> I think that this would be the cleanest approach.
> 
> Best regards
> 
> /stefano
> 
> » -----Original Message-----
> » From: bhaugen [mailto:linkage@interaccess.com]
> » Sent: 21 November 2001 18:56
> » To: Martin W Sachs; Dale Moberg
> » Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa@lists.oasis-open.org
> » Subject: Re: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> »
> »
> »
> » Dale Moberg:
> » > Suppose 2 companies want to engage in OrderManagement,
> » > but do not wish to engage in POCancel actions or
> » > POChange actions. [This is not a far-fetched example,
> » > by the way.] If the ServiceBinding embraces all actions
> » > in the instance, they will in effect agree to bindings
> » > for actions that they do not support across the mythical
> » > BSI interface.
> » >
> » > These situations may have the following possible remedies
> » > (and I am sure there are others as well!):
> » >
> » > 1. Create ways to specify a portion
> » > of a BPSS instance as the
> » > targeted package of leaf actions.
> » > That reopens themyriad "name" attributes
> » > from which the service name
> » > could come from. May be feasible though.
> » > 2. Create ways to have Override specify
> » > a null binding for
> » > actions not agreed to.
> » > (Not wild about
> » > this one either
> » > as it seems to introduce clutter that
> » > the binding-up-actions as a group)
> » > 3. Apply Tony W's XSLT filter ideas to
> » > the BPSS instance to extract
> » > the right ones. If we use this technique,
> » > then we still
> » > should document how the service
> » > naming convention works.
> » >
> » > MWS:  There is one more remedy, which is
> » > to create a BPSS instance document that
> » > defines only the functions that will be
> » > used for a particular interaction. This
> » > is probably just a restatement of (3) and
> » > is my preference.
> »
> » BobH: I agree emphatically with Marty.
> » Creating different BPSS's for different business
> » processes is certainly simpler and safer than
> » trying to design, agree on and develop any
> » facility for on-the-fly variations.
> »
> » -Bob Haugen
> »
> »
> »
> » ----------------------------------------------------------------
> » 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.ebtwg.org/ob/adm.pl>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC