Atlas Service Programmers’ Manual
Introduction
1. Service Oriented Architecture (SOA)
SOA has established itself as a "prevailing software engineering practice" in
recent years [McCoy and Natis, 2003]. Its popularity extends to the domain of
pervasive computing. Its characteristics of loose-coupling, stateless, and
platform-independence make it an ideal candidate for integrating pervasive devices.
While the semantics of SOA are being standardized, its use in pervasive computing is
under research and being experimented [Yang et al., 2008].
SOA basic represents the idea that in order to support dynamic and distributed
environment, and allow devices and services to participate or excuse at any moment
during the operation, each piece of software has to be broken into smaller, more
manageable services. Just like Lego blocks, more complicated software can be
stacked up using simpler services as basic building blocks, while each service can be
used by multiple services as long as they are compatible. The power of SOA resides in
the fact that services are interchangeable, hence can be removed or inserted as the
situation arises. The system can attempt to find replacements should existing
services become unavailable, and arrival of newer services may in fact enables the
composition of new services, or enhances existing ones.
The basic unit of software in SOA is a service. Services in a pervasive computing
system are more complicated than their counterpart executing in desktop or in
client-server architecture, as the heterogeneity and dynamicity of the environment
make proper management of changes in availability of critical resources a necessity.
A system that employs SOA, not only regular software artifacts carrying business
logic, but also devices are represented as services with additional characterizations
and restrictions.
A service is one of a group of software artifacts with specific objectives. They
require necessary resources to accomplish these objectives, including devices
(hardware) or other services (software). The functioning of these services often
requires communications and interactions with other services in dynamic
environments, which means the necessity of explicitly defining their dependencies
and service interfaces.
The business logic and lifecycle, in most of popular programming language today,
are likely hidden behind objects or procedural calls, and the only information
available is signature and public attributes. The advantage of this approach can be
found in discussions and books about programming languages. But in pervasive
computing environments, it poses as both an advantage and a disadvantage, since
dynamic compositions are common, and it allows any developer to plug in software
artifacts as long as the interfaces are consistent, but makes no revelation or
guarantee about the compatibility or correctness of the implementation. In most
practical situations, it often relies on the implicit trust on the vendor or programmer
to assume that the software artifact delivers the goals while avoiding the traps.
2. Atlas Architecture and OSGi
The Atlas architecture is a framework for pervasive computing systems in the
Mobile and Pervasive Computing Lab at the University of Florida, which provides a
scalable network-enabled, service-oriented middleware in which numerous and
heterogeneous sensors and actuators can be automatically represented as software
services upon activation. It offers programmers with services and associated utilities
to manage devices and compose applications without the detailed knowledge of the
physical characteristics of the devices or the sensor platform node. The Atlas
architecture, which includes both the middleware and the sensor platform as shown
in Figure 1, provides an all-around solution to the development and deployment of
pervasive computing systems.
Figure 1 Atlas Architecture
The middleware layer of the Atlas architecture has heavily utilizes the
framework provided by OSGi. OSGi is the abbreviation of Open Service Gateway
Initiative supported by OSGi Alliance, a non-profit group collaboration whose
members include some of the biggest names in computing, appliance, and telecom
industries, such as IBM, Sun Micro, Red Hat, Samsung, Hitachi, NEC, etc. OSGi aims to
be the universal middleware. With great support in dynamic lifecycle management,
this technology allows programmers to create service-oriented, component-based
dynamic module system implemented in Java. It promotes high level of
interoperability, and creates systems that are robust, and unflinching in dynamic
environments.
3. Software Engineering Process of Service Implementation
The process of designing and implementing a new service is summarized in a
flowchart (Figure 2).
4. Basic Structure of Software within Atlas Architecture
A service using Atlas architecture can be represented using the following three
entities, service description, interfaces and software artifact(s) that actually provide
the expected service. Sometimes the interfaces or knowledge associated with service
description may be embedded within the code, but with the SOA approach, it is
preferable to make them explicit to facilitate the dynamic interactions. For example,
the reference implementation of OSGi platform suggests explicit definition of
interfaces, places dependency related information in the manifest, and bundles them
together with associated classes into a single bundle
The typical software structure within the Atlas architecture include 3 Java
classes/interfaces and a manifest file.
1. The interface presents the public methods that other services can invoke;
2. The activator class implements lifecycle management functionalities, so the
service can be enabled, disabled and adapt properly;
3. The implementation class is where the service logic resides. The computation,
communications and processing specific to the service is implemented in this
class;
The manifest file must be both human and machine readable. It includes all the
basic generic information about the service, author, and support, as well as the
specification of the java package dependency between services.
In addition, as an integral part of the implementation, programmers also have to
provide detailed information about the target service, such as supported methods,
allowable parameters, operation conditions, supported protocols and in case of
devices, hardware interfaces, etc, in a descriptor file, using the device description
language (DDL).
Start
Design
Include/Convert
documented design spec
Define service
objectives
Implementation
Review design against
service objectives
spec
Devise service
logic
Identify resource
and dependency
Implement service logic
Verification/
Compilation
Implement emergency
handler
Deployment
Design software
architecture
Detailed design
Implementation
End
Class
Interface
Service Logic
Methods/Interfaces
Manifest File
Impl. Safety API
Operational
Service Descriptor File
no
yes
Build File
Impl. emergency
handler
Customization
Misc. Info
no
yes
yes
Dynamic Info
General Service Info
Desc. File
Verified
no
parameters
Dependency/Resource
Other Info
yes
Compilable
no
Figure 2
Flowchart for programming services
5. Atlas Programming Toolset
The Atlas programming toolset is provided to assist programmers in
implementing new services based on the Atlas architecture more efficiently and
effectively. Two major authoring aides are included in the toolset, an integrated
development environment (IDE) which allows programmers to devise more
sophisticated services, and a service generator which can be used to automatic
create service bundles from the semantic descriptions using device description
language (DDL), particularly useful when dealing with more rigidly defined hardware
device related services.
Assistances and benefits offered by the IDE includes,
 Provides step-by-step guidance to design new service
 Enforce explicit specification of semantic knowledge on service/device and
user during implementation
 Provide templates of various source code
 Hide the complexity of OSGi bundle programming and the interaction with
safety mechanisms from programmers
 Verify existence of explicit descriptor files and Safety API before deployment
 Allow remote programming of intelligent environments
Assistances and benefits offered by the service generator includes,
To be provided by Chao.
6. How to Choose Which Tool to Use When Programming Services
To be discussed with Chao.
Summary of Device Description Language (DDL)
1. Overview
DDL (Device Description Language) is an XML-based description language which is
being developed to initially support the integration of devices such as sensors and
actuators to the intelligent environments. However, the specification is being written
with enough flexibility to accommodate actuators and more complicated devices
such as blood pressure monitors. DDL enables a uniform schema to describe devices
and defines a proposal to the Service Oriented Device Architecture (SODA) standard.
The major goal of SODA is to represent devices such as sensors and actuators as
services in today’s enterprise Service Oriented Architecture (SOA). With well-defined
interfaces, software services are everything application developers need to know to
bring together the devices and program the smart space. They should not worry
about the nitty-gritty details of each ports and pins. However, the reality is that
wiring and interfacing with devices of all types has been one of the major headaches
of the real-world developer. This community needs a convenient solution that closes
the gap between the physical devices and digital world. DDL provides a standard tool
that describes a variety of devices in a common language that are readable to both
human users and computer programs. It creates a common interface for sensors and
actuators and enables automatic integration of these devices in the programmable
smart space.
This manual serves as a quick starting point for programmers who have no previous
experience with DDL. For more detailed information of the language, the DDL
Specification (version 1.2 available at http://www.icta.ufl.edu/atlas/*.*) consists of a
complete documentation and several sample applications. Also available online is a
DDL language processor (version 1.2 available at http://www.icta.ufl.edu/atlas/*.*)
which is a piece of software capable of parsing and verifying DDL documents and
creating service bundles that represent devices in the SOA framework. These
documents and tools provide good resources for learning the DDL language.
The remaining of this section is organized as following. Section 1.2 goes over the
basic syntax and semantics of the language. Section 1.3 briefly explains the
mechanisms of service oriented architecture and then provides a quick glimpse at
some example applications of DDL.
2. Basic elements of DDL
In DDL, a device is characterized as a physical (hardware) or logical (software service)
entity consisting of a set of properties, some internal mechanism responsible for the
operation of the device and interfaces to receive input from the device or send
output to the device (Figure 1). From a service-oriented perspective, the
characteristics of a device which are essential to its utilization by an external user are
its properties and interface. The properties provide information about a device such
as its purpose, its capabilities, vendor and operating requirements. The interface
defines how a device interacts with its external users and provides ways to access the
device either to get information from it and/or to control it.
I
External
Output
System
t
Input
Internal
n
e
Mechanism
Properties
r
f
a
Figure 1. Characterizing
c a Device
e
In DDL, devices are classified into three categories according to the difference in
interfacing: Sensor, Actuator and Complex Device.

Sensor: A sensor is a device which only provides input to the external user.

Actuator: An actuator is a device which only accepts output from the external
user.

Complex Device: A complex device is one which can both accept output from
the external user and provide input to the external user.
The DDL specification provides a more detailed definition of these three categories
and an example device of each category. In this manual, however, we mainly focus
on sensors which are the most common and the easiest to describe.
2.1. Description of Sensors
A DDL document of a sensor consists two parts: description and interface.
Description provides name and model information of a device, as well as high-level
function descriptions and deployment requirements to application developers and
system integrators. The Description element includes tags such as Name,
Device_type, Verbose_description, Vendor, Version and a composite element
Physical which provides dimension and operating environment information for
deployment. Figure2 gives an example of the Description element that describes the
temperature sensor.
<Description>
<!-- Identification information of the device -->
<Name>
<!-- Name of the device -->
Temperature Sensor
</Name>
<!-- Type of Device (Physical(Singleton) or Virtual) -->
<Device_Type>
Physical
</Device_Type>
<Verbose_Description>
<!-- Description of the device -->
TMP36 Analog Temperature Sensor
</Verbose_Description>
<Vendor>
<!-- Device vendor -->
University of Florida
</Vendor>
<Version>
<!-- Device version -->
1.0
</Version>
<Physical>
<Dimensions>
<!-- Dimensions of the device -->
<Length>
<!-- Length in mm (not available for virtual sensor) -->
24
</Length>
<Width>
<!-- Width in mm (not available for virtual sensor) -->
34
</Width>
<Height>
<!-- Height in mm (not available for virtual sensor) -->
24
</Height>
</Dimensions>
<Operating_environment>
<!-- Permissible environment for operation -->
<Temperature>
<Range>
<Min>
</Min>
<Max>
</Max>
</Range>
</Temperature>
<Humidity>
<Range>
<Min>
</Min>
<Max>
</Max>
</Range>
</Humidity>
</Operating_environment>
</Physical>
</Description>
Figure 2. Example description of TMP36 analog temperature sensor
2.2. Interfaces
From a data-oriented perspective, a device can be modeled as a process consisting of
inputs, data processing and output. In a service-oriented architecture, each device
has a service representation which provides access to its properties and interface
and abstracts away its internal operation. Hence, in this document we describe the
operation of devices in terms of input/processing/output from the perspective of
their respective service objects (devices are said to be members of their respective
service objects). In the description language described in this document,
communication between member device(s) and their service object are called
‘Signals’ and outputs sent from the service object to an external user are called
‘Readings’. The Interface element in DDL is a collection of Signals and Readings that
provide a way to define interactions between devices and applications.
Figure 3 shows a fragment of a DDL document that describes the interface of an
analog temperature sensor. The commented parts in gray color are explanations of
each element and attributes. For more detailed information, learners should read the
DDL specification and the DDL schema.
<Signal id=”s1”>
<!-- To avoid confusion, ensure Signal id is always alpha-numeric instead of numeric -->
<Operation>Input</Operation> <!-- Value of Operation attribute can be Input or Output -->
<Type>Analog</Type>
<!-- A Signal Type can be: Analog or Digital or Protocol or Logical
* Analog/Digital is a low level collection of pins
* Protocol is a high level interface to a device which has an
in-built communication protocol (example: AnD Blood Pressure Monitor)
* Logical is high-level device service.
-->
<Measurement>
<!-- Value of Measurement attribute can be: ADC, Digital or a string whose value
is equal to the Reading->Measurement attribute of another physical/virtual sensor
-->
ADC
</Measurement>
<Unit>null</Unit>
<Number>
<!-- Number can be Single or Multiple (many signal inputs of same type) -->
Single
</Number>
<Range>
<Min>0</Min> <!-- write null or leave blank if you don’t know -->
<Max>1023</Max> <!-- write null or leave blank if you don’t know -->
</Range>
</Signal>
<Reading>
<Type>
<!-- Type can be: Basic(Virtual Sensor), Derived(Virtual Sensor),
Physical (Singleton Sensor)
-->
Physical
</Type>
<Measurement>Temperature</Measurement>
<Unit>Centigrade</Unit>
<Computation>
<Type>
<!-- Possible value of the Type attribute can be: Aggregate, Formula or Map -->
Formula
</Type>
<Expression>
<!-- Possible valid Expression attribute values can be:
* For Type=’Aggregate’: Mean, Median, Mode, Max, Min, Sum
* For Type=’Formula’: <numerical expression as function of signal ids>
* For Type=’Map’: <map of signal ids to range of output values>
-->
<!-- The formula function conforms to Java syntax -->
reading = (((s1/1023)*3.3)-0.5)*(1000/10)
</Expression>
<Range>
<Min> <!-- can be calculated automatically -->
</Min>
<Max> <!-- can be calculated automatically -->
</Max>
</Range>
</Computation>
</Reading>
</Interface>
Figure 3. Example interface of TMP36 analog temperature sensor
Integrated Development Environment
To assist programmers in implementing safer pervasive computing services
based on OSGi, an authoring tool in the form of an integrated development
environment is provided to the programmers.
Eclipse is an IDE originally designed for Java programming. As it happens, OSGi
platform and the service bundles are also designed to be implemented in Java. The
decision to develop the IDE tool set as an Eclipse plug-in is therefore quite
straightforward. But there are more reasons for this design decision, Eclipse is
implemented to be completed platform-neutral, allowing developers to use Windows,
Linux or any other operating systems which can run Java programs. Eclipse provides
an open platform, allowing numerous third party plug-ins to integrated seamlessly
with Eclipse, hence allowing its capability to be further enhanced as the synergy
between the original functionalities and the installed plug-ins continues to grow.
Choosing to implement the IDE tool set on top of Eclipse makes it possible to
take advantage of all the available extensive capabilities, to allow programmers to
use an IDE they are probably quite familiar to start with, hence make the task of
programming safe and less error-prone OSGi services much less daunting for
programmers.
The implementation of this IDE consist of two parts, the front-end that allows
programmers to intuitively and easily design the new services using the tools
provided, and the back-end that actually offers these functionalities when activated
from the front-end.
As of today, the implementation of the Eclipse plug-in ver. 2.0 is almost
completed with the back-end, and the design of the front-end is just underway. This
document will focus on explaining the basic programming procedures as dictated by
the implementation of the back-end.
The programming process of a new service is organized into a six-step process:
1. Creation of a new project
2. Creation of semantic files
3.
4.
5.
6.
Retrieval of dependent bundles and projects
Generation of code template
Compilation and verification
Deployment into a runtime system
We’ll succinctly explain these six steps as following:
1. Creation of a new project
As with any other Java projects created using Eclipse, the plug-in create the new
project and setup the necessary directories and file structures for a new project.
What is different from ver. 1.0 of this plug-in is, ver. 2.0 does not automatically
assume all other projects within the same workspace are part of the dependency
requirement for the newly created OSGi service project.
2. Creation of semantic files
As per discussion in the Appendix A of my dissertation, it is crucial that the
semantic knowledge about the service, device and users are explicitly expressed
so as to avoid misunderstanding and enhance the interoperability in highly
dynamic environments. As part of the project creation process, important
semantic description and project management files are created using templates.
These files include
a. .project file: which describes the attributes of a project
b. .classpath file: which describes the classpath of all dependent resources at
the time of compilation
c. Manifest file: which annotates generic information and attributes about the
bundle (to be filled by the programmer), as well as the package dependency
d. Build file: which gives instruction on how and what to be compiled and build
into the final service bundle
e. Service descriptor file: which annotates detailed information about the
services, such as the methods supported, parameters, service dependencies,
user requirement alignments as well as emergency handler specifications
f. Logging property file: which denotes the various set up of service logs,
including level and location of what to be recorded
3. Retrieval of dependent bundles and projects
Services built on SOA have dependencies. They require the existence of other
services to support their proper functioning. Programmers can either specify
these dependencies in the service descriptor file, but they can also use
drag-and-drop operation from the front-end to include additional bundles and
services as dependent entities. Either way, the back-end would attempt to
retrieve these necessary bundles for the sake of proper compilations.
4. Generation of code template
Instead of generating the entire code that includes every function, the design of
the software structure is to place as much of the code associated with OSGi
bundle related operations and safety mechanism invocations to base classes,
hence maintaining a minimal and clean extended classes in the template when
presenting to the service programmers. The ultimate objective is to allow
programmers to implement services as easily and straightforward as regular java
applications without having to worry about these additional mechanisms. The
basic code structure in these generated code templates already includes separate
methods for operations such as state transitions and emergency handler
methods. Service programmers would only need to fill in the service logic in
appropriate methods created as part of the templates.
5. Compilation and verification
Prior to the compilation of the new service, the back-end performs a series of
verification, such as the support of the Service Safety API, the provisioning of the
emergency handler, and the conformance of semantic descriptions files to their
respective schemas. Although the correctness of the actual logic
implementations for these handlers cannot be tested without detailed
knowledge about the service, the step of verification ensures that at least the
programmers have provided some sort of procedures to be followed when the
worst come to happen. After the implementation of the new service is verified, it
is then compiled into a single service bundle in the form of a jar file.
6. Deployment into a runtime system
With a single press of a button, the IDE can deploy the compiled service into an
OSGi framework.
Currently, the design of the front-end includes views for browsing available
service bundles on any connected OSGi platform, the step-by-step guidance
information panel, the toolbar for tracking and manipulating the stages of the
six-step process, and all encompassed in a single OSGi service implementation
perspective. The detailed design of the front-end is still evolving, and may change
without further notice.
Device Service Bundle Generator
DDL is based on the concept that the availability of standard device descriptions
allows for the development of intelligent environment applications integrating
multiple sensors, actuators and complex devices. By representing each device as a
service in the service-oriented architecture (SOA), programming the smart space
becomes as easy as calling a number of methods from the device services. This
subsection provides an example project that shows how DDL fits into the SOA
framework and supports the programmable smart space.
The example showcased in this section is an application that uses DDL language
processor to automatically generate device drivers. In this example, the output of the
application is a driver program, which is a software entity that represents the device
in the SOA framework. It describes the functions and properties of the device and
allows interfacing with the other services and applications in an Atlas-enabled
software environment.
At the client side, user checks in the DDL document for a certain device through
the DDL web interface. The DDL document can be provided by the device
manufacturer or generated by the web script as user fills in the necessary
information in the HTML form. A DDL validity checker runs at the server side and
examines uploaded information for syntax errors. The errors and warning
information will show up on the webpage if there is any. If the errors are cleared,
the DDL file generator will create a downloadable DDL file for the device.
The DDL file device is then passed to the DDL parser and the driver generator.
This software analyzes the DDL document and creates a driver project for the device.
The project includes the source code for the driver program, build file and manifest
information and is buildable using Apache Ant 1.7.0 or higher.
Once the project file is prepared, they will be built automatically into the sensor
driver software and uploaded to the sensor repository. The user or other
programmers can use the device described by loading the device driver and
integrated it in their applications.
Figure 4 shows the process and data flow of the sample application described in
this appendix.
Figure 4. The flow chart for the DDL Sensor Driver Generator
References
[McCoy and Natis, 2003] McCoy, D. W. and Natis, Y. V. (2003). Service-Oriented
Architecture: Mainstream Straight Ahead. Technical report, Gartner Inc.
[Yang et al., 2008] Yang, H.I., Bose R., Helal, A., Xia J. and Chang, C. (2008).
Fault-resilient Pervasive Service Composition, Book Chapter in "Advanced
Intelligent Environments, Hagras, H., Eds., Springer Verlag. To appear 2008.