-
1. Re: Classloader-Registry in AS/ESB allows one central jbpm i
kukeltje Sep 30, 2008 4:48 AM (in response to camunda)So I think I do a crossposting in the ESB forum (Sorry Ronald ;-)).
I'm not subscribed to the esb forum, so I do not mind :-P
Regarding your proposal, You mention something about not deploying classes to the database but to a classpath. Are you thinking about some other way of versioning then or ditch it at all? -
2. Re: Classloader-Registry in AS/ESB allows one central jbpm i
kukeltje Sep 30, 2008 6:25 AM (in response to camunda)Sorry, to short a statement.... some additions
It is not the just the versioning of processdefinitions but screens (or even pageflows) for tasks (which in the current solution is only viable to be used in demo situations)
It is a more generic problem than just jBPM. So maybe we could come up with something together with the seam guys which are more knowledgable about the frontend. -
3. Re: Classloader-Registry in AS/ESB allows one central jbpm i
camunda Sep 30, 2008 12:21 PM (in response to camunda)In our current project we have the following concept for versioning (sorry for not posting that the first place):
Versioning is applied to applications and services, normally correspond to one EAR (with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service). There are two versioning schemes:
1.) Major Versions: Bigger changes. These may be not compatible. New major versions may be run in parallel to older services.
2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New Minor versions replace the existing service.
The EAR includes the version in its name, so all beans and stuff include the version in the JNDI-Name. jBPM-processes are included in this EAR. New major versions will create new processdefinition names (basically the version is added to the process name, e.g. "websale_3"). "Normal" jbpm versioning is only applied on patch level.It is a more generic problem than just jBPM.
Exactly, normally you have to take care of versioning for a lot of artefacts, so I think this solution makes sense... And I like having bytecode and classpath stuff in EAR files more than in the jBPM database...So maybe we could come up with something together with the seam guys
Yeah, maybe. But I think it is not only seam, but much more. Especially if you look into the direction of the ESB with whatever services connected to it. This direction (to the backend) is also very interessting. -
4. Re: Classloader-Registry in AS/ESB allows one central jbpm i
kukeltje Oct 1, 2008 5:07 AM (in response to camunda)"camunda" wrote:
Versioning is applied to applications and services, normally correspond to one EAR (with Java classes, maybe web pages, wsdl, whatever. Depends on the kind of service). There are two versioning schemes:
1.) Major Versions: Bigger changes. These may be not compatible. New major versions may be run in parallel to older services.
2.) Minor versions = patches. These are patches, bug fixes or compatible changes. New Minor versions replace the existing service.
Ok, clear. Would be my take to."camunda" wrote:
The EAR includes the version in its name, so all beans and stuff include the version in the JNDI-Name.
You do this manually (deploy time), manually (design time) or is this some automagic JBoss AS feature?"camunda" wrote:
jBPM-processes are included in this EAR. New major versions will create new processdefinition names (basically the version is added to the process name, e.g. "websale_3").
Again, do you do this deploy time or designtime?"camunda" wrote:
"Normal" jbpm versioning is only applied on patch level.
Ok, makes me even more curious how you achieve this. The high-level take on it is clear, now the devil^W details ;-)"camunda" wrote:
It is a more generic problem than just jBPM.
Exactly, normally you have to take care of versioning for a lot of artefacts, so I think this solution makes sense... And I like having bytecode and classpath stuff in EAR files more than in the jBPM database...
It does make sense, I miss one thing though but I'll talk about that in the end."camunda" wrote:
So maybe we could come up with something together with the seam guys
Yeah, maybe. But I think it is not only seam, but much more. Especially if you look into the direction of the ESB with whatever services connected to it. This direction (to the backend) is also very interessting.
You are right, but currently I am (was) focussing on the web side of things.
How do you run multiple major versions next to eachother? Suppose I have App A-v1 (version 1) on http://myhost/AppA. That is easy to run. But now comes AppA-v2, an incompatible major release. Running this on http://myhost/AppA. is not possible since we already have AppA-v1 there, so something more advanced needs to take place.
One thing I came upo with (and I do not know all the disadvantages yet, or alternatives, so please shoot) is to have an AppA 'wrapper' which contains things like showing tasklist (since our customers do not want to use to different 'apps' because there are newer versions), basic navigation etc which is a war by itself running on url http://myhost/AppA. The 'versioned' parts are in separate deployable artifacts (war or ear) running on urls like http://myhost/AppA-v1 or http://myhost/AppA-v2 of which the wrapper has knowledge via some defined schema so it can make a link directly to a task. But there probably needs to be some kind of 'TaskHandlingPageUrlService' to retrieve that.
I'll not go into it any further now and just let you guys shoot... But I do think there needs to be some more generic mechanism for all this Gourvernance stuff... -
5. Re: Classloader-Registry in AS/ESB allows one central jbpm i
camunda Oct 16, 2008 9:45 AM (in response to camunda)I described the solution which works for our current project now in a bit more details:
http://www.camunda.com/knowledge/jbpm_deployer_for_enterprise_environment.html
[quote from ESB forum]
The current codebase appears to be based on the premise that each jBPM instance is standalone and co-located with the code running within the system
I agree! We got rid of it with the described solution and something similar should find its way into the SOA platform I think...
But seems to be the first task to define which project is responsible for this type of functionality (jBPM? ESB? ..?)...How do you run multiple major versions next to eachother?
-
6. Re: Classloader-Registry in AS/ESB allows one central jbpm i
camunda Oct 16, 2008 9:46 AM (in response to camunda)Forum swallowed the rest, here it is:
I think this is really out of scope of jBPM itself. The question for jBPM to solve is how to support what the people want to do in terms of classloading and how to align jbpm versioning (or life cycle) with the app/esb versioning...
Cheers
Bernd -
7. Re: Classloader-Registry in AS/ESB allows one central jbpm i
camunda Nov 14, 2008 5:22 AM (in response to camunda)I have created a JIRA issue on the SOA platform for this and posted my current code in our blog:
https://jira.jboss.org/jira/browse/SOA-1008
http://www.bpm-guide.de/2008/10/16/jbpm-deployer-for-jbpm-in-enterprise-environments/
http://www.bpm-guide.de/2008/11/14/jbpm-deployer-status-and-sourcecode/ -
8. Re: Classloader-Registry in AS/ESB allows one central jbpm i
thomas.diesler Nov 21, 2008 6:03 AM (in response to camunda)Hi Bernd,
this
http://www.camunda.com/content/jbpm/esb/jbpm-esb-classloading.pdf
is not acceible any more -
9. Re: Classloader-Registry in AS/ESB allows one central jbpm i
camunda Nov 21, 2008 6:05 AM (in response to camunda)You are right, this was just a first shot. But the information was moved into this blog entry: http://www.bpm-guide.de/2008/10/16/jbpm-deployer-for-jbpm-in-enterprise-environments/
-
10. Re: Classloader-Registry in AS/ESB allows one central jbpm i
thomas.diesler Nov 21, 2008 7:35 AM (in response to camunda)merci (f)