[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] Fork and Join semantics in BPSS 1.04 ver
Suresh: It is preferable to avoid these boundary cases if you can. I would recommend to write collaboration with symmetric fork and join. I think that a fork without join is no problem as "threads" will be managed until one of them reaches an end state of the collaboration. After that remember that the collaboration will be closed and all further messages will be rejected. Now when it comes to joins associated with different forks, this is actually not so different than a fork without join, you would have threads to manage just as well and the rule about ending the collaboration would also apply. So there is no need to enforce that fork/joins are symmetric, you just have to be aware of the behavior. Jean-Jacques Dubray____________________ Chief Architect Eigner Precision Lifecycle Management 200 Fifth Avenue Waltham, MA 02451 781-472-6317 jjd@eigner.com www.eigner.com >>-----Original Message----- >>From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] >>Sent: Thursday, June 13, 2002 7:42 PM >>To: ebxml-dev@lists.ebxml.org >>Cc: 'nandini.ektare@sun.com' >>Subject: RE: [ebxml-dev] Fork and Join semantics in BPSS 1.04 ver >> >>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. >> >> >> >> >> >> >> >> >> >> >>---------------------------------------------------------------- >>The ebxml-dev list is sponsored by OASIS. >>To subscribe or unsubscribe from this elist use the subscription >>manager: <http://lists.ebxml.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC