[jbpm-dev] Features and jBPM 5

Bernd Rücker bernd.ruecker at camunda.com
Fri May 28 10:20:43 EDT 2010


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
>
> 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


More information about the jbpm-dev mailing list