JAOO 2008, Tuesday

Today, at JAOO, I attended sessions related to architecture, REST, and network databases.

For the record, I should state that I have strong distaste for the software architecture / architect terms. In my opinion, software architecture is a muddy buzzword, just like the architect title seems to cover a suspiciously broad category of profiles (Buzzword manager? Very experienced developer? Software development project manager?) I remember a recruiting conference where a company was hiring graduates for architect positions; if the architect title can include people without any experience at all, then it's void of meaning. Anyways, one should be open minded, so I decided to attend selected talks on the architecture track.

Frank Buschmann held a talk about architecture reviews. Buschmann has several good points, although they would probably hold for just about any review situation. A point was that an architecture reviewer should keep a neutral approach towards the development team; this certainly sounds like a good idea. <rant>However, one of Frank's war stories included a tale of how he had once used a special strategy to convince a team that they should stop being critical about a development framework which had been forced upon them. Is that being neutral?</rant> Performing an architecture review sounds like a good way to ensure documentation which would probably never be written otherwise; for this reason alone, it's probably recommendable.

Another architecture talk was Top Ten Software Architecture Mistakes by Eoin Woods. Woods seems to subscribe to a definition of a software architect which is much akin to a project manager who knows about systems development. The talk was a very well performed live version of an article which Woods has written. Too bad there wasn't time for discussion (a general problem with JAOO's presentations); but it would probably have been hard to handle anyway -- the large room was packed with people.

Eberhard Wolff held a two-part talk about Java History and Outlook. I attended the second part, which was a rewarding experience. Wolff gave several examples of how community initiatives have outlived certain over-designed "official" J2EE components. He also made an interesting point of how the Java world's web application trends seem to move from MVC towards component-based desig -- while, conversely, .Net is currently sliding from component-based design towards MVC. Wolff's company is involved in the Spring framework; if I'm not mistaken, it sounds like the Java world may finally be cured of its "frameworkitis" and converging on Spring for modern Java-based web applications. Although Wolff obviously has a strong interest in Java, the talk wasn't an evangelism event: He pretty much declared Java dead on desktop. And he noted that while the JVM is doing fine, the Java language has trouble incorporating new, needed features; instead, JVM based languages like Scala may take over in the long run. Until then, Wolff strongly suggested adopting aspect oriented Java add-ons such as AspectJ and Spring AOP to gain more expressiveness.

I had the pleasure of attending two good talks about REpresentational State Transfer (REST): Ian Robinson's RESTful Enterprise Development and Stefan Tilkov's Successfully applying REST - Integration, Web-style.

Tilkov presented a rigorous definition of REST, but in a nutshell, REST is web services, done right, IMHO. Unlike over-designed and obese SOAP, REST doesn't abuse the HTTP protocol; instead, REST takes advantage of URLs, MIME-types and HTTP's basic operations/verbs (GET/HEAD, POST, PUT, DELETE) to offer surprisingly powerful, yet simple, solutions. Other HTTP features, like content negotiation and caching, make REST even stronger. (On a side note, Tilkov pointed out it's a shame that HTML doesn't allow PUT as a form method; HTML 5 should fix this, however.)

After a good, basic explanation of REST, Tilkov went through a number of patterns and anti-patterns which one should be aware of. One interesting suggestion was to always provide an HTML representation, in addition to the main MIME type of a URL. Sort of like Java's toString() method which can be performed on any object type. That way, it's easier to perform tests.

Robinson's talk described a case where a legacy system had been integrated with new solutions, using REST. Specifically, Atom and AtomPub were used to enable the new solutions to efficiently pull messages and data from the legacy system.

In the late afternoon, a number of BoF sessions were held.
I'm always skeptical when people propose something as "post-relational", keeping in mind how the relational databases actually took over after the network databases way back then. But one needs to have beliefs challenged sometimes, and I really like BoFs as a supplement to traditional talks. So I attended a BoF about graph databases, led by Emil Eifrem. Emil's company have created an embedded database for Java which is good at storing nodes and edges and traversing them. The database -- called Neo4j -- is allegedly the fastest of its kind in the Java world. Neo4j is GPLed and offers transactions; nice. I can certainly think of use cases for navigational databases, but I didn't leave the meeting with an urgent need to take a closer look at the product. It seems that there are no standards for network database queries, and most (all?) of them tie you to one particular development platform, leaving you to have to expose web services if other platforms must have access. At the least, I would see if recursive SQL could be used before I went for a network database.

JAOO 2008, Monday

This year, I'm attending JAOO -- for the first time. JAOO was once a Java-centric venue, but nowadays it has broader coverage.

Gregor Hohpe's The Internet as Platform: Programming the Cloud was about how systems developers should rethink their solution strategies. If scalability is of high priority, we need to give up luxuries, and give up some control:

• Luxuries would be traditional ACID and two-phase commit which are exchanged with compensation mechanisms, focus on idempotent operations, etc. Gregor presented a metaphor: In a coffee shop, asynchronous work processes result in high throughput, and error handling (if the customer didn't get the right coffee) is handled by retries. There are certainly many applications where relaxed consistency is acceptable; and there are settings where it's simply needed, for performance reasons. However, I feel that it's somewhat irrational to write off traditional ACID: ACID can make life of the systems developer much simpler due to not having to worry about sneaky compensation schemes. As not all applications need to be massively scalable, I believe that ACID should keep a prominent position in the systems developer's toolbox. Also: The World is not all about coffee shops: There are lots of applications where you can't just shrug and try again if something fails. (That said: I'm very sceptical of two-phase commits: I've seen several cases where it goes wrong and result in complicated situations.)
  
• Another of Gregor's points were about giving up control: As developers, we need to be more declarative and less imperative; that way, compilers and execution environments have a much better chance of parallelizing our work. This principle seems to be a general theme of this year's JAOO.
• Naturally, Gregor spent some time describing and demonstrating Google's exciting App Engine. App Engine is a cloud computing variant which works at a higher level than, for example, EC2: With App Engine, you dont' have to worry about operating system configuration, at the price of much fewer degrees of freedom. App Engine applications can "only" be written in a (large) subset of Python; certain cloud-unfriendly parts of Python have been cut away in order to ensure isolation between cloud guests. In addition to the Python language, App Engine developers can take advantage of a number of nice turn-key frameworks and APIs, e.g. for caching, authentication and data queries. Python is a great language, and cloud computing at a high level seems like a sensible idea, so I hope to get time to experiment with it at some point soon. My only grive about App Engine is: Why yet another query language? -- I'd much prefer a more SQL-like syntax.

Overall, Gregor's presentation was very well delivered and with interesting and thought-provoking statements.

Another presentation that I attended featured Guy Steele who gave an update on the progress of the Fortress programming language. Fortress is to be a programming language for high performance computing -- sort of Fortran++, although the syntax and the features of Fortress are rather different from Fortran. Fortress is designed with parallel execution in mind; e.g., many constructs are parallel by default, and if sequential execution is wanted, this has to be explicitly stated. Fortress is clearly aimed at the mathematically inclined programmers: It has operating overloading 'on steroids', in combination with tools to present source code with just about any glyph, such as greek letters. Note: Fortress is an imperative language; I was beginning to think that functional languages with minimal side effects would be the only way forward here.

Finally, I attended a panel discussion about cloud computing. The session wasn't as interesting as I had hoped for; maybe people were a bit tired in the afternoon. Discussion within the panel lacked energy, and there wasn't much audience involvement. I asked the panel to comment on two of the obstacles for cloud computing which I see. Where I work, we actually have some perfect use cases for cloud computing, in principle: Once a month, for example, we run some heavy computations which take several days and cause much stress, while at other times, the hardware is more or less idle. However, 1) what about security, i.e. protection of privacy sensible data, and 2) where is the business case if we need to upload ½ terabyte of data before the computations can start? My conclusion from the subsequent discussion was that we aren't going to be using EC2 for our computations any time soon, sadly. (Another unfortunate problem is that we rely heavily on SAS programs, and SAS Institute is notorious for virtualization-unfriendly licensing. But mayby SAS will wake up some day -- and perhaps even work with Amazon to provide access to SAS on EC2 nodes, charged by the hour?)

Apart from attending presentations, I had a chance to talk to a people in the exhibition area.

Among those were Red Hat which has recently opened a (small) office in Denmark.

I talked with people from the Danish National IT and Telecom Agency (ITST) about project-ideas for ITST's Software Exchange: I've recently had vague ideas about some identity management code which would be nice to have in the agency where I work; this might be in the scope of the Software Exchange. And I think that many public sector organizations would be able to make good use of a project charged with adding LDAP-based group definitions to per-directory access controls in Subversion.

Finally, I got a chance to shake hands with Stefan Tilkov. I recently listened to a podcast where Stefan did a great job of explaining the (very sound) ideas behind REST.