I think you have it backwards. If you want your API WAR to see the plugin WAR service implementation, the API WAR has to have a dependency on the plugin WAR (in addition to the reverse). That should work although importing WARs as dependencies is probably generally not what one would consider "elegant" (you might want to consider using a JAR instead for the API, and just using Class-Path to reference it from the WARs).
Thanks for your reply. So you mean that I would have to declare both the plugin WARs to export their implementation (and services folder) as well as declare them as (import?) dependency on the WAR which does the service lookup. This sounds very uncomfortable to me because that would render the plugin concept useless. Everytime I deploy a new plugin that implements the interface, I would have to add the dependency in the core and re-deploy the core as well.
I agree that the Dependencies approach does not seem to be elegant. However, I have not found out what the JEE way of realizing such a feature would be. How would you implement such a core / plugin architecture which allows for separate deployments of plugins at runtime?
It's too late, but can be useful to someone.
I found an article decribing how to do this.
Source code on Dropbox - spi-tutorial-src.zip
I used this as reference to do an EAR.