What is the alternative to OSGI for inter-module service injection in Wildfly?
We are in the process of disentangling a classic legacy monolithic EAR-packaged Java EE application. Our (most complex) component wiring pattern is as follows: component A 'requires' interface X, whilst components B and C (... N) each 'provide' interface X. Our requirement is to package and deploy A, B, C and X separately and independently in order to minimize downtime and minimize business impact.
We therefore require the necessary robustness to allow providers (B,C) of interfaces to be removed and added (redeployed), at runtime, without requiring a redeployment of the consumers (A) of the interface, nor a restart of the server. The solution will run on Wildfly 8, but can make use or other technologies as long as they work on Wildfly 8.
We've implemented a POC using JBoss-OSGI and Weld-OSGI which fulfilled all of our requirements, and offered us an excellent migration path as well. However, in Wildfly 8 Alpha 3, JBoss-OSGI was removed from the default distribution. This made us think we should explore alternatives that are more in line with the thinking of the people behind Wildfly.
The question therefore is, on Wildfly 8, what is the alternative to OSGI for inter-module service injection that would meet our requirements?
For the sake of budgets, simplicity, performance overheads and company policies, we've had to eliminate the following:
1. Remote EJB's
2. Web Services
3. JSon/Rest
4. SCA
Please note that this is not a request for a debate on the viability of OSGI nor for an evaluation or comparison of different solutions. I am simply looking for any solution(s) that would meet our criteria and is NOT based on OSGI.
Answer
Since you're asking about the thinking of the people behind WildFly, I will refer you to the following mail-list message. It was posted to the Jigsaw development list by David Lloyd, who is (I believe) the designer of JBoss Modules on which WildFly is based. The context was a discussion about the introduction of a service model into Jigsaw: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html
What David seems to be saying is either that the idea of services itself flawed – i.e. you don't need them! – or that the requirement is already sufficiently solved by the ServiceLoader API which was introduced in Java 6.
However, ServiceLoader is known not to work on module systems that use classloader isolation, which includes both OSGi and JBoss Modules. This is because ServiceLoader uses classpath scanning, and in a module system there is no "classpath". In OSGi we have specced a way of adapting ServiceLoader (though it's yucky and requires bytecode munging). Perhaps JBoss Modules also has a way of handling this, but I couldn't find anything from a quick scan of their docs.
Anyway as I said in my comment above, I'm puzzled about your motivation. You clearly get benefits from the service model provided by OSGi, and JBoss-OSGi is still available and supported by Red Hat... so why not continue to use it? Especially if there is nothing clearly provided by WildFly out-of-the-box that does what you want.