Re: [ebxml-bp] Late Binding

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

Anders,

Ok - I'm not seeing anything here in your laundry list
that conflicts with the context approach.  See my
notes below!

Cheers, DW.

----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, January 27, 2004 2:41 PM
Subject: Re: [ebxml-bp] Late Binding


> David,
>
> Im not sure I fully agree with you. Im pointing to the fact that the
> problem is more problematic than just defining a value=function()
> mechanism. I agree that more parameters that timeToPerform are subject
> to dynamics changes, but we are discussing a business protocol so IMO
> more aspects comes into play.
>
> * Establisment of Trade Practices by an organization -> what values are
> defined where, when and by whom.
>
 DW:  Obviously these will reflect the BPSS and industry domain exactly.
 In fact some factors may go across a domain very nicely - example
 grocery industry - refridgerated goods - Y/N ?  The industry CoI must
 be free to set their important metrics in this way - we cannot legislate
 against that.
>
> * Predictability -> If too much flexibility is available then building
> business systems are not simplified. More expensive COTS. Less is more.
>
 DW: What the BCM and CAM work teaches us is that these factors that
 "bubble up" here to the CPA are the "big ticket" ones.  By exposing them
 at the CPA level - you get that consistency - that is LOST if you bury them
 down lower.  These factors are globally important across the BPSS, and
 that is why we see them declared in this way.  Other factors can be
 handled easily locally at the interchange layer - forinstance CAM
templates.
 So we do not get trivial factors flooding the CPA layer.  I can show you
 example templates that clearly show this working in practice - in fact
 Figure 3.2 is a good illustration of this.  (The CCTS work also agrees
 with this in terms of context of core components and the factors that
 one takes into account to derive context varables).
>
> * How can "overriding" be used to create a "natural" way of defining
> timing or other constraints?
>
 DW: By tying it to the existing BPSS structure.  We are not allowing
 people to morph or extend the BPSS itself - so this is a naturally
 constrained facility here.  The namespace bpss: is also intuitive way
 to reference the BPSS elements.

> * In the  business domain there is need for "propose-accept-reject"
> semantics and not only "declare". Agreed business procedures often need
> consent before changes can be applied.
>
  DW: we're not supplanting that - the context instance becomes part of
  the CPA process - infact its empowering - because now people can
  exactly see what business rules directly impact their process - whereas
  before they could be hidden in the transaction layer - as late binding
  issues.  We can "pretty print" the rules in say HTML from the XML
  to help the management sign-off.  And you can propose changes and
  accept / reject the context document just as with the CPP/CPA itself.

>
> * Are you trying to use BPSS to solve another problem? (real world vs
> virtual, communication world)
> As Bob Haugen pointed out, many timing constraints could be viewed/are
> really notification committments/duties.
> (see slide
> 11<http://www.toolsmiths.se/documents/serviam_legal_20040202.pdf> for an
> example)
>
  DW:  Not at all.  What we're providing is the context mechanism that is
  currently missing.   You can map between say UML business rules, and
  the XML format for those as part of the CPA very easily indeed.

>
> * If you delegate the task of determining timeToPerform to a remote
> method, then what happens in case of invocation failure or timeout?
>
  DW:  We are NOT doing this.  The context is EXPLICTLY managed
  by the BPSS engine - by looking at the intersection of three factors:
  as:function() statements, bpss:reference(s) and doc:transaction details.
  All these are within the BPSS environment and there are no external
  calls.

> * If you delegate the task of determining timeToPerform to a remote
> method, then isnt really defining another BusinessTransaction the right
> way to go if the remote methods is located in one of the parties
> business IS/IT system?
>
  DW: See note above - NA.

> Just to complicate the issue a little ;)
>
> /anders
>
DW: Anders - actually that is the whole point of the context mechanism;
 it is not complicated.  It is a simple, discreet approach that provides
 a restricted and focused mechanism that fits into the existing CPA
 and BPSS metaphors and enables business rules.