[jbpm-dev] Feedback for jBPM5 proposal
Kris Verlaenen
kverlaen at redhat.com
Mon Apr 19 16:09:31 EDT 2010
Sebastian Schneider wrote:
> 1.) Will jBPM 5.0 be based upon jBPM 4.x? You mention the PVM and the
> native BPMN 2.0-implementation. So I assume it will be. Am I right?
>
jBPM 5.0 will be based on a combination of jBPM 4.x and Drools Flow,
like "the best of both worlds". So it will be based on jBPM 4.x and
Drools Flow. We haven't decided yet which bits and pieces exactly will
be used in jBPM5.
> 2.) What's the reason for replacing the task management with WS-Human
> Task?
The number one reason is simple: WS-HT is a standard. And many people
have thought a lot about this problem, and decided that they believe
this is the best solution.
> The task life cycle model?
The task life cycle model and features related to that are much more
advanced, while you can still have a simple task life cycle if you
want. I don't you will lose any functionality here.
> Will this be implemented as a webservice as most of the other vendors do or will you supply a java
> implementation using the same model?
Current plans are to implement it as a java service (if you for example
like close integration with the process engine), but also provide a WS
interface for it.
> 3.) Will JBoss ESB be an optional component? I am thinking of
> embeddability again. Why use an ESB when you don't need one? One of the
> strengths of jBPM IMHO is the small footprint.
>
Yes, while the core engine could be deployed as a service on the ESB,
the ESB will not become a dependency. The footprint of the core engine
itself will be (remain) small.
> 4.) IMHO it's absolutely crucial to fix some really basic issues
> concerning jBPM 4.3 and release 4.4. This is important to not lose the
> community. There's also a great insecurity about jBPM 4.x. To be more
> precise: whether or not you should start a project wiht jBPM 4.3 right
> now. Wide usage by the community is the best test you can get for a
> software product.
>
This request for comments is about jBPM5, because we believe the
features we are presenting here are (sometimes) big steps forwards and
we want to target them in a new major release. I think this is just how
a lot of open-source projects are doing this: at some point you need to
decide whether you just keep adding functionality as a minor enhancement
to the existing version or whether you start focusing on the next
version. We believe that the features we are presenting (like for
example BPMN2 execution) can best be implemented as part of the next
version and not a simple add-on to the current.
This however does not necessarily mean that jBPM 4.x is "finished". We
know there are some issues that need to be dealt with (where some of
them have even been solved in the latest snapshot code already), and
we're also looking into that. Community involvement here is definitely
welcome, so please drop me a message if you want to help out. What it
does mean however, is that, for new features, we are changing our focus
to the next release.
> In general the overall looks nice but there should be priority on the
> core engine since all the other components can still be added later on
> with no problem.
>
Thank you for your feedback, we'll definitely take it into account.
Kris
More information about the jbpm-dev
mailing list