Here are features that I have seen a need for in jBPM while using it at

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

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:

b.      Notifications should be sent to secondary service via JMS to

that no notifications are sent until the Transaction completes

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

[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

flawed, give users the ability to bring existing processes to the

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

last.  It increases the development effort for the product with little payoff.  Our true competitors should be seen as Microsoft Biztalk and

ESB/BPEL, not Activiti.  There are so many more features we could spend

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

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

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

BPEL and Biztalk. _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Eric, if you really want parallel execution, you can set async="true" on all nodes following a fork. As for JMS, there are already two options, the MDB solution in the "enterprise" module or the JCA inflow alternative shipped in the ESB. FWIW, the default job executor *can* scale. http://www.theserverside.com/news/1363588/Scalability-and-Performance-of-... -Alejandro El vie, 28-05-2010 a las 12:01 +0200, Eric D. Schabell escribió: > 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(a)amentra.com&gt; 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jbpm-dev > > > > > > _______________________________________________ > jbpm-dev mailing list > jbpm-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbpm-dev _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

I also have been thinking about a Adapter architecture. An Adapter would facilitate communication between the workflow and other components. Adapters in the Oracle BPEL environment are basically Wizards which allow the configuring of different Gateways [using the SOA-P term]. http://technology.amis.nl/blog/504/publishing-plsql-services-as-webservic... As you can see this the article above, Oracle offers: File, FTP, AQ, Database, JMS and Oracle Application Adapters. I believe having File, Database, JMS, FTP, and Web Services adapters would move the product forward. Each Adapter would have a Wizard which plugs into the Eclipse jBPM Toolset. The Wizard would walk the user through configuring the Adapter. I believe JBoss has the related technologies that could come together for great adapters. As an example: In Oracle BPEL, they achieve very sophisticated SQL Adapters to Oracle databases. It can be used to interact with a datasource and provides CRUD operations. In the background, Oracle uses the Wizard on the Workflow UI to generate Toplink code; this is transparent to the experience for the workflow developers, who never has to work with Toplink. At JBoss, we have a very advanced Hibernate Tools set in Eclipse which could work as a backbone for an experience similar to the Oracle Toplink Adapter; after the Wizard has completed, the user could interact with the Adapter in Object form. For a Web Service Adapter, we could take advantage of JAX-WS to generate the client code in the background. If jBPM is targeting new features for jBPM 5, it would be great to include a plugable Eclipse Wizard (Adapter) feature into the jBPM Workflow UI. That way, if users or 3rd parties want to add adapters to the jBPM Eclipse Tooling, we support it. We could start by offering the simplest adapters to write: FTP, File, JMS. As the product matures, we could offer the more advanced adapters like the Database [Hibernate] adapter, and Web Service [JAX-WS], noted above. Brad _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev

Audit Logging ============== I think we could just pass all Audit Logs into a queue. However people want to process from that Topic is their business ;) We are doing this at one client with a large throughput. The benefit is that their secondary system which processes from the Queue can be responsible for the CPU needed to persist and also display [through a custom UI] the audit logs. OOTB, we could offer a listener to the Topic which can persist to the DB. Another which may listen to the topic could be responsible for analytics such as throughput. As the system scales, since these listeners would be standalone, people could move them off the default instance for performance sake.

Web Editor =============== I think by providing an advanced, rich Eclipse development environment, we will come out ahead for sure. Sure, it might look nice for presentations; but the minute there is a product bakeoff at a large customer, I imagine that will not stand up. That said, a lot of our customers do ask if Workflows can be imported from Visio -- which the Business users generally are using. Maybe they are targeting it for this purpose. Regardless, developers always will have to get involved. Also, I have never seen this as a deal-breaker when it comes to a company adopting the technology = low on the feature list in my opinion.