Keynote title: The Changing Nature of Enterprise Java Application Development
Speaker: Adrian Colyer CTO SpringSource

Adrian – perhaps principally of AspectJ fame – begins by stating that we live interesting times and that “seeds of change” are present… which leads naturally enough to a rain-forest metaphor.

To cut a long story short: New stuff starts out as a seed, some of this stuff rises and becomes well established… whereas much of it dies out at some point on the way up. Assuming my interpretation of the symbolism is on the mark.

A picture of the sun setting over the rainforest… represents Sun “moving on”. And the metaphor continues… but strangely I find my interest in it is waning…

Adrian cites Java 7′s improved for support new languages, plus the proliferation of new languages (Groovy, Scala, Erlang, JRuby, Clojure, Jython, Ruby) as one of the significant new developments. And questions which one of the new languages will dominate over the coming years…

And initially picks Groovy, Clojure, JRuby and Scala because they are designed to work on a JVM.

A comparison of Java versus Groovy ensues, with emphasis on Groovy conciseness.

The challenges posed by concurrency are mentioned, and Clojure’s “immutability by default” and Scala’s built-in actor model are cited as a ways of addressing them.

The speaker drops Clojure from his list of candidates because he feels the Lisp-inspired syntax of Clojure too radical a leap from Java’s syntax and the C-legacy/culture.

Eventually he gives Groovy the edge because of its super-tight two-way integration with Java… and then is kind enough to admit his (or his company’s) bias in this matter.

Next up: A monolog on the various application frameworks, and acknowledges both the power and the complexity of the new programming environment. He recalls the classic terminal application to reinforce the point that times have changed radically. Can’t disagree with that!

The final message: “The future is coming!” which for me definitely means a very strong coffee.

Conclusion: A well delivered presentation, rather too drawn out and too long on metaphors. Nevertheless, an opportunity to reflect a bit about the strange, changing ocean in which we IT geeks are immersed. Hey… I wonder if I can develop this metaphor and use it in my next presentation?

Now I’ll be the first to admit that I’ve had my issues with Java-the-language over the years. When it came to the lack of support for Design by Contract, for example, I recall thinking to myself back in the late 90s “if I ever meet James Gosling personally, I’m gonna give him a piece of my mind!”

Well, at long last I did finally get a chance to meet James “the father of Java” Gosling (which I guess makes him the grandfather of Groovy, Scale, JRuby and subsequently the great grandfather of myriad other life-changing innovations.) And guess what… I did not give him a piece of my mind.

This was because immediately following the Java Rookie event JG was simply too forthcoming, too attentive and too downright chilled when I approached him with a view to chatting about matters more constructive than simply what Java lacks or cannot do.

Here I am in chat mode with The Man:

Here are some other members of the Canoo/Jazoon’09 team in completely natural poses:

So thanks James for gracing Jazoon’09 with your presence. You made a great conference even greater. We wish you a pleasant journey home!

Session title: JavaFX/Android: Competing technologies or ideal partnership?
Speakers: Andreas Hölzl (Canoo), Mike Mannion (Canoo)

Two geeks discussed Mobile/RIA stuff over coffee and while Mike played the part the JavaFX-guy, Andreas was the Android-man in this short talk. 

 
Mike first talks about the JavaFX Mobile architecture, which builds on JavaME. The JavaFX API available to tje JavaFX Mobile developer is a subset of the whole JavaFX API available on the desktop. 

Andreas goes on to present the more sophisticated Android architecture, which first of all has an applicaton framework while we see a big hole at this level on the JavaFX side (see slide).

Mike agrees that the application framework is missing on JavaFX. He mentions that both he and Andreas have done iPhone development in which the the importance of the iPhone’s app framework plays a significant role in achieving look and feel consistency across applications.

On the other hand, Mike notes, JavaFX has a very impressive designer-developer workflow, which enables you to transfer static Photoshop or Illustrator design to the netbeans environment. JavaFX can subsequently be used to add functionality to the design. Andreas points out Android’s architecture also permits one person to work on the UI design (working with an XML document) whilst another person works on the functionality (Java code).

The two would-be actors raise the question of how one might possibly get a JavaFX program running onthe Android platform. Two technical scenarios are described, one involving a cross-compiler (cross-compiling JavaFX Script to the Android-compatible Java code), the second involving a port of the JavaFX runtime. The moral of this story is that no matter how you look at it, getting JavaFX to run on Android would be technically challenging. Android was designed from the ground up with its own intentions and philosophy. It would be miraculous if JavaFX would simply work on top of this.

A poll of the audience at the end of the talk reveals that most of the audience thinks that Android will win over JavaFX mobile (in the market place) because of it’s mature and already commercially established architecture.

Session title: Convenient Disconnected Mode for your Rich Java Application
Speakers: David Bernhard und Philipp Oser, ELCA

Szenario: Rich Java Client and app on app server -> work offline without the app on the server. Offline with part of data and syncronize

Working offline is wished for in a lot of client – server applications. This talk presents a possilbe solution for this problem.

The hibernate offliner needs a local database and a local persistence framework (here hibernate, but not necessarily) on the client. On the server side two additional db tables are needed to store the mapping information for the remote and local objects.

Basically the hibernate offliner works as follows:
To start working offline, the user extracts some part of the data from the database and transfers it to the local database on the client.

In this process the mapping information is stored on the remote database. It consists of the remote key and the local key.
After working offline and going online again this data needs to be synchronized. That’s done by fetching the original remote key with the local key and then insert the data remotely. So for the remote db it’s the same thing as working without offliner.

Object graphs are a bit more complicated they use a graphwalker to make sure that a parent can only be offlined if all of its children are correctly processed.

Offliner does this by first checking the changes on the client side and insert them into the real database. Then it checks for changes on the server database. What happens to conflicts?

To identify conflicts version info and optimistic locking is used. When conflicts occur all conflicts are returned. Object graphs can only be processed if no child has a conflict. Conflicts need to be resolved manually by the user. Similar to well known version controls. Force operations exist.

Limitation:

• works only with fat clients -> application logic needs to be on the client
• only a prototype not ripe
• two set of keys (e.g. positive and negative)
• not all of hibernate features are available
• Offliner cannot guess pointers to the offlined objects

Conclusion: Interesting approach but the restriction to fat clients is kind of disappointing.

Session title: Securing AJAX Applications
Speakers: Moritz Kuhn, Philipp Färber – AdNovum Informatik AG

The subtitle of this talk is: “New threats and defenses?” Does the question mark imply that they will question the existence of new threats?

Speaker Moritz begins by citing some interesting attacks which took place recently, one of which took down myspace for a period of time – apparently using a simple JavaScript payload.

Proceeds to explain the “Same Origin” policy, which is designed to prevent a JS script in one frame from accessing the DOM in another frame. Note that this is enforced at the Window’s border. However, the rules are very complex and apply to cookies, XHR… and several other areas.

XMLHttpRequest has a stricter security model, which is often a pain for developers because it is inflexible, yet it is too loose for engineers because it is ambiguous.

Cross-Site Scripting (XSS) is an attack which exploits ambiguity in Same Origin rules.

Cross-Site Request Forgery (CSRF) when the victim is logged into an authenticated web application and his browser stores a session cookie for the app. The attackers web page makes the victim’s browser send a request to the vulnerable web app. The victim’s browser appends the cookie to the end of his request.

Speaker demos these attacks by showing how an attacking app can insert JavaScript code into a calendar; points out that the code could contain anything… reading email for example. Scary stuff!

How to combat these threats? Philipp takes to the stage…

Begins by contrasting classic and AJAX architectures, which increases awareness of the technical interactions involved between the parties.

Looking from the server-side, need to consider that the attack-surface is increased in an AJAX architecture e.g. via exposed services, protocols, sessions, domains. Also: code contains call params and service URLs. Finally, there are concurrency issues.

From the client side, new attacks are around like JSON hijacking and DOM-based XSS with URl fragments.

A final observation from the speaker is that one of the consequences of all this is that testing is getting harder. Exhaustive testing is obviously out of the question.

Counter-measures:

Input validation, output encoding, service hardening. Retain awareness of the technologies you are using. Defensive design involves avoiding mashup-like services, KISS and using separate domains for public and private data. Points out the fact that the Google domain strategy is open to XSS attacks.

Some AJAX-specific counter-measures: Know the output’s insertion context (don’t allow angled brackets in the output, for example!); Ensure no sensitive data is sent to the client (be aware what your frameworks are sending!); Prefix all JSON replies e.g. ‘while(1); {“x”:”y”}’; Add a random number to a response and match it up when the next request comes in. This can’t be predicted in advance by an attacker (I like this!); Validate services responses – also in the client; Understand and use a secure framework e.g. GWT, prototype, jQuery…

Rigorous testing is obviously a must; Designing for security/testing upfront is a must; Test individual AJAX features individually; Simulate malicious requests…

Conclusion: AJAX means: Old threats + new threats + higher complexity = bad news.

Summary: I never cease to be shocked by the degree of details and complexity which the developer has to be acquainted with in order to make an AJAX-based app secure. The reality of AJAX development is that in most projects the developer will be focussed on delivering the the core business requirements and getting the look and feel right. With this focus security holes are virtually inevitably.

A very worthwhile presentation!