[jbpm-dev] Re: Migration

[Tom Baeyens]

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 at redhat.com 
> <mailto:bsutter at 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.