This post is part of the Who's @ Google I/O, a series of blog posts that give a
closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written
by Alex Moffat, Chief Engineer - Blueprint, Lombardi Software
Lombardi has been using Google Web Toolkit (GWT for
short) since January 2007 to build Lombardi Blueprint, an online, collaborative
business process modeling and documentation tool. The client part of Blueprint is completely
written using GWT and runs in any modern browser, that is IE6 and anything later, such as IE7,
IE8 or Firefox. One of the biggest advantages of Blueprint is that it's easier to learn and
quicker to use than a pure diagramming tool like Visio and it's more effective because it's
focused on process mapping.
One of the things we do to make Blueprint
more effective is automatic diagram layout. This allows the user to focus on describing their
process instead of worrying about object positioning and line routing. You can see this in
action in the video below as objects are added to the diagram.
Remember, this
is JavaScript compiled by GWT from Java code, but it's as fast as, or faster than, anything
you could write by hand, compact, and much, much, easier to maintain. The ability to use the
excellent tooling available for Java is one of the great advantages of GWT.
One of the goals for our automated layout routines is to generate a flow diagram that
looks like it was produced by a human. When the algorithms don't get it quite right, Blueprint
also supports hinted layouts so that the user can drag and drop hints about where one object
should be positioned in relation to another. Working out what the final layout should be and
where the lines should go for large diagrams can be computationally expensive.
Modern browsers have very fast JavaScript engines. For these systems, there are no
problems. However, we still need to support the browsers our customers use, which may not
necessarily be the fastest or most up-to-date.
This is where GWT gives us
a unique benefit. We can implement our algorithms in Java and compile this implementation
twice, once with GWT to produce JavaScript to run on the client and once with javac to produce
JVM bytecode to run on the server. This lets us use the much faster JVM if we need to without
having to create, and maintain, separate client and server layout implementations. There's no
other toolkit that makes this possible, never mind easy.
Blueprint client
code continuously measures how long it takes to perform the layout and routing operation in
the browser. If this exceeds our threshold value, then the code dynamically switches to trying
a server side layout. We call the server code with GWT
and the data structures returned, via the GWT
serialization mechanism, are of course the same ones produced by the layout when
executed on the client. The time required for a server layout is also measured, which includes
both the execution time and any network delays so we account for the different connection
experiences people have. After the first server layout, Blueprint chooses whichever method,
client or server, has the lowest average elapsed time. I'm still amazed by how easy this was
to implement.
Damon Lundin and I will be talking at Google
I/O this year about how we built Blueprint, both what we do technically with GWT to
get high performance and how we organize development so that we can make the most effective
use of GWT. We look forward to meeting fellow GWT developers in person!
By Alex Moffat, Chief
Engineer - Blueprint, Lombardi Software
