Java – how to share business logic across multiple applications

We must develop and maintain many Java Web based applications of different sizes, ranges and lifetimes (for the same company) Some of them are huge, others are just simple pages, which may only exist for a few months (or days). Some have been implemented and need to be refactored

But one thing in common is that they need to access (almost) the same information

problem

Because of the complexity with which companies process data, we have to deal with many different sources, some of them from ancient times Our domain objects can be mapped across many sources For example, the contract domain object is mapped to our master database, but its related (physical) files are stored in the document server, and its related activities are stored in the NoSQL database Therefore, adding, deleting and searching any of these objects involve many internal operations

Our data source (although it may be any data source):

>AS400 (using DB2 as database) > Documentum document manager > Mongo DB > external Web Services > other legacy resources

We usually use GlassFish as the application server and Maven as the build tool

target

Our goal is to create a business layer or library that can be accessed by all our applications. It is:

>Compact > consistent > easy to use > easy to maintain > accessible from many different customers

What have we found so far

We've been struggling for weeks, but we still can't find anything satisfactory Some solutions

>Package all business logic in one or more jars: it is very easy to share, but all applications must contain all jar dependencies and configuration files, and be responsible for security, cache and other contents Difficult to maintain (when there is a change, we must update the jar of each item). > Create an EJB project that contains all logic and remotely accesses it: easy maintenance, security, caching and configuration are implemented only once We are afraid of the punishment of remote calls As we have noticed in our research, this seems to be a bad practice (we don't have much experience with EJBs). > Create an ear project that contains everything and use local access: Well, it's faster than the remote version, but it's a hell of maintenance. > OSGi: we're a little afraid of this because it's not as popular as EJB. We've never taken it seriously

Is there a common practice for this problem?

Thank you.

Solution

I do not recommend putting all logic into 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 will create a mutlti module Maven project with public dependencies One of the dependencies – a service with business logic and Dao access that exposes the API With the Maven project, you can easily control the version of POM files Different projects can use different versions of public services Maven will handle version control for you However, this requires some configuration and implementation work

Another option you mentioned - a stand - alone ear with a remote EJB should also work Unless you are overloaded, don't worry about the performance and number of remote calls Just cache the remote EJB stub on the client to avoid unnecessary JNDI lookup

Personally, I prefer the first option of shared dependency managed by Maven It is easy to maintain, manage, deploy and configure With maven, you don't need to manually change the jar file for each project, just use tools such as nexus