Late binding summary

[<Lars.Abrell@teliasonera.com>]

Hi, I will try to make a summary of the discussions around "Late bindings" as far as I understand it right now:

1) There are several different "times" or stages when some "value or statement" in a BPS could be initiated or changed. 
I believe there are at least four such stages that are important to us 
a) when the BPS is first defined based on business knowledge in a company or in an industry
b) when this defined BPS later on is used as the base for an agreement (CPA) between two parties
c) when this agreed BPS later on is instantiated into a conversation by one of the parties sending a message (and giving it a conversation-id) 
d) when this instantiated BPS during runtime [A] may enter into a sub-collaboration (CollaborationActivity) or BTActivity   
There might be other stages also in "the lifetime and use" of a BPS (see the list from Anders Tell) but I think that the four stages above are the most important ones for us to discuss right now.

2) I also believe there is a difference between the stages (a+b) and (c+d) above.
When you at stage (a) define a BPS or at stage (b) make an agreement to a BPS you could define/agree on an allowed "value range" (for example for timeToPerform). But when you in runtime at stage (c) or (d) enter into and instantiate a BPS (main outer collaboration) or a sub-collaboration/BTActivity you need to have an explicit and precise value [C]. I think that when you are at the stages (a+b) the BPSS spec and/or the CPPA spec should allow you to specify a value range, which is not the case with the current specs.

3) The "things" in a BPS that could be initiated or changed or more accurately specified at any of the stages mentioned above is not only the timeToPerform value, but also other values. I believe that we need to discuss more about what things in a BPS should at all be allowed to be changed or more accurately specified at any of the later stages mentioned above. 

Is it OK, at some later stage (in the lifetime and use of a specific BPS) to
- Skip BusinessTransactions/BTActivities
- Insert BusinessTransactions/BTActivities
- Override transition or transition rules
- Change GuaranteedDelivery 
- Change Transaction Documents 
- Change Signals: Receipt/Acceptance and the TimeToReceipt/Acceptance 
- Change Time-outs: for a Collaboration, BTActivity, 
- Change DocumentSecurity: Confidential/Tamperproof/Authenticated

For example: 
- Is it OK to "skip a BusinessTransaction/BTActivity" in a "(industry) generic BPS" when you agree to it in a CPA? I think this may be OK.
- Is it OK to "skip a BusinessTransaction/BTActivity" in an agreed BPS in a CPA when you instatiate a conversation? I'm not sure - it may be OK 
- Is it OK to "insert new BusinessTransactions" in a "(industry) generic BPS" when you agree upon it in a CPA? I think not - then it is a "new BPS"
- Is it OK to "change/specify time-outs" to a Collaboration or BTActivity in an agreed BPS in a CPA when you insatiate a conversation? I think this is OK.
- etc. etc. 

4) We also might want some mechanism in the BPSS spec that makes it possible to say that, even if the BPSS spec in general allows you to change a certain value/statement at a later stage, it is in this specific BPS not allowed to change this specific value/statement at a later stage. (At the moment I have no use case.)

Have I missed anything important?

[A] A BPS is not running and not executed, but is keeping track of where in the flow the process/collaboration is at any given time 
[B] This explicit and precise value could need to be "renegotiated" or "reinitiated" into another equally explicit and precise value at an even later stage (if for example something happens later on in the "real world" outside the instantiated BPS), but I think we should not discuss that extension right now.   

* Lars.Abrell@TeliaSonera.com * +46 (0) 705 619080
* Kilsgatan 4, Box 299, SE-401 24 Gothenburg, Sweden