4:30 p.m.
JPDL Changes:
+90% of the conversion of JPDL would be acceptable for me. In fact I think
it will be higher. The number of users that use really complex stuff is
limited. The number of users that accidentally abuse some functionality
because it was never intended that way but works might be higher.
API changes:
They are no problem for me since we've isolated those in PAO (Process Access
Objects) where the real jbpm api is used in a limited number of places (like
it is hidden when you use seam). Not sure about other users though, I just
hope they follow best practices as well.
Application/process retesting
Not a real problem for two reasons.
- I would introduce jBPM 4 in combination of a major release of the
application so it needs full testing anyway.
- I encourage TDD for the processes as well, so the behaviour of jBPM 4
could be tested before the full application is tested and errors caused by
upgrading jBPM could be tackled first.
DB change:
That is the area where I have the least knowledge about and like to keep it
that way. Way to many other technologies that I have to keep track of. But I
do have some additional remarks. My argument about the direct access to the
database via jBPM was not because of schema changes, but because of the
initial proposal (because of disgust ;-)) to remove this. That I think is
unacceptable. People who have written queries directly to the database are
mostly aware of the risk and are knowledgable about creating the queries.
They should have encapsulated those as well and so I think we have the
'liberty' to change the schema since they will be able to adapt fairly
easily. They will start asking questions like: what will happen with the DB
for 4.1 (easy answer: nothing that requires you to change again) or 5 (no
idea, Tom?) or ....
I think Thomas is right stating that deployment to 3 or 4 could be decided
in the new api and be based on the schema. Cannot remember this argument
came up in Antwerp btw. It would require code changes for the client since
they have to start using 'the' api.
Regarding Thomas additional statement:
> Also mixing the libraries will be a very hard or impossible.
Also not true. Project libraries should have distinct maven artefact ids.
The container integration layer takes care of transitive dependencies that
are
available to all BPM engines.
For normal webapps this might be true by using classloader scoping. I've
never used JBoss ESB extensively, so not sure if something similar is
possible (also not remeber this remark from Antwerp, but better late than
never)
What you (and Thomas) are in fact stating is that if Toms statement
In most deployment environments, I don't think our users will
have an
option to run jBPM 4 in a different DB schema then their own app and jbpm
3.
Can be addressed/solved/documented in some way, co-existence of 3 and 4
prevails.
Just my quick remarks
Ronald
On Wed, Dec 10, 2008 at 3:31 PM, Burr Sutter <bsutter(a)redhat.com> wrote:
I'm curious to see if Joram, Bernd & Ronald agree (even a
little) with my
suggestion that a 90% conversion of DB, JPDL & API and the need to re-test
the end-user application are substantial barriers to the any migration. The
question is how big are those barriers and we have to measure the cost
associated with development of the conversion tools vs the likelihood that a
user will be willing to take on the rest of the effort (the final 10% and
re-test). My guess is that many users will simply not migrate unless they
are using jBPM in a "small way" or have issues causing them great pain in
jBPM 3.
5:07 a.m.
New subject: Migration
Ronald van Kuijk wrote:
JPDL Changes:
+90% of the conversion of JPDL would be acceptable for me. In fact I
think it will be higher. The number of users that use really complex
stuff is limited. The number of users that accidentally abuse some
functionality because it was never intended that way but works might be
higher.
we can get the percentage as high as we want to. it just takes resources to
introduce the backwards compatibility features that we ripped out because we think
they are invalid. if we really want to, we can go up to 100%. but i think we should
apply the 70-98 rule here: spend 70% of the time to get 98% of coverage :-)
API changes:
They are no problem for me since we've isolated those in PAO (Process
Access Objects) where the real jbpm api is used in a limited number of
places (like it is hidden when you use seam). Not sure about other users
though, I just hope they follow best practices as well.
i never have seen people use it differently then encapsulated. except for our own
jsf console... oooops :-)
Application/process retesting
Not a real problem for two reasons.
- I would introduce jBPM 4 in combination of a major release of the
application so it needs full testing anyway.
+1
- I encourage TDD for the processes as well, so the behaviour of jBPM
4
could be tested before the full application is tested and errors caused
by upgrading jBPM could be tackled first.
+1
DB change:
That is the area where I have the least knowledge about and like to keep
it that way. Way to many other technologies that I have to keep track
of. But I do have some additional remarks. My argument about the direct
access to the database via jBPM was not because of schema changes, but
because of the initial proposal (because of disgust ;-)) to remove this.
That I think is unacceptable. People who have written queries directly
to the database are mostly aware of the risk and are knowledgable about
creating the queries. They should have encapsulated those as well and so
I think we have the 'liberty' to change the schema since they will be
able to adapt fairly easily. They will start asking questions like: what
will happen with the DB for 4.1 (easy answer: nothing that requires you
to change again) or 5 (no idea, Tom?) or ....
+1 those are typically encapsulated and should pose no real obstacle to migrate.
I think Thomas is right stating that deployment to 3 or 4 could be
decided in the new api and be based on the schema. Cannot remember this
argument came up in Antwerp btw. It would require code changes for the
client since they have to start using 'the' api.
deploying to 3 and 4 is possible. but we concluded that this will never happen in
practice.
as new versions of old jbpm 3 processes will always have to be deployed in jbpm 3.
the running instances are mostly very long running (weeks, months, even years).
so users don't have a fade out scenario in this way. even if we offer them the
ability to run side by side. jbpm 3 executions will not fade out.
so the only option that we considered as viable was a single shot migration.
Regarding Thomas additional statement:
>> Also mixing the libraries will be a very hard or impossible.
>Also not true. Project libraries should have distinct maven artefact ids.
> The container integration layer takes care of transitive dependencies
that are available to all BPM engines.
For normal webapps this might be true by using classloader scoping. I've
never used JBoss ESB extensively, so not sure if something similar is
possible (also not remeber this remark from Antwerp, but better late
than never)
What you (and Thomas) are in fact stating is that if Toms statement
> In most deployment environments, I don't think our users will have an
option to run jBPM 4 in a different DB schema then their own app and
jbpm 3.
Can be addressed/solved/documented in some way, co-existence of 3 and 4
prevails.
but we concluded in antwerp that co-existence (which i thought was the best option at
the start of the migration debate), will not solve the problem as indicated above.
regards, tom.
Just my quick remarks
Ronald
On Wed, Dec 10, 2008 at 3:31 PM, Burr Sutter <bsutter(a)redhat.com
<mailto:bsutter@redhat.com>> wrote:
I'm curious to see if Joram, Bernd & Ronald agree (even a little)
with my suggestion that a 90% conversion of DB, JPDL & API and the
need to re-test the end-user application are substantial barriers to
the any migration. The question is how big are those barriers and
we have to measure the cost associated with development of the
conversion tools vs the likelihood that a user will be willing to
take on the rest of the effort (the final 10% and re-test). My
guess is that many users will simply not migrate unless they are
using jBPM in a "small way" or have issues causing them great pain
in jBPM 3.
--
regards, tom.
5830
days inactive
5832
days old
1 comments
2 participants
participants (2)
-
Ronald van Kuijk -
Tom Baeyens