How to share business logic among multiple applications

Question

We have to develop and maintain many Java web based applications (for the same company) of different sizes, scopes and life-spans. Some of them are huge and other ones are just simple pages that may live only a few months (or days), some are already implemented and need refactoring.

There have one thing in common though, they need access to (almost) the same information.

Problem

Due to the complexity of the data the company handles, we have to deal with many different sources, some of them inherited from the ancient times. Our domain objects may be mapped across many of those sources. As an example, a Contract domain object is mapped to our main database but its related (physical) files are stored in a document server, and the activity related to it is stored in a NoSQL database. Therefore, adding, removing, searching any of these objects involves many internal operations.

Our data sources are (although it could be any):

• AS400 (using DB2 as a database)
• Documentum document manager
• Mongo DB
• External web services
• Other legacy sources

We normally use Glassfish as the application server and maven as our build tool.

Goal

Our goal is to create a business layer or library that all of our applications can access and it is:

• Compact
• Consistant
• Easy to use
• Easy to maintain
• Accessible from many different clients

What we have found so far

We have been struggling for weeks and still we cannot find anything fully satisfactory. Some solutions:

• Pack all the business logic in one or more jars: Very easy to share, but all the applications will have to contain all the jar dependencies and configuration files and take care of security, caching and other stuff. Difficult to maintain (we have to update the jars for every project when there are changes).

• Create an Ejb project containing all the logic and access it remotely: Easy to maintain, security, caching and configuration only implemented once. We are afraid of the penalty of the remote calls. As we have noticed in our research, it seems to be a bad practice (we don't have much experience with ejbs).

• Create an Ear project with everything inside and use local access: Well, this is faster than the remote version but it is a hell to maintain.

• Go for OSGI: We are a bit afraid of this one since it is not as popular as Ejb and we have never used it seriously.

Is there a common practice for this kind of problem?

Many thanks!

Answer 1

I would not recommend put all logic into 1 EAR project and use local access. If you have a lot of code in the one place, it will be harder to maintain, test, deploy etc.

I would create mutlti-module maven project with common dependencies. One of the dependency - service with business logic and DAO access, which will expose API. With Maven project you can easy control version of the POM files. Different projects may work with different version of common service. Maven will handle version control for you. However it's require some configuration and implementation efforts.

Another option mentioned by you - standalone EAR with remote EJBs should work fine as well. Do not worry about performance and number of remote calls, unless you have heavy load. Simply cache remote EJB stubs on client to avoid unnecessary JNDI lookup.

Personally I prefer first option with shared dependency managed by Maven. It's clear and easy to maintain, easy to manage versions, deploy, configure. With Maven you don't need to change jar file manually for every project, you can simply use tools like Nexus