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


Stefano,
Parameterized specifications make a lot of sense - it is a large part of
what CC has been searching for with "context" and what we always need to use
to generate implementation (or other intermediate artifacts).
"substitutions" was a last-minute move in that direction but would be much
better as a general mechanism. Good work has been done on this in the EDOC
patterns work from CBOP.  However, when I have brought it up previously
(including in the BPSS team) there has not been much uptake since it adds
complexity (and power) to the specification.

Is there interest in pursuing this?

Cory

> -----Original Message-----
> From:	Stefano POGLIANI [SMTP:stefano.pogliani@sun.com]
> Sent:	Monday, November 26, 2001 1:16 PM
> To:	Himagiri(Hima) Mukkamala; Cory Casanave
> Cc:	Martin W Sachs; Dale Moberg; ebtwg-bps@lists.ebtwg.org;
> ebxml-cppa@lists.oasis-open.org
> Subject:	RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> 
> Hima,
> 
> 	I think that the "common document" approach you mention
> could lead to a more complex management of information.
> 	- one should look at more than one document
> 	- there may be more than one "common parts"...
> 
> Would it be possible to have the BPSS document referencing
> some parameterized information (like the time to perform you mention)
> and have the CPA (or just any other thing, that's irrelevant from
> the point of view of BPSS) to actually provide an actual value?
> In this way, by reading the BPSS document one would understand
> the process flow and the constraints and will be able to
> define an actual value for the formal parameter in the
> agreement on executing such BP.
> 
> Does this make sense ?
> 
> /stefano
> 
> » -----Original Message-----
> » From: Himagiri(Hima) Mukkamala [mailto:himagiri@sybase.com]
> » Sent: 26 November 2001 19:11
> » To: Cory Casanave
> » Cc: Martin W Sachs; Dale Moberg; ebtwg-bps@lists.ebtwg.org;
> » ebxml-cppa@lists.oasis-open.org
> » Subject: Re: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call
> »
> »
> » Continuing with compositional approach,
> » If someone wanted to model collaborations between
> » multiple partners, but with different parameters at the
> » collaboration level, e.g
> » time to perform, and  want to structure it in such a way that they have
> a
> » different
> » BPSS for each of these, it can't be done as it is now.
> »
> » ActivityNames are a reference to either the BusinessTransaction or the
> » BinaryCollaboration within the document, although it's not
> » explicitly stated.
> »
> » It would helpful to do something like what WSDL does, where the common
> » elements could be defined in a common document and the differing
> » elements be defined in partner specific bpss instance documents.
> »
> » One way would be to use QNames.
> »
> » Brian, May be a 2.0 issue.
> »
> » -hima
> »
> » Cory Casanave wrote:
> »
> » > 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>
> » >
> » > ----------------------------------------------------------------
> » > 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.ebtwg.org/ob/adm.pl>


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


Powered by eList eXpress LLC