ubimarket
TRANSCRIPT
UBIMarket Report 2014-2015
Small Ubiquitous development System.
University of Murcia Tel +34 968 36 30 00
Campus Universitario de Espinardo, s/n, 30100 Espinardo, Murcia, Spain
www.um.es
Table of Contents
Contents
Introduction _________________________________________________________________ 1
UBIMarket short description ____________________________________________________ 2
UBIMarket some screenshots ___________________________________________________ 4
Implementation _____________________________________________________________ 11
Conclusion_________________________________________________________________ 16
Contact information __________________________________________________________ 17
Pg. 01
Introduction
Introduction The purpose of this report is to provide a short description of UBIMarket project. We will give
some details about the scenario applied in this project and some details about the structure of
the system and its implementation. UBIMarket is a small ubiquitous system applied to a
supermarket scenario. It is based on the idea of ubiquitous computing in which we have that
computing must appear anywhere and everywhere in our life, helping us more than computers
do actually. The idea behind ubiquitous computing is that every different systems must interact
with each other because in this way they are more powerful helping us, taking autonomous
actions. And then a user using a device can interact with this big system (“ubiquitous”).Taking
in consideration ubiquitous computing, I tried to build this small system that help the
consumers of the supermarket take in real time all the offers published by a producer. The
consumer can use its smartphone or tablet or any other device to interact with the system of
supermarket. In consumer device must be installed a software that provides communication
with supermarket system to get the offers provided by producer.
UBIMarket helps
Supermarket
consumers to
receive in real
time all offers to
which they are
subscribed to.
Pg. 02
UBIMarket short description
UBIMarket short description UBIMarket is composed by 3 types of applications:
1. UBIMarket_Producer_Java_app, a java desktop application that allows the producer to
publish offers.
2. UBIMarket_Producer_Android that allows the producer to publish offers using its
smartphone. This helps the producer to use the system every time.
3. UBIMarket_Consumer_Android that allows the consumer to receive offers in real time.
Producer can publish all types of offers and the consumers are allowed to choose the types of
offers he wants to receive. This is the way the user context as one of the important
specifications of a ubiquitous system. System is developed taking in consideration properties of
ubiquitous computing that specify that the system must be:
1. Autonomous
2. Context aware
3. Distributed
4. Intelligent
Producer can use UBIMarket_Producer_Java_app if he is in his office and working with his
personal desktop computer .Producer can also use UBIMarket_Producer_Android from his
mobile and he can publish offers whenever he/she is located. In both apps the producer first
must select the product and then the product item for which he wants to publish the offer.
Consumer can use UBIMarket_Consumer_Android to express his preferences and see the
offers in real time based on his preferences. So in this case the system can be adapted based
on the user preferences (here is where Context aware takes place).Consumer can select the
products for which he wants to get offers , this process is called subscription and specifies the
user preferences to which the system must behave.
Figure 1 shows a sample idea about things mentioned above.
Pg. 03
UBIMarket short description
Figure 1
But how does this parts of the system communicate with each
other?
From the picture above we see that they are all connected to one single point that is the core of
the system. The core of the system is a broker. The broker establish the connection with the
producer and the connection with the consumer.
How does the broker function?
Broker is a middleware in our system. After receiving messages from producer the broker
distributes the messages to the consumers based on their preferences. More details about the
type of broker we have chosen and the architecture of our broker will be given in the
implementation section.
Pg. 04
UBIMarket some screenshots
UBIMarket some screenshots Taking in consideration the user – system interaction or (HCI) that is one of the properties of
ubiquitous system, the system is very simple to be used and the most part of the work Is done
by the system based on the preferences of the consumer.UBIMarket offers a beautiful GUI and
simple actions to be performed by user, this motivates the user to use app and feel comfortable
with it.
UBIMarket_Producer_Java_app :
GUI of this app is shown in figure 2. As we see the producer in 4 steps places offers into the
system.
Figure 2
After the producer places the offer a successful confirmation message is shown to him.
Figure 3
Pg. 05
UBIMarket some screenshots
UBIMarket_Producer_Android :
Here to better present to the producer the product categories and product items is used
expandable list in which the producer easily selects the product item. In figure 4 is shown the
putt offer interface.
Figure 4
After user selects a product item an input box is shown to him as presented in figure 5.Here
producer puts the percentage of the offer he want to place for this product item.
Pg. 06
UBIMarket some screenshots
Figure 5
After user presses OK button, if everything is ok a confirmation message is shown to the user.
Figure 6
Pg. 07
UBIMarket some screenshots
UBIMarket_Consumer_Android :
If the consumer opens for the first time the app it requires the name of the user as shown in
figure below. This is part of the configuration and is shown to the user only one time.
Figure 7
Then directly to the user is shown the subscription interface which consumer can select the
product to which he wants to get offers. This step is shown in figure 8.
Pg. 08
UBIMarket some screenshots
Figure 8
After the user subscribes now we can say that the app is fully configured. The main interface is
shown to the user, giving information to him about the products subscribed. As we see
consumer is able to change the subscription list or directly can see offers in real time for the
subscribed products. This step is illustrated in figure 9.
Pg. 09
UBIMarket some screenshots
Figure 9
Consumer can see offers in real time after he presses View offers button. Figure 10 presents
this interface. As we see to the consumer is show even the time to which the offer was made.
Pg. 10
UBIMarket some screenshots
Figure 10
Chief Executive Name
Chief Executive Title
[Date]
Pg. 11
Implementation
Implementation In this section the scenario, how the whole system works will be described. As we mention
before, we have 3 types of applications. Java_producer_app is installed in a desktop pc and
producer can use it from his office to publish offers. As we see the application uses an XML file
to receive the product list and product items, this because this is only a demo version of the
system, but in reality the list must is got directly from supermarket server. So we are using a
static list just for demonstration. All the apps of the system use this XML file. The most
important point of the system, as we discussed before, is the broker server because it establish
the communication between two systems. In the figure below is show a simple illustration.
The Broker
As we mentioned before Broker serves as a middleware for our system. We have used a
broker because the system is efficient and scalable. Broker takes care and manages the
communication between producer and consumer. As we know we have different types of
middleware based on the communication type:
Synchronous communication middleware:
Asynchronous Communication middleware:
The best type for our scenario is Asynchronous Communication, because the client (consumer)
is not blocked waiting for any return message. The message is returned to the after being
Pg. 12
Implementation
processed and user during that time can actually perform different action without being blocked
until a response is taken.
We have chosen MOM (Message Oriented Middleware) because is one middleware system
that follows an asynchronous communication model. We have a producer that publish offers
and a consumer that is subscribed to offers. There are messages exchanged between
consumer and producer and MOM supports publish–subscribe messaging architecture.
(MOM) is middleware where transactions or event notifications are delivered between
disparate systems or components by way of messages, often via an enterprise messaging
system. With MOM, messages sent to the client are collected and stored until they are acted
upon, while the client continues with other processing. Taking in consideration the
requirements for UBICOMP middleware that are:
Interoperability
Discoverability
Adaptability
Scalability
Security
Autonomous management
In this case is EMS that considers some of this requirements. EMS systems are facilitated by
the use of structured messages (such as using XML or JSON), and appropriate protocols, such
as DDS, MSMQ, AMQP or SOAP with web services.
We have chosen AMQP as an open standard application layer protocol for message-oriented
middleware. The defining features of AMQP are message orientation, queuing, routing
(including point-to-point and publish-and-subscribe), reliability and security. The reasons why
we have chosen AMQP are:
AMQP is more flexible
AMQP offers interoperability
How AMQP works?
The main components as we see are:
Publisher
Subscriber
Pg. 13
Implementation
Exchange
queue
The publisher in this case represents the producer that publishes offers and the subscriber
represents the consumer that subscribes to the offers.
We see here 2 other important components that are the core of the broker that are:
Exchange
The core idea in the messaging model in RabbitMQ is that the producer never sends any
messages directly to a queue. Instead, the producer can only send messages to an exchange.
When publisher sends a message he has to specify also an identifier called routing key.
Exchange receives messages from publisher and manages this messages sending them to
specific queue based from the type of the exchange and from the routing key of the message.
Exchange can be direct: The message will be send to the queues when the routing key of the
message is equal to the binding of the exchange.
Pg. 14
Implementation
Exchange can be fanout : When the consumer joins to a exchange using this type of binding,
it will receives all the events of this exchange.
Exchange can be topic: he consumer joins to exchange using a pattern (topic. Queue.*). If
the routing key of the received messages matches the pattern, the message is sent to the
queue.
For this system we have chosen topic exchange type because consumers can subscribe to the
entire product category of the product, for example: they want to get all the offers for drinks,
and we know that drinks is a product category. In this case he can make a subscription using
this pattern: “drinks.*” and all the messages containing a routing key that matches the pattern,
will be stored in this queue connected to the exchange using this pattern
Queue
Queue is connected with exchange through binding. A queue is the name for a mailbox, in
which we can store as many messages as we want. Queues are bounded to exchange through
a routing key, so bindings can take an extra routingKey parameter. Consumer in our case
make the subscription using queues. To a queue can be connected more than 1 user, because
there can be users that have the same subscription policy.Also a user can be connected to
more than one queue.
But, MOM unfortunately requires extra component in the architecture, the message transfer
agent (message broker).
On the market there are a lot of message broker software’s, some of them are free some are
open source ect.We have chosen rabbitmq as a message broker for our system.
WHY rabbitmq ?
It is open source
It implements the Advanced Message Queuing Protocol (AMQP)
It is cross-platform
Pg. 15
Implementation
So it provides to us all the things we need to build our system. To implement rabbitmq we have
to download:
1. RabbitMQ Server (must be installed and configured)
2. Official Client libraries (that are used to build client app to interact with the broker)
Using Client libraries of RabbitMQ we are able to:
Declare an exchange
Declaring queues bounded to an exchange based on the routing key
Publish offers
Make subscription to a queue
Pg. 16
Conclusion
Conclusion This is a small system trying to illustrate an example of how a ubiquitous system must be and
how this type of system will help us in the future with everything in our everyday life. In our
case the consumer is directly connected to the supermarket system and the supermarket
system is helping user with the information about offers it provides, but the same idea can be
applied for other cases.
Pg. 17
Contact information
Contact information
Mikel Berdufi
University of Murcia
Campus Universitario de Espinardo, s/n, 30100 Espinardo, Murcia, Spain
Tel +34 968 36 30 00
Fax [Fax]
www.um.es