How to share business logic between multiple applications

Question

We must develop and maintain many Java web applications (for the same company) of different sizes, areas, and life cycles. Some of them are huge, while others are just simple pages that can last only a few months (or days), some of them are already implemented and need refactoring.

There is one thing in common, although they do need access to (almost) the same information.

Problem

Due to the complexity of the data that the company processes, we have to deal with many different sources, some of which are inherited from ancient times. Our domain objects can appear in many of these sources. For example, the Contract domain object is mapped to our main database, but the (physical) files associated with it are stored on the document server, and the activities associated with it are stored in the NoSQL database. Therefore, adding, deleting, searching for any of these objects is associated with many internal operations.

Our data sources (although this can be any):

• AS400 (using DB2 as a database)
• Documentum document manager
• Mongo db
• External Web Services
• Other obsolete sources

Usually we use Glassfish as an application server and maven as our build tool.

goal

Our goal is to create a business layer or library accessible by all our applications, and this:

• Compact
• consistent
• Ease of use
• Ease of maintenance
• Available from different customers

What have we found so far

We fought for weeks, and we cannot find anything completely satisfactory. Some solutions:

• A package of all business logic in one or several banks: it is very easy to share, but all applications will need to contain all the dependencies and jar configuration files and take care of security, caching and other materials. It’s hard to maintain (we need to update banks for each project when there are changes).

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

• Create an ear project with everything inside and use local access: well, it is faster than the remote version, but it is hell that can be maintained.

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

Is there a common practice for this kind of problem?

Thank you very much!

Answer 1

I would not recommend putting all the logic in one EAR project and using local access. If you have a lot of code in one place, it will be more difficult to maintain, test, deploy, etc.

I would create a maven maven module project with common dependencies. One of the dependencies is a service with business logic and DAO access, which will expose the API. With the Maven project, you can easily manage POM file versions. Different projects may work with a different version of the shared service. Maven will manage the version for you. However, this requires some configuration and implementation efforts.

Another option you mentioned is a standalone EAR with remote EJBs should also work fine. Do not worry about the performance and number of remote calls if you do not have a lot of work. Just cache remote EJB stubs on the client to avoid unnecessary JNDI lookups.

Personally, I prefer the first option with a general dependency managed by Maven. It is clear and easy to maintain, easily versioned, deployable, customizable. With Maven you don’t have to manually change the jar file for each project, you can just use tools like Nexus