Re: [ebxml-bp] Dynamic (late) binding proposal - take 3 now with diagram

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

Anders,

I'm a bit confused by some of this.  Surely right now the
transport layer has the timers in it already - so no
need for this - you just have a <failure> condition on
timeout - (see how I've done this in my BPSS model
already).

And then - the context mechanism V2 proposal and
latest V2 schema *already* supports the use of
variables and associating a context instance.
(Have you read the context mechanism proposal I have
posted?).  I don't agree this is a path to unforeseen
sideeffects.  That's the whole point of the external
context mechanism - that there are *no* unforeseen
options - all are known and perscribed and
agreed at design time.

Again - the BPSS model example includes this coupling,
and the tutorial PPT explains it in detail.

However - having said all this - linking events into this
I believe is a V3 item.  So far the context mechanism
supports using variables and rules relating to document
content (eg: if urgentOrder="true", etc).  Simple stuff.
Use of an event to change BPSS aspects is another
whole item that would need to be thought thru.

Thanks, DW

----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Saturday, May 22, 2004 5:12 AM
Subject: Re: [ebxml-bp] Dynamic (late) binding proposal - take 3 now with
diagram


> Please find next version 3 of the LateBinding Pattern.
>
> This version has some new apspects in it such as the possibility to
> relate binding to Events,
>
> The bindingTime contains an initial set if types but could be extended
> to handle more variations.
>
> The bindingBasis points to an runtime instance of CA-BI or BAT-BT and
> together with the boundEvent it determines when the value is
> instantiated. It also open up for possibly adding Timers in V3, ie if
> nothing happens for 3 hr a Timeout could be establised.
>
> The following example show hows to pick out a TTP from the request message
> <BusinessTransaction>
>   <RequestMessageTTP defaultTTP="2h" boundWhen="OverridePossible"
>                           bindingBasis="./RequestMessage"
> boundEvent="CompletionEvent" >
>      ./MessageEnvelope//ResponceTime
>   </RequestMessageTTP>
> </BusinessTransaction>
>
> Reference path is:
>  BTANameID/RequestMessage/MessageEnvelope//ResponceTime
>
> The VariableTimeToPerform and ExternaTTP and optional future elements
> where you can can get values from a runtime "variable" (this is of
> course not part of V2) and external is an extensionmechanism for the
> brave ones who want to sidestep the BPSS and enter into the area of
> possible and unforseen sideeffects.
>
> /anders
>
> Anders W. Tell wrote:
>
> > Please find the following diagram outlining one way of formulating
> > dynamic or late bound TimeToPerform or similar parameters.
> >
> > At the top there is a abstract superclass that does not turn up in the
> > document, the concrete subclasses does.
> >
> > The BindingTime speficies when binding occurs, i.e. which
> > collaborationEvent(s). (maybe this should also be an element?)
> > Default value is the value before binding occurs
> > TTP duration can be ORed together with Union.
> >
> > <TimeToPerform boundWhen="enclosingCollaborationInitiationEvent">
> >  <Union>
> >      <StaticTimeToPerform>2h<StaticTimeToPerform>
> >
> > <RequestMessageTTP>//MessageEnvelope//ResponceTime</RequestMessageTTP>
> >  </Union>
> > <TimeToPerform>
> >
> > This patterm may be used for other parameters that are candidates for
> > dynamic binding..
> >
> > /anders
> >
>
>
> -- 
> /////////////////////////////////////
> / Business Collaboration Toolsmiths /
> / website: <www.toolsmiths.se>      /
> / email: <anderst@toolsmiths.se>    /
> / phone:  +46 8 562 262 30          /
> / mobile: +46 70 546 66 03          /
> /////////////////////////////////////
>
>
>


----------------------------------------------------------------------------
----