views:

40

answers:

3

Say a web application is a central payment processing engine, where each user may have a different credit card provider that will be processing the credit card.

There is an interface that all of the implementations adhere to.

I want to know if there is a pattern where you could allow new implementations to be simply dropped in the deployment folder (the .jar file), without having to recompile the application. At most you would have to go into the administration section and enter some details about the new credit card implementation.

Example: Say the application currently supports Authorize.net. So all users are using authorize.net. Now I code a new implementation and drop the .jar file, go into the admin and register the new credit card provider.

Now users can login to the system, and choose to use the new implementation.

Is this possible to do w/o having to recompile? Would spring's DI come in handy for this?

+3  A: 

What you're describing sounds more suited to OSGi than the "basic" Spring bean container mechanism. Typically, the Spring ApplicationContext doesn't change once the app is up and running. In contrast, OSGi is designed for this kind of runtime dynamic behavior and can be used in conjunction with Spring. Take a look at the Spring Dynamic Modules documentation to get a sense for how that works.

Rob H
+2  A: 

I suggest that you take a look at java.util.ServiceLoader, which allows you to do a 'lookup' for interface implementations, which are added dynamically to the classpath at run time. Basically, the service jar must simply contain a text file called /META-INF/services/some.package.InterfaceName which contains a list of classes, which implement the specified interface.

There is however no standardized way to extend the classpath of a running web application (as in J2EE web application), so depending on your servlet container, you may have to restart the web application after adding new jars to the deployment directory.

jarnbjo
+1 for `ServiceLoader`
skaffman
A: 

@Rob H presents a good option with OSGi, as it does natively support what you want to do.

Another option that will not introduce a new technology is to delegate the payment methods to other JEE applications that can then be started, added or updated independently of the central payment processing engine. The admin can easily map the new payment method to the appropriate application.

Robin