7

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!

danielsan
  • 73
  • 9
  • Been a while since I did some EJB. Could you explain why you need separate BL. For the data side, are you using DAO patterns ? Would it be possible to map to multiple sources through those ? It should be possible to manage multiple data sources. – James P. Mar 28 '13 at 09:50
  • Thanks for the hyper-fast answer! That is actually the main idea. We want to use DAOs to encapsulate all the dirty stuff. The problem is how to access those DAOs from the 'client' applications. – danielsan Mar 28 '13 at 09:55
  • I would recommend an osgi approach if you are building a completely new app. But i would not recommend it if you are planning to port a lot of stuff and if the team is new to osgi. – techuser soma Mar 29 '13 at 04:43

1 Answers1

3

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

Anton
  • 5,831
  • 3
  • 35
  • 45
  • Thanks Anton. So far we have a multi-module maven project consisting of 6 modules (all the business logic and domain objects). I understand you mean we could have each of the client applications as another independent maven project and calling the Business API as a dependency, am I right? In that case it means we would deploy a Business API with each client application, in which case we would have to use different applications servers. – danielsan Mar 28 '13 at 10:29
  • yes, if you extract your business logic to separate maven project, you can include as dependency to all your applications. In this case you can use different application servers, if you want – Anton Mar 28 '13 at 10:42