Exactly, that's the other option, or you can use any async implementation that you want to achieve that. but the messages will be created in sequence.<br><br><br><div class="gmail_quote">On Fri, May 28, 2010 at 11:46 AM, Alejandro Guizar <span dir="ltr"><<a href="mailto:aguizar@redhat.com">aguizar@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Eric, if you really want parallel execution, you can set async="true" on<br>
all nodes following a fork.<br>
<br>
As for JMS, there are already two options, the MDB solution in the<br>
"enterprise" module or the JCA inflow alternative shipped in the ESB.<br>
<br>
FWIW, the default job executor *can* scale.<br>
<a href="http://www.theserverside.com/news/1363588/Scalability-and-Performance-of-jBPM-Workflow-Engine-in-a-JBoss-Cluster" target="_blank">http://www.theserverside.com/news/1363588/Scalability-and-Performance-of-jBPM-Workflow-Engine-in-a-JBoss-Cluster</a><br>
<br>
-Alejandro<br>
<br>
El vie, 28-05-2010 a las 12:01 +0200, Eric D. Schabell escribió:<br>
<div><div></div><div class="h5">> Brad,<br>
><br>
> I am so glad you did this, make the list I was putting together based<br>
> on my experiences obsolete (almost).<br>
><br>
> One thing I know that several customers have asked about in regards to<br>
> current projects running on our supported versions of jBPM is to have<br>
> real parallel execution. So when they use a fork / join they want it<br>
> to truly use separate threads, which is not happening now. I believe<br>
> the current versions are running single thread with sub-flows and<br>
> forks just executing serially.<br>
><br>
> Also would be nice to drop the existing and simple JobExecutor queuing<br>
> mechanism and REQUIRE a real JMS queue. I see lots of customers trying<br>
> to scale out the default implementation and I see no reason to provide<br>
> a simple queue solution or maintain it if it is not usable in real<br>
> enterprise solutions.<br>
><br>
> For the rest I have been very busy with travel around my region, my<br>
> next post will be to comment on the rest of the roadmap.<br>
><br>
> Kind regards, erics<br>
><br>
><br>
><br>
> On Thu, May 27, 2010 at 4:33 PM, Brad Davis <<a href="mailto:brad.davis@amentra.com">brad.davis@amentra.com</a>> wrote:<br>
> > Here are features that I have seen a need for in jBPM while using it at our<br>
> > various Red Hat clients. These comments are based on the currently<br>
> > supported 3.2 branch.<br>
> ><br>
> ><br>
> ><br>
> > 1) The ability to create Typed Actions which can be plugged into the<br>
> > Eclipse UI [similar to Drools Flow]<br>
> ><br>
> > 2) Truly plug-able Identity Management backing to JAAS.<br>
> ><br>
> > 3) Email Notification should instead be a general notification<br>
> > framework.<br>
> ><br>
> > a. Oracle BPEL supports this functionality – See:<br>
> > <a href="http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.htm" target="_blank">http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.htm</a><br>
> ><br>
> > b. Notifications should be sent to secondary service via JMS to ensure<br>
> > that no notifications are sent until the Transaction completes successfully.<br>
> ><br>
> > c. Out of the Box Email Notification Support for HTML Email and<br>
> > multiple SMTP servers [similar to what was created for jBPM 4]<br>
> ><br>
> > 4) Reporting; this has been suggested in jBPM 5 blogs.<br>
> ><br>
> > a. Contact me for specifics; we can questionnaire our clients.<br>
> ><br>
> > 5) Service layer to more easily create custom UI for processes.<br>
> ><br>
> > 6) More Complex Form Generation for Tasks via XForms?!<br>
> ><br>
> > 7) Better Audit Logging configuration OOTB.<br>
> ><br>
> > a. Ability to offload this from the main database to a secondary store<br>
> > [like warehouse].<br>
> ><br>
> > 8) OOTB use of JBoss Cache.<br>
> ><br>
> > 9) Cluster-ready timer executions.<br>
> ><br>
> > 10) Keep Decision Handler plug-ability.<br>
> ><br>
> > a. Provide OOTB Drools support.<br>
> ><br>
> > b. Reuse existing BRMS tooling and provide jBPM Eclipse integration<br>
> > with BRMS?! for Drools Decisions via Wizard.<br>
> ><br>
> > 11) Bring Maven Support in-house from the current Codehaus offering<br>
> > [<a href="http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html" target="_blank">http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html</a>]<br>
> ><br>
> > 12) Support Process Upgrades OOTB.<br>
> ><br>
> > a. If a new Process Definition is added because the previous one is<br>
> > flawed, give users the ability to bring existing processes to the current<br>
> > version from the jBPM console.<br>
> ><br>
> ><br>
> ><br>
> > From my experience, no one in the field has asked me for support to edit<br>
> > workflows in the browser. If I were scheduling features, I would put this<br>
> > last. It increases the development effort for the product with little<br>
> > payoff. Our true competitors should be seen as Microsoft Biztalk and Oracle<br>
> > ESB/BPEL, not Activiti. There are so many more features we could spend our<br>
> > time on than in-browser workflow manipulation.<br>
> ><br>
> ><br>
> ><br>
> > Additionally, I fundamentally believe that all our SOA initiative should<br>
> > start and end in workflow. The integration in SOA-P currently for jBPM and<br>
> > back is not ideal. To create a Service, it should be as simple as<br>
> > configuring an input type and output type in jBPM, configure if the process<br>
> > should be request/response or async, and registering within the jBPM<br>
> > workflow the appropriate ESB gateways. So, my suggestion is to pull the<br>
> > gateway concept into jBPM directly. This has worked well for both Oracle<br>
> > BPEL and Biztalk.<br>
> ><br>
> > _______________________________________________<br>
> > jbpm-dev mailing list<br>
> > <a href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
> ><br>
> ><br>
><br>
> _______________________________________________<br>
> jbpm-dev mailing list<br>
> <a href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
<br>
<br>
_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> - CTO @ <a href="http://www.plugtree.com">http://www.plugtree.com</a> <br> - MyJourney @ <a href="http://salaboy.wordpress.com">http://salaboy.wordpress.com</a><br>
- Co-Founder @ <a href="http://www.jbug.com.ar">http://www.jbug.com.ar</a><br> <br> - Salatino "Salaboy" Mauricio -<br>