Hello, I also agree that automagic migration is at least very difficult to implement, so it's not an option. My suggestion is just to add a simple save/load instance for each version of a process, including load instance validation. No magic at all. When somebody wants to do a migration, he takes older version's instance, saves it, deletes and loads in newer process' version. It may result in an error if something goes wrong. When it happens, this person can manually correct it and try to load again. This technique raises also a requirement that serialized xml should be human readable and human modificable (not just a bunch of %$&*s), but this is possible to achieve.
Why this whole issue is important? If you talk about an architecture of software to be delivered, you get a question: how will you support your long running instances without loosing them? The answer for current ODE is no way and this is bad. In my opinion the above quite simple solution resolves this problem well. You move a migration procedure to a technical person. The other option I thought of is to replay all message exchanges for process instance in a new version of the process to get into similar state. But this quite bad solution, because: -it may take longer time -it may be not so easy to implement (eg. timers replaying) and also unexpected behaviour may happen (eg. when you replay some xpath functions, like current-time) -some others. So I wouldn't get into it. Regards, Rafal Rusin 2009/1/20 Tammo van Lessen <[email protected]>: > 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 >>> >>> >>> >> > >
