Musings of a SpringOne 2009 Attendee – Day 4

By Sudahukar Ramasamy | October 20, 2009 |

This is the last and final part on my SpringOne 2009 experience. This post summarizes the sessions I attended from day 4 and wraps up with a summary of my take aways.

Session: OSGi and Groovy Jump Start

The presentation started with a 5 minute youtube video preview which I thought was pretty innovative.

The first half was around what is OSGi, some of which I’ve had experience with. I did pick up on a few key concepts that I didn’t know i wasn’t communicating earlier in my own presentations on OSGi.

We covered how a groovy POGO has groovy types in the public API. So if your groovy bundle has the groovylib in it’s classpath then it has to export the groovy package. Also when using Groovy in OSGi, if possible use POJOs for your applications type system since POGOs force you to expose couple groovy types in the bundle’s API.

The examples were done using gradle and this was my first live example of using gradle. This is a key benefit of conferences – being exposed to technologies you may otherwise not have the time to take a peek at.

I liked how the presenter took the path of not making things look complex but rather simplifying the concepts. He did this with concepts such as the OSGi bundle lifecycle.

Some of the tools covered in this session were:

bnd to create a groovy manifest
osgi bundle for gradle uses bnd
junit4osgi

Session: Expand your business with Groovy - Case Study

This session was a case study on how a monolithic application was extended to provide customizations using groovy. A major customer had approached HypericQ wanting a custom dashboard.

HypericQ developed a architecture around attach point’s which are places within the UI where plugins can connect to.

Custom UI was provided by gsp templates for customer specific dashboards.

Groovy templates was used as the templating framework that allowed partners to build their own using GSP pages.

A Web Services API was provided as part of the core platform that enabled several benefits:

hqapi command line interaction
allows integration testing of the application
embedding a groovy console inside the application
console gives you a HQL way to query the domain and not worry about the end customers database environment

The talk was an interesting exercise in how a dynamic plugin architecture could be implemented. Groovy categories was heavily used to enable this.

Session: Re-factoring a Spring Application for SOA using Spring technologies in 40 min

The current focus of SOA is really software architecture. SOA is neither static nor predictable. The architectural pattern of any application must be reflective of the business. SOA is preparing the stuff that is critical to your business to stand the test of time.

Architecture involves the courage to be wrong while minimizing the impact of being wrong. It is about making educated decisions between speed and perfection. The longer it takes to deliver the software the higher the partner’s expectations of that software is.

The foundation of SOA is highly cohesive, loosely coupled modules. One must practice

strategy first programming
process life-cycle dynamics
process collaboration
loose coupling promotes a network based architecture over a hierarchical one - composition over inheritance

SOA and OSGi enable embracing change by making versioning a runtime concept.

There is an argument to be made for deploying a process as a whole in BPEL. But what about flexible orchestration via simple messaging. We were given the American football analogy. Each play is scripted, but between plays we need to adjust strategy to meet the overall goal.

Modern event driven architecture was mentioned as a composite process linked together in a linear fashion through the use of rule based pathing.

The second half of this talk was the Spring booking demo from Spring Web Flow project. There are 3 OSGi bundles:

war bundle
service bundle
datasource bundle

The demo was using STS and it’s DM Server tooling. The entire development workflow was very seamless with SpringSource having done an awesome job of the tooling.

We saw an example of a transparent failover. So there is a need to take down the primary database for maintenance work without taking the application down. A backup datasource bundle is started and the primary datasource bundle is stopped. The datasource bundle is a simple datasource definition and an osgi service with ranking. Because of a higher rank the backup datasource bundle takes precedence and the primary datasource bundle can be safely stopped. Bundles can also take advantage of filtering besides ranking.

Spring Integration builds on pipes and filters. You can expose OSGi services as pipes. It provides the ability to change the behavior of a modularized application by changing how the modules are hooked up in the XML as opposed to modifying source code or in cases where the source code is not available.