NFJS - Spring ACEGI

Presented by Stuart Halloway, Relevance, LLC

ACEGI is a generalized authentication and authorization system for Java, with specific hooks built-in for the Spring Framework. Since my experience with such systems is light, my ability to cover what was presented will be correspondingly basic.

The name ACEGI is not an acronym. It is derived by using the first 5 odd letters of the alphabet. Like most Spring-based services, ACEGI relies heavily on XML-configuration files. It is built using the Inversion of Control pattern and with dependency injection, it is possible to modify behaviors of the security system. One key example pointed out by Stuart in the talk was that JAAS security library, which (if I remember correctly) is part of the Java standard, can be used as the authentication server instead of the default service provided by the ACEGI distro.

The key components of an ACEGI based system include:

• Authentication


• Authentication Manager


• Access Decision Manager


• Secure Object Interceptor


• Run As Manager


• After Invocation Manager

The last two components are only used in special cases. A simple use case would be:

1. User submits principle (user) and credential (password) to Authentication object


2. The Authentication Manager populates the Authentication class with Authorities (permissions) based upon the provided Principal and Credential


3. User invokes the desired method, which is intercepted by the Secure Object Interceptor (shades of AOP at work!)


4. The SOI queries the Access Decision Manager regarding whether the request can proceed


5. The ADM passes this query on to the Authentication object, which accepts or rejects the request based upon the stored security data


6. Assuming the request was allowed, the SOI then invokes the actual method requested by the user

Because of the use of AOP, it is possible to add security to objects that were not even designed with security in mind!

Internally, the Authentication object and the Access Decision Manager use a collection of web filters that are responsible for the ultimate processing of the security requests. These filters are configured in an XML file (another example of IOC and DI use). Several examples of how these filters are used were presented in the class. This turns out to be one of the more difficult concepts in using ACEGI. It turns out that these configuration files must be carefully constructed and the order of the filters must follow explicit rules in order for the system to work correctly. Stuart is a big fan of this system and even he had harsh criticism to levy about this issue.

As mentioned earlier, a lot of the details are being elided here, mostly because of my ignorance of security. Based upon the examples shown in class however, I believe that it would be very straightforward to set up a secure system (typically web-based, but that isn’t required) using the ACEGI Security system.

NFJS - Spring AOP

Presented by Stuart Halloway, Relevance, LLC

This seminar provided a deeper dive in to AOP with Spring. As mentioned earlier, Spring uses Dependency Injection and the IOC pattern to minimize dependencies. But sometimes, there are dependencies that are too broad to be removed using DI. In many of these instances, AOP can solve the problem. The simple (yet powerful) example Stuart provided was that of three inheritance trees:

SuperBeing                  SoftwareProject
 ^      ^                          ^
 |      |                          |
 |      --------                   |
 |             |                   |
SuperHero SuperVillain      OpenSourceProject         Server

 

Assume that each of the classes has an attribute name and we need to validate the name when it is set. Placing a name validation method in each of the four concrete classes would result in repeating the code four times. But since we understand OO concepts, we move the method into the base classes to reduce repetition. Now we only have to repeat the code three times!?! Not a great improvement. But with AOP (in Spring), we write the name validation method one time and using a Spring configuration file, attach the method to every class that needs it. This, in a nutshell, is what AOP is all about. Note that this mechanism is so powerful, we could add the name validation method to a class even if we don’t have the source code for it.

The name validation requirement in the previous example is referred to in AOP as a “cross cutting concern”. In non-AOP systems, cross cutting concerns often result in a lot of code duplication. When this code is isolated in one place with AOP, it is referred to as “advice”. The point where advice is applied in the code is called a “joinpoint”. A collection of all joinpoints for a given piece of advice is called a “pointcut”. The combination of a pointcut with its advice is called an “aspect”. Lots of new terminology, but it didn’t take long for it to make sense.

Stuart presented several examples that illustrated how aspects could be applied to a class, including method intercept, before method, after method, and throw only. The Spring framework implements AOP natively and is relatively easy to use. For higher efficiency implementations, Spring also supports AspectJ. It was mentioned that it is straightforward to start with Spring AOP and migrate to AspectJ.

It should be pointed out that the primary mechanism for implementing aspects is to modify the byte code of the class being aspected. It was interesting that Stuart offered the same advice on concerns about this that Dr. Venkat Subramaniam did at a JUG meeting a couple of months ago, which was, “Get over it!” Stuart followed this with an observation that wound up being a “Got it!” moment for me. He compared people who complain that they can’t directly see aspects in the code and therefore worry about what is being executed to similar criticisms in the past about OO and how you couldn’t see what code was being executed because of inheritance hierarchies. Not only do I remember these criticisms, I was guilty of making them early on (he admitted shamefully). So I am happy to say that I have “gotten over it” and am really looking forward to investigating AOP. I’ll probably start with the Spring version, but hope to try AspectJ soon as well.

NFJS - Introduction to Spring

Presented by Stuart Halloway, Relevance, LLC

Stuart is a consultant out of North Carolina. As you will see, I attended many sessions presented by him. He is very dynamic, very knowledgeable, and has a great sense of humor. He also covered lots of Spring topics, which helped as well.

According to Stuart, Spring is Australian for no EJB. As an aside, he said that “having a pulse is Australian for no EJB 1.x or 2.x”. Kind of puts where he is at in perspective.

Spring is a framework that attempts to solve problems typically solved using J2EE, but in a more lightweight fashion. Based on what I heard over the weekend, I tend to agree. At its core, Spring is based on three core concepts. Configuration, Dependency Injection, and Aspect Oriented Programming.

Spring’s answer to configuration may be the most controversial of its features. The basics of a Spring application require minimal code, but the cost of this is large configuration files written in XML. I lost track of the number of times over the weekend a disparaging remark was made about XML. I do wonder why as much as the experts seem to dislike XML, it is still so prevalent. Anyway, if you are going to use Spring, you are going to use XML.

Dependency Injection is the mechanism that allows the details to be encoded in an XML configuration file. DI is based upon the Inversion of Control pattern. The idea is that an object doesn’t “reach out” to get other objects it needs (typically by calling new). Instead, the dependencies are “pushed to” the object from external sources. The means of this injection can be via constructor arguments or via bean-like setters. If the object is designed to depend only upon interfaces, DI can be used to modify object behavior by injecting specialized objects which implement these interfaces. And in Spring, the XML configuration files allow the injected objects to be changed without changing the code.

J2EE also uses an IOC pattern, but realizes it via context or JNDI lookups, which according to Stuart is more cumbersome. Also, evidently Spring minimizes the number of dependencies upon itself, while such dependencies are prolific in J2EE. Never having worked with J2EE, I am parroting what I heard at the seminar. I did find the explanation of Spring much easier to comprehend compared to some J2EE classes I took last year.

The final core component of Spring is Aspect Oriented Programming. If I took nothing else out the symposium, I learned that AOP rocks! I had some exposure to AOP prior to NFJS, but the message was really brought home in Stuart’s talks. I took an entire seminar on Spring and AOP, so I will cover the details in an upcoming blog. Again, the biggest downside to AOP in Spring is the massive XML burden it brings along.

During this talk, Stuart also presented examples of support services provided by Spring. He showed an example using a JDBC that showed how simple it was to connect to a database from a Spring container. He followed that up with a Hibernate example. I am really interested in Hibernate and it is dead easy to use in Spring, but for now, I plan to learn stand-alone Hibernate so that I really understand it well. After that, I will probably explore using it in Spring.

The last topic Stuart covered was Spring’s answer to security, called ACEGI. Again, I took an entire seminar on the topic, and so will reserve the details for a later blog.

NFJS - Intro

One of my goals for the year was to improve my technical skills, particularly related to Java surround technology. One of the first things I did to realize this goal was to start attending meetings of the Boulder Java User’s Group and Denver Java User’s Group. Both JUGs attract excellent speakers who cover interesting and relevant topics. If you live in the Denver area, I highly recommend attending.

While I will probably blog more on these meetings at a later date, the point today is that through these meetings, I learned of the 2006 Rocky Mountain Software Symposium, a.k.a, the No Fluff Just Stuff Tour. The symposium was held near Avaya and after looking at the seminars available, I decided I wanted to attend. The first option, obviously, was to pay for it myself. While I was willing to do so, I decided to first see if Avaya would foot the bill. The company ended up sending me along with two co-workers. SCORE!!!

It was well worth the time. I learned a lot of great stuff.

Future blogs will summarize the seminars I attended. Along the way, I will also share some of the most interesting ideas and soundbites that I took away from them.

Until then, here are some general soundbites I took away from the speakers and attendees…

• Java is not just a language, it is a framework.


• Who needs architects?


• Right to left scheduling. <= One of my favorites!


• And a bonus quote from a speaker (I wish I could remember who) at a local JUG:
  
  • Any project with more than 10 team members is bound to fail!

Why am I blogging...

Short answer, cuz all the cool kids are doing it!

Longer answer. I've really enjoyed reading other peoples blogs. In particular, a friend of mine writes on some interesting things. A local technical author has also peaked my interest. And while Joel On Software isn't really a blog, Joel uses it as a forum to share ideas, which I hope to do as well.

My focus will be on some kind of geeky things, but I reserve the right to stray into unfamiliar territory when the mood strikes. I probably won't be the most consistent blogger in the world, but since I won't be the most scintillating either, you won't be missing much.

First up... The No Fluff Just Stuff seminar.