Project Mobilis
A German-Brazilian collaboration
Technical University Dresden (TUD)
Catholic University of Rio de Janeiro (PUC-Rio)
Federal University of Minas Gerais (UFMG)
2007-2009
Proposal of the General Architecture of the Mobilis Application
Prototype (MAP)
Version
Date
Editor
Description
1.0
9.5. 2008
PUC Team
First, general architecture
1 Introduction
This document presents the proposed general architecture of the Mobilis Application Prototype
(henceforth, named MAP) as it will be implemented by the PUC team. It is based on the overall
requirements specified in 8, and details the work plan [5], but some service names have changed as
follows:
•
CMS has been renamed to Context service
•
MPS has been renamed to Maps service
•
FFS has been renamed to Fun flags service
•
GDDS will be implemented by SDM + NaradaBrokering (see below)
•
GLBS now is just a simple wrapper of positioning information (as part of Context service)
2 Overview
MAP uses OGSi, the Android SDK [2] and the Publish-Subscribe infrastructure NaradaBrokering [3]
for distribution of data and events between the devices. MAP is composed of a client component
executing on the (mobile) user devices, and one or more NaradaBroker servers, executing on
stationary hosts of the wired network. In the following, we describe the structure of a MAP's client.
MAP client is composed of: one Basic service, the Shared Data Manager (SDM), at least three Mobilis
Services: Context service, Maps Service and Fun flags Service, and a common GUI framework (all
but the last are OSGi services). Hence, it will be possible to include or remove new services
dynamically, and OSGi, enables services to announce and discover their interfaces for the purpose of
inter-service method invocation. The set of instantiated Mobilis Services at a client will constitute the
application functionality offered to the users. When MAP is used by a group of users, it is assumed
that the clients have a same set of instances of Mobilis Services executing on the corresponding
devices.
In the first version of MAP, we will consider static user groups, and just implement a simplified
Groups service, which just shares a list of active group members (and some attributes) with the
remaining services. We will also implement a simple Chat Service for Mobilis (but since it is not the
main focus of the Tourist Scenario, it will not be further detailed in this document.
2.1
Shared Data Manager
The SDM is a basic service used by all Mobilis Service executing on the client to exchange data and
events both locally, i.e. with another Mobilis Service, or remotely, with instances of Mobilis Services
executing on remote devices.
It implements both a Request-Reply and a Publish-Subscribe interface to the Mobilis Services, through
which these can explicitly and synchronously (Req/Rep) or anonymously and asynchronously
(Pub/Sub), communicate with each other. SDM also implements the transcoding of local requests to
the NaradaBrokering Pub/sub interface, i.e. each SDM will be both a NaraderBrokering publisher or
subscriber, as a surrogate of the local Mobilis Services demanding some remote sharing of data or
events.
SDM also has a data repository that caches locally data that Mobilis Service instances (local or
remote) are sharing. Figure 1 shows the general structure of the client.
In principle, Mobilis Services can share nearly every type of data, which is also supported by the
Mobilis Prototype - Executive Summary
2 of 7
NaradaBrokering infra-structure. Each sharable data is encapsulated by an object with metainformation. The meta-information will essentially include an objectID, describe the source, the type
(or coding format), the semantics, and other information concerning the shared object. This
information will be used by Mobilis Services to announce, discover and check type compatibility of
shared objects.
In the first version of MAC we will not implement a Discovery Service for sharable data, but the goal
is to later use the pub/sub infra-structure also for this discovery.
Mobilis Application
GUI Framework
Maps Service
Groups Service
Context Service
Fun Flags service
Shared Data Manager
Figure 1: General architecture of a MAP client
2.2
The GUI Framework
The GUI framework is a set of objects used by all Mobilis Services to create standard panels (views)
for receiving user commands and displaying the Mobilis Service's output. Moreover, the GUI
framework provides graphical controls that show all the OSGi services which are executing, and
allows the user to manage them (e.g. start/stop them, or toggle between their GUIs). These general
GUI controls are provided by vertical and horizontal tool or rule bars at the display's border.
Each Mobilis Service has its GUI composed of several independent views (min: 2, max: 4, described
in the following) each of which fills almost the entire area of the device's display (3-5 inches).
Hence, at any time, at most one view of a single Mobilis Service will be the focus of the user's
interactive events - we say that this view is 'open'.
The other views of this Mobilis Services are collapsed (minimized) into a tab shown in a horizontal
ruler at the bottom of the display. As soon as the user selects any such tab, the corresponding view is
opened, and the previous view is collapsed into a new tab. On a vertical ruler, all the remaining
Mobilis Services that are executing, but which have no open view, have a corresponding tab.
The four possible views of any Mobilis Service are, of which only the first is mandatory.
Control: allows the user to input service parameters and preferences, and to manage the service's life
cycle (e.g. start, stop, suspend, resume)
Global: displays a global view (e.g. overview) of the data and supports a macroscopic navigation in
the data space (think of a map)
Focused: displays a focused view (e.g. detailed) of the data, and supports a view-specific navigation
and input commands
Event: displays the set of latest, and yet unvisited, asynchronous events of the Mobilis Service. When
a new event arrives while this view is minimized, the corresponding tab will change its color (or blink)
until it the view is open, in order to direct the user's attention to this fact.
Mobilis Prototype - Executive Summary
3 of 7
3 Basic Functionality of the Mobilis Services
3.1
Application
The application (i.e. an instance of the GUI Framework), when started, requests information about
group members and their context (location and connectivity) and for fun flags within a delimited
region. It requests this information directly to the Groups service and to the fun flag service.
The application opens the map on the screen pin-pointing the objects that represent fun flags and
group members. The further changes in their position or state will be updated through Shared Data
Manager.
3.2
Maps service
Composed by a MapView and a MapController – the Google API view and model classes – Maps
service is responsible for showing the map, fun flags and group members’ location. It permits the
navigation and zooming in the map, as well as the creation of a new fun flag. It does make no
difference between group members and fun flags, it only places graphical objects on the map.
3.3
Groups service
Maintains the information about who are the current group members – including the local user –, their
location and connectivity. If the user is off-line or doesn’t belong to a group, the group is composed
only by himself. The information is updated automatically through the context service.
3.4
Context service
Provides to the groups service the interested users’ location and connectivity. With the information
about who is member of the group, it is possible to locate a member and get information about him. It
alerts the groups service if any change in a group members’ status or location occurs.
3.5
Fun flags service
This service is responsible for managing (creating, removing own, etc.) fun flags and finding and
storing information about fun flags registered from members of the local user’s group on a specified
region and/or interest subject. This information is updated as other fun flags are created or updated.
To reduce the stored information and network traffic, the application can subscribe only to a specific
interest in fun flags. Fun flags will have an attribute that describes their type, which will be used to
differ between different interests.
It is also possible to register for a fun flag only in a specific region, e.g. the region which is shown on
the user’s display.
3.6
Shared Data Manager and its interactions
The Shared Data Manager is responsible for the communication between services on the same device.
It can be used in Req-Reply-mode or Pub/Sub-mode, and delivers the shared data based on a specific
interest.
It is used for the communication between Maps, Groups, Context and Fun flags services, specifically
for information that is updated on-the-fly.
Mobilis Prototype - Executive Summary
4 of 7
From
Application
Maps
Groups
Context
Fun flags
To
Application
Fun flags and
members location
Maps
Information about
group members,
their location and
connectivity
Group members’
fun flags, their
description
and
location
Members updates
Fun flags updates
Specific
users’
location
and
connectivity and
their updates
Groups
Context
Fun flags
Fun flag creation,
deletion or modify
request
Table 1. Interactions among Mobilis services
The items in red are the information exchanged through the Shared Data Manager.
4 Interactions among the Mobilis services
4.1
Initialize map, group members and fun flags position
When the application is opened, it asks groups service for the group members and their context, and
asks Fun flags service for fun flags on a region and a topic.
These services will answer to the application, which is going to show the map on the screen with the
available information.
Fun flags service will exchange information directly to get other members’ fun flags. Groups services
will find out who are the members of the group (including the local user) and ask the context service
about their location and connectivity.
4.2
Update members positions and connectivity information
The groups service has to subscribe to SDM to receive from context service events related to user
moving or connections and disconnections.
The same way, maps service has to subscribe to SDM to be notified from groups service if any
important group members’ context has changed.
The local context service has to propagate any changes to other group members’ Context services.
4.3
Remote updates in fun flags
The Maps service has to subscribe to SDM to be notified from fun flags service if any fun flag was
created, deleted or modified.
Mobilis Prototype - Executive Summary
5 of 7
4.4
Local updates in fun flags
The fun flags service has to subscribe to SDM to receive notifications from maps service about
requests to create, delete or modify a fun flag. It then has to propagate this change to other group
members.
5 Next Steps
1. Define the main user commands and views of the Maps, Context, Groups and FunFlags
Service
2. Set up the general data & meta-data model for sharable data, according to the types of data
shared between the Mobilis Service instances
3. Elaborate use cases of SDM-based data sharing (by the Mobilis Services)
4. Study, and make practical experiments with the google service’s APIs
5. Implement the SDM, its interaction with NaraderBrokering, and early versions of Groups,
Maps and FunFlags Services
6 Main Milestones of the Development
•
April/2008: Draft Architecture of the prototype application as a framework for pluggable
services (done)
•
June/2008: First version of SDM and prototype GUI Framework
•
July/2008: First operational version of Maps, Groups, Context and Fun flags services
•
October/2008: Refined version of the services, and first version of the integrated application
framework with pluggable Mobilis Services
7 Team Members & Main Responsibilities
Name
Contact
Tasks/Responsibilities
Ricardo C.A. da Rocha
[email protected]
Development
of
Context
Development Manager
Skype: rcarocha
Juliana F. S. Aquino
[email protected]
Skype: julianafsa
Hubert da Fonseca
[email protected]
Service
&
Development of Shared Data Manager & GUI
Framework
Development of Maps & FunFlags Service
Skype: ??
Marcelo G. Malcher
[email protected]
Development of Maps (core features) + GLBS
skype: marcelomalcher
Tathiane Mendonça
[email protected]
Skype: tathiane.mendonca
José Viterbo Filho
[email protected]
Skype: jviterbo
Mobilis Prototype - Executive Summary
Development of Chat Service + GUI Framework
(prototype)
Use Cases of user commands and views for
Maps and Fun Flags Services
6 of 7
8 References
[1]
Daniel Schuster, Specification of Mobilis First Prototype, V. 0.2, Dec. 2007
[2]
Android – An Open Handset Alliance Project, http://code.google.com/android/
[3]
The NaradaBrokering Project @ Indiana University, http://www.naradabrokering.org/
[4]
W. Dargie, R.C.A. da Rocha, (Eds.), Requirements for Tourist Application, Mobilis-internal
specification, December 2007.
[5]
PUC-Rio Team, Mobilis First Prototype: Work Plan of the PUC team, v.01, April 2008.
Mobilis Prototype - Executive Summary
7 of 7