RE: [ebxml-dev] Fork and Join semantics in BPSS 1.04 ver

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

Nandini and I had an offline discussion on this topic,
and here is the digest.

In brief, Nandini's question is:
"can a "join" join activity threads from different forks?"

Short answer is: yes.
The long answer:
BPSS 1.04 specifies a single START state for BinaryCollaboration.
Therefore, at least one common fork must exist for any two threads,
and therefore, a join cannot exist without a fork.

Even though BPSS 1.04 does not specifically state (as far as I can see)
explicitly that a join cannot join threads from different forks, 
case 1 shown by Nandini is permissible.
Would like to know of any holes in this argument?

Regards,

-Suresh
Sterling Commerce   



-----Original Message-----
From: Nandini Ektare [mailto:nandini.ektare@sun.com]
Sent: Wednesday, June 12, 2002 7:22 PM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] Fork and Join semantics in BPSS 1.04 ver


Hi,

I was trying to understand the interpretation of fork and join semantics
in BPSS.

The 1.04 version of BPSS spec (draft format) explicitly says (pg. 31
line 1186) a fork can exist without a join. Is the reverse true? Can a
join exist without a fork?
I can think of a couple of scenarios why a join could exist without
fork:

1. A Binary collaboration process graph as shown below (what I have
tried to depict is a case where a Join joins two paths from different
forks.)
    Here though there is a fork, the join is not a "corresponding join".

    Legend: yellow boxes = forks; purple box = join; green circle = biz
transaction activity

[Image]


2. Another case I can think of is a Binary collaboration process graph
containing transitions into a join with the join having the parameter
waitForAll = false.
    Here the join doesn't need to have any fork.
    Legend: yellow boxes = forks; purple box = join; green circle = biz
transaction

[Image]


Could anyone please throw light on these semantics?

Thanks in advance,
Nandini.