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: 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.

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!

Session title: Refactoring of Large Software Systems revised
Speakers: Sibylle Peter, Sven Ehrke – Canoo Engineering AG

First observation: This is a very well attended session, which reflects the fact that refactoring, whilst not the most glamorous of tasks, is obviously very important to a lot of developers.

The speakers describe the key lessons learned during a very challenging refactoring undertaking at a major bank. The project essentially involved trying to clean up software, the internal dependencies of which had gone out of control over time.

One of the key lessons learned: Keep it Simple, Stupid.

Options:

• Do a huge refactoring at some point once it has been recognised that costs per features have sky-rocketed. This is obviously not the recommended approach, but it is often the only option available.
• Do refactoring incrementally per release
• Do refactoring constantly

The costs of the project are pretty shocking: 6 persons for around a year. I could imagine this was a pretty sobering message for many members of the audience.