All that can be said about this is that jBPM5 is slated to be productized into a JBoss SOA-P product version later this year. There is nothing that can be said about which version of JBoss ESB will be used in that yet.
As far as the community JBoss ESB project, I would suggest asking that integration question there.
We're planning to improve our out-of-the-box integration with web service as part of jBPM 5.1. Integration with JBoss ESB is similar to how you integrate with any external service, using domain-specific work items. There is a work item handler that allows you to invoke a service on JBoss ESB already.
Which version of JBoss ESB will include jBPM5 as a service for web service orchestration hasn't been decided yet.
I think this must be a crucial issue for jbpm because next version of a soa platform must include jbpm5. It's not real to go on working with jbpm3 in soa jboss projects.
So IMHO jbpm5 must provide a handler to call a esb service in a synchronous way and in an asynchronous way (service orchestration)
From esb side, jboss esb must be able to start,stop,signal a jbpm5 process
jbpm5 in a soa fashion must provide a taklist web application that can be easily customized for customer needs (for example provide a maven profile to build a tasklist webapp with the logo of company and with specific css)
I'm working and trying to help with Mule ESB integration withjBPM5 and Drools. The sync and async calls will be handled by thisintegration.
About the tasks list I'm not totally agree withthat. If you provide a web application, you need to choose atechnology. Let's say that we choose GWT, each company will be tied tothis technology, and they will need to have qualified people to adaptit to their company. if the company has all their solutions in struts2,that company can't adopt the generic task lists.
This is a complicate topic, but I'm sure that we can reach a good conclusion if we expose and share different point of views.
Right now the project expose very concrete APIs to build this task lists front ends without being restricted to any technology.
Mauricio it's good that will be provided an integration with Mule but what about JBoss ESB?
IMHO the future of jbpm5 must be inside a soa platform and the next one must be integrated with jbpm5.
So I think it should be considered primary to integrate jboss esb and jbpm than jbpm and mule.
About the task list; working with customers during these years I always faced the problem to build a web application for task list; basically the jbpm task list can be good but the customers wants for example remove red hat logos or use its own css.
So I don't ask too much :-)
Hi there, I'm doing the Mule integration as a community contribution, I don't even know the state of jboss esb, what are the supported versions and what about future roadmap for that product. Once I have a little bit of visibility about those topics I can work on JBoss integration as well.
There is no problem about that.
About the task lists, as you mention there are some clients that only need to remove the company logo, and there are some clients that wants to improve everything there for real usage. I personally think that for real, big applications you need to create something from the scratch where you have control about the performance, the mechanisms used to interact with the server, etc.
If you want to change the logo and the css for current tools, I think that you can do it right now, it's only to replace an image and the css files.. But we can improve that mechanisms as well. Feel free to create a jira issue for those topics.
regarding the task list app I agree with you that the most important issue is to provide an API to easily interact with task; that's a issue fully covered by jbpm...
anyway it happens that you want only customize the default web app only to adapt to customer templates (you don't want to modify its behaviour); why you need to modify the web app source code only for some layout configurations?
I think that you are using jBPM to just represent new business processes, or business processes that doesn't integrate already developed applications. In such situations, you want to change almost everything in the task lists interfaces, for example:
- To show extra information about the domain objects from old applications
- To change the way that the task list filter and show the important information
- To extend the way that each activity task form shows specific information and the communication with external applications to be able to query or get external information.
These kind of features really complicate the integration. You can imagine if all the other (old) applications are not developed using GWT, it becomes a nightmare.
As far as I understand, you want to have a simple interface, like the one provided now, but with some extra configurations to do minimal changes in the layout, the css and the logo right? We can work on that if you want.
I'm fairly sure -- on the basis of what I've heard -- that jBPM 5 will be integrated with Switchyard, which is basically the new jBoss ESB.
See http://www.jboss.org/switchyard for more info!
(In fact, they've already started (and done lots) on jBPM integration: https://github.com/jboss-switchyard/components/tree/master/bpm )
As for the "old" or "current" version of jBoss ESB, I think it's a better idea to look at Switchyard if you don't already have jBoss ESB setup.