Rich Internet Applications (RIA)

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: Programming the Semantic Web with Java
Speaker: Taylor Cowan, Travelocity

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

Session title: A complete Tour of JSF 2.0
Speakers: Ed Burns – Sun Microsystems, Inc
Martin Marinschek – IRIAN Solutions

My interest in this talk is simple to explain: I used JSF in a really cool project last year, and found it cable but wanting in a number of respects. Lets see if the problems have been addressed…

The speakers begin with quite a few words about how the JSR was the result of a community effort. Then note that JSF 2.0 doubles the scope and integrates Facelets.
 

And the new features are…

1. Composite components. To a large extent the philosophy is the same as for rails with pay as you go complexity. Goal was to enable true abstractions. Makes heavy use of naming conventions to reduce verbosity. Composite components builds on top of resources and facelets. Nice to know: Mojarra supports Groovy.
2. AJAX support inspired by RichFaces, IceFaces, DynamicFaces, ADF Faces. Enables AJAX elements to be specified decleratively or programmatically.
3. Partial state saving. Biggest problem for performance to-date was the size of the state. Everything was a state and every request was a post. Pre-view state size is now 25% less than prior to 2.0.
4. View parameters. Inspired by Page Parameters from Jboss Seam. Provides a way to map requests parameters to special components within the view. Reduces the need to redeclare all the params across all the pages in the app. I had this problem in the aforementioned app and am glad to hear this issue has been addressed!!!
5. System Events. Inspired by Dtrace, influenced by JSFTemplating. This is a publish/subscribe event bus for the JSF app. A suite of events is provided. The list may be extended.
6. Resources mechanism is now standardised. Separate Filter or Servlet is now no longer necessary. Resources are now logically related to components. Full “library” support (whatever that means), I18N, versioning,
7. Behaviours enabled you to attach a behaviour to a component in a way which I didn’t quite understand.
8. Navigation enables pages to be bookmarked. Uses the View Parameters feature to ensure params are validated before rendering the page. Implicit Navigation enables pages to be bookmarked.
9. Exception Handler enables a single point of failure handling to be defined for a given app.
10. Validation is integrated with JSR303 Bean Validation
11. New Scopes have been defined: “conversation” (enables wizard-type functionality); “Flash” inspired by Ruby on Rails, which is used in Master-Detail situations; …
12. FacesConcext used during startup/shutdown eases the business of keeping things tidy.

I may have missed one or two points during this rather information-intense session. Nevertheless interesting stuff. Big take-home: JSF2.0 appears far easier to use than its predecessor. It’s also much bigger.

Conclusion: Valuable information, competently presented.

Having been asked 2-3 times at Jazoon about my JSF experience. I now have the impression that interest in JSF is pretty high – and growing. I’d have to go back and look at my notes about the project to see what we could have done better using these new features.

Title: Java SE and JavaFX RoadMap
Speaker: Danny Coward, Chief Architect, Client Software

Danny begins be showing the JavaFX roadmap…

Towards the end of the timeline: “JavaFX.next”
What on Earth could that mean?
In any case: JDK 7 release due early 2010.

Top 5 JDK SE 7 features

1: Modularity
Long overdue, the current JRE is around 14MB and contains a wide range of APIs. The average app only requires a small proportion of these. It also increases startup time.
Danny points out a number of weaknesses in the CLASSPATH concept. This will apparently be addressed by a low-level modularilty system entitled Jigsaw.
http://openjdk.java.net/projects/jigsaw/jcp.prg/en/jsr/detail?id=294
The concept externalizes the package depenencies to a module file… which reminds me of Eiffel’s solution to this issue which is donkeys years old.

2: Broadening the JVM to accelerate runtimes
DaVinci Project should result in a new bytecode model, which enables dynamic invocation, lightweight method handles and a variety of other optimizations.
http://openjdk.java.net/projects/mlvm

3: Java Language Additions
Project coin will result in a few small language enhancements:
http://openjdk.java.net/projects/coin
The switch statement will work with Strings.
Multiple Exception handling
catch (final IOException | ServletException e)

Improved type interence will remove the need to double-declare generics so:
List l = new ArrayList()
Becomes:
List l = new ArrayList ()

Elvis operator eliminates a significant cause of Java’s verbosity:
String s = mayBeNull?.toString() ?: “nothing”;

Integer ival = …
int i = ival ?: -1; // will be set if currently null

Must confess, this is not what I understand by the Elvis operator, but it looks useful nevertheless.

4: Four new I/O APIs
These include: New filesystem API, File notifications, Directory operations, Asynchronous I/O. The latter permits an IO task to be defined using a Future, the Future delivering the result at a later point in time.

5: New GC
New garbage collector “Garbage First” should result in predictably low pauses, few full GCs and good throughput. Can be accessed in Java SE6 update 14 using:
-XX:+UnlockExperimentalVMOptions –XX:+UseG1GC

This will be switched on by default in JDK 7.

Danny notes at this point that numerous other (small) features are also part of JDK 7.

JavaFX 1.2 Top 5
Danny begins by stating that Sun is trying to make up for lost time with JavaFX (as I have blogged in the past).

More platforms
JavaFX 1.2 runs on more platforms i.e. Linux and Solaris in addition to Windows and Mac. LG TV (purchasable in South Korea) incorporates JavaFX1.2. Finally, the HTC developer phone is also mentioned. Danny states that he hopes that phones will be available to consumers on the coming months. Don’t we all!?

New features
New widgets, charts, plus a new look and feel. L&F is possible via CSS, which is obviously a whole load easier than creating an L&F for Swing.
Improved layout management
Layout management: There are three new layout managers, but I know from experience these don’t yet cut it for non-trivial B2B apps.
There follow a series of nice looking demos, which highlight that JavaFx is scenegraph based.

Improved perforamance
Performance up: Realtime streaming for media is now supported, which improves media startup significantly. Various optimizations in generated code and scenegraph. Bytecode footprint is down 30%.

Improved data handling
More and better ways to use data. RSS and Atom feed support. A simple asynchronous framework is also included, plus a simple data storage API.

One final demo is really impressive: Using the bubblemark demo, Danny demos that JavaFX 1.2 performance is significantly better than Silverlight. Now that I would not have expected!

Session: Jsf and Ajax in the Credit Suisse
From: Benjamin Bratkus, Credit Suisse; Micha Kiener, Mimacom AG

It will be interesting to see what CS has been up to with JSF. My last JSF project finished early in 2008. I look back to it with pleasure not primarily because we used JSF but because we really got to use all of the key JEE features under Glassfish – which worked sweetly. JSF (which included facelets), on the other hand…

CS began with JSF in 2004. Corporations begin what they are, this resulted in a pilot (2005). Release 1 of their app took place in 2007. Since then CS claims to have one of the biggest JSF-based component libraries around.

 
Framework must support:

• Realtime data
• Handle huge data sets
• AJAX and JavaScript due to security aspects

…and must achieve acceptance by various architects.

The speakers also used ICEFaces to achieve the required level of interactivity and security. Specifically: Direct-to-DOM rendering (D2D), page level AJAX on existing components, AJAX Push capabilities.

Key to achieving efficient push: Asynchronous server push, which will apparently become standardised in the next version of ICEFaces. This approach frees up threads on the server-side, which is obviously essential for scalability.

Summary: Good talk, competent speakers. I still feel sorry for the average AJAX developer, who despite frameworks like ICEFaces is confronted with myriad non-trivial technical details. Plus, I imagine CS is not confronted with the other big pain for browser-based RIA: Multiple browsers.

Session title: RIA Security: Broken by Design
From: Joonas Lehtinen, CEO IT Mill

IT Mill is the creator of Vaadin: A 100% Java tool for RIA.

Joonas outlines a spectrum of complexity from Basic site to 3D games examples:
Web Sites (Wikipedia), AJAX Sugar (Facebook), Full RIA

He divides „Full RIA“ divide into client side vs. Server driven. Gives a crash course in GWT.

Vaadin: Apparently 100% Java and server driven, which sounds an awful lot like ULC at this stage… But here’s a difference: It builds on GWT and relies on JavaScript on the client-side.

He goes on to present a bunch of development rules:

Rule #1: Don’t trust the browser
Rule #2: Complexity is a hiding place for bugs
Rule #3: Large surface give more opportunities for attack. This surface has increased with Web 2.0.

Difference between GWT and Vaadin architectures is that GWT relies on the client invoking a server-side Web Service API, whereas Vaadin renders the client’s view on the server.

Erm… he then offers the cures for the problems (Rules above)… which I miss because the explanation is compressed into around 5s.

I’m starting to dislike this presentation at this point. Because here comes another artificial security issue scenario… which guess which product solves. And I thought product placement in Hollywood movies was irritating.

The issues he raises are legitimate, but the lack of objectivity is obscuring the message. And as I write the presenter is debugging JavaScript which depends on analysing the DOM on the client side – I’m not sure if he’s now analysing the problem or trying to fix it!?

I am formally declaring myself lost at this stage. At least I hope the other attendees are getting something out of this presentation, which has lost focus IMO.

He continues with a discussion about attacking at the transport level, inserting new data on the fly. But come on: A secure transaction in this technical setting will operate under HTTPS, which in most instances will deal with this kind of attack. Unless, of course, that’s something else I missed.

I think I need a coffee!!!

Title of this session: Development for the iPhone from a Java Perspective
From: Software Architect Ognen Ivanski, Netcetera

Note: Netcetera developed the wemlin app for the iPhone – a useful tool for navigating public transport in the Zürich area.

Ah… it’s become apparent to me that Ognen will tell us about his personal experience with becoming an iPhone developer, having previously been a Java developer. I have gone through this process myself and so it will be interesting to compare notes…

Ognen states that the first realisation was that performance, startup-time and UI were kind of new priorities for him. Not really the case for me, I must say. Canoo is known for its RIA experience and therefore these are issues we’ve been dealing with for some time. For the record: The issues which I found most difficult when switching to the iPhone SDK and XCode were:

- No garbage collection: Clearly I’ve been spoiled by Java
- XCode: Powerful but nowhere near as comfortable as a typical JavaIDE
- SCM support: We managed to get Subversion working, but kept running into trouble with things getting out of sync anyway. Best to use the command line

I certainly agree with Ognen’s observations on XCode: Like me, he missed features such as refactoring and the countless options for viewing, navigating and outlining code.

Ognen notes that XCode’s visual builder is difficult to get used to but delivers in the end. Possibly like many Java/would-be iPhone developers, I shied away from the visual designer, opting to code from hand instead. Perhaps for my next iPhone app I’ll take a look at it again.

I agree with Ognen’s observations on Objective C syntax. It’s got a “familiar and yet somewhat strange” feel to it. The behaviour around “nil” seems odd at first, but one quickly learns to appreciate that it pays not to have to check for null values all the time, as in Java code.

There follows a lot of examples of Objective C Syntax.

Patterns of note in the iPhone world: Delegate pattern, Target/Action pattern, MVC – which is perhaps truer to the original Smalltalk concept that what we typically see in Java swing, say.

In summary: A good presentation, but no new insights for someone who’s gone through the process of switching from Java to iPhone development already.

Speaker: Neil Ford, Thought Works

Warning: This entry assumes knowledge of GOF patterns…

Observation on the GOF (Design Patterns) legacy: Many of the patterns were really good at getting over C++ nightmares.

Boy does the blogger agree with the following statement: UML is too technical for non-techies; not technical enough for techies.

Iterator: Super-easy in Groovy using closures; requires a non-trivial interplay of interfaces and classes using the traditional GOF pattern. Lesson: What’s commonly needed will eventually be subsumed by language features.

Command pattern: Modern languages implement this using closures. Java, for example, again requires a command interface, command implementations etc. Structure (e.g. adding undo/redo) can be easily added on an as needed basis.

Strategy pattern: Using code blocks in Groovy instead of adding extra classes, as one would in Java.
(Must see article: Execute in the Kingdom of Nouns from Steve Yegge)

Template Method pattern: Traditionally declared using abstract methods in classes. In Groovy we can use variables that hold onto code blocks, thus eliminating the need for the abstract methods. Use Groovy’s null dereference operator to avoid null pointer exceptions when the code blocks are null.

Interpreter pattern: Originally designed to overcome deficiency in language being used by creating a new language on top of the current language. Alternative: Groovy permits us to easily create new DSL using the “expando property” feature. Ford notes the fact that a new form of pattern is arising: Patterns of DSLs (Ford notes that Martin Fowler is going to release a book on this very subject in the coming months.) Ford notes that internal DSL’s amount to embedding an interpreter.

Decorator pattern: Groovy’s invokeMethod feature can be used to achieve what requires Aspects in Java. Inline decoration is also possible. Ford goes on to explain a few other interesting aspects of Decorator… but I can’t keep up ‘cos I’m not familiar enough with Ruby!

Adapter pattern: In Java we need to wrap existing entities to achieve interface compatibility. Ford shows a really interesting Ruby-based approach which involves dynamically changing the interfacing of an object at runtime. Notes that this can only be done with interpreted languages and that similar things can be achieved using AST transformations in Groovy. However, the latter is more difficult than in Ruby because of it’s nature as a truly interpreted language.

Null object pattern: In Groovy null dereference operator can be used to handle the null object situation frequently. In Ruby this doesn’t work because even null (nil in Ruby) is also an object.

Aridifier pattern: Avoid repetition. Ruby example shows how test methods can be created on the fly to reduce code footprint significantly.

Ford’s Summary: Traditional DPs use a lot of structure to solve problems. Dynamic languages permit far more elegant solutions.

I’m reminded of statements made long ago (in an online article, I recall) by OO grand master Bertrand Meyer to the effect that:Patterns? All well and good but there are no replacement for language features and reusable libraries.

Ford’s presentation was absolutely first class in terms of both content and delivery.

Session title: Groovy – seven usage patterns

Dierk begins firstly by emphasising that Usage Patterns are not to be confused with (GOF) Design Patterns, secondly by stating that the intent of Groovy is not to replace Java but to make the life of the Java developer easier.

Up front: I won’t attempt to describe all Dierk’s patterns here in detail, but will limit myself by noting the quintessence …

Pattern #1 “Super glue”: Hook large components i.e. middleware, frameworks, widgets etc… together.
Dierk now engages in an act which I swore I’d never attempt myself live and on stage: Live coding! And boy Dierk can type fast!!!
Ah ha… naughty but amusing… The typing is being done by an app.
Regardless: With just a few lines an RSS feed is shown in a Swing GUI including a table, a scroll bar. Very nice.

Pattern #2 “Liquid Heart”: Externalise business models because they need to constantly reflect our changing understanding of the business problem. The “liquid” here is, for example, a rule that needs to be dynamically changed. In this case Dierk invokes Groovy from Java. The Groovy functionality can be exchanged at any time… even runtime.

Pattern #3 “Keyhole Surgery”: Minimal invasive surgery “in vivo”
Dierk shows how Java objects can be seamlessly addressed (in-line) in Groovy statements and expressions. This means that with very little code we can wrap existing code and add some additional functionality. Dierk mentions how this was recently used to great effect as part of a SAP mandate, saving days of work as a result.

Pattern #4 “Smart Configuration”: Enhance configuration with logic
This is a common pattern in Groovy. Whereas Java apps tend to use XML for configuration, Groovy makes extensive use of itself as the configuration mechanism. Dierk shows an example taken from Navis. Instead of having one config file per client, Navis now has a single config file (in Groovy) which handles all the desired configurations.

Pattern #5 “Unlimited Openness”: Every line of code may be changed
Dierk cites PlanetRIA (planetria.org) as an example of where vey little code change was required to create a new app based on an existing one – which in this case was groovyblogs.org.

Pattern #6 “House Elf”: Delegate the housework
Example: Use the Groovy ant task to introduce novel functionality to ant at the time the ant script is running!

Pattern #7 “Prototype”: Feasibility study on the target platform
Groovy is ideal for rapid prototyping. Dierk explains how Canoo uses functional prototypes as a partial replacement for a complex, static description of the application’s intent, such as is found in most tenders made to clients.
A cool example involving prime numbers follows. Groovy’s category feature is used to introduce a count of the number of times the modular operator is invoked, which subsequently leads to a vastly improved algorithm.

In closing Dierk mentions a couple more patterns which are in the pipeline: Lipstick, Ghost Writer. For more information on Groovy usage patterns: Wait for Groovy in Action 2nd ed.; out later this year.

Just two question from the audience: What’s the best IDE for Groovy development. Answer: At the present time IntelliJ, but improvements are on the way for Eclipse. Next: How reliable and easy-to-use are AST transformations? Answer: A junior developer recently succeeded in developing an AST-based solution in just a few days, as part of the PillarOne project.

Read a french Blog about Dierk’s talk!