Re: [ebxml-bp] BPSS executability and where it ends

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

John has a point here, Business Entities Types is a powerful concept 
which can tie complex dialogs and business behavior together. BETs got 
characteristics and one or more lifecycles and here one can find an 
important type of lifecycle state: "Fullfilled".

Especially for agreement frameworks such as UBAC it is important to be 
able to adress and regulate all that the thingies dialogs involve and 
refers to. Key is legally relevant artifacts such as "instrument of 
offer" and when the instrument of offer is introduced and accepted by 
both parties.

Apart from BET or "shared business knowledge" it is important to keep 
track of how transactions effect the whole lifecycle of shared 
state-of-affair and BE's. In order to determine, on business and legal 
level, which transactions, messages contains an instrument of offer 
there is a need to identify where Offers are introduced and created. An 
efficient way is to attach "effects" to transactions. It would be a huge 
step forward in term of creating a "business" protocol if business 
semantics were to be found in transactions etc. Just the name of and 
identified document types and transaction types are not enough.

An example of a simple effectlanguage binding that increases the level 
of business semantics in transactions.

<transaction>
   <request>
    <effect force="propose" ontology="myorg-2003" effect-lang="beml">
         create PO with id=123,  
date="/messageenvelope/message[id=abc]/po/date", state=proposed;
    <effect>
    <effect force="propose" ontology="myorg-2003" effect-lang="beml">
         create Car with id=345,  po-id=123, name=Volvo;
    <effect>
   </request>
   <acceptace>
    <effect force="accept" ontology="myorg-2003" effect-lang="beml">
         accept proposal=$transactionRequest;
       <!-- here the PO has been accepted. This can be extracted by 
business systems and mapped to agreements and planning software -->
    <effect>
    <effect force="declare" ontology="myorg-2003" effect-lang="beml">
         state-change id=123 from-state=proposed  to-state=accepted
    <effect>
   </acceptace>
</transaction>

A Business Entity Manipulation Language could easilly be mapped 
downwards to the dml of choice: UML::ActionSemantics, SQL::DML, 
Java::Text, Java::ByteCode, C++ etc,

/Anders W. Tell
Project team Unified Business Agreements and Contracts (UBAC)

Yunker, John wrote:

>This is an area that Business Entity Types was supposed to partially address, by allowing the BPSS to reference named states of business objects (e.g. Shipment is Delivered), and then layering the definition of "Delivered" (rule expression) in the business agreement (being addressed by UBAC).
>
>Note that you could still put the BET state expression on the BPSS transitions (e.g. Invoice.is_Paid AND Product.in_Shipment AND Shipment_is_Delivered), and provide an element in the BPSS where the states could have their complete definition (e.g. < 5% scrap).
>
>By allowing conceptual "business" state to guard the transitions, and then allowing both standard and partner specific definition of those states, we could truly extend the BPSS to be "business process" and not just "message exchange choreography".
>
>John
>
>-----Original Message-----
>From: Boonserm (Serm) Kulvatunyou [mailto:serm@nist.gov] 
>Sent: Thursday, November 06, 2003 6:44 PM
>To: ebxml-bp@lists.oasis-open.org
>Subject: Re: [ebxml-bp] BPSS executability and where it ends
>
>
>I have a comment here that I would like to hear comments.
>
>I think I totally understand the role of BPSS in the B2B Collaboration and its functionality and scope as Monica quoted from the charter makes a total sense to me. However, when I came to think again about this scope against the ebXML vision of dynamically composing, configuring, and execution of the collaboration, the expressiveness of BPSS alone may not sufficiently facilitate that. If the two parties have no way of seeing and dynamically aligning/agreeing with some underlying business logic (which will likely be not apparent in the BPSS), I think such vision will not be realizable. Parties agreeing on the same BPSS only agree on the format and data (not taking into account infra level) to be exchanged and not the behaviors associated with the data. I am not sure if I took the ebXML vision too further away. I understand that some dynamic configuration alignment can happen up to some level like MSH.
>
>Taking a PO example. Even if a PO biz process says that it is the exchange of ProcessPO and AckPO, there can be a lot of other underlining agreement to be done off-line. Like if your shipment has more than 5% scrap, I will return. Will anything like BPEL, etc support this or is there some way to engineer this into the BPSS as of now?
>
>Comments?
>
>-serm
>
>----- Original Message ----- 
>From: "Jussi Lemmetty" <jussi.lemmetty@republica.fi>
>To: "Monica J. Martin" <Monica.Martin@Sun.COM>
>Cc: <ebxml-bp@lists.oasis-open.org>
>Sent: Tuesday, November 04, 2003 3:09 PM
>Subject: RE: [ebxml-bp] BPSS executability and where it ends
>
>
>Monica,
>
>I wasn't completely clear expressing what I meant with BPSS describing 'one side'. How I was trying to visualize the BPSS-configured layer was that it acts as a curtain between organizations stage and backstage. BPSS describes what happens on the (visible to partners) stage. Whatever is bound to the curtains backstage, is not necessarily visible to others. Since BPSS is shared among partners and they might have different runtime-systems, any binding-information (which might be partner-specific) should be in separate definition instance.
>
>I hope this clarified what I had in mind. I was probably thinking the deployment-time too much when writing :)
>
>Jussi
>
>-----Original Message-----
>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
>Sent: 4. marraskuuta 2003 16:58
>To: Jussi Lemmetty
>Cc: ebxml-bp@lists.oasis-open.org
>Subject: Re: [ebxml-bp] BPSS executability and where it ends
>
>
>Jussi Lemmetty wrote:
>
>  
>
>>Hi,
>>
>>I'm yet another one to agree on the executability of BPSS, meaning that
>>    
>>
>BPSS-instance should contain enough information to be deployable without excessive configuration-phase.
>  
>
>>What comes to the definitions of process/transaction binding to 
>>back-end
>>    
>>
>systems, it's getting quite case/implementation/technology dependant.
>  
>
>>During the first teleconference, I mentioned having done something with
>>    
>>
>BPSS and agents (one kind of approach to execution).
>  
>
>>Here's a link: 
>>http://www.kanetti.fi/~juslem/docs/Bridging%20the%20gap.pdf
>>
>>My point is, that there are several ways in practice to produce the 
>>runtime
>>    
>>
>for the BPSS (as expressed already here on the list), so clarification to the boundaries of executability is something I'm eager to see agreed upon. How I see it, BPSS is deployable configuration describing one side of the organizations public process and specifications that are defining the binding to back-end systems should be considered/recommended but not anchored.
>  
>
>>    
>>
>mm1: Jussi, typically BPSS describes the shared view of both parties, not just one party. This is in contrast to lower level views from one party's perspective such as described in WS-BPEL. If you look at your charter and previous specification versions:
>
>"The ebXML Business Process Specification Schema provides for the nominal set of specification elements necessary to specify a collaboration between business partners, and to provide configuration parameters for the partners' runtime systems in order to execute that collaboration between a set of e-business software components." (ebBPSS, v1.05).
>
>Bindings may be within our scope as defined in the charter, although the first primary focus is the specification itself (The bindings may be expressed in white papers or other position documents).
>
>"The ebBP TC may identify bindings to support the business process instance and ultimately the run-time execution. A binding (map) could enable other executable process mechanisms to drive enterprise applications where ebBP controls (rather than create) service behavior."
>
>I believe if we can first place boundaries that differentiate computability and execution, we can lay the groundwork for future development. Thanks.
>
>
>  
>
>>Cheers,
>>Jussi
>>
>>--------------------------------------------
>>Jussi Lemmetty
>>Product Manager
>>Republica Corp., R&D Labs
>>Ohjelmakaari 1
>>40500 Jyväskylä
>>Finland
>>E-mail: jussi.lemmetty@republica.fi
>>Tel. +358 (0)443 011 146
>>http://www.republica.fi/
>>http://www.x-fetch.com/
>>
>>
>>    
>>
>
>
>
>
>
>
>
>
>  
>


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