RE: [ebxml-bp] Clarification - FORK and BusinessTransaction

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Responses in-line.

-----Original Message-----
From: Anders W. Tell [mailto:anderst@toolsmiths.se] 
Sent: Friday, May 14, 2004 1:31 PM
To: BPSS ebXML
Subject: Re: [ebxml-bp] Clarification - FORK and BusinessTransaction


Sorry guys , Im in a why mood today;)

Dale Moberg wrote:

>A lot of this functionality is not yet needed for designs, and possibly

>never will find a niche. But we do need to allow RequestResponse BTs 
>where, after the Request, but before the Response, there is another 
>Transaction. The refactor part 2 certainly allows this and builds on 
>the ideas of onInitiation in earlier drafts.
>  
>

Could you elaborate on why there is a need for more levels? Why not 
break the transaction into two transaction, one for request and one for 
response?

Dale> The RequestResponse unit-of-work that is a BusinessTransaction is
supposed to be a unit of work, between parties. I prefer "unit" to
"atom" because apparently there are misleading connotations of "atom"
It is something supposedly documented from a legal standpoint by
UNCITRAL. 

Haugen and Fletcher apparently posed questions about business process
involving numerous transactions, not done one after the other, but
rather ones wherein between the Request and the Response, other
transactions with other parties occurred. That seems to be a possible
class of cases to me. It has been represented before and I am simply
refactoring syntax in a way that seems to recognize that interpolating
BTs between stages of another process is useful to represent.

These have been called "nested" or "embedded" and so on. For monitoring
and verification, a verifier needs to know that after the Request,
another Transaction needs to be monitored, and its status assessed,
before it then proceeds to verify the status for the original
Transaction. This maintenance of tracking is facilitated by
syntactically showing somehow that one transaction depends on another in
a way that is distinct from the syntactic markers that indicate one
follows the other. There might be many ways to invent syntax to show
this dependency. I am trying to stick to one that is not too distant
from what was available when I came in.

It would be technically possible, perhaps, to have a Notification
followed by a Notification. However, the semantic state primitives of
BPSS have been the BTAs (each related to a BT). I have not sought to
overturn that form of representation, because that is what supposedly
represented the unit of work of UNCITRAL, and I chose to make those
choices work within a notation for process, regarded as a state
transition graph over the chosen states. 

Your query then, should probably be redirected to UNCITRAL, and why they
have chosen a RequestResponse, when they could have had two
Notifications. I assume they would say they had different commitments
reflected, and it was not appropriate to analyze in that fashion. I am
sure you can tell us in some detail how those commitments differ.

For my own part, I am presently looking for a notation that allows a
computational task to be performed. This task is checking on document
flows, statuses, timers, etc, and then transitioning in accordance with
the events that have occurred to the next relevant state(s). This is not
to say that I am indifferent to all the legal nuances, but it does
reflect thinking about the OASIS requirement that at least 3 companies
can testify to satisfactory use of the specification. These will be
software vendors, mainly, because they will need to use that the schema
is workable. 

Many levels of interest need to be satisfied in getting a specification
done. The business semantics, such as they are, are found in the QOS
attributes and the flavors of BTs. Monitoring and verification also need
to be possible. Graphical display needs to be possible. Aligning with
CPPA needs to be possible. And so on.


>We need to establish that atomicity is compatible with subtransactions.
>  
>

Could you elaborate on why this is need? 

Dale> See above for a start.

Could you elaborate on your definition of atomicity?

Dale> This was not my choice of words but John's. I will let him explain
what he meant. You now make me think he wasn't necessarily thinking of
completes as a whole or not (though I personally think that is involved)
Certainly other parts of ACID are not here under discussion. I think
that he is thinking of a unit of business collaboration in which state
alignment is attained with respect to some underlying business agreement
(PO, POConfirm). I am not a theorist of such items so I defer to those
who wish to define what constitutes the Unit, and what is the "essence"
common to the UNCITRAL named items.


>We may wish to have some WF rules for UNCITRAL forms that mandate 
>certain interfaces of superordinate BT with subordinate BT. We should 
>definitely allow some time Monday to discuss atomicity and 
>subtransaction, if you are able to be on the call.
>  
>
Could you elaborate on why there is a need for more levels? Why not use 
what we have?

Dale> We are using the levels we have. This just rewrites what was
already present in "onInitiation" as far as I can tell. You could get
multilevels with onInitiation if you chained together a whole lot of
Transitions with the onInitiation attribute set. I think it is cleaner
to give this importantly different item a different name, and start to
analyze the "glue" that makes up the dependency (see Returns). It might
also be possible to refactor CollaborationActivity to cover this case. I
took a hint from UML Activity model which thought it worthwhile to
distinguish SubMachineState from Composite (and Simple) as kinds of
State. Since CollaborationActivity packages up BinaryCollaborations as
"states," it seemed more like a SubMachineState than a Composite. But I
am flexible as long as we at least start to introduce a notation that
permits subordination (so that eventually (v 3.0 or so) we can relate
BPSS to other problems such as Coordination and Transaction/Coherence).
And in the meantime, we have a notation that is more explicit (and not
so ingeniously subtle) as the one we have had. [Afterthought: it might
be better to think of "level" here as more like a new swim lane (where
swim lanes correspond to partner pairs.)] 

Hope that helps. If there is something radically new in what I did, then
the refactoring is probably not working correctly. So please raise your
concerns on the next couple of calls to see that they are properly
addressed and at the right level :-)

/anders

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