Re: [ebxml-bp] Late binding summary

["Anders W. Tell" <anderst@toolsmiths.se>]

Im sorry David, but dont I see a desired solution here using the context 
mechanism. It dont think its time to resort to a generic document 
transformation mechanism ala XSLT,CAM yet.  IMHO I think we should 
working "with" the BPSS model before taking the route of adding a 
"programing language" solution. Being as generic as CAM is something 
that should be tried if no other solutions are available.

There are plentiful of solutions that work with/in the model and not on 
a storage format level. See followup message in-time to-perform.

Thanks
/Anders


David RR Webber wrote:

>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
>
>
>
>
>
>
>  
>


-- 
/////////////////////////////////////
/ Business Collaboration Toolsmiths /
/ website: <www.toolsmiths.se>      /
/ email: <anderst@toolsmiths.se>    /
/ phone: +46 8 545 885 87           /
/ mobile: +46 70 546 66 03          /
/////////////////////////////////////