& Continuous Learning

Running a day late on my posts. Here's day two (yesterday)

Session: Grails Quick Start - David Klien

David walked through the creation of a Grails web application to track a JUG's meeting schedule. I liked his presentation style or maybe because the room wasn't very crowded things just registered better. Picked up a few tips such as the Bootstrap class. Grails still has a ways to go in the eclipse tooling. It would've been nice to have been able to File --> New Project and follow along. Too bad IntelliJIDEA CE doesn't support grails though there has been plenty of buzz on the latest STS. Downloading this right now. Only 3 more hours for the download to complete!

I think I'm beginning to dig duck typing. All in all the presentation encouraged me to put my head down and hammer out a sample app to start building some grails knowledge. More homework!

Session: XML and Web Services with Groovy - Paul King

XMLParser and XMLSlurper were covered. I'd attended a similar talk by Scott Davis at NFJS. So I wasn't all oo-ahh about it. But I did pick up on a few things. Like the XMLSlurper's lazy evaluation. Apparently lazy evaluation is more pervasive in Groovy and you see it in sql result set processing as well. This actually makes groovy faster than Java in these use cases. We also saw how existing Java XML libraries such as DOM4J can be used within groovy.

For the web service half GroovyWS was shown. In literally three lines of code you can standup a POJO/POGO as a web service endpoint. Not likely to be used in production but this shows how you can easily take an existing Spring bean and expose it's responsibilities as a web service for a proof of concept. A simple SOAP webservice consumer was shown in 4 lines too. Also learnt that Synapse and ServiceMix have groovy support built into them.

Session: Simplifying Java Server Faces Development with Spring Faces - Jeremy Grelle

I probably got most out of this presentation. At times I felt like Jeremy was speaking directly to me. My day job involves JSF 1.2 and Jeremy was pointing out all the (anti) patterns we employ in order to overcome the limitations of JSF 1.2.

He pointed out two ways to integrate JSF with Spring

1. JSF centric - where Spring simply replaces the managed bean functionality of JSF. With the caveat that if you need to dynamically inject a Spring bean it is not possible using Spring 2.5. In those situations you'll need to revert to JSF managed beans. You could still use the JSF managed beans for view action classes and inject Spring service beans into the action classes. The JSF centric approach is the one I'm familiar with.
2. The Spring centric on the other hand does all of the following:
   1. JSF plugs into Spring as the View layer
   2. Does not use the FacesServlet
   3. Spring MVC + Web Flow together replace the
   • managed bean provider
   • request dispatcher
   • navigation handler
   • state manager

Spring Web Flow provides the conversation scope (more than Request but less than Session scope) that is sorely missing in JSF.

In the Spring centric approach one would use the Spring MVC DispatcherServlet for Controllers for stateless iterations (basically selecting JSF views for rendering) and Spring Web Flow for stateful interactions.

He demonstrated what I think was JSF 2.0 Custom components. And how one can wrap them with Spring Faces components to do client side validation etc. The Spring Faces components wrap Dojo under the hood and this same technique can be used by us to wrap other Dojo components that are not already available in Spring Faces.

Another issue we run into frequently in JSF 1.2 is being able to initialize a view. The framework does not provide a built-in way to do this. Spring Web Flow has a clean way to do this using on-Render in the flow definition. Web flow also has viewScope allowing you to do multiple interactions with the same page without having to go back to the database.

The big benefit of Spring Faces is it's integration with Web Flow. And Web Flow makes the restarts due to changes in faces config a thing of the past.

There was a slide that compared the pet clinic application built using Spring Faces and pure JSF. The Spring Faces application used 1/3rd the lines of code -- which was believable considering how the faces config was completely trimmed and how a lot of the workaround code was eliminated. Some of the new features requires JSF 2.0.

What about Seam? Not sure if and how Seam would work in a Spring web stack.

Session: Grails Security - Ken Sipe

This session covered SQL injection attacks and XSS attacks. Made me wonder how many of us building applications that live behind the firewall really code for this. Ken also showed examples of how an enterprising hacker can discover the data structure of your application using SQL injection. O/R frameworks solve most of the SQL injection problems but apparently there are edge cases where these frameworks still spit out un-parameterized queries and how we need to always verify the SQL being generated. Another question about input validation and what is it that you are validating. This is still a hazy area and there was no definitive answer on this. Also Stories and Abuse Stories -- are we writing code that prevents the user from breaking (nicer word for hacking?) the application? Does this need to be part of the story acceptance criteria.

We then got to look at security in Grails and how we need to add the html codec in the Config.groovy to escape out the HTML.

grails.views.default.codec = "html" in /conf/Config.groovy.

Ken mentioned the Command Object and treating the interaction with the data store as different from the interaction with the web. We then looked at Cross Field validation in Groovy which was pretty sweet.

It was mentioned that we should never show error pages to users which to me makes absolute sense in a public facing web application. But are there internal applications that we may need to expose the error message to the end user -- such as when we cannot duplicate the issue in the  support or development environments and it is a fairly complex interaction that is quicker to have the user send you the stack trace or walk you through the steps to reproduce the issue. We are trading security for ease of troubleshooting. How big a risk is this in internal apps?

Ken said something interesting about handling session riding attacks -- upon login expire the newly authenticated session and create a new one based on the expired session. For requests that are highly sensitive, using encrypted tokens with a timeout. So if the following request doesn't provide the token and doesn't meet the time expectation then you can invalidate it.

Few resources that were mentioned:

1. Spring security for Grails (SecurityConfig.groovy)
2. Apache Shiro
3. keylength.org
4. Writing Secure Code - best book on security as per Ken (believe it or not from Microsoft press)
5. Webgoat - learning tool to learn about securing Java EE applications. This looks like something I need to check out. More homework again!
6. EASPI from owasp attempts to solve the security concern at the framework level.

Case Study: RESTful Web Services at Orbitz - Alex Antonov

Alex talked about solving the problem of management of shared, versioned dependencies with serializable objects in a highly distributed environment. And the pain involved in keeping about 60 to 70 systems in sync during upgrades.

The original maze of systems were implemented in JINI. But since Sun is no longer behind JINI and JINI is no longer evolving they have had to ditch it. They actually won an award for their use of JINI. But they have migrated to a REST based architecture using Google Protocol Buffers for the messages across the wire instead of XML or JSON. I should  have paid attention during Octavian's protocol buffers presentation! So protocol buffers is a substitution for java serialization. It is 7 to 10 times faster than JSON and even faster than JINI/JERI.

Protocol buffers provides transparent versioning where if a message needs to flow through System A --> System B --> System C, you can upgrade the message structure (up to a certain extent) in System A and  System C and not have to modify System B. Protocol buffers lets connected systems mesh both backwards and forwards at the joints without the developer having to put in any effort.

We were then introduced to REST API best practices. Didn't see much new stuff that I hadn't seen before. Speaks for REST which is supposed to be simple with a few guiding principles. One thing I did learn about writing REST APIs was to use query strings for optional filtering. Another was to let the client define what message format they will accept via the Accept header. You can then use plugins for protocol buffers to send down the message in the requested format.

TECHNICAL KEYNOTE - Adrian Colyer

Adrian Coyler's keynote started of very entertaining when he walked across the stage with just the handle of his new roll-on bag. Story about how his luggage got ripped out and disappeared on his way to SpringOne. We heard about some of the new things in Spring. But he moved quickly to showing SpringSource's last acquisition, Crowd Foundry and it's capabilities. Having seen Google's App Engine before I wasn't very impressed. Essentially Crowd Foundry provides a developer centric way to deploy Java applications on Amazon EC2 including a plugin for Eclipse (or does this require STS?).

VMware then took over explaining their technology blueprint that leverages Spring tc server running in virtualized environments. Looks like VMware which has till date been visible mostly in the infrastructure and operations space will soon be surfacing visualization and the cloud to developers. Some of the technologies that were showcased were:

1. vMotion
2. Dynamic Resource Scheduling

Interesting stuff. I later on learnt that on of the organizations that was implementing an enterprise OSGi application was using vMotion at the infrastructure layer for fail over.

Spring Core BOF

Spring ESB? More like Environment Specific Beans may be coming in a future release of Spring 3.x.This should eliminate the need to use environment placeholder configurers for environment specific beans. Learnt that spring-oxm can be used outside of the spring-ws.

Springbyexample was suggested as a useful resource for learning.

Wrap up

One of the best parts of this SpringOne conference is rubbing shoulders with guys who've written the books, written the code, and give talks about the technologies that we use. These guys literally sit around with the attendees and are there to geek out with us regular joes. I got the chance to meet Craig Walls and talk about OSGi and Venkat and pick his brain on functional languages. And of course there is the always helpful SpringSource team easily recognized by their "uniforms".

Looking forward to more. Also got my first re-tweet.