Hi, I absolutely agree. I was just feeding from a researchers point of view. >From the BPEL engine implementer's point of view I strongly believe that instance migration should not be an immediate task of a workflow engine. It should however be capable of supporting multiple versions of a process model (with a gentle migration phase, i.e. running process instance are completed following the old model while new instances are created according to the new model), like ODE does.
If there were tools which help developers to identify [1] and create a meaningful diff between BPEL process models we could think about mechanisms to apply such a patch to migrate the process status. But this is IMO right after "incorporate alien technology" on the our roadmap. Best, Tammo [1] http://dbis.eprints.uni-ulm.de/335/1/DKE_WRR08.pdf Andres P. Ferrando wrote: > I think that automatic Process migration isn't something useful to > achieve. All process definitions have a background process that covers a > business need, and that cannot be expressed there. So, even when in the > new definition there exists the same activity unmodified, you can't be > sure that the best option is to kept instances in this step. > So, IMO perhaps a better option could be to have some tool that helps in > migration tasks, allowing to define source and targets activities for > process instances. But I repeat: that helps a person that understands > the business to do it, and not that tries to do it by itself. It could > automatically do a suggestion, but no more than this. > > Regards, > > Tammo van Lessen wrote: >> Hi, >> >> Matthieu Riou wrote: >>> On Sun, Jan 18, 2009 at 1:37 PM, Rafal Rusin <[email protected]> >>> wrote: >>> >>>> Hello, >>>> >>>> recently I added feature request: >>>> https://issues.apache.org/jira/browse/ODE-483 >>>> >>>> It's about adding save/load process instances to/from XML in management >>>> API. >>>> I'd like to hear from you, what's the best solution from your (user's) >>>> perspective. >>>> >>> This is a pretty hard problem. Saving and reloading the instance >>> state is >>> the easy part, migrating it to a new definition is where it gets hairy. >>> Generally speaking, automagically migrating any process definition to >>> a any >>> new one is impossible, too many cases are undecidable. So whichever tool >>> gets used to do that migration will need human input to know what to >>> do in >>> all but simple cases (which might already be interesting). The >>> question then >>> becomes how to describe a transformation from one process definition to >>> another. With a relational database you would use SQL to alter the >>> schema >>> and update data. There's no equivalent for processes. >>> >>> I'm not aware of much literature directly in that field although >>> Tammo may >>> be able to point you to some papers. >> >> Instance migration is definitely a non-trivial problem, though very >> interesting. The guys in Ulm have done a lot of research in this field >> [1], I think it is a good starting point (also to find related work). >> >> Best, >> Tammo >> >> [1]http://www.uni-ulm.de/en/in/institute-of-databases-and-information-systems/research/projects/adept2.html >> >> >> >
