- Service-oriented computing is a new emerging com- to a broad range of systems, ranging from personal handputing paradigm that changes the way applications are designed, helds and smart phones to larger set-top boxes. The second implemented and consumed in a ubiquitous computing environ- requirement is that applications and services need to be less tmraenditt.ioInnasludcehskentovpirtoonmsmeanltlsecmombepdudteindganisdpnuesthweodrkaewdaycofmropmutitnhge dependent on user-intervention and prevent users from being devices around us. However, developing mobile and pervasive overwhelmed with intrusive human computer interactions. services for a broad range of systems with different capabilities Therefore, service-oriented architectures must be able to gather and limitations while ensuring its users a minimum quality of information about the user and his physical and digital enviservice is a daunting task. ronment to autonomously adapt the behavior of the provided posTithieoncoinrefrcaostnrturcibtuurtieontoocfrethaitse paanpeinrstisanatiacotinotnexotf-daripveenrvcaosimve- services according to the current context of the user and the service customized to the preferences of the user and to the capa- device he is interacting with. It are these two gaps that our bilities of his device. We implement services as a composition of infrastructure is trying to fill in. components. This enables us to compose a service implementation To alleviate the first concern we employ a component-based targeted at a specific device while still being able to adapt it at software engineering methodology [3] for building services run-time to respond to changing working conditions. to be consumed within ubiquitous computing environments. I. INTRODUCTION Component-based software engineering is being recognized as an important approach for software upgrade and dynamic The third wave of computing is slowly appearing: ubiq- reconfiguration in dependable resource-constrained and emuitous computing. This new computing paradigm promises bedded devices. As such, services are a collection of interan augmented reality that changes the way people interact connected computational building blocks that offer a certain with computers. It promises continuous human computer functionality to a network of devices with varying capabilities. interaction with small embedded and networked computing The second concern with respect to customization of services systems around us that provide 24/7 access to information and is tackled by context-driven composition of components and computational capabilities, and envisions pushing computing using context-awareness, including user preferences, to inaway from the traditional desktop system [1]. crease the non-intrusiveness of pervasive services. The overall When Weiser introduced the area of ubiquitous comput- objective is to achieve automatic composition of customized ing [2] in 1991, he put forth a vision of a deployment of pervasive services using components as building blocks by usdevices at varying scales, ranging from hand-held personal ing contextual information [4] for dealing with the variability digital assistants to larger shared devices providing the neces- of pervasive computing devices and user personalization. sary infrastructure support. He also envisioned a new paradigm In section II we discuss several non-functional concerns of interaction using natural interfaces such as speech, video with respect to services being targeted at ubiquitous computand sensor inputs, instead of traditional keyboard and mouse, ing environments and how a component-based development to facilitate communication between humans and computers. methodology can be of help for designing and deploying perThis new way of interaction with computational devices vasive services. Section III discusses how context, including introduces two important non-functional requirements with user preferences and resource availability among other inforrespect to the development of pervasive services. The first mation, and components are formally specified in OWL to suprequirement is that services should not be developed from port automated service composition for optimal deployment scratch to provide an optimal implementation for each device on a specific device. The core ideas of automated contextwith different capabilities and limitations. As such, the design driven composition of components into services are directly and the deployment process of services should offer the illustrated in section IV and build upon previous work on software engineer the necessary flexibility to target services context modeling [4], pervasive service specification [5] and
context management support [
II. NON-FUNCTIONAL CONCERNS OF PERVASIVE SERVICES
Pervasive services offer a certain functionality to nearby customers and are accessed in an anytime-anywhere fashion, while being deployed on all kinds of devices. The aspects of user mobility, personalization and context-awareness may activate service adaptation and migration to other devices with different characteristics. In this section we review several non-functional concerns with respect to ensuring that all the requirements of the delivery and provision of the service to be consumed in a mobile and pervasive setting are met.
These concerns have an impact on the design and the deployment of services and often define deployment constraints that take the capabilities and limitations of a device into account as well as any user requirements or preferences with respect to the service.
In the ubiquitous computing setting, available services will approach the user on detection of his presence, while the user wants to have the best deals. However, this multi-user and multi-computer interaction causes a competition of resources on shared devices. Therefore, resource-awareness about the maximum availability and current usage of processing power, memory, network bandwidth, battery lifetime, etc., is a prerequisite to guarantee a minimum quality of service.
Due to the black box nature of components, a component’s
functional properties (interfaces and task description) as well
as its non-functional properties (resource requirements and
adaptation policies) [
User mobility is a corner stone of the society of tomorrow. Due to possible wireless network disruptions, a user may wish to download and run a service locally. If, on the other hand, the downloaded service does not run within the currently available resources of the device, the user may wish to run the service on a remote more powerful device in the vicinity of the user or to relocate (parts of) an already running service. In both cases the mobile setting of the user triggers service migration to other devices.
The encapsulation of the implementation of components and
their message-based interaction make it easy to relocate a
component for distributed execution of the service by instantiating
the component elsewhere [
In the face of highly dynamic environments, heterogeneous devices and their changing context, services will need to adapt to changing working conditions.
For stateless components, a component can be replaced
with a similar component at runtime as long as the syntax
and semantics of the interfaces of a component remain the
same [
Our pervasive service design methodology makes use of the
SEESCOA component methodology [
The example in Figure 1 shows how three components, Number Generator, Switch and Control Relay, are composed into a new composite component Pausible Number Generator. The number generator repeatedly provides random numbers with a user-defined frequency. If the Switch component is enabled, then the numbers are shown on a screen by the Number Display component. The random number generator interacts with the Scheduler component to get notified of when to send out a new number. The user is able to interact with the application by using the Interactive Shell component. It provides a prompt to send messages to the application, for example, to pause and later continue the random number generation by (de)activating the switch. These messages are intercepted by the Control Relay component, which forwards the messages to the right component. The Timing contract specifies timing constraints for sending messages from the number generator to the switch to ensure that messages are delivered on time, and is only shown here for demonstration purposes.
COMPONENT-BASED PERVASIVE SERVICES
The example in Figure 1 is an extension of an even smaller application that does not include the switch and control relay. In the latter case, the user is not able to pause the random number generation.
The core of our contribution is that pervasive services are modeled by specifying all components, including the optional components and that these components are instantiated by selecting an appropriate implementation or bypassed depending on the current context of the device or any user requirements. The functional specification of components and runtime support for their non-functional concerns in component systems allow the programmer to design services in terms of components and focus on program logic instead of deployment dependencies. With proper middleware support, the programmer does not need to implement resource monitoring, decision making or adaptation of services to respond to changing working conditions.
Two prerequisites for context-aware composition of
pervasive services are an explicit model for specifying context
and middleware that is able to gather and interpret this
contextual information. In the Context Toolkit [
We have designed a context ontology [
<owl:ObjectProperty rdf:ID="hasPort" /> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="CompositeComponent"> <rdfs:subClassOf rdf:resource="#SimpleComponent" /> <rdfs:subClassOf> <owl:Restriction> <owl:minCardinality rdf:datatype="&xsd;#int"> 1</owl:minCardinality> <owl:onProperty>
<owl:ObjectProperty rdf:ID="hasComponentInstance" /> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:ObjectProperty rdf:about="#hasComponentInstance"> <rdfs:domain rdf:resource="#CompositeComponent" /> <rdfs:range rdf:resource="#ComponentInstance" /> </owl:ObjectProperty> <owl:Class rdf:ID="Port"> <rdfs:subClassOf> <owl:Restriction> <owl:cardinality rdf:datatype="&xsd;#int"> 1</owl:cardinality> <owl:onProperty>
<owl:DatatypeProperty rdf:ID="maxInstances" /> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PortGroup">
<rdfs:subClassOf rdf:resource="#Port" />
</owl:Class>
...
and syntax of a service and its service ports, and hence
of how the service can be interfaced, so that other
components or services can discover and use the service.
This information is expressed in OWL-s [
By modeling services as components, all aspects of composing components into a services apply to services is well, which means that services can be combined to form a new service.
The automated composition of our infrastructure requires
that all components are fully specified. We therefore created
a component ontology in OWL which serves as a meta-model
of all the concepts of the SEESCOA methodology,
specifying components, ports, messages, parameters, connectors,
contracts, etc. as an OWL Class, ObjectProperty or
DatatypeProperty with cardinality restrictions where appropriate. See
Figure 2 for a partial meta-model specification of a
component in OWL 1. It allows the software engineer to validate
component descriptions by using a regular OWL validator [
Context-awareness comes into play during the evaluation
of the non-functional properties of services and components.
The service and each component separately can specify
minimum resource requirements, such as the minimum
availability of memory, processing power or network bandwidth.
These resource requirements are specified by extending the
serviceParameter concept in OWL-s of which an
example is given in bold in Figure 3. In this example, a minimum
memory requirement for the service is specified, but it could
have been any contextual requirement with respect to concepts
in our context ontology [
Our context-driven composition infrastructure instantiates a pervasive service by connecting a selection of components such that all requirements hold. In the next section, we will describe an example of a service with several optional components that can be activated when possible. These optional components require extra resources, and we therefore specify triggers to model QoS requirements and to define adaptation policies.
IV. CONTEXT-DRIVEN COMPOSITION OF PERVASIVE
SERVICES
The core ideas of how our infrastructure supports automated context-driven composition of pervasive services are discussed in this section. The concepts of taking into account the capabilities and limitations of a device, resource awareness and user preferences in a specific context are illustrated by means of an example. We also provide an outline of our algorithm to discuss the steps taken to deploy a customized pervasive service and mention implementation details.
Consider the following scenario in a ubiquitous and mobile computing environment where two friends, Jack and Jill, are having a conversation over the Internet:
“Jack is heading off to work and using public transport. He is using his advanced smartphone and a shared Internet gateway service on the train. Bandwidth is equally shared by all passengers currently logged on to the Internet gateway service. Jill is at home using her laptop with broadband Internet connection and has no resource limitations.
The communication service both Jack and Jill downloaded on their device is able to communicate using text messaging, speech and video, sorted by increasing bandwidth requirements. The speech and video quality (high, medium and low) depends on the compression, the frame rate and the frame size being used. These parameters are chosen dynamically depending on the available bandwidth and processing power on the smartphone or are defined as user preferences in a certain context.” A. The component-based model of the communication service
See Figure 4 for a simplified overview of both services. We will now focus on the Communication Service for which a composition will be auto-instantiated depending on the current context of the user and the communication device. The service has the following components: • Audio Encoder and Decoder: Adaptable and optional components for (de-)compressing the audio stream with high, medium or low quality encoding. • Video Filter: Optional components for reducing the video frame rate or changing the frame size. See Figure 5 for an instantiation of the OWL component meta-model. The component name and port names are in bold for clarification purposes. • Video Encoder and Decoder: Adaptable and optional components for (de-)compressing the video stream with high, medium or low quality encoding. • Controller: (de-)multiplexes text, speech and video, and sends/receives the combined data stream.
The audio and video components in this service model are optional, and can be activated when enough resources are available. These components can have several implementations using different encoding schemes. Both parties would have to agree which encoding schemes can be used on the two communication devices. However, in this example one party, Jill, has no resource restrictions and can instantiate any component she likes. <component:SimpleComponent rdf:ID="FrameRateFilter"> <component:hasPort rdf:resource="#FrameRate"/> <component:hasPort rdf:resource="#VideoIn"/> <component:hasPort rdf:resource="#VideoOut"/> <component:PortGroup rdf:ID="FrameRate"> <component:maxInstances rdf:datatype="&xsd;#int"> 1</component:maxInstances> <component:hasMessage> <component:InMessage rdf:ID="SetFrameRate"> <component:hasParameter> <component:Parameter rdf:ID="FramePerSec"> <component:parameterType rdf:datatype=
"&xsd;#anyURI">&xsd;#int </component:parameterType> </component:Parameter> </component:hasParameter> </component:InMessage> </component:hasMessage> </component:PortGroup> <component:PortGroup rdf:ID="VideoIn"> <component:maxInstances rdf:datatype="&xsd;#int"> 1</component:maxInstances> <component:hasMessage> <component:InMessage rdf:ID="NewFrame"> <component:hasParameter> <component:Parameter rdf:ID="Frame"> <component:parameterType rdf:datatype=
"&xsd;#anyURI">&concepts;#VideoFrame </component:parameterType> </component:Parameter> </component:hasParameter> </component:InMessage> </component:hasMessage> </component:PortGroup> <component:MulticastPort rdf:ID="VideoOut" />
<!-- Similar to the video-in port --> ... </component:SimpleComponent>
The minimum resource requirements for the service, as
shown in bold in Figure 3, specify what is needed to have a
text-based conversation. This kind of communication requires
the least bandwidth and processing power. If more resources
are available, audio and video-based communication can be
enabled as well. Information about available resources is
provided by our context management system [
A user may have a preference stating that during office hours the high quality option for video encoding should be used. See Figure 6, the preference property and value as well as the time and location conditions are marked in bold. Using this contextual information, an appropriate service is instantiated that takes any user preferences and the current available resources and the limitations and capabilities of the device into account. For example, before deploying the communication service on a PDA or smart phone, we check if the hardware has the necessary support for video communication as, for example, not all devices have a camera on-board. D. Outline of the context-driven service composition procedure
The goal of our context-driven composition infrastructure is an automated instantiation of a service targeted at the capabilities of a specific device that takes into account any user preferences in a specific context. The whole algorithm is entirely based on the processing of OWL and OWL-s specifications and consists of the following steps. 1) Hardware Process the hardware description of the device to discover resource specifications, such as maximum available memory, processing power, network bandwidth, etc., as well as support for user input and output, such as microphone, camera, speaker, keyboard, display, sensors, etc. This is part of the context specification of a device and is largely static information. 2) Resource awareness Request the current available resources from the context management system. This is also part of the current context, but mostly dynamic information achieved by monitoring the system. 3) Service requirements Check any I/O requirements of the service with the I/O support of the device. Check if the minimal resource requirements can be fulfilled. If deploying is not possible, then stop or propose to run the service on another device in the neighborhood or relocate already running services. 4) User preferences Check for all preferences if the context of application is fulfilled and if these preferences can be enforced given the available resources. Checking if the context applies, may require some reasoning steps, for example, to determine that geographical coordinates of a GPS system point to a location known as our office. 5) Component selection Given the available resources, eliminate all optional components which resource requirements are too demanding. For each obligatory component, retrieve the resource requirements for all of its implementations. 6) Constraint solving Given the above resource constraints of the device and the requirements for the obligatory components and user preferences, solve the set of equations to find a minimal composition of component instances. Cut down on the user preferences if no solution is found. 7) Adaptation policy Check which optional components can be enabled for the preliminary minimal service instantiation from the previous step. Given the available resources, these optional components can be enabled immediately, when enough resources are available or when the context changes and other user preferences are to be applied.
For the multimedia components of the communication
service, we made use of the IBM Mpeg4 Java toolkit [
The case study has shown that for varying hardware and resource descriptions the implemented infrastructure is able to compose and instantiate a service while also taking the user preferences into account. Another advantage is that composing the service targeted at a specific device can also be carried out on a more powerful device when composing the service, for example, on a personal hand-held would take too long.
Something that is currently not implemented is multi-party negotiation of which components to instantiate as there can be dependencies between component deployments on different devices. In the above example, there is no use in instantiating a video encoding component on one device if the other party is not able to process or show the video stream.
The two non-functional concerns with respect to
resourceawareness and user-preferences in a certain context are easily
managed using a component-based methodology if all aspects
are fully specified. These aspects are specified by hand in
OWL using the Prote´ge´ [
However, not all non-functional aspects can be solved that
easily using a component-based software engineering
methodology. For cross-cutting concerns, such as security or logging,
an aspect-oriented software development approach (AOSD)
can prove to be more useful. Security concerns, for example,
relate to the connection between components and may impose
restrictions on how to customize and adapt pervasive services,
such as restricting the relocation of parts of a service to another
device to avoid interception of sensitive messages sent over
a network. The disadvantage of using AOSD techniques is
that depending on the tools applied, such as AspectJ [
Two very well-known component models are OMG’s
CORBA Component Model (CCM) [
The COMQUAD component model [
Efstratiou et al. [
Lin et al. [
We have developed infrastructure support for automated context-driven composition of components into pervasive services, while taking into account non-functional concerns such as the capabilities and limitations of a device on which it will be deployed, resource availability and user preferences in a specific context. It lets the software engineer focus on the application logic of smaller building blocks, while optimal deployment of a service on a specific device and adaptation support for responding to changing working conditions is managed by our supporting infrastructure.
First, we have identified several non-functional concerns
with respect to pervasive services and then discussed how a
component-based methodology can alleviate these concerns.
We formalized the component methodology by creating a
meta-model of all software aspects of components to allow
automated processing of the functional and non-functional
properties of components and services. We discussed how
contextawareness can be used for composition of component-based
services using our previous work on context modeling [
However, more work should be carried out to provide support for cross-cutting non-functional concerns, such as security. Security requirements cannot be derived from component descriptions as is the case for resource requirements. Future work in the short term will focus on how to integrate multiparty negotiation for selecting and instantiating components in the presence of dependencies between component deployments on different devices.