[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss
by tom.baeyens＠jboss.com
"bill.burke(a)jboss.com" wrote : I've been thinking about this a bit the last day. Here's the advantages, IMO, of the new deployer I'm proposing:
|
| * Easier for newbie to get start. One last thing they have to worry about.
| * Easier for development
| * Less configuration
| * Doesn't impair other jBPM deployment options
| * gets in line with how other JEMS projects deploy into JBsos
|
| Disadvantages:
| * Not portable to other application servers. (Until we get JBoss Embedded going).
| * I don't think this will work well with class versioning unless we add metadata to the .par (like a version number)
|
could you summarize your new proposal on a wiki page cause a lot of arguments and aspects have been put forward in this discussion and i lost track of which combination your evaluating
e.g. on http://www.jboss.org/wiki/Wiki.jsp?page=JbpmJBossDeployment
also, it's not a question of pro's and con's for me. i'm all in for a jboss deployment model in addition to the models that we have.
the deployment models might be sanetized later, but to date, we don't have a clear enough view on what people actually need. so we offer everything.
the motivation is that people must be free to work the way *they* want. we shouldn't force them to work in one way or another.
"bill.burke(a)jboss.com" wrote :
| My questsions are:
| * How often is versioning used?
|
It's used quite a bit. Although we recommend for performance reasons to skip versioning of classes and just put them in the classpath.
"bill.burke(a)jboss.com" wrote :
| * How many versions are live at one time? How many versions do applications usually have in play?
|
no clue on the average.
but process instance migration is not a straightforward task. when you deploy a new process definition (either as a new separate definition or as an update of the existing) you'll need to convert the old executions to the new definitions.
if all the nodes are the same, it's easy to convert the tokens to the new process. if you can map old node names to new node names that could be an enhancement too.
but in the general case, you can't translate old process instances to new definitions. even your concurrency model might have changed. in that case it becomes impossible to map the old tokens to new tokens.
on top of that, you need to take the logs into account. in case of a process update, the previous logs might not match the process definition any more.
that is why i only see one way of handling versioning:
when deploying a process that already exists (process equality is based on the name), then a completely new process definition is created. old executions keep running in the old definition, new process instances are started in the new definition.
"bill.burke(a)jboss.com" wrote :
| One last thing:
| * Maybe with this new deployer, versioning should be turned off by default?
| * Should a piece of metadata be added to the deployment to say whether or not it should be versioned or just overwrite the old deployment?
see previous remark about process instance migration. please explain how you want to handle that if you talk about not doing versioning.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052783#4052783
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052783
18 years, 10 months
[Design of JBoss jBPM] - Thinking about transition attrs
by brittm
The process patch thread got me thinking about some things I've been wanting to see in Transition configuration.
1) Is anything in the works to allow a process designer to suggest to the UI that a user be asked to "confirm" a particular transition? For instance, when completing a task, one option might be 'done' while the other option is 'cancel'. If the user selects 'cancel', the process designer may want to suggest that he user be asked to confirm that choice.
Something like <transition name='...' to='...' confirm='true'/>
2) Is anything coming up that would allow the process designer to suggest to the UI that a transition should be restricted to administrative use? For instance, transitions that you would like to be available to application adminsitrators or administrative tools, but not available to the typical user--I might not want a typical user to revisit a node handling integration 20 times in one hour, but I might want an admin to be able to retry it after the problem has been solved--same thing for some types of cancellation.
Something like <transition name='...' to='...' restricted='true'/> or refer to a UI's roll based system with <transition name='...' to='...' role='admin'/>
I know there have be plenty of words put out discussing where certain types of configuration ought to go. Thoughts?
-Britt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052769#4052769
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052769
18 years, 10 months
[Design of JBoss jBPM] - Re: process patch files
by brittm
Tom,
I like that suggestion. Already we've found ourselves in a predicament in which a transition was omitted from a process, only to find out weeks later that users were wondering how to do something from where they were in the process (or we where wondering how we could retry a failed integration step after it had moved into a "manual" state, that we never thought would need to be retried).
The only thing we could reasonably do was to re-point an available transition to the desired node, signal the problem processes while there was little chance of normal users being on the system, then re-point the existing transition back to its original destination.
What you're proposing would give us the ability to properly insert the needed transition into the running process without cheating (like we did) or figuring out a bunch of API calls--As it is, we've already built into our own "Admin" UI the abilities to upload updated resource files (like action handlers and such) and to re-direct transitions. Maybe its good to be wary of giving this ability to the business analyst, but it sure is useful in the development department.
Of the two proposals, I think the merge idea is a little more dangerous as it increases the likelyhood of introducing unintended changes.
-Britt
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052758#4052758
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052758
18 years, 10 months