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



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




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


Powered by eList eXpress LLC