Michael Hollander BSc Computer Science (Industry) 2006

Transcription

Enhancing Customers’ Experiences
through the Integration of RFID
within Intelligent Mashups
Michael Hollander
BSc Computer Science (Industry)
2006 / 2007
The candidate confirms that the work submitted is their own and the appropriate
credit has been given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source
may be considered as plagiarism.
(Signature of student) _______________________________
Summary
This report details the analysis, design, implementation and evaluation of a prototype to
examine how RFID can be used within Intelligent Mashups to enhance customers’
experiences.
First the background of Intelligent Mashups and RFID is discussed. Following this an
appropriate approach to the project is researched and decided upon, including the most
appropriate methodology to develop the application. Requirements are then gathered from
devised shopping scenarios and finally the chosen methodology is applied, and the resultant
application evaluated.
i
Acknowledgements
With thanks to my project supervisor, Dr. Vania Dimitrova for all her help in this project. I
am also grateful to Prof. Peter Dew for his advice on the Mid-Project report as well as during
the progress meeting.
I would also like to thank Dr. Nick Efford, focus group participants as well as everyone else
who participated in the product questionnaire, for their time and feedback.
Finally, a big thanks to my family and friends who have supported me during the hard but
also the good times at University.
ii
Table of Contents
Summary.................................................................................................... i
Table of Contents .................................................................................... iii
1
2
3
Introduction...................................................................................- 1 1.1
Problem Definition.................................................................................... - 1 -
1.2
Project Aim ............................................................................................... - 2 -
1.3
Objectives.................................................................................................. - 2 -
1.4
Relevance to Degree Programme ............................................................. - 2 -
1.5
Deliverables .............................................................................................. - 2 -
Project Methodology.....................................................................- 3 2.1
Introduction............................................................................................... - 3 -
2.2
Chosen Methodology ................................................................................ - 3 -
Background Research...................................................................- 5 3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
4
Web 2.0 and Intelligent Mashups.............................................................. - 5 What is Web 2.0?.............................................................................................- 5 What are Intelligent Mashups? ........................................................................- 7 Why are Intelligent Mashups important?.........................................................- 7 Mashup Categories ..........................................................................................- 7 -
RFID within Intelligent Mashups.............................................................. - 8 What is RFID? .................................................................................................- 9 RFID vs. Barcode ............................................................................................- 9 RFID Formats and Standards.........................................................................- 11 Example RFID Applications..........................................................................- 11 -
RFID Mashups ........................................................................................ - 12 -
Problem Analysis ........................................................................- 14 4.1
Online data sources ................................................................................ - 14 -
4.2
Application Scenarios ............................................................................. - 15 -
4.3
Simulation Environment.......................................................................... - 16 -
4.4
RFID technologies .................................................................................. - 17 -
4.5
Database Technologies........................................................................... - 17 -
4.5.1
Data Selection................................................................................................- 17 -
iii
4.5.2
5
Client-Server technologies...................................................................... - 19 -
4.7
General Architecture .............................................................................. - 20 -
4.8
Conclusion .............................................................................................. - 21 -
Iteration 1: Feasibility of the Architecture...............................- 22 5.1
Goals ....................................................................................................... - 22 -
5.2
Design ..................................................................................................... - 22 -
5.2.1
5.2.2
6
Implementation ....................................................................................... - 24 -
5.4
Unit Testing............................................................................................. - 25 -
Iteration 2: Matching Application Scenarios ...........................- 27 6.1
Goals ....................................................................................................... - 27 -
6.2
Design ..................................................................................................... - 27 -
6.3
Implementation ....................................................................................... - 29 -
6.4
Evaluation ............................................................................................... - 31 Procedures and Materials...............................................................................- 32 Participants ....................................................................................................- 32 Results against Evaluation Objectives...........................................................- 32 Implications for the Third Iteration ...............................................................- 35 -
Iteration 3: Interfacing with a Mobile Device..........................- 36 7.1
Goals ....................................................................................................... - 36 -
7.2
Design ..................................................................................................... - 36 -
7.3
Implementation ....................................................................................... - 38 -
7.4
Evaluation ............................................................................................... - 41 -
7.4.1
7.4.2
7.4.3
7.4.4
8
Client architecture:.........................................................................................- 22 Mashup Server architecture: ..........................................................................- 23 -
5.3
6.4.1
6.4.2
6.4.3
6.4.4
7
Chosen Database Software ............................................................................- 18 -
4.6
Procedures and Materials...............................................................................- 42 Participants ....................................................................................................- 42 Data Collection and Analysis ........................................................................- 42 Results against Evaluation Objectives...........................................................- 43 -
Evaluation ....................................................................................- 44 8.1
User Prototype Evaluation ..................................................................... - 44 -
8.2
Minimum Requirements and Extensions................................................. - 45 -
8.3
Project Methodology............................................................................... - 46 -
8.4
Project Schedule ..................................................................................... - 46 -
8.5
Business Case Consideration.................................................................. - 47 -
iv
8.6
9
Further Work .......................................................................................... - 47 -
Conclusion....................................................................................- 49 9.1
Feasibility of Combining RFID and Mashups ........................................ - 49 -
9.2
Comparison to Other Solutions .............................................................. - 49 -
9.3
Summary ................................................................................................. - 50 -
References...........................................................................................- 51 Appendix A – Personal Reflection....................................................- 54 Appendix B - Project Methodology..................................................- 55 Appendix C – Java Client Class Diagram .......................................- 59 Appendix D – Amazon and Yahoo Web Services...........................- 60 Appendix E - Transcript of Focus Group .......................................- 65 Appendix F – Usability Testing ........................................................- 68 Appendix G –Expert Interview Material ........................................- 71 Appendix H – RFID Workshop Correspondence...........................- 74 Appendix I – Product_Info Table ....................................................- 75 Appendix J – Unit Testing ................................................................- 76 -
v
1
Introduction
1.1 Problem Definition
Current technological advances such as the Internet have allowed people to become
increasingly aware of the growing availability of data. In addition, the mobile revolution and
the development of the mobile web have transformed how we gather this information.
As a result, in today’s consumer-driven world customers are enduring to get the best value for
their money whilst shopping. Currently, they achieve this by gathering information from
several sources, such as magazines or online media, regarding a desired product. The
information contained within these sources is then manually filtered by the consumer and the
best product is chosen. This is a highly tedious process due to the large number of search
results, thereby restricting consumers to research products before leaving their homes.
The mobile revolution has now enabled users to access the internet on the go through various
mediums such as mobile phones and PocketPC’s, thus removing the restriction of searching
for product information prior to entering a shop. As consumers search for the best and
cheapest product deals available on the market, identification technologies such as barcode
scanning can help facilitate the process of achieving this. At present, companies such as
Virgin [39] have incorporated this identification technology within mobile web browsing, to
allow consumers to research a desired product on the go.
This project aims to improve on the consumer experience when using mobile devices to
retrieve product information whilst shopping. It will therefore utilise Radio Frequency
Identification (RFID) technology and retailer’s merchandise data to automatically identify
products and retrieve information from retailers’ databases. As opposed to other identification
technologies, RFID is of automated nature and as a result allows a product to be in close
proximity of a reader to be successfully identified. Having retrieved the product description,
data will be pulled from multiple data sources within the internet and filtered to present the
user with the most relevant information. In essence this will help bridge the gap between
products contained within the physical world and data retrieved from the virtual online media.
-1-
1.2 Project Aim
The aim of this project is to examine how Radio Frequency Identification (RFID), an
electronic tagging technology, can be used within Intelligent Mashups (Applications
combining data from multiple services) to enhance customers’ experiences. This is to be
illustrated with the use of a prototype.
1.3 Objectives
The objectives of this project are outlined below:
Research different methodologies and decide upon an appropriate one for this project
Research Web 2.0 and Mashups
Review existing RFID applications and formats in order to identify appropriate usage
of RFID for this project
Identify currently available free online data sources
Apply the selected methodology throughout the project
Apply appropriate analysis techniques to determine the system requirements
Develop a prototype showing the potential use of RFID within Intelligent Mashups
Identify and use appropriate evaluation criteria for the prototype
1.4 Relevance to Degree Programme
This project draws upon several modules taught in the second and third year at the
University’s School of Computing. Third year modules GI32 and SY33 were foundation
modules for this project. GI32 gave the author an understanding of personalisation and
ambient or ubiquitous applications which are topics relevant to this project. It also provided
the author with guidance on setting evaluation criteria. SY33 provided knowledge on Web
Services, JavaServer Pages (JSP), MySQL database access as well as XML based
technologies, all of which are methods or technologies that have been used within this project.
1.5 Deliverables
The minimum requirements consist of an Intelligent Mashup prototype which includes a
single web data source and simulated RFID data with a shopping scenario. Possible
extensions consist of integrating a user rating system or integrating more data sources (i.e.
online price comparison).
-2-
2
Project Methodology
2.1 Introduction
This project involved the development of a prototype, for which an appropriate software
methodology was to be chosen. A software methodology or process can be defined as “a set
of activities and associated results which lead to the production of a software product” [1].
There are four activities common to all software methodologies; software specification,
software design and implementation, software validation and software evolution. Consumers
are the category of people who were ultimately going to use the prototype, and were therefore
defined as end-users. Since no specific end-users were specified for this project, there was a
need for opportunistic software development methodologies. This meant that one or more
shopping scenarios were to be designed and shown to end-users in order for the author to
receive feedback and to know which one will be best to pursue.
The author compared different software process models in Appendix B in order to decide
what the most suitable model was going to be for the scope of this project. The Waterfall
approach, evolutionary development (also known as Rapid Application Development (RAD))
and reuse-oriented development have been chosen by the author as appropriate methodologies
to be further looked at. These appeared to be the most relevant methodologies for this type of
project, since they are popular and widely used by developers.
2.2 Chosen Methodology
Using the Waterfall model for this type of project did not seem appropriate, since this project
required flexible requirements change from users. Also, requirements might not have been
obtained until later during the project. Making use of this approach might therefore have led
to expensive post-implementation programming.
RAD might have been an appropriate method to use in this project for defining system
specification, through its iterative approach with regards to flexible change of requirements
and system refinement. Since existing components such as Application Programming
Interfaces (API) had to be used for the scope of this project, Reuse-Oriented Development
seemed like a suitable methodology which could have reduced the amount of software to be
developed.
-3-
Since both RAD and Reuse-Oriented Development were found to include features relevant to
the project prototype, the author decided to produce a custom methodology where features
from both models would be used effectively. Below is a diagram (Fig. 2.3.1) of the redefined
methodology, which was used for the development of the prototype.
Figure 2.3.1: Diagram showing the redefined methodology
The customised methodology can be reflected in the final project schedule (Appendix B Fig.
2) by looking at the Problem Analysis stage. The process starts with the identification and
analysis of free online data sources in order to help identify user-based scenarios which would
then be the basis for a prototype enhancing customers’ experiences. Having justified the
choice of online data sources, user-based scenarios would then to be constructed in the next
stage, reflecting the available data sources. The last phase contained within the problem
analysis section is Component Analysis, where new or existing software or hardware
components are to be identified and as a result created or reused for the development of a
prototype. This stage is part of an iterative cycle where a number of prototype iterations are to
be developed. Therefore, at the start of each of these iterations, new or existing components
can be identified and included in the iteration.
Following the Problem Analysis phase, the prototype to be developed in a number of
iterations is to be designed using the new or reused components identified in the previous
stage. Development and Integration is the next stage, where software which cannot be reused
is to be developed and integrated with the reused components. Finally, the system will be
validated using suitable testing methods or through evaluations based on specified criteria.
After system validation, if required, the whole process of analysing components up to system
validation can be reinitiated.
-4-
3
Background Research
3.1 Web 2.0 and Intelligent Mashups
In order for the reader to understand what Intelligent Mashups are and where these have come
from, it is important to first discuss the broader topic surrounding Mashups. Looking at the
big picture, Intelligent Mashups are part of a large set of trends called “Web 2.0”. In the
following sections, the author will explain what Web 2.0 is all about by giving a definition as
well as the term’s origin and its general principles, through the use of examples. The author
will then continue by defining Intelligent Mashups and by giving examples of existing
Mashups.
3.1.1 What is Web 2.0?
The O’Reilly Radar team defines Web 2.0 as “a set of economic, social, and technology
trends that collectively form the basis for the next generation of the Internet—a more mature,
distinctive medium characterized by user participation, openness, and network effects.”[3]
The term “Web 2.0” refers to the second generation of web applications. It was invented by
O'Reilly Media in 2004 as a title for a series of conferences of which the first one named “The
web as a platform” [4]. The first generation of web applications can be thought of as one
where a webmaster or a group of people could write as well as edit content, and then make
this content available to others. This is quite similar to the way in which books are published.
The Web 2.0 generation, on the other hand, can be thought of as one where anyone can add
their own contents to a shared content base, and where anyone can then also access that space.
O’Reilly discusses the evolution of websites, applications and companies through the use of
examples [5], comparing Web 1.0 efforts such as content management systems, screen
scraping and directories with Web 2.0 alternatives such as Wikis, Web Services and Tagging.
Below is a comparison table, illustrating this evolution to a full participatory web where not
only machines, but also humans can participate. It also shows how Web 2.0 is a two-way
medium, where people are both readers and writers. [6]
-5-
Web 1.0
Web 2.0
Browser bookmarking
Social bookmarking (del.icio.us)
Content Management Systems (Britannica)
Wikipedia
Manual website browsing
RSS feeds subscription
Screen Scraping
Web Services
Directories (Taxonomy)
Tagging (Folksonomy)
Table 3.1.1: Web 1.0 / 2.0 Comparison [6]
The first example of such an evolution is the use of bookmarking. Previously, users were only
able to keep web bookmarks for their own usage, on their PC. With the introduction of Web
2.0, this lead to social bookmarking where users could share their favourite websites with
everyone else online. Del.icio.us is a popular example of social bookmarking where people
can store, share and discover web bookmarks. Web 2.0 also saw a move from traditional
content management systems such as Britannica Online, towards an open collaborative
system allowing participation from any user. Wikipedia is a good example of such an open
system, since it is one of the most popular free collaborative systems available online. Manual
website browsing used to be the only way for people to view websites of their own interest.
With the introduction of RSS1 feeds, users can now subscribe to online services of high
interest to them, and can easily get content updates with the click of a button.
Screen scraping used to be the only way of getting data from a website into your own
application. This required long lines of coding and did not always work. With the introduction
of web services, this quickly changed. The use of Application Programming Interfaces (API)
now allows web developers to easily utilise data from websites for use in their own
applications. An API can be described as an application’s interface designed to make all or
some of its functions available to other applications. Another term part of the Web 2.0
evolution is Folksonomy, which is a method of collaboratively sharing tags with the purpose
of categorising content. The term was coined by Thomas Vander Wal, who believes that in
the next couple of years, companies will adopt tagging widely [7]. Taxonomy on the other
hand, does not allow people to contribute to the categorisation of content. It is a method of
classifying content using controlled vocabulary. Yahoo Directory applies taxonomy to its
website, where users search the web by choosing from a list of categories. Flickr, in contrast,
is a photo sharing website which is known to be one of the first websites that used
folksonomy in order to tag photos.
1
Really Simple Syndication – a format used to publish frequently updated web content
-6-
3.1.2 What are Intelligent Mashups?
Intelligent Mashups can be defined as “applications that combine data from multiple services
to create something new” [8]. They belong to the Web 2.0 set of technology trends, gaining
their popularity by emphasising on interactive user participation and by aggregating and
putting together third-party data to produce a new creative work. The term “Mashup” was
originally borrowed from the pop music scene, where it represents a new song that is mixed
from the vocal and instrumental tracks from two different source songs. [9]
Intelligent Mashups can be characterised as applications which are built using lightweight
web services, in other words services easily understood by anyone wishing to use these,
without the need for a steep learning curve. Combining content therefore takes a fair lower
amount of time and is usually done through the use of rapid prototyping techniques. In
addition to that, many Web site owners provide APIs to make their content and functionality
more easily accessible to developers who often use JavaScript and Asynchronous Java and
XML (AJAX) techniques to build their Mashups.
3.1.3 Why are Intelligent Mashups important?
With the introduction of Mashups, fewer technical skills are needed in order to become a web
developer. This means that any basic to advanced programmer can potentially turn their
creativity into innovation [10]. As a result, Mashups can bring big changes for software
companies, web sites and everyone else online. The web is no longer just a collection of
pages, but it is becoming a sort of global operating system [11], where different components
of that system can be pulled out and used together with other elements.
3.1.4 Mashup Categories
There are four different Mashup genres [9] which are most prominent on the web, the most
popular being mapping Mashups. The author will discuss each of these in turn, using an
appropriate example for every genre.
Mapping Mashups: These became popular since Google’s release of its Maps API. This
allowed web developers to mash any kind of data onto maps. An example of such a Mashup
is housingmaps.com [12], which locates Craigslist’s real estate “for rent” and “for sale” pages
onto Google maps. Other API providers such as Yahoo and Microsoft shortly followed with
their own maps API.
-7-
Photo and Video Mashups: Social networking sites such as Flickr provide their API to web
developers who can use their metadata in order to mash pictures or videos with other
information that can be associated with it. FlickrSoduku [13] is a good example of such a
Mashup, and uses random pictures of numbers from the Flickr website in order to create a
Soduku puzzle. The correct pictures are taken by using tags associated with Flickr pictures
which represent numbers.
Search and Shopping Mashups: Before public APIs were released, comparative shopping
websites such as Froogle.com had to use screen scraping methods in order to obtain
comparative price data from online retailers. With the release of their public API’s, popular
search engine providers as well as consumer marketplaces such as Amazon and eBay made it
easier for developers to easily access their contents. Early Miser [14] is a Shopping Mashup
which is built on top of these shopping APIs. It offers comparison shopping as well as custom
product lists, feeds and tagging.
News Mashups: News sources such as the BBC or Reuters provide RSS feeds for people to
subscribe to in order for them to obtain the latest news. These feeds can be used as data
sources for the creation of a News Mashup. An example of such a Mashup is BBC News
Maps [15], which combines BBC news feed information obtained in the last 12 hours, with
Google Maps.
Having looked at the major Mashup categories available on the web, the next step is to see
how RFID can be integrated within each of these Mashup genres, with the aim of identifying
a use case to illustrate RFID in Mashups. In order to do this, research of what RFID is, what
data formats it entails, and possible applications including this technology, has to be made.
3.2 RFID within Intelligent Mashups
This section will examine how RFID can be integrated within Intelligent Mashups (defined in
section 3.1.2), with the intention of identifying a use case to illustrate RFID in Mashups. The
review will start by defining RFID and its underlying structure, and will then discuss the
advantages RFID usage has over existing Automatic Identification technology used in today’s
industry. Data formats contained within RFID will then be covered, and existing RFID
applications will be explored.
-8-
3.2.1 What is RFID?
Radio Frequency Identification (RFID) is an electronic tagging technology which allows
people, objects or places to be automatically and precisely identified at a distance without a
direct line-of-sight, using electromagnetic fields. [16] This proven technology has been
around since the 1970s, but up to recently has been too limited and too expensive for practical
use. This is why the Auto-ID Center, a centre for continued research into the nature and use of
RFID, was formed in 1999, with the help of scientists at the Massachusetts Institute of
Technology (MIT). [17] Their mission was to design an open source system that would
connect all physical objects to the global Internet, forming an intelligent infrastructure. [18]
Using an Electronic Product Code (EPC) encoded into tags, these physical objects can be
uniquely identified with the use of an RFID reader device. There exist two types of RFID
tags: active and passive. Active tags are powered by a battery, whereas passive tags become
“illuminated” and communicate their information (a single identifying number) when these
are in close presence of a reader. [19]
RFID is part of a range of technologies, such as barcodes and contact memory, called
Automatic Identification (Auto-ID or AIT), which are used to help devices identify objects.
Out of these technologies, two – RFID and barcodes – have become most popular and are
widely used nowadays. By comparing these two technologies, the advantages of RFID can be
identified and its suitability for this project will be justified.
3.2.2 RFID vs. Barcode
Barcode is a technology that has been around for more than three decades, and it is still being
used by retailers, manufacturers and logistics as a quick and easy way to track inventory. [20]
However, with the constant price drop of RFID equipment and with its technologically
advanced characteristics, barcode seems to soon be replaced by this fast-growing Radio
Frequency technology. In order for the reader to gain a better understanding of the advantages
RFID has over barcodes, Patrick Sweeney [17] suggests comparing the two different
technologies against specified criteria;
Reading Distance: A big advantage of RFID over barcode is that it does not require line-ofsight for a tag to be read. Tags located inside containers or behind walls for example can still
be read. Also, barcodes can only pick up a signal from a range of a few feet. RFID tags on the
other hand can communicate between a few millimetres and up to more than 100 metres
(depending if a tag is passive/active). The following example shows the advantage of using
-9-
RFID over Barcode, when combined with Intelligent Mashups. A household mirror could
integrate RFID technology in order to respond to people’s presence. When a person would
bring a tagged piece of clothing in front of the mirror, content would be displayed on that
mirror with a description of the garment along with suggested possible accessories matching
that item, taken from the brand’s website. On the other hand, using barcode would require the
person to manually scan the item of clothing. In addition, it might also not provide enough
information about the item for the website to return information.
Number of reads at a time: With barcode, only one item can be scanned at a time. RFID
allows for nearly hundreds of tags to be read simultaneously. This can greatly reduce the time
required to scan a large number of items. Simultaneous tagging can prove useful with
Intelligent Mashups; a consumer might use an RFID-integrated device to scan a food shelf
containing RFID-tagged fruit and vegetables. With the click of a button, the tagged items
could be scanned simultaneously and data about these would be used to search for possible
online recipes. These would then be returned to the consumer for advice on which ingredients
to buy to make up a recipe. However, this example may be too challenging and not feasible
for the scope of this project.
Data modification: Barcodes cannot be written to or be modified, whereas some RFID tags
(Class 1 tags) are modifiable. The ability to modify data can be cost-effective (re-use), but can
also be useful when additional information is obtained for an item over the duration of its
production cycle. These advantages can be valuable when used together with Intelligent
Mashups; having got the permission to append information to a tag in a retail shop for
example, consumers could write their own reviews for a particular item they have purchased.
The online link to their review could then be written to the item’s tag, allowing other buyers
to later scan it and obtain the review on their mobile device used to scan RFID tags.
Data storage: Linear barcodes can only store up to 30 characters, as opposed to RFID tags
which can store up to 8MB of data. This allows tags to contain larger serial numbers to ensure
uniqueness of an item. Data storage is a crucial element for the success of Intelligent
Mashups. Depending on the amount of data and quality of data associated with a tag, it can be
used to integrate with Mashups in a very innovative way. In itself, the RFID tag contains
nothing but a unique ID number, but when connected to an Internet database, this anonymous
number will suddenly come to life.
The next section will review existing RFID formats and standards, which are essential for the
development of a prototype in this project.
- 10 -
3.2.3 RFID Formats and Standards
Data availability plays a significant part in Intelligent Mashups. Therefore, appropriate
formats and standards need to be identified in order to maximise their usefulness towards
users. Having standards for new technology such as RFID can help incorporate the
technology into people’s culture, with rules being defined for using it. [21] Standards are also
needed to make sure information is shared appropriately and effectively. This is why the
Electronic Product Code (EPC) was created by the Auto-ID Center, as a standard for this
technology. The EPCglobal2 is an organisation which supports the use of RFID by
determining standards and protocols, and by allocating EPC numbers to end-users.
RFID tags are encoded with an Electronic Product Code, which is a globally-unique identifier
for the object being tagged. When scanning a tagged item, the EPC obtained by the reader can
then be used to search an EPC database for more information on the item. An EPC tag usually
contains a 96-bit unique identifier, which can be structured in four separate parts [17]; the
first partition is the Header, which contains 8-bit of information on the length and structure of
the code being used. The EPC Manager Number partition then identifies the company or
company entity, spanning 28-bit. The third partition, taking up the next 24-bit, is the Object
Class which is similar to a stock-keeping unit (SKU). The last element and 36-bit of the EPC
is the Serial Number, which is unique for all objects of that class.
3.2.4 Example RFID Applications
RFID being a fast-growing technology has continuously been used for many different
purposes, from tracking cows3 to unlocking hotel doors4. Since RFID readers and tags are
becoming less expensive each year, more companies are becoming interested in using this
technology. There are already a considerable number of companies in different industry
sectors which are employing RFID to save on their overall company costs. This section will
investigate different types of RFID applications through the use of suitable examples.
RFID in Airports for baggage handling [22]: There are already a number of airports, such as
Hong Kong International Airport and Las Vegas McCarran International Airport, which
employ RFID with the aim of improving their baggage service. RFID allows tagged luggage
to be identified without being in line-of-sight with a reader. Tags can also be updated in order
to reflect on a passenger’s itinerary changes. These advantages reduce baggage mishandling
2
http://www.epcglobalinc.org
Brandt: Tracking its beef with RFID - http://www.brandtbeef.com
4
Assa Abloy: VingCard RFID - http://www.assaabloy.com
3
- 11 -
and therefore provide for better customer service, making sure airports obtain a return on their
investment in RFID.
RFID in Water Parks [23]: Great Wolf Resorts, an American firm, has this year launched
RFID within one of its six water parks. New guests at the Pennsylvania resort will be issued
RFID wristbands which they can use for keyless room entry, food purchase, game vouchers
and other available services. The wristband will also act as a way of identifying each guest
within the resort. As with the previous example, the aim of this company is to provide better
customer satisfaction through the use of RFID. Guests no longer need to carry their wallets,
nor do they need to have their room card handy, since payments and room entry is all done
through the use of their RFID-tagged wristbands.
RFID in Car Parks [24]: Hoboken, a city located in New Jersey, US has recently armed its
parking-enforcement officers with RFID-enabled interrogators. The officers can easily
determine whether a car is legally parked with a valid permit, by waving the handheld when
standing alongside the vehicle. Previously, officers had to manually look for a permit, leading
to additional processing time. Using RFID for this task will therefore save the city valuable
time and a considerable amount of money.
3.3 RFID Mashups
There seems to be only one Mashup which integrates RFID data – this shows that the area is
not sufficiently examined and therefore allows for opportunities. This project will examine
such opportunities through the identification of suitable APIs, leading to the creation of
scenarios. The best suitable scenarios will then be used to develop a prototype RFID Mashup.
Sherelog, [25] the RFID Mashup found to be the only one of its kind, is a system that fetches
data from a popular RFID train pass in Japan named “Suica”. It will visualise personal trainride records obtained from this train pass onto Google Maps. Suica uses a read/write RFID
tag which can store a small number of train-ride records. The developers of this Intelligent
Mashup had two clear intentions for this system - the first one being to help people remember
their travel histories and to reflect upon them. They also wanted to create unique
communication opportunities by making it extremely simple to share personal travel histories.
- 12 -
Figure 3.3.1: Suica travel history on Google
Maps [26]
Figure 3.3.2: Sharelog system shown at
Japan Media Arts Festival [25]
- 13 -
4
Problem Analysis
Having researched the topics of Mashups and RFID technology, the aim of this chapter is to
provide the basis for a feasible prototype which would enhance customers’ experiences. This
stage initially consists of identifying online data sources offering shopping services, such as
price information or ratings for particular items to enhance the customer experience. Once
appropriate sources have been identified, a shopping scenario can be devised. The scenario
will be used as the basis for building an Intelligent Mashup prototype, and will be referred to
during the different phases of the application.
4.1 Online data sources
Having searched for free online shopping data sources, a total of nine sources listed as
shopping related services were identified at ProgrammableWeb [27]. Table 4.1 shows a list
containing these services.
Source
Service offered
Commision Junction
Online affiliate programs
UPC Database
UPC lookup service
Windows Live Expo
Online classifieds service
Google Base
Marketplace and structured data service
SwapThing
Community driven swapping site
Yahoo Shopping
Shopping Services
Zazzle
On-demand product creation service
Google checkout
Shopping cart services
Amazon E-commerce
Shopping Services
Table 4.1: List of shopping-related services
All of these services have been tried by the author to see if they would provide useful
information on a particular shop item. Only Amazon E-commerce and Yahoo Shopping were
found to provide useful information though their respected service, such as price information,
ratings, related items as well as product images. All other services did not provide standard
shopping services, i.e. consumer oriented services where information can be retrieved on
retail products. Instead, they offered information intended for other purposes such as
advertising, publishing, real estate, job events and others.
- 14 -
4.2 Application Scenarios
Now that two usable data sources have been identified (Amazon E-commerce and Yahoo
Shopping), the requirements of the application needs to be devised. It was decided that the
creation of scenarios would be the most suitable method to do this, as opposed to other means
such as gathering requirements from a retailer or carrying out a focus group with consumers
to elicit requirements. This is to some extent for the reason that a scenario gives the users a
feel for what they will get from the proposed application, whereas obtaining a list of
requirements from retailers or consumers does not [28]. Interactions specified within a
scenario can also prove useful as a guide for producing system testing [29].
Two scenarios have been created on the basis of information retrieved from the two
aforementioned web services. Both scenarios demonstrate how an Intelligent Mashup
application could be used by describing a user's view of interactions with the system. By
walking through these scenarios, the reader will gain a better understanding of the
requirements as well as the interactions that occur within the application.
Scenario 1:
A user is interested in buying a book as a present for a friend. In possession of an RFIDintegrated mobile device such as a Personal Data Assistant (PDA) with an integrated RFID
reader, the user may enter a bookshop and start looking at a range of books which he knows
his friend already owns. Upon finding one of these books, the user would like to know what
other similar items he could buy, that his friend does not possess. The user picks up the item
of interest, switches on his mobile device and scans the specific item using the device’s builtin RFID reader. Once scanned, the device will communicate with the shop’s database,
requesting basic information on that item. Upon receiving this information, the device will
connect to a Mashup server located in a remote area, requesting more information on the
scanned product. The user, unaware of these occurring communications, browses to the
Mashup website with the help of the personal device. The website allows the user to retrieve
additional information on an item by selecting from a list of scanned items. Once selected, the
web page shows the user a list of similar items, along with an image, price and rating for
each of these items.
Scenario 2:
A user is interested in buying a DVD player for his own interest. In possession of an RFIDintegrated mobile device such as a PDA with an integrated RFID reader, the user may enter
an electronics shop and start looking at a range of available DVD players. Upon finding an
- 15 -
item of interest, the user would like to know what other customers have said about that
particular item, and whether buying the product online would be cheaper. The shop might be
crowded, and there may not be a shop assistant nearby or available to the user to ask for
assistance. Additionally, an assistant would typically be prohibited to encourage customers to
buy online. Bearing these factors in mind, the user instead picks up an item of interest,
switches on his mobile device and scans the specific item using the device’s built-in RFID
reader. Once scanned, the device will communicate with the shop’s database, requesting
basic information on that item. Upon receiving this information, the device will connect to a
Mashup server located in a remote area, requesting more information on the scanned
product. The user, unaware of these occurring communications, browses to the Mashup
website with the help of the personal device. The website allows the user to retrieve
additional information on an item by selecting from a list of scanned items. Once selected, the
user is presented with information on the scanned item, including online prices and ratings
obtained from Amazon and Yahoo web services.
Although these scenarios show usage of the application from a single customer's perspective,
the Intelligent Mashup application should support a large number of shoppers making
simultaneous requests.
4.3 Simulation Environment
Since the prototype will be based on the aforementioned shopping scenario, simulated data
needs to be produced in order to illustrate a realistic application of that scenario. Furthermore,
a simulation was needed since additional equipment was purchased. Therefore, prior to the
system design stage, it is necessary to consider the different components to be used within a
simulation environment. Both the design and implementation phase of the prototype follow an
iterative approach through the development of three prototypes.
Smith RD [30] defines a simulation as “the process of designing a model of a real or imagined
system and conducting experiments with that model.” In the case of this project, the model is
a collection of hardware and software components which is used to mimic the behaviour of
realistic shopping scenarios. For these scenarios, it is assumed that a mobile device contains
an integrated RFID reader as well as an online browser, and that the considered shop has
implemented RFID on its entire merchandise. One of the major advantages of simulations is
that they are able to provide practical feedback to users before the actual real world system is
designed. This in turn allows the developer to determine whether the design is correct and
- 16 -
efficient before the real system is developed. The following components will be used as part
of the simulation, though additional components will be discussed later during each of the
prototype iterations, as the product evolves in its functionality as well as its efficiency.
4.4 RFID technologies
In order to make the simulation as realistic as possible, an RFID toolkit was purchased from
Phidgets Inc [31]. The toolkit includes an RFID reader as well as eight RFID tags, and it only
allows for USB communication with a paired device, using a provided USB cable. The
advantage of using the PhidgetRFID toolkit is that it provides the developer with a set of APIs
for different programming languages. It is also extremely easy to install, and is one of the
cheapest RFID readers available on the market. The limitations associated with the toolkit are
that its read distance is 7.5cm, tags cannot be re-written and two tags cannot be read at the
same time. Each RFID tag contains a unique product code, which can be read by the reader
and consequently passed back to an application. The product code of tags included within the
RFID toolkit is however not structured in the same way as specified in section 3.2.3, where
RFID formats were discussed. This is because the toolkit is intended for low-budget projects
where mass usage of tags is not considered. Each product code associated to a tag is made up
of ten characters, and is not structured in four different parts as in the 96-bit unique identifier
contained within a standard tag.
4.5 Database Technologies
4.5.1 Data Selection
The first and most important component within the simulation is the data. Without data, the
system will not have any interest to the end-user. Since information is to be retrieved from
Amazon ECS and Yahoo! Shopping, the author decided to look up eight different items which
would each exist in both web sources, and for which at least a single user rating exists. Since
the purchase of additional tags is relatively expensive, it was decided that only the available
tags would be used, as mentioned in section 4.4. Out of the eight items, four were chosen to
be Books and the remaining Electronics items. These were most common categories which
consumers would normally consider looking up on the internet prior to making a purchase,
and for which offering more details would be relevant. Furthermore, both categories match
the scenarios created in section 4.2; the first scenario relates to the purchase of an electronics
item, and the second relates to the acquisition of a book.
- 17 -
The simulation is based on the assumption that a shop contains RFID-tagged items linked to a
database containing more information on each item. Therefore, a database will be created
containing simulated data on items described above, in order to follow that assumption. The
shop database will contain a single table with 3 columns; i) EPC – unique identifier for the
item ii) Description – full product title, iii) Category – type of item. This data structure is
similar to the one created on UPC Database [32], which is a public database that indexes
items by their barcode. As both RFID and barcode items can be retrieved using a unique
identifier, a similar structure was chosen for use in the simulated shop database. Below is a
table containing two simulated entries, illustrating the way item details will be stored within
the database.
EPC
Description
Category
01023899ea
J.K. Rowling Harry Potter
Books
and the Order of the Phoenix
010238840c
Sandisk SDCZ2-512-A10
Electronics
USB Flash Drive
Table 4.5.1: Stored items in shop database
4.5.2 Chosen Database Software
As mentioned in the previous section, a database will be created to represent a shop’s
database. MySQL Server 5.0, Microsoft SQL Server 2005 Express and Oracle Database 10g
Express Edition are the only three major database packages which are freely available online,
which is why the author has considered these for possible use within the prototype simulation.
The author also already had previous experience with all three database packages, and is
looking for ease of installation, platform-independence as well as ease of use as important
factors for choosing the right software for the development of this prototype. Additionally,
advanced database functionalities are not required for the scope of the product. Having
previously used each of these packages, the author considered MySQL Database Server to be
the easiest and quickest to install. Out of the three vendors, only MySQL and Oracle provide
platform independent database software. Microsoft software being platform dependent limits
it usage to Windows-based operating systems only. With regards to ease of use, Oracle and
Microsoft both offer a graphical interface for their database, which makes it easy to produce
queries. MySQL on the other hand does not provide a graphical interface, but once the
developer becomes familiar with its SQL syntax, the command-line interface turns out to be
very handy and fast-responding.
- 18 -
Based on the author’s previous experience as well as characteristics such as ease of
installation, platform-independence and ease of use, MySQL has been chosen as the database
package to be used for the web application prototype. The fact that many big Web 2.0
applications such as Wikipedia, YouTube and Flickr have decided to rely on MySQL
databases is another reason for using the technology within this project scope. [33]
.
4.6 Client-Server technologies
Java has been chosen as the main programming language to be used for the prototype
simulation. It contains extensive libraries for XML processing, and can be integrated within
servlets in order to provide a front-end to the user. The use of XML will be essential in order
to retrieve information from the web services specified in section 4.1. Alternatives such as the
.NET Compact Framework and Java 2 Mobile Edition (J2ME) have been considered for
mobile development, but were unfamiliar to the author. Since the prototype is to be simulated,
the author decided to have the development done on a desktop PC instead of a mobile device.
Also, since MySQL has been chosen as the database software to be used for the simulation,
its combination with Java can be justified for a number of reasons. Both are open source, and
MySQL includes a native java driver that converts Java Database Connectivity (JDBC) calls
into MySQL’s network protocol. Since Java has also been the only language extensively used
by the author over the course of his studies, it was decided that this would be the best choice
for developing a web application.
Part of the simulation is to provide the user with a web-based front-end where information on
a scanned item can be presented to the user, as stated in the shopping scenario. Since the
prototype is to be used on a mobile device, it is important to have a web server which can
process a considerable amount of information such that the device itself can avoid doing
extensive processing. Apache Tomcat is an open source, Java-based web container that runs
Servlet and JavaServer Page (JSP) web applications. As a web container, Tomcat is typically
used on top of an Apache web server. It can host web applications which contain Java
snippets embedded within HTML code. Microsoft Internet Information Server (IIS) is another
type of web server which solely runs on a Windows environment, as opposed to Apache
being platform independent. Active Server Pages (ASP) is Microsoft’s equivalent to JSP in
that both technologies provide the ability to create dynamically generated web content. ASP
however, does not allow use of the Java language within its framework. Instead, it does
support code written in Visual Basic, C++, C# or Perl. None of these languages have been
extensively used by the author. The author possesses prior practical knowledge of JSP as well
- 19 -
as Tomcat from a third year module (Building Distributed Systems). Since IIS and ASP were
never previously encountered by the author, the choice of using the open source alternative is
justified. Additionally, since Java will be used for the client-side development, using it on the
server-side as well will arrange for ease of integration.
4.7 General Architecture
Since the essential components for the simulation have been identified in the previous
sections, a proposed general architecture can be devised for the prototype, taking the shopping
scenarios from section 4.2 into consideration. The sequence diagram in Fig. 4.7 shows the
interactions that occur between three different entities, namely a client, a Mashup server and a
database server. This abstract diagram hides the complexities behind each entity’s interaction
within the system, in order to give a general overview of the system.
Figure 4.7: Abstract sequence diagram
The client is the first point of interaction within the system. The user will use a PDA or
Smartphone with an integrated RFID reader, to scan a shop’s item equipped with an RFID
tag. Once an item has been scanned with the mobile device, the EPC number associated with
the item will be sent to the shop’s database server, as stated in the shopping scenario. At that
time, the client will request more information on the item from the database. Once receiving
the request, the server will locate information on the product and will return it back to the
client. Now that the client is equipped with useful information on the product, and not just
with a 40-bit number, it can contact the Mashup server. This is a web server which accepts
product information as an input parameter, and which returns ratings, similar items and price
information for the selected product. Once the Mashup server receives the product
information, it will obtain this information from Yahoo! Shopping as well as the Amazon
shopping website. It will then return this data back to the client.
- 20 -
4.8 Conclusion
The analysis in this chapter led to the identification of web data sources followed by the
creation of two shopping scenarios, after the decision has been made to build a prototype
which would enhance customers’ experiences. A simulation environment was constructed,
and hardware and software components have been discovered and added to the simulation.
Once the simulation environment has been set up, a general architecture was generated to
match the scenarios.
- 21 -
5
Iteration 1: Feasibility of the Architecture
5.1 Goals
The goal of this prototype is to validate the feasibility of the general architecture stated in
section 4.7, by implementing two sets of functionalities. The primary functionalities are to
have the client interact with the RFID reader, and to have the client connect to the shop’s
database (to be created), passing it the results obtained from the reader. These goals are
focused around client interactions only, leaving server-side interactions for later, once the
client is equipped with enough information on a scanned item. The secondary goals consist of
setting up a web server and having it interact with both web data sources chosen in section
4.1, displaying retrieved information back to the client’s web interface. The author is not
aiming to provide a fully integrated solution as yet, but is instead focusing on having different
parts of the system work correctly.
5.2 Design
5.2.1 Client architecture:
Below is a sequence diagram (Fig. 5.2.1) depicting client interactions. A java program is run
on the client’s PDA or Smartphone as soon as the device is switched on. The program will
first enable the integrated RFID reader for incoming tag reads. When a tag is within the
reader’s read range, it will be scanned, and will consequently return its EPC number (defined
in section 3.2.3) to the reader. The RFID reader will then send this number back to the Java
program. The EPC number along with the product information associated to the tags’ item is
then written into a text file on the handheld device, after having communicated and matched
the EPC code with the shop database. For every tag that is read, the process above should be
repeated.
- 22 -
Figure 5.2.1: Client sequence diagram - the activities are shown in sequential order
5.2.2 Mashup Server architecture:
The Mashup server is a web server which provides a web interface to the client, allowing for
instant retrieval of rating, price and related items information. What distinguishes the Mashup
server from a traditional web server is the fact that it allows the creation, deployment and
consumption of web services. Interactions with the server are shown in Fig. 5.2.2. After each
scanned item’s description has been stored into a text file, the client can start a web browser
on the handheld device, and can then connect to the Mashup website. The website provides a
text field which allows the user to input a path name, referring it to the text file previously
generated by the Java program. It also provides a ‘submit’ button which, when pressed, will
have the server transfer the local file onto the Mashup server. Once the file has been
transferred, the server will generate a dropdown menu with a list of item names, of which
only one can be selected by the user for rating, price and similar items information retrieval.
Now that the Mashup server is aware of the selected product, it can access each web API
individually and use the product description in order to obtain more details for the specific
item. Once all of this information is retrieved from these web sources, the results will be sent
back to the client browser.
- 23 -
Figure 5.2.2: Mashup Server sequence diagram
5.3 Implementation
The first set of functionalities as stated in section 5.1 consists of having the client device
interact with the RFID reader as well as with the shop database. This has been done through
the creation of two Java classes contained within the mobile device (see Appendix C Fig. 1
for a class diagram); RFIDScan - this class listens for RFID tag scans by enabling the RFID
reader and by listening for incoming scans. Once a scan has been recorded, the class will
record the EPC number associated with that scan. ProductInfo - this class will use the EPC
code obtained from RFIDScan in order to request the product’s description, to be contained
within the shop database. In order to perform an SQL query to accomplish this task, the actual
shop database had to be created. The database structure as well as the software to be used for
it was already covered in section 4.4. Having set up the MySQL database, the SQL query was
added to the ProductInfo class, allowing information to be later retrieved from the database.
Finally, the Java class needs to store this information into a text file on the client’s device for
later use. In order to avoid storing information twice about an item, a restriction has been put
on the RFIDScan class. The class includes a list used to store EPC numbers. As soon as a new
item is scanned, the class will compare the item’s EPC number with existing entries contained
within that list. An EPC number which does not find a match in the list will be added at the
end of that list. On the other hand, if a match is found, the program will do nothing until a
new item has been scanned. This will avoid the creation of duplicate records within the text
file as well as an unnecessary database query.
- 24 -
The second set of functionalities relates to the serverside implementation, that is, the Mashup server
interacting with the shopping data sources and the
display of retrieved information to a web interface. The
author has therefore set up an Apache web server which Figure 5.3.1: UploadText.jsp
includes the Tomcat web container, for JSP
scripts. The web server can be referred to as
the Mashup server, as stated in both
Figure 5.3.2: ItemSelection.jsp
shopping scenarios as well as in section
5.2.2. A JSP file named UploadText was created on the
server, and allows for the uploading of a text file to the
Mashup server. The JSP page will operate as follows,
once the user is connected to the Mashup website; the
user locates the text file which contains information on
the scanned items by pressing the ‘Browse’ button, as
illustrated in Fig. 5.3.1. Once located, the client presses
the Upload button to send the file to the web server. Has
the upload been successful, a message would appear on
the page and the user obtains a list of product names on
the next page, as illustrated in Fig. 5.3.2. The client then
selects which item he/she wants to obtain additional
details for. Results are displayed to the client, with
information such as price and ratings obtained from
Yahoo! Shopping as well as Amazon (Fig. 5.3.3). In Figure 5.3.3: Rating.jsp
order for the web page to retrieve this information, two Java classes were called by the
Mashup server, and contained XML parsing methods to process information from Amazon
and Yahoo (See Appendix D). All JSP pages have not yet been optimised for use on mobile
devices, since the first iteration focuses on making sure different parts of the system work
correctly.
5.4 Unit Testing
Now that the stated goal has been achieved, the author can start performing system testing
prior to a further iteration. The testing aims to examine whether all parts of the system work
correctly, so that the prototype can correctly evolve. The author is to inspect the different
components of the application with the intention of locating errors. If all components are
- 25 -
correctly examined, it is likely that new errors will be identified and subsequently fixed,
thereby increasing the success of the application. The testing is split into three sections; client
testing (documented in Appendix J), server testing and data testing, each section relating to a
single component of the application (as illustrated in Fig. 4.7). Since the system is in its early
stages and given that there are no specific users for this application, user acceptance testing
was not considered. Also, given that the application has not yet been designed for use on
mobile devices, showing it to users would bring back inappropriate feedback. Since the stated
goal of this iteration was to validate the feasibility of the general architecture, system testing
was found to be sufficient at this stage.
- 26 -
6
Iteration 2: Matching Application Scenarios
6.1 Goals
The aim of the second iteration is to have the prototype match the shopping scenarios
specified in section 4.2. The current prototype requires the user to manually upload a text file
to the Mashup server, and does not consider multiple users carrying out simultaneous
requests. These are two performance issues which need to be addressed in this iteration, in
order to correctly comply with the scenarios. The prototype will also need to seamlessly
integrate different parts of the system, by allowing communications between client and server
to occur without the user’s knowledge.
6.2 Design
In order to improve the efficiency of the existing system, two components will be added to the
existing simulation environment; a web service and an additional database. Both components
will be part of the Mashup server. To create a web service, a Java platform called Apache
AXIS will need to be added on top of the existing Apache web server. This will allow the
creation and deployment of web service applications written in Java. The database will be
created using MySQL software, since it has already been used to create the shop database.
The web service will accept the user’s login credentials as well as the scanned item’s
description and its associated EPC number. The purpose of the web service is to collect the
aforementioned details in order to then instantly retrieve information about the item. Prefetching the information is a considerate improvement to the first iteration, where scanned
items were stored in a text file on the client’s handheld device. This meant that the client had
to manually locate and then load this file onto the Mashup server, through the web browser.
The Mashup server consequently had to parse the file and only then did it provide the user
with a list of items, for which additional information could be obtained.
The Mashup database is needed in order to store information retrieved from the Yahoo!
Shopping and Amazon web services. It is also required to store details retrieved by the new
web service. The Mashup server will store information discussed above in a table not specific
to a single user. The reason for this can be explained through the use of a short scenario;
“Imagine two users requesting a rating for a Nokia 6110 phone on the same day. At 9.00am
the first user requests information for this product. Details are obtained from Yahoo and
- 27 -
Amazon, and then stored into the database. The information is then displayed to the user.
Fifteen minutes later, a second user walks into a local phone shop and scans the same item.
Since information has already been obtained for that item, there is no point in making
another request. The information can simply be taken from the existing database entry.”
The scenario clearly explains the need for stored information to be available to all users of the
system, as opposed to having a single table for each user. It also illustrates the use of caching,
which overcomes issues related to server performance and bandwidth. There will be no
further need to request data from Yahoo! or Amazon web services if an item was already
scanned by any user of the application on the same day. Two tables will be created within the
new Mashup database; i) User_info – this will contain information retrieved from the web
service, ii) Product_info – this table will contain information obtained from the shopping
APIs. The user information table will contain a username entry as well as the EPC number
and a timestamp of when the item was scanned (Table 6.7.1).
Column Name
Data Type
Column Name
Data Type
User_id
Varchar(30)
Epc
Varchar(10)
Epc
Varchar(10)
Product
Varchar(100)
Date_time
Timestamp
Rating
Double
Date_time
Timestamp
Image
Varchar(100)
Similar1
Varchar(200)
Similar2
Varchar(200)
Similar3
Varchar(200)
Similar4
Varchar(200)
Similar5
Varchar(200)
Price_amazon
Varchar(10)
Price_yahoo
Varchar(20)
Table 6.7.1: User_info table
Table 6.7.2: Product_info table
The product information table will contain details about the scanned item, retrieved from the
shopping APIs (Table 6.7.2). The table is linked to the User_info table through the EPC field.
Columns Product, Rating and Price will contain general information on the item. The Image
will consist of a URL pointing to the product image located on the Amazon website. For each
similar item obtained from Amazon as stated in the shopping scenario, a column named
SimilarX (X being a number from 1 – 5) will contain a range of details about that item. Only
- 28 -
five similar items will be considered, since the system is to be displayed on a mobile device.
This will avoid data overloading but it will also reduce the amount of information stored in
the database. A timestamp will be recorded for each entry, in order to later observe whether
stored information is recent enough or whether it should be updated. The use of timestamps is
what the caching mechanism relies on, as explained in the short scenario.
The use of pre-fetching and caching is illustrated in the diagram below. The diagram shows
what happens from the moment the client scans an item, up to the point where information on
the item is stored in the Mashup server’s database. The Mashup server connects to its
database in order to check whether data on an item has already been retrieved and stored. If it
has, then a message will be communicated to the Mashup server stating that no action is
required. Otherwise, a message will be sent to the server stating that it needs to retrieve data
from the Shopping APIs. In this case, the Mashup server will retrieve data from Yahoo! and
Amazon, and will then store that information into the database for a later client retrieval.
Figure 6.7.1: Sequence Diagram for item scan
6.3 Implementation
The first step in this second iteration is to create a web service on the Mashup server. For this
to happen, Apache AXIS had to be installed on the existing Apache web server. A Java web
service called Service was then created on top of the AXIS platform. It provides a method for
the submission of a scanned item’s details as well as the user credentials. In order for the
handheld device to access this method, a client is needed to communicate to that web service.
A Java class ServiceClient was therefore created and integrated within the existing client
- 29 -
application, implemented in section 6.4. It contains a method which takes in parameters from
the ProductInfo class and consequently sends these to the web service. Instead of storing
information into a text file, ProductInfo will now call the ServiceClient module in order to
pre-fetch information to the Mashup server.
Now that pre-fetching was working, some means to store the pre-fetched information was
needed. A database, outlined in the design section, was therefore set up in order to store this
information in addition to information retrieved from the shopping APIs. Both the
Product_info and User_info tables have been created on the new database using data
structures outlined in the previous section. Below are two tables containing possible
information within the User_info and Product_info table. The use of caching can be explained
through the scenario below, with the help of these two tables.
User_id
Epc
Date_time
tobys
01023c1182
2007-03-21 13:03:45
tobys
010238a5e4
2007-03-21 16:56:42
michaelb
01023c1182
2007-03-21 16:59:34
Table 6.8: Simulated data within the User_info table
Table 6.8 shows a list of all items that have been scanned on the 21st of March. Michael (user
michaelb) and Toby (tobys) are two users of the Mashup application. From the table, it can be
seen that both users scanned at least a single item on that day. The table shows that one of the
items scanned by Toby was also scanned by Michael, a few hours later. Each record in the
User_info table is related to a record in the Product_info table, using the EPC number as a
key to link the tables. Table 1 in Appendix I illustrates that item details for both scanned
items have been obtained from the shopping APIs and subsequently stored into the database.
The similar item columns each contain chunks of information about an item. Details stored
about such items are author, title, rating, price and image URL. In order to reduce the payload
of used database columns, the author decided to concatenate information for a single item into
a single column.
For product “Dan Brown – Deception Point”, only a single record was stored in the
Product_info table. This happened directly after user Toby scanned the item. When user
Michael then scanned the same item a few hours later, the database already contained an entry
for that item. Since caching has been set to work on a day-to-day basis allowing stored
information to be used for 24 hours, the stored database entry was still valid for user Michael.
The logic for the caching mechanism can be explained using code below taken from the Java
- 30 -
web service located on the Mashup server. The code gets executed as soon as an item is
scanned by the user, and contacts the Mashup database and Shopping APIs when needed.
/** IF EPC ENTRY IS NOT FOUND **/
if (foundEPC == null) {
// get information from shopping APIs
// insert information into Product_info table
// create a new entry in the User_info table
}
/** IF EXISTING EPC ENTRY IS FOUND **/
else {
// check if item is already stored in database
/** IF EXISTING INFORMATION IS NOT FOUND IN DATABASE **/
if (foundRating == null) {
}
/** IF EXISTING INFORMATION IS FOUND IN DATABASE **/
else {
// check if information is recent enough
// check if stored data is less than 24 hours ago
/** IF RECENT RATING IS NOT FOUND IN DATABASE **/
if (foundRecentRating == null) {
}
/** IF EXISTING RECENT INFO IS FOUND IN DATABASE **/
else {
}
}
}
6.4 Evaluation
In order to evaluate the current prototype, a focus group was conducted with six participants.
The objectives of the focus group were;
to identify missing functionality with regards to the existing system, allowing for
later additions or modifications
to identify other possible scenarios with a combination of RFID and Mashups
to identify issues which a real life application should cope with
to assess the technical robustness of the application
Since identifying missing functionality was the prior concern at this stage, conducting a focus
group was found to be the most relevant, allowing for extensive user feedback.
- 31 -
6.4.1 Procedures and Materials
A focus group was arranged with active members of the School of Computing. The session
was due to last an hour, and consisted of a short presentation on the author’s project followed
by a demonstration of the most recent version of the application. After the demonstration the
author was to gather feedback from the participants with regards to the stated objectives.
The session took place in a meeting room located in the Informatics department, which was
equipped with a large TV screen ideal for focus groups. The author’s notebook was used for
the session, since it contained the simulated data as well as the client application modules for
the demo. An RFID-reader was also used in order to successfully simulate the application,
and to provide the participants with a clear view of the application’s capabilities. The
feedback session was recorded with the participants’ consents, and a transcript with the
summary of the feedback is available in Appendix E.
6.4.2 Participants
The six participants involved in the focus group assisted voluntarily in the session. They are
all part of the Knowledge Management and User Adaptive Systems reading group, to which
an e-mail has been sent with regards to this event. The author did not target a specific
audience for the session, though it was assumed that members of the reading group would
have technical and research backgrounds, having previously attained a PhD or MSc degree.
Each of the participants had prior knowledge of at least one of the following fields; Mobile
Development, Personalisation, e-Commerce, Digital Libraries, Web Mashups.
6.4.3 Results against Evaluation Objectives
Identify missing functionality with regards to the existing system, allowing for later additions
or modifications.
One of the participants suggested showing the source for a rating and price to the user.
She stressed that users want to know where information comes from, so that if they are
interested in buying the item from the online shop, they can instead buy it from there.
Another suggestion was regarding Yahoo’s price range not including the respective shops
and their individual price; “If it comes from Yahoo, can you get the exact shop that it’s
coming from?” Another participant encouraged the possibility of showing the status of
items, by marking them new or second hand items. This would allow the user to be aware
- 32 -
of the item status and to decide whether it would be cheaper to buy the item in the actual
shop or otherwise online.
Having gathered additions for the next iteration, the author introduced his idea of a smart
rating algorithm to the participants. This was in order to know whether they would be
interested in the outcome, if it was to be available to them. The idea was to collect a
rating (out of five) for an item from each customer review contained within the shopping
website. Depending on how many reviews a customer gave, a relative weight would be
applied for that customer rating. This meant that the more reviews a customer gave on
Yahoo or Amazon, the more weight were to be associated with the review. At the end of
the algorithm, weights would be accumulated and a final rating would be given to the
user. As a response to the idea, the participants were not too interested in knowing an
item’s rating. They were rather inclined to know what the price would be for that item.
Identify other possible scenarios with a combination of RFID and Mashups.
Tourist information scenario: One of the participants pointed out that RFID tags have
been attached to various locations in York. Tourists would walk around the open city and
notice tags located on walls. If a tourist is to be equipped with an RFID reader, he would
be able to “get information about that particular site” which he is seeing. This is where
RFID technology comes into play. With regards to Mashups being integrated within the
scenario, the participant added that it is “interesting to see what else you can pull from the
web about that particular site”, referring to web sources containing additional information
about the tourist site.
Library scenario: A participant with knowledge on digital libraries suggested the use of
RFID within bookshops. Shoppers would be equipped with a mobile RFID-integrated
device with the possibility of scanning books. A customer might be interested in a
specific book, but is not yet looking to buy it. His mobile device will therefore allow him
to obtain “a link to all libraries” in his city that contains this book. These libraries will
allow customers to “borrow a book and have a look”, and if interested, they could buy the
book from the shop they were in previously.
Recipe scenario: The last scenario was proposed by a participant with e-Commerce
background. When a customer goes shopping, she might like a specific food item, but
does not know what else to buy in order to make a dish. The potential mobile application
would recommend other food items in order to provide the customer with all the
ingredients required for a recipe.
- 33 -
Identify issues which a real life application should cope with.
The first issue was raised by a participant with experience in mobile development. The
issue was the problem of changing the programming environment for the prototype from
J2SE to J2ME. The first environment, Java 2 Platform Edition, is a platform which was
used for the prototype, and can be used for desktop applications only. Java 2 Micro
Edition, on the other hand, is aimed at mobile devices. In order to translate the prototype
to a real life mobile application, issues regarding the conversion from a desktop to a
mobile development environment need to be considered.
A second issue raised by one of the participants was the ease of extending the application
to another web service. The current prototype uses two different formats to obtain data
from Yahoo! and Amazon. This is because each shopping web service accepts different
parameters in order to then return requested data. Adding a new service would therefore
require the creation of a new format. The participant also suggested the use of UDDI
(Universal Description, Discovery and Integration) within the application, in order to
allow for discovery of new web services.
The final issue raised by some of the participants was the acceptance of the application by
companies. Since the author is targeting users of the system and not companies willing to
invest in the product, the issue is not considered within the scope of this project. It is
however important to accept that companies “don’t actually want you to know about the
competitors”, as one of the participants acknowledged.
Assess the technical robustness of the applications
An important aspect in providing robustness within the application is ensuring a reliable
connection between the different physical components. Wireless communications
between the handheld device and the Mashup server should be reliable. Connection to the
shop database should also be reliable.
Another issue is the availability of a shop database, which is needed to identify scanned
items. Shops might not be RFID-compliant, or they might not publish their database to
the public. This is an issue that needs to be considered if the application is to be real,
instead of a simulation. What worldwide companies might do in the future is transfer
RFID data on their stock to a centralised database, which would be available to the
public.
- 34 -
6.4.4 Implications for the Third Iteration
Having discussed different aspects related to the prototype, missing functionality raised by
some of the participants is what should be taken into consideration for the next iteration. The
last set of objectives considers other possibilities with RFID Mashups, and issues which are
important if a real life application is to be released. These are important factors for making
this application a real business case, but are not to play a role in the third iteration.
The author has decided not to implement the smart rating algorithm in the next iteration, as a
result of the participant’s response, but also because of time constraints. If enough time
remains, missing functionality will be added to the prototype. However, the main focus for
the next iteration is to get the simulation working on a mobile device. This will be done by
converting all created web pages to a mobile format.
- 35 -
7
Iteration 3: Interfacing with a Mobile Device
7.1 Goals
The aim of the third iteration is to use the integrated solution, completed at the end of the
previous iteration, to interface with a mobile device. Previously, information was designed to
be displayed on a desktop PC, thereby making it hard to show the benefits of the application
to users. This iteration will allow for mobile compatibility, thus enhancing the customer
experience. The mobile interface to be created should be kept simple and should not overload
the user with unnecessary data. Overall, this iteration will try to match the prototype to the
shopping scenario as close as possible, turning the prototype into a sensible and realistic
application.
7.2 Design
Providing users with a mobile interface will be achieved by converting all existing JSP pages
located on the Mashup server to a mobile web format, yet still allowing access with ordinary
web browsers. Wireless Access Protocol (WAP) is the mobile services specification which
controls these mobile formats. It was coined by the WAP Forum, now called the Open Mobile
Alliance (OMA). XHTML-MP (eXtensible HyperText Markup Language Mobile Profile) is
the mark-up language for the most recent WAP version (2.0), and it has been identified to be
the most suitable for converting pages to a mobile format. Kaikkonen and Roto [34]
acknowledge this by stating that XHTML-MP allows developers to create web applications
viewable with both ordinary and mobile browsers. Mark-up languages such as WML and
WMLScript are used for older WAP versions, which on the other hand only allow for mobile
development.
Since the prototype has already been built for use on ordinary PCs, the author is looking to
extend it for use on mobile devices. A mobile PDA was therefore to be used as part of the
simulation, requiring a wireless network card for connection to the shop database, and a
Mashup server as well as a web browser to display the XHTML-MP pages. An HP iPAQ
5550 PocketPC was chosen to act as the simulation component, since it was already available
to the author, and also satisfies both aforementioned requirements. With regards to input of
data, it is worth noting that essential differences need to be taken into consideration when
initiating the design of a mobile application, as opposed to a desktop solution. Given that the
- 36 -
current iteration covers the use of a mobile device, it is worth explaining these important
differences.
User Interface:
Limited size of screen; this leads to a difficulty in the choice of font size, as users
need to be able to read information from the screen. This limitation is emphasised if
the PocketPC’s operating system does not have a function to increase displayed text.
It also restricts the amount of information displayable on the device.
The user should be provided with as much information as necessary in order to
achieve a rewarding experience. Thus, information can be browsed by the user in a
quick manner, thereby enhancing their experience.
The interface should be user-friendly as well as intuitive.
It is therefore vital for the success of an application to have a clear and fluid user interface.
The added use of colour would also allow the user to easily distinguish between various
content areas.
Input methods:
Designing a mobile application must take into account the following issues involving user
input:
Current PocketPC’s are equipped with a crude pointing device, such as a stylus pen,
which is used for all consequent user input.
The small majority of these PocketPC’s may also include an embedded semi-sized
keyboard. These keyboards are inherently hard to use due to their small size. They
also take up valuable space which could be used to increase display size.
On the other hand, some devices offer an emulated keyboard which is used by
pointing the stylus at the required key. Yet, this type of keyboard is tedious and errorprone when used. Furthermore, this type of keyboard consumes vital display space.
Along with the previously mentioned issues, the above stated drawbacks must also be taken
into consideration when designing a mobile application. A means to overcome these issues is
to reduce user input to a minimum. For example; the user should be presented with a number
of options instead of a textual input box, in other words item information can be selected from
a pre-fetched list instead of being manually inputted by the user.
- 37 -
7.3 Implementation
A total of two JSP pages to be found on the Mashup server were converted to the XHTMLMP format; List.jsp and GetRating.jsp. Both pages first needed a Document Type Declaration
in order to be later validated against the WAP standards. The added DOCTYPE declaration is
shown below.
<!DOCTYPE html PUBLIC "-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
Two considerable modifications were required in order for the pages to comply with the
XHTML-MP format, the first one being the conversion of all tags and attributes to lowercase.
This is because the mark-up language is case-sensitive, as opposed to regular HTML code
being case-insensitive. The second change was regarding tag closures; all tags must be closed
properly, that is if a <p> tag is followed by content, it should be terminated with a </p> tag to
specify the end of a paragraph. Tags which do not come in pairs (as a result of no content
being enclosed) must be self-closed, in other words a tag representing a space should be
written as <br/> instead of <br> as in ordinary HTML.
List.jsp is the initial page the user is faced with after an item has been scanned and the user
has connected to the Mashup website. The outcome of the change to XHTML-MP is very
similar to Fig. 5.4.2 from the first iteration, although the JSP page is now compatible with the
PocketPC device. The Java code fragment below shows the first step taken to provide the user
with a list of scanned item. The code is contained within JSP tags (<% and %>) to allow for
Java enclosure.
<%
// Store username
String username = request.getParameter( "user" );
// Connect to the Mashup database
QueryDB query = new QueryDB();
Connection c = query.getConnection();
// Query the Mashup database for information on item
query.getInfo(username, c);
// Store information into array lists
productArray = (ArrayList)query.getProductArray();
epcArray = (ArrayList)query.getEPCArray();
%>
The parameter “username” is obtained through the browser when the user has specified a
username upon connecting to the Mashup website. This can be shown by the looking at the
following URL.
http://129.11.144.9:8000/Ratings/List.jsp?user=michaelb
As soon as the username has been retrieved, a connection to the Mashup database will be
performed, passing the username as a parameter in order to later obtain a list containing
information on the scanned items as well as a list holding EPC numbers. The second step is
- 38 -
outlined below, where the list of scanned items is dynamically created on the web page, once
more, through the use of Java code.
<form method="post" name="myform" action="GetRating.jsp">
<select name="mylist">
<%
for (Iterator it = productArray.iterator (); it.hasNext (); ) {
for (Iterator it1 = epcArray.iterator (); it1.hasNext (); ) {
Object product = it.next ();
Object epc = it1.next ();
out.println("<option value="+epc+">"+product+"</option>");
}
}
%>
</select>
<br/><br/>
<p>Get Rating :</p><input type="submit" value="Submit">
</form>
The JSP fragment above shows the outline of an HTML form which includes a dynamic list
made up of data obtained from the two stored Java array lists. In order to obtain information
stored within these lists, two ‘for loops’ are required to iterate through their entries. Within
each iteration, the loop creates a list item. The example below shows an example of such
item.
<option value=01023878c6>Dan Brown The Da Vinci Code</option>
The outcome of List.jsp can be shown through usage of the PocketPC, as illustrated in Fig.
7.3.1 and Fig. 7.3.2. The first image shows the initial screen the user is presented with upon
connecting to the Mashup website. The second image shows the exact same page but after the
user has clicked on the list box, displaying a list of all scanned items back to the user.
Figure 7.3.1: List.jsp
Figure 7.3.2: List.jsp
- 39 -
Once the submit button has been pressed, the user is forwarded to GetRating.jsp. This page
will display information regarding the item selected in List.jsp. The information consists of a
product description, rating, image and price as well as details on similar items. The java code
below shows how information on the selected item is retrieved, and later used to perform a
database query. The aforementioned information will then be stored after data has been
returned by the database.
<% // Retrieve item description from previous page
String epc = request.getParameter( "mylist" );
// Connect to the Mashup database
QueryDB query = new QueryDB();
Connection c = query.getConnection();
query.getSpecificProduct(epc, c);
// Store product information
String product = query.getProduct();
String rating = query.getRating();
String image = query.getImage();
String priceAmazon = query.getPrice();
String priceYahoo = query.getPriceRange();
%>
Once the information is stored into Java variables, it can be integrated within HTML code,
using colours to facilitate the display of the interface to the user. The code below applies a
style sheet used to alternate between two colours to achieve this.
<table border="0">
<tr>
<td><% out.println("<img src='"+image+"' align=left>"); %></td>
<td>
<p class = "blue"><b>Product Name:</b>
<%=product%><br/></p>
<p class = "black"><b>Price from Amazon:</b>
<%=priceAmazon%><br/></p>
<p class = "blue"><b>Price Range from Yahoo shops:</b>
<%=priceYahoo%><br/></p>
<p class = "black"><b>Average Rating:</b>
<%=rating%> / 5 <br/></p>
</td>
</tr>
</table>
Fig. 7.3.3 shows the JSP page being displayed on the PocketPC, with a clear alternation of
colours. It also shows a list of related items obtained from the Amazon web service. Fig 7.3.4
demonstrates how related items are clearly separated from one another through the use of a
divider, thereby providing the user with a clear interface.
- 40 -
Figure 7.3.4: GetRating.jsp – Similar Items
Figure 7.3.3: GetRating.jsp – Item Info.
Having discussed both mobile compatible JSP pages, it can be said that these adhere to the
input methods provided in the design stage. Neither page requires the user to enter data into
the application, therefore making it easier for the user to navigate through the application.
User interface differences have also been considered, and the application now fits all content
within the PocketPC screen.
7.4 Evaluation
Since the third iteration is the final version of the prototype, the author has decided to perform
usability testing with eight participants. The testing is qualitative in nature, and consists of
gathering data from actual users through successive, in-person one-on-one interviews. The
objectives of the evaluation were;
to determine whether the intended audience and anyone else who might come in
contact with the Mashup web interface, can use the application.
to determine participants' satisfaction with the product.
- 41 -
7.4.1 Procedures and Materials
The eight interviews were each due to last less than ten minutes and consisted of a quick
explanation of the product followed by a demonstration on how to use the application. The
user was then to use the application and fill in a usability questionnaire. For same reasons as
in the focus group (section 6.4.1), the author’s notebook as well as RFID reader was needed
for the session. The questionnaires were provided by paper, and along with a summary of the
feedback, these are available in Appendix F.
7.4.2 Participants
According to Waldal and McLachlan [35], five participants can help provide trends in a
product’s usability test. In addition, they believe that having three more users can help qualify
the trends, thereby making eight users the bare minimum for performing usability testing. It is
for that reason that the author decided to perform eight interviews, thereby collecting
sufficient information in order to find trends. Due to time constraints, the testing was
restricted to the minimum of eight participants.
The eight participants involved in the usability testing were randomly selected by the author,
although the following criteria needed to be met before testing could continue; the user had to
be a consumer of electronics products or books, or at least willing to purchase items within
one of the categories. This is because the current prototype only allows for these specific
categories to be scanned. It was also crucial that the potential participant was to agree to use a
mobile device in a shop, as this is how the customer experience was to be enhanced. Once a
participant matched the abovementioned criteria, demographic characteristics were gathered
about him/her. This was in order to build a user matrix, covering different types of users with
varied levels of experience with mobile devices and online shopping.
7.4.3 Data Collection and Analysis
Data to be collected was demographic information as well as feedback gathered from eight
participants through usability questionnaires. With regards to data analysis, demographic
information retrieved was to be used to categorise the different type of users. Results from the
questionnaire, on the other hand, were to be analysed to determine user satisfaction with the
application.
- 42 -
7.4.4 Results against Evaluation Objectives
A number of demographic information was asked to each of the participants. The results
indicated that most of them did not have previous experience with mobile web browsing. The
average years of experience that the participants had of online shopping were five years. This
was similar for previous usage of Amazon or Yahoo! Shopping, as the average for this was
four years.
Determine whether the intended audience and anyone else who might come in contact with
the Mashup web interface, can use the application.
Regarding the questionnaire, the majority of the participants agreed that the mobile
application was easy to use, and that information was very clearly presented to them.
However, one of the participants commented on the fact that it was not clear to them
that the related items displayed were user recommendations. Anther participant did
not like having to scroll down the results page to find the “back” button in order to
select another item. Having to reload the page when scanning an item was not liked
by two of the participants. According to them the application needs to run smoothly,
by automatically showing the user the last item he has scanned. Someone else
commented on the fact that a list of all items should be displayed to the user, instead
of a dropdown box hiding all entries.
Determine participants' satisfaction with the product.
All participants liked the use of colours within the application. However, one of them
observed that background colour for prices being displayed was not consistent. With
regards to the application providing enough information about an item, the majority
of participants disagreed, stating the following; 1) the average rating was not
informative. 2) a customer review for an item is missing 3) more retailers along with
their prices should be displayed. One of the participants proposed to have a
personalisation option, where user profiles can be stored, indicating the type of
information that should be displayed on an item. When asked about their satisfaction
with the application, the majority of participants were pleased with it. Finally, all
participants said that they would use of the application again, if they were to be in a
shop.
- 43 -
8
Evaluation
This chapter initially talks about the evaluation of the prototype, performed through an
interview with an expert in the field of Software Engineering and Computer Security. The
chapter then outlines the evaluation of the project, which will most importantly be judged
against whether or not it has achieved the stated objectives, and to what extent these have
been extended. Furthermore, the project methodology will be examined as it was a key
constituent for the success of the project, but also identified the way the author decided to
tackle the project. Part of the evaluation is to also examine the approach taken to schedule the
entire project.
8.1 User Prototype Evaluation
A structured interview took place with a senior teaching fellow at the School of Computing
responsible for teaching programming and security modules, and with prior knowledge of
Mashups. The interview questions are documented and can be found in Appendix G. At the
start of the session, the expert was given an introduction on the project, and was then asked to
read through the shopping scenario as well as the final prototype architecture specified in
Appendix G. A demonstration of the prototype was consequently given before the interview
could start.
When asked about the appropriateness of the shopping scenarios, the expert acknowledged
that the scenario was a good example and that it related well to the architecture. He then
pointed out that the simulation approach was sensible. Feeding back on the architecture, the
expert mentioned that a component which would automatically load a web page when an item
is scanned, was missing. He also mentioned that a plug-in architecture should be used in order
to allow for an abstract layer between the Mashup server and the shopping services.
Regarding the feasibility of the application, the expert emphasised that security was an issue.
This is due to the prototype not having considered the use of encryption to secure stored
database information, but also other security issues. When asked about the chosen
methodology method, he commented that the use of an iterative approach was a sensible for
this kind of project. Finally, the expert stated that the combination of Mashups and RFID
allows for automation with regards to obtaining information about an item. He mentioned that
the scenario cannot be applied had there not been usage of RFID technology, as it would not
be practical to bring a keyboard and manually start typing item information.
- 44 -
8.2 Minimum Requirements and Extensions
The project aim was to examine how RFID can be used within Intelligent Mashups to
enhance customers’ experiences. In order to meet this aim, achieving the minimum
requirement was of great importance. The requirement was defined as “an Intelligent Mashup
prototype which includes a single web data source and simulated RFID data with a shopping
scenario”. Since only a single minimum requirement was stated in the introduction chapter, it
shall be split up in order to be able to examine how each individual requirement was met.
A shopping scenario
Two shopping scenarios have been considered, and these can be found in section 4.2. The
scenarios have been the fundamentals for the design and implementation of the prototype,
seeing that they acted as the requirements.
Simulated RFID data
Since obtaining real RFID data used in retail shops was not possible due to a different RFID
format being used in this project as outlined in section 3.2.3, RFID data was simulated by
having set up a dummy shop database. The database accommodated for RFID tags of the
format specified in section 4.6, and product information was gathered from two different
shopping sources chosen in section 4.1. The choice of product categories has been identified
and together with the number of items used in the simulation, these have been justified.
An Intelligent Mashup prototype which includes a single web data source
The interactions specified in the shopping scenarios as mentioned in the above requirement,
were used to build a general architecture for the prototype. Once the simulation environment
was set up to include the simulated RFID data, the first prototype iteration was developed.
The prototype consisted of two data sources, Amazon E-Commerce and Yahoo Shopping!.
The initial integration of a single web data source was to be as generic as possible, in order to
later add more data sources. This allowed for the troublesome addition of the Yahoo
Shopping! service.
The prototype extensions were additional requirements set for the completion if the project, if
the author was to have enough time as well as the available resources.
Integrating more data sources (i.e. online price comparison)
As mentioned in the evaluation of the third minimum requirement, an additional data source
was added to the prototype. The Yahoo Shopping! API was used in order to provide prices
- 45 -
associated with its affiliated online shops, as well as to present product ratings. Both data
sources however were already used within the first prototype iteration. Therefore, instead of
integrating more data sources, it was decided that more data was to be pulled from the
Amazon E-Commerce service in order to allow for compliance with the scenarios.
Integrating a user rating system
Having carried out a focus group after the second prototype iteration, the idea of extending
the prototype by adding a smart rating system was presented to the participants, as stated in
section 6.4.3. The participants however did not like the idea of such extension, and said they
would rather be interested in price information than rating details. This was taken into account
in third the iteration, where the author focused on providing a mobile interface to turn the
prototype into a realistic application. As the application was shown to the participants on a
regular PC, it was not clear to them how the application was to be of real use.
8.3 Project Methodology
Chapter 2 and Appendix B summarise research which was performed on different software
development methodologies, varying from the traditional Waterfall approach to other more
flexible models. It was decided that a mixture of two models would be used for this project, as
these contained features relevant for the development of the prototype. The customised
methodology (illustrated in Fig 2.3.1) enabled the use of iterations, allowing the prototype to
evolve through stages of user feedback or testing. The use of these iterations integrated well
within the project as each of these allowed for a set of new or existing components to add
value and functionality to the product. However, the problem with the implementation phase
is that restricting the choice of functionality to be fitted into a single iteration proved to be a
difficult task. To try and avoid this issue, detailed goals have been set at the start of iteration
along with required functionalities.
8.4 Project Schedule
Time management is essential for the success of any type of project, and was therefore
evaluated for this project. As pointed by the project assessor, the initial project schedule (Fig.
1 in Appendix B) strongly resembled the use of a Waterfall model approach. This was due to
the schedule not having appropriately illustrated the use of iterations. The initial project
schedule left all implementation work to be done after the allocated Easter break, and as a
result the schedule was criticised for being rather ambitious. The final schedule is illustrated
- 46 -
in Fig 2.3.2 and was compiled after having received project feedback on the Mid-Project
report. It differs from the initial schedule by having partitioned the system design,
implementation and validation stages into smaller tasks which would allow the use of stricter
deadlines. Looking at the initial schedule, disambiguation occurred with regards to the system
design stage. As identification of online data sources and the shopping scenarios belonged to
a stage called “Design”, it added confusion to the schedule which already contained a System
Design stage. This was reflected upon in the final schedule by changing the Design stage to
Problem Analysis.
8.5 Business Case Consideration
Turning the prototype into a business case was not taken into consideration in this project, as
the prototype was aimed at consumers and not companies willing to invest in the product. The
project scope was therefore scaled to only accommodate for the users needs. Although
companies’ interests in the prototype were not considered, it is important to discuss the issues
they would have with the application. The prototype developed in this project provides users
with product prices from online competitors. This would benefit the users, but is something
companies would not approve, since it defeats the purpose of buying from their shops.
Therefore, a suggestion for an alternative use of the application can be given which would be
of use for both companies and consumers. The potential mobile application would
recommend food items to users after they have scanned grocery item, in order to provide
them with ingredients required for a recipe. Recipes would be gathered from different
cooking sources on the internet. This alternative application would benefit the shop by
pushing the consumers to buy other food items in the shop, but would also be beneficial for
consumers since they could be offered suggestions on what kind of dish they could make with
scanned items.
8.6 Further Work
Personalisation – As suggested by one of the questionnaire participants, the application
could evolve to allow the storage of user profiles. Each profile would indicate the type of
information that should be displayed for a user about an item. Another feature would be to
allow the user to choose from a list of shops he would like information on.
Conversion to RFID-integrated phone – Since the prototype is built around a simulation,
future work might be to develop it for a real mobile device with an integrated RFID module.
- 47 -
NOKIA has already released two of its phones with RFID integration [36], and other phone
suppliers are likely to do the same, knowing the clear benefits RFID technology has to offer
when combined with phones. The author has applied to participate in a 5-day RFID workshop
in the Netherlands where RFID equipment will be available and a proof of concept is to be
designed and developed. Exchanged e-mails between the author and a representative for the
workshop are documented in Appendix H.
- 48 -
9
Conclusion
9.1 Feasibility of Combining RFID and Mashups
Three different perspectives were taken on the feasibility of RFID integration within
Intelligent Mashups, and on whether both technologies are suitable to enhance customers’
experiences. Each of these are be summarised below. i) The opinion of the author, who has
developed a working RFID Mashup prototype. ii) The perception from the focus group
participants who have seen a working version of the prototype. iii) The view from an expert in
the field of Software Engineering and Security who also had detailed knowledge of Mashups.
Author’s viewpoint
Having developed an RFID Mashup prototype for a shopping scenario, the author believes
that the two technologies can work together effectively to enhance customers’ experiences.
This would not only apply to shopping situations, but could be useful for different
circumstances, such as household appliance use, as mentioned in section 3.2.2.
Focus group participants’ viewpoint
Participants acknowledged the fact that merging RFID technology with Mashups can bring
added value to users. They mentioned the use of three alternative scenarios to illustrate the
possibilities that are available when combining both technologies with useful sources of
information. Data about tourist attractions, libraries and recipes were sources of information
discussed in the focus group (section 6.4), which could be used to bridge the gap between the
physical world and the virtual world thereby enhancing people’s experiences. The participants
also mentioned the issue of reliability such as wireless communication between the Mashup
application and its web data sources located on the internet. This problem is especially
applicable to mobile applications requiring wireless connection to the internet.
Expert’s viewpoint
When asked about the feasibility of combining both technologies, the expert only gave an
answer with regards to the shopping scenario. He mentioned that the merging of RFID and
Mashups can lead to the automation of objects or devices, but that security should be
considered when building such applications.
9.2 Comparison to Other Solutions
In this section, similar solutions to the prototype developed in this project will be compared.
As explained in section 3.3, there seems to be only a single commercial Mashup application
- 49 -
making use of RFID data. The application however cannot be compared to the prototype,
since it does not offer shopping services. However, research projects as well as pilot tests by
companies have been undertaken on RFID-based shopping assistants [37] [38]. The author
has chosen to compare fully deployed solutions offering similar services to the prototype,
making instead use of alternative technologies.
Virgin Mobile Shopping Assistant – Virgin has launched a mobile shopping service [39]
allowing its customers to search and compare products over their mobile phones whilst
shopping. Features such as product comparisons, other retailers’ prices and live purchasing
are included within the service. The service has the disadvantage of requiring users to
manually type in products they wish to obtain more information on, as opposed to the
prototype allowing for automatic product scanning. Features such as product purchasing and
retail prices are useful characteristics which are not addressed in the prototype.
SmartWorlds iShop Books – iShop Books [40] is a free software designed for use on a
PocketPC that can act as a personal shopping assistant for books, using the device’s wireless
or cellular connectivity to obtain information from Amazon.com’s web services. The
application can provide customer reviews retrieved from Amazon, in addition to this project’s
prototype features. Relevant book information is retrieved after the user would enter a ten
digit book identifier known as the ISBN. Again, compared to the prototype, this software
requires manual input from the user, but is also restricted to Amazon-related books
information only.
9.3 Summary
The project aim was to examine how RFID could be integrated within Intelligent Mashups in
order to enhance customers’ experiences. Research on RFID technology as well as Mashups
has been undertaken in order to form the basis of a prototype. The problem analysis section
allowed for a set of scenarios to be identified based on previously chosen online data sources.
Different user opinions have been gathered throughout the prototype development, thereby
allowing for useful feedback regarding feasibility, functionality and usability of the
application. Comparisons to other solutions have showed that other technologies can equally
enhance customers’ experiences, although manual intervention would still be required. In
essence, the final product confirmed the feasibility of combining the two technologies to
allow for the enhancement of customers’ experiences.
- 50 -
References
[1] Sommerville, I. Software Engineering Sixth Edition, Addison-Wesley, 2001
[2] Bocij P, Chaffey D, Greasley A, Hickie S, Business Information Systems Second Edition,
Prentice Hall, 2003
[3] O’Reilly Media Inc. Web 2.0: Principles and Web Practices,
http://www.oreilly.com/catalog/web2report/chapter/web20_report_excerpt.pdf, Nov 2006 (as
of Nov. 8 2006)
[4] O’Reilly Media. Web 2.0 Conference, http://www.web2con.com/web2con (as of Apr. 20,
2007)
[5] O’Reilly, T. What Is Web 2.0: Design Patterns and Business Models for the Next
Generation of Software, self published on http://www.oreilly.com, 09/30/2005 (as of Nov. 8,
2006)
[6] Porter, J. Introduction to Web 2.0, http://www.squidoo.com/introtoweb20/, 12/12/2005 (as
of Nov. 8, 2006)
[7] Fitzgerald, M. 2006. The Name Game: Tagging tools let users describe the world in their
own terms as taxonomies become "folksonomies." CIO, Apr 01.
[8] Chase, N, The ultimate mashup -- Web services and the semantic Web, published on
http://www-128.ibm.com/developerworks/edu/x-dw-x-ultimashup1.html, 22 Aug 2006 (as of
Nov. 15 2006)
[9] Duane M, Mashups: The new breed of Web app, published on http://www128.ibm.com/developerworks, 08 Aug 2006 (as of Nov. 8, 2006)
[10] Berlind, D. Mashup Ecosystem poised to Explode, http://blogs.zdnet.com, 27 Jan 2006
(as of Nov. 8 2006)
[11] Hof, R D. Mix, Match and Mutate, http://www.businessweek.com, 25 Jul 2005 (as of
Nov. 8 2006)
[12] Rademacher P. Housing Maps, http://paulrademacher.com/housing (as of Nov. 15 2006)
[13] sudoku.com.au. FlickrSoduku, http://flickrsoduku.com (as of Nov. 15 2006)
[14] Thalasar Ventures. Early Miser, http://www.earlymiser.com (as of Nov. 15 2006)
[15] O’Neill B. BBC News Maps, http://benedictoneill.com/content/newsmap (as of Nov. 15
2006)
[16] Want R. 2004. The Magic of RFID. Queue 2, 7 (Oct. 2004), 40-48.
[17] Sweeney II, P J. RFID for Dummies. Wiley Publishing,Inc., ISBN: 0-7645-7910-X,
2005.
[18] Cole, P H. and Engels, D W. Auto ID - 21st Century Supply Chain Technology. (Sep.
2005) White Paper, Ed.1.
- 51 -
[19] Borriello G. 2005. RFID - Tagging the World: Introduction. Commun. ACM 48, 9 (Sep.
2005), 34-37.
[20] Dargan G, Johnson B, Panchalingam M, Stratis C. (2004). The Use of Radio Frequency
Identification as a Replacement for Traditional Barcoding.
http://www.andrew.cmu.edu/user/cjs (as of Nov. 22 2006)
[21] Matrics Inc. (2004). EPC and Radio Frequency Identification (RFID) Standards
http://www.scansource.com/rfidedge/Future_Trends_Opportunities/Legislation_Standards/EP
C_RFID_Standards.pdf (as of Nov. 22 2006)
[22] IATA. Radio Frequency ID (RFID) for aviation.
http://www.iata.org/stbsupportportal/rfid/ (as of Dec. 06 2006)
[23] RFID Journal. Great Wolf Water Park Launches RFID.
http://www.rfidjournal.com/article/articleview/2211/1/1/ (as of Dec. 06 2006)
[24] RFID Journal. Hoboken RFID-enables Its Parking Permits.
http://www.rfidjournal.com/article/articleview/2421/1/1/ (as of Dec. 06 2006)
[25] We Make Money Not Art (WMMNA). Sherelog: Suica Mashup. http://www.we-makemoney-not-art.com/archives/008164.php (as of Dec. 06 2006)
[26] Smartspace. Sharelog and Suica.
http://smartspace.squarespace.com/smartspace/2006/3/13/sharelog-and-suica.html (as of Dec.
06 2006)
[27] John Musser. ProgrammableWeb. http://www.programmableweb.com (as of Mar. 28
2007)
[28] Glinz, M. (2000b). Improving the Quality of Requirements with Scenarios. Proceedings
of the Second World Congress on Software Quality. Yokohama. 55-60.
[29] Ryser, J., Glinz, M. (1999). A Practical Approach to Validating and Testing Software
Systems Using Scenarios. QWE’99: Third International Software Quality Week Europe,
Brussels, Nov 1999
[30] Roger D. Smith. Simulation: The Engine Behind the Virtual World, eMatter, (Dec. 1999)
http://www.modelbenders.com/papers/sim2000/SimulationEngine.PDF (as of Apr. 22 2007)
[31] Phidgets Inc, http://www.phidgets.com (as of Mar 29 2007)
[32] The Internet UPC Database, http://www.upcdatabase.com (as of Mar 29 2007)
[33] MySQL. How MySQL Powers Web 2.0. (Aug. 2006) White Paper
http://www.mysql.com/why-mysql/white-papers/mysql_wp_web20.php (as of Apr. 22 2007)
[34] Kaikkonen, A. and Roto, V. 2003. Navigating in a mobile XHTML application. In
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (Ft.
Lauderdale, Florida, USA, April 05 - 10, 2003). CHI '03. ACM Press, New York, NY, 329336.
- 52 -
[35] Waldal, L. and McLachlan, E. Ready, Set, Go: Usability Testing. (Aug. 2003)
http://www.adobe.com/devnet/articles/usability_testing.html Adobe Developer Article (as of
Apr. 18 2007)
[36] NOKIA. Nokia Field Force Solution. (2007)
http://usa.nokia.com/NOKIA_BUSINESS_NAM_38/Products/Mobile_Software/Field_Force
_Solutions/Nokia_Field_Force_Solution_Datasheet.pdf (as of Apr. 22 2007)
[37] Lee, K. J. and Seo, Y. H. 2006. A pervasive comparison shopping business model for
integrating offline and online marketplace. In Proceedings of the 8th international Conference
on Electronic Commerce: the New E-Commerce: innovations For Conquering Current
Barriers, Obstacles and Limitations To Conducting Successful Business on the internet
(Fredericton, New Brunswick, Canada, August 13 - 16, 2006). ICEC '06, vol. 156. ACM
Press, New York, NY, 289-294.
[38] Cisco Systems. Japanese Retailer Deploys Intelligent Fitting Room. (Aug. 2006)
http://www.cisco.com/web/strategy/docs/Mitsukoshi_CS.pdf Customer Case Study (as of
Apr. 23 2007)
[39] Virgin Mobile. Virgin Mobile Unveils Shopping Assistant Powered by digitalRUM. (Feb.
2001) Press Release (as of Apr. 23 2007)
[40] SmartWorlds. iShop Books. (2003) http://www.smartworlds.com (as of Apr. 23 2007)
- 53 -
Appendix A – Personal Reflection
My year in Industry has given me a considerable amount of experience in developing
database systems. During that time, I came across the concept of RFID technology.
Throughout the year, I regularly visited RFID-related news articles on the web, and became
extremely impressed with the range of applications that can be used when combined with this
fast-growing technology. It can potentially be used for everything, from tracking cows to
unlocking hotel doors. This was one of the main reasons I chose to use RFID within my
project.
My initial idea was to allow for a shop item to be scanned and for prices about physical shop
competitors (unlike online shops) to be consequently displayed on a customer’s mobile
device. As the customer would select the cheapest price presented by the device, he would be
shown how to get to the shop offering the cheapest deal. However, the idea turned out to be
unfeasible since retailers’ websites were found not to be offering web services to allow for
ease of product retrieval (thereby requiring the tedious use of screen scraping). Because of
this, the choice of the actual application to be developed in this project was delayed until
December, thereby leading to less product functionality being developed.
I would strongly recommend any future project student to ensure that they enjoy the subject
area of their project, as it will take up a vast majority of their time during their final year.
Furthermore, it is extremely important to quickly decide on the problem needing to be
tackled, and to check that it is indeed feasible.
Having chosen a project that has not been previously pursued in the School of Computing,
along with the notion of RFID being an expensive technology which has not sufficiently been
taken advantage of has provided me with a clear opportunity.
The modules split I have chosen in my final year was a 50-30 split, which meant more
resources were to be available for my project in the second semester. In my opinion this has
worked well for me as I was able to commence research during the first University term,
thereby leaving more time for product implementation in the second term. The fact that no
breaks occurred within the implementation phase allowed no time to be wasted in reviewing
previously undertaken practical work. Another issue with regards to project schedule was the
fact that coursework deadlines were not taken into consideration, and therefore I advise any
student to consider these into their project schedule.
- 54 -
Appendix B - Project Methodology
The Waterfall Approach
The Waterfall approach uses a traditional development model where the developers and the
users move logically from one stage to the next one. A stage cannot start until the previous
one was completed. Each phase includes a key deliverable which is typically produced on
paper.
The Waterfall model is a well-established and widely used model for practical systems
development, but can lead to the following problems:
•
Commitments have to be made at an early stage in the process, which means it is
different to respond to changing requirements from customer.
•
The Waterfall model should only be used when requirements are well understood.
•
If the developer misses important requirements, expensive post-implementation
programming may be needed.
RAD / Evolutionary Development
Rapid Application Development (RAD) is a method of developing systems which use
prototyping in order to achieve user involvement and faster development compared to
traditional methodologies such as the Waterfall model [2]. Its objectives are to deliver a
working system to end-users by starting with user requirements which are best understood
and which have highest priority.
The main idea behind RAD is to develop an initial implementation, exposing this to users for
comments, and refining this through many iterations until an adequate system has been
developed. The advantage of a software process based on an evolutionary approach is that the
system specification can be developed in stages. As users better understand their problem, the
software system can later reflect on this. There are two clear drawbacks with this method; the
first one is reduced scalability, since a RAD application starts as a prototype and ends up as a
finished product. However, scaling a prototype to predetermined goals can avoid this issue.
Another problem with RAD is reduced features, seeing that application features need to be
pushed to later versions due to time boxing. These two problems however are not critical to
this project, since the author is not aiming for a finished product.
- 55 -
Reuse-Oriented Development [1]
This process model is also sometimes referred to as Component-Based Development. It relies
on a large base of reusable software components which can be later accessed. It also relies on
some integrating framework for these components.
The initial stage as well as the validation phase of this model is very similar to other software
processes. However, the intermediate stages are different as they accommodate for
components integration. A list of these stages follows;
1. Component analysis: the developer searches for components in order to implement
the requirement specification.
2. Requirements Modification: requirements are analysed using the information
provided about the discovered components, and are then modified to reflect available
components.
3. System design with reuse: Design a new or reuse an existing framework. Organise
framework to cater for reused components.
4. Development & integration: Software which cannot be reused is developed and
integrated with the reusable components.
This methodology has got clear advantages over the previously mentioned process models:
1. It reduces the amount of software to be developed which leads to reduced risks.
2. It usually leads to faster delivery of software.
However, using this model means that control over the system evolution is lost as new
versions of reusable components are not under the control of the developer. Additionally,
components functionality may restrict the application so that it would not be able to satisfy all
of the user requirements.
- 56 -
Initial Project Schedule
Figure 1: Project Schedule
- 57 -
Final Project Schedule
Figure 2: Final Project Schedule
- 58 -
Appendix C – Java Client Class Diagram
Figure 1: Class Diagram
- 59 -
Appendix D – Amazon and Yahoo Web Services
AmazonInfo.java – Java Class for Amazon information retrieval
/**
* This class will get product information from the Amazon e-Commerce
* web service. An XML parser is used to retrieved the desired information.
*
* @author Michael Hollander
* @date 17th Mar 2007
**/
public class AmazonInfo {
private
private
private
private
private
ArrayList simArray;
String image;
String price;
String avgRating;
SimilarityItem sim;
public AmazonInfo(String desc, String cat) throws Exception {
simArray = new ArrayList();
String requestAccessKeyID = "13S0F4DPEDXCE8AMZXR2";
String requestSecretAccessKey = "ZO4vmDnoDHZ9drz9MWi0ZbXifJFsEPb9Li4eOBt2";
String description = desc;
String category = cat;
// XML file location
String docString = "http://webservices.amazon.com/onca/xml?Service=AWSECommerceService"+
"&SubscriptionId="+requestAccessKeyID+
"&Operation=ItemSearch"+
"&SearchIndex="+category+
"&Keywords="+description+
"&ResponseGroup=Reviews,Small,Images,ItemAttributes,Similarities"+
"&ReviewPage=1";
Document doc = null; // reset document
try {
// Get the document builder factory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// Using factory get an instance of document builder
- 60 -
DocumentBuilder db = dbf.newDocumentBuilder();
// Parse using builder to get DOM representation of the XML file
doc = db.parse(docString);
} catch (java.io.IOException e) {
System.out.println("Can't find the file");
} catch (Exception e) {
System.out.print("Problem parsing the file.");
}
// Get the root element
Element root = doc.getDocumentElement();
// Store whether results were found for the query
Element successElement =
(Element)root.getElementsByTagName("IsValid").item(0);
// If results were found
if (successElement.getFirstChild().getNodeValue().equals("True")) {
// Get a nodelist of elements
NodeList results = root.getElementsByTagName("Items");
// Get the first Item element
Element resultsElement = (Element)results.item(0);
/**============= IMAGE INFORMATION ================**/
// Get the Item Image element for the first Item
Element MediumImageElement =
(Element)resultsElement.getElementsByTagName("SmallImage").item(0);
// store product image URL
image = MediumImageElement.getChildNodes().item(0).getFirstChild().getNodeValue();
/**============= END IMAGE INFORMATION ============**/
/**============= PRICE INFORMATION ================**/
// Get the Item Price element for the first Item
Element itemAttributesElement =
(Element)resultsElement.getElementsByTagName("ItemAttributes").item(0);
Element listPriceElement =
(Element)itemAttributesElement.getElementsByTagName("ListPrice").item(0);
Element amountElement =
(Element)listPriceElement.getElementsByTagName("FormattedPrice").item(0);
// Store product price
price = amountElement.getFirstChild().getNodeValue();
/**============= END PRICE INFORMATION ===========**/
/**===== CUSTOMER REVIEW SECTION ======**/
- 61 -
// Get the Customer Reviews element for the first Item
Element customerReviewElement =
(Element)resultsElement.getElementsByTagName("CustomerReviews").item(0);
// Store average rating for the first item
avgRating = customerReviewElement.getChildNodes().item(0).getFirstChild().getNodeValue();
/**=== END CUSTOMER REVIEW SECTION ===**/
/**===== SIMILARITIES SECTION =====**/
// Get the Similarities element for the first Item
Element similarProductsElement =
(Element)resultsElement.getElementsByTagName("SimilarProducts").item(0);
NodeList similarProductElements = similarProductsElement.getElementsByTagName("SimilarProduct");
int numberOfSimilarProducts = similarProductElements.getLength(); // Get the number of similar products
System.out.println("There is a total of "+numberOfSimilarProducts+ " similar items.");
for (int thisProduct = 0; thisProduct < numberOfSimilarProducts; thisProduct++){
Element similarProductElement =
(Element)similarProductsElement.getElementsByTagName("SimilarProduct").item(thisProduct);
// store similar product's ASIN number, in order to later obtain information on similar item
String asin = similarProductElement.getChildNodes().item(0).getFirstChild().getNodeValue();
// Loop through all similar items available, and obtain information on each of these
sim = new SimilarityItem(asin);
simArray.add(sim.getAuthor()+sim.getTitle()+"|"+sim.getAvgRating()+"|"
+ sim.getPrice()+"|"+sim.getImage());
System.out.println("Similar Item "+(thisProduct+1)+ ": " + sim.getAuthor() + " - "
+ sim.getTitle() + " with average rating of "+sim.getAvgRating()+" and price of " + sim.getPrice());
sim = null;
}
/**=== END SIMILARITIES SECTION ===**/
} //end if results were found
// If no results were found and an error occured
else {
System.out.println("The request did not process properly.");
}
}//end constructor
}//end AmazonInfo
- 62 -
YahooInfo.java – Java Class for Yahoo! Shopping Information retrieval
/**
* This class will get information related to a product, given its
* description, from the Yahoo e-Commerce web service.
* An XML parser is used to retrieved the desired information.
*
* @author Michael Hollander
* @date 17th Mar 2007
*
**/
public class YahooInfo {
private String price;
private String avgRating;
private String catalogID;
public YahooInfo(String query) throws Exception {
String requestAccessKeyID = "UAEr3czV34FRLmGCALNzyDzUiqVA.nWpwrUyBOkNoPqAr0nR22orlpQ7P2uGOuk";
String keywords = query;
// XML file location
String docString = "http://api.shopping.yahoo.com/ShoppingService/v1/productSearch?"+
"appid="+requestAccessKeyID+
"&query="+keywords+
"&results=1";
Document doc = null; // reset document
try {
// Get the document builder factory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// Using factory get an instance of document builder
DocumentBuilder db = dbf.newDocumentBuilder();
// Parse using builder to get DOM representation of the XML file
doc = db.parse(docString);
} catch (java.io.IOException e) {
System.out.println("Can't find the file");
} catch (Exception e) {
System.out.print("Problem parsing the file.");
}
// Get the root element
Element root = doc.getDocumentElement();
- 63 -
// Get a nodelist of elements
NodeList results = root.getElementsByTagName("Result");
// Get the first Item element
Element resultsElement = (Element)results.item(0);
// Get the Catalog element for the first Item
Element CatalogElement =
(Element)resultsElement.getElementsByTagName("Catalog").item(0);
catalogID = CatalogElement.getAttribute("ID");
/**============= PRICE INFROMATION SECTION ====================**/
Element PriceFromElement =
(Element)CatalogElement.getElementsByTagName("PriceFrom").item(0);
Element PriceToElement =
(Element)CatalogElement.getElementsByTagName("PriceTo").item(0);
price = PriceFromElement.getFirstChild().getNodeValue()+" - "
+ PriceToElement.getFirstChild().getNodeValue();
/**============= END PRICE INFROMATION SECTION ================**/
/**============= CUSTOMER REVIEW SECTION ====================**/
// Get the Max User rating, Total Ratings and Average Rating for first Item
Element userRatingElement =
(Element)CatalogElement.getElementsByTagName("UserRating").item(0);
Element avgRatingElement =
(Element)userRatingElement.getElementsByTagName("AverageRating").item(0);
avgRating = avgRatingElement.getFirstChild().getNodeValue();
/**============= END CUSTOMER REVIEW SECTION ====================**/
}//end constructor
}//end YahooInfo
- 64 -
Appendix E - Transcript of Focus Group
List of users:
User1 = Mobile Development Expert / frequent mobile user
User2 = Personalisation Expert
User3 = e-Commerce Expert
User4 = Digital Libraries Expert
User5 = Mobile Expert
User6 = Developer of Personal Travel Assistant Mashup
User1: “Now, you have 2 formats, from Yahoo and Amazon
User2: You need to know the protocol to communicate to the new data store. So Yahoo
communicates in one way, Amazon communicates in another”
User1: Now, you use a java program on the desktop, and in a mobile. When you use the mobile, you
want to change to, or create the application on the mobile. How do you do it?
Michael: I think the best way to do that would be to use J2ME, or some other mobile java software. I
am using Eclipse at the moment to do the Java coding, but I will probably need to change it into java
mobile format.
User1: That uses J2SE (referring to the current system), and this one is J2ME (referring to potentially
converting my system for use on mobile devices).
User2: You are evaluating a simulation, and then one of the points you have to discuss is; How to
make it a real life application. So what are the issues with the real life applications should cope with.
One of them is changing the problem of environment; changing to J2ME.
The other one is awareness of the technical robustness of the system; if the connection may not be
reliable.
Issues which are not related to your simulation now, but are issues which are related to the real life
and you have to comment on these at the end of your project.
User3: Extending to another mashup. There is UDDI which is developed for web services. Do you
think the future is, if people vote for UDDI, you just go to that directory, and you can find new
services.
User2: Will the shops actually accept this application? They don’t actually want you to know about
the competitors.
User3: This project is about possibilities
Michael: There is a physical world and a virtual world, and you want to combine them together.
User2: You came up with one shopping scenario. But they may think, are there any other possibilities,
where RFID and Mashups could be mixed, for future work? You are evaluating how well they mix
together.
User2: RFID tags attached to some places in York. York is like an open city, so you walk around and
you see these tags on the wall. If it has an RFID reader, then you can get information about that
particular site which you are seeing. It’s interesting to see what else you can pull from the web about
that particular site.
- 65 -
User4: It’s a library scenario, when I buy a book for someone else; if I find that this book is
interesting, I say hmm well, you want to read it, but you don’t want to buy. So would it be possible to
have a link to all libraries in your city that contains this book.
User2: Where can you find this book, all the other shops.
User4: Well not only shops, but libraries where you can borrow a book and have a look, and then you
can buy the book.
User5: I am using a PDA, and I found myself many times somewhere. For example, two nights ago
we were just shopping at Tesco and you look at something and you want to know more, then I will go
home, and Google it…
User2: I find for example very often; I go to a shop and I’m looking for a present for somebody, and I
know what they like. I don’t want to buy this, because they already have it. And then I think, what
else can I buy for them? And it’s a huge shop. And they have no idea. They go to HMV, plenty of
DVDs, and you could pick one or two DVDs which you know they’ll like and you could say, well,
show me the related ones, and that’s, I mean, again, I can buy from the shop, because I’m there to
buy, but it’s just, I haven’t got a clue how to find those things.
[Assuming the company implements RFID within all of its items.]:
User3: One thing now I realise, for Tesco to do this, it may be, a recipe; so, oh, I like this artichoke,
but I don’t know what else should I buy from Tesco.
Michael: That’s what I have put in my report, I talked about the recipes, where you scan a food item,
and then it tells you, I think it scans all the other items within the same shelf, and it tells you what else
you can buy to make a dish.
User3: The current system, can the user actually see, oh, these are from Yahoo, these are from
Amazon?
Michael: No.
User3: So they don’t know. So if somebody finds a cheaper one from Amazon, you want to go and
buy from Amazon.
User5: If it comes from Yahoo, can you get the exact shop that it’s coming from?
User6: But even Amazon, they have like many shops from other people, not from Amazon. So the
price might be different.
User5: Yes, Second hand, new…
User3: It is important to know where one gets the message.
User5: If you can find Amazon fifteen pounds, but it’s second hand, then you will buy the new one or
you will not buy?
User1: So maybe you can have a link to eBay.
Michael: What do you think of the rating? The thing is, with the rating it’s doing a really smart
algorithm on the server side where it’s compared all the ratings and put small weights depending on
how many reviews one gave. But the in the end, the user just gets one rating. So is it worth it to do all
- 66 -
of this for the user, in comparison to just getting the average from Yahoo and Amazon and take the
average of that?
User3: For shoppers, they want to know what’s cheapest, not average.
- 67 -
Appendix F – Usability Testing
Questionnaire Questions
Demographic Information
Experience web browsing on a mobile device (how many years?)
Previous experience with online shopping
Previous usage of Amazon or Yahoo! Shopping service
1. How easy do you find the mobile application to use?
Very easy
Easy
Somewhat easy
Difficult to use
Impossible to use
2. What do you think of the colour scheme?
Excellent
Good
Average
Poor
Terrible
3. How clear is the text presented to you?
Very clear
Clear
Unclear
Not clear at all
4. Does the application give you enough information to make a decision on whether or not to buy the
product?
Too much information
Enough information
- 68 -
Not enough information
No information at all
5. Are you satisfied with the system?
Extremely satisfied
Very satisfied
Neutral
Very dissatisfied
Extremely dissatisfied
6. Would you use this application again, if you were to use it in a shop?
Yes
No
7. User comments
- 69 -
Questionnaire Results
Demographic information:
A – Previous experience with web browsing on a mobile device (in yrs)
B – How many years of experience with online shopping?
C – Previous experience with using Amazon or Yahoo! Shopping Service? (in yrs)
Outcome:
User
1
0
3
4
5
6
7
8
A
B
C
0
0
4
0
0
4
0
0
9
0
7
2
3
8
8
1
9
1
4
2
1
7
3
1
Questions:
How easy did you find the mobile application to use?
Very Easy – 12.5% (1)
Easy – 75% (6)
Somewhat easy – 12.5% (1)
What do you think of the colour scheme applied in the application?
Excellent – 37.5% (3)
Good – 62.5% (5)
How clear is the text presented to you?
Very clear – 75% (6)
Clear – 25% (2)
Does the application give you enough information to make a decision on whether or not to
buy the product?
Enough information – 37.5% (3)
Not enough information – 62.5% (5)
Are you satisfied with the application?
Very satisfied – 62.5% (5)
Neutral – 37.5% (3)
Would you use this application again, if you were to use it in a shop?
Yes – 100% (8)
- 70 -
Appendix G –Expert Interview Material
Technical Questions for Interview
1. How appropriate do you find the shopping scenario (with regards to the architecture)?
2. How appropriate do you find the simulation (RFID reader, components, web service, JSP,
XML, XHTML-MP, tomcat, MySQL and data used)?
3. Could you feed back on the architecture? (Appropriateness)
4. What do you think about the feasibility of the architecture? (Implementing it for a real
product)
5. What do you think of the chosen approach (Iterative approach, 3 iterations)?
6. What do you think about the combination of Mashups and RFID (to enhance the customer
experience)?
- 71 -
Shopping Scenario
A user is interested in buying a book as a present for a friend. In possession of an RFID-integrated
mobile device such as a PDA with an integrated RFID reader, the user may enter a bookshop and start
looking at a range of books which he thinks might be of interest to his friend. Upon finding an item of
interest, the user would like to know what other similar items he could buy for his friend, and if
buying it online would be cheaper. The shop might be crowded, and there may not be a shop assistant
nearby or available to the user to ask for assistance. Additionally, an assistant would typically be
prohibited to encourage customers to buy online. Bearing these factors in mind, the user instead picks
up an item of interest, switches on his mobile device and scans the specific item using the device’s
built-in RFID reader. Once scanned, the device will communicate with the shop’s database,
requesting basic information on that item. Upon receiving this information, the device will connect to
a Mashup server located in a remote area, requesting more information on the scanned product. The
user, unaware of these occurring communications, browses to the Mashup website with the help of the
personal device. He is then faced with a list of items he previously scanned on that same day. The
website allows the user to select one of these entries in order to obtain more information on an item.
Once selected, the user is presented with information on the scanned item, including price and rating
obtained from Amazon and Yahoo services. The webpage also shows the user a list of similar items,
along with an image, price and rating for each of these items.
- 72 -
Prototype Architecture – Deployment Diagram
- 73 -
Appendix H – RFID Workshop Correspondence
-----Original Message----From: [email protected] [mailto:[email protected]]
Sent: 26 March 2007 19:02
To: [email protected]
Subject: RE: Hybrid World Lab
Hi Deborah,
…
About my project, I have actually already implemented a simulated mobile
application using an RFID Phidget toolkit. Once an RFID item is scanned,
more information will be gathered from Yahoo Shopping as well as Amazon ECommerce web sources. The workshop really caught my eye on the fact that it
is, just like my project, focusing on narrowing the gap between the
'physical' and the 'virtual' world, thereby enhancing the customer
experience. So I believe the workshop can be a step further for me to make
my application more realistic (using an actual RFID-integrated phone), but
also to improve my knowledge on the subject.
Regards,
Michael
From: Deborah Meibergen - Mediamatic [mailto:[email protected]]
Sent: 26 March 2007 09:51
To: [email protected]
Subject: Hybrid World Lab
Dear Michael Hollander,
I received your registration for the workshop, the deadline for enrolment
is April 27.
As soon as I have more details / information about the workshop I will
inform you about this.
…
Your project sounds interesting, I'm sure this workshop can give you a
extra set of 'tools' for your project.
If you have other questions, please contact me.
Best regards,
Deborah Meibergen
Workshop co-ordinator
MEDIAMATIC
[T] +31 (0) 20 638 99 01
[F] +31 (0) 20 638 79 69
[W] www.mediamatic.net
- 74 -
Appendix I – Product_Info Table
Epc
Product
Rating
Date_time
Image
Similar1
Price_amazon
Price_yahoo
01023c1182
Dan Brown
4
2007-03-21
http://ec1.images-
Dan Brown|Digital Fortress: A
$9.99
2.95 - 139.95
13:03:46
amazon.com/images/P/14165248
Thriller|3.0|$7.99|http://ec2.images-
00.01._SCTHUMBZZZ_.jpg
amazon.com/images/P/0312995423.01._SC
$999.99
319.95 - 525.00
Deception Point
THUMBZZZ_V47013259_.jpg
010238a5e4
Toshiba HD-A1
HD DVD Player
4.35
2007-03-21
http://ec2.images-
null|Casino Royale [Blu-
16:56:43
amazon.com/images/P/B000M6X
ray]|4.5|$38.96|http://ec1.images-
KEK.01._SCTHUMBZZZ_.jpg
amazon.com/images/P/B000MRA5NS.01._
SCTHUMBZZZ_V46853516_.jpg
Table 1: Simulated data within the Product_info table (discarding unnecessary columns)
- 75 -
Appendix J – Unit Testing
Test Id
Section
Module
Description
T0
Client Testing
RFIDScan
When starting the
application, the
system awaits RFID
attachment.
Expected
result
T1
When an RFID
reader is attached to
the mobile device,
the reader gets
activated.
Expected
result
T2
When an item is
scanned for the first
time by the reader,
the program calls the
ProductInfo class to
obtain more
information on its tag.
When an item is
scanned for a
consecutive time, the
program does the
same as in test T2.
Tag in
close
proximity
to reader
Expected
result
Tag in
close
proximity
to reader
ProductInfo
should not be
called for
already
scanned
items
When initialised,
method call_db() will
be called. It will
connect to the shop
database, retrieving
and storing the EPC
number, product
description and
category for the item.
Method write_file() is
called after
connection to the
database has
completed. The
method writes the
stored information
(T4) into a text file.
New session – an
item is scanned; text
file contains a single
line of text.
Existing session –
another item is
EPC
number
obtained
from
RFIDScan
module
Expected
result
T3
T4
T5
T6
T7
Client Testing
ProductInfo
Input
- 76 -
Results
Expected
Results
Expected
Results
Expected
Results
Remarks
The LED on the
RFID Reader is
turned on during
scanning, and the
EPC number is
displayed on the
console.
A list of scanned
items should be
stored. When an
item is scanned, it
should be
compared to that
list.
Database
connection
information is
displayed to the
console to
confirm
connection/discon
nection status.
Each line in the
text file contains
information on a
scanned item.
T8
scanned; text file
contains 2 lines of
text.
New session – an
item is scanned; text
file contains three
lines of text.
- 77 -
Text file
should be
cleared when
a new session
occurs.
A variable should
be passed from
RFIDScan in
order to know
whether a
scanned item
belongs to a new
session or not.
This will in turn
help ProductInfo
determine
whether the text
file should be
overwritten or
appended.

Michael Hollander BSc Computer Science (Industry) 2006

Transcription

Similar documents

Join the Hundreds of Locations Now Powered by

Omni-IDMax® SQ

AutoCount - Idea to Product Competition

The Three Waves of RFID

Read More - United Central Industrial Supply

technology solution

Infographie EN