-
30. Re: Rework of jBPM deployment within JBoss
Thanks for all the input. I think I should hold off on this and make Scott aware of JBPM requirements for versioning. It looks like we can't unify jbpm with JBoss AS deployment until JBoss 5. I know Scott has thought a lot and implemented a bunch around versioning applications, but I'm not sure he is aware of jbpm requirements.
-
31. Re: Rework of jBPM deployment within JBoss
I would also appriciate a single wiki site where all the requirements are collected.
I want to add some comments to various points:
- process versioning: What I like in the current deployment model is the control you have, YOU decide when you deploy and if you include the classes or not. And that should not be somehow automated, at least in production.
- a version attribute in the xml and maybe a attribute if to include classes would be interessting option (much better than hash I think). Waiting for jbpm 3.3 should not be a showstopper for this.
- normally there are many different versions with running processes around. It is quite normal in long running business processes (like Britt said)
- I like the protability of jBPM very much. And I think it is a important advantage that should be kept. Today it runs in standalone, Tomcat, JBoss or other AS environments. Very important in my eyes. So some proprietary JBoss deployment should be always (or at least in the near future) additional. Thats what the people like about jBPM, it is not tied to some AS.
Bernd. -
32. Re: Rework of jBPM deployment within JBoss
Another one:
- Actually a process deployment should normally be possible without a Jboss-Archive-Deployment. This is one additional advantage of business process modelling.
All over all after thinking a bit about it, I think, process deployment, which is to some part a business analyst related problem, should not be completly solved by a technical dpeloyment solution. The Eclipse-Plugin, the webconsole or some other admin gui is the right place for it in my eyes.
Also other business proecess engines take this approach as far as I know. -
33. Re: Rework of jBPM deployment within JBoss
"camunda" wrote:
I like the protability of jBPM very much. And I think it is a important advantage that should be kept. Today it runs in standalone, Tomcat, JBoss or other AS environments. Very important in my eyes. So some proprietary JBoss deployment should be always (or at least in the near future) additional. Thats what the people like about jBPM, it is not tied to some AS.
A couple of things:
* I never talked about removing the current way of jBPM deployment
* Portability is good. BUT...many developers use more than one JEMS project. Wouldn't it be good if deployment was portably consistent between desparate projects? This is why I created the http://wiki.jboss.org/wiki/Wiki.jsp?page=EmbeddedJBoss project.
* I don't think jBPM can continue to live in a black box in terms of versioning. jBPM interacts with web applications and various other subsystems that would also need to be versioned. How do current jBPM users handle this scenario?
Many JBoss.org projects like jBPM have done a great job at being portable to other environments than JBoss AS. Unfortunately, they have not done a great job at taking advantage of the JBoss AS platform and becoming a cohesive suite of projects. Right now, most JBoss.org projects are configured and deployed different and have their own unique, but similar/familiar component models. When you want to use two of these projects together, it becomes painful. Tooling efforts are more difficult. An overall way of tieing these projects together is non-existent. This is what I'm trying to solve. We need to get to a point where 1 + 1 > 2.
The funny thing is, JBoss AS has the opposite problem, it looks like one product, but does a horrible job at running in other environments.
The thing is, I NEED INPUT from users like yourself. I'm trying to figure out the big picutre. How all these projects at JBoss.org can fit together. Learning how you all use these projects alone or together is part of the process. Please help!
Thanks -
34. Re: Rework of jBPM deployment within JBoss
"bill.burke@jboss.com" wrote:
* I don't think jBPM can continue to live in a black box in terms of versioning. jBPM interacts with web applications and various other subsystems that would also need to be versioned. How do current jBPM users handle this scenario?
uhhhhmmmm...... yes... correct... challenge... problem.... and not solvable by the jbpm gui/console."bill.burke@jboss.com" wrote:
Many JBoss.org projects like jBPM have done a great job at being portable to other environments than JBoss AS. Unfortunately, they have not done a great job at taking advantage of the JBoss AS platform and becoming a cohesive suite of projects. Right now, most JBoss.org projects are configured and deployed different and have their own unique, but similar/familiar component models. When you want to use two of these projects together, it becomes painful.
Correct, so your initiative is really appreciated"bill.burke@jboss.com" wrote:
The thing is, I NEED INPUT from users like yourself. I'm trying to figure out the big picutre. How all these projects at JBoss.org can fit together. Learning how you all use these projects alone or together is part of the process. Please help!
I'm currently looking into jboss esb as well... could be that services running there have to be versioned with process versions.... or not... the late/early binding that jbpm has with subprocesses could be a solution... or not.... ..... lots of challenges in this area.... -
35. Re: Rework of jBPM deployment within JBoss
"kukeltje" wrote:
"bill.burke@jboss.com" wrote:
Many JBoss.org projects like jBPM have done a great job at being portable to other environments than JBoss AS. Unfortunately, they have not done a great job at taking advantage of the JBoss AS platform and becoming a cohesive suite of projects. Right now, most JBoss.org projects are configured and deployed different and have their own unique, but similar/familiar component models. When you want to use two of these projects together, it becomes painful.
Correct, so your initiative is really appreciated
Was thinking of integrating Seam bijection/scripting. This might give us some consistency across component/programming models."kukeltje" wrote:
"bill.burke@jboss.com" wrote:
The thing is, I NEED INPUT from users like yourself. I'm trying to figure out the big picutre. How all these projects at JBoss.org can fit together. Learning how you all use these projects alone or together is part of the process. Please help!
I'm currently looking into jboss esb as well... could be that services running there have to be versioned with process versions.... or not... the late/early binding that jbpm has with subprocesses could be a solution... or not.... ..... lots of challenges in this area....
One of the things I talked to Tom about was adding singleton actions/node/handlers that are created per process definition and had lifecycle equivalent to the startup of the process definition. THis could allow us to define start states which are really connector definitions. Not sure this is a good idea or not. I'll start another thread on it.