[jbpm-dev] Features and jBPM 5

[Kris Verlaenen]

Eric,

Regarding the multi-threading, could you maybe share a use case where 
this would be necessary?  As real multi-threading on the same process 
instance brings a lot of additional complexity (syncing the state).  And 
since a process should never include any processing that is not 
instantaneous (you should use async. work items for that), I don't think 
real multi-threading on the same process instance would make a huge 
difference.  Of course, using multiple thread to execute different 
process instances will definitely give you a performance gain and we do 
want to allow that.

Kris

Eric D. Schabell wrote:
> 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.htm
>>
>> 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
>