Devoxx Day Two

I wanted to start with the apache wicket session which was cancelled. So I ended up in a google app engine session. Seems very nice to get a small/personal app up in there however because of the restrictions placed (which seem fair to me), you will run in to unexpected problems here and there. They demonstrated a SpringMVC, JSF2 and GWT user interface on top of a common spring bean service layer using a JDO DAO layer. I think the presented application is interesting as a starting point since they encountered and fixed a number of gotchas. It looks like of the three, SpringMVC gave the least problems.

I tested a couple of weeks ago Google App Engine and tried to run grails on it. Worked fine with some tweaks but I couldn't get my JRebel to work with it but this is getting worked on. Look at this page to see if your favorite framework works on it. Apache Wicket doesn't so I have to find something else to know what this Wicket stuff is about ...

Next session "SOA in practice" by Nicolai Josuttis, apparently he also has a book about the topic. From all code session to a no code session. Very very interesting session which also confirmed my suspicions on BPEL the previous day. It should only be used for backend processes, not when user interaction is needed. He really doesn't like BPEL (probably had to work with too long) and raised valid points that vendors won't tell you:

• You need to implement the services to be able to plug an play.
• Implementing error handling is hard and takes 80% of your workflow.
• It doesn't help you to handle your SLA (service level agreement)
• Converting from UML, BPMN, EPC or visio to BPEL may work but the result will not be readable.

But that was not what the talk was about. You should only use SOA if you need it because of

• distributed processes
• on heterogenous systems (using different technologies)
• with different owners.

and even then it will be hard. A large system that is tightly coupled may sound bad but loosely coupling and a lot of systems is complex. The gained flexibility comes at a price! Maintaining a landscape of systems instead of developing one system brings not only technical challenges but also organizational. You can't buy SOA!

After that he also talked about the SOA manifesto that he helped creating. While probably useful as communication instrument, it is too abstract for me.

Last sesion about "Gradle, a better way to build" or not because I left for the java monitor session which was quite interesting. A lot of garbage collector insights. A pity the session was so short but you can find the slides here. An interesting thing was that the server VM is faster than the client VM which starts up faster.
The gradle session I left because it seemed very complicated. I could as well use Ant which I know already instead of learning another complicated thing.