[jbpm-dev] Features and jBPM 5

[Alejandro Guizar]

The notification framework is a compelling proposal - the ability to
send a message as an email, or alternatively as a fax, SMS, pager or
even a social network, through a regular interface is quite valuable.
This is the kind of feature that differentiates proprietary and open
solutions.

As for offloading audit logs to a separate DB, I don't know what would
be best, relying on the persistence framework capabilities (e.g.
Hibernate Shards) as we have discussed previously, or design with a
secondary DB in mind. The former should be more flexible.

JBoss Cache: this is already going into the platform. This will serve as
an early experience.
https://jira.jboss.org/jira/browse/SOA-1406

Cluster-ready timer executions: noted. The EJB timer service solution
did not make this requirement, but the other two solutions in the
platform did (JCA inflow, Quartz).

I share your opinion on the web designer, the Eclipse/desktop
alternative is richer, more reliable and overall better, with one
exception - the web designer makes for more dramatic presentations. I,
for one, was impressed the first time I saw it. Devs will soon realize
it is more fluff than stuff (at least in its current state), but if it
helps convince the "business analysts", great.

Lastly, your words, "I fundamentally believe that all our SOA initiative
should start and end in workflow", reminded me of an article I read last
year, where the author expresses a similar thought.
http://www.itbusinessedge.com/cm/blogs/byron/talking-with-pierre-fricke-of-red-hat-about-bpm-and-the-stack/?cs=36694

-Alejandro

El jue, 27-05-2010 a las 09:33 -0500, Brad Davis escribió:
> 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