Hot and Fresh Technology for the Enterprise

April 17, 2002

Antoine Quint

This month I'm taking a break from flooding you with heaps of technical SVG tricks in order to reflect on how SVG has been progressing. In my first article here five months ago I discussed where we were then with SVG. I focused on the application area I was most familiar with, end-user graphics. The situation since then has evolved as the community is still awaiting an SVG-enabled animation authoring tool from a major vendor, as well as counting the months until an SVG viewer achieves complete ubiquity (like Adobe's).

Since I started working at ILOG, I've stepped into a whole different world, enterprise graphics. The term may sound a little barbarous, but it covers professional usage of graphics for business applications like gantt charts, graphs, maps, workflow monitoring, etc. While on the Web SVG faces a very fierce competitor format for high-end interactive graphics (SWF), it is being accepted in a cosier way in the enterprise where no vector-based technology has yet made its mark. Today I'll try to show you how SVG is used in enterprise applications, and how it ranks in usage and power against other client-side technologies like DHTML and SWF.

Server-side Graphic Frameworks

One of the key elements of enterprise graphics solutions is to be able to meld data and graphic presentation together in a seamless way. There are a variety of tools out there which allow this on a variety of platforms. Lately, two graphics giants have come up with new technologies for dynamic serving of high-end graphics. Corel has announced its DEEPWHITE content management system, with a strong focus on providing graphically-enriched content. Adobe has been shipping its AlterCast product for a few months now as a server-side imaging solution tightly integrated with Adobe's applicative workflow. The common point in those two offerings is the strong implication of SVG.

XML makes it easy to separate data and rendering. SVG, as an XML technology, also offers that great advantage. This makes SVG a great candidate as a format for use in a graphics framework. Let's take a look at how AlterCast can work with Illustrator. A designer would create a graphic document template within Illustrator, assigning variable names to certain bits of text or graph values. She would save this template as SVG with the application adding some XML metadata in a different namespace in order to identify the variable names with objects to access in the document within AlterCast. Then the SVG is piped into AlterCast where a developer would connect the identified bits and pieces of the template to a database that would feed data directly to the SVG. Then the document can be published and served. The metadata held originally in the document is still there and the document could be read back in after some client-side processing (like editorial modification of the content) and any XML-powered system would be able to read back the updated data and notify original data sources. This truly allows for some intelligent document design. SVG is an excellent application to centralize different data sources in a structured and open way, while allowing for rich graphics.

SVG being a public and free-to-implement specification, some open-source and free server-side tools are available to help you create SVG-powered applications. The most noticeable one of which is Apache's Batik, which offers advanced SVG power on the Java platform. It offers SVG DOM functionality for constructing SVG documents and renderers for rasterizations of the final graphic composition. And it is fairly simple to embed in other applications.

Related Reading SVG Essentials

Thin-Client Interactive Applications

Once you've managed to dynamically assemble the bits and pieces of your graphics, you are going to want to allow for remote visualization and maybe even editing of your contents. SVG makes real progress possible in this area. The thin-client/server application model has to this point been based on the tricky DHTML "platform" (HTML, JavaScript, CSS, and DOM). Anybody who has had experience of developing a client application involving some interactivity with DHTML would probably tell you about inconsistencies between different browsers, and how hard it is to introduce advanced features that will work in a consistent way across platforms (ie. IE/Netscape, Windows/Mac/Unix). However this does not mean that DHTML isn't useful, and one can manage to create applications with some load-on-demand functionality as well as basic visualization interactors (zoom and pan). The problem is that DHTML does not really allow for drawing, and you would be stuck asking your server-side graphics framework for validation of the image very often, resulting in substandard performance and intense network traffic. DHTML thin-clients allow for the creation of a simple UI with simple controls, leaving much of the "intelligence" to the server.

Flash has found astonishing success in the Web design community and has even been used in some pretty simple but nifty thin-client applications for map visualization. However, Flash technology is very much handicapped by its isolation. Macromedia has adopted a real all-in-one approach, and you basically have to use both Flash MX and the upcoming ColdFusion MX to do heavy client-server interaction. There has also been a great push towards using XML as an exchange data format between Flash client-side applications and servers, but this has been wildly hyped and the truth of its capabilities is not as inspiring. Looking at the public API of the XML object as implemented in Flash Player 6, you will see that it is truly simplistic and does not allow for half of what you would expect from an XML API. For instance, it is impossible to create an attribute node, which ignores the semantic value of XML documents or messages and disallowing a more serious usage of Flash. On top of that, that XML API is completely non-standard. Another issue with Flash 6 Player is its drawing API which limits greatly the generation of graphic data on the client-side from local or remote generated data. However, the new Flash MX and ColdFusion MX technologies sound like a reasonable replacement for DHTML clients in terms of ease of use and development, although it will probably not give you the capability boost you might expect from it. Overall, there is a need for more open creation and deployment solutions for Flash content as users will always be tied to using the Macromedia MX-family application to generate content and interact with it.

Recently, ILOG has published a survey of JViews customers, asking what technologies they used in their projects. Some interesting feedback appears on thin-client technology usage: as of today, 22.9% claim to be using DHTML in their applications, 15.7% use SVG, and 0% use Flash. As for what customers will be using in their next projects, 26.5% will use DHTML, 27.7% will use SVG, and 2.4% will use Flash. Even though SVG is a relative newcomer in regards to DHTML and Flash, it will eventually be the most-used solution for deploying thin-client applications by our customers, either for creating raster data from the server or serving it as pure SVG to the client.

First of all, SVG is an XML application and greatly benefits from the XML experience of programmers who get to use this technology. SVG is fully compatible with XML standards such as the DOM, and anyone with some DOM experience should be able to construct SVG graphics from a data set. Also, XML is an ubiquitous technology in the application server world, now pushed more than ever by Web Services trends. On top of that, we have seen that major industry players such as Adobe and Corel are pushing SVG-centric server-side graphic frameworks. Finally, SVG offers a real platform on the client-side with Core, CSS, Events, and SVG DOM available for scripting. This offers great tools for drawing, transforming, filtering applications in a completely open, standalone and dynamic way; and all of this with the same DOM technology many developers are familiar with. You can create a complete visualization system on the client-side with SVG without having to query once the server. SVG does not suffer from distribution problems in the enterprise world so much as it does in the Web world since many graphic applications customers have a greater control of user's software and are not scared to have them install a plug-in or standalone viewer.

SVG also opens some exhilarating possibilities. Many developers have begun to embrace the power of DOM and SVG combined to parse XML data and render it. For example, XForms form controls, which are in XML but there's no definite way to render them. A document with some XForms controls can be rendered completely with an SVG Viewer that would parse the document for elements in the XForms namespace and then add SVG objects. The SVgUI project aims at providing that kind of functionality completely on the client-side with a set of plug-and-play JavaScript libraries. Following the same rationale, and thinking of pioneering work done in the Mozilla project with XUL, one can think of SVG as a solid user interface framework. For instance, one could have a <window> element that would be converted to SVG.

Wrapping it all up

SVG has sure benefited from XML's solid reputation in the enterprise world to acquire a respectable level of usage and application offering for a a young technology. Major vendors have found SVG to be a helpful tool to incorporate into their graphics applications. We can expect further growth as more developers use it to develop reusable components and take part in leveraging the interactivity between clients and servers.