OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-bp] Clarification - FORK and BusinessTransaction


Anders,

I think I'm done with this all!  I've managed to implement the Fork
and Join so that it does not break the BusinessTransaction into pieces.

What I was missing - if you view the interactions as from left to right,
requester < - > responder; I was trying to use the Fork on the RHS,
coming back from the responder to the requester - it *never* goes
there (a la BPEL thinking!).  It must always be used on the LHS,
by the requester to initiate the next sequence, based on the outcome
from the prior BusinessTransaction step.  However conversely Join
will always occur on the RHS, not the LHS, since it must tie together
potential multiple responses from the responder.

Once you grok this - all is well with our world - since we have this
cause and effect model around a single initiating transaction action.

Now of course Dale raised the issue of sub-transactions et al - 
but so long as those are viewed as a logical transaction instance
at the initiation - with a "beginsWhen" condition controlling the 
outset - then our model integrity is maintained.

OK - back to finishing the XML outputting stuff so I can send
everyone the example to visualize!

Thanks, DW

----- Original Message ----- 
From: "Anders W. Tell" <anderst@toolsmiths.se>
To: "BPSS ebXML" <ebxml-bp@lists.oasis-open.org>
Sent: Friday, May 14, 2004 4:26 PM
Subject: Re: [ebxml-bp] Clarification - FORK and BusinessTransaction


> Yunker, John wrote:Message
> 
> > We can get into trouble if we break up the atomicy transactions.
> 
> 
> The so called businesstranaction is a key element. It is a 'unit of 
> shared understanding' in the sense that both partes has the same view 
> after its execution. Breaking it into pieces would complicate keeping 
> track of the "business/legal semantics".
> 
> Altough the name of Business*Transaction* is highly infortunatelly 
> because it leads the thoughts to ACID and rollback etc. making a 
> business statement whether it is by phone, email, ebMS or webservices 
> are all equal and can very seldom be retracted. So thinking IT ACID 
> semantics most if the time leads to the wrong conclusions.
> 
> I talked today to a retired Judge specialized in eCommerce IT law and 
> its very much clear that what IT often talk about is far from the legal 
> doscussion.
> An example: I national laws there are rules for when a document has 
> reached a government organization, these rules vay from country to 
> country but interesting enough many rules state a document has reached 
> the organization when the envelope containing the document has beed 
> handed over to the "janitor". This means that the content, format etc 
> has NOT been check, validated etc. One doesnt even know the envelope 
> contains a document or not.
> How does this example relate to ebXML, well it could mean that ebMS 
> Acknowledgement has a meaning which BPSS partially deals with.
> 
> /anders
> 
> -- 
> /////////////////////////////////////
> / Business Collaboration Toolsmiths /
> / website: <www.toolsmiths.se>      /
> / email: <anderst@toolsmiths.se>    /
> / phone:  +46 8 562 262 30          /
> / mobile: +46 70 546 66 03          /
> /////////////////////////////////////
> 
> 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]