Re: [jbpm-dev] Re: Migration

Not true. Deployments are identified by namespace. The spec integration layer deploys the process to the appropriate engine. jBPM3 next to jBPM4 is not handled differently than jBPM3 next to DroolsFlow. 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. New project can bind to any BPM engine that is available. Tom Baeyens wrote: > 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. > > > > 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. >>>>> >>> >> >