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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: Re: [ebxml-bp] Early and Late Binding


Tony,
 
I agree with your overview here - but not that the use and
boundaries be perscribed.
 
I believe the 6 patterns show that we can provide these as
illustrative, but then people need to
provide their own context configuration - and we need to
just state that when that occurs that they need to be
cognisent of ensuring that they fulfil legal business
requirements - we cannot guarantee that.
 
We provide the tools - they determine how to use them.
 
The IV&I example I posted shows this exactly - where
you need to model the process as descrete steps that
have their own TTP settings and own start conditions.
So we cannot antipicate what the answer is for a given
scenario.
 
DW.
----- Original Message -----
Sent: Thursday, February 12, 2004 11:03 AM
Subject: [ebxml-bp] Early and Late Binding

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'.
 
Best Regards     Tony
A M Fletcher
Home: 35, Wimborne Avenue, IPSWICH  IP3  8QW
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 amfletcher@iee.org     (also tony.fletcher@talk21.com  &  tony_fletcher@btopenworld.com)
 


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