Park & Go

Parking Internet Solution

Keywords: User Interface, SVG, Web Services

Paul Lynch
Senior Consultant
Trinity College & Vision Consulting
Dublin
Dublin
Ireland
pjlynch@vision.com
http://www.tcd.ie

Biography

Paul is in his final year studying for a BSc (Bachelor of Science) in Computer Science degree in TCD (Trinity College Dublin) . He has gained extensive experience in software engineering and is a senior technical consultant with an international consultancy. He has worked on a number of projects which incorporate XML (Extensible Markup Language) but this is his first that uses SVG (Scalable Vector Graphics) .

Benjamin Jung
Trinity College Dublin
Dublin
Ireland
benjamin.jung@cs.tcd.ie
http://www.cs.tcd.ie/Benjamin.Jung/

Biography

Benjamin Jung is a lecturer in Computer Science and Medical Informatics at Trinity College Dublin and supervises Paul Lynch's final year project. He is a regular speaker at XML conferences in Europe and the US. His main rsearch interest are data visualisation, document architectures and XML technologies in the domains of medical informatics and electronic publishing. Since 1997, Benjamin has presented papers and chaired sessions at various Computer Science and Medical conferences. He developed full-day XML tutorials and workshops that were given at conferences in Europe and the US. In 2000, Benjamin co-founded deepX Ltd, where he holds positions of director and consultant.


Abstract


Combining the benefits of both thin browser based clients and traditional client-server architecture, "Park and Go" is a web-based client-server application that will provide users with all of the functionality required to administer their parking requirements while also providing the parking wardens with the functionality to communicate the status of their spaces with the users.


Table of Contents


1. Introduction
2. Technologies Involved
     2.1 Internet Client
     2.2 Web Server
     2.3 Application Server
     2.4 JDBC
     2.5 Database
3. Design
     3.1 Space State Transition
     3.2 User Interface
4. Implementation
     4.1 Database Design
     4.2 Drawing the Map
         4.2.1 Landmarks
         4.2.2 Parking Spaces
     4.3 Automatic Update Daemon
         4.3.1 Concept
         4.3.2 Implementation
         4.3.3 How the map is refreshed
5. Future Developments
     5.1 Migration to Web Services
     5.2 Security
         5.2.1 SSL
         5.2.2 Database protection
6. Summary
     6.1 SVG vs Flash
Bibliography

1. Introduction

The powerful combination of rich display functionality coupled with strong ECMA (European Computer Manufacturers Association) script support categorises SVG as a promising choice for designing interactive images and graphical user interfaces. More recently SVG is evaluated as a technology to build platform and system independent clients and also as stand alone applications. Undoubtedly, flexible SVG user-interfaces will soon become an interesting alternative to application front-ends, which are often proprietary to operating systems.

The innovative architecture combines the benefits of both thin browser based clients and traditional client-server architecture. Ease of installation by means of a browser plug-in subsequently combines simplicity with response times and richness of traditional client software. SVG provides the ability to create desired thick client functionality. An SVG application consists of a rich user interface that performs client side processing and interacts with the backend server via background calls to server side scripts. The ability to process the response from server side scripts rather than simply rendering the returned document is one of the features that make SVG a powerful GUI (Graphical User Interface) framework.

"Park and Go" is a web-based client-server application that will provide users with all of the functionality required to administer their parking requirements while also providing the parking wardens with the functionality to communicate the status of their spaces with the users. The specific objectives are to:

2. Technologies Involved

2.1 Internet Client

The internet client is the software which displays the user interface to the users of the application. This project was developed on IE6 (Internet Explorer 6) with the Adobe SVG plug-in installed. Any browser with these correct plug-ins would be able to run the application without any problem.

Browsers have always been traditionally considered "thin clients", meaning their primary function is to display and not to perform much processing of business logic. Because of SVG 's ECMA scripting language ability to dynamically alter the attributes of any element in the SVG document coupled with its ability to perform asynchronous background processing, SVG offers the ability to create real thick client functionality while retaining the best aspects of thin client such as ease of installation.

2.2 Web Server

All of the interaction from the client's browser is handled by the web server. The web server is the part of the architecture which receives to HTTP (Hyper Text Transport Protocol) requests from the client and delivers the SVG pages back to the client. In this application the only files that the web server would service directly to the client are the static included JavaScript files. All of the other requests are for JSPs and are routed to the application server.

For this project, the web server and the application server are discussed as two separate entities. This is logically correct because when deploying the application, the web server can be a completely different machine and can be implemented using any of the many different web servers e.g. iPlanet, Domino Go or Roxen. In this implementation, Apache Tomcat serves as both the web server and the application server.

2.3 Application Server

The application server is where all of the back end logic is executed. This is where the JSP (Java Server Pages) files are compiled into servlets and executed. The JSP s in this application do all of the interaction with the database – selecting, inserting, updating and deleting. Requests routed via the web server are processed and the output is passed back to the client again via the web server.

It is important to decouple the web server and the application server primarily for scalability. As the traffic on our website increases, we can add extra resources to each as they reach their maximum capacity. This separation also give the application extra security by providing another layer of separation between a potential hacker and our valuable data being held in the database. We can place firewalls between each which only allow traffic on the correct ports to travel between them. This is what is being illustrated in the following diagram.

networktopology.jpg

Figure 1: Architecture: Network Topology [Jav02]

2.4 JDBC (Java Database Connectivity)

JDBC is an industry standard for database-independent connectivity between a computer platform or device operating in the Java environment and a wide range of databases. The JDBC provides a call-level API (Application Program Interface) for SQL (Structured Query Language) -based database access.

2.5 Database

Virtually any of the popular databases could be used for this system – Microsoft SQL Server, Sybase, mySql or Oracle. This project was implementated using Oracle 9i Personal Edition which is freely available for download from the Oracle website.

3. Design

deckcards.jpg

Figure 2: Moving between Layers

function showLegend(evt)
{
     var SVGDoc;
     SVGDoc = evt.getTarget().getOwnerDocument();
     var glegend = SVGDoc.getElementById("legend");
     glegend.setAttribute("visibility", "visible");
}
wrapper.png

Figure 3: Initial Login Layer (wrapper.svg)

wrapper1.png

Figure 4: After clicking on the registration link (wrapper1.svg)

wrapper2.png

Figure 5: After Logging In (wrapper2.svg)

3.1 Space State Transition

std.png

Figure 6: State Transition Diagram

The background colour of the parking space is dependent on which state it is currently in. The functionality available to each user type is also dependent on which state the parking space is currently in. The different states are as follows:

3.2 User Interface

screenshot.jpg

Figure 7: Screen Shot

There are two sections to the screen. The first main section is 600 pixels wide leaving 200 pixels wide for the second section. The design theory behind these two sections is that the first section will be relatively static, the structure of the contents of that section will not be altered. Elements such as the structure of the landmarks and the parking spaces along with the refresh and legend buttons will not be altered by anything the users do. Things like the background colour may change but this does not constitute a change of structure.

The second section is the control panel. This is intended as the primary source of all information and main area for all user interaction with the system. The content of the control panel is very dynamic. It changes dependent on whether you are logged in or not, whether you are a user or a traffic warden, when you select or deselect a parking space and the status of the parking space that is selected.

Due to the number of fields required in the registration page, there was not enough room to have all of them in the right hand control panel. The illusion of a popup window was created. By having this, it felt like this new "window" was on top of and not a part of the original two sections of the screen.

Capturing user input was another problem. The SVG specification does not include simple structures as buttons, text boxes, option buttons, drop downs or checkboxes. These are essential to create forms similar to those standard in HTML (Hypertext Markup Language) , important so they are immediately intuitive. One of the biggest mistakes a user interface designer can make is to start moving away from well established standards which people are used to. If a system is difficult to use, the odds are that people are not going to use it. This project used the control libraries built by Scott Straley [Str03] . His library is available by including his ECMA js file. The following is a screen shot of one of the inputbox controls he has built:

textbox.jpg

Figure 8: Third party text box

While his control library is fantastic, there do exist a number of bugs. Some of these I fixed but some minor ones do still remain, the main one being the flashing caret giving the user the impression that text box has focus when in fact it doesn’t. This can be a bit confusing but is overcome once the user clicks on it again.

The next task was to build buttons that the users could "click". The following screen shot shows two buttons that created:

buttons.jpg

Figure 9: Simulated Buttons

These buttons are in fact only simple rectangles with text types over them. As the following code which is the code that was used to create the "Submit Details" button above demonstrates, two SVG elements were grouped together and given an id so they may be uniquely referenced in any of the ECMA functions. The onclick event of this grouping means if anyone clicks on either the rectangle or the text, the buttons action is fired.

<g id="registerbutton" onclick="submitRegister(evt)" >
     <rect x="330" y="320" width="100" height="25" rx="2" ry="2"
           style="fill:#ededed;stroke:rgb(0,0,0); stroke-width:1;" />
     <text x="340" y="337">Submit Details</text>
</g>

This next example is simulated option buttons. They behave exactly like standard HTML option buttons. The following three screen shots demonstrate the working of the option buttons and how they can respond to user events and invoke ECMA functions.

In this the first of the three screen shots, you can see the structure of the option buttons section of the registration form where the user indicates the method by which they wish to pay for their transactions.

paymethods.png

Figure 10: Simulated option buttons for choosing Payment Method

As the following code which shows how one of the option buttons were defined, it is made up of all standard SVG elements – circles, rectangles and text. Again you will see that the elements are grouped and referenced that way but in this case we need to be able to reference the inner black dot which indicates when an option has been selected to make it visible or hidden. You will also see that when the user clicks on the option, a function called PMClick is called passing in the id of the option button selected.

<g id="pm1">
     <text id="lblpm1" x="535" y="245">Visa</text>
     <circle cx="515" cy="240" r="5"
             style="stroke:#000000; stroke-width:1;
             fill:#FFFFFF;" onclick="PMClick(evt, '1', 'Card Number')" />
     <circle id="optionpm1" cx="515" cy="240" r="2.5"
             style="stroke:#000000; stroke-width:1; 
             fill:#000000;" visibility="hidden" />
</g>

Once a user selects one of the options, the black dot of that particular option is made visible. This gives the appearance of the option button being selected. Also when they select a "Payment Method" such as "Direct Debit", there is additional information required, in this case the bank account number to debit the money from.

If another option is selected, the change of option is reflected by the black dot from the original selection now becoming hidden and the black dot of the new option becoming visible. Also you will notice with this option of "Postal Invoice", there is no additional information required so the input box which was visible is now hidden.

The final user input control developed is one which becomes active when a parking space has been selected for payment. It is used to select the duration the user wished to pay for. The following is a screen shot if the control in its initial state:

paymentduration.png

Figure 11: Control for Selecting Payment Duration

The duration defaults to one hour. This means that the "Total Amount" is the same as the "Rate for selected space". As we click on the up or down arrows, the duration increases or decreases in increments of 15 minutes. The limits set are for a minimum payment of 15 minutes and a maximum of 12 hours. The second screen shot illustrates the situation after the up arrow has been clicked 6 times.

You will see that the duration now stands at 2 hours and 30 minutes and the new "Total Amount" had been dynamically calculated by multiplying the duration by the rate for that space. The user can now click on the pay button and the details of the payment will be sent to the database and the map refreshed.

One of the things anyone who is very used to data input on web forms will notice very quickly is that this application is very mouse orientated. There is no tabbing around the screens and no defaults actions when you hit keys such as return. Unfortunately to get this sort of functionality working would probably constitute a project in itself.

4. Implementation

4.1 Database Design

All of the co-ordinate data used to build the map and the usage data recorded in payments etc are held in a relational database.

4.2 Drawing the Map

The map in the system is built consisting of two different entities types, parking spaces and landmarks. They are both simple elements but drawn in very different ways. The primary reason for there being such a difference is that landmarks are free to be any shape and parking spaces are fixed instances of a space category.

4.2.1 Landmarks

Each landmark is a polygon of an undetermined number of points. Each landmark that is defined in the database has a background fill colour and a name that will be displayed when the user hovers the mouse cursor over it. For each Landmark, a coma delimited string of the points associated with it is built up and the area it encloses by the lines connecting these points is filled with the background colour.

<polygon id="LAND1" style="fill:#FF0000;" 
         points="100,100 100,200 200,200 200,100 100,100" />

This piece of code will render out a polygon which connects 4 points (to make an enclosed shape, you must finish back at the point you started out at) as illustrated below. It has a unique identifier of LAND1 and has a fill of red (Hex #FF0000).

4.2.2 Parking Spaces

Parking spaces are all instances of one of the space categories:

In the following code example we define a parking space category called "CAT1". This space category is a polygon defined by four points.

<defs>
     <polygon id="CAT1" points="-25,-50 25,-50 25,50 -25,50" />
</defs>

The following diagrams illustrate how the parking spaces are instantiated, rotated and translated into position.

spaces.jpg

Figure 13: Illustration of Space Creation

Note: The order in which these stages occur is critical to getting the spaces into the correct positions.

Each parking space is an instance of a defined space category. When it is created, the points of the space are set so that the exact centre of the parking space is at the origin. This is critical for rotation because when SVG rotates an object, it rotates it around the origin. Once the space is linked to the space category, it is firstly rotated around the origin ( Figure 13 ) and is then translated into position ( Figure 13 ).

The following code fragment demonstrates how this is achieved in SVG :

<use id="SPACE4" xlink:href="#CAT1" 
     transform="rotate(45) translate(200,200)" />

This code allows SVG to drastically reduce the amount of code that is required to build any images which uses many elements which are

The "use" tells the SVG engine that the element that you are about to create is an instance of one of those defined in the "defs" section. The xlink gives the engine the reference to the element definition. In this case we are creating a copy of the CAT1 element definition and it is designated by an id (unique identifier) of "SPACE4". A transform matrix is then applied to the new space. It is firstly rotated 45 degrees clockwise around the origin and is then translated 200 pixels along the x axis and 200 pixels along the y axis. The coordinate system for SVG images run from the top left to the bottom right i.e. the x axis is positive as you move from left to right and the y axis is positive as you move from top to bottom. The transform also allows for the scale function but I don’t avail of it in this project.

4.3 Automatic Update Daemon

4.3.1 Concept

While using the system, it is obvious that the status of the different spaces may change. For this reason, the map had to automatically refreshing. To achieve this, a "daemon" process needs to be created - a background thread which gets kicked off after the map is loaded and runs for the duration of the browser session with a set interval between runs.

4.3.2 Implementation

The following is an exert from the code that was used in the implementation of the refresh daemon:

function refreshDaemon()
{
     if(CURRENTLY_PROCESSING==PROCESSING_NONE)
     {
          CURRENTLY_PROCESSING = PROCESSING_REFRESH;
          refreshMap();
     }
     setTimeout('refreshDaemon()',5000);
}

function refreshMap()
{
     var sUrl = "getSpaceData.jsp";
     getURL(sUrl, refreshMapProcess);
}

The section of code that makes this a daemon process is in the refresh daemon function where it recursively calls itself after 5 seconds.

4.3.3 How the map is refreshed

The map is refreshed by making a background call to the getSpaceData JSP . This JSP queries the database and returns a string which contains a structured list of details about each space organised by status.

The next step is to set all of the spaces that have a status of occupied. This sets them all to the grey colour because the user id of the logged in user is not taken into consideration in this query. When I get the actual spaces which related to the currently logged in user, there won’t be more than one or two so the over lap is minimal.

5. Future Developments

5.1 Migration to Web Services

Web services are widely expected to be the "next big thing" in application development. ''Web services represent a kind of next best-practice architecture for designing Web systems, the idea is to create coarse-grained services that encompass business functionality, and make them acceptable to platform-independent XML . It's not exactly built into the standard that these things have to be business functionality or coarse-grained, but when you talk about Web services as a best-practice architecture, that's how it works [Adt03]

By deploying our back end processing as web services and web service enabling the client, this application would have great flexibility. When pertinent web services become available (such as parking payment systems or pay and display meters), this architecture enables the client and the server applications to interface seamlessly with them.

By writing this application using JSP instead of some of the other popular scripting languages such as PHP, the code is inherently Java which means the transition to web services should be relatively painless.

5.2 Security

As with any internet site that is capturing sensitive information from users, there is a responsibility on the proprietors of the website to ensure that that information does not become accessible by any third party, be they external "hackers" or dishonest internal employees. There are endless ways in which a website and its data need to "hardened" to be considered secure, so many that to address even half of them would require turning this section of the document into an internet security document which is not what I intend to do. This section mentions some of the more fundamental and important to implement.

5.2.1 SSL (Secure Socket Layer)

Data about the user is at its most vulnerable while it is being transmitted across the internet, i.e. While travelling between the web server and the internet client ( Figure 1 ). Anyone with the correct know-how can easily "eaves drop" on the line and get a copy of the data that is being transmitted. The well established method of combating this is by implementing SSL which is a public private key encryption system. This will use 128-bit encryption and will mean it is only of any interest to the intended recipient. This can be implemented very easily by purchasing an SSL certificate which is renewable every year.

5.2.2 Database protection

When storing sensitive data such as credit card numbers in the tables in our database, we have a legal obligation to protect that data. The most fundamental way of protecting the data is to ensure only trusted employees that must have access to the database know the login usernames and passwords. Also make sure there are logs kept of all activity carried out by these users while they are in the database.

Information such as credit card data is extremely profitable data if a third party could get their hands on it. Some people, hackers or internal will go to extraordinary lengths to get it and despite the tightest of security, you may not be able to stop them gaining access to the database. For this reason, it would be an immediate requirement to develop encryption algorithms which make the data readable to the system only and useless to any external system or people.

6. Summary

This project was successful on two different fronts; the project is a very strong business model which could be developed into a fully operational commercial system and it also demonstrates how SVG web client interfaces offer a far superior level of user interaction for graphical based applications. Once there is a complete control library defined in the SVG standard, SVG may well become the client side language of choice.

6.1 SVG vs Flash

Probably the most obvious alternative to SVG is Macromedia’s Flash, current version being MX or 6. It sticks out because it also produces vector based graphics and has the same ability for background scripting. A lot of what can be achieved in SVG could also be achieved in Flash but there are definitely many differences between the two.

SVG is a superior choice because of the power of the ECMA script to manipulate every attribute of every element in the DOM (Document Object Model) of the image. SVG is a standard established by the W3C (World Wide Web Consortium) , every vendor’s implementation of SVG must conform and code that works on one implementation will work on the others. That is preferable to Flash, where there is only one company developing it and setting the standard for it.

As it is text-based, to edit SVG code you need nothing more than a simple text editor such as notepad. With flash, the generated files are binary files which cannot be reverse engineered - you must have the source code to be able to make any changes to it and in order to be able to edit it, you must firstly purchase Macromedia’s product. The clear text can be indexed by search engines whereas Flash SWF (Shockwave Flash) files cannot.

Some of the other features of SVG that makes it superior are things like CSS (Cascading Style Sheet) s which are fully incorporated into SVG but are only partially implemented in Flash. This means that in an SVG application such as this one, to change things such as text fonts and colours along with background fills and borders can be achieved by editing one file. Also being XML based, the syntax and validity of the SVG can be verified by defining a DTD (Document Type Definition) .

Bibliography

[Wetal03]
Watt, A., Lilley, C., Ayers, D.J., George, R., Wenz, C., Hauser, T., Lindsey, K., Gustavsson, N. (2003) SVG Unleashed, SAMS Publishing.
[Eis02]
Eisenberg, J.D. (2002) SVG Essentials, O&Reilly.
[Hor99]
Horrocks, I. (1999) Constructing User Interfaces with Statecharts, Addison-Wesley.
[Jav02]
Java World, Article, http://www.javaworld.com
[Str03]
Straley, S., Control Library, Third party http://www.straley.net
[Adt03]
ADTmag.com, Article, http://www.adtmag.com

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.