[ebxml-bp] 2/12/2004: RSD (Early and Late Binding)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|oais.ebBP;
Topic|Late binding summary;
Point|Lifecycle of a BPSS Instance;
mm1@

Tony Fletcher wrote:

> Dear Colleagues,
> I would like to return to one of the earlier mails from Anders (sorry 
> I seem to have deleted the exact one I was intending to build on - 
> could be the one from 5 Jan 04 in the Archive) and try to make a few 
> other points.
>  
> It seems to me that there is (as I think others have already stated) a 
> natural progression of where one can make statements about the values 
> of certain parameters of a business interchange, such as a 
> TimeToPerform.  Here I am interested in the What and When rather than 
> the How.  The How could be by using schema tricks, or by using CAM 
> tricks or some other technique we eventually agree on - may be more 
> than one according to circumstances.
>  
> It seems to me that the progression is as follows:
>  
> The contract (UBAC work) can establish the master values or say that 
> they are open for determination at a later stage
>  
> The Business Process specification (a use of BPSS) can establish 
> values, perhaps particularly important for default values.
>  
> A CPA can provide agreement to override or establish certain values 
> for the uses of a Business Process specification that it governs
>  
> Some parameters could be overridden / established at the start of (or 
> when first needed) a use of CPA + Business Process specification (an 
> instance of use)
>  
> Some parameters could be overridden / established at the start of a 
> communications session (a long running Business Process specification 
> might have several of these with times of inactivity in between).
>  
> Finally some parameters could be overridden / established by a 
> particular message.
>  
> (Note this ordering is for establishing / overriding parameters.  Of 
> course in principle a BPSS and CPA may be written in order or 
> iteratively, and a contract be written at a later date that references 
> them.)
>  
> Two points occur to me.  The first is that we need somewhere to agree 
> this progression, or some other and exactly what can be overridden / 
> needs to be established at each stage.  One possibility is in the 
> Technical Architecture.  Another possibility is in the UBAC 
> specification.  (A third possibility would be to have the same 
> specification in the UBAC, CPP/A, BPSS and Messaging specifications, 
> but this has obvious problems of trying to maintain consistency and 
> such repetition is usually frowned open and usually only occurs as a 
> temporary measure forced by timing of approval or when folk can not 
> agree on a single place.)
>  
> Secondly, although it seems logical for the things that occur later in 
> time to be able to override things that were 'agreed' earlier (hence 
> the above suggested ordering of the list), it seems to me that the 
> overall contract, the use of the UBAC specification should actually be 
> the master document in some sense.  It seems to me that an electronic 
> contract (a use of UBAC) should state what can be overridden / 
> established when and should be able to set ranges for some parameters 
> that the later stages can not go outside of.
>  
> For instance with regard to a TimeToPerform for a delivery process the 
> contract might say something like: the delivery time request shall be 
> between 1 day and 30 days.  In this case trying to set this value to 2 
> hours or 40 days at a later stage would need be permitted under the 
> terms of this contract / agreement (though of course actually 
> achieving the delivery in 2 hours would be fine!)
>  
> Summary:
> 1) we need to agree where to document this scheme
> 2) we need to agree the precise scheme - what can be established / 
> overridden when
> 3) the contract (use of UBAC) should establish ranges / boundaries or 
> explicitly state that the establishment of a parameter is left to a 
> particular 'later stage'.

mm1: Tony, this mirrors broadly the four BPSS lifecycle categories 
discussed and pretty much agreed upon in the teleconference before the 
F2F.  I think we have two approaches. First, for the near-term, provide 
a mechanism to handle timing parameters (in the context of these 
lifecycle categories) for 2.0. Next, look at the overall issue of late 
binding in a later version. If I have not captured this for those who 
are near and dear to this issue, please chime in.
@mm1