This is the last and final part on my SpringOne 2009 experience. It’s late catching up to the 3 earlier posts but it’s here now. This post summarizes the sessions I attended from day 4 and wraps up with a summary of my take aways. If you want to catch up here are the three earlier posts:
- Musings of a SpringOne 2009 Attendee Day 1
- Musings of a SpringOne 2009 Attendee Day 2
- Musings of a SpringOne 2009 Attendee Day 3
Read on for day 4.
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
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 clients 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.
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 client’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 precendence 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.
Conference Wrap Up
Here are my key take aways:
- It is time for Grails
- Need to investigate Spring Faces
- Spring Web Flow
- Spring Integration
- Spring DM Server
Overall it was a very productive conference and I would recommend it for anyone looking to attend it next year.