Re: [ebxml-bp] Late Binding

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

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, whe and by whom.

* Predictability -> If too much flexibility is available then building 
business systems are not simplified. More expensive COTS. Less is more.

* How can "overriding" be used to create a "natural" way of defining 
timing or other constraints?

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

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

* If you delegate the task of determining timeToPerform to a remote 
method, then what happens in case of invocation failure or timeout?

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

Just to complicate the issue a little ;)

/anders



David RR Webber wrote:

>Anders,
>
>A useful illustrative list - but I think it points up that what
>is really going on here is that we need a generalized
>mechanism.  For today it is TimeToPerform, tomorrow,
>something else.
>
>The context mechanism draft specifically allows you to
>reference any element within the BPSS using
>{namespace}:{XPath}.
>
>The example assumes bpss is the namespace ID,
>so we have:
>
> <condition name="bpss:timeToAcknowledgeAcceptance*" value="P10M"/>
>
>and value denotes the replacement setting.  Of course you have an
>optional conditional constriant to denote when this occurs - and
>again that uses XPath expressions with namespaces to point to
>the late binding needed (see Fgiure 3.2 in draft document).
>
>Bottomline - I believe the context design mechanisms covers this
>neatly and succinctly - using simple XML techniques - and follows
>the BPSS model while extending it in a natural way.
>
>Thanks, DW.
>
>----- Original Message ----- 
>From: "Anders W. Tell" <anderst@toolsmiths.se>
>To: "Dale Moberg" <dmoberg@cyclonecommerce.com>
>Cc: <martin.me.roberts@bt.com>; <ebxml-bp@lists.oasis-open.org>
>Sent: Tuesday, January 27, 2004 1:13 PM
>Subject: Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding
>and Document References
>
>
>  
>
>>Dale,
>>
>>Its a complicated situation, but its clear that timeToPerform is needed
>>however there are several "times" when timeToPerform  could/should be
>>initiated or changed. A list of possible "times" may enrich and simplify
>>the discussions in relation to current set of requirements.
>>
>>1: in BPSS as default value - needed when you want to establish
>>(industry) TradePractices. Here BPSS is reusable artifact that is
>>related to a specific context (such as BusinessArea's, ProcessArea's ala
>>Porter or SCORE). In order words it used by many legal entities.
>>
>>2. in TPA as default value - needed when you want to establish bilateral
>>TradePractices. This value overrides BPSS default value since agreement
>>is established at a later stage
>>
>>3. in Technical agreement such as CPA as default value - this value
>>overrides TPA and BPSS value since agreement is established at a later
>>stage.
>>
>>4. in a negotiated BPSS that specializes an industry BPSS through
>>negotiation process. This is done in the scope of a one more  UBAC,TPA,
>>    
>>
>CPA.
>  
>
>>5. at the time of enactment/instantiation of a BPSS. Here a specific
>>timeToPerform may be proposed by initiator and accepted by responder.
>>Usually not a good idea to let the initiator unilaterally decide,
>>especially if the timeToPerform really means delivery date.
>>
>>6.a by exchanged business information in a transaction. TimeToPerform is
>>extracted from exchanged document during  transaction enactment.
>>
>>6.b by exchanged business information in a transaction. TimeToPerform is
>>extracted dynamically by "invocing a method", "calling a function", etc.
>>during  transaction enactment.
>>
>>7. by referencing a "variable" that contains a duration value that was
>>extracted from an enactment of transaction/completion of another
>>transaction at an earlier point in time. I.e. first transaction sets a
>>variable ttp="valueFromRespondingDocument" at transaction completion
>>with success status
>>
>>8. by the time of enactment,execution of a bootstrap transaction named
>>"ChangeTimeToPerform(bpssInstanceID, transactionActivityID, 2h)". Here a
>>change is proposed and subsecuently accepted or rejected
>>
>>....
>>
>>99. TimeToPerform in a BPSS is not really a constraint on the message
>>exchange protocol but really a delivery-date constraint, that is, a real
>>world event constraint. Possibly in conjunction with a PaymentUpFront
>>business rule.
>>However by putting a delivery-date constraint in a BPPS as TimeToPerform
>>you get an approximation that both parties can live with.
>>
>>Have I missed any relevant time,mechanism?
>>
>>
>>thanks
>>/anders
>>
>>
>>Dale Moberg wrote:
>>
>>    
>>
>>>Martin writes:
>>>
>>>"Late Binding has some interesting and curious requirements.  We tried
>>>to model the ordering process in BT.  We found that the use of the
>>>overall TimeToPerform for a BinaryCollaboration was unworkable.  If I
>>>have a PO that has a standard lead teim of 5 days do I set the TTP to 5
>>>days?  But what happens if the customer does not want their goods for
>>>30days.  The process would time out.  So I would like to treat all Times
>>>and possible documents as being variables that may, but not necessarily,
>>>be overidden by data sent within the Business Documents.  At the moment
>>>there is lots of data that is passed between our customers that effect
>>>the times and documents which we can not use as there is no way to
>>>reference that information within the BPSS."
>>>
>>>Martin, I think you are joining other people who have commented that
>>>TimeToPerform (and also TimeToAcknowledge) can be difficult to know how
>>>to define at BP definition time. This makes me wonder whether they
>>>should be optional to place in BPSS for cases where the time constraints
>>>are known at design time? (Are there any cases of these?)
>>>
>>>In fact, the use cases being presented seem to suggest that
>>>configuration time may also be too early to decide on these values (so
>>>the CPPA really should also have some way to indicate that precise
>>>values will be set at runtime). Would it still be useful to enter into
>>>agreements on the "floor" or "ceiling" for these values? Would this
>>>interval be a configuration aspect of a CPA agreement (or part of BPSS,
>>>or in a UBAC agreement)? Is there any need to retain in CPPA or BPSS any
>>>support for declaring values for these parameters?
>>>
>>>If it is runtime only, should it be part of Messaging headers? Or
>>>possibly in business headers (such as those of ATG SBDH ?) Or both,
>>>depending on which software components need to set or get the values.
>>>
>>>It seems to me that while these values certainly pertain to the business
>>>process commitments, they are not clearly part of the design-time
>>>machinery. It is difficult to know which software components need these
>>>values, or at what layer of specification, the values that are used need
>>>to be declared.
>>>
>>>I am sorry to be raising so many questions but those are ones that occur
>>>to me while reading your remarks.
>>>
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>/////////////////////////////////////
>>/ Business Collaboration Toolsmiths /
>>/ website: <www.toolsmiths.se>      /
>>/ email: <anderst@toolsmiths.se>    /
>>/ phone: +46 8 545 885 87           /
>>/ mobile: +46 70 546 66 03          /
>>/////////////////////////////////////
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>


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