SVG as the Visual Interface Layer to the Emerging Web Services Market

contact info:
Shane Aulenback and Rob Williamson
Corel Corporation
1600 Carling Ave, Ottawa, Ont. Canada, K1Z8R7


Keywords: svg, web services, application integration, system integration, XSLT, XML


Web Services define a standard framework for accessing and delivering applications over networks. They focus on a separation of the application logic, the standard communication layer, and the interface. Separation is key to enable integration of multiple Web Services into distributed Applications. What is missing is a compelling standard for building the interface to these Web Services. A standard that recognizes the importance of application openness, of enterprise demands for extensibility and scalability and of the existing technologies in place on the client and the server. The interface should not require any custom server pieces but can take advantage of the competing Application and Content Management Servers in the market today. This paper outlines a case for SVG as a standard Visual Interface technology along with a case study illustrating the delivery of geospatial data from multiple sources into an application called 'Geoinitiative'. It concludes with a breakdown of the design and development challenges that were faced in building a complex Web application.

What is 'Geoinitiative'?

Geoinitiative (figure 1) is a case study that is used to illustrate an application that was built using a combination of technologies that conform to the framework outlined here. This case study was chosen for its technical complexity and real-world business application. Although the focus of the article is on the technology, a quick overview of the problem will help in understanding the approach that is used in delivering a solution.

Figure 1: Screen capture from the Geoinitiative application showing a bi-directional interface built with a combination of Web Services delivering the content and SVG displaying the content.


Governments worldwide have launched 'e-initiatives' to improve internal, agency-agency, and agency-citizen communication. Serving a large and variant group of users requires a system that delivers from multiple systems to multiple channels. With geographic information, this case outlines several problems:
(1) How to deliver large amounts of information (native files are 150MB+) to users that average 28.8 dial-up;
(2) How to ensure that the information is delivered in a usable format;
(3) How to integrate information from multiple agencies at run-time.

The solution uses a visual interface that combines the richness of the bitmap with the interactivity of SVG. Layers and transparency are used to effectively communicate large amounts of data in one interface while behaviors are used to control what data is being viewed. Roll-overs display more information while new data can also be entered and posted to the server via a management approval step. On the server, Web Services deliver the data and application intelligence from multiple sources.

What is a Web Service?

A Web Service is a standards-based approach to delivering self-contained applications over the network (i.e. the Web). Web Services can be as simple as delivering a piece of data such as a stock quote or as complicated as delivering full application-like usability with relevance to the end user (such as an interactive stock chart covering a personal portfolio). It can be argued that today's Web pages for many online applications like banking are already, in substance, Web Services of a proprietary nature. Systems such as the Geoinitiative prototype, while possible, would be very difficult to build and maintain without using some standard form of Web Services. Every change from any content contributor would result in a new design-to-development cycle.

Today's applications are often based on proprietary systems with common requirements not addressed by common applications. A Web Service delivers richer functionality to the user but limitations of the viewing technology make it difficult to expose this functionality.

Comparing descriptions of Web Services from three different sources illustrates the remarkable similarity that has developed despite the (sometimes) conflicting goals of the sources.

Microsoft describes Web Services within its .NET framework as:

XML Web Services are the fundamental building blocks in the move to distributed computing on the Internet. Open standards and the focus on communication and collaboration among people and applications have created an environment where XML Web Services are becoming the platform for application integration. Applications are constructed using multiple XML Web Services from various sources that work together regardless of where they reside or how they were implemented. Copyright © 2002 Microsoft Corporation, One Microsoft Way, Redmond, Washington 98052-6399 U.S.A. All rights reserved.

Sun Microsystems describes a Web Service similarly:

"...Web Services" is the next level of this trend, which builds on the current server-hosted and -maintained Web-based applications. The idea is that Web Services result from software components being spontaneously discovered, combined, and recombined to provide solutions to users' problems and requests. XML is the prominent technology enabler in this phase." Copyright © 1994-2002 Sun Microsystems, Inc.

The W3C® has come to an agreement on this working definition that defines a Web Service in more technical terms:

A Web Service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML-based messages via Internet-based protocols.
Copyright © 2002 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.

What are the technical underpinnings of a Web Service?

XML (Extensible Markup Language) forms the foundation for the delivery of Web Services. XML by itself though, cannot be considered a Web Service. Broadly speaking, for a Web Service to extend beyond the simplistic definition of information delivery, a common framework is needed (figure 2).

FIGURE 2: Web Services architecture outlining the importance of standards in every layer. The term 'register' is used generically to describe any method for making the service known to its intended aggregator (public or private).

SOAP (Simple Object Access Protocol) is the industry standard method for exchanging structured data between applications running on a network. SOAP is made up of a framework describing what is in the message, a set of rules for expressing the data, and a method for representing remote procedure calls.

The programmatic interface is described in XML form using WSDL (Web Services Description Language) which enables a developer to build the usable application. Finally, UDDI (Universal Description, Discovery, and Integration) is a registry for developers to quickly find and use publicly available Web Services.

Other technologies can be used to locate applications not intended for public consumption, such as Microsoft and IBM's Web Service Inspection documents ' a successor to the Discovery documents (coined as 'disco' by the development community) currently used in the .NET framework.

Because all of these technologies are structured and standard-based they can be readily incorporated into a RAD (Rapid Application Development) tool to expose the functionality of the service without needing to understand the underlying technology ' much like WYSIWYG HTML editors of today.

<?XML version="1.0" encoding="utf-8"?>
<definitions xmlns:http="" xmlns:soap="" xmlns:s="" xmlns:s0="" xmlns:soapenc="" xmlns:tm="" xmlns:mime="" targetNamespace="" xmlns="">
<s:schema elementFormDefault="qualified" targetNamespace="">
<s:element name="SetWellData">
<s:element minOccurs="0" maxOccurs="1" name="wellNumber" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="easting" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="northing" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="zone" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="depth" type="s:string" />
<s:element name="SetWellDataResponse">
<s:element minOccurs="1" maxOccurs="1" name="SetWellDataResult" type="s:int" />
<s:element name="GetWellData">
<s:element minOccurs="0" maxOccurs="1" name="wellNumber" type="s:string" />
<s:element name="GetWellDataResponse">
<s:element minOccurs="0" maxOccurs="1" name="GetWellDataResult" type="s0:welldata" />
<s:complexType name="welldata">
<s:element minOccurs="0" maxOccurs="1" name="WellNumber" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Northing" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Easting" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Zone" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Depth" type="s:string" />
<s:element name="GetAllWellData">
<s:complexType />

CODE SAMPLE 1: Typical WSDL code in the Geoinitiative case outlining how water well data is defined and accessed. In this instance, the logic is fairly straightforward ' a well either exists or it does not. If the well exists then the elements of that well are described.

One advantage of a standards-based communication layer is that application code can be separated from the result. By providing a communication layer, a Web Service is independent of the underlying code. Combining multiple Web Services into multiple client applications does not require reinventing each application, but rather the recombination of assets.

This has been well summed up by analyst Uttam Narsu of the Giga Information Group:

"As companies strive to move away from proprietary development platforms and tools, standards become the essential ingredient that makes that possible. Standards, whether in hardware, software or networks, provide the mechanisms that allow different types of applications and devices to interoperate."

The Web Service communicates to the client through standard high level Internet communication protocols like HTTP or SMTP. In very simple Web applications, the information is typically static HTML delivered to a browser. When full client-side application is required, the client is responsible for getting that data into an application.

The core requirements are outlined as follows:

Value of Web Services

Web Services deliver tremendous value to the World Wide Web by solving multiple problems associated with distributing, extending, and interacting with a traditionally static environment. Significant benefits include:

What is missing from Web Services?

Web Services, like the data delivered in the Geoinitiative example, introduce rich functionality over a system that was designed to support static publishing and to a consumer that is conditioned to this result. The design and delivery is not conducive to richer functionality. A more powerful Visual Interface layer is required to effectively deliver applications. To most end users the interface is the application, and coding efficiencies aside, the end user is the primary recipient of the value of Web Services.

Traditional technologies were designed to publish information (content) to the end user. With Web Services, the content is no longer a simple static document but in fact becomes an application. Figure 3 shows an example of this framework which combines a rich graphical interface with dynamic data to display any type of application to the user.

FIGURE 3: DOCUMENT = APPLICATION, DOCUMENT ELEMENT = GRAPHIC, TEXT, LAYOUT. When delivering applications multiple tools and technologies take the place of human intervention.

This Geoinitiative case study uses a small subset of data from several complex database systems. To make each system accessible it must have its own API and data structures. While the protocols to access it may be standard, how it interacts with the calling application is not. In this case, the developer retrieves valuable information from the service that is simply data ' data that is complex and not suitable for delivery in its raw format.

  - <wells>
<well number="381190" northing="3541611.50" easting="346200.69" zone="13" depth="2245" />
<well number="381931" northing="3541150.50" easting="346200.69" zone="13" depth="1732" />
<well number="381322" northing="3541611.50" easting="347148.72" zone="13" depth="0" />
<well number="34606023" northing="3541778.25" easting="347994.22" zone="13" depth="652" />
<well number="34606034" northing="3541598.75" easting="348237.66" zone="13" depth="605" />
   <?xml version="1.0" encoding="utf-8" ?> 
- <counties>
- <county id="curry" name="Curry">
<point x="346021.31" y="3541916.00" />
<point x="346021.31" y="3540493.00" />
<point x="347590.63" y="3538744.50" />
<point x="348186.34" y="3538039.75" />
<point x="348359.28" y="3537469.75" />
<point x="348340.06" y="3537053.50" />
<point x="348436.16" y="3537047.00" />
<point x="348384.94" y="3538677.00" />
<point x="348276.03" y="3541916.00" />
- <county id="sanjuan" name="San Juan">
<point x="346021" y="3540493" />
<point x="347590" y="3538744" />
<point x="346143" y="3538834" />
<point x="346021" y="3538834" />

Code Sample 2: XML Data displaying information from two outside databases. Structured XML simplifies the use of information not stored centrally. The XML data on the top represents well water locations coming from one source while the data on the bottom represents county boarder data coming from another. Neither source is the service aggregator described in Figure 1.

SVG is the right vector format

It can be assumed that a vector graphic format is the logical way to deliver information both at present and in the future. Vector formats provide quality, scalability, and extensibility that cannot be obtained in a bitmap. This isn't to suggest that bitmaps won't continue to play an important role in the delivery of information, just that the data driven components are best delivered using vectors.

The data, the registration of the data, and the creation of the SVG have all been described above. In typical application development scenario, it is management's responsibility to determine the business goals and the design team's responsibility to generate the usable Visual Interface. Figure 4 shows one view of the completed application based on the goals and the designs in the Geoinitiative case.

Figure 4: Review of Geoinitiative visualization of data in SVG layered on a bitmap. This image is captured from a live application pulling information from multiple locations. Image source: U.S. Geological Survey (USGS).

In the case of Geoinitiative, both bitmaps and vector content are needed to display the data. The structured data illustrated in Code Sample 2 is transformed into SVG code that results in the interface shown in Figure 4. Since SVG supports both bitmaps and vector layers it is ideal for displaying the data published by the application.

Delivering the high-resolution raster image within the SVG to low-bandwidth connections requires an image server to be introduced into the workflow. The image server's job is to sample down the 150 MB images to a Web-suitable format while retaining the ability to zoom and pan within the image while retaining quality. Alternatively, if the application was being delivered over a low-bandwidth wireless network, the same application logic with a new presentation layer could simply ship a vector outline of the bitmap. This illustrates the key point: it is the same data, the same logic, yet a different presentation.

Figure 5: Overview of SVG

There are multiple technologies designed to interface with information published over the Internet. Each of which has its own strengths and weaknesses. Simple HTML is accessible by everyone, readable, searchable and has well defined usability. Java™ has the most flexibility in delivering proprietary systems since it provides a complete application development framework. The Macromedia Flash™ viewer is well distributed and has a good designer following. However, SVG is the most appropriate technology available in that it provides richness yet has the same key values of openness, extensibility, and scalability that is inherent in Web Services themselves (Figure 5). Enterprise systems need to maintain extensibility, scalability, legacy format compatibility and cross platform support to ensure that technology created today remains usable tomorrow.

SVG - The technology to build Smart Graphics

How does the user of the resulting application visualize, interact, and respond to the data that is delivered via a Web Service? If the end user requires, for example, a different time period than the service originally delivered, how is that request made? If a user's preference is to always require that data in a certain form then how is that distinguished from a different user's preferences? Perhaps most importantly, does the Web Service even provide that functionality?

This introduces the concept of Smart Graphics. Smart Graphics enable graphically-based Visual Interfaces to link with data and systems. Intelligence within the graphic can lie either completely on the server-side, completely within the client, or in some subset in between. Intelligence in this case is defined by the ability of the graphic to present relevant information based on the underlying data. For example, the axis in a simple bar chart can have the intelligence to scale according to the data that is being presented. Figure 6 covers the typical service-interface stack. The environment depends on when and where that graphic is delivered as well as the business purpose of that graphic.

Figure 6: Distinction between a Web Service and the consumption of that Web Service illustrating the difference between technology and form.

The key is that the same data source, intelligence, and interface characteristics are preserved regardless of how the content is viewed. Figures 4 and 6 outline the value and the technology behind separating the logic from the interface as well as the likely technologies that play a role in generating the Smart Graphics. Where suitable, server-side scripting transforms the graphic to the relevant form, whether that form is based on user preferences or based on the technology limitations of the viewing device (i.e. using SVG Tiny, Basic, or a raster transformation of the SVG). In this way, changes can be made to either the Visual Interface Layer or the Application logic layer independent of each other.

SVG represents an ideal technology for the creation, delivery, and management of Smart Graphics. The Geoinitiative case study demonstrates the difference between static SVG and dynamic SVG ' dynamic because it is driven from data. With dynamic SVG, the code-base becomes significantly smaller while at the same time delivers more information. It also eliminates costly and time-consuming involvement of design when multiple outputs change based on one set of data.

Creating rich Visual Interfaces

Creating a rich visual interface for one or more Web Services is still a laborious task. The developer must request UI (User Interface) mockups from a designer and then inspect the WSDL carefully to determine how the information can be mapped from the service to the UI.

Take for example a simple UI element like a drop down list (combobox) that needs to get populated. How do I create a drop down list at all? If the application needs to display current weather conditions then how does that string "overcast" get converted to an image of a cloud for the user? What device is this going to be displayed on? Will a raster image work? Does the client have the processing power to interpret the data?

All of these questions take time to answer and thus cost the customer money and effort. Such issues also increase the effort or may even prevent the solution from being reusable in another application.

Figure 7: The painful workflow

Figure 7 outlines how the development process remains iterative. Often the design process either reaches beyond the capabilities of the underlying system or fails to recognize some required functionality that the system can provide (and is desired). This is sometimes a limitation of the information collection phase of a development project; most often it is a result of a simple change in the business goals during development.

The developer returns to the designer (and vice-versa) to explain that certain applications are or are not available and offers alternatives based on coding principals. Design returns the request with new design parameters requiring changes to the application logic.

Compare this to the world of current desktops. Here, the answers are easy. Many good UI frameworks are available which include listboxes, checkboxes and any other UI controls imaginable. Many tools exist that allow you to layout and customize your interface, with clear ties to the APIs set out by your DLLs or other coding modules. The processing power of the desktop, while variant, is generally known.

Outside of the standard GUI controls, visual interface development needs are not met in the Web Service application development paradigm. In this environment developers must create everything from scratch. ASP, .NET and JSP provide the language to do so, but the tools, the libraries and the precedent aren't available. Many standards forums are attempting to address this problem - XUL, WSIA, WSUI, XUP to name but a few - but the tools are still missing.

Take, for example, the creation of a simple dialog in a Web-based application which consumes Web Services. The type of controls you use in your dialog should be completely dependent on the Web Service interface. If the Web Service is looking for Boolean parameters and returns a list of strings, then a checkbox may be the proper control to trigger the calling of the function and a listbox is populated with the results. Since Web Services provide an XML standard for their definition (WSDL), one can clearly visualize the structures for these interfaces.

What is missing today?

In building the Geoinitiative case, many complex tasks were undertaken that took full advantage of the value of Smart Graphics. The various alternatives to delivering content to the user are outlined in Figure 8.

Existing systems typically centralize data or collect the data on an 'as needed' basis. Often this data is collected by hand, assembled in desktop systems and delivered to a user who can read the file format. This system is ideal where huge quantities of information need to be delivered on a consistent basis and manipulated (by hand) by the recipient. However, when the goal is to get information from 'many-to-many' it quickly breaks down.

Figure 8: The differences between three common systems for publishing data and applications from end to end.

In figure 8, the far left schematic outlines typical file delivery, the middle system a typical application delivery, and the right an architecture for the delivery of Web Services. Delivering a closed application requires that the system be syndicated numerous times with multiple output types. Application logic and presentation layer are joined which makes changes within the system difficult.

The system on the right outlines the run-time delivery of Web Services. While it initially appears more complex, its complexity allows it to deliver multiple Web Services to multiple output locations and media and provides for a system that is easier to extend and maintain. By delivering the application at run-time the data is relevant at any given time or to any given user.

The value of a run-time system based on standards is summed-up well with the following quotation:

"While simplicity makes it possible to deploy an initial implementation of a distributed system, extensibility allows us to avoid getting stuck forever with the limitations of what was deployed. Even if it were possible to build a software system that perfectly matches the requirements of its users, those requirements will change over time just as society changes over time. A system intending to be as long-lived as the Web must be prepared for change." 1

Graphical application development environment

The appropriate system needs to be in place to deliver XML-based applications. A simplified proposed framework is outlined in figure 9.

Figure 9: Framework stack outlining 4 key groupings of activities in delivering Web Services to a Visual Interface layer.

This framework provides sufficient extensibility and scalability to meet all of the demands of the application but introduces significant complexity to the designer and the developer. Although the job of building the application required hundreds of small tasks, a few major tasks required the most effort to complete. These challenges are detailed in Table 1 and explained in more detail in the paragraphs following the table.


Solved By Framework


Base Image (with tiling)

Serving out the base image in a manner that it can be scaled and tiled appropriately.
Coordinate System Determining a transformation that allows all layers (image and vector) to be at the same scale ratio and position.
Tying data to SVG Specifying what data defines which vector layer.
Writing XSLT

The XSLT converts the data to the appropriate looking SVG vector layer.
Preparing data for use Data that does not originate from XML needs to be converted to XML for XSLT processing.
Artist & Development teams workflow is seamless Both teams were able to share both design and code without having each others skill set
UI Controls The user controls (HTML and SVG) that the user interacts with.
Zoom/Pan Controls SVG is open and scalable and completely interactive, therefore, standard and custom UI components can be easily supported.
HTML with SVG Communication Cross DOM™ talking between the HTML and the SVG worlds. SVG can affect HTML and HTML can affect SVG. A standard, well-defined interface is used for this.
Posting Data back to a Database The process needed to post user updates back to the database. The ability to add water wells is an example here.
Authoring SVG This is the creation of the core SVG. There are multiple tools available to author SVG.
Debugging ECMA Script & XSLT Output is standard XML and any tool on the market can be used.
Scalability Need to be able to catch proper levels so that minimal processing is needed at any given server request.
Bandwidth Limitations Needed to overcome a narrow bandwidth concern even though large amounts of data potentially could be accessed.
Different scaling for different elements Certain SVG elements need to maintain size even though the map is scaling in size. The water well icon is an example.

Table 1: List of core tasks to Generate the Geoinitiative Case. The top 5 elements are highlighted and discussed in more detail in the body of the paper.

Base Image (with tiling)

The ortho-images (satellite images of geographical areas) which are 150Mb+ in size, change on a regular basis and thousands of them exist. Either a custom solution is needed that does image processing or preprocessing needs to be done for all possibilities. A delivery process that includes well-defined imaging capability allows it to handle images like any other type of data. Through a simple process the large image can by dynamically referenced. Only the requested portion of the image is accessed at the scale factor needed, thus the load time is minimized. The request can happen from the client side in the SVG coordinate system and the server calculates the actual pixel position of the request.

Coordinate System

The problem facing our developers was in building a system that converts the UTM coordinate system (Universal Transverse Mercator - a system for mapping the Earth's coordinates) to SVG. There are three core issues: (1) When the map console (what the map displays within), was designed it was in its own coordinate system; (2) The y-axis for SVG is opposite of the UTM y-axis; (3) The map scale is added on top so that the user is able to view the map at different levels. What was needed was a tool that allows the user to select given points within the SVG and map them to a corresponding value. For this example two points can be used to set up this relationship. More points can be used to develop a nonlinear relationship if needed. This has significant application in any system where two or more objects are related to one another in some way.

Tying data to SVG

Keeping track of where data comes from and how it will be shown in the SVG is a challenge that will be unique to every project. The solution is to provide drag-and-drop capabilities that tie user interaction to data retrieval requests. Rather than hand-coding every data connection, the ideal scenario will have a graphical interface that allows the user to describe just how and where the data is shown once retrieved. Tools which allow you to connect visual controls directly to the WSDL elements, or that can generate customized Visual Interfaces based on the WSDL of the Web Service, provide a powerful solution not available today.

Writing XSLT

Writing XSLT can be cumbersome both initially and for maintenance purposes. If the data structure changes then the XSLT needs to change as well. If the data is described using appropriate XML schemas and delivered using appropriately described Web Services, then tools can be used to enable a visual representation of how data aggregates and is transformed. Any required XSLT can then be dynamically generated and used at run-time.

Preparing data for use

A majority of legacy data is not XML-based. The task of converting to XML can be either time consuming or impractical depending on how the data is used by other parts of the company. Server components that provide a data aggregation/transformation pipeline that can easily set up as a task that converts data to XML when needed. Only the requested data is converted and data used extensively is in any server environment, auto cached. This enables multiple legacy data and new systems to work together, without modification while reducing the need to have and maintain multiple copies

Artist/Design & Development teams workflow is seamless

Although not strictly a technology problem, the collaboration of art and design teams introduces significant bottlenecks to every development initiative. The artistic and development teams often depend on each other throughout the implementation in a highly iterative process. Effective deployment of tools will recognize this dependency while maintaining a level of separation. If both the data and the graphics are data driven, then the data and the application can change and the graphic is automatically updated. At the same time, if the design is changed, there is no need to involve the development team in reconnecting the design parameters to the assets.


It is obvious that to effectively build SVG applications requires a combination of technologies that are presently available though not in one usable environment. The appropriate tools are needed to reduce the effort, improve the workflow between development and design, and decrease maintenance. Though some tools exist on the market today, joining them together in order to make a working application is difficult and reduces the core value of Web Services. Tools are also required that make it easier to solve the needs of both server and client.


Web Services as a framework alone is a very compelling distributed application delivery system. The fact that the major development tools vendors support environments for building Web Applications only furthers the scope of the opportunity for the designer, the developer and the enterprise. SVG represents a compelling technology for interfacing with Web Services because it provides richness and interactivity while ensuring that the application logic and the application interface layers remain separated. To deliver application interfaces requires the addition of other technologies such as Java, Javascript, C#, and XSLT. Challenges that are faced with HTML development today. However, the appropriate tools allowing design-development workflow integration and open standard output makes the development of the next generation of Web Applications possible.



1 Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.


Valid XHTML 1.1!