[jbpm-dev] Features and jBPM 5

Fri May 28 10:32:18 EDT 2010

I agree about the JMS Job Executor,
I don't agree with the true parallel execution, I think it's just a
conceptual change, and if you really need parallel executions, you can
implement a Work Item that do that for you.
Including multi threaded execution at business process level seems to be
very technical for a high level view of a business situation/use case.

Cheers

On Fri, May 28, 2010 at 10:20 AM, Bernd Rücker <bernd.ruecker at camunda.com>wrote:

> Hi Eric.
>
> Quick remark on JMS: We made the experience in big clustered environments,
> that the JobExecutor (okay, we pimped it :-)) scales even better than JMS.
> Because Jboss Messaging, clustering and huge amounts of messages aren't
> best friends (okay, maybe that gets better with HornetQ)...
>
> Agreed on a lot of issues from Brad.
>
> Cheers
> Bernd
>
> -----Ursprüngliche Nachricht-----
> Von: jbpm-dev-bounces at lists.jboss.org
> [mailto:jbpm-dev-bounces at lists.jboss.org] Im Auftrag von Eric D. Schabell
> Gesendet: Freitag, 28. Mai 2010 12:02
> An: Brad Davis
> Cc: jbpm-dev at lists.jboss.org
> Betreff: Re: [jbpm-dev] Features and jBPM 5
>
> Brad,
>
> I am so glad you did this, make the list I was putting together based
> on my experiences obsolete (almost).
>
> One thing I know that several customers have asked about in regards to
> current projects running on our supported versions of jBPM is to have
> real parallel execution. So when they use a fork / join they want it
> to truly use separate threads, which is not happening now. I believe
> the current versions are running single thread with sub-flows and
> forks just executing serially.
>
> Also would be nice to drop the existing and simple JobExecutor queuing
> mechanism and REQUIRE a real JMS queue. I see lots of customers trying
> to scale out the default implementation and I see no reason to provide
> a simple queue solution or maintain it if it is not usable in real
> enterprise solutions.
>
> For the rest I have been very busy with travel around my region, my
> next post will be to comment on the rest of the roadmap.
>
> Kind regards, erics
>
>
>
> On Thu, May 27, 2010 at 4:33 PM, Brad Davis <brad.davis at amentra.com>
> wrote:
> > Here are features that I have seen a need for in jBPM while using it at
> our
> > various Red Hat clients.  These comments are based on the currently
> > supported 3.2 branch.
> >
> >
> >
> > 1)      The ability to create Typed Actions which can be plugged into
> the
> > Eclipse UI [similar to Drools Flow]
> >
> > 2)      Truly plug-able Identity Management backing to JAAS.
> >
> > 3)      Email Notification should instead be a general notification
> > framework.
> >
> > a.       Oracle BPEL supports this functionality – See:
> >
> http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.h
> tm<http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.h%0Atm>
> >
> > b.      Notifications should be sent to secondary service via JMS to
> ensure
> > that no notifications are sent until the Transaction completes
> successfully.
> >
> > c.       Out of the Box Email Notification Support for HTML Email and
> > multiple SMTP servers [similar to what was created for jBPM 4]
> >
> > 4)      Reporting; this has been suggested in jBPM 5 blogs.
> >
> > a.       Contact me for specifics; we can questionnaire our clients.
> >
> > 5)      Service layer to more easily create custom UI for processes.
> >
> > 6)      More Complex Form Generation for Tasks via XForms?!
> >
> > 7)      Better Audit Logging configuration OOTB.
> >
> > a.       Ability to offload this from the main database to a secondary
> store
> > [like warehouse].
> >
> > 8)      OOTB use of JBoss Cache.
> >
> > 9)      Cluster-ready timer executions.
> >
> > 10)   Keep Decision Handler plug-ability.
> >
> > a.       Provide OOTB Drools support.
> >
> > b.      Reuse existing BRMS tooling and provide jBPM Eclipse integration
> > with BRMS?! for Drools Decisions via Wizard.
> >
> > 11)   Bring Maven Support in-house from the current Codehaus offering
> > [http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html]
> >
> > 12)   Support Process Upgrades OOTB.
> >
> > a.       If a new Process Definition is added because the previous one
> is
> > flawed, give users the ability to bring existing processes to the
> current
> > version from the jBPM console.
> >
> >
> >
> > From my experience, no one in the field has asked me for support to edit
> > workflows in the browser.  If I were scheduling features, I would put
> this
> > last.  It increases the development effort for the product with little
> > payoff.  Our true competitors should be seen as Microsoft Biztalk and
> Oracle
> > ESB/BPEL, not Activiti.  There are so many more features we could spend
> our
> > time on than in-browser workflow manipulation.
> >
> >
> >
> > Additionally, I fundamentally believe that all our SOA initiative should
> > start and end in workflow.  The integration in SOA-P currently for jBPM
> and
> > back is not ideal.   To create a Service, it should be as simple as
> > configuring an input type and output type in jBPM, configure if the
> process
> > should be request/response or async, and registering within the jBPM
> > workflow the appropriate ESB gateways.  So, my suggestion is to pull the
> > gateway concept into jBPM directly.  This has worked well for both
> Oracle
> > BPEL and Biztalk.
> >
> > _______________________________________________
> > jbpm-dev mailing list
> > jbpm-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbpm-dev
> >
> >
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at 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.jbug.com.ar

- Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20100528/45f23806/attachment-0001.html 