It will be a more declarative approach than running a complicated algorithm.. I mean for business situations.. not for pure graph analysis. you are right. That's why the use case that you are trying to tackle down is extremely important.
Cheers

On Mon, Aug 15, 2011 at 10:05 PM, Kris Verlaenen <kverlaen@redhat.com> wrote:
That might be possible, but not sure rules would be ideal to do graph analysis.  While in simple cases this would work, performance might blow up in more complex cases where more complex reachability analysis is necessary, which can probably be done upfront during compilation as well, using specialized algorithms.

Kris

Mauricio Salatino wrote:
I was thinking for a different situation, instead of transversing the process graph, insert all the nodes in the working memory, allowing us to create rules to evaluates situations. I was thinking to do something similar to the declarative agendas, where the activations are inserted. I think that this feature will be extremely helpful and we can tackle down situations like this one.
I will probably create a different thread for that.
Cheers

On Mon, Aug 15, 2011 at 9:53 PM, Kris Verlaenen <kverlaen@redhat.com <mailto:kverlaen@redhat.com>> wrote:

   Antoine,

   While we would like to support all constructs as defined in the BPMN2
   specification, we currently do not support the OR gateway yet.
    Since it
   is a rather advanced construct (especially if you start using it in
   combination with (unstructured) cycles), we in general recommend users
   to try and avoid this complexity by trying to remodel the business
   problem using a combination of (the much simpler) XOR and AND
   gateways.
   Therefore, the construct is not yet on any specific release.

   The best way if you want to track progress would be to create a JIRA
   issue I would say, that we will then use to report progress when
   implementing this feature.  It would also allow other users to
   vote for
   this issue to keep track of interest.

   The implementation would be an extension of the generic Join node (and
   JoinInstance), where the logic to decide when to continue would
   not only
   keep track of the "tokens" that already arrived (as is already done in
   the current implementation) but would also check for incoming branches
   that don't have a "token" yet whether there aren't any active node
   instances that could still reach this incoming branch.  In most cases
   this can be done by simply traversing the process graph.  But we could
   add support for complex cases, where the graph reachability
   analysis is
   done during process compilation (to avoid runtime overhead) and to
   support more complex cases (where for example the join instance would
   need to register as a listener to the process instance to make sure it
   is re-evaluated whenever necessary).

   Kris

   Antoine Toulme wrote:
   > The BPMN spec contains the business requirements and the description
   > of the functionality of this construct.
   > Anurag also explained the functionality in this thread.
   >
   > The questions we have for the jBPM team are:
   > -is this construct on the roadmap ? if yes, for which release ?
   > -if yes, is there a way to track its development ?
   > -Overall, what would the work consist and how hard is it to
   implement ?
   >
   > Please advise.
   >
   > Antoine
   >
   > On Fri, Aug 12, 2011 at 9:00 AM, Mauricio Salatino
   <salaboy@gmail.com <mailto:salaboy@gmail.com>
   > <mailto:salaboy@gmail.com <mailto:salaboy@gmail.com>>> wrote:
   >
   >     That's what I mention. it can be easy to implement most of the
   >     times but there are also some complex business use case that can
   >     complicate the generic approaches.
   >     Looking at a concrete use case will help a lot to understand
   what
   >     do you want to achieve.
   >
   >
   >     On Fri, Aug 12, 2011 at 12:53 PM, mardo <mardo@abicola.de
   <mailto:mardo@abicola.de>
   >     <mailto:mardo@abicola.de <mailto:mardo@abicola.de>>> wrote:
   >
   >         Hi there,
   >
   >
   >
   >         just some general remarks from my side:
   >
   >
   >
   >         the semantics and implementation of the inclusive
   OR-join are
   >         far from trivial. See e.g. references below.
   >
   >
   >
   >            http://domino.research.ibm.com/library/cyberdig.nsf/papers/331BE249A11C1B3F852577DE003B5477/$File/rz3791.pdf
   >
   >         http://www.springerlink.com/content/97413825k6141332/
   >
   >
   >
   >         However, I’d be interested in the concrete business
   >         requirement you have for modeling, since from my experience
   >         you can cover a very large part of regular requirements just
   >         using the “simple” gateways.
   >
   >
   >
   >         Best
   >
   >
   >
   >         Markus
   >
   >
   >
   >
   >
   >
   >
   >         *From:* jbpm-dev-bounces@lists.jboss.org
   <mailto:jbpm-dev-bounces@lists.jboss.org>
   >         <mailto:jbpm-dev-bounces@lists.jboss.org
   <mailto:jbpm-dev-bounces@lists.jboss.org>>
   >         [mailto:jbpm-dev-bounces@lists.jboss.org

   <mailto:jbpm-dev-bounces@lists.jboss.org>
   >         <mailto:jbpm-dev-bounces@lists.jboss.org
   <mailto:jbpm-dev-bounces@lists.jboss.org>>] *On Behalf Of
   >         *Mauricio Salatino
   >         *Sent:* Freitag, 12. August 2011 14:21
   >         *To:* Anurag Aggarwal
   >         *Cc:* jbpm-dev@lists.jboss.org
   <mailto:jbpm-dev@lists.jboss.org> <mailto:jbpm-dev@lists.jboss.org

   <mailto:jbpm-dev@lists.jboss.org>>
   >         *Subject:* Re: [jbpm-dev] Re- IOR gateway
   >
   >
   >
   >         Hi Anurag,
   >
   >         Based on your description I think that I'm understanding
   what
   >         do you want to do now.
   >
   >         Right now the behaviors implemented in jBPM5 are XOR and
   AND.
   >
   >         I think what you want to implement is N of M converging
   >         gateway, as it was in Drools Flow? Am I right?
   >
   >         You want to wait 2 of the 3 branches that you have to
   >         propagate the execution?
   >
   >
   >
   >         Cheers
   >
   >         On Fri, Aug 12, 2011 at 5:47 AM, Anurag Aggarwal
   >         <anurag@intalio.com <mailto:anurag@intalio.com>
   <mailto:anurag@intalio.com <mailto:anurag@intalio.com>>> wrote:
   >
   >         Hi Mauricio,
   >
   >
   >
   >         If an an AND converging gateway has n incoming branches, it
   >         expects that all incoming have been triggered and when it is
   >         so - it calls triggerCompleted (so that the rest of the
   >         process can continue)
   >
   >
   >
   >         In case of OR converging, lets assume a process
   >
   >
   >
   >                                 branch1
   >
   >                              /               \
   >
   >         OR (diverging) - branch 2 -  OR (converging)
   >
   >                              \               /
   >
   >                                branch 3
   >
   >
   >
   >         now any of branches may be triggered, OR converging has to
   >         wait for all branches that were actually triggered (say
   >         branch1 and branch 3). But the problem is it does not know
   >         which branches were triggered (for AND it was easier - just
   >         wait for all branches to be triggered). here in case of OR -
   >         we don't know to continue to wait for branch 2 or not
   >
   >
   >
   >         Regards, Anurag
   >
   >
   >
   >         On Aug 12, 2011, at 1:18 AM, Mauricio Salatino wrote:
   >
   >
   >
   >         Hi Antoine,
   >
   >         So do you want to implement and OR or and AND converging
   >         gateway, by the description it looks like and AND converging
   >         gateway. Is there any differences with the AND converging
   >         gateway that is currently implemented in jBPM5?
   >
   >
   >
   >         Cheers
   >
   >         On Thu, Aug 11, 2011 at 4:46 PM, Antoine Toulme
   >         <atoulme@intalio.com <mailto:atoulme@intalio.com>
   <mailto:atoulme@intalio.com <mailto:atoulme@intalio.com>>> wrote:
   >
   >         Hi Mauricio, that's an OR converging gateway.
   >
   >
   >
   >         On Fri, Aug 12, 2011 at 12:42 AM, Mauricio Salatino
   >         <salaboy@gmail.com <mailto:salaboy@gmail.com>
   <mailto:salaboy@gmail.com <mailto:salaboy@gmail.com>>> wrote:
   >
   >         Hi guys.. that's the AND Converging gateway right?
   >
   >         The AND waits for all the branches that are converging
   before
   >         propagate.
   >
   >         If that's not what you are looking for it should be very
   easy
   >         to implement.. and probably you can model that with the
   >         complex converge gateway.
   >
   >
   >
   >         Cheers.
   >
   >         On Thu, Aug 11, 2011 at 4:33 PM, Antoine Toulme
   >         <atoulme@intalio.com <mailto:atoulme@intalio.com>
   <mailto:atoulme@intalio.com <mailto:atoulme@intalio.com>>> wrote:
   >
   >             Broadcasting to list in case other committers have an
   >             insight ?
   >
   >
   >
   >             Antoine
   >
   >             On Thu, Aug 11, 2011 at 12:39 PM, Anurag Aggarwal
   >             <anurag@intalio.com <mailto:anurag@intalio.com>
   <mailto:anurag@intalio.com <mailto:anurag@intalio.com>>> wrote:
   >
   >             Hi Kris,
   >
   >             How are you
   >
   >             Recently one of our requirements came up for converging
   >             IOR gateway, this is the gateway which according to bpmn
   >             specification syncs up on all upstream tokens and
   >             propagates token when no upstream token is left
   >
   >             Currently jbpm does not support this construct, I was
   >             wondering if jbom has this in roadmap and if you can
   give
   >             some advice on difficulty and state  of implementation
   >
   >             Regards,
   >             Anurag
   >
   >
   >
   >
   >
   >             _______________________________________________
   >             jbpm-dev mailing list
   >             jbpm-dev@lists.jboss.org
   <mailto:jbpm-dev@lists.jboss.org> <mailto:jbpm-dev@lists.jboss.org

   <mailto:jbpm-dev@lists.jboss.org>>
   >             https://lists.jboss.org/mailman/listinfo/jbpm-dev
   >
   >
   >
   >
   >         --
   >          - CTO @ http://www.plugtree.com <http://www.plugtree.com/>
   >          - MyJourney @ http://salaboy.wordpress.com
   >         <http://salaboy.wordpress.com/>
   >          - Co-Founder @ http://www.jbug.com.ar
   <http://www.jbug.com.ar/>
   >
   >          - Salatino "Salaboy" Mauricio -
   >
   >
   >
   >
   >
   >
   >         --
   >          - CTO @ http://www.plugtree.com <http://www.plugtree.com/>
   >          - MyJourney @ http://salaboy.wordpress.com
   >         <http://salaboy.wordpress.com/>
   >          - Co-Founder @ http://www.jbug.com.ar
   <http://www.jbug.com.ar/>
   >
   >          - Salatino "Salaboy" Mauricio -
   >
   >
   >
   >
   >
   >
   >         --
   >          - CTO @ http://www.plugtree.com
   >          - MyJourney @ http://salaboy.wordpress.com
   >
   >         - Co-Founder @ http://www.jugargentina.org
   >          - Co-Founder @ http://www.jbug.com.ar
   >
   >          - Salatino "Salaboy" Mauricio -
   >
   >
   >
   >
   >         _______________________________________________
   >         jbpm-dev mailing list
   >         jbpm-dev@lists.jboss.org
   <mailto:jbpm-dev@lists.jboss.org> <mailto:jbpm-dev@lists.jboss.org

   <mailto:jbpm-dev@lists.jboss.org>>
   >         https://lists.jboss.org/mailman/listinfo/jbpm-dev
   >
   >
   >
   >
   >     --
   >      - CTO @ http://www.plugtree.com
   >      - MyJourney @ http://salaboy.wordpress.com
   >     - Co-Founder @ http://www.jugargentina.org
   >      - Co-Founder @ http://www.jbug.com.ar
   >
   >      - Salatino "Salaboy" Mauricio -
   >
   >
   >     _______________________________________________
   >     jbpm-dev mailing list
   >     jbpm-dev@lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
   <mailto:jbpm-dev@lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>>

   >     https://lists.jboss.org/mailman/listinfo/jbpm-dev
   >
   >
   >
   ------------------------------------------------------------------------
   >
   > _______________________________________________
   > jbpm-dev mailing list
   > jbpm-dev@lists.jboss.org <mailto:jbpm-dev@lists.jboss.org>
   > https://lists.jboss.org/mailman/listinfo/jbpm-dev
   >
   _______________________________________________
   jbpm-dev mailing list



--
 - CTO @ http://www.plugtree.com 
 - MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar
 
 - Salatino "Salaboy" Mauricio -