3:23 a.m.
I don't get this:
the underlying DB should IMO be considered an implementation detail
of
the iBPM engine. If that is not the case in jBPM3 it needs to get fixed
in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say
there is no DB migration needed.
The whole state of my processes is in the database. Of course no direct
access should be exposed, but the existing process data may have to be
migrated, no stable API helps me out here. And therefore I need DB
migration...
Maybe we can discuss If I need to migrate existing process instances (I
would tend to say yes), but I don't get your reasoning. Maybe you can
explain that for me again, that I get what you mean....
The migration from jPDL3 to jPDL4 should be possible with
tool support.
But one function of this tool would be DB migration (beside the jPDL XML
conversion of process definitions).
Cheers
Bernd
-----Ursprüngliche Nachricht-----
Von: jbpm-dev-bounces(a)lists.jboss.org
[mailto:jbpm-dev-bounces@lists.jboss.org] Im Auftrag von Thomas Diesler
Gesendet: Donnerstag, 30. Oktober 2008 09:07
An: Tom Baeyens
Cc: Jeff DeLong; Joram Barrez; Burr Sutter; Ronald van Kuijk;
jbpm-dev(a)lists.jboss.org
Betreff: Re: [jbpm-dev] Migration
Hi Folks,
the underlying DB should IMO be considered an implementation detail of
the iBPM engine. If that is not the case in jBPM3 it needs to get fixed
in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say
there is no DB migration needed.
One of the replacement criteria for jBPM3 is that jBPM4 is functionally
equivalent. The migration from jPDL3 to jPDL4 should be possible with
tool support.
On the API mission page there is a section on what is expected to be
stable, what is not.
http://www.jboss.org/community/docs/DOC-12868#What_is_expected_to_be_stabl
e_what_is_not
Hopefully, during our jBPM meeting next week we can iron out some open
questions on migration and come up with a migration article on the wiki.
cheers
-thomas
Tom Baeyens wrote:
Jeff, Burr, Martin,
Afaict, you are the guys closest to our customers. Next week, we'll be
discussing migration between jBPM 3 and 4 in the team. We would
appreciate your input.
If we had unlimited resources, we'ld simply provide DB, process-XML and
API backwards compatibility, but given that our resources are limited
and the improvements numerous, here are my initial thoughts on how we
currently think to handle migration:
Probably DB migration will be too hard to supply in a decent manner. So
we'll probably target that users will be able to use jBPM 3 and
jBPM 4
in parralel. That way they can start deploying new processes to jBPM 4
and let jBPM 3 processes fade out.
For each process in jBPM 3, they could migrate the process to jBPM 4
(see below), redeploy and start new executions in jBPM 4. Although from
the user client code perspective this will be hard or impossible.
We also anticipate that we'll have to supply a process translation tool
that can translate jPDL 3 process XML files to jBPM 4 process XML
files. Most of the process file will be converted. But probably there
will be some things in jBPM 3 that we will not support in the exact same
way in jBPM 4. So some converted processes might not be complete
or
might not execute exactly the same way as in jBPM 3.
API will be different. Only migration docs. The good news is that with
the arrival of jBPM 4, we'll start to ship a more limited API
that is
more decoupled from the engine internals so that it will remain much
more stable from then onwards.
Feedback from our jBPM Community Day in Dublin was very clear: Migration
is one of the biggest concerns for our users.
So here are my questions:
What aspect of migration will be the biggest challenge for our customers
?
Which aspects of migration will be showstoppers for ourcustomers ?
Suppose that we ship the above migration strategy and a really really
really important client wants to migrate his DB really really really
badly. Would we
a) be able to say no.
b) provide him with skeleton code that the client can use as a basis to
write their own DB migration in code.
c) let our consultants work out the DB migration for the first customer
that wants to pay for it and then add it to the jBPM codebase.
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev