What is the alternative to OSGI for inter-module service injection in Wildfly?

Question

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.

Junia

I appreciate you don't want a debate, and you're right that StackOverflow is not the place for debates. But... you said that JBoss-OSGi fulfilled all your requirements, and offered an excellent migration path. And to be clear, JBoss-OSGi is still available and supported by Red Hat, albeit now as an optional add-on rather than out-of-the-box. So I don't really understand the motivation for this question. – Story

Valid point. Yes JBoss-OSGI is still available as an add-on. However, support from Red Hat is a more tricky issue, excluded from EAP etc., which is my first concern. In addition, it is risky using JBoss-OSGI on Wildfly when important people behind Wildfly don't really buy into it. Once again I do not wish to debate the validity of their point of view, but the fact that it exists is a risk in using JBoss-OSGI. Lastly, I feel I am missing the more obvious solution they actually had in mind for a scenario such as this, and that my tendency to think in OSGI concepts may have closed my eyes to it. – Junia

Hey @ArjanTijms, do you really patrol the whole of StackOverflow to make sure people say "Java EE" instead of the widely understood terms JEE and J2EE? Your devotion to nomenclature and trademarks is admirable but a little narrowly focused... I mean why not correct OSGI to OSGi? – Story

I suppose I understand your reasoning, though I disagree with it. While some people at Red Hat don't buy into OSGi, others certainly do. Removing OSGi from the core product seems to have been pushed through successfully by one faction, but I believe they would have a much harder time killing the JBoss-OSGi add-on project. Anyway... you're the customer, shouldn't Red Hat be concerned about supporting what you want to do, rather than you trying to second-guess what they think you "should" do? – Story

Agreed. And things on the Weld-OSGI side still seem to be going strong as well and I believe there is a lot of potential there too. We are weighing in alternatives at this point. The problem is that the removal of JBoss-OSGi from the Wildfly distribution, especially along with the statement that there was a "lack of customer interest", hurt our arguments for adopting OSGi, which we still have to take through our corporate structures. So we are desperately open to alternatives a this point, but they're not exactly poring in, likely for the reasons you have highlighted. – Junia

@NeilBartlett Thanks for the comment, yes I indeed try to. Note that SO itself also renames both JEE and J2EE to Java EE (see stackoverflow.com/tags/synonyms, filter on e.g. JEE). See also this answer: #17762584 You are right about OSGi and such. If I happen to spot them in the same sentence I occasionally try to improve these too, but I only edit for a couple of minutes per day and unfortunately there's only so much I can do in that time. – Judithjuditha

Answer 1

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.

Story

Very relevant link, and it clarifies a lot. I can see where David Lloyd is going, but in our case I actually think a good argument can be made in favor of the service idea. Not that I have that luxury either way since it is a legacy application. See my comment above regarding my motivation. – Junia

Can you please back up the claim that jboss-osgi would be still available and supported by Red Hat? As far as i know (and I've been htting my head against the wall about this for a long time, also with RH support) it's never been supported by Red Hat, only by community efforts, and nowadays not even that. Also it doesn't work OOB with any final version of Wildfly (see this and this), and the person responsible for the integration (Thomas Diesler) is no longer an employee of Red Hat. – Capability

Ok, I just noticed this message was written in 2013. At that time there was at least an idea that JBoss-OSGi would become supported, so possibly this answer is just outdated in that regard. – Capability

Answer 2

Apache Felix can be embedded in your application server as 'OSGI host'. Then you can create plugin mechanism for the required system. All of your services can be implemented as 'bundles'. OSGI host in the server can find the bundles in a deployment folder, and installs/starts them. You can then enable your web service,rest and other services without restarting the application server.

Unreflecting

Whereas Felix is indeed an alternative to JBoss-OSGI, and your solution could very well work, it does not get us away from OSGI as such. Remember we are trying to align our thinking with the Wildfly 8 world in this regard, a world without OSGI. Wildfly's jboss-modules infrastructure offers a lot of similar features to OSGI, so some kind of OSGI-like solution must be possible without actually using OSGI. I'll put your suggestion on my todo list though... – Junia

'A world without OSGI'. Apache Felix is there to provide you the osgi functionality, not the WildFly. You can then use IPojo or etc... But you want to get away from OSGI solutions as well, not only beacuse of the WildFly limitation? – Unreflecting

Correct. See my response to Neil Bartlett's comment for my reasoning. – Junia

Answer 3

Where I work, we had to pick something in order to continue the project when JBoss-OSGi was declared dead. We went with JBoss Modules + EJB approach, since they're actually supported by Red Hat. JBoss Modules is used for static module dependencies, and EJB for runtime injection of services.

We don't use remote EJB but EJB 3.x local EJBs, and that wasn't thrown away in your list, so I guess it's ok to offer this.

Capability

That does indeed address the need for inter-module injection, but as far as I know, when you inject the interface of the EJB, you have to specify the implementation. That means that you create a static dependency on a specific implementation - either B or C in my question. OSGi and the Java ServiceLoader framework which Neil refers to, both provide a way to provide multiple implementations of an interface and only decide at runtime which one to use. – Junia

@AmpieBarnard um. No, you don't have to specify the implementation. That is kind of the point. We have lots of implementations of a single interface that you can change runtime. – Capability

I'm stumped. Please could you attach some code where you have two EJB implementations (B and C) of the same interface X, you inject the interface into EJB A, you deploy both implementations and then at runtime decide which implementation to use? – Junia

I don't have such example at hand, that is work done for my employer. But I don't see where the need to specify the implementation would be coming from - EJB in general is based on JNDI lookups with agreed namespaces, not hardcoding the implementation. – Capability

Unless by specifying the implementation you mean specifying the JNDI name? Portable JNDI namespaces should be used, not something tied to an implementation class... – Capability

Fair enough, but no need to show all the code. I just still don't know of a technique to inject multiple (not 1, or 2 but N) EJB implementations of an interface and then deciding at runtime, (maybe I should rather have said 'programmatically'?), which to use. As an example, in PAX CDI I would use: @OsgiService @Inject Instance<X> x; and use qualifier literals to find the right implementation. With Blueprint I can inject a collection of implementations and scan its metadata. How did you achieve this with EJB's? – Junia

Ah - to be exact, that's not what our system does. What it does is that on runtime, there is only one implementation deployed, but it is looked up runtime and no implementation class is specified anywhere. If you want to switch to another implementation, you undeploy the previous one and deploy a new one, or replace the previous one at runtime. New one is then looked up with JNDI lookups based on the interface. – Capability

Thanks for sharing that. It does give me some new ideas on how to address this requirement, albeit not with injection. I could register all the implementations of an interface under a certain location in JNDI and programmatically select one. – Junia