[jbpm-dev] Re: Migration

[Tom Baeyens]

These are the ideas that we came up with in the jBPM team meeting:

 > B- Side-by-Side - execute concurrently in same AS/ESB container

A big drawback that we identified was that users would not be able to deploy new 
versions of existing processes to the new jBPM instance.  Cause in that case, our 
users (or we) would have to write code to determine on which jbpm instance, the 
execution is running.  That is so impractical that we believe this is a showstopper.

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.  Also mixing the 
libraries will be a very hard or impossible.

 > C- New Engine, New Projects - start new projects on the new engine

This would mean completely different SOA-P installations ?  I don't think that would 
be feasible for our users.

 > A- Migrate - tools & documents

We came to the conclusion that migration was the only viable option that we had left. 
  On top of that, users can be expected to migrate code and do significant conversion 
work when they do a major version upgrade.

If they are not able to do this migration, they still have the option of sticking 
with jbpm 3 for a couple of years longer.

For the API, things will change.  jBPM 4 will be the version where we introduce a 
new, more limited API that will be easier to keep stable.

For the jPDL XML, we think its feasible to provide the migration tools that will 
cover +90% of the jPDL XML, document which features are not supported and provide 
pointers on how users should proceed with those non automated parts of the jPDL XML 
migration.

For the DB just the same.  We think it is feasible to supply a serialization to file 
of the DB contents and then load it back into the new DB.  Again, this will not be 
100% but we must be able to indicate how our users should proceed for the features 
that are not automatically supported.

jBPM 4 has a lot of improvements/changes, but the structure of the XML and the DB is 
still similar.  That is why we believe that migration is a viable route.

regards, tom.



Burr Sutter wrote:
> I was traveling when this thread started and just now getting back to 
> it.    One thing to keep in mind is that the ESB embeds jBPM for its 
> service orchestration capabilities.  We have to consider that use case 
> otherwise it might take many months/years to migrate SOA Platform 
> codebase & userbase from jBPM 3 to 4.  That will delay the official 
> support date of jBPM 4.
> 
> There are 3 options that I can see:
> A- Migrate - tools & documents
> B- Side-by-Side - execute concurrently in same AS/ESB container
> C- New Engine, New Projects - start new projects on the new engine
> 
> A - Migrate Negatives
> - Very expensive to build all the tools & document all the elements
> - Requires a complete re-testing of the customer's end-user 
> applications, a process that could take years in larger customers
> - Automated tools are likely to be error prone and will not address 100% 
> of the customers solution, for instance, their custom reports (SQL 
> scripts) won't be automatically migrated and will need to be re-written.
> - Large customers will take multiple years to move due to the 
> re-testing, re-writing effort
> - Will the Action API also change?  Even if not I don't see great value 
> in automated JPDL migration tools, the average end-user app has much 
> more invested in actions & other jBPM API usage than it does JDPL 
> "coding".  The cost associated with re-drawing a diagram in a visual 
> tool is pretty marginal.
> 
> B - Side-By-Side Negatives:
> - QA requirements to verify that the 3 and 4 DB schemas can live happily 
> and perform well in the same DB instance
> - QA requirements to verify that the 3 and 4 JARs can live happily in 
> the same AS container and/or same .WAR
> - Timer & other enterprise features shouldn't interfere with each other
> - The downside is that the customer has to learn about and administer 
> essentially two different environments.  For example, customers are 
> likely to have custom reports on the old data model which will need to 
> "join" data with the new data model for a comprehensive report.
> 
> C - New Engine, New Projects:
> - Current users can only start their next .war, .ear with the new API, 
> new DB schema in a new DB instance, therefore they must wait for the new 
> project to start
> 
> Give me some more pros & cons for the various approaches.  The odd thing 
> is that on B & C look more reasonable based on what I've stated here.
> 
> 
> Tom Baeyens wrote:
>> to what extend will we be able to avoid DB migration if we make sure 
>> our users can run jBPM 3 and jBPM 4 next to each other ?  That should 
>> make a difference, no ?
>>
>> regards, tom.
>>
>>
>> Martin Putz wrote:
>>> IMO, we will need all of it:
>>>
>>> 1. DB migration
>>> 2. process migration
>>> 3. API migration
>>>
>>> If we don't offer tools for 1 and 2, we will definitely face much 
>>> pressure from our customers. So although it's true that we might save 
>>> some resources beforehand, we will have to deal with those issues and 
>>> questions afterwards. For 3 I think having docs should be sufficient.
>>>
>>> Regards,
>>> Martin
>>>
>>>
>>> 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.
>>>>
>>
> 

-- 
regards, tom.