Hi, All --
I agree that automated migration is probably too difficult to achieve
as a meaningful feature.
I can certainly imagine that wizard-like tools for migrating instances
would be useful, but those would really be the kind of thing that a
combined business/process expert would use -- select which activities
are enabled in the new model (discarding any history), apply
transformations to existing variables, set correlation keys, and then
dehydrate. (Ode's state model makes it possible to work with instance
state outside of the server runtime, but I don't know of anyone who's
done that outside of a lab environment.)
I *do* like the idea of save/load from serialized format (XML or
other) in the management API, since that might give a way to migrate
an instance between, say, a staging environment and a production
environment.
Just my $0.02.
-- Paul
On Jan 20, 2009, at 10:32 AM, Tammo van Lessen wrote:
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
