Functional and Architectural Adaptation in Pervasive Computing Environments S.K. Nandy, K. Kalapriya
N.C. Narendra
Umesh Bellur
[email protected]
[email protected]
IBM Software Labs India Airport Road, Bangalore, India
CADL, Indian Institute of Science, Bangalore, India
KReSIT, IIT Bombay Mumbai, India
ABSTRACT
Service-oriented computing paradigm encourages the use of dynamic binding of application requirements to the resources needed to fulfill application tasks. Especially in pervasive computing that is characterized by disconnected operation and mobility, the process of using service specifications and dynamic binding becomes critical. For this, adaptation techniques that provide for seamless service composition are needed for user task execution. In this paper we present our approach to enable two kinds of adaptations: functional (due to changes in user requirements) and architectural (due to changes in nonfunctional requirements) in pervasive computing systems. The key features of our approach are to model services as workflows, service handoffs as points of variability, and context detailing for dynamic service provisioning.
Categories and Subject Descriptors
H.4.1 [Information Systems Applications]: Office Automation – workflow management; H.4.0 [Information Systems Applications] General; C.2.0 [ComputerCommunication Networks] Distributed Systems – distributed applications
General Terms Algorithms, Design
Keywords
Pervasive Computing, Workflow Adaptation, ServiceOriented Architectures
1. INTRODUCTION
In Pervasive Computing [7] environments users will no longer be tied to the desktop, and will therefore be increasingly mobile. This results in usage patterns that are quite different from traditional workflow or office work. The new usage patterns are composed of low-power
[email protected] [email protected]
devices (mobile phones, PDAs, palmtops) co-existing with desktop computing systems, disconnected operation, and rapid and ad-hoc changes in usage patterns. Analogous to call continuations at cell boundaries in cellular telephony, we need a mechanism of computational handoff (also called variability points) that ensures that a running task is able to continue execution in the new environment without user intervention. The emerging service-oriented computing (SOC) paradigm (see [10]) stresses the need for computing systems to develop flexibility in both dynamically binding a request to the appropriate provider and for resource allocation to the provider to ensure an adequate quality of service (QoS). This is an enhancement over traditional computing systems, where this binding is done statically at design time and any run-time changes can only be implemented with extensive re-programming (although CORBA does provide some level of dynamic binding, it suffers from limitations such as requiring syntactic naming matches for interfaces, which violate the loose coupling requirement necessary for dynamic binding as per SOC principles). It now becomes apparent that this flexibility in binding resources to a request is precisely what we seek in attempting to adapt an existing transaction in a pervasive computing environment to mobility. At the same time, since resource availability is not guaranteed and can change rapidly due to mobility we need to have the ability to “provision” a service dynamically by allocating resources only upon the arrival of a service request and upon entering a new computing environment as a result of mobility. This is because resources in pervasive computing come online at any time and a service request in execution can migrate to a new compute environment [8]. Dynamic provisioning would therefore have to be preceded by dynamic discovery of resources for allocation.
"Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Please note that Web services (http://www.w3.org/TR/wsarch/), which are a variant of service-oriented architectures, offer a standardized way of publishing, looking up and using services based on protocols such as XML. However, this alone is not sufficient; we believe that service oriented environments also need strong support in the area of service conformance (to determine the set of candidate services for a request), service discovery and dynamic service instantiation.
MPAC '05, November 28- December 2, 2005 Grenoble, France, Copyright 2005 ACM 1-59593-268-2/05/11... $5.00"
In this paper, we present our ongoing work on using SOC principles to build pervasive computing systems. The
Article No. 5
following concepts are central to our approach. Each one of these concepts is detailed in the rest of the paper. a. A service in pervasive computing can be modeled as workflows, where every workflow is an ordered sequence of tasks. This is necessary to be able to gain control of the computation during the execution of the service at certain points from the perspective of being able to effect changes at these points. We term these points as variability points and the process as functional adaptation. A functional adaptation is required whenever there is a computational hand-off due to transience of services. The programming model includes a combination of the workflow together with the variability points. b. In this environment, non-functional aspects Quality of Service (QoS), performance, reliability, etc. - are represented by multi-layered contexts which are also used to do dynamic service provisioning. We term this notion of dynamic provisioning by matching available resources to the request’s context architectural adaptation. (It is necessary to re-compute the non-functional requirements at the variability point so that the user’s non-functional requirements are not violated.) The middleware layer is the one that is responsible for effecting functional and architectural adaptation. In this sense the key services afforded by a middleware layer are those of dynamic service binding and provisioning. The rest of this paper is organized as follows. Section 2 outlines the conceptual model of a service in both its logical and physical forms – this will lay the groundwork for the rest of this paper. Following this background, we outline how functional and architectural adaptation can be achieved, in Section 3. In Section 4 we tie these concepts together by describing the architecture of the middleware needed in pervasive computing environments. In section 5, we present an example scenario and show how it can be achieved in this setting. The paper concludes in Section 6 with suggestions for future work.
2. BASIC CONCEPTS
While the concept of service oriented architectures is not new, we need to clarify what a service exactly represents. The web services definitions of service orientation remains ambiguous about this. In our view, a service is the abstract representation of provided functionality together with a context specifying the provided non-functional attributes. In other words, it is a guarantee from a providers’ perspective, while a service request represents what is needed from a requestors’ perspective. A service cannot be invoked directly– we decouple the resources from its guarantees. This decoupling is critical to be able to instantiate the same functionality in several configurations depending on the non-functional needs of the user. The actual representation is name followed by the syntactic specification (signature) along with semantic information such as preconditions expected, postconditions guaranteed and specific algorithms used. So a sorting service might specify the input parameters it needs together with what it will return along with the fact that it uses bubble sort as
the algorithm of choice. Similarly, alternate sorting services could incorporate other sorting algorithms although they should all conform to the post-condition specifications. (We are currently working on a formal description language for representing functional and nonfunctional user requirements, and it will be described in a future paper.) We define context and what it represents in later sections. Figure 1 gives the conceptual model of the a service and its view as a workflow. 1…N
Tasks
1 1…N
Executed by
Resource (Role)
1
Service
Human
Physical (Component)
Figure 1. Conceptual Model Referring to Figure 1, a service is an abstract description of a capability. A software component is a computational entity that uses physical resources such as CPU and disk to perform its functions. It exports an interface made up of messages that can be sent to it and every message sent to it results in some computation being performed and results being returned. Services and components are orthogonal concepts – a service is realized through an ordered set of component & other service invocations. For example, one could have an ordering service at an eCommerce site that was itself realized using an inventory component used to reserve inventory of the item being ordered, a billing component used to charge the users’ credit card and a logistics service used to arrange for shipping of the ordered product. The logistics service in turn would be another workflow that will invoke further software components and so on. A variability point is a point where the task execution happens by a call to a component or to another service (rebinding). This selection of a component or service depends on the context. This gives us control of the binding to the specific component/service that will actually be used at runtime. Note that not all points where this call out occurs need be a variability point – the programmer has precedence over middleware to decide on the execution of the workflow. Variability points not only have to be designated but need to have a service request specified along with a context which can be used for dynamic binding of services by the middleware.
Article No. 5
3. ADAPTATION At the variability points the functional and architectural adaptations are detailed below.
3.1 Functional Variability Points
Adaptation
the
Using
Functional adaptation is the process which allows the workflow to change its behavior dynamically. This is necessary due to the following triggers: a. Change in availability of services/component in the execution environment. b. A change in the design of the application. Binding to the service/component is dynamic and is based on the designation of variability points. Binding of a task to a service/component at a variability point involves a dynamic discovery of the available services/components that best match the service requested at the point (our formal description language, which is under development, will more clearly define what “best match” means). Binding to a particular service represents the adaptation indicated by the former trigger. The latter trigger is caused by the user changing a functional requirement. This change can be expressed either as a change to the control flow of the workflow execution sequence and/or as a change in the variability point specified by the user to bind a task to a service/component. It should be noted that both the control flow as well as the variability points are available as configuration information and so a change in either of these is not a code change but merely a configuration change which can be dynamically incorporated.
3.2 Contexts Adaptation
and
Architectural
used by the components when they execute their functionality in order to meet the user requirements. Some examples are CPU usage, resource capacity, and execution speed associated with the resource. In order for component composition to be successful, that is for a preceding component to successfully “hand off” execution to its successor (as per the execution sequence) – their contextual information need to be matched. By “matching” here we mean that the successor component should be able to execute successfully based on the “hand off” from the preceding component. In other words, during the dynamic binding, contextual information can be thought of as originating from two sources – one from the component providing the service and one from the component requesting the service. The Table 1 below shows some samples of contextual information present at each level of the context for the provider (i.e., successor) and consumer (i.e., predecessor) components [1]. Table 1. Contextual Information
E-context
S-context
Binding of a service request to a service, and binding of the service to resources, is done on functional and nonfunctional attributes of the service specified via a context. Context is any information relevant to the interaction between a user and his environment [2]. Each component in the execution sequence possesses its own contextual information at the following three levels that we have identified [4]: a) Environmental level (E-context): this represents the contextual information of the overall environment, such as user (functional and non-functional) requirements, and services representing user requirements (we assume that the entity that publishes the service will also publish specific nonfunctional attributes of the service, along with the supported ranges for values of each non-functional attribute) b) Service level (S-context): this represents the contextual information at the level of the individual service, such as execution sequence representing a service, component interface descriptions, candidate components for execution at each stage of execution sequence, Quality of Service (QoS) range supported by individual components of the service. c) Resource level (R-context): this represents the contextual information related to the resources being
R-context
Provider Side context Infrastructure needed for the component to execute. For example: a J2EE component needs a JVM and a J2EE container to execute – it may further mention a specific RDBMS which it can work with etc.
QoS range that is supported by the provider component. Performance, availability and other guarantees provided by the component under appropriate resource allocation. This could even be additional information regarding behavioral guarantees such as type of algorithm used or the communication protocols supported in implementing the component. Resources needed by the provider to supply the QoS range it supports. This can include threads, CPU speeds, memory, DB connections etc.
Consumer side context Device and connectivity information of the consumer component, Language environment of the consumer etc. For example: PDA with limited bandwidth and display capabilities. QoS information that is needed by the consumer component. In addition the consumer can request for specific types of service such as the algorithm it wishes the provider to use for providing the service.
N/A
On the provider side, the set of customizations possible along with the existing configurations that the component needs for execution is also specified. A context specified as part of a service request is used by the matchmaking engine to select the appropriate service. Once a match is made the context is handed over to the service instance (which in our case starts execution by executing the first
Article No. 5
task of the workflow that the service has been mapped to). A context handoff accompanies the progress of the workflow from task to task and the context information is used both to bind to the appropriate services at variability points as well as to allocate resources to components for their executions. The architecture of the middleware used to achieve dynamic provisioning is described later. In order to instantiate a service, resources have to be allocated to components that perform the tasks specified in the workflow. For example a virtual machine may have to be started with some heap memory on a selected service providing host. This represents the actual execution of service (active form). To realize seamless execution of long running computations across variability points there is a need for a Meta Scheduler [11] that performs the following functions (a) Discovery (identify a matching service at a variability point), (b) Monitor resources (proactively prepare for transience of resources) (c) Matchmaking engine (decides the best resources that can be used for execution of the task). In addition, the Meta Scheduler also performs service aggregation and computes new QoS metrics at variability points. The discovery unit of the Meta Scheduler discovers and maintains the list of clients and the available resources in these clients so that computation hand-off can be transparently achieved. The monitor constantly obtains information about the availability of new resources due to joining of peers and non-availability of the resources due to transience caused by mobility. During the service request the Meta Scheduler composes services using the available resources. Changes in the environment can lead to changes in resource availability, which can in turn affect the QoS guarantees. Hence, at variability points the QoS metrics are recomputed. Figure 2 shows the components of the Meta Scheduler.
3)
4)
5)
resource availability anytime during the execution of a task. QoS Calculator: At variability points, the QoS metrics has to be re-calculated due to the change in environment which in turn depends on the availability of resources. This component is the core of the Broker. This takes the application objectives and translates them into resources and QoS guarantees for those resources. To do this, it needs detailed information about the resources available. This information is available through the Monitor. Discovery: This is a key component of our serviceoriented architecture. Service providers register with this component and consumer of the service query the directory service to find a service provider. The discovery unit maintains the list of services or resources. When resources are available service composition and aggregation is carried out by the Service Aggregation Unit. Service Aggregation Unit: At variability point the requirements of the user have to be aggregated based on available resources at that time.
Please note that failure of a pre-allocated resource during execution of a task using that resource is also a trigger for architectural adaptation; in such a case, control returns to the point before the failure occurred, the existing task is suspended, and the task re-executed by dynamic rebinding to an alternate resource at that variability point, as shown above. Based on the above concepts, our architecture for a pervasive computing system is as shown in Figure 3 below (also see [3]). The environment, service and resource layers, respectively, map directly to the E-, S- and Rcontexts. Please also note that the Meta Scheduler of Figure 2 will be located in the Requirements Management module of Figure 3. Users
Discovery unit
Monitor
Service aggregation based on new variability point
Requirements Management Module
Broker
Functional Adaptation Module
E-Context Management Module
QoS calculator
Workflow Repository
Environment Layer
Environment-Service Interface Manager Matchmaking engine
S-Context Management Module
Service Module
Role Management Module
Service Layer
Service-Resource Interface Manager
Figure 2. Meta Scheduler The description of each component of the Meta Scheduler is given below: 1) Monitor: This component is responsible for monitoring the availability of required services/resources. The components raise notification if there are deviations from the contracted grade of service. 2) Broker: This component is responsible for translating QoS objectives into appropriate resources to meet QoS guarantees [6]. It is also responsible for informing the client application of changes in
R-Context Management Module
Service Binding Module
Architectural Adaptation Module
Resource Layer
Figure 3. System Architecture
4. PUTTING IT ALL TOGETHER – EXECUTING AND ADAPTING A WORKFLOW
At every variability point, the output of the predecessor task, state of the workflow execution and overall state
Article No. 5
given by E- context serve as input to the new task that is to be executed. Based on these inputs dynamic service lookup and binding is done. Once the services are identified the task can be executed. The output of the task forms the input to the task that follows this task in the execution sequence. A schematic of the execution of the workflow is shown in Figure 4.
similar. In the case of X-Ray, however, the doctor decides to delegate the task to the Nurse#2 directly, who will then ensure that the X-Ray is carried out. The doctor then confers with a Specialist in order to interpret the results of the MRI Scan, after which he will prepare his diagnosis and enter it into the hospital’s computer system. Pervasive computing devices such as mobile phones, PDAs, pagers, etc., are needed here, since the doctor, nurses, pathologist, and specialist could be constantly on the move when they need to be contacted. START Doctor informs Pathologist
Doctor informs Nurse #1
Nurse #1 arranges for blood test & informs Pathologist Pathologist conducts blood test & reports to Doctor
Doctor informs MRI Technician
Doctor informs Nurse #2
Nurse arranges X-Ray with X-Ray technician
X-Ray technician conducts test & reports to Doctor
Figure 4. Execution of Workflow Realization of functional adaptation involves suspension of the task that requires adaptation and rollback to a checkpoint in the predecessor task. Further E-context information has to be updated to record the changes in user requirements. This is followed by execution of new workflow. This necessitates architectural adaptation which is triggered by availability of resources. On availability of resources R-context information is updated and the new task is set for execution. If the resources are not available, functional adaptation has to be carried out. Figure 5 gives a schematic of the various tasks to be performed for functional adaptation.
MRI Technician conducts MRI Scan & reports to Doctor
Doctor sends MRI Scan test results to Specialist for interpretation
Doctor prepares test results & enters them into the computer system
Specialist replies with interpretation
END
Figure 6. Workflow for Organizing Tests on a Patient Resources in our pervasive computing context could mean human resources such as doctor, nurses, etc., or physical resources such as the computing devices used by the doctors and nurses, hospital computer system, etc. An example of binding human resources would be to bind the role of Nurse #2 to a particular nurse in the hospital capable of providing the services of Nurse #2. An example of binding physical resources would be to allocate a doctor’s device to a particular PDA that the doctor owns. Hence the binding of roles to services, and dynamic binding of services to resources (human and physical), is as depicted in our conceptual model shown in Figure 6. That is, a service is provided by a role, and the service would also require the use of physical resources as well. This service is mapped to a task in the workflow. Examples of E-context would be: participant role (doctor, nurse, pathologist), names of devices used by the participants (mobile, PDA, pager, PocketPC), participant locations (nurse’s station, operating room, consulting room, outside hospital). Examples of S-context would be: architectural requirements (point-to-point messaging, publish-subscribe messaging), performance requirements (maximum time to be taken for each test, maximum time for reporting test results). Examples of R-context would be: screen size of a device, memory capacity, processing speed, facilities offered (paging, SMS, email).
Figure 5. Procedure for Functional Adaptation
5. AN EXAMPLE
Nurse #1 arranges for MRI & informs MRI Technician
Imagine a hospital that runs a series of tests on a patient – blood, X-Ray, MRI scan. These tests can be organized into a workflow execution sequence, as shown in Figure 6 below. Since the blood test is carried out by a skilled pathologist, the doctor notifies the pathologist and Nurse#1 separately, who will then coordinate with each other to carry out the test. The case for MRI scan is
As an example of dynamic service binding to resources, let us consider the following for the activity of X-Ray Technician conducting X-Ray and reporting to the doctor: (a) R-Context: PDA carried by doctor, (b) S-Context: point-to-point message from X-Ray technician to doctor, (c) E-Context: doctor inside/outside operating room. Hence if the system determines that the doctor is in an operating room, it would merely send an informational
Article No. 5
message to the doctor about the X-Ray, with a reference to the location in the hospital computer system where the doctor can obtain the X-Ray image. Otherwise, depending on the type of PDA that the doctor is carrying, the system can directly send the digitized X-Ray image to the doctor. Even in this rather simple example, several functional adaptation possibilities exist: (a) The order of tests could be changed, e.g., X-Ray test would need to be conducted before blood test, due to the lack of availability of a pathologist – this is an example of the trigger, (b) Instead of reporting to the doctor after every test, the hospital’s computer system could first be directly updated and the doctor could be notified after all tests are completed – this is akin to the introduction of a new service for summary notification, and is an example of the trigger (a) introduced earlier in Section 3, (c) The process could be further optimized by the appointment of a Head Nurse, who would report to the doctor on all the tests and coordinate with the nurses. Likewise, several architectural adaptation possibilities also exist in our running example: (a) Some users’ computing devices could be unreachable (i.e., disconnected), leading to a switch from point-to-point communication to publish/subscribe communication via a messaging middleware. For example, the lack of availability of the doctor’s device at that point in time could necessitate this change. (b) Alternatively, if publish/subscribe was the mechanism originally chosen by the users and if the message traffic on the middleware exceeds a performance threshold, it may be appropriate to dynamically switch to point-to-point communication for certain classes of messages (such as the doctor’s interaction with the specialist).
6. CONCLUSIONS WORK
AND
FUTURE
In this paper, we have presented our approach for building adaptive pervasive computing systems via the adoption of service-oriented computing principles. We have shown how workflows can be modeled, and how tasks can be executed as part of workflow execution, in such systems. Based on these ideas, we have shown how adaptation – a common feature in pervasive computing systems – can be modeled. In particular, we have shown that adaptation is of two key types – functional and non-functional (architectural) – and we have shown how both these types can be modeled in our approach. For developing a proof-of-concept implementation of our proposal, we are investigating the use of Jini (http://www/jini.org/), which is a Java-oriented serviceoriented system. In Jini, Java interfaces are used as the basis for syntactic conformance along with distributed polymorphism which can be extended with contexts to achieve semantic conformance for functional adaptation. Moreover, being in a Java environment where the source code of the JVM is available helps us integrate the context seamlessly and allocate resource dynamically for architectural adaptation.
Our future work therefore consists of completing the implementation of our system architecture and
demonstrating it on real-life examples. We are also investigating the development of a description language for describing functional and non-functional aspects of services, similar to Scooby [9], and leveraging from our earlier work [1]. We are also investigating policy-driven techniques for implementing adaptation [5], as well as resource contract-based mechanisms for binding services to resources [6].
7. ACKNOWLEDGEMENTS
The authors wish to thank Zakaria Maamar and Giovanna DiMarzo Serugendo for their feedback. The authors also wish to thank the anonymous referees, whose feedback improved the quality of the paper. The first author also wishes to thank his manager, K. Muralidharan, for supporting his work. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both. Other company (i.e., nonIBM), product and service names may be trademarks or service marks of others.
REFERENCES
[1] Bellur, U., and Narendra N.C., Towards a Programming Model and Middleware Architecture for Self-Configuring Systems. Proceedings of 1st International Conference on Communication Systems Software and Middleware (COMSWARE 2006), to appear [2] Dey, A.K., Abowd, G.D., and Salber, D., A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. HumanComputer Interaction Journal, Special Issue on ContextAware Computing, 16, 1, 2001. [3] Bellur, U., and Narendra, N.C., Towards Service Orientation in Pervasive Computing Systems. In Proceedings of International Conference on Information Technology: Coding and Computing (ITCC’05), Las Vegas, Nevada, USA, 2005; also available from http://dx.doi.org/10.1109/ITCC.2005.280
[4] Maamar, Z., and Narendra, N.C., Ontology-based Context Reconciliation in a Web Services Environment: From OWL-S to OWL-C. In Proceedings of WSABE 2004; available from http://www.agentus.com/WSABE2004/program/Maamar.p df
[5] Mukhi, N., Plebani, P., Silva-Lepe, I., and Mikalsen, T., Supporting Policy-Driven Behaviors in Web Services: Experiences and Issues. In Proceedings of International Conference on Service-Oriented Computing (ICSOC) 2004 [6] Rigole, P., Berbers, Y., Holvoet, T., Component-based Adaptive Tasks Guided by Resource Contracts. In Proceedings of Workshop on component-oriented approaches to context-aware systems in conjunction with the 18th European Conference on Object-Oriented Programming, ECOOP, Oslo, Norway, June 14-18, 2004; also available from http://www.cs.tcd.ie/COA-CAC04/submissions/rigole.pdf
[7] Satyanarayanan, M., Pervasive Computing: Vision and Challenges. IEEE Personal Communications, 2001
Article No. 5
[8] Satyanarayanan, M., The Many Faces of Adaptation. IEEE Pervasive Computing, July-September 2004 [9] Robinson, J., Wakeman, I., and Owen.T., Scooby: Middleware for Service Composition in Pervasive Computing. In Proceedings of 2004 MPAC Workshop; also available from http://smartlab.cis.strath.ac.uk/MPAC/2004/MPAC2004_P apers/MPAC22-robinson.pdf
[10] Singh, M.P., and Huhns, M.N., Service Oriented Computing. Wiley-VCH Publishers, 1st Edition, ISBN 0470-09148-7, November 2004 [11] Nainwal, K.C., Lakshmi, J., Nandy, S.K., Narayan, R., Varadarajan, K., A Framework for QoS Adaptive Grid Meta Scheduling. In Proceedings of First International Workshop on High Availability of Distributed Systems (HADIS2005), Workshop at DEXA 2005, August 22-26, 2005, Copenhagen, Denmark
Article No. 5
