[Design of JBoss jBPM] - Re: Classloader-Registry in AS/ESB allows one central jbpm i
by kukeltje
"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 :
| anonymous 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 :
|
| anonymous 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...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179718#4179718
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179718
16 years, 1 month
- 1
- 0