Conference host Christian Frei finished last the conference night with some thanks to everyone who doodled on the James Gosling campaign and for the Java Rookies. He noted that Jazoon ‘09 had 20% more visitors than 2008, which is not what one might expect under the current financial climate… but is certainly encouraging.

So three cheers for Jazoon ‘09! Three more cheers for Jazoon 2010!!!

Session title: Wuala Webstart – Launching a Java Application directly from a Website
Speakers: Luzius Meisser – Caleido AG / Wuala

Luzius describes Wuala (which I’ve never heard of until now) as an all for offline file-storage. The goal was to make this available in as many contexts as possible, and to get the app up and running as fast as possible, which resulted in them creating their own webstart implementation.

In the speaker’s implementation of webstart he demonstrates how the app starts before the complete app is loaded… which if I’m not mistaken is also possible in Java webstart.

The strategy: Load a trusted applet, copy loader.jar into a temp folder and run it. Now RCP exists as it’s own process and consequently survives browser closure…

On the server-side the apparently smart webstart server (the server counterpart to loader.jar) “learns” which classes are needed first and subsequently delivers the app faster and faster with time.

Some extremely wordy slides are shown which are impossible to read because Luzius is talking. To read or to listen? That is the question.

What I’m extracting from this mix of written and spoken words is that their webstart solution enables quicker downloads and updates than conventional Java webstart.

Summary: This short talk was a little confusing to follow until I realised that I was hearing about two technologies: (a) Wuala – the offline file storage solution; (b) The unique webstart implementation – which was developed in order to improve Wuala’s quality. Nevertheless, I found it quite interesting to learn of the existence of Wuala… 20 minutes well spent.

Session title: Agile and Secure; Can we do Both?
Speakers: Jason Li & Jerry Hoff, Aspect Security

 Goal: To try to get developers to think about security early on in the development process.

Jason begins with a brief description of a common security flaw (in AJAX apps at least) XSS, which typically involves replacing regular text with a malicious piece of JavaScript. Example attack: The JS steals the end-user’s cookie by querying the DOM. A cross-site request forgery might subsequently be mounted by using the stolen cookie from within a new application context such as mail in order to delete all the users mail.

Another example – SQL injection – is when part of a SQL statement is replaced with a semi-colon followed by another statement e.g. DROP TABLE… which is obviously bad news.

With that whirlwind tour of web security… how to fix the process which results in such errors?

Speakers refer to the waterfall and explain how in each of the chunky phases activities include (or should include) security; security requirements, security design etc…

Speakers then argue that embellishing the highly iterative agile process in the same way as was done for waterfall is not practical. Blogger agrees… the granularity of the activities is too fine to permit the kinds of security analyses which are required. So what’s the solution?

They recommend…

Leveraging user stories

Prerequisite step: Ensure that all developers have received adequate security training

Another prerequisite step: Get management to fund this (gets a laugh!)
Alternatively: The OWASP Open Web Application Security Project is an organization providing resources which provides heaps of information on attacks points and solutions for these.

Leverage unit testing… and include security tests in the unit tests. This is obviously particularly effective in a continuous integration environment.

To speed up this process, use common security components such as those at Open Enterprise Security. Organizationally, this needs to be communicated across the development team(s).

Leverage and consolidate sprints… and ensure that all security stories are included in each sprint. For dealing with security stories which don’t fit into any particular sprint, run sprints that are focussed solely on security.

Great line (paraphrased): Web apps are a kind of “perfect storm” comprising a complex mixture of technologies, which results both in a large attack surface area as well as numerous subtle edge cases which make us more vulnerable.

Couldn’t agree more!!!

I found this talk excellent both stylistically and, more importantly, in terms of content. There are still voices out there which claim that agile in some way incompatible with quality. Talks like this should go some way to quell those remaining voices. Although the pair used AJAX’s inherent security vulnerabilities to highlight the necessity for a systematic approach to security in agile environments, much of what they recommend applies to any agile environment, whether it is creating AJAX applications or not.

To quote Monty Python: And now for something complete different.

William correctly notes that ABC is an accepted accounting practice.

Novel: A movie excerpt (THX1138). In the portrayed world every activity has a budget. (The chase ends when the chaser’s budget runs out.) William claims that the cloud will operate in an analogous manner to this world. Business will demand a breakdown of the activities which result in a given total cost. They will do this so they can subsequently optimize their resource usage and reduce costs.

The speaker describes (and seemingly accepts) the assumption that the lower the cost, the higher the efficiency. For example, if I can identify that my persistence costs are high I may choose an alternative persistence provider.

Blogger thinks: What a horrible world this would be, where cost becomes the sole consideration at the expense of all other quality attributes. What about uptime, response time, throughput? But come to think of it: Isn’t this how companies have been thinking ever since the bubble burst!? For that matter maybe this is how businesses have been thinking since the invention of Taylorism.

Continues… billing will be required on various levels: Across groups and aggregated services.

The Jinspired product “Probes” enables the monitoring of high-level entities e.g. user, house, washing machine etc. as opposed to simply methods, which is what most probing software focusses on. AspectJ is used to inject probes into code.

The Probes API is attempting to become a JSR. It’s certainly an incredibly powerful idea. It permits metering at various levels, groups and aggregated entities.

Summary
This whole business of costing everything and billing accordingly will likely appeal to today’s business mindset.
However, I (and I’m not alone) view ABC as a disastrous approach to improving the efficiency of the organization. This is not just because quality comprises a multitude of attributes (cost being just one of them), but – more fundamentally – because it turns out that organizational efficiency (the cloud, which forms part of the organization) is not in fact maximized by maximizing the efficiency of each individual element involved.

Counter-intuitive though it is, the quality and quantity of what your organization produces (products, services) is actually determined by a handful of constraints (bottlenecks.) ABC does not only not recognize this fact, it guarantees that quality and quantity will be less than their potential for a given set of resources. For more information read this.

Taylor claims to quote Niel Ford (prior keynote): “The best way to predict the future is to create it”… and doesn’t appear aware that he’s actually quoting Abraham Lincoln.

Taylor shows a couple of sites which exhibit the semantic web, one of which is Yahoo.

Then demo’s GeoSPARQl which enables semantic-style queries.

Then contrasts RDFa (a way of embedding RDF in XHTML) with Microformats, the latter being more complex to parse. With RDFa you can use a single format and hence require a single parser. With Microformats you a parser for each format.

Technically, everything identified by UDI, all data as canonical RDF, RDFS provides a schema, OWL provides additional meaning, SPARQL queries semantic web data, RDFa encodes RDF within XHTML.

Speaker then contrasts the RDF Triple Store vs. the Relational DB approaches to persisting semantic web data and notes that RDF is not XML but rather a way of structuring data as a directed graph. In this graph nodes are nouns; axes are verbs.

For the record: Triple = Subject, Verb, Object

The concepts in a semantic declaration can be represented sequentially using N3.

Similarly, the Java API JENA can also be used to model semantic relationships.

Using an inferencing engine new relationships can be derived automatically e.g. the explicitly declared relationship “Java is the primary topic of Jazoon” (after interence) automatically results in a new relationship “Jazoon has Java as the primary topic”. Pretty neat!

One of the major pain points with JENA: Having to create unique URL’s for every entity.

Taylor then describes a bean helper mechanism “JenaBean” (which I understand he created and is hosted at jenabean.googlecode.com) which (he claims) makes working with JENA somewhat easier.

Finally some words on tooling:
Triple stores: JENA, Sesame OpenRDF and Mulgara are all Java-based.
Java binding tools: JenaBean, Jastor, Owl2Java, Elmo.

During Q&A Taylor notes that triple store scalability is often a big issue; thinks that commercial solutions such as Oracle’s will not suffer from this problem.

From the perspective of a non-expert in Semantic web (i.e. myself), this was a valuable, quick introduction to a deep subject. Good stuff!

Links:
http://thesemanticweb.com
http://twitter.com/tcowan

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?

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!

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.

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.

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!