Lombardi Blueprint: Client side code, server side execution with GWT
April 28th, 2009 | Published in Google Code
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!
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!