Final Year Project Progress Report

1	Overview

Work to date has mainly comprised research into topics relevant to the construction of E-commerce sites and the development and deployment of smartcard applications.  Investigation into different Internet protocols and various server, scripting and database technologies has enabled many decisions to be made with regard to the implementation of the Internet site.  However, many obstacles have been encountered during the smartcard research phase, and as such it is still unclear as to how this part of the project will be implemented.

This document acts as a brief summary of the research and testing which has been carried out, and the decisions made as a result of these activities.

2	Administrative Arrangements

2.1	Supervisors

These have been assigned to be Mr. P J Miller and Prof. K J Blow.  Regular progress meetings with Mr. Miller have taken place on a weekly basis throughout term 1.

2.2	Moderator

This has been assigned to be Dr. J A R Williams.  Arrangements have been made for the project inspection to take place early in term 2.

2.3	PC Workstation

A Pentium 133 in N402 running Windows 98 has been claimed for use in development work.  Appropriate software has been installed upon it.

3	Internet Site

3.1	Server Type

Different permutations of operating system and web server software were assessed, and in many cases, evaluated by installing and testing them and reading their accompanying documentation.

3.1.1	UNIX

UNIX servers are generally highly regarded for their reliability and stability, hence initially appeared to be an attractive option for deployment.  However, the fact that smartcard wallet transactions always appear to be implemented as card-to-card value transfers implies the need for the server to itself to possess a smartcard reader, or CAD.  Unfortunately, the majority of CAD’s are supplied only with drivers suitable for Windows environments, and any UNIX or Linux alternatives are slow to materialise, and usually unsupported.

3.1.2	Windows NT/2000

From amongst the various Windows product offerings, NT or 2000 are generally regarded as the most suitable for server applications.  Suitable CAD drivers do appear to be available for NT and 2000, permitting these to be attached to the sever.  Two different web server packages were installed and evaluated fairly extensively.

3.1.2.1	Apache (with PHP)

The Apache HTTP server from the Apache group appears to be the most commonly deployed web server on UNIX machines.  The Windows version of this package appears to be extremely capable and well-featured.  Apache is highly configurable, yet minimalist in nature (i.e. not bloatware) and apparently fast and efficient.  It is also very extendable, in that supplementary modules can be added to it to provide enhanced functionality.

An E-commerce site obviously requires some degree of server-side processing over and above supplying static content at the request of browsers.  Requirements include keeping track of current product selections (the user’s “shopping basket”), maintaining and querying a database of available stock, etc.  Research showed that this could be achieved using a number of different techniques, e.g. CGI implementations using PERL, or server-side (inline) scripting using PHP.  Both of these possibilities were considered in some detail, with the latter identifying itself as a fairly simple yet logical approach, highly suitable for such an application.  PHP can, apparently, be run as a CGI process itself, resulting in performance overheads comparable to other CGI implementations.  The PHP module was added in to the Apache server, and numerous scripts created to test performance and the feature-set of the commands provided.  Both were found to be impressive.

Despite the many advantages that Apache (and PHP) were found to provide, the Windows implementation is still, however, only in beta form and not recommended for actual deployment.  More crucially, it appears that methods for interfacing with CAD’s via PC/SC will be extremely difficult using any of the programming or scripting extensions available for use with Apache.  The standard method for achieving communication with such devices appears to be via instantiation of COM objects or ActiveX controls.  With both of these fundamentally being Windows concepts, it is perhaps unsurprising that with this being a port of a UNIX package, support for such objects is non-existent.  A module to allow Apache to serve ASP scripts was located, and it was hoped that - in the same way that ASP’s running on Microsoft IIS or PWS can deal with COM/ActiveX objects - so this would provide the same functionality within Apache.  However, this was not found to be the case.  Instead, the feature-set provided by the ASP module was incomplete.

3.1.2.2	Internet Information Server (with ASP)

IIS from Microsoft is a web server designed for use on Windows NT machines, and comes as part of the NT4 Option Pack.  Installation and configuration was, in comparison to Apache, much more laboured and cumbersome.  IIS lacks the minimalism offered by Apache, instead providing numerous wizards and options windows which attempt to provide a more user-friendly front end, but in practice seem to inhibit appreciation for the full scope of configuration options.  Once running and correctly set up, performance is comparable to that of Apache.

IIS is supplied as standard with ASP, a server-side scripting tool comparable to PHP.  Although more laboriously documented, the feature-set of ASP is similar to that of PHP and, crucially, provides support for instantiating COM objects and ActiveX controls - for communicating with the CAD and smartcard.  It is on this basis that IIS is considered the most suitable server for this project.

A number of test ASP pages have been created - for example to query a database and represent a recordset on a web page.  This has been carried out using, for the time being, PWS on Windows 98, as no NT machines are currently available for testing purposes.

3.2	Protocols

Initially, the protocols required to serve web content were considered.  Subsequently, thought was given to serving the site to mobile devices.

3.2.1	HTTP/HTTPS

HTTP is the standard protocol for requesting and receiving unencrypted data over the Internet, using the HTML markup language for web content.  All of the web servers considered previously serve pages via HTTP as their fundamental function.  The transfer of private or sensitive data requires encryption to be in place, and thus for a Secure Socket Layer (SSL) to be imposed within the communication system (involving the generation of public/private key sets, session keys, etc.).  This can also be achieved in both Apache and IIS, and will probably be of use in the project in transmitting sensitive data such as a user address.

3.2.2	WAP

WAP (Wireless Application Protocol) is a protocol by which devices such as mobile phones can access Internet sites.  Information is served using a different language, WML, which has been created with the constraints of mobile devices in mind - small screens, awkward keyboards, etc.  The devices themselves communicate with a WAP Gateway using the WAP protocol, but this gateway is itself present on the Internet, and requests WML pages via use of HTTP.  Consequently, it is possible for standard HTTP servers to provide WAP content by appropriate configuration (simply setting the MIME types correctly).  Example WML pages have been successfully created, served using Apache, and tested using a real WAP-enabled phone.

Although the use of WAP within this project is somewhat dubious, and perhaps overly ambitious in terms of timing consideration, it will nonetheless be considered as an alternative method for accessing the E-commerce site.  Given that all GSM phones contain smartcards (their SIM’s), and that some of these are programmable, it would seem feasible, at least in theory, that the smartcard payment mechanism used for the web site could be extended so that the electronic wallet is stored on the SIM and the transfer of value takes place over WAP.

The feasibility for using WAP and programming SIM’s will be assessed as the project progresses, and time constraints become more apparent.

3.3	Additional Technologies

3.3.1	ODBC Database Connections / SQL Queries

A standard method for programs to communicate with databases, in both Windows and UNIX environments, appears to be via ODBC connections.  Given the need for an updateable database of products and services, a connection needs to be made from the web server to a database.  This has been successfully achieved on the Windows 98 development machine by setting up a system ODBC connection to an Access database of products, and creation of an ASP script to retrieve the data contained within the database.

Retrieval and manipulation of data is achieved by use of SQL statements, and basic research has been carried out into the keywords required for selection, updation, insertion, etc.

3.3.2	Cookies

Cookies provide a method for storing small amounts of data on a user’s computer, which are automatically sent as part of the HTTP headers in any URL request to a given site.  It has been determined how to use ASP’s to create cookies on the client’s computer, then read their value and thus identify individual users.

Through use of this mechanism, it will be possible to remember individual users’ preferences and current shopping basket contents.

3.3.3	XML

In a system serving the same data in a variety of formats (e.g. in HTML and WML), there appears to be inherent benefit in storing this data in an more abstract XML form.  Such data can then be easily transformed into an appropriate markup language, as required, using appropriate stylesheets or XSL’s.

ASP’s have been created which take data stored in an XML format, and apply an XSL to render this as HTML.

It is currently unclear as to whether the use of XML would be advantageous within this project.  Given that XML is a data format, and thus would ideally be the format in which data is stored, the fact that a database will instead be at the back-end of this system may imply that use of XML will be superfluous (e.g. if an ASP was written to pull data from the database and dynamically generate HTML, it would probably be more simple to create a second ASP to represent that data as WML, instead of creating two XSL’s - one each for HTML and WML).  The feasibility of the use of XML needs to be investigated further.

4	Smartcard Payment Mechanism

It was initially the intention that Mondex be used as the electronic wallet application from which payments could be made on the site.  However, following weeks of attempted contact, it appears that Mondex International will not release the specification of the application to the university.  Consequently, it will probably be impossible to use this, unless its operation can somehow otherwise be determined.

Therefore, it would appear that it will be necessary to create a bespoke wallet application on a smartcard of some description.  Research is continuing into which card types an application might be developed for - limited almost entirely by the availability and cost of various development kits.

At the time of writing, Mr. Miller is attempting to source a MULTOS or Java Card kit from Hitachi, whilst I am attempting to gain information on equivalent kits (and prices) from Bull and Gemplus.