[jbpm-dev] Proposal for jBPM5 first release

[Maciej Swiderski]

Just one more comment that just came to my mind - some time ago I got a
question from one of our customer - "is it possible to prioritize process
definitions?"
Motivation for that was that they had 4-5 different process definitions
deployed to same process engine, where two of them were mission critical
processes and the rest just regular ones. Regular processes were ran very
frequently consuming quite some server resources and when one of the mission
critical process wanted to be executed it could jump into a highly loaded
environment with the same priority as any other. That caused them to be
executed with delays that were not acceptable from business point of view.
They would like to have possibility to specify that some of the process
definitions are more important than the other, to be able to ensure that
those mission critical processes will be served quicker and better.

I noticed that jBPM 4.x has already a possibility to set priority but looks
like it is not used afterwards.

/Maciej

2010/5/31 Eric D. Schabell <eric at schabell.org>

> > See comments inlined ...
> >
> > As a general remark, we know we need to start adding much more detail to
> the
> > roadmap to define what needs to be done exactly for each component and
> each
> > release etc. and we're working on that.  So I will keep the comments on a
> > little higher level for now.
> >
> This is the part of the discussion I hope to be included in.
>
> >> Migration
> >> =======
> >> I think you need to take a look at API mapping too. Why not provide
> >> some api call mapping in the tooling where it is possible? I expect I
> >> would be able to provide customer input (code bases) for looking at
> >> real world implementations to start generating a matrix of used calls
> >> for example? Just migration of the jPDL 3/4 -> BPMN2.0 would be rather
> >> weak attempt. If it turns out that a customer uses API calls, no
> >> custom SQL or hibernate tweaking, plays nice in the infrastructure
> >> code they create, then it is conceivable that we could provide simple
> >> instance migration. (Cross your fingers!). I have a personal interest
> >> in this area and if we can go a bit farther in detailing the
> >> components and development that needs to be done in the roadmap, I
> >> will complete my blog articles on jBPM Migration Strategies
> >>
> >> (
> http://www.schabell.org/2010/03/jbpm-migration-strategies-introduction.html
> ).
> >>
> >
> > We are planning to do what we believe is the best way to do this and
> still
> > feasible.
> > But the compatibility between jPDL and BPMN2 has been defined in detail
> yet,
> > so hard to predict exactly.  But documentation on how to migrate APIs
> etc. is
> > definitely part of a migration strategy.
> >
> Excellent, this is pretty important part of migration to even get a
> customer to take it
> seriously. Just jPDL to BPMN2 at process definition level would be too
> simplistic.
>
> >> Conclusions:
> >> =========
> >> Basically I would like to discuss the details within each area to be
> >> developed for the roadmap; what is the break down of components to be
> >> developed, what is existing and/or ready to be leveraged, map this to
> >> the components, planning in milestones for what is to appear and when.
> >> With that kind of roadmap you can then leverage JIRA for the roadmap
> >> creating milestones for all to watch progress and/or help with by
> >> picking up work to be done.
> >>
> >
> > Any suggestions on how we set up something like that? Different thread on
> > the mailing list / forum for each of the components?  Open discussions on
> irc?
> >
> I have setup this several times in my previous work, using just JIRA and my
> dev
> team used the Mylyn plugin to keep a focus on their assigned tasks. This is
> not
> required as the web interface with JIRA works just fine too. It is
> just a matter of
> having a project lead that takes the time to orchestrate the process
> and sort out
> the milestones. I would be more than happy to help, just need to be in on
> the
> planning phases.
>
> The mailinglists and dev lists are fine as is, for discussion the
> problems/progress, etc.
>
> Irc is great for meetings, ad-hoc discussions and poking the developer
> in question! Btw,
> what or which irc are the jBPM developers hanging out on?
>
> Let me know if you need help with this, I can make some room for this
> in my schedule.
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20100531/f1c05beb/attachment.html