The simplest way to share database services is to make them into discrete projects that produce JARs. These JAR files can then be included into the process of manufacturing the various apps that use them, in the same way that Spring's own various JARs are.
Maven, for example, handles this sort of arrangement very well.
There are some obvious limitations here. One is that it's assuming that all of the services are probably local to the app that's using them and that there are no shared interactions between the services of different apps. You also cannot bundle in a sharable cache for the database services. And, of course, updates to the service libraries generally mean having to update all the apps and possibly restart some servers.
One of the earliest ways to share resources and services that have interactions constraints between multiple apps in Enterprise
Java was Enterprise JavaBeans. EJBs got a lot of bad press over the years, but that's in large part because they were used as the proverbial hammer in the hands of a small child. EJBs are very well suited for providing remotable resources and services and now, of course, also local ones (the JPA standard is a subset of
EJB 3.0). Spring generally discourages EJBs over other alternatives, some of which are widely considered as more capable, but the choice is yours. EJBs do require an EJB-compliant container, though.
There are other remoting possibilities that are also popular. RMI is effectively EJB without the "bean" part, JMS and MQ technologies are good where asynchronous and high-latency communications are allowable. And of course web services, which are language-independent (as was the late, unlamented, CORBA).
One of the best ways to find options is simply to look at the Spring website for the major functional families (such as Spring Persistence), then see what sub-families look good to you.
Bundling up resources into separate JARs doesn't hide them from Spring. Spring looks for stuff using the standard classpath services, so if you add Spring annotations to the classes, Spring will treat them just like direct inclusions (of course it does need to know about scannable package paths just like in direct source inclusion).
I'd have to check, but I believe that you can also put fractional application context files in a JAR's META-INF directory. And/or declare/override application context in the application's own application context files (or whatever context-defining mechanism your BeanFactory is using).
1
