[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