APIMan Policies as Plugins

[msavy]

This is something somewhat in the future, but would be nice to strike up a conversation about now. Consider the following to be 'thinking out loud' more than 'official APIMan architectural decision'!

ewittmann and I had a long design meeting on Friday, and amongst the topics we covered was the possibility of having 'Policy Plugins', which would allow developers to easily define new policies (that would then be loaded into APIMan's core).

Because of how Java works it can be a bit tricky, especially when there may be arbitrary external dependencies that must be satisfied (e.g. the plugin wishes to import a library). Obviously, rolling our own would be quite tricky, and possibly a problem that's already been solved elsewhere.

One of the key criterion of APIMan is that we pull in as few dependencies as possible, so anything we look at must be lightweight and pull in as few transitives as possible.

After quick bit of research, the only 3 options I really obviously stumbled across are:

1) Java Simple Plugin Framework (JSPF)

  https://code.google.com/p/jspf/wiki/UsageGuide

2) OSGi

3) DIY

1) Seems quite nice, but hasn't been updated in a while; however, it does use annotations which may pull in more deps than we'd like?

2) I think is excessively complex for our needs, and pulls in a huge number of large dependencies - it may create more problems than we solve.

Is anyone aware of possible projects which could do what we want, or perhaps some experience of the above which might be helpful?

[objectiser]

Have no experience with (1) and agree (2) is too heavy weight.

Wouldn't it be possible to use the Service loader mechanism in commons? which I think can use OSGi services or the service loader, depending upon which environment it is in - Eric would obviously be the best person to comment on this? So although OSGi on its own would be too heavy weight - if running in an OSGi container there is no extra overhead, so the mechanism could be leveraged.

[eric.wittmann]

It's possible to use the service loading mechanism already in overlord-commons, but that assumes everything is on the classpath.  A true plugin mechanism would presumably work at runtime.  So we'd either need something else or else the overlord-commons loader would need to be enhanced in some way.

I agree that when running in an OSGi environment we should definitely use OSGi.  That should be easy enough to do - it's just a matter of using the OSGi service registry.

The question is what to do when running in some other environment.  I'm thinking that packaging up a plugin as a WAR (or something similar) is the way to go.  We then just need a classloader that can understand a WAR format.  Perhaps there is something open source we can leverage for this.  WAR is nice because it can do what we need and is easy to produce.  Whatever the unit of packaging is, it would need to include 3rd party dependencies inside of it - another reason WAR is a nice choice.

[eric.wittmann]

It would probably be worth our time to list out all of the functionality that would need to be provided by apiman plugins.  I'll start and we can add content as we think of it:

• Policy Implementations
• Policy Definition meta-data (consumed by the management layer to show users what policies are available?)
• Components (used by policy implementations - examples include the Shared State Component and the HTTP Client Component)