"Middleware Platforms for Heterogeneous
Distributed Systems"
Whitepaper of WG5: Services and Applications
Preface
This report was prepared by Working Group 5 Services and Applications from 2004 till
2007. It provides an overview of standard middleware platforms and middleware
platforms that focussed on mobile computing. This state-of-the-art provides the basis for
the discussion of open research issues in the area of heterogeneous distributed systems,
which concludes this report.
This report was authored by:
•
•
•
•
Dr. Guido Gehlen, RWTH Aachen (now Ericsson)
Dr. Götz Brasche, EMIC
Dipl. Inf. Michael Maaser, IHP,
Dr. Peter Langendörfer, IHP.
In addition the authors received substantial support from projects funded in the “Wireless
Internet Initiative” of the bmbf, i.e from the “wireless Internet: ad hoc” and the “wireless
Internet: zellular” project. We like to thank the coordinators of the initiative Prof. Dr.
Klaus David, University of Kassel and Prof. Dr. Rolf Kraemer, IHP, as well as Dr.
Henning Maass, Philips GmbH and Dr. Cornel Klein, Siemens AG as representatives of
the formerly mentioned projects.
Peter Langendörfer
Kontakt:
Dr. Peter Langendörfer
Wireless Communication Systems
IHP GmbH
15236 Frankfurt (Oder)
Telefon: 0335 5625 350
Telefax: 0335 5625 671
Email: langendoerfer@ihp-microelectronics.com
Table of Contents
1
Introduction ______________________________________________________ 4
1.1
Definition of Terms _____________________________________________________4
1.2
Support an application programmer would like to have _______________________5
2
Efforts in Standardization for Mobile Computing ________________________ 6
2.1
Standardization Overview________________________________________________6
2.2
Open Mobile Alliance (OMA) _____________________________________________9
2.3
Wireless World Research Forum (WWRF)_________________________________16
2.4
OSGi Alliance _________________________________________________________18
3
“General Purpose” Middleware Approaches ___________________________ 18
3.1
The .NET-Framework __________________________________________________18
3.2
J2EE ________________________________________________________________23
3.3
WebServices __________________________________________________________25
4
Upperware for Mobile Computing____________________________________ 32
4.1
PLASMA (Platform Supporting Mobile Applications) _______________________32
4.2
Mobile Web Services based Middleware (MobWebSam) _____________________40
4.3
Wireless Internet Cellular Platform _______________________________________47
5
Evaluation and future research ______________________________________ 53
5.1
Evaluation ____________________________________________________________53
5.2
Open Issues and research Directions ______________________________________55
6
References ______________________________________________________ 58
1 Introduction
Middleware platforms are a suitable means to hide the complexity of a distributed system
from an application developer. For wired networks middleware platforms are well
researched and widely used. The advent of mobile devices has raised a lot of new
questions in this area that have or have not been answered by now.
The aim of this report is to identify open research topics in this area. As a basis for
discussion of open issues we first provide a short overview of
•
Standardization efforts
•
Prominent de-facto-standard middleware platforms
•
Selected middleware platforms for mobile computing.
Before discussing open research topics we provide an evaluation of the discussed
platforms. In order to clarify which functionality is really needed to realize useful
applications and services we use a top down approach. We start from the view point of
the application programmer - “What would I like to have?” - to define essential
requirements. In addition we take the heterogeneity of upcoming systems into account,
i.e. we consider sensor nodes as part of the overall system.
In the rest of this section we define terms used in this document and already provide the
evaluation criteria from an application programmer’s point of view.
1.1
Definition of Terms
In this chapter we clarify the meaning of the terms we use in this document.
1.1.1 General Purpose Middleware and Upperware
General purpose middleware approaches aim to provide high level abstractions for the
development of distributed applications. So they naturally focus on rather general
features like network communication. What we call upperware is a middleware platform
that is intentionally developed to support a special kind of applications such as location
based services.
Almost all applications and services can be realized on top of general purpose
middleware platforms. But application domain specific platforms allow much faster
development of those services and applications, since they already provide some useful
abstractions such as location handling features. So, upperware provides much better
support for application programmers. The upperware itself might be realized on top of a
general purpose platform since a lot of useful abstractions are already provided, i.e. basic
communication means. In addition some properties of general purpose platforms can be
inherited if they are used to realize upperware.
From the perspective of service creation, providing and management, the inheritance of
features like load balancing, robustness, reliability etc. are of high importance. Other
issues such as privacy protection can be realized in a general way, but they need to be
adaptable to the needs of the application running on top of the upperware. Here
mechanisms are needed that allow configuring basic components to a special application.
The open issue is: which platform features have to be solved in a more general approach
and which have to be done just to support a special class of applications?
1.1.2 Application versus Service
The terms service and application are often used synonymously. The most appropriate
distinction of both is given in the following:
•
A service is a module/component that provides means to be used by more than
one application. So a location handling component of an upperware approach is
called a service. Services are regularly used by application programmers only.
•
An application is a “service” that is used by an end user, and which is not
supporting any other application or service. So, a “navigation service” is a special
kind of an application, and not a service.
Given the above definition of application and service the components of an upperware
might be called also services of a certain general purpose platform if they are realized on
top of this platform. In this document we generally use the terms application and service
with above defined meaning. They are used in the meaning of an application without
indication, if the correct meaning is evident from the context.
1.2
Application Programmer
Support
There are manifold ways to support an application programmer in the development of the
application with means and components provided by the middleware or upperware. A
number of such quite general means are enumerated in the following.
•
Tools to develop applications (support for adaptable applications, i.e. enabling of
disconnected operations)
•
Sophisticated service modules (location handling, access to sensor networks,
privacy protection mechanisms, means anticipate changes of the current situation,
etc.)
•
High level (abstracted) access to distributed services/objects
•
Possibility to subscribe to environmental events ( support context-awareness)
•
Access to any kind of information from other software components, devices,
environment
•
Interoperability support with other applications/devices
•
Dynamic Lifecycle Management of applications
•
Software deployment and management support
2 Efforts in Standardization for Mobile Computing
2.1 Standardization Overview
In the last few years several companies started the standardization of mobile middleware.
Now, there are a lot of forums which are proposing several competing and
complementing standards for mobile middleware services and protocols. Figure 1
illustrates the collaboration of some important consortia and forums related to mobile
middleware.
3GPP
SMIL
RFC3113
W3C
WS-I
Web Services
RFC3131
IETF
XML Signature
3GPP2
Web Services
RFC3975
XML Key
Encryption
IMS in OMA
Mobile Location Protocol
OMG
OMA
XML Signature
Web Service
Web Service
OASIS
Liberty Alliance
ID-WSF
Figure 1: Collaboration of standardization consortia
2.1.1 Protocol related standardization
The most standard protocols are provided by Internet Engineering Tasks Force
(IETF). The IETF began in January 1986 as a forum for technical coordination by
contractors for the then US Defense Advanced Research Projects Agency (DARPA),
working on the Advanced Research Projects Agency Network (ARPANET), US Defense
Data Network (DDN), and the Internet core gateway system. Since that time the IETF has
grown into a large open international community of network designers, operators,
vendors, and researchers concerned with the evolution of the Internet architecture and the
smooth operation of the Internet.
The work of IETF is divided into areas, each of which is further divided into working
groups (WGs) and Birds Of a Feathers (BOFs). Today there are more than 130 active
working groups in eight different areas.
The IETF collaborates with 3GPP, 3GPP2, and the OMA defined in RFCs. They are
exchanging knowledge about their expertise, since these boards are not competing.
The World Wide Web Consortium (W3C) has several activities that are relevant to
wireless world. These activities are related to ontologies of the mobile Web, including
especially the Web Services activity, Device Independence activity, and Semantic Web
activity. In the Web Services Activity, there are working groups for Web Services
Architecture, XML Protocol SOAP, WSDL, and Web Services Choreography. The
Device Independence working group has published several specifications on the
Composite Capability/Preference Profiles (CC/PP). In the Semantic Web Activity, there
are the Resource Description Framework (RDF) core working group and the Web
Ontology Working group ongoing.
The W3C shares ontologies, i.e. data formats, and architectures, with the other bodies like
the Web Service Architecture. Thus, the W3C plays a central role in the data definition
for middleware by utilizing the strengths of the Extensible Markup Language (XML).
Also, the definition of the XML Web Services is mostly controlled by the W3C.
Some aspects of service description are also included in OASIS, particularly in the UDDI
specification. Foundation of Intelligent Physical Agents (FIPA) has defined a
networking ontology specification that provides the means to describe properties of
connectivity. FIPA has also developed a device ontology specification.
The Third Generation Partnership Project (3GPP) and Third Generation Partnership
Project2 (3GPP2) are forums which in particularly deal with 3rd generation mobile
technology. They do not create new proposals, but select existing standards like a set of
Internet protocols.
2.1.2 Middleware related standardization effort
The Object Management Group (OMG) is the forum specifying CORBA and its
extensions. The OMG is doing less effort related to a mobile middleware specification.
Nevertheless, specifications of Wireless CORBA, Super Distributed Objects and Smart
Transducers are useful in wireless environments. The Model Driven Architecture (MDA)
is focused at the abstraction level of software development: modeling instead of
programming. The essence is code generation directly from the specification. This is
obviously useful for the service creation of mobile applications, since the heterogeneity
of the mobile environment motivates a higher abstract programming model.
The Open Mobile Alliance (OMA) specifies service enablers for the mobile world. The
core of OMA work is inherited from the forums (SyncML initiative, Wireless Village,
Location Interoperability Forum (LIF), Wireless Application Protocol (WAP), Forum
Mobile Wireless Internet Forum (MWIF) and Mobile Gaming Interoperability Forum
(MGIF) that merged into the OMA.
The WWRF is a pre-standardization forum addressing issues related to the 4G or Beyond
3G Systems. It provides and complete systems view from lower layers up to middleware
approaches.
2.1.3 Miscellaneous
The Java Community Process (JCP) has recently produced several Java Specification
Requests (JSRs) increasing the functionality of J2ME. Important for the definition of a
mobile middleware are the following JSRs cut into different middleware related issues
[1]:
•
Connectivity:
JSR80
(USB),
JSR82
(Bluetooth),
(WirelessMessaging), JSR257 (ContactlessCommunication)
JSR120/205
•
Protocols/Networking: JSR180 (SIP), JSR259 (AdHocNetworking), JSR272
(MobileBroadcastService)
•
Context-Awareness: JSR164 (SIMPLEPresence), JSR179 (Location), JSR186
(Presence), JSR246 (DeviceManagement), JSR256 (MobileSensor)
•
Collaboration:
JSR172
(Web
Services
Specification),
JSR248/249
(MobileServiceArchitecture),
JSR279
(ServiceConnection),
JSR281
(IMSServices)
•
Security: JSR177(Security&TrustServices)
The primary targets of Open Services Gateway Initiative (OSGi) specifications are
digital and analog set top boxes, service gateways, cable modems, consumer electronics,
PC s, industrial computers, cars and more. OSGi defines a runtime platform that enables
the management of software components on runtime and the collaboration of these
components. Currently, there are only Java implementation available, see chapter ….
The Liberty Alliance Project has the mission of serving as the premier open alliance for
federated network identity management and services. It ensures interoperability; supports
privacy and promotes adoption of its specifications, guidelines and best practices. Liberty
Alliance Version Specification Suite incorporated Federated Authentication to enable
single sign-on. The Liberty Alliance Version 2.0 specification suite is intended to support
a Web Service Framework, authorizing e.g. a Service Provider to access your location
information.
The Universal Plug and Play (UPnP) Forum [2] addresses the discovery and autoconfiguration of home network device services, like printer device service, or media
server/renderer service. UPnP collects existing protocols like HTTP, GENA, SSDP, and
SOAP in order to manage these home network services. Thus, the forum has relations to
the W3C and the IETF.
The Web Services Interoperability Organization (WS-I) promoting Web Services
Interoperability across platforms, operating systems and programming languages, Trusted
Computing Group (TCG) specifying security in the network layer, and Digital Living
Network Alliance (DLNA) ensuring interoperability of consumer electronics, personal
computers and mobile devices in the home.
Figure 2 shows specifications as well as the specification bodies, which are working on
WebService standards.
WS-Federation
WS-Management
Devices
Profile
WSDM
WS-I
Profiles
Infrastructure
and Profiles
WS-Metadata
Exchange
WS-Secure
Conversation
WS-Business
Activity
WS-Trust
WS-Atomic
Transaction
“WS-Security”
+ token profiles
WS-Reliability
WS-Reliable
Messaging
Metadata
Assurances
WS-Discovery
UDDI
WS-Coordination WS-CAF
WS-Security
Policy
Messaging
WS-Notification
WS-Resource
Framework
WS-Eventing
WS-Transfer
WS-Enumeration
WSDL
SOAP
WS-Addressing
MTOM
XML Schema
XML Signature
and Encryption
XML
SOAP / HTTP
WS-Policy
SOAP / UDP
Foundation
Legend
W3C
OASIS
in progress
in progress
Workshop &
Community Dev
DMTF
WS-I
Converging plan
(March 2006)
Obsolete or
Alternative
Formatiert: Beschriftung
Figure 2: WebService Specifications
2.2 Open Mobile Alliance
OMA was formed in 2002 and includes almost 300 companies. The member companies
represent the world’s leading mobile operators, device and network suppliers,
information technology companies, application developers and content providers.
OMA is designed to be a focal point of mobile services standardization work to assist the
creation of interoperable mobile services across countries, operators and mobile
terminals. The alliance drives the implementation of end-to-end mobile services
including an architectural framework, open standard interfaces and enablers.
The foundation of the Open Mobile Alliance was created by consolidating the Open
Mobile Architecture initiative and the WAP Forum. The LIF, SyncML, MMS
Interoperability Group (MMS-IOP), and Wireless Village, each focusing on mobile
service enabler standardization work have each signed a Memorandum of Understanding
to express their intent to consolidate with OMA. Additionally, OMA will be liaising with
various other organizations from the mobile and Internet industries to leverage existing
approved standards and specification.
An overview of the OMA Technology Framework is illustrated in the Figure 3.
External Functionality
Interface
Browsing
Billing Framework
SyncML Common
Specification
Device Management
Browser Protocol Stack
Data Synchronization
Wireless Public Key
Infrastructure
SynchML
WAP
Email Notification
OMA Standard Transcoding
Interface
Client Provisioning
On-Board Key Generation
User Agent Profile
DNS
W3C
Download
vObject Minimum
Interoperability Profile
Digital Rights Management
JAVATM
IETF
Multimedia Messaging
Service
IMS in OMA
Internet Mail
Consortium
XML Document Management
Online Certificate Status
Protocol Mobile Profile
Push to talk Over Cellular
3GPP
OMA Mobile Location Service
Presence Simple
3GPP2
WV
PARLAY
Instant Messaging and
Presence Service
WS-I
MGIF
Mobile Location Protocol
Web Services
Liberty
Games Services
Figure 3: OMA Technology Overview and Dependencies to Standardization forums
2.2.1 OMA Services
2.2.1.1 Client Provisioning
Provisioning is the process by which a WAP client is configured with a minimum of user
interaction. The term covers both over the air (OTA) provisioning and provisioning by
means of, e.g., SIM cards.
The WAP provisioning mechanism leverages the WAP technology whenever possible.
This includes the use of the WAP stack as well as mechanisms such as WAP Push. The
provisioning architecture attempts to generalize the mechanisms used by different
network types so that the network specific part is isolated to the bootstrap phase.
Table 1: OMA Enabler Release
List of Enablers
OMA Phase 1
OMA Billing Framework
V1.0
OMA Browsing
V2.1
V2.3
Browser Protocol Stack
V2.1
OMA Client Provisioning
V1.1
OMA Data Synchronization
V1.2
OMA Device Management
OMA Phase 2
V2.2
V1.1.2
V1.1.2
OMA Digital Rights Management
V2.0
OMA DNS
V1.0
OMA Download
V1.0
V1.0
OMA Email Notification
V1.0
OMA External Functionality Interface
OMA Games Services
V1.0
OMA Instant Messaging and Presence Service
IMS in OMA
V1.1 V1.2
V1.0
OMA Mobile Location Protocol
OMA Multimedia Messaging Service
V1.1 V1.2
On-Board KeyGeneration
V1.0
OMA Online Certificate Status Protocol Mobile V1.0
Profile
OMA Presence Simple
V1.0
OMA Push to talk Over Cellular
V1.0
OMA SyncML Common Specification
V1.1.2
OMA User Agent Profile
OMA vObject Minimum Interoperability Profile
V1.0
OMA Web Services
V1.0
OMA Wireless Public KeyInfrastructure
XDM -OMA
Version 1.0
XML
Document
V1.0
Management V1.0
2.2.1.2 OMA Email Notification
The primary objective of the E-Mail Notification specification is to enable e-mail servers
to invoke the e-mail client residing on the mobile device using the WAP Push
framework. For this purpose, the specification defines a single format for the e-mail
notification (EMN) in the form of a new content type that can be pushed to devices using
WAP Push. In addition, the specification defines the EMN User Agent that handles the
EMN and triggers the e-mail client for further action. The e-mail client may then
(depending on the implementation and user settings) retrieve the e-mail. This
specification will allow e-mail servers to send notifications in a standardized format
without the need to address various email client implementations.
2.2.1.3 OMA Data Synchronization
The Open Mobile Alliance Data Synchronization v1.1.2 specifications are based on the
SyncML Initiative’s v1.1.1 Data Synchronization specifications and make use of the
OMA SyncML Common v1.1.2 specifications as specified in the OMA SyncML
Common specifications Enabler Release Definition.
2. Standardization Overview
Prior to SyncML, data synchronization and device management had been based on a set
of different, proprietary protocols, each working only with a very limited number of
devices, systems and data types. These non-interoperable technologies have complicated
the tasks of users, manufacturers, service providers, and developers. Further, a
proliferation of different, proprietary data synchronization and device management
protocols have placed barriers to the extended use of mobile devices, which have
restricted data access and delivery and limit the mobility of the users.
SyncML is a specification that contains the following main components:
•
An XML-based representation protocol
•
A synchronization protocol and a device management protocol
•
Transport bindings for the protocol
Although the SyncML specification defines transport bindings that specify how to use a
particular transport to exchange messages and responses, the SyncML representation,
synchronization, and device management protocols are transports independent.
Each SyncML package is completely self-contained, and could in principle be carried by
any transport. The initial bindings are Hypertext Transport Protocol (HTTP), Wireless
Session Protocol (WSP) and Object Exchange (OBEX), but there is no reason why
SyncML could not be implemented using email or message queues, to list only two
alternatives. Because SyncML messages are self-contained, multiple transports may be
used without either the server or client devices having to be aware of the network
topology. Thus, a short-range OBEX connection could be used for local connectivity,
with the messages being passed on via HTTP to an Internet-hosted synchronization
server.
To reduce the data size, a binary coding of SyncML based on the WAP Forum’s Wireless
Binary XML (WBXML) is defined. Messages may also be passed in clear text if
required. In this and other ways SyncML addresses the bandwidth and resource
limitations imposed by mobile devices.
SyncML is both data type and data store independent. SyncML can carry any data type
that can be represented as a MIME object. To promote interoperability between different
implementations of SyncML, the specification includes the representation formats used
for common PIM data.
2.2.1.4 OMA Device Management
The OMA DM (based on SyncML DM) specification define the protocols and
mechanisms for how configuration parameters can be delivered to an OMA client from a
SyncML DM server that is part of the overall architecture. The mandatory functionality
defines a set of commands used in the DM protocol for various management procedures
as well as needed security level for management session. Mandatory management tree is
used as server interface to the device, which includes several mandatory management
objects that are providing basic device management functionality.
Device management is the generic term used for technology that allows third parties to
carry out the difficult procedures of configuring mobile devices on behalf of the end user
(customer). Third parties would typically be wireless operators, service providers or
corporate information management departments.
Through device management, an external party can remotely set parameters, conduct
troubleshooting servicing of terminals, install or upgrade software. In broad terms, device
management consists of three parts:
Protocol and mechanism: The protocol used between a management server and a
mobile device
Data model:
The data made available for remote manipulation, for
example browser and mail settings
Policy:
The policy decides who can manipulate particular parameter,
or update a particular object in the device
In a wireless environment, the crucial element for device management protocol is the
need to efficiently and effectively address the characteristics of mobile devices including
low bandwidth and high latency. The SyncML Initiative, based on its experience and
track record within basic synchronization, is well-prepared to meet the market and
technological challenges of device management.
2.2.1.5 OMA Download
OMA Download is based on two already existing and successful download services:
Basic HTTP Download and MIDlet Download. The purpose of OMA Download is to
provide a service similar to MIDlet Download. The difference between MIDlet
Download and OMA Download is that OMA Download is not designed for downloading
Java MIDlets, or any other specific media type. OMA Download is a general download
framework. The similarities between the two download services permit reuse of server
infrastructure and, in the device, to the extent possible, make the download of general
media objects not significantly different from the download of a new MIDlet.
Consistencyis a basis for a good user experience. OMA Download does not, however,
imitate MIDlet Download exactly in all technical details. But to the users downloading
media objects to the device and to the content providers publishing media objects, MIDlet
Download and OMA Download are very similar.
OMA Download can download any type of media object. The typical media object
targeted by OMA Download is downloaded and stored persistently in the device, in order
to personalize the device or enhance its functionality. Ring-tones, background images,
and Java MIDlets are media types used for this purpose.
2.2.1.6 OMA Instant Messaging and Presence Service
The Wireless Village Instant Messaging and Presence Service (IMPS) includes four
primary features:
Presence is the key enabling technology for IMPS. It includes client device availability
(myphone is on/off, in a call), user status (available, unavailable, in a meeting), location,
client device capabilities (voice, text, GPRS, multimedia) and searchable personal
statuses such as mood (happy, angry) and hobbies (football, fishing, computing, dancing).
Since presence information is personal, it is only made available according to the user’s
wishes -access control features put the control of the user presence information in the
users’ hands.
Instant Messaging (IM) is a familiar concept in both the mobile and desktop worlds.
Desktop IM clients, two-way SMS and two-way paging are all forms of Instant
Messaging. Wireless Village IM will enable interoperable mobile IM in concert with
other innovative features to provide an enhanced user experience.
Groups or chat area fun and familiar concept on the Internet. Both operators and endusers are able to create and manage groups. Users can invite their friends and family to
chat in group discussions. Operators can build common interest groups where end-users
can meet each other online.
Shared Content allows users and operators to setup their own storage area where they can
post pictures, music and other multimedia content while enabling the sharing with other
individuals and groups in an IM or chat session.
2.2.2 IP Multimedia Subsystem (IMS) in OMA
The IMS have been developed based on the widespread technical know-how of the
cellular industry and internet technology to enable the realization of real-time and non
real-time multimedia services in a mobile environment.
IMS provides a Session Initiation Protocol (SIP) based architecture that addresses the
needs of mobile operators for session management, security, mobility, Quality of Service
(QoS) and charging capabilities. The use of SIP allows the mobile communication
services to be combined with services in the Internet in a modular and extensible way.
Currently there exists a 3GPP/3GPP2 profile of SIP, but this is interoperable with any
other profile of SIP. The differences between the different profiles are only apparent
between the IMS network and the IMS mobile equipment. Other interfaces between the
IMS network and the service layer are based on a profile of SIP that contains no
3GPP/3GPP2 specific extensions. At the moment there are no other globally standardized
SIP architectures. SIP and other protocols used in IMS are specified in IETF, but in
general this document does not refer to IETF specifications directly, only to 3GPP/3GPP2
specifications.
2.2.3 OMA Web Services
The OMA Web Services Enabler (OWSER) provides specifications and guidelines for
Web Services technologies, implementations and deployments to integrate and
interoperate within the OMA architecture. It also ensures interoperability across servers
and terminals supporting web services protocols through the use of standardized
protocols.
The OWSER Version 1.0 consists of two specifications:
1. OWSER Core Specifications provides the basic Web Service infrastructure that is
needed to offer and consume Web Services in an OMA environment. This specification is
based on already well accepted standards as Service Oriented Architecture (SOA), HTTP,
SOAP, WSDL etc. see below in Figure 2.3
2. OWSER Network Identity Specifications provides the specifications of the components
needed to provide aspects of the Network Identity related capabilities of the OWSER
based on references to version 1.1 of the Liberty Alliance specifications.
The service-based architecture model makes it possible to put wrappers around large
applications that use unique data formats and proprietary interfaces – transforming them
into Web Services, which can support flexible business models and can be more easily
integrated with other systems.
2.3 Wireless World Research Forum (WWRF)
WWRF is a global organization founded 2001 which discuss a future technologies and
research directions related to mobile system. The members of this forum are global
network operators and service providers as well as the important manufacturers of mobile
systems. WWRF is structured in six working groups which discuss and research ideas
provided by vision committee.
Figure 4 : WWRF Architecture
Working Group2 (WG2) provides a "I-centric" middleware framework proposal based on
adapt-able personalized context-aware platform. The Figure 4 outlines the characteristics
of I-centric communication. User objects provides I-centric services that support three
main features: ambient awareness, personalization and adaptation.
2.3.1 Standardization Overview
The service platform for I-centric communications is responsible for shaping the
communication system, based on individual communication spaces, contexts,
preferences, and ambient information. Preferences will be provided by personalization,
whereas ambient information has to be provided by ambient awareness.
The IP-based communication subsystem is responsible for providing interactivity
between different objects in the communication spaces. It provides features such as call
control, session control, and mobility management. IP communication is seen as the
common denominator to harmonize heterogeneous network infrastructures.
The reference model introduces the concept of a generic service element that implements
common functionalities on all layers. Generic service elements such as service discovery
or environment monitoring provide cross-system knowledge of the context.
2.3.2 Personalization
Personalization seems to be a key factor for I-centric communication. This service feature
provides ability to incorporate the individual into I-centric service platform by managing
its preferences and providing them as user context to services.
User contexts are structured in environment, personal, task, social and spatio-temporal
context. Furthermore all user context information are described and stored in profiles
which use XML or UML to define different semantics of information stored within.
2.3.3 Ambient-Awareness
Ambient-Awareness in I-centric systems refers to the situational context in which an
individual user or actor is. The goal of ambient awareness is to acquire and utilize
information about the situation of an actor to enable services in an active context (i.e.,
personalize and adapt services to a certain situation at a certain momentum time.
In order to acquire ambient information, sensors or human-machine interfaces gather
information about actors (humans) and their environmental states. This also includes
appropriate models for structuring ambient-aware applications is also needed.
Standardization in the area of context-aware applications is mainly performed within
OMA, W3C, and Parlay, but focuses on specific aspects like location information (Parlay
and OMA),privacy and terminal capabilities W3C,or SyncML2.1.4(for synchronizing
information between devices).
2.3.4 Adaptability
Adaptation or Adaptability is ability of services and applications to change their behavior
when circumstances in the execution environment change.
Adaptation process requires frequent change of profile structure. In order to meet this
requirement it is necessary to imply an ontology-based service which enables
dynamically accessible semantic definition. The FIPA offers intelligent agents, which can
serve as basis for an ontology-based service[3].
The most problems related to modeling, representing and supporting of ontology can be
solved with already well adopted technologies provided by W3C such as RDF [4]
Semantic Web [5] Resource Description Framework Schema (RDFS),DAML+OIL
provided by the DARPA Agent Markup Language(DAML) [6] or OntologyTC [7, 3]
provided by FIPA
2.4 OSGi Alliance
The OSGi Alliance has been founded in 1999 in order to specify, create, advance, and
promote wide industry adoption of an open service delivery and management platform. It
offers a horizontal software integration platform that is mostly used within home, vehicle,
mobile and industry environments.
The OSGi Service Platform enables to remotely manage the life cycle of the software
components in the device. Software components can be installed, updated, or removed on
the fly without having to disrupt the operation of the device.
The core component of the OSGi specifications is the OSGi framework which provides a
standardized environment to applications (called bundles). The framework itself is
divided into an Execution Environment, Modules, Life Cycle Management, Service
Registry layer.
Currently, the OSGi Release 4 specification is available [8].
3
“General Purpose” Middleware Approaches
3.1 The .NET-Framework
The .NET Framework that is currently available in version 2.0 is an integral Windows
component that supports building and running the next generation of applications and
XML Web services. The .NET Framework is designed to fulfil the following objectives:
•
•
•
•
•
•
To provide a consistent object-oriented programming environment whether object
code is stored and executed locally, executed locally but Internet-distributed, or
executed remotely.
To provide a code-execution environment that minimizes software deployment
and versioning conflicts.
To provide a code-execution environment that promotes safe execution of code,
including code created by an unknown or semi-trusted third party.
To provide a code-execution environment that eliminates the performance
problems of scripted or interpreted environments.
To make the developer experience consistent across widely varying types of
applications, such as Windows-based applications and Web-based applications.
To build all communication on industry standards to ensure that code based on the
.NET Framework can integrate with any other code.
The .NET Framework can be hosted by unmanaged components that load the common
language runtime into their processes and initiate the execution of managed code, thereby
creating a software environment that can exploit both managed and unmanaged features.
The .NET Framework not only provides several runtime hosts, but also supports the
development of third-party runtime hosts. For example, ASP.NET hosts the runtime to
provide a scalable, server-side environment for managed code. ASP.NET works directly
with the runtime to enable ASP.NET applications and XML Web services, both of which
are discussed later in this topic. Internet Explorer is an example of an unmanaged
application that hosts the runtime (in the form of a MIME type extension). Using Internet
Explorer to host the runtime enables you to embed managed components or Windows
Forms controls in HTML documents. Hosting the runtime in this way makes managed
mobile code (similar to Microsoft® ActiveX® controls) possible, but with significant
improvements that only managed code can offer, such as semi-trusted execution and
isolated file storage.
With Windows Vista Microsoft will ship the .NET Framework 3.0 that was announced as
WinFX until now. As shown in Figure 5, the new version of the framework will comprise
the existing .NET Framework 2.0 components, including ASP.NET, WinForms,
ADO.NET, additional base class libraries and the CLR, as well as new developer-focused
innovative technologies, namely the Windows Presentation Foundation (WPF), Windows
Communication Foundation (WCF), Windows Workflow Foundation (WF) and the
newly christened Windows CardSpace (WCS) formerly known under the codename
“InfoCard.”
.NET Framework 3.0
Windows
Windows
Windows
Windows
Presentation
Communication
Workflow
CardSpace
Foundation
Foundation
Foundation
(WCS)
ADO
ASP
Windows
-
.NET
.NET
Forms
Common Language Runtime
Figure 5: Main Components of .NET Framework 3.0
3.1.1 Windows Communication Foundation
Windows Communication Foundation is the new service-oriented communications
infrastructure built on top of web services protocols. The advanced web service support
in Windows Communication Foundation provides interoperable secure, reliable, and
transacted messaging. The Windows Communication Foundation service-oriented
programming model is built on the .NET Framework and radically simplifies
development of connected systems. It unifies a broad array of distributed systems
capabilities in a composable, extensible architecture that supports multiple transports,
messaging patterns, encodings, network topologies, and hosting models. It is the next
version of several existing products: ASP.NET’s web methods (“ASMX”) and Microsoft
Web Services Enhancements for Microsoft .NET (WSE), .NET Remoting, Enterprise
Services, and System.Messaging.
3.1.2 Windows Presentation Foundation
Windows Presentation Foundation is Microsoft’s unified presentation subsystem for
Windows. It consists of a display engine and a set of managed classes that allow you to
create rich, visually-stunning applications. Windows Presentation Foundation also
introduces XAML, which allows you to use an XML-based model to declaratively
manipulate the Windows Presentation Foundation object model. The classes that make up
the API are largely part of the System.Windows namespace or its descendants.
3.1.3 Windows Workflow Foundation
Windows Workflow Foundation is a new workflow development platform built on the
.NET Framework.
Windows Workflow Foundation provides a programming model for developing and
executing a wide variety of stateful, long-running, persistent workflow applications.
Windows Workflow Foundation provides out-of-the-box workflow functionality that for
easily developing workflow-based applications such as document management,
commercial page flow, IT management, and various line-of-business applications.
Applications can load the workflow engine and plug a variety of runtime service
components into it. Windows Workflow Foundation is highly extensible, so you can
create your own custom components to address your particular business concerns.
Windows Workflow Foundation also offers ASP.NET support to make it easy for you to
build and execute workflows that run in the Internet Information Services (IIS)/ASP.NET
environment.
3.1.4 Windows CardSpace (formerly "InfoCard")
Windows CardSpace (formerly "InfoCard") is a Microsoft .NET Framework version 3.0
(formerly WinFX) component that provides the consistent user experience required by
the identity metasystem. It is specifically hardened against tampering and spoofing to
protect the end user's digital identities and maintain end-user control.
3.1.5 Common Language Runtime
The common language runtime is the foundation of the .NET Framework. You can think
of the runtime as an agent that manages code at execution time, providing core services
such as memory management, thread management, and remoting, while also enforcing
strict type safety and other forms of code accuracy that promote security and robustness.
In fact, the concept of code management is a fundamental principle of the runtime. Code
that targets the runtime is known as managed code, while code that does not target the
runtime is known as unmanaged code.
3.1.6 Class Library
The class library, the other main component of the .NET Framework, is a comprehensive,
object-oriented collection of reusable types that you can use to develop applications
ranging from traditional command-line or graphical user interface (GUI) applications to
applications based on the latest innovations provided by ASP.NET, such as Web Forms
and XML Web services.
3.1.6.1 Market penetration
The .NET Framework has been live since version 1.0 was released in January 2002. It has
achieved numerous adoption milestones:
• Compilers for over 20 programming languages are available for use with the
.NET Framework.
• Over 350 tools are available from third-party vendors to aid in .NET Framework
development, including approximately 250 add-ins for Visual Studio .NET, as
well as IDEs from Borland and Macromedia.
• Over 350 books have been published or soon will be published discussing
software development with the .NET Framework.
• Over 750 .NET Framework user groups exist worldwide.
• Millions of users every month visit the .NET Code Wise Community Web sites.
• Over one million developers are using Visual Studio .NET.
The multiple-language capability of the .NET Framework enables developers to use the
programming language that is most appropriate for a given task and to combine
languages within a single application. Components written in different languages can
consume functionality from each other transparently, without any extra work required
from the developer. Support for the .NET Framework has been announced for over 20
commercial and academic programming languages.
3.1.7 The Microsoft .NET Compact Framework
The Microsoft® .NET Compact Framework is a smart-device development framework
that brings the world of managed code and XML Web services to devices. The Compact
Framework is a rich subset of the .NET Framework, thus providing the same benefits as
the .NET Framework; but it is designed specifically for resource-constrained devices,
such as PDAs and smart mobile phones. The Compact Framework greatly simplifies the
process of creating and deploying applications to mobile devices while also allowing the
developer to take full advantage of the capabilities of the device.
Figure 6: .NET Compact Framework
The .NET Compact Framework, shown in Figure 6, provides the following key
functionalities:
• Runs programs that are independent of hardware and operating systems.
• Supports common network protocols, and connects seamlessly with XML Web
services.
• Provides developers with a model for targeting their applications and components
to either a wide range or specific category of devices.
• Provides benefits of design and optimization of limited system resources.
• Obtains optimal performance in generating native code using just-in-time (JIT)
compilation.
The .NET Compact Framework uses the same class library documentation as the full
.NET Framework. The .NET Compact Framework provides access for applications to use
the native operating system of a device. This integration supports native operating system
services and provides you with the capability to invoke native APIs selectively. It is
possible to run managed and native applications concurrently. The application domain
host, itself a native application, starts an instance of the common language runtime for
running managed code.
3.1.7.1 Market Penetration
Based on latest market research, .NET has gained a significant market share as
application development platform since its introduction the last 3 year age. In 2004, the
analysts concluded that .Net has achieved a market share of 30%, J2EE 40% with the
remaining 20% for legacy and CORBA. Depending on the industry the adoption rate
varies between 30% to 70%. While on overall average slightly more than 50% mention
.Net as primary choice, the telco industry is still in favour of J2EE with 60% to 40%.
However, as may be concluded from these short facts, both J2EE and .Net are long-term
winners in the market.
3.2 J2EE
3.2.1 Components
J2EE which is the Java 2 Enterprise Edition is based on the Java 2 programming
language and the respective runtime environment. It describes a software architecture for
transaction oriented execution of web based applications. It allows developing distributed
applications built out of components. The adherence to that architecture specification
enables such applications to scale well. J2EE components require a more specific
environment than just a Java 2 virtual machine but a J2EE application server. The
application server provides certain functionalities such as
• Deployment,
• Inter-component communication,
• Component life cycle management,
• Naming and directory services,
• Security and
• Transaction management.
These functionalities are provides through a number of APIs which extend the APIs of
the Java 2 Standard Edition and might be helpful for distributed web based applications.
Those APIs are
• Java Servlet API
• JMX Java Management API
• JMS Java Message Service
• JDBC Java Database Connectivity
• JTA Java Transaction API
• JavaMail
• A number of Java APIs for XML binding, processing and so on
This list is not exhaustive.
The probably most important components of the J2EE are the Enterprise Java Beans
(EJB). All EJBs require to be executed within an EJB container that is part of the
mentioned J2EE application server. The specification further requires the server to
provide a Web container which is the runtime environment for Servlets and Java Server
Pages (JSP). There are three types of EJBs:
• Entity Beans
• Session Beans
• Message Driven Beans (MDB).
Entity Beans represent persistent data objects. Appropriate descriptors belong to such
entity beans that allow a mapping to means of persistent storage such as relational
databases. The EJB container takes care of storing and updating EJBs in such databases
upon creation or change of the EJB as well it can recreate an EJB from its persistent
database representation.
Session Beans implement the actual business logic. They may be stateful or stateless.
Clients of such EJB based application access most likely those session beans either via
different types of remote procedure calls using XML, Java’s Remote Method Invocation
(RMI) or similar or through Servlets and JSPs, which are explained later. To fulfil their
task in the business logic the session beans use entity beans to store or retrieve their data
or other session beans as well.
The Message Driven Beans have some similarities to session beans as they implement
business logic as well but they are triggered by messages from the Java Message Service.
This allows asynchronous communication with the J2EE application. MDBs are available
since Version 1.4 of J2EE.
3.2.2 Servlets and JSPs
Java classes that are designed to receive requests from clients and to respond to those
appropriately within the application server are called Servlets. Although the Servlet
specification does not limit those to the underlying transport protocol HTTP, this one is
the most often used protocol. Servlets are the Java pendants to CGI scripts. As these
Servlets are regular Java classes they can access all the provided APIs of the J2SE and
J2EE. Hence those can make up an adequate user interface to the EJBs and their
implemented business logic. In case the business logic is well implemented in those EJBs
and not much of a logic is needed in the user interface representation pages JSPs should
be preferred over Servlets. JSPs are comparable to Microsoft’s Active Server Pages
(ASP) or PHP pages. They allow to design web pages with the user interface with
standard html and javascript and to further embed some Java code within special XML
tags. The web container transparently converts those into Servlets at first use and
compiles them at runtime. Afterwards they work just as the Servlets described before.
3.2.3 Architecture
Figure 7 displays an overall architecture view on the J2EE. A certain J2EE application
does not need to include all of the shown components. The picture shows different means
how client application in the form of applets or stand-alone Java application may interact
with web interfaces, EJB business logic or even the persistent storage itself. It is also
possible that users interact with the application through a web browser directly with the
web interface in form of JSPs or Servlets which in turn access the database or take
advantage of EJB business logic. Even an access to the Java enterprise application by
using Web-services and SOAP from other non Java programs is possible but not
displayed here.
Figure 7 J2EE architecture
3.3 WebServices
The following summary of the web services specifications is based on the description
made at the Microsoft MSDN Library [9]. Web services extend the WWW infrastructure
to provide the means for software to connect to other software applications. Applications
access Web services via ubiquitous Web protocols and data formats such as HTTP,
XML, and SOAP, with no need to worry about how each Web service is implemented.
Web services combine the best aspects of component-based development and the Web,
and are a cornerstone of the Microsoft .NET programming model. Web services
specifications compose together to provide interoperable protocols for Security, Reliable
Messaging, and Transactions in loosely coupled systems as shown in Figure 8. The
specifications build on top of the core XML and SOAP standards.
Figure 8: Web Services Specification Overview
3.3.1 Messaging Specifications
3.3.1.1 SOAP
SOAP (Simple Object Access Protocol) is a lightweight protocol for the exchange of
information in a decentralized, distributed environment. It is an XML-based protocol that
consists of three parts: an envelope that defines a framework for describing what is in a
message and how to process it, a set of encoding rules for expressing instances of
application-defined data types, and a convention for representing remote procedure calls
and responses. SOAP can potentially be used in combination with a variety of other
protocols; however, the only bindings defined in this document describe how to use
SOAP in combination with HTTP and the HTTP Extension Framework. SOAP 1.1 is the
current standard Web Service message protocol and SOAP 1.2 is the latest version of
SOAP from W3C that has been recently ratified as the emerging standard Web services
messaging protocol.
3.3.1.2 WS-Addressing
WS-Addressing provides transport-neutral mechanisms to address Web services and
messages. Specifically, this specification defines XML elements to identify Web service
endpoints and to secure end-to-end endpoint identification in messages. This
specification enables messaging systems to support message transmission in a transportneutral manner through networks that include processing nodes such as endpoint
managers, firewalls, and gateways.
3.3.1.3 MTOM
MTOM describes a mechanism for optimizing the transmission and/or wire format of a
SOAP message by selectively re-encoding portions of the message while still presenting
an XML Infoset to the SOAP application. MTOM also describes an Inclusion Mechanism
that operates in a binding-independent way, plus a specific binding for HTTP.
3.3.1.4 WS-Enumeration
WS-Enumeration enables an application to ask for items from a list of data that is held by
a Web service. In this way, WS-Enumeration is useful for reading event logs, message
queues, or other data collections.
3.3.1.5 WS-Eventing
WS-Eventing describes how to construct an event-oriented message exchange pattern
using WS-Addressing concepts, allowing Web services to act as event sources for
subscribers. It defines the operations required to manage subscriptions to event sources,
as well as how the actual event messages are constructed.
3.3.1.6 WS-Transfer
WS-Transfer defines how to invoke a simple set of familiar verbs (Get, Post, Put, and
Delete) using SOAP. An application protocol may be constructed to perform these
operations over resources.
3.3.2 WS Security
The Web Services Security (WS-Security) specifications define a comprehensive Web
service security model that supports, integrates, and unifies several popular security
models, mechanisms, and technologies (including both symmetric and public key
technologies) in a way that enables a variety of systems to securely interoperate in a
platform- and language-neutral manner. It describes scenarios that show how the
following specifications might be used together. This family of specifications delivers on
this roadmap.
3.3.2.1 WS-Security: SOAP Message Security
WS-Security describes enhancements to SOAP messaging to provide quality of
protection through message integrity, message confidentiality, and single message
authentication. WS-Security also provides a general-purpose, but extensible, mechanism
for associating security tokens with messages. Additionally, WS-Security describes how
to encode binary security tokens—specifically X.509 certificates and Kerberos tickets, as
well as how to include opaque encrypted keys.
3.3.2.2 WS-Security: UsernameToken Profile
This document describes the use of the UsernameToken with the WS-Security
specification.
3.3.2.3 WS-Security: X.509 Certificate Token Profile
This specification describes the use of the X.509 authentication framework with the WSSecurity specification.
3.3.2.4 WS-SecurityPolicy
WS-SecurityPolicy indicates the policy assertions for use with WS-Policy that apply to
WS-Security, WS-Trust, and WS-SecureConversation.
3.3.2.5 WS-Trust
WS-Trust defines extensions that build on WS-Security to request and issue security
tokens and to manage trust relationships.
3.3.2.6 WS-SecureConversation
WS-SecureConversation defines extensions that build on WS-Security to provide secure
communication. Specifically, we define mechanisms for establishing and sharing security
contexts, and deriving session keys from security contexts.
3.3.2.7 WS-Federation
WS-Federation defines mechanisms that are used to enable identity, attribute,
authentication, and authorization federation across different trust realms.
3.3.2.8 WS-Federation Active Requestor Profile
WS-Federation Active Requestor Profile defines how the cross trust realm identity,
authentication and authorization federation mechanisms defined in WS-Federation are
used by active requestors such as SOAP-enabled applications.
3.3.2.9 WS-Federation Passive Requestor Profile
WS-Federation Passive Requestor Profile describes how the cross trust realm identity,
authentication, and authorization federation mechanisms defined in WS-Federation can
be utilized used by passive requestors such as Web browsers to provide Identity Services.
Passive requestors of this profile are limited to the HTTP protocol.
3.3.2.10 WS-Security: Kerberos Binding
WS Security: Kerberos Binding describes how to use Web Services security
specifications with Kerberos.
3.3.2.11 Web Single Sign-On Interoperability Profile
Web Single Sign-On Interoperability Profile defines an interoperability profile of the
Web Single Sign-On Metadata Exchange Protocol that allows using either Liberty
Identity Federation or WS-Federation-based Identity Providers to interact with a service.
3.3.2.12 Web Single Sign-On Metadata Exchange Protocol
Web Single Sign-On Metadata Exchange Protocol defines how a service can query an
identity provider for metadata that describes the identity-processing protocol suites
supported by that provider.
3.3.3 Reliable Messaging Specifications
This WS-ReliableMessaging specification describes a protocol that allows messages to be
delivered reliably between distributed applications in the presence of software
component, system, or network failures. The protocol is described in this specification in
an independent manner, allowing it to be implemented using different network transport
technologies. To support interoperable Web services, a SOAP binding is defined within
this specification. The protocol defined in this specification depends upon other Web
services specifications for the identification of service endpoint addresses and policies.
How these are identified and retrieved are detailed within those specifications and are out
of scope for this document.
3.3.3.1 WS-ReliableMessaging
This specification describes a protocol that allows messages to be delivered reliably
between distributed applications in the presence of software component, system, or
network failures. The protocol is described in this specification in a transport-independent
manner allowing it to be implemented using different network transport technologies. To
support interoperable Web services, a SOAP binding is defined within this specification.
3.3.4 Transaction Specifications
This specification describes coordination types that are used with the extensible
coordination framework described in the WS-Coordination specification. It defines two
coordination types: Atomic Transaction (AT) and Business Activity (BA). Developers
can use either or both of these coordination types when building applications that require
consistent agreement on the outcome of distributed activities.
3.3.4.1 WS-Coordination
This specification describes an extensible framework for providing protocols that
coordinate the actions of distributed applications. The framework enables existing
transaction processing, workflow, and other systems for coordination to hide their
proprietary protocols and to operate in a heterogeneous environment. Additionally this
specification describes a definition of the structure of context and the requirements for
propagating context between cooperating services.
3.3.4.2 WS-AtomicTransaction
This specification provides the definition of the atomic transaction coordination type that
is to be used with the extensible coordination framework described in the WSCoordination specification. The specification defines three specific agreement
coordination protocols for the atomic transaction coordination type: completion, volatile
two-phase commit, and durable two-phase commit. Developers can use any or all of these
protocols when building applications that require consistent agreement on the outcome of
short-lived distributed activities that have all-or-nothing semantics.
3.3.4.3 WS-BusinessActivity
This specification provides the definition of the business activity coordination type that is
to be used with the extensible coordination framework described in the WS-Coordination
specification. The specification defines two specific agreement coordination protocols for
the business activity coordination type:
BusinessAgreementWithParticipantCompletion, and
BusinessAgreementWithCoordinatorCompletion.
Developers can use any or all of these protocols when building applications that require
consistent agreement on the outcome of long-running distributed activities.
3.3.5 Metadata Specifications
WSDL provides an extensible mechanism for defining the base messaging description
and metadata for a Web service. The Web Services Policy Framework provides a
general-purpose model and corresponding syntax to describe and communicate the
policies of a Web service. Web Services Metadata Exchange defines messages to retrieve
specific types of metadata associated with an endpoint.
3.3.5.1 WSDL
Web Services Description Language (WSDL) defines an XML-based grammar for
describing network services as a set of endpoints that accept messages containing either
document-oriented or procedure-oriented information. The operations and messages are
described abstractly, which are bound to a concrete network protocol and message format
to define an endpoint. Related concrete endpoints are combined into abstract endpoints
(services).
WSDL is extensible to allow the description of endpoints and their messages regardless
of what message formats or network protocols are being used to communicate. However,
this document only describes how to use WSDL in conjunction with SOAP 1.1, HTTP
GET/POST, and MIME.
3.3.5.2 WSDL 1.1 Binding Extension for SOAP 1.2
WSDL 1.1 Binding Extension for SOAP 1.2 describes how to indicate in a WSDL 1.1
document that a service uses SOAP 1.2.
3.3.5.3 WS-Policy
WS-Policy defines a base set of constructs that can be used and extended by other Web
services specifications to describe a broad range of service requirements, preferences, and
capabilities.
3.3.5.4 WS-PolicyAttachment
WS-PolicyAttachment specifies three specific attachment mechanisms for using policy
expressions with existing XML Web service technologies. Specifically, we define how to
associate policy expressions with WSDL type definitions and UDDI entities. We also
define how to associate implementation-specific policy with all or part of a WSDL
portType when exposed from a specific implementation.
3.3.5.5 WS-MetadataExchange
To bootstrap communication with a Web service, this specification defines requestresponse messages to retrieve arbitrary types of metadata. Metadata can be returned
inline or by reference.
3.3.5.6 WS-Discovery
This specification defines a multicast discovery protocol to locate services. By default,
probes are sent to a multicast group, and target services that match return a response
directly to the requestor. To scale to a large number of endpoints, the protocol defines the
multicast suppression behavior if a discovery proxy is available on the network. To
minimize the need for polling, target services that wish to be discovered send an
announcement when they join and leave the network.
3.3.6 XML Specifications
Web Services specifications are built upon the bedrock of the various XML specifications
described below.
3.3.6.1 Extensible Markup Language
Extensible Markup Language, abbreviated XML, describes a class of data objects called
XML documents and partially describes the behavior of computer programs that process
them.
3.3.6.2 XML namespaces
XML namespaces provide a simple method for qualifying element and attribute names
used in Extensible Markup Language (XML) documents by associating them with
namespaces identified by URI references.
3.3.6.3 XML Information Set
This specification defines an abstract data set called the XML Information Set (Infoset).
Its purpose is to provide a consistent set of definitions for use in other specifications that
need to refer to the information in a well-formed XML document.
4 Upperware for Mobile Computing
4.1 PLASMA (Platform Supporting Mobile Applications)
The major design goals of PLASMA [10] are adaptability, scalability and openness.
PLASMA should be equally suitable for small hot spots such as shopping malls or train
stations as well as worldwide deployment. An example for the latter case could be if a
certain airline wants to equip all its lounges with PLASMA.
PLASMA consists of a set of platform components called engines (which provide the
basic functionality such as managing the location information of mobile clients etc.) and
a set of so-called PLASMA servers (which provide management services inside the
infrastructure).
In order to achieve scalability and adaptability we developed an architecture that allows
to replicate and distribute PLASMA servers over several server machines or to combine
them on a single server machine, respectively. In order to achieve openness we realized a
so-called mediator, which is used to communicate with clients that do not run PLASMA.
The PLASMA architecture, its servers and management are described in the following
subsections. The basic mechanisms needed to implement location-aware services are
provided by seven platform components that are presented in sub-section 4.1.3.
4.1.1 Infrastructure
PLASMA may be deployed in a hierarchical structure and it allows replicating the
infrastructure servers. The tree structure allows to split geographical regions with high
density of mobile devices into several new geographical regions, so that the load per
infrastructure node is reduced. On one hand this approach provides simple means to do
efficient load sharing. On the other hand, in a world wide deployment scenario a single
tree may become a bottleneck, since its root has to keep track of up to worldwide 109 to
1012 objects. In order to avoid this drawback, PLASMA may be deployed with several
independent trees. With this approach it would be impossible for two mobile devices to
find each other if they are located in different trees. In order to support world wide search
facilities we introduced the object register which stores for each object the information in
which tree it is currently active. This concept is very similar to those of the home agent of
mobile IP or the home location register of GSM.
PLASMA allows to introduce several hierarchical levels between the root of the tree and
its leaves. It is even possible to have no intermediate levels. This approach was also
introduced in order to allow easy clustering of geographical regions when load sharing
should be used. Our experiences show however that flat structures should be preferred at
least in local deployments. To summarize, PLASMA provides a whole set of parameters
that can be used to achieve good scalability. One example for a hierarchical structure is
shown in Figure 9
Figure 9: Hierarchical structure of PLASMA's infrastructure
The platform servers in the lowest hierarchy level (i.e. level 0 in 6.1) are also referred to
as Leaf Servers. They directly communicate with mobile clients. Each of these platform
servers is responsible for a particular geographical region. So, clients inside a certain
geographical region communicate with the server that is responsible for that region. The
geographical regions can have any shape, but they must be disjunctive and they must
completely cover the area in which the platform services should be available. The size of
the geographical regions can be adapted in such a way that the entire workload is
homogeneously distributed between all platform servers. For hot spots such as city
centers, convention domes etc. with many mobile users, small geographical regions are
suitable, whereas for rural areas large regions are adequate.
A platform server in a higher hierarchy level is called Domain Server. It is the
communication partner for a certain number of servers in the next lower level. Thus, the
geographical region of a server in level 1 is the combination of the geographical regions
of its child nodes in level 0. This concept spans a pyramid of platform servers, each
responsible for one geographical region and child node servers, respectively.
The top of this pyramid is referred to as Root Server. The entire platform can consist of
more than one root server, i.e. it is built up out of more than one hierarchical structure.
The number of root servers as well as the number of hierarchy levels in a pyramid, the
number of platform servers in a level, and the size of geographical regions can be adapted
according to the requirements of a particular deployment scenario.
In order to store user-specific data that is relevant to the middleware, profiles are
assigned to each mobile user. A profile contains information on the user's terminal as
well as privacy-related settings, such as a flag indicating whether or not the user's
position is to be exposed to other users. More than that, possibly defined auras and events
are all stored in the profile. These user profiles are managed by so-called Profile Servers.
Each profile is stored persistently at exactly one Profile Server making this server the
authoritative original source for that profile. Of course, a single Profile Server may store
several, even thousands of profiles. One of the tasks of PLASMA is to provide multiple
copies of the same profile at different locations (i. e. to different platform servers) in a
consistent way.
Deployment scenarios may use several profile servers or even several PLASMA trees. In
order to support an easy and efficient way to identify the correct profile server for a given
mobile client, we use another platform entity called Object Register. It forms, in some
sense, the administrative top of the platform. The object register provides a mapping of
an object's id to the address of the object's profile server. Moreover, also the reference of
the current root server can be requested from the object register. This data is important
when searching for the location of a certain object. The "correct" object register can be
identified from only knowing an object's id, as the contact address of the register is part
of each object's id. Thus the object register can be used to connect several PLASMA
trees.
Since our platform is based on Java, any client which wants to use the service offered by
the platform should have a Java virtual machine running on it. Very thin terminals like
mobile phones or other devices, which do not have a Java virtual machine, cannot use the
service. The need to use Java as programming language and the need to run a JVM on the
mobile device significantly reduces the number of potential applications and PLASMA
clients, respectively. In order to enlarge the number of potential clients and applications,
we decided to introduce a so-called Mediator which realizes a gateway between the Javaand the non-Java world. We selected SOAP as communication protocol between the Java
and the non-Java world. The benefit of this approach is that SOAP can be used to realize
remote procedure calls between any two programming languages. Therefore, we need
only one kind of mediator instead of one per programming language. The major
PLASMA APIs are described in WSDL, so that interfaces for different programming
languages can be generated automatically. Basically PLASMA can be used as a huge
WebService that is invoked by sending SOAP requests to the Mediator. The latter is
really implemented as a web service, which exposes the PLASMA API to the non-java
world. It translates SOAP calls into the PLASMA internal protocol. It is connecting to
and interacting with PLASMA servers like a single JAVA-Client (see Figure 10).
Figure 10: For the support of non-Java clients, the mediator translates the protocol
for the platform communication into SOAP calls and vice versa. PLASMA events
are sent as UDP packets to the non-Java clients.
The major part of the methods provided by the mediator work in a synchronous way, i.e.
the calling instance on the mobile blocks until the result is received. The benefit of this
approach is that no resources are wasted for polling in order to check whether the result is
delivered or not. But this concept does not work for asynchronous scenarios in which
PLASMA sends a message to the mobile client, e.g. if one of the events defined by the
client has become true. On a Java client running the PLASMA proxies, PLASMA
directly calls internal functions of the client. This is not possible with a non-Java Client
which is realized as a WebService Client. One possible solution is to run a SOAP
listener and parser on a non-Java Client in order to be capable to receive messages from
the infrastructure. But this would increase the load on the mobile client drastically. In
order to reduce this overhead we decided to use non-SOAP solution for the messages that
are sent from the infrastructure to the client. The major part of these messages, e.g.
information about a landmark, is useful only for a very short time, i.e. the loss of such a
message does not cause much harm. Thus, a reliable transport protocol like TCP is not
really needed. Therefore we decided to minimize the communication overhead and to use
UDP to send events from PLASMA via the mediator to the client. If the client has
registered for PLASMA events, it opens an UDP socket and listens on a predefined port.
The event can then be handled by the application running on the mobile client in a
suitable way.
Since PLASMA provides a WSDL API, application programmers are not bound to any
programming language or operating system running on a mobile client.
4.1.2 Platform Management
PLASMA allows to configure which of the above mentioned servers are clustered
together on a single machine as well as on which machine they are installed. Thus, it is
possible to run all servers on a single machine (see Figure 11a) in order to provide
PLASMA functionality in a small hot spot. If a large area is to be covered PLASMA,
servers may be structured as a tree and the PLASMA servers may be distributed over the
whole tree. This allows solutions such as a single object register for two or more
physically separated hot spots (see Figure 11b). This flexibility opens up a new problem.
Figure 11: Two sample deployment configurations of the PLASMA platform; a)
single server b) hierarchically structured
In order to provide the platform functions in a correct and consistent way, the platform
servers need to have certain items of knowledge about the infrastructure:
• For searching mobile clients as well as for the hand-over mechanism the platform
server needs to know all its neighbours, that is, leaf servers with geographical
regions that are adjacent to its own region.
• For the search mechanism it needs to know the platform server in the next
hierarchy level, which is responsible for the domain to which the platform server
itself belongs.
• In order to create a new object, it needs to know at least one object register.
• To store and retrieve object profiles, it needs to know at least one profile server.
Since the PLASMA infrastructure can be deployed in many different configurations the
above mentioned information has to be provided dynamically, i.e. the platform servers
need a way to retrieve all necessary information independent of the actual setting.
Therefore we decided use Jini look up services to provide and maintain this information.
For each domain one logical lookup service exists. Each lookup service contains the
following information:
• all PLASMA servers in the domain of the Jini look up service, including the
geographical region belonging to each server.
• The addresses of object registers available in this domain.
• The addresses of data bases available in this domain.
• Whether the domain is a search domain or not.
• How to contact a lookup service of the next hierarchy level upwards.
• How to contact a lookup service of the next hierarchy level downwards, which is
responsible for a particular domain.
So, every platform server can access the information necessary to contact other PLASMA
servers, such as profile servers from the lookup services. The lookup service in the top
hierarchy knows all root servers with the corresponding lookup services in the domains
directly below the root servers.
An automatic reconfiguration of PLASMA is supported by the fact that all platform
servers register appropriate lookup services, requesting to be notified if changes in the
platform structure occur.
4.1.3 Platform Components
In order to provide useful location-aware applications it is necessary that the current
position of a user can be queried by the application. This means a suitable positioning
system has to be part of the infrastructure and must be able to submit its information to
PLASMA. This information has to be processed in a suitable manner. In addition,
potential users require the possibility to define areas of interest (which we call aura) as
well as the means to define events (such as “please notify me when a color printer is less
than 5m away”). In order to support large-scale deployment, a handover mechanism is
needed. Thus, the platform consists of the following components:
•
sighting proxy
•
database engine
•
event engine
•
auras & objects engine
•
communication engine
•
lookup engine
•
profile engine
•
hand-over engine
•
security engine and
•
privacy engine
All these components are used on the infrastructure side. Java clients only need to
implement the communication engine as well as proxies of the Location Management
API, Look-up service API, and Profile Database API. Non-java clients do not need
platform-specific components at all. The capability to process SOAP requests is
sufficient. Thus, applications can use well-defined API’s provided by the components of
the platform.
Figure 12 shows all components of the platform that are realized in the infrastructure.
Location Handling Content Adaptation
Micro
Payment
Event Auras &
Engine Objects
Position DB
Privacy
To
Person
Profile Handling
To
Device
Events
OB-ID
Profile DB
Settings DB
Priv. Neg. Prot. Contract Eval.
Security Authentication/Autorization.
Communication Engine
Sightings Proxy
IR Beacons
GPS
Figure 12: PLASMA components and their structure inside a platform server
•
Sighting proxy : The sighting proxy receives the position information of registered
clients. It converts the position information and the client ID provided by the
sighting system into geographical coordinates and object ID that are required by
the platform. Then sighting information is forwarded to the database engine. The
position information may be delivered by any positioning system e.g. by GPS in
outdoor scenarios or by IR beacons in indoor scenarios. The sighting proxy
resides only on platform servers of the lowest hierarchy level, since only these
servers communicate with mobile clients and receive sightings from an
underlying sighting system.
•
The database engine (DB) stores the sighting information and provides it to other
platform components and to the application upon request. More than this,
significant sightings, e.g. an object's first sighting ever or a sighting that is
relevant for further event processing, are automatically forwarded to the event
engine. This filtering dramatically reduces the communication effort inside a
platform unit.
•
The auras & objects engine handles an aura, which is the spatial scope of
interest for an object. For instance, a user can inquire all objects that are currently
located in a particular aura, or all objects which have auras overlapping with a
particular aura. To perform the queries of users, the engine for auras and objects
uses rendering algorithms. Moreover, with the concepts of auras and objects,
events such as "object A entered aura X" can be defined. Thus, the purpose of the
auras & objects engine is to calculate which objects are located in which aura and
to determine which auras intersect each other.
•
The event engine is responsible for interpreting and monitoring user-specified
events. It has to process all sighting notifications coming from the DB engine in
order to observe and possibly fire user events. For example, to find out, if two
persons are near each other, it deploys the auras & objects engine which is able to
determine if one position is within a certain aura of another one. Our event
definition language as well as the event evaluation process is explained in detail in
the selected components section.
•
The communication engine handles target references, which are used for the
communication between clients and platform servers and for platform-internal
communication. In fact, a target reference is made up of the machine's IP address
and the number of the port used by PLASMA. The communication engine is also
responsible for an initial communication establishment for newly appearing
devices, e.g. when powered on.
•
Look up engine: The platform supports queries on the Jini lookup system. Users
can register their own services with this lookup system or can just use services
offered by other devices. Since the registration of services with a Jini lookup
service is done via the platform, locations and auras can be defined for the
services. The platform search mechanisms can be used to find services. The
lookup engine at the server side handles the queries and sends appropriate objects
to the client. Moreover, the lookup engine also supports the platform
management, e.g. by finding different platform components such as next
neighbour platform servers, object register, profile server etc. to organize the
communication within the platform.
•
The profile engine is responsible for the support of personalization. Each mobile
terminal can provide a profile to the platform that contains some common,
platform-related properties of the terminal and the user. For example, capabilities
of the terminal, as well as user preferences such as security-related information
could be specified in this profile. This profile is stored in the profile database. The
primary copy of the profile is managed on the profile server responsible for a
certain object. In order to speed up applications, local copies of profiles are
needed. Our replication and consistency model is equivalent to the one used by
the Andrew file system and denoted as call back promise, i.e. each owner of a
copy is informed as soon as a write operation is executed on the original profile.
•
Hand-over engine: When a mobile object leaves a geographical region and enters
a new one, the hand-over engine transfers all object related data (communication
references, auras, profile, registered events) from the old leaf server to the new
one.
•
The security & privacy engine provides means to protect user data against misuse.
Its negotiation mechanisms enable the mobile device to select a cipher mechanism
for the communication with the infrastructure. The selected algorithms are used to
encrypt the messaged exchanged with the infrastructure as well as to provide
digital signatures. Thus, eavesdropping can be avoided. Data stored in the
infrastructure are protected via access rights that can be changed only by the user
herself. That is, she can authorize selected services or users to access her data, e.g.
to allow these to localize her.
4.2 Mobile
Web
(MobWebSam)
Services
based
Middleware
The Web Service based middleware architecture [11] is shown in Figure 13. The
middleware is bordered upwards by the application and downwards by communication
layers. The middleware is capable of coupling either to a session layer protocol, like
HTTP, BEEP, or WSP, or to a transport layer protocol, like TCP or UDP.
The middleware itself is structured in a protocol part and a service part. The protocol part
is based on SOAP, including the bindings to the underlying protocols and security
mechanisms. The service part of the middleware is once again divided into a static part
within the U shaped block and a dynamic part. The static part acts for base middleware
functions, like Service Publishing/Discovery and Object Monitoring and Eventing. The
Monitor Service, Notification Service and the Rule Engine are described in section 4.2.3.
The dynamic part depends on the application and adapts on compile or runtime.
In addition, all elements in the service part of the middleware can be distinguished in
services and service proxies. As mentioned before, the service proxy is a representative
of a remote service and offers the application an interface to this remote service.
The realization of the middleware has been done for Java enabled mobile devices,
compliant to the J2ME standardization. The SOAP part is based on the Open Source
libraries kSOAP and kXML and has been extended by additional SOAP Bindings to
alternative underlying protocols and by server capabilities.
The following subsections will present each of this middleware parts in detail. First,
SOAP and our extensions in respect of a mobile environment will be explained. The next
two subsections describe the static middleware parts, the Publishing/Discovery and the
Rule based data monitor services. The last subsection will introduce the use of these
middleware functionalities to build context aware applications.
4.2.1 SOAP and Bindings
Within the Web Service framework the services and service proxies communicate via the
Simple Object Access Protocol (SOAP). It is based upon messages encoded in XML,
called SOAP Envelopes, transmitted by arbitrary transport protocols. The SOAP
Envelope is divided in an optional SOAP Header and the mandatory SOAP Body. The
body contains the message to be transmitted, the header contains additional information
regarding this message, as e.g. message ID’s for the session management or security
related information.
As mentioned, SOAP can be coupled to an arbitrary protocol by using a protocol specific
SOAP Binding. The most common protocol used by SOAP is Hypertext Transport
Protocol (HTTP), since it is mostly used in the Internet and easily allows Remote
Procedure Calls (RPCs). But HTTP on top of TCP has a bad performance in mobile
communication systems. Thus, this middleware provides a set of alternative SOAP
Bindings, like a binding to Wireless Session Protocol (WSP), User Datagram Protocol
(UDP) or BEEP. The WSP binding for SOAP has the advantage, that the protocols are
adapted to the mobile communication system. The WSP header is more lightweight
compared to HTTP. In addition, the XML content can be encoded binary. Existing
Internet Web Services which are bound to HTTP can be accessed via WAP using a WAP
gateway.
The middleware realization is based on kSOAP, which solely provides a HTTP client
binding. Thus, kSOAP enables by default only Web Service access, but no Web Service
provision. We extend the middleware by a lightweight Web and SOAP Server. By using
this lightweight server, the middleware can publish arbitrary service methods and make
these services available via HTTP. In addition, static web content, like HTML pages
could be accessed on the mobile device. The HTTP Server binding for SOAP runs on
MIDP1.0/2.0, Personal Java, and on any arbitrary standard Java platform. Service classes
which should be published by the server have to implement one interface and have to
declare their exposed methods and objects to the server.
An additional extension which is not included in kSOAP is the SOAP Security. The
package provides functions to encrypt or sign SOAP messages or only parts of these
messages. SOAP Security is a building block of the Web Service Security specification
and is based on XML Encryption and XML Signature. The security implementation will
be presented in a further paper.
4.2.2 Service Publishing, Discovery and Integration
We have to differentiate two kind of services. Unique services and well defined plural
services. The first kind of services are specialized services provided by one unique
service provider, like e.g. the amazon web or google service.
Application
Monitor Proxy
Notification Service
Notification
Proxy
Monitor
Service
Service
Rule
Engine
Service
Service Proxy
Mobile Web Service
based Middleware
Service Proxy
Service
Publishing
Dynamic Service
Publishing
Service
Discovery
Dynamic Service
Discovery
At compile time
SOAP
SOAPSecurity
HTTPBinding
BEEPBinding
Session Layer
Transport Layer
Network Layer
HTTP
BEEP
TCP
TCPBinding
WSPBinding
UDPBinding
WSP
UDP
IP
Figure 13: Mobile Web Services based Middleware Architecture
The second ones are specified services, which can be implemented by any arbitrary
service provider, like e.g. the Domain Name Service (DNS) or UPnP services.
The unique services and service proxies are published and integrated on compile time, ,
see Figure 14. It makes in general no sense to do these tasks at runtime, since the
application on top of the services and service proxies is coupled with them. Thus, the
application developer has to do the publishing and integration process for unique
services. From the service source code, written in an arbitrary programming language, a
WSDL description is generated and published. A second application developer, which
wants to use this service, automatically generates source code for his target platform from
the WSDL description.
Figure 14 : Publication and Integration of Web Services using the WSDL
description
In contrast, well defined services can be published and integrated on runtime, assumed
that the middleware supports these services and that the application can use or provide
them. Upon entering a new service environment with a device, its services are published
and remote services, which are of interest, will be integrated in the middleware. This
dynamic service publishing and discovery is e.g. applied in UPnP. Currently, it will be
discussed to align UPnP version 2 with the web service technologies. Thus, our
middleware will support in future both, Web Services and UPnP2 services.
4.2.3 Rule Based Data Monitoring
Context aware applications are often distributed, since the context information provider
are distributed themselves. We will consider without loss of generality one mobile
context provider device and one backend system with the main application logic as
depicted in Figure 13. The context provider will be generalized as a set of data, updated
by persons or sensors. Thus, not only context aware applications are supported by this
application class, but also applications which provide data sets on the mobile device in
general.
There are three different high level communication relations between the mobile device
and the backend system, see Figure 15 a). The first possibility is to periodically forward
the relevant data to the backend system. This is simple to realize, but data will be
transmitted even if the data is not of interest for the backend application.
The second possibility is to access the data on demand from the backend system, see
Figure 15b). The advantage is that the backend system can decide at which time the
mobile data is needed, but it can only be realized if the mobile device has server
capabilities and is addressable from the Internet. As mentioned in a previous section, the
middleware supports HTTP server capabilities and consequently supports also this
second possibility. However, this solution is only advantageous, if the backend
application knows the point of time the mobile data is needed. In case that the decision
whether the data is relevant or not depends on the mobile data itself, this solution as well
as the first one are not sufficient.
The third possibility, in Figure 15 c), breaks this disadvantage by shifting the logic. Thus,
the mobile device can filter the data before forwarding it to the backend system
(notification). Before, a self-defined rule composed by the backend system has to set up
the data filter. This is done by submitting a subscription to the mobile device containing
this rule.
Figure 15: High level communication possibilities for context awareness: a)
Periodically forwarding of the context data b) Periodically access of the context data
c) Rule based object monitoring
The high level communications are divided into two phases separated in time, see Figure
16. In the first phase the backend system will subscribe with a rule to the mobile device.
The rule is related to the data published by the mobile device and defines which data
changes cause a notification of the backend system. The second phase is the notification
itself. A notification, specified in the rule, is send from the mobile device to the backend
if the rule is fulfilled.
Figure 16: Subscription to the rule based monitoring and notification
To realize this concept, a rule parser, a rule evaluator, the subscribe and un-subscribe
methods, and a notifier are necessary. The subscribe and un-subscribe methods will add
or delete a new rule on the mobile device application. The rule parser will transform the
serialized rule, in our case a specialization of the XML, into a processable data object,
which can be evaluated.
The implementation of this functionality is based on the Service Oriented Architecture
(SOA). The mobile node offers and publishes a rule based object monitor service with
two public methods Subscribe(Rule) and Un-subscribe(RuleID). The subscription method
contains the Rule and starts at the mobile node the evaluation of this rule. The un-
subscription method stops the evaluation of the rule with the corresponding RuleID, see
Figure 17. The RuleID is assigned by the mobile node after verifying the rule and is
returned back to the backend system.
Figure 17: Architecture of the rule based monitoring middleware part
After the subscription, see (1) in Figure 17, each incoming rule is parsed and verified, (2).
If the rule syntax is valid, the subscribe method returns a acknowledgment message to the
backend containing a unique Rule ID, else an error message. A valid rule will be saved
into an list of rules, (3). In a parallel process this list is sequently evaluated by a
RuleEvaluator, (4). Each time the rule applies, a notification service of the backend
system will be invoked with the event as parameter, (7), by invoking the Notification
Proxy, (6).
The rules are defined in an platform independent and XML based rule language, named
RuleML (see subsection IIIC.1). The RuleParser generates in the first step a Document
Object Model (DOM) of the XML rule. This DOM tree can be recursively processed,
thus, arbitrary hierarchically structured rules can be evaluated. The RuleEvaluator
accesses each DOM rule tree, beginning with the root element. Within the condition of
the rule, two different nodes occur. Relation nodes (AND, OR) with two or more child
nodes and the leave nodes without child nodes, containing the atom conditions (x>y, ...)
1) The Rule Meta Language (RuleML): RuleML is a XML based meta language, which
defines rules in a platform independent syntax. The RuleML hierarchy of general rules
branches into the two direct categories of reaction rules and transformation rules. On the
next level, transformation rules are specialized to the subcategory of derivation rules.
Then, derivation rules have further subcategories, namely facts and queries. Finally,
queries are specialized to integrity constraints.
Within this article we solely consider derivation rules. They state a sort of if then
statements building a filter for the logic component on the mobile device.
The root element of each rule is the <rulebase> element. It can contain attributes such as
Namespaces. Among others, child elements like <Query>, <Fact> or <Imp> are possible.
As mentioned before, the main focus in this work lies on implication rules (<Imp>) and
their structure in order to come up with the demands. The <Imp> element consists of a
<head> and a <body> element. Inside the <head> element the implication is stated e.g.
send an event to this URL. The condition is nested in the <body> element, which is
processed recursively. Many conditions are possible, where each condition is declared in
an <Atom> element. These are coupled by <And> or <Or> relations, resulting in a
complex tree structure. See in the listing 1 an example rule description in Rule ML and
the corresponding document object model tree in Figure 18.
<Imp>
<head>
<Atom>
<opr><Rel>send</Rel></opr>
<Ind>Event</Ind>
</Atom>
<Atom>
<opr><Rel>URL</Rel></opr>
<Ind>137.226.4.133:8080</Ind>
</Atom>
</head>
<body>
<And>
<Atom>
<opr><Rel>lower</Rel></opr>
<Var>Lat</Var>
<Ind>5040.0000</Ind>
</Atom>
......
<Atom>
<opr><Rel>greater</Rel></opr>
<Var>Lon</Var>
<Ind>10020.0000</Ind>
</Atom>
</And>
</body>
</Imp>
Listing 1: Example of Rule ML description
Figure 18: RuleML Document Object Model tree
4.3 Wireless Internet Cellular Platform
4.3.1 Architecture
The major objective of our approach [12] was to ensure easy adaptability of the whole
platform. I.e. we wanted to provide an architecture that allows to tailor-made an
application specific middleware, while also providing means to adapt to client device
characteristics.
Support for application domain specific platform adaptation was achieved by clustering
potential platform components into the following “classes”:
•
Management
•
Basic components
•
Distributable components
The management layer comprises all components that are essential to realize an adaptable
platform, i.e. it is responsible to ensure component life cycle management, to provide
service discovery means as well as security support. These means allow to search for new
components, check their integrity and to start the components on the currently used
device. So the management components represent the minimal configuration of the
platform that has to be installed an each device.
Basic components are components that have to be executed on the currently used device
whenever they are used. In contrast to this distributable components may be executed
locally or remotely. They may use basic components to provide their functionality, but
they must not. In other words distributed components may reside directly on top of the
management components. Figure 19 shows the structure of our architectural design, and
displays some components within the appropriate component classes.
Figure 19: Structure of the mobile middleware architecture
Figure 20: Abstract model and component view of the mobile middleware
architecture
Additional flexibility was gained by allowing platform components to be specified in two
roles namely as service provider and service user components. Figure 21 depicts two
devices which are running components in different roles.
All components, independent of their role have, to provide APIs needed for proper life
cycle management i.e. APIs to start, to stop and to unload components.
Figure 21: Physical view showing the distribution of components
Platform internal Communication: Due to the flexible structure of our architecture
local and remote method invocations have to be supported. In addition there may be
components which are implemented in different programming languages. In order to
allow easy “plug and play” of components differences in the communication flow show
be hidden. In order to provide efficient communication especially on the mobile devices
local calls should be used whenever possible. Therefore we introduced a new abstraction
“layer”, which we call intelligent interface wrapper (IIW). The IIW provides the
following benefits:
•
From the component point of view all calls are local calls
•
All calls are done in the components native programming language.
•
Platform components may be implemented in any programming language w/o
causing interoperability problems
This optimistic approach leads to efficient implementations, since adaptations are done
only when they are really needed. In order to provide this functionality the IIW checks at
the platform manager whether the component is executed locally or not as well as in
which programming language the component is realized. If the programming languages
of both components are the same, native interface are used for remote and local
communication. Otherwise the IIW generates a SOAP call out of the method invocation
and activates the SOAP APIs of the called component.
4.3.2 PLATFORM CONFIGURATION
In this section we will describe how a certain platform configuration may be adapted to
new applications that shall be executed. We first describe the potential triggers for such a
reconfiguration, and then we provide inside into the sequence of action that have to be
taken to install new components are on a certain device.
4.3.2.1 Reconfiguration triggers
Basically a reconfiguration can be triggered by the following events:
• A user starts a new application that needs additional components to be installed at
the mobile device.
• The user changes her role i.e. she is going to be a service provider instead of a
service user, and the resources of the mobile device do not allow to have both
roles of all components needed to be installed. Thus, those components which are
no longer needed are stopped and unloaded, whereas the others are downloaded
and installed.
4.3.2.2 Reconfiguration Sequence
The trigger mentioned above activate the service discovery component which then
searches for the components needed. When these are found, the download component is
retrieving the components form their current locations. After finishing the download the
security component checks the integrity of the components, before they are installed and
started by the platform manager.
Service discovery (component discovery)
One challenge with SD is that several standards are exiting already today, being
incompatible to each other. As soon as a platform has several SD implementations
available, the development of components can become more difficult, because the
components should know where the SD mechanisms are and how to access them.
The solution we developed is that our SD is realized via a dispatcher mechanism. This
Dispatcher sends search request to all SD mechanisms currently registered to the
platform. The results of this SD request are gathered and passed on the requesting
component.
Via this dispatcher mechanism, the search for components is transparent to the requesting
component. The client sends a service discovery request to the service discovery
dispatcher. The dispatcher forwards this request to all service discovery implementations
which are registered at the platform. Next the dispatcher collects all results from the
service discovery implementations and returns this collection to the requesting client.
In Figure 22 the structure of the service discovery system with client, query and service
discovery technologies is shown.
Client
send
Open Service
Discovery API
create
start
Job dispatcher
invoke
dispatch
Service discovery job
formulate
Query
return
Service
discovery
technology
Service
descriptions
write
Service
discovery
technology
Service
discovery
technology
Figure 22: Structure of the service discovery system
Below the service discovery request from a client to the service discovery system is
described.
The Client (e.g. a platform Component) formulates a “query” and sends it to the open
service discovery API.
On the basis of this client query, the Open Service Discovery API creates a Service
Discovery Job, consisting of the query itself and a Service Description Container. Next
the job is forwarded to the Job dispatcher. The Job dispatcher sends this Job to all Service
Discovery Implementations with are registered at the platform. Each Service Discovery
Implementation which is able to interpret this search request puts the service descriptions
of all located Services to the Services Description Container.
•
After all registered Services Discovery Implementations are queried the list of
service descriptions is forwarded to the requesting client.
•
In order to allow an optimal automatic selection of the best fitting components the
following features should be provided:
•
Component composition: allows to create components of higher functionality
from components with basic functionality. Composed components can be
composed again to create even more function-rich ensembles.
Semantic component description: for automatic component composition, a machineprocessable semantic component description is necessary to explore the capabilities of
components subject for composition. Furthermore, semantic component description
contains hints for configuration settings of components to adjust them optimally to the
current context, like maximum allowed resource use.
Ontologies: are required for deciding which components are to be composed, and to find
matches between compatible components. Ontologies also provide hints for global
configuration settings that shall be applied to a whole set of components within the
middleware.
Security Component
As soon as the new component is received it has to be verified whether it is save to install
and start the component. This functionality is provided by the security component. The
idea here is that components that are implemented by a trustworthy software company,
service provider or similar get a digital signature from that entity. The security
component then uses the digital signature to verify whether the component received is
unchanged or not. It calculates the hash value of the downloaded data and verifies then
digital signature. The result of this verification is indicated to platform manager which
then starts or removes the component, in case of successful or unsuccessful verification
respectively. The cipher mechanisms currently supported by our component are AES, and
elliptic curve cryptography.
Platform manager
The life cycle management, being part of the platform manager, is explained in detail in
[13]. Components are loaded and started by the platform manager to become available in
the middleware, and are stopped and unloaded when they should become unavailable.
Components implement the life cycle operations to perform, e.g. opening and closing
files, allocating memory and supporting user interfaces. The platform manager only
performs the life cycle transitions, i.e. loading, starting, stopping and unloading
components and monitoring life cycle operations. This separation gives components the
flexibility to perform operations they need when going through the life cycle while the
platform manager has control over it.
While performing life cycle transitions the platform manager announces itself to the
component currently transiting. Resulting, components have a reference to the platform
manager that is responsible for them, one necessary requirement for the service discovery
strategy explained above. Components may instruct the platform manager to perform
other management activities such as signaling events and loading and starting other
components on demand.
5 Evaluation and future research
In this section we provide a short evaluation of the introduced middleware approaches
and discuss future research directions. The latter are obviously influenced by the
shortcomings of existing middleware approaches and by new research directions that
came up recently.
5.1
Evaluation
The evaluation given here takes into account the platforms introduced in this document.
The criteria for this evaluation are taken from section 1 “Application Programmer
Support” and have been extended by the following ones:
•
•
•
•
•
•
•
•
•
Support of heterogeneous networks: does the platform support networks with
heterogeneous architectures, i.e. are they somehow taken into account (ad hoc,
cellular and WSN features and problems)
Agnostic to layer 2.5 and below: can the platform deal with different transmission
technologies (GSM, UMTS, WLAN); is it agnostic, i.e. does it see IP only; can it
support ad hoc as well as infrastructure based operations
Management of network properties: does it provide different transaction models
i.e. semantics of RPC such as at least or at most once; can it cope with loss of
connectivity
Clients supported (Thick/Thin): what kind of hardware does the platform require,
e.g. is a Java Virtual Machine needed; (this point may be relevant only if sensor
node are considered as clients)
Expandability: does the platform allow easy integration of new components
Configurability: are means provided to load and start components on demand, in
other words are means provided to adapt the instantiation of the platform to
specific needs of the client
Interoperability: inside the platform and with other services
Support of competing services: does the platform support pre-emption, e.g. can
voice services interrupt data services
Resource-Management (Client vs. Infrastructure): does the platform provide
means to re-allocate services in order to reduce processing load at the client side
or to allow for disconnected operation
Table 2 shows the evaluation results. Those results are on a quality basis only, i.e. no
quantitative means such as measurements or experiments have been used. Thus, the
ratings are somewhat influenced by the personal experience of the authors. The
evaluation results clearly point out that the upperware approaches outperform the general
purpose platforms. This result was quite naturally to be expected. The upperware
approaches inherited features from the general purpose platforms, which have been used
to realize them, and provide additional services, e.g. location handling, to support mobile
applications. Most upperware approaches have ignored the need for tool support.
PLASMA is the only upperware that supports a graphical editor [14] to define, simulate
and implement a location based service.
Although upperware approaches already solved several mobile computing challenges a
lot of open issues still exist. Those issues reach from tool support for application
developers over dynamic adaptability of the platforms down to network related issues
such as anticipation of loss of connectivity. Resulting research directions are discussed in
the following subsection.
Table 2: Comparison of the platforms under evaluation
„ General Purpose“ MW
.NET J2EE
Upperware
WebServices
PLASMA
MobWebSam
Winzell
Agnostic to layer 2.5 and
below
++
++
++
++
++
++
Support of
heterogeneous networks
(cellular/ad hoc/WSN)
--
--
--
--
--
--
Management of network
properties
-
-
-
+
+
+
Clients supported
+
++
++
++
+
++
Expandability
o
+
++
-
++
++
Configurability
+
+
+
+
+
+
Interoperability
-
-
++
-/+
++
++
Support of competing
services
o
o
o
o
o
o
Resource-Management
+
+
+
+
+
++
Sophisticated Services
(e.g. location handling)
-
-
-
++
++
++
Lifecycle Mgmt
-/+
-/+
-/+
-/+
-/+
++
Tool Support
-/+
-/+
-/+
+
-/+
-/+
Legend:
++ provides/supports the feature very good
+ provides/supports the feature
+/- provides/supports the feature in parts i.e. not for mobile devices or inherited
form the general purpose architecture used to realize the upperware
- does not provide/support the feature
o no information given
5.2
Open Issues and research Directions
During the development of the platforms described in this document mobile devices have
been considered as resource constrained. As consequence they are used merely as kind of
portable displays. Meanwhile mobile devices have become very powerful, i.e. they are
equipped with 400-800MHz XScale processors and up to 1 GByte memory. But a
transparent view on the heterogeneous distributed devices is still not provided by
platforms and development tools. Or to be more correct the current view is transparent
but agnostic, i.e. details such as used protocols and current network load that would allow
improving performance of applications in heterogeneous systems are merely suppressed
by the platforms. Dealing with those issues on higher layers is still in its infancy and tool
support is still missing.
During the same time frame wireless sensor networks have gained momentum. Compared
to mobile devices used to investigate middleware approaches for mobile computing, most
sensor nodes are still pretty constrained with respect to computing and electric power.
The capabilities of sensor nodes are going to change significantly within the next decade.
The first ideas to use multi core architectures for sensor nodes are under consideration
[15]. This new situation provides a lot of fascinating opportunities for service and
application developers.
In order to provide transparent application development support in a world consisting of
sensor nodes, mobile devices such as smart phones and PCs/workstations new
middleware services need to be investigated. The same holds true for tools support for
developers of middleware services and especially for application programmers.
The explicitly mentioned research challenges are not a complete list of open issues but
are discussed merely as examples to show to which kind of questions attention should be
paid. We have developed our vision of future research topics by analysing systems
consisting of stationary and mobile devices that are connected via faulty wireless
connections. We consider the following aspects to be important basic building blocks:
•
Mobility management
Proactive mobility management can be exploited to allow real disconnected
operation, i.e. it can be used by a platform module that reallocates code and data
according to situation changes such as expected loss of connectivity. A lot of
work has been done in the area of mobility management [16, 17, 18, 19, 20, 21,
22, 23, 24, 25, 26, 27]. All these approaches provide a solid basis for further
investigation, but are somewhat limited since they focus on single protocol layers
or are applicable for specific kinds of applications only. More sophisticated
approaches that take into account several protocol layers still need further
investigation [28]. In addition only little attention has been paid to proactive
strategies.
•
Performance Optimization in Heterogeneous Systems
Most standard platforms such as CORBA, J2EE etc. provide load balancing
means. But they are focussed on stationary devices. Load balancing in the area of
mobile computing has also attracted attention [29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 40, 41]. The focus of most of these approaches was to reduce
computational load on mobile devices. The processing power of mobile devices
and sensor nodes are merely ignored in those approaches. We are convinced that
these resources need to be taken into account in order to provide high quality
services in all situations. First steps in this direction have been discussed in [42].
Here, the authors have proposed the migration of some tasks onto mobile devices
such as laptops in order to reduce latency.
Performance optimization can be realized by appropriately using load balancing
means, but also by supporting disconnected operation of mobile devices. To the
latter code and/or data need to be relocated according to the concrete situations
described by computing load, network load, network availability and many more
parameters.
In order to allow for a meaningful performance optimization three different
aspects, i.e. the middleware, the operating system and the network, need to be
taken into account. One of the open issues here is that a common semantics for
“load” is missing, so that information is lost if it is not completely ignored by
other components. Also appropriate load monitoring support for heterogeneous
systems, which would form the basis for performance optimization, is missing. In
addition suitable strategies for relocating code and data need to be investigated.
•
Negotiation of SLA
The advent of paradigm of service oriented architecture (SOA) and even more
recently of service oriented computing provides interesting new opportunities
when it comes to service and application realization. But it poses new challenges
such as how an appropriate service can be identified, how service quality can be
negotiated before service use and how it can be verified during service use [43].
All these issues are still not solved for stationary services, but first attempts are
already made to apply SOA also in the area of sensor networks. So, means to
negotiate service quality, describe service semantics, etc. need to be investigated
and the solutions require to be applicable by very heterogeneous devices. The
existing approaches [44, 45, 46, 47, 48] are still not providing negotiation with
real bargaining features but merely a kind of calculating the intersection of
offered features similar to the negotiation of the encryption method in SSL/TLS.
In addition these approaches are not really suitable for mobile and embedded
devices.
•
Security/Privacy
The new capabilities of sensor nodes, upcoming applications, e.g. in the health
care area, and approaches that try to integrate WSN into the world wide web [49,
50] require new mechanisms to secure services from the sensor nodes up to the
service level on stationary devices. In addition it requires new approaches to
ensure privacy. Here especially the data gathering side needs to be taken into
account. We also envision that new techniques to determine the level of privacy
that needs to be ensured have to be developed. Especially in pervasive
environments privacy requirements of several users need to be obeyed
simultaneously. This is a challenging task since user requirements may vary
widely from no privacy protection to total suppression of data.
•
Tool support
o Application development tools: The capabilities of (embedded) hardware
are rapidly evolving. We foresee a fundamental shift from systems where
a single processor manages a set of peripherals to multi-core systems that
interact more richly with embedded micro-controllers, VLIW components,
DMA engines, and sensors. Advancements in FPGA technologies are
providing a fertile mechanism to realize these complex, customized
designs. Current middleware is not capable of making use of these
disruptive advancements in microelectronics. New design paradigms and
programming models are needed that support e.g. real concurrency.
o Verification and diagnosis tools: As systems become more and more
complex, more sophisticated verification and diagnosis methods are
needed. In order to master this increasing complexity, there is a strong
demand to develop integrated software development tool chains.
6 References
[1]
Java Specification Requests, http://www.jcp.org/en/jsr/all
[2]
Universal Plug and Play, http://www.upnp.org
[3]
FIPA
Ontology
Service
http://www.fipa.org/specs/fipa00086/index.html
[4]
Semantic, http://www.w3.org/RDF/
[5]
World Wide Web, http://www.w3.org/2001/sw/
[6]
http://www.daml.org
[7]
FIPA
Ontology
Service
http://www.fipa.org/specs/fipa00091/index.html
[9]
Microsoft Library, http://msdn.microsoft.com/library/
[8]
OSGi
Service
Platform
http://www2.osgi.org/Specifications/HomePage
[10]
P. Langendörfer, O. Maye, Z. Dyka, R. Sorge, R. Winkler, R.
Kraemer; “Middleware for Location-based Services: Design and
Implementation Issues”, in Q. Mahmoud (ed.) Middleware for
Communication, Wiley, 2004
[11]
G. Gehlen, G. Mavromatis; “Mobile Web Service based Middleware
for Context-Aware Applications”, Proceedings of the 11th European
Wireless Conference 2005, Vol. 2, Nicosia, Cyprus
[12]
C. Klein et al.; “Wireless Internet-zellular” Abschlussbericht, TIB
Hannover,
2005,
http://edok01.tib.uni-hannover.de/edoks/e01fb07/524541892.pdf
[13]
B. Wuest, O. Drögehorn, K. David; “Framework for middleware in
ubiquitous computing systems”, PIMRC 2005 - The 16th IEEE
International Symposium on Personal, Indoor and Mobile Radio
Communications, Vol. 4, 2005
[14]
P. Langendörfer, S. Adam; “A Graphical Tool for Specification,
Rapid Prototyping and Implementation of Location Based Services”,
Proceedings des VDE Kongress 2006 Innovations for Europe:
Mobility, VDE Verlag, Oktober 2006
[15]
„TANDEM - Ein extrem verbrauchsarmes, skalierbares,
tandemprozessorbasiertes Funksystem für sensorische, aktuatorische
und kennzeichnende Anwendungen“, http://www.unternehmenregion.de/de/1843.php, 2007
Specification,
Specification,
Release
4,
[16]
R. Bagrodia, T. Phan; “Guy, A Scalable, Distributed Middleware
Service Architecture to Support Mobile Internet Applications”,
Journal of Wireless Networks (Kluwer), Vol. 9, 2003
[17]
S. S. Yau, F. Karim, “A Context-Sensitive Middleware-based
Approach to Dynamically Integrating Mobile Devices into
Computational Infrastructures”, Journal: Parallel and Distributed
Computing, Vol. 64(2), February 2004
[18]
T. Strang, C. Linnhoff–Popien, M. Röckl; “Highlevel Service
Handover through a Contextual Framework”, Proceedings of 8th
International Workshop on Mobile Multimedia Communications
(MoMuC2003), Center for Digital Technology and Management
(CDTM), Munich, Germany, 2003.
[19]
A. Dutta, S. Madhani, W. Chen, O. Altintas, H. Schulzrinne, “Fasthandoff Schemes for Application Layer Mobility Management”,
PIMRC 2004 - The 15th IEEE International Symposium on Personal,
Indoor and Mobile Radio Communications, Barcelona, Spain, 2004
[20]
A. Dutta, T. Zhang, S. Madhani, K. Taniuchi, K. Fujimoto, Y.
Katsube, Y. Ohba, H. Schulzrinne, “Secure Universal Mobility for
Wireless Internet”, Proceedings of the 2nd ACM International
Workshop on Wireless Mobile Applications and Services on WLAN
Hotspots, WMASH 2004, Philadelphia, PA, USA, October, 2004
[21]
N. Van den Wijngaert, C. Blondia; “A Location Augmented Low
Latency Handoff Scheme for Mobile IP”, Proceedings of First
International Conference on Mobile Computing and Ubiquitous
Networking ICMU04, Yokosuka, Japan, January 2004
[22]
M Ergen, S. Coleri, B. Dundar, R. Jain, A. Puri, P. Varaiya;
“Application of GPS to Mobile IP and Routine in Wireless Networks”,
Proceedings of 56th Vehicular Technology Conference, 2002
[23]
J.Z.Sun, J. Sauvola, “Mobility management reconsideration:
hierarchical model and flow control methodology”, 14th IEEE
International Symposium on Personal, Indoor and Mobile Radio
Communications, Beijing, China, Sep., 2003, Vol. 3
[24]
T. Braun, M. Danzeisen; “Secure Mobile IP Communication”,
Proceedings of the 26th Annual IEEE Conference on Local Computer
Networks, 2001
[25]
J. Tourrilhes; “L7-mobility: A framework for handling mobility at the
application level.“, PIMRC 2004 - The 15th IEEE International
Symposium on Personal, Indoor and Mobile Radio Communications,
Barcelona, Spain, 2004
[26]
K. Murakami, O. Haase, J. Shin, Th. LaPorta; “Mobility Management
Alternatives for Migration to Mobile internet Session-Based
Services”, IEEE Journal on Selected Areas in Communications,
Vol. 22, No. 5, 2004
[27]
L. Chen, T. Sun, B. Chen, V. Rajendran, M. Gerla; “A Smart Decision
Model for Vertical Handoff”, The 4th ANWIRE International
Workshop on Wireless Internet and Reconfigurability, Athens,
Greece, 2004
[28]
I.F. Akyildiz, J. Xie, S. Mohanty; “A Survey of mobility Management
in Nextgeneration All-IP-Based Wirelss Systems”, Wireless
Communications, IEEE, Vol. 11, No. 4. 2004
[29]
R.K. Balan; “Powerful Change Part 2: Reducing the Power Demands
of Mobile Devices”, Pervasive Computing Vol. 03, No. 2, 2004
[30]
T. Desell; K. e. Maghraoui; C. “Varela Load balancing of
Autonomous Actors over Dynamic Networks”, Proceedings of the 37th
Hawaii International Conference on System Sciences, 2004
[31]
G. Chen et al.; “Energy Aware Mobile Computing”, Transactions on
Parallel and Distributed Systems", Vol. 15, No 9, 2004
[32]
http://www.oio.de/m/jboss-clustering/clustering-nutshell.htm
[33]
http://www.jboss.org/developers/projects/jboss/clustering
[34]
http://www.jboss.org/modules/html/developers/projects/jboss/
JBossCluster_FeatureMatrix.pdf
[35]
Inprise Corporation Inc., “VisiBroker for Java 4.0: Programmer’s
guide: Using POA”
http://www.inprise.com/techpubs/books/vbj/vbj40/programmersguide/poa.html, 1999
[36]
K.S. Ho; H.V. Leong; “An Extended CORBA Event Service with
Support for load balancing and Fault Tolerance”, Proceedings of the
International Symposium on Distributed Objects and Applications,
2000
[37]
Th. Barth, G. Flender, B. Freisleben, F. Thilo; “Load Distribution in a
CORBA Environment”, Proceedings of the International Symposium
on Distributed Objects and Applications, 1999
[38]
M. Aleksy, A. Korthaus, M. Schader; “Design and Implementation of
a Flexible Load Balancing Service for CORBA-based Applications”,
Proceedings of the International Conference on Parallel and
Distributed Processing Techniques and Applications, 2001
[39]
BEA Systems Inc., “Weblogic Administration Guide”,
http://www.bea.com/, 2000
[40]
IONA Technologies, “Orbix 2000”, http://www.iona.com/products/,
2000
[41]
J. Balasubramanian, D.C. Schmidt, O. Othman; “Performance
Evaluation of Adaptive Middleware Load Distribution Strategies”,
Proceedings of the 8th International IEEE Enterprise Distributed
Object Computing Conference, 2004.
[42]
T. Newhouse, J. Pasquale; “Resource-controlled Remote Execution to
Enhance Wireless Network Applications”, Proceeding of 4th
Workshop on Applications and Services in Wireless Networks,
Boston, MA, USA, August, 2004
[43]
M.P. Papazoglou, P. Traverso, S. Dustdar, F. Leymann; “ServiceOriented Computing Research Roadmap”,
ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/st-ds/servicesresearch-roadmap_en.pdf
[44]
H. Ludwig, A. Keller, A. Dan, R. P. King, R. Franck; “Web Service
Level Agreement (WSLA) Language Specification”,
http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf,
IBM T.J. Watson Research Center, IBM Software Group, 2003
[45]
Electronic Business using eXtensible Markup Language, Technical
Specifications,
http://www.ebxml.org/specs/index.htm#technical_specifications, 2001
[46]
M. Sachs, A. Dan, T. Nguyen, R. Kearney, H. Shaikh, D. Dias;
“Executable trading partner agreements in electronic commerce”,
IBM T.J. Watson Research Center, New York 2000.
[47]
A. Dan, D. Dias, N. Halim, L. Lam, M. Sachs; “Automated Dynamic
Negotiation of Electronic Service Contracts”, US Patent Application
20020178103 Filed March, 2001, Published November, 2002
[48]
S. Schlegel; “Candidacy Report”,
http://www.schlegel.li/ebXML/candidacy_report/
candidacy_report.pdf, October, 2002
[49]
S. Nath, J. Liu, F. Zhao; “SensorMAP for Wide-Area Sensor Webs”,
IEEE Computer Magazine, Vol 40, No. 7, 2007
[50]
M. Botts, G. Percivall, C. Reed, J. Davidson; “OGC® Sensor Web
Enablement: Overview And High Level Architecture.”
http://www.opengeospatial.org/projects/groups/sensorweb