SpringOne in Antwerp: Day One.

My choice of topics today was fairly eclectic (if it’s possible to say that about such a niche conference). It started with a look at the [tag]Google Web Toolkit[/tag], continued on to [tag]Spring Web Flow[/tag], then to an introduction to the [tag]Service Component Architecture[/tag] standard. The day finished with a tour of [tag]Coherence[/tag] under the title of Data Grid, and wound down with an hour of Pragmatic [tag]SOA[/tag]. The standard of delivery was high in all cases, and I could easily spend a blog entry on each of them. But it’s late and I need to drink some [tag]beer[/tag] – ahem I mean get some sleep.


I’ll start the description of this talk with a question I asked Bram Smeets at the end: “Are you using this commercially?” The answer was yes. GWT is not a toy.

That said there are drawback and limitations, and it’s very important to use the framework correctly if it’s to be used at all.

Most of the talk was taken up with a presentation of GWT itself, which is very public already, we’ve blogged about it in the past, and I’m not going to repeat here in detail. One of the reasons that I went to this talk is because I’d like to invite Bram to come and talk to Java developers in Cork, as part of the planned DSI-sponsored it@cork Java conference. I think he would make a fine speaker – very technical – and would offer a nice comparison to the planned JSF discussion from Sun. But he’s getting married around then so we shall see.

There are some gotchas with the use of GWT which Bram covered at the outset, but which have remedial solutions – not optimal but workable. For example, to get over the fact that domain objects that are to be passed between client and server you need to implement an IsSerializable interface, Bram uses DTOs and a DtoConverter stage in the RPC stack. This will no longer be necessary in GWT 1.4, when it will be enough to implement the standard java.io.Serializable interface. Advocates of DTOs will not see any problem with this in any case. I’m not one of those advocates.

Amongst the many tips that Bram shared was the suggestion to define your own abstract AsyncCallback base class to deal with error results in a centralized way.

Spring integration with GWT is restricted to the server side and involves the use of the DispatcherServlet to route the RPC calls. Quite light.

The overall impression I was left with was that there is sufficient momentum behind GWT to have some of its more awkward corners taken off.

As an aside: Something that Bram said, almost as a throw-away comment, chimed with another point that was made earlier, in the keynote, by Rod Johnson. Bram said that there were too many frameworks in the AJAX space. Earlier Rod has pointed to Spring as following the Eclipse model where only one main survivor is left and competition now centres on things that plug into it (you could equally call it the Highlander model – there can only be one). In both cases, the point was that competition is good but only for a while. Eventually the development community needs things to settle around a strong, adaptable but simple solution. It’s still too early to say if this will happen in the presentation layer, and if so, who will win out.

Spring Web Flow

This was the first of a two-part presentation by Erwin Vervaet and was pitched as an introduction. This was perfect for me. We’re not using this framework yet in DSI, but I can see this (or something like it) being used alongside many of the presentation tier frameworks that we will be using.

The problems that Spring Web Flow addresses are the following:
Navigation Flow Control
State Management

These are issues which arise when you use a stateless protocol like HTTP, which is perfect for ‘free browsing’, for a system that is composed of permitted ‘conversations’ through views.

Web Flow

“allows developers to model user actions as high level modules calls flows…a strong solution to enforcing navigation rules and managing application state.”

Erwin got to the code very quickly and showed a simple ToDo application. We stepped into creating a Create Todo flow, and it became quickly clear that flows correspond directly with State Transition Diagrams that you might arrive at as part of your requirements gathering, with each state corresponding to a view. The STD in question was simple enough – three states and three transitions – and when modeled in XML configuration files it was still easy to get to grips with. For larger examples I’m sure this wouldn’t be the case, but luckily the latest version of [tag]Spring IDE[/tag] has a graphical editor for the job.

As well as the basics of the transitions, Erwin also configured the states and some transitions to perform data binding with the related view’s form (remember that each state has an associated view). In this introduction, SpringMVC was being used. It wasn’t clear to me how the references to the forms/view data would be made if alternatives to SpringMVC (such as Struts or JSF) were being used, but we were assured that Web Flow can indeed deal with these alternatives.

In answer to a question on whether Web Flow was another BPEL, Erwin replied that Web Flow is “not a workflow engine but a pageflow engine”. That is all it aims to be, and it appears to do it quite nicely. It manages all the potential mistakes and hacks of users by dealing with forward and back button pushes, and hacked URLs, in the context of the current state of the flow. Nothing is permitted that isn’t explicitly allowed for in the STD.

I couldn’t hang round for the deeper dive of the second session but I’ll be keeping an eye out for it on Parlays.com in August. By the way – Erwin was a superb coding presenter – he didn’t have any ‘here’s one I made earlier’ tricks – he brought us through the entire process from scratch. It felt like the real thing.

Service Component Architecture and Spring

Adrian’s skills as a speaker were clear to us from his trip last year to Cork, where he educated local developers in the ways of AOP and its many applications. As CTO of i21 the scope of his work is now wider than just AOP, and this talk covered something dear to our hearts in DSI: SOA – but under the very particular auspices of something called Service Component Architecture.

SCA is a specification from Open Service Oriented Architecture. (I have to confess that I knew nothing about this specification and thought I was attending a general talk of service oriented architecture.) The OSOA’s objectives in this specification were

  1. Language neutral programming model
  2. Exploit SOA characteristics and benefits.

SCA provides a model for

  1. Creating service components
  2. Assembling service components into a business solution.

In Spring terms, an analogy would be the definition of beans and their subsequent wiring up.

It has four key parts:

  1. Assembly Model (components, composites, wiring)
  2. Policy Framework (analogous to Spring proxies and AOP)
  3. Client and Implementation Model (language support – Java, BPEL, C++, Spring)
  4. Bindings (access mechanisms – how do I get access to the services, what protocols)

At this point in the proceedings, we were treated (?) to diagrams employing SCA-specific notations to describe the modeling and wiring of components. There were colour-coded chevrons and diagrams that reminded me of Rational Rose for Realtime (an old memory) with properties being ‘promoted’ from models up to their parent composites. Were it not for Adrian’s well-pitched tone of irony, I might have felt the need to bale out. This was not what I had been expecting. It got worse: behind the diagrams was an XML descriptor. It became clear that at the heart of this spec lies an attempt to define any SOA system – implemented using any of the client and Model Implementation choices from above – and wired together into complete systems (or more comprehensive services) with these descriptors. Is it just me or have we all been here before? Perhaps I’m being too cynical.

Every specification needs its slew of implementations, and SCA is no exception. Many are opensource:Tuscany, Eclipse SOA Tools Platform Project, Newton.

I asked where OSGi fitted in with all of this? Adrian replied that there was probably an [tag]OSGi[/tag] Client and Implementation Model in the offing. I would have thought that OSGi’s ambitions were greater than to be part of Yet Another Specification. I’m looking forward to seeing where OSGi and SCA are headed – collaboration or confrontation.

Data Grids

After lunch, where I recharged both myself and the laptop, it was time for something completely different, and surprisingly simple. Given the title, I had braced myself for new programming paradigms, and brain-bruising rewiring of established architectures. What I found (and I’m happy to summarize the hour into one sentence) was a very clever more-than-a-cache system for sharing massively scalable data.

OK – another few sentences then. Image a Map (yeah – as in java.util.Map) into which you put data that you are going to be operating on. Imagine that this map is accessible from other JVMs, and that more and more JVMs can be transparently added as more and more processing power is required and available. Imagine further that you can tell these multiple JVMs how to configure themselves into one of many choices of cluster topology (based on what kind of operations you are principally going to apply to your data). Now while you’re at it, imagine a nice clean write-behind algorithm to gather up all your changes that have been made to the Map into suitable batch sizes and send them to an underlying persistence layer. Allow also for the possibility that both .NET and Java processes can use these Maps at the same time. And finally, if any of the JVMs fails, the cluster repairs itself. All this without complicating the programming model for the developer beyond the humble Map. That’s Coherence. I loved it.

At the start of the talk, the light was temporarily blocked out as the unmistakable figure of Aleks Seovic passed by and then sat down next to me. I reached up and tapped him on the knee. To avoid any confusion I hoisted up my name-badge for him to examine (my voice doesn’t carry that far). Recognition. Aleks came to Cork a few months back to give a Spring.NET course to a number of our developers. It was during that visit that we agreed to begin a sustainable collaboration between DSI and Spring.NET – DSI would dedicate resources towards the Spring.NET codebase. I took the opportunity to talk to him about where Spring.NET is going. But more on that tomorrow. (I also found out that Aleks’ company in Serbia was central to the development of Coherence Data Grid for .NET.)

And finally (is anyone still reading? I’m given up some beer time – Belgian beer at that – to get this written down!) my [tag]SpringOne[/tag] continued with…

Pragmatic SOA. Substance not Hype.

Arjen Poutsma’s entertainingly cynical history of faltered attempts to reuse down the years, and treatment of the current state of the latest attempt, SOA, would have been worth the hour even if he had done just that: entertained. But he went a step further by making a clear and refreshing statement about SOA that I think is spot on.

He began by pointing out that SOA was the buzzword of 2006 most despised by engineers (pipping Web 2.0). How did we get here?

We got here, of course, as part of our long and worthy attempts to reuse. Arjen reminded the audience of recent (90’s onwards) developments towards this holy grail, from ActiveX to CORBA/EJB and on to SOA itself. He ridiculed the inflated complexity and competing versions of WS-* but tempered this with the observations that there is some value in some of these standards. The inevitable comparison between REST and SOAP was taken out and examined, and though Arjen seemed to be more favourably disposed towards REST, he refused to come down on one side or the other (to the annoyance of some of the audience I spoke to afterwards). Overused ESBs and all-powerful tools that are being sold to paper over cracked ideas have been another feature of recent times in the world of code reuse, according to Arjen.

And then, in the dying minutes, he explained why SOA is so despised by techies. Is is because it has nothing to do with us. It’s not about the technology.

SOA, says Arjen, is all about business, and about the soft skills of talking to the business experts, seeing the big picture, seeing the system in terms of other systems and other platforms. And then putting something together that serves that business – whatever the technology might be.

I found this quite insightful, and if I haven’t brought that across it because it’s too late now to go for a beer and I’m too cross for any more words.

Well, perhaps more tomorrow.

– brendan

  1. Business Management Process Workflow

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: