Re: [ebxml-bp] Late binding summary

["David RR Webber" <david@drrw.info>]

Lars,

Excellent summary.

I obviously see the context mechanism as
the "missing piece" here needed to complete the picture of
CPA + BPSS + Transaction processing in the real world.

Being able to drive context by referencing between CPA,
BPSS and Document factors will complete the picture,
and the context mechanism proposal does this
with the three names spaces -
as:{statement}, bpss:{xpath ref}, doc:{xpath expression}

It does make sense for us to also caution people and
provide suggested best practices over what may be
done with late binding against the BPSS and CPA,
and we could tailor the bpss:{xpath ref} to specifically
detect conditions that would cause the underlying ebMS
to fail.  Perhaps the simpliest way to ensure operation
is to make it so that both sender and reciever ebMS
are using complimentary sets of functions.

If we wanted to - we could derive that set - and then
have those are part of bpss:{function} - where instead
of accessing the BPSS {xpath} directly - we
used a level of abstraction like:

 bpss:setAutoResponse="off"

and this would then allow us to automatically
configure the correct behaviours for users.

i.e. there are two ways people can go - they
either code explicit xpath to a piece of BPSS
that they want to set with some value, or they
use a set of predefined 'safe' functions that will
set some behaviour for them - without them
needing to know about the XML settings
directly.

Is that the sort of thing you are thinking of
here as a means to implement everything
consistently?

Thanks, DW

----- Original Message ----- 
From: <Lars.Abrell@teliasonera.com>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, February 01, 2004 4:06 PM
Subject: [ebxml-bp] Late binding summary


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