In the Spotlight - Craig Walls

I read this last night, but I have seen this coming for over a year.

I normally don't write opinion pieces on my blog. But this one was special to me and I felt compelled to share my thoughts on the recent Spring Source announcement. We'll return to the normal tech-centric blog entries soon.

About this time last year, I was chatting with Rod Johnson on the phone and he said something to me that stuck: "We (SpringSource, then Interface 21) are poised to change enterprise Java more than ever before." To me, this seemed like a very bold statement coming from a man who had started a revolution that has already had a profound impact on enterprise Java. What more could be in store for us?

Then I started seeing the pieces come together: OSGi, Tomcat support, an application management suite, and perhaps dozens more pieces that I didn't associate with the "big picture". And that's not to mention several hints that Rod has given us in blog entries, interviews, and keynotes.

So, last night's announcement wasn't a surprise to me at all. In fact, I've pretty much been playing prognosticator for awhile now, predicting this new breed of application server to people I work with, meet at conferences, and exchange e-mails with. The only surprise was that it happened when it did...I was expecting a few more months before a big announcement.

I've read some of the comments on the InfoQ article and there are some interesting points made. In particular, one reader pointed out that this splinters the enterprise Java world into a "standard" JEE environment and a Spring/OSGi-enabled JEE environment--wouldn't adopters of the Spring application server be signing up for vendor lock-in?

Well, in a word, yes. Sorta. But not really. Well...maybe.

How's that for a definitive answer?

You see, along with my predictions of a Spring application server, I've also been predicting a shift in what we call "standard" JEE. I've been predicting a JEE future where applications are no longer deployed in big monolithic EAR/WAR files and instead are deployed in smaller, easier to manage, individually deployed bundles that collectively make up an application.

In my predictions, that piece-by-piece approach to development not only applies to the applications that you and I write, but also to the platform that they run on. Rather than deploy to application servers with every capability under the SUN (pardon the pun), why not size the platform appropriately to fit the needs of the applications running on it? If your application doesn't need EJB, then don't install the EJB bundle. You do need JMS? Okay...install the JMS bundle. This "right-sizing" of the application server works both ways: You don't need to have the entire JEE collection of specifications if all you're running is a servlet-based application. Likewise, if there's some capabilities that you need that go beyond the JEE specifications, then perhaps there's a bundle (or bundles) that provide what you're looking for.

Now, before I add "Soothsayer" to my business cards, I must admit that my predictions were quite easy to make. They are in line with things that Rod has been saying in his blog, in interviews, and in his Spring Experience keynote. It's also consistent with the two primary goals of Java EE 6 (JSR-316): extensibility and profiles. In short, I haven't envisioned anything that hasn't already been in the minds of Rod and several other people out there that are smarter than me.

Back to the original question: Does this splinter JEE? If you consider JEE a comprehensive suite of specifications to cover all enterprise needs, and if you think of EAR/WAR files as the end-all of deployment units, then yes...this is a departure from the JEE you've come to know and love. If this concerns you, then you are free to not use Spring's application server. Please go ahead and use whatever JEE platform suits you best.

But I say that while that model has served us well for several years, I think we can do better. And so does Spring Source.

So, while the development and deployment models of the new Spring application server are not exactly consistent with the standard JEE specs, they do represent a shift in the JEE landscape. I won't wager that Java EE 6 will follow the exact same model as the Spring application server, but I expect that it will be greatly influenced by it and that the Spring application server will ultimately be an implementation of JSR-316. (See Hibernate/JPA for a precedent case on how the JCP can be influenced by open-source.)

Put another way: The "standard" is changing.

I'm in Bellevue, WA this weekend for the Pacific Northwest Software Symposium (a No-Fluff/Just-Stuff event) and I've been caught off-guard with a handful of questions regarding Tapestry. Then, half-way through one of my sessions, it occurred to me that the reason for those questions might have something to do with the fact that Mr. Tapestry himself, Howard M. Lewis Ship, is also speaking at this show (his presence at the back of the room tipped me off).

I used to be a big fan of Tapestry. I've written apps with both Tapestry 3 and Tapestry 4...and had a great time doing it. But I've not worked with Tapestry in quite some time. There are several reasons:

• I simply haven't had much opportunity to use it on any projects. For the past 2-3 years, I've been on projects where Tapestry wasn't an option...either because a web framework choice had been made before I joined the project or, on one project, it was a .NET project.
• I didn't find that there was a vibrant Tapestry community. I can't say for sure if that's still true, but 2-3 years ago, it seemed like it was just Howard and a handful of other folks.
• Other web frameworks caught my eye and have kept me plenty busy enough to not re-explore Tapestry.
• Honestly...while I liked Tapestry, I didn't feel good about the not-so-POJO development model. And, although I'm not a member of the He-Man XML-Haters Club, I did think that Tapestry's XML configuration was a bit much.

Howard caught me after a session yesterday and wanted me to take another look at Tapestry. I was too exhausted to look at anything last night, so I just went to bed. But this morning, my central-time brain woke up plenty early enough in this pacific-time world to give Tapestry 5 a once-over.

My initial reaction: It's good stuff! The XML is gone and annotations are in. Pages are no longer abstract and no longer extend base Tapestry classes--they're POJOs.

So...very good work, Howard! I might have to come up with some excuse to try Tapestry 5 on one of my personal projects to see if the niceness of the simple examples scale up to a more real application.

Spring Security 2.0 was released today. To mark the occasion, I thought I'd write a little blog entry to show how you can use Spring Security to restrict method invocations to properly authorized users.

Let's say that you have a class with a method that must be secured...something like this:

package com.habuma.expectations.springsecurity.intercept;
public class SecuredObject {
   public String getSecuredData() {
      return "Top-Secret Data";
   }
}

In this simple example, we only want users who are granted "secret agent" authorization to be able to invoke the getSecuredData() method. In Spring Security 2.0, there are three ways to secure this method, starting with adding a method interceptor in the Spring XML:

<?xml version="1.0" encoding="UTF-8"?>
	
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:sec="http://www.springframework.org/schema/security"
   xmlns:beans="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
               http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
               http://www.springframework.org/schema/security
               http://www.springframework.org/schema/security/spring-security-2.0.xsd">


   <bean id="securedObject" 
       class="com.habuma.expectations.springsecurity.intercept.SecuredObject">
     <sec:intercept-methods>
       <sec:protect access="ROLE_SECRET_AGENT" method="getSecuredData"/>
     </sec:intercept-methods>
   </bean>
...
</beans>

The <sec:intercept-methods> along with <sec:protect> tells Spring Security to intercept calls to getSecuredData() and only allow the method to be invoked if the Authentication object in the security context has "ROLE_SECRET_AGENT" authority. If there is no Authentication object in the security context (that is, the user hasn't been authenticated), then an AutheneticationCredentialsNotFoundException will be thrown. If the user has been authenticated, but does not posses the required authority, then an AccessDeniedException will be thrown.

Tweaking the XML as shown is pretty easy, but annotations make it even easier to secure methods. Let's change the XML to look like this:

<?xml version="1.0" encoding="UTF-8"?>
	
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:sec="http://www.springframework.org/schema/security"
   xmlns:beans="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
               http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
               http://www.springframework.org/schema/security
               http://www.springframework.org/schema/security/spring-security-2.0.xsd">


   <bean id="securedObject" 
       class="com.habuma.expectations.springsecurity.intercept.SecuredObject" />

   <sec:global-method-security secured-annotations="enabled" />
...
</beans>

The <sec:global-method-security> element is used to specify security settings that apply across an entire application context. In this case, I've enabled annotation-based security by setting secured-annotations to "enabled". With this in place, I can now annotate the getSecuredData() method as follows:

package com.habuma.expectations.springsecurity.intercept;
import org.springframework.security.annotation.Secured;

public class SecuredObject {
   @Secured( {"ROLE_SECRET_AGENT"} )
   public String getSecuredData() {
      return "Top-Secret Data";
   }
}

What's great about the annotation-based approach is that I can now restrict access to any method in my application by simply annotating them with @Secured.

As nice as @Secured is, some of you may be wondering if a standards-compliant annotation might be a better choice. No problem...Spring Security can also support JSR-250's security annotations with the following adjustment to the XML configuration:

<?xml version="1.0" encoding="UTF-8"?>
	
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:sec="http://www.springframework.org/schema/security"
   xmlns:beans="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.springframework.org/schema/beans
               http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
               http://www.springframework.org/schema/security
               http://www.springframework.org/schema/security/spring-security-2.0.xsd">


   <bean id="securedObject" 
       class="com.habuma.expectations.springsecurity.intercept.SecuredObject" />

   <sec:global-method-security jsr250-annotations="enabled" />
...
</beans>

Now the SecuredObject's getSecuredData() can be annotated with @RolesAllowed annotation from JSR-250:

package com.habuma.expectations.springsecurity.intercept;
import javax.annotation.security.RolesAllowed;

public class SecuredObject {
   @RolesAllowed( {"ROLE_SECRET_AGENT"} )
   public String getSecuredData() {
      return "Top-Secret Data";
   }
}

This barely scratches the surface of the goodness offered by Spring Security 2.0. If you want to hear more about it, then make plans to attend one of the No-Fluff/Just-Stuff events coming up in Seattle (this coming weekend), Oklahoma City, and Dallas where I'll be presenting Spring Security 2.0 (among other topics).

Note that the above examples all require some additional Spring Security configuration, specifically an authentication provider. To keep things simple, I've used the following authentication provider configuration in my Spring XML:

<sec:authentication-provider>
  <sec:user-service>
    <sec:user password="password" name="cwalls" authorities="ROLE_SECRET_AGENT"/>
    <sec:user password="password" name="intruder" authorities="ROLE_ANONYMOUS"/>
  </sec:user-service>
</sec:authentication-provider>

For a real application, you'll no doubt want to choose a different authentication provider, such as <jdbc-authentication-provider> or <ldap-authentication-provider>

For the adventurous reader who wants a quick way to try this stuff out, you can check out my learning-tests from my Subversion repository at svn://svn.geekisp.com/habuma/trunk/expectations/SpringSecurity. If you can't access svn: for some reason (stupid firewalls), then you can download a zip file from http://spring.habuma.com/examples/SpringSecurityMethods.zip. There's a Maven 2 pom.xml file in there--run the "test" goal to see the tests in action.

A few weeks ago, I blogged about how the new <jdbc-user-service> in Spring 2.0 is hard-coded to a specific set of SQL for querying user information and authorities. This, in my opinion, effectively rendered <jdbc-user-service> useless for any application whose user details are kept in a schema that isn't what <jdbc-user-service> expects.

It was suggested by some that it's easy enough to configure a JdbcDaoImpl as a <bean> and wire it into <authentication-provider>. That's true...and since JdbcDaoImpl can be configured with custom SQL, it would solve my problem. Even so, I still argue that <jdbc-user-service> should either offer the same SQL customization or it should be removed from Spring 2.0's configuration schema.

After creating an issue (SEC-703), submitting a patch, asking everyone I met to vote for SEC-703, and waiting patiently, I've finally got my wish. As of today, SEC-703 has been closed with a resolution that adds new attributes to <jdbc-user-service> to allow custom SQL to be specified.

Many thanks to the 100 or so people I've spoken to at user groups in the last month for enduring my rant on SEC-703 and to the 4 people who actually voted for that issue. But mostly, thanks goes to Luke Taylor who committed the change that made this possible. When you download Spring Security 2.0, you'll be downloading a little bit of my code.

Speaking of Spring Security 2.0, it looks like a release is imminent. There are no more open issues and it appears that the 2.0.0 release has been "released" in JIRA. By the time you read this, it may already be available.

If you'd like to hear more about Spring Security 2.0 and how it is so much better than Acegi (not to mention how it will make a huge difference in the lives of thousands of fairies), I'll be presenting Spring Security 2.0 at the upcoming No-Fluff/Just-Stuff events in Seattle, Oklahoma City, and Dallas.

A Erik has mentioned on his blog, I gave a presentation on Spring MVC and Spring Security (with emphasis on the new stuff in Spring 2.5 and Spring Security 2.0) last night at the Spring Dallas User Group. What Erik didn't mention was where you can download the slides. So, if you're interested, here they are.

BTW, this presentation is actually a mashup of two other presentations that I'm working on. Neither presentation is yet complete enough to fill a full hour and a half, so I merged the two for last night's meeting. For the expanded versions, keep an eye on the No-Fluff/Just-Stuff schedule this year to see if I'll be presenting them near you.