A Groovy Apache Fortress

[Shawn McKinney <sm...@apache.org>]

I’ve been doing some experimentation around a couple of API sets, specifically AccessMgr and AdminMgr.

The goal

To simplify or enhance the API interactions with Apache Fortress specifically, or access control systems in general.  Admittedly, the fortress managers have grown over the years, both in number of methods, and complexity.  That is, as a new use case or features pop up, say dynamic constraints placed on roles, new APIs must be invented to handle the new patterns.

While this is a good thing, the system’s evolving/adaptable, it’s bad from the standpoint of the number of methods users must learn.

Let’s take the [AdminMgr](https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/AdminMgr.java) for example.  It has over 50 public methods!  Perhaps understandable when one considers all of the entities that are being processed.  But also highly complicated and confusing for someone who is new to the space.

What does groovy got to do with it?

Enter Apache Groovy.  As most of you know, a dynamic scripting language that sits on top of the Java virtual machine.  It accelerates development through the elimination of boilerplate and bringing some convenience to longstanding irritations in the platform.  Things like checked exceptions, brackets, even semi-colons are no longer required.  

Here it brought the means to rapidly iterate over some design patterns, in order to find easier to use call/response flows.

The new GroovyAdmin manager has really just one method!  Basically, the ‘doIt' passing an operation and entity names, along with a map, that contains the model (data).  The map maps directly to the fortress model, using the same entity names and attributes.

Similarly, the Access manager can be simplified.  No longer do we need many methods to create the session (for example).  Again, only one method, start, is needed.  Again passing only a map containing the operands pertinent to the requires.

One could easily envision how this API pattern would work in a service-based setting.  Instead of calling a groovy function, the client would invoke a service, passing a JSON map with the data.

If this sounds interesting, there’s a test project here:  

[groovy-apache-fortress](https://github.com/shawnmckinney/groovy-apache-fortress)

Comments, critiques (tell me that I’m crazy), pull requests, etc, are welcomed.  From my perspective, the conversation about authorization has grown STALE.  It appears to me we’ve relegated this concern to the cloud providers (Oauth anyone?).  Our challenge, to find innovative ways to engage with the community.  Introducing patterns that work in the real-world, breaking down barriers, forcing the conversation into newer areas, beyond the status quo.

—
Shawn



---------------------------------------------------------------------
To unsubscribe, e-mail: fortress-unsubscribe@directory.apache.org
For additional commands, e-mail: fortress-help@directory.apache.org