JAOO 2008
Last week I attended JAOO 2008 in Aarhus, Denmark (Java And Object Orientation). The conference was well organized, and covered a wide range of topics. It was great to be able to listen to many opinions on the future of software development, as well as what is being done today.
I attended 18 talks in all, and there were a few major themes that recurred.
- Cloud computing; how to develop and manage distributed systems. (and how
can make this easier…) - Functional programming; an alternate paradigm in coding style that (among other benefits) allows for easy runtime distribution of code (cloud computing).
- Scaling / High performance; how to architect and manage systems that are high volume and/or high performance.
- Development and project methodologies; scrum and agile pep-talks, common planning and project mistakes, code review and refactoring.
- Rich internet applications (RIA); Both standards based and proprietary approaches to RIA development.
There are a few talks that really interested me, and I’ll cover them here.
Top Ten Software Architecture Mistakes
By Eoin Woods from Barclays Global Investors
I really enjoyed this talk, although I noticed that the project name was misleading. The mistakes were not to do with the architecture itself, but with the edges of a project that can get neglected or forgotten. Never-the-less, it made for a great laundry list of issues to make sure all your projects have an answer for. Indeed, Eoin himself noted in the summary for the talk
“In this talk I’ll share some of the pitfalls that I’ve encountered in my experience as a software architect and in doing do, hopefully make sure that you avoid making just the same mistakes on your projects.”
So, here is my summary of the 10:
- Scoping Woes: the dreaded scope creep needs to be tackled head on; rigorously check that features are really needed, and that the flow on effects of missing features are communicated.
- Not Casting Your Net Widely: Ensure you identify the spectrum of stakeholders, and work to ensure that difficult stakeholders are addressed, to ensure they are onboard.
- Focusing on Function: Functionality is only one component of a successful project. Its the qualities of the project that need to be considered early, as these can be the hardest to change later on. Rank the most important qualities to help guide guide the project: availability, compliance, evolvability, maintainability, performance, reliability, scalability, security, supportability.
- Boxes and Line Descriptions: Many designs are drawn in a way that can be ambiguous or inaccurate. This leads to others misunderstanding design diagrams and all sorts of confusion. Ensure you are accurate and use a well defined notation! Make all diagram elements ( vertices’s, box styles, colors) explicit in their meaning.
- Forgetting It Needs to be Built: This point touches on the Golden Hammer problem. Consider why new technologies should be used rather then just following trends. Make sure you have a team with experience with your chosen tooling, else expect a learning cost. Ensure that any extra time is worth the benefit.
- Lack of Platform Precision: Saying it runs on “Linux with Tomcat” leaves the door open for problems like; “why doesn’t it work on my Linux kernel 1.0 with Java 1.2 and Tomcat 3 ?”. Specify a specific and versioned stack, and ensure that developers, testers and users all use the same stack.
- Performance Assumptions: A difficult quality to guarantee. Assume nothing and consider it early in the project. Test it properly based on the importance of this metric.
- DIY Security: How hard can it be to implement security? Answer: Its hard to do correctly! Generally, reusing infrastructure is a smarter way, unless you have very unusual needs.
- Lack of Disaster Recovery: Any system has a large risk without DR. Even if DR is in place it is rarely tested. Plan, Design, Build, Practice!
- No Backout Plan: For those times that deployments don’t go well, ensure you have a rollback/backout plan! Not easy for large deployments, but very risky without backout option.
I know in the past that I have neglected some of these non-functional and tangential considerations; the implication from this speech is that Software Architects must manage many more areas then just the functional development and tool choice. For me it reinforces how architects must work very closely with Project Managers and clients to architect a complete and robust solution.
Kaazing Gateway: An Open Source HTML 5 Websocket Server
By Jonas Jacobi from Kaazing
So how do we get proper 2-way communication between a browser and a server using HTTP? Classically this functionality, known as Comet programming, has been achieved with some sneaky emulation techniques. These include server polling, holding long-term HTTP connections and using hidden iframes. The existing solutions have costs, however. Polling adds lots of unneeded requests to a server, and holding connections open causes many open connections for the server as user count rises. Kaazing has taken a commendable approach to solving this limitation of HTTP.
First off, they contributed the WebSockets section to the HTML5 standard. This specifies a JavaScript API and DOM tag (<eventsource>) to open a new connection, allowing bi-directional communication. This connection uses the standard HTTP protocol, and actually changes the wire protocol from HTTP to WS after the connection is open. This means that connection can be open through proxies and firewalls without needing admins to open the network for this communication.
This means that there is a standardized way to code proper bi directional communication without thinking about the (tricky) details.
This is great, but HTML5 isn’t yet finalized: so how do we get browsers to support this? Its a chicken and egg problem - you need browser support before you use a feature, and you need a feature to be used to encourage browsers to support it. Kaazing has taken an approach that really resonated with me; I like to call it fake it till you make it.
Kaazing has a script that checks for existing WebSocket support, and if not there, it adds Kaazings implementation of the API. This means that developers can code using the standardized API before the browser has native support! Kaazing actually has multiple implementations of WebSockets, and their insertion script picks the best implementation for the clients browser. If a client has Flash installed, this is used as a bridge. If there is no Flash, Sliverlight or other bridge with proper socket support, it will have to default back to an implementation using long connections or polling.
This means that the solution works for everyone, even the 1% who don’t have Flash or similar installed. Now instead of polling or long connections of every customer, you only need to use this old tecqnique for 1% of your clients - much easier to deal with. Jonas mentioned that one browser already has native support for this API in one of their nightly builds (Maybe the newest Firefox? Opera? Can remember sorry).
Of course, you need a server that knows how to handle the protocol upgrade - this is Kaazings’ commercial offering: Kaazing gateway. In fact, their product can be used to allow any TCP traffic to be routed over HTTP, allowing the same proxy/firewall benefits for RIA and client-server software. The gateway can simply expose a normal network socket and any TCP content can be transmitted over the open connection. Much better then making your software have to make lots of HTTP requests, and the server needing to convert, package and send back each request in a textual format.
update: Look at http://orbited.org/ and/or http://js.io/ for other implementations of WebSockets.
The concept that really resonated with me is the fake it till you (they) make it approach. I have seen this a few times already in the browser space, such as in these projects:
- IE <canvas> tag support with javascript+VML emulation: http://sourceforge.net/projects/excanvas/
- IE SVG support via Silverlight: http://ajaxian.com/archives/svg-on-ie-via-silverlight-via-xslt
- IE <canvas> tag support via a plugin that embeds the firefox canvas code: http://blog.vlad1.com/2008/07/30/no-browser-left-behind/
- ECMAScript4 support (aka Javascript 2): https://wiki.mozilla.org/Tamarin:ScreamingMonkey
A standardized approach to Comet programming is great; a solution to browsers’ chicken and egg adoption issue is even better!
The Lively Kernel
By Dan Ingalls from Sun Microsystems Laboratories
The Lively Kernel is a project from Sun laboratories. It is an environment coded completely in JavaScript and SVG. It is not a production ready tool, but an interesting research project. The environment is designed for visual element creation, cloning and enlivening via scripting. The environment allows the end user to add scripting to any visual element and modify any existing one.
I don’t have much else to say about it - it works in all good browsers, and the tutorial demonstrates its features and concepts well.
Of interest to me is the idea that SVG could be used to develop richer applications that still use standards (ECMA, SVG in this case). UI design can be freed up with SVG, and good libraries would make an SVG based UI easy to develop. Coupling SVG with WebSockets would allow you do develop pixel perfect RIAs that could rival solutions such as Flex; I think these are the 2 major areas that traditional websites suffer in comparison.
Performance Considerations in Concurrent Garbage-Collected Systems
By Peter Holditch from Azul Systems
Going in, I knew this was a sponsored talk. I was expecting lots of PR and marketing fluff, but I was pleasantly surprised. Yes, Azul make high end Java appliances (more on them later) but the talk was about real-life Java garbage collection. I’m not going to cover it here as you can find better information elsewhere, but we covered stuff like concurrent, parallel garbage collection and fragmentation of the heap.
In this discussion, we were lead to an important conclusion: Java sometimes needs to pause execution (phrased: stop the world) to garbage collect and defragment the heap. High volume and high performance systems simply cannot afford this pause, and its frustrating even for regular Java systems. You can increase the heap size but this only delays the problem AND makes the pause longer. Larger heap == larger defragment time.
Azuls’ hardware gives the JVM garbage collector hardware mechanisms to work in realtime in parallel, giving your processes 100% cpu time with no stop the world interruptions. Oh, and did I mention that you can have heap sizes of > 500Gb ?!!
Their hardware is the CPU/memory equivalent of NAS; you have a regular server running a tweaked version of Sun Java. This version is a wrapper JVM which delegates all its work to the JVM running on the Azul CPU. As far as the regular server knows, it is a completely standard JVM. (albeit a very fast one with an abnormally large heap!)
The Azul hardware ships with many cores, and the CPU/memory can be logically divided into multiple JVM backends. I didn’t inquire into pricing, but I imagine that a box with 54×16 CPUs and 768GB of memory is going to cost a bit. Still, a very nice piece of hardware, and a good discussion on the art of garbage collection. Azul systems, you are welcome to send me some sample hardware so I can play more and do a better writeup…
Conclusion
These summaries are for some of the sessions I enjoyed, but there were many more interesting talks: Google Chrome and its JavaScript engine, the OpenSocial API, Googles’ App Engine, JRuby and others. I really enjoyed the talks, but also being able to socialize with so many different (smart) people means that its hard not to have an interesting time.
On one hand, conferences like this are really humbling. Listening to knowledged talks on so many subjects makes me feel like a fool only scratching the surface, and makes me appreciate how much more there is to learn. On the other hand, the whole experience is so inspiring! I suppose I’m inspired to continue scratching…