Whenever one Project decides to join with another one (which is the way we want to go, we decided to migrate our code to be integrated into the JFire ERP Project) there are some hurdles to be taken in architecture. Architectural decisions are sometimes defined to be hard or impossible to change or revert. I took a long walk through the existing ERP Solutions to find that Jfire is as close to our architecture that an integration attempt could be made.
Jboss
Jfire Server runs on Jboss with EJB 2.x Components. Mango (our project, see http://www.eiswind.de) up to now had a monolithic J2SE Server based on pure Spring solutions. It took me a day to migrate the Spring RMI Services to EJB Stateless beans, mostly by replacing the Spring Annotations with EJB3 counterparts. Concepts are mostly the same, only name changes. Some little more effort still needs to be taken to deploy Jackrabbit as a Jboss Service. What turns out to be the hardest thing is that we need an xmpp server component ready. With Mango I already had a hard time in integrating OpenFire in the monolith, and as I know the hell inside the openfire distribution jars (sorry for that, I had to say it) I will give up on openfire and try to deploy tigase on jboss. I still don’t have a conrete solution for that, guess it will still need some hacking, staring with JNDI configuration for the datasource.
The Backend: From hibernate to datanucleus:
Jfire uses datanucleus JDO on the backend side (generated with xdoclet), mango has annotated JPA inside with hibernate. This should have been no greater issue, if we didn’t use hibernate search and hibernate validator. Hibernate search will be replaced with compass http://www.compass-project.org/ which at least can manage the lucene index on our objects. Need to change Annotations here to, concepts are similar. For now I will leave the hibernate valdator stuff in the model as its used in the client for validation in the ui. Still have to think if we need another validation layer in the server at all, and when so if we build a bridge to datanuclues. Why we change the backend at all? We found that even if JDO has a little outdated taste it has some strengths compared to hibernate when it comes to client-server computing (see all the crazy discussions on remote lazy loading that come up with hibernate.) With hibernate you can define EAGER or LAZY but you have to decide. With JDO you can have mutliple fetch plans defined and load only what you need for the moment. To me that’s the groundbreaker to move away from hibernate. Hibernate is made for web apps, that what I always thought. But I simply didn’t know better and I’m keen to find out about the possibilities datanuclues will open up.
Eclipse RCP
On the client side I still fight with the target platform. Jfire compiles against a 3.3 target, and we need at least 3.4 for Mango client to compile. I still did’nt manage to setup a clean target platform that will satisfy Jfire dependencies as in the Jfire code there seem to be bo feature sets defined that declare the dependencies (folks at nightlabs correct me if I’m wrong). From the Code side its really simple, I just replaced the Spring RMI Stub lookubs with JNDI lookups.
The hell: data migration.
What will be a tough part is to migrate data from existing installations into the jfire database. I hope that I will be able to hack our model code generator to be able to generate mappings that both fit to the old database and the new ones.
But all in all its something we can do within reasonable time. Life is magic.
