Pers Ubiquit Comput (2008) 12:143–153 DOI 10.1007/s00779-006-0105-4
O R I G I N A L A RT I C L E
A resource and context model for mobile middleware Sten L. Amundsen Æ Frank Eliassen
Received: 19 May 2006 / Accepted: 23 June 2006 / Published online: 31 October 2006 Springer-Verlag London Limited 2006
Abstract Mobile computing systems should be selfmanaged to simplify operation and maintenance plus meet user’s expectation with respect to Quality of Service (QoS). When architecting self-managed mobile computing systems, one must take a holistic view on both QoS management and the entities in the mobile environment. This paper presents a novel model that includes both resources and context elements. To illustrate the usefulness of the model, it is applied to a video streaming application by: (1) modelling context elements and resources in the environment, (2) specifying context dependencies and QoS characteristics of the application, and (3) designing weakly integrated resource and context managers. We describe a middleware that uses the developed managers when evaluating context dependencies and predict offered QoS of alternative implementations of the application. In order to select the one that can operate in the current environment and that best satisfies given user preferences. Keywords Context model Resource model Mobile middleware QoS management Context management QoS specifications
S. L. Amundsen (&) F. Eliassen Simula Research Laboratory, Network and Distributed Systems, P.O. Box 134, 1325 Lysaker, Norway e-mail:
[email protected] URL: http://www.simula.no/departments/networks/ F. Eliassen e-mail:
[email protected]
1 Introduction Application developers have embraced components as the most suitable software entity for developing mobile computing systems. The focus within component based software engineering has been on modelling the functional properties and developing suitable execution environments [1]. The research community, on the other hand, has worked on architectures and mechanisms for dynamic adaptation of content, middleware services, and applications (e.g., the mobile middleware platforms ANSAware [2], Odysse [3], BARWAN [4], ReMMoC [5], MobiPADS [6], and MADAM [7]). Researches have also started to take a more holistic view on computing systems to address the increasing complexity system administrators face as computing systems are becoming tighter interconnected and opened up for connections from Internet and wireless communication systems. The vision is to make the computing system and its building blocks self-managed [8], and free system administrators from the details of configuration, operation, and maintenance, plus provide users with services that meet their expectations to performance and reliability. A self-managed system maintains and adjusts itself in the face of changing components, loads, system failures, and user demands. Properties of such a system are: self-configuration, selfoptimisation, self-healing, and self-protection. To achieve this existing concepts and technologies must be combined to a system architecture that has the desired self-management properties [9, 10]. One also needs to develop generic models and mechanisms that apply across all building blocks. The reflectiveness of dynamic middleware platforms is such a mechanism, for example a reflective J2EE server [11].
123
144
We argue that quality of service (QoS) management of component based applications is part of the selfconfiguration and self-optimisation properties. Hence, the need for taking a holistic view on technologies and mechanisms also applies to QoS management support in middleware. Our work addresses this problem, which has resulted in a new reflective component based architecture that integrates QoS-specific elements [12, 13]. Mobile terminals and wireless communication systems available today offer no QoS guarantees, so adaptation mechanisms are needed to maintain QoS. Work on dynamic mobile middleware have either used resource information (e.g., [2, 3, 14]) or context information (e.g., [5, 6, 15]) to decide the correct adaptation of the application and middleware. In more recent work [7], both resource and context managers have been included in the mobile middleware. The result is a powerful design, but since the holistic view is missing the managers are designed as two enclosed entities. In sum, existing architectures and designs limit the QoS management mechanisms to adapt the application to either changes in context or fluctuations in resource availability, and not according to a larger picture of the environment. Hence, the remaining research problem is: how to combine resource and context management mechanisms and handle resource and context information in way that contributes towards the self-management vision? We apply the scenario analysis method to identify the requirements to and validate the design of resource and context managers for a mobile middleware. The combination of the streaming application domain and the mobile technical domain, gives a representative scenario with respect to QoS and context management due to the inherent QoS constraints of the streaming application, the dynamic QoS characteristics of the radio channel, and the heterogeneous execution environment. Resource and context models of the application’s environment are the foundation for resource and context management, as these models take into account the various entities in the environment. In this paper a combined resource and context model is presented as an answer to the defined research problem. It builds on ideas we introduced in [16], and is now sufficiently expressive to provide the semantics required to develop domain specific resource and context models that (1) guide the design of integrated resource and context managers, and (2) ensures correct interpretation of context dependencies and QoS specifications. To validate the designed resource and context managers, they are plugged into our mobile middleware, QuAMobile (QUality of service aware component Architecture for MOBILE computing), and used
123
Pers Ubiquit Comput (2008) 12:143–153
in the processes of choosing an optimal application configuration. This demonstrates that the QoS and context dependency specifications are interpreted as intended by the application developer. Furthermore, our experience shows that the resulting resource and context managers can share code and provide consistent resource and context information to other QoS management mechanisms. In the following we start by discussing related work. Section 3 describes our QoS-aware mobile middleware prototype. Section 4 presents a combined resource and context model, which in Sect. 5 is applied to a scenario of a video streaming application for mobile terminals. Validation and qualitative assessment of the combined model and the resource and context manager implementations is presented in Sect. 6. Finally, in Sect. 7 we provide some concluding remarks.
2 Related work Mobile middleware platforms that adapt middleware services, applications, or support self-adaptive applications, must have processing and delivering mechanisms for either resource or context information. For instance, Odysse [3] delivers resource information about changes in the mobile communication system to interested applications. Similarly the architecture in CARISMA [15] defines wrappers, to sensors and monitors, which encompass post-processing with filters and event messages that deliver context information to the applications according to triggers/policies set by the applications. ReMMoC [5] also gather context information about available services (detected by standard service discovery protocols) without aggregation. It uses the information to control the configuration and adaptation of the remote binding protocol. MobiPADS [6] is taking this a step further and has an event notification model that supports hierarchical composition of event messages, i.e., a particular combination of information about network, memory, and Central Processing Unit (CPU). The BARWAN project [4] adds aggregation to the basic processing and delivery mechanisms, and combines context information about the execution environment with resource information about the wireless network. This highlights the importance of combining both resource and context information for controlling the adaptation in the mobile domain. None of these mobile middleware platforms employ a general model of resources and context elements. The result is inflexible applications and middleware services that cannot use new resources and context
Pers Ubiquit Comput (2008) 12:143–153
elements as they appear in the environment. Furthermore, without a combined model for resource and context information, inter-working between the managers will be implementation specific. A general resource model has been implemented in OpenORB, an enterprise middleware platform [17]. The resource model positions resource representatives in a hierarchy; physical resources at the bottom and logical resources that encompass several resources at the top. The strength of a hierarchical resource model is that resource requirements can be expressed at the granularity level suitable for the application, but the model does not easily lend itself to analysis models of the environment or resource management mechanisms. This is, however, addressed in the General Resource Model (GRM) specified by the Object Management Group (OMG) [18]. Due to the generality of the model, GRM is chosen as the starting point for the combined resource and context model presented in this paper. Context models have been developed for AmbiSense [19], ConFab [20], and UbiComp [21]. In general these models have shown to be useful for classification of context elements in the environment, and for storage of context information according to context types. Though, resources and their QoS characteristics are not supported. The MADAM project has made a distinction between context elements and resources, by employing two models (one context model and one resource model). The result is a powerful and flexible design, but since the applications are configured and adapted to a combination of the user’s and the system’s context, it lacks resource QoS characteristics in the model and mechanisms for processing, delivering, and storing resource QoS characteristics. In sum, related work highlights the need for a (general) combined resource and context model. It should include concepts that are required in a domain
145
model of resources and context elements. This model must again be easy to apply to the design of resource and context managers and other application analysis models.
3 QuAMobile: a QoS-aware mobile prototype Before presenting the combined model we describe our dynamic mobile middleware, to motivate for a combined resource and context model. QuAMobile implements an open reflective component architecture. To make the middleware executable on mobile terminals and large servers, the architecture has a small core (see Fig. 1), with hooks where QoS management mechanisms are inserted as plug-ins [12, 13]. The architecture is geared towards context- and QoSawareness, making resource and context management mechanisms the basis on which other QoS management rely on. Some of the resource and context management mechanisms ought to be shared. For instance, reasoning logic and storage facilities should cover both resources and context elements to give other QoS mechanisms a complete picture of the environment at a suitable abstraction level and of high quality (include trends, filtered against hysteresis, etc.). Likewise, policies for controlling the submission of event notifications are required, to ensure a correct interpretation of the gathered data and a balance between responsiveness and stability. To enforce the required level of integration, while maintaining a clear allocation of responsibility for admission control, resource reservation, monitoring, and sensors, the context manager inherent the resource manager. QuAMobile takes advantage of context and resource information when selecting a configuration of the application suitable for the current context, resources available, and that meets the user’s QoS
Fig. 1 Core architecture
123
146
requirements. The basis of this approach is to model the application as service types and let the middleware select among alternative implementations of these types. The alternative implementations, each with different QoS characteristics and/or context dependencies, are provided by application developers and deployed in the repository together with associated service plans. Service plans serve four purposes: (1) provide the link between a service type and an implementation of the type; (2) specify service composition and parameter configuration of the implementation; (3) specify dependencies to context elements; and (4) describe the QoS characteristics of the implementation. By applying the concepts specified in the combined model, resources and context elements in the environment are modelled. From this the resource and context managers are designed, i.e., wrappers to sensors and monitors, post-processing, reasoning logic, and storage facilities for resource and context information. Context dependencies and QoS characteristics are also specified according to the model of the environment. In sum this ensures that the middleware gather the required data, process, store, and use it as intended by the application developer when choosing an application configuration that is suitable for the environment and optimal with respect to the user’s QoS requirements. QoS requirements are specified in the form of utility functions, which give users the means to specify their preferences at a high abstraction level. When a user requests a service, QuAMobile invokes the service planner plug-in (see Fig. 1) with the service type name and the utility functions. The planner asks the broker to search the repository for plans that implement the requested type. Plans returned specify component compositions and parameter configurations, which the service planner combines into alternative application configurations. When the service planner asks the context manager for information about the environment, it shall receive a data set with both context and resource information. The service planner uses this information to (1) filter application configurations that has dependencies to context elements that currently is not in the environment, and (2) predict the end-to-end QoS characteristics of the application configurations (using the QoS prediction functions in the service plans [22]), and (3) choose the application configuration that best meets the user’s QoS requirements. For each dependency the application configuration has to context elements in the environment and to relevant resource QoS dimensions, the service planner sets triggers in the
123
Pers Ubiquit Comput (2008) 12:143–153
context manager. It is the design of the managers that ensures a correct trigger setting, according to some policy for the target domain. The service planner uses the resource manager to check if the resources can sustain the additional load and to make resource reservations, if supported by the operating system or the communication system. Next, the configuration manager uses the selected application configuration to instantiate the requested service. Should the context change or the resource load fluctuate, triggers in the integrated context and resource managers will send an event message to the service planner. If the user’s QoS requirements are no longer met, the service planner chooses an alternative application configuration (if available). It is the adaptation manager that is responsible for reconfiguring the running application according to the chosen application configuration. QuAMobile and the management plug-ins are implemented in Java. Service plans for the components, service compositions, and parameter configuration of the video streaming application are deployed in eXtensible Markup Language (XML) files, and the service types in Web-Service Description Language (WSDL) files. User service requests, with QoS requirements and service type name, are entered into a Web-based presentation layer, which through an applet and a User Datagram Protocol (UDP) socket interact with the business layer where QuAMobile components are created and executed.
4 Combined resource and context model The objective of a context and resource model is to define concepts and their relationships that are useful in analysis models of the environment and the resource and context management mechanisms [20]. To design the combined model, we start by studying existing resource and context models. Two resource models for middleware platforms have been identified [17, 18], where the General Resource Model (GRM) [18] from OMG is considered most suitable as it is the most comprehensive of the two. GRM includes a core model that can be applied to all resources. It makes a distinction between resource types and their run-time instances, enabling designers to model unknown resources at design-time. For the context model we seek a model that supports classification of the different entities in the environment. This covers entities with static and dynamic properties plus logical and physical entities that offer services. Existing context models (e.g., [19, 20, 23, 24]) do not meet our needs, as they are designed for location and presence
Pers Ubiquit Comput (2008) 12:143–153
information. Furthermore, properties of the entities are not included in these models. Hence, for the context part of the combined model new concepts must be defined. The environment is modelled as a set of entities. If there is a dependency between an Entity and the application, the entity consists of a ContextElement part. In case the entity offers one or more services to the application it also consists of a Resource part. To view both context elements and resources as parts of an entity is the crux of the combined model. For instance, the physical entity mobile communication system will be modelled with a context element wireless network and the resource service communication. Similarly, a file system in a ubiquitous system has the context element local storage and the resource services read and write. Albeit modelled as parts of the same entity it is important that the properties of the resources are not modelled as context properties since resource information is used in QoS prediction, admission control, and QoS monitoring (i.e., QoS must by quantified using numbers and units). Hence, the model separates between the properties of a context element and properties of a resource. ContextProperty associated with the context element represents quantifiable properties, where ContextValue defines a specific quantification of the context property. A resource provides one or more ResourceServices. Often the service is running in the operating system. Thus, there are one or more instances of the resource, ResourceInstance, and its service, ResourceServiceInstance. QoSCharacteristics represents the quantifiable quality properties of a resource service. QoSValues defines the specific quantification of the QoS characteristics of an instance of the resource service. Figure 2 shows all these concepts and the associations between them.
147
Fig. 2 Combined resource and context model
specification, context values, and resource QoS values is described. 5.1 Video streaming scenario Recent advances in mobile communication systems have enabled the deployment of video streaming applications in the mobile domain, which raises several new challenges in order to achieve best possible playback at the client side. In our scenario the clients are executing on: home theatres, laptops, and Personal
5 Applying the combined resource and context model The concepts defined in the combined resource and context model provides a suitable framework for dealing with the complexity of dynamic heterogeneous environments like the mobile domain. To demonstrate the usefulness of the general combined model it is applied to a scenario of a video streaming application for the mobile domain (see the activities in Fig. 3). We model the resources and context elements in the target environment, provide an example of a context and QoS characteristic specification, and describe the design of resource and context managers pluggable into a QoSaware mobile middleware. Lastly, the usage of the
Fig. 3 Applying the general model
123
148
Digital Assistants (PDAs), which are connected to the Internet over the access networks: fixed Local Area Network (LAN), Wireless LAN (WLAN), and General Packet Radio Service (GPRS). IP mobility management enables the mobile terminals, PDAs and laptops, to roam seamlessly between access networks while receiving the video stream. Figure 4 shows an overview of the system. The main challenge, with respect to QoS, is to satisfy user preference and efficiently exploit available resources in different system contexts, when network conditions are changing and terminals roam between access networks. Each user has their own opinion of what high quality video is, e.g., different values for user QoS dimensions like detail level and smoothness. This may result in parallel video streams with different characteristics and requirements. Hence, the application must be adapted to the user’s QoS requirements and the capabilities of all the resources and context elements along the data path from server to client. QoS management and adaptation mechanisms work together to decide when, what, and how to adapt the video streaming application. The foundation for choosing an application configuration is end-to-end QoS prediction and allocation. In our approach QoS is calculated by a set of functions that establish relationships between QoS at different abstraction levels (context-resource, application, and user). These functions take data about resources and context elements as arguments. 5.2 Model of the environment First the combined general model is applied to model the environment. This is done in two steps: (1) suitable resource and context types are defined for classification of entities, and (2) property types and resource QoS characteristics are specified. OMG has in [18] defined three resource types, which are general enough and sufficient for classifying the
Fig. 4 System overview
123
Pers Ubiquit Comput (2008) 12:143–153
resources in the video streaming scenario. The three resource types are: (1) Processor: physical computational resource that is capable of storing and using code and data; (2) Communication: logical resource that provide connectivity and transport of bits between two locations; and (3) Device: logical or physical resource that is not classified as processor or communication resources. Figure 5 shows the three resource types including the ResourceInstance interface that all types implements. Likewise, one must have context types for classification of the context elements in the environment. In general, context information is data about the user environment, but in the video streaming scenario only data about the technical context elements is required. We have not found any general definitions of context types in related work, and therefore define our own types. The result is seven context types, shown in Fig. 5: (1) LocalComputation: local physical entity for computing and temporarily storing of data and code, e.g., CPU and memory; (2) PermanentStorage: logical entity for storing and retrieving permanent data and content, e.g., disc; (3) RemoteStorage: logical entity for storing and retrieving permanent data and content, e.g., a streaming server; (4) Network: physical entity representing an access network, such as GPRS packet switched; (5) LocalDisplay: physical entity for presenting computation result or content, e.g., screen or ASCII display; (6) UserInput: physical entity for entering of user data and QoS requirements, like a touch screen or a keyboard; and (7) ExecutionEnvironment: logical entity the application and middleware is running on, i.e., the combination of the operating system, virtual machine, and interpreters. The notion of context and resource types is included in the combined resource and context model (see Fig. 2). Furthermore, since the model specifies a part of association between resources and context elements of the same entity, the context type inherent the resource type. Hence, the three context types LocalComputation, Network, and RemoteStorage inherit the resource types Processor, Device, and Communication. To model the QoSCharacteristics and ContextProperties of the classified Resources and ContextElements, we adhere to the Uniform Modelling Language (UML) profile for QoS modelling [25]. It is a formal specification that defines the required terms and meta-models, which ensures that models can be integrated into other UML compliant design models, software development methods, and tools. In addition we introduce two new UML stereotypes; ContextProperty represents quantifiable properties of the context element, where PropertyType is the quantification of one context
Pers Ubiquit Comput (2008) 12:143–153
149
Fig. 5 Resource and context types
property. To show how the concepts of the general model and stereotypes are applied, we use the context element network and the resource communication as an example (see Fig. 6). 5.3 Context dependencies and QoS characteristics specification The model of the environment specifies resources and context elements and their QoS characteristics and
Fig. 6 Example of QoS characteristics and context properties
properties. Specifications of the application’s QoS characteristics and dependencies to context elements must be related to the model of the environment. To enable the middleware to check if an application configuration is suitable for the current context, and predict end-to-end QoS characteristics for the resources available. When the middleware is QuAMobile context dependencies and QoS characteristics are specified using the service plan, which the service planner plugin (see Fig. 1) employ in the process of choosing an application configuration. To illustrate the above feature we use the distributed component RTP_TRFCTransport, which is responsible for the transportation of video frames from the video server to the client. Figure 7 shows context dependencies, QoS predictor functions, and QoS requirements associated to the component as it is specified in the application design model. A dependency is here a constraint associated with a property type (of the context element), and is included in the UML design model of the application, using the QoSContext stereotype. The QoS prediction function is used by the middleware (i.e., the service planner plugin) to calculate the QoS value along an application QoS dimension. Input to the function is context values and QoS values (for the classified context elements and resources). To include these functions in the application design model, we use the QoSOffered stereotype. Both QoSContext and QoSOffered are stereotypes defined in the QoS constraint package described in the UML profile for QoS [25]. We have extended the constraints package to include QoSRequirement, which
123
150
Fig. 7 Context dependencies and QoS characteristics specification
describes the levels of QoS a service need to fulfil (e.g., min and max predicted QoS at application and user levels). The Object Constraint Language (OCL) is used to specify the constraints (context dependencies and QoS values), and to relate the QoS prediction functions to property types, resource QoS dimensions, and other QoS prediction functions. By using these stereotypes and OCL constraints, we were able to develop a generator that automatically maps from UML models down to the service plans. This simplifies significantly the software engineering of applications with QoS requirements and context dependencies. 5.4 Resource and context managers design The QuAMobile core architecture places one requirement on the design of the resource and context manager plug-ins; all operations specified by the IContextManager and IResourceManager interface classes shall be implemented. Design decisions like tight or weak integration of resource and context management mechanisms are left to the plug-in designer. Resource and context managers must gather, process, trigger notifications, and store QoS and context values. Figure 8 shows the design that we choose to use in our work. The two managers share post-processing, reasoning, and storage functionality. Storage objects for QoS and context values are in the package contextElements, which contains instances of the classes
123
Pers Ubiquit Comput (2008) 12:143–153
shown in Fig. 5. These objects form a repository that can be extended with statistical analysis tools, for trends and quality estimation of the values. Wrappers and post-processing are configured by the resource and context managers to handle and pass on the QoSDimensions and PropertyTypes specified in the model of the resource QoS characteristics and context properties, previously shown in Fig. 6. Triggers for delivery of notification messages about changes in the environment are set by invoking the setTrigger( ) operation on the context manager, with the parameters resource QoS dimensions, context property types, and a callback reference of type IServicePlanner. For validation and simulation of changes in the environment, data about each entity are fed into the wrappers using a test tool. The tool’s graphical user interface, depicted in Fig. 8, includes text, values, and units for all property types and resource QoS dimensions in the video streaming scenario. Even though the resource and context managers were easy to implement, one should not underestimate the technical challenges associated with developing sensor and monitoring software. It is important to note that new resources and context elements may appear in the environment. Thus, there must be some means to reconfigure the resource and context managers with new resource and context types. There are many ways to design this reconfiguration, e.g., [17, 26], but this is a separate challenge not discussed here. 5.5 Exploiting context information in service planning To illustrate run-time usage of the context and QoS specifications and the integrated resource and context managers (all adhere to the semantics of the general and domain specific resource and context model), we describe how the context dependencies, QoS characteristics, and QoS requirements for the RTP_TFRCTransport component are exploited during service planning. Assume that the user has a laptop connected to a LAN when requesting the play out of a video. After some time the user disconnects from the LAN and moves over to WLAN. Properties of context elements and resources in the two system contexts are listed in Table 1. Changes in context and resource capacities are indicated with an arrow. When choosing the initial configuration for the LAN case, the service planner gets resource QoS values and context values from the context manager and exploits the context dependencies, QoS characteristics, and QoS requirements, specified in the service plans to
Pers Ubiquit Comput (2008) 12:143–153
151
Fig. 8 Weak integration of resource and context managers
calculate the utility of each configuration alternative. For the transport component alternative depicted in Fig. 7, the LAN case satisfies the context dependencies of the component, and the QoS of this alternative is calculated to pckRate = 83 kpck/s and startupTime = 210 ls. When the user disconnects from the LAN and moves over to WLAN, triggers sends a notification message. In response to this the service planner gets updated resource QoS values and context values from the context manager. Table 1 indicates what values that have changed. For the RTP_TFRCTransport component we observe that its context dependencies are also satisfied in the WLAN environment. Recalculation of the QoS of this alternative yields pckRate = 1.2 kpck/s and startupTime = 770 ls. These values are used by the service planner in recalculation
of the end-to-end QoS and utility of current configuration of the video streaming application. Whether this implementation alternative of the transport service will still be used in the WLAN environment, depends on the new utility value. If the utility becomes too low, the service planner re-plans the application and forwards a new application configuration to the adaptation manager plug-in.
6 Validation and assessment Tests of the implemented resource and context managers showed a good performance; less than 2 ms from entering data to storage. This is as expected since the longest signal path from wrapper to storage is five objects. Hence, the emphasis was instead placed on
123
152 Table 1 Context and resource information
Pers Ubiquit Comput (2008) 12:143–153
Context elements
Properties
LAN
LocalDisplay – ‘‘ – LocalComputation – ‘‘ – Network – ‘‘ –
Resolution Colour RamSize UtilisationFactor MobilityMgmt Layer2SDUsize
1,400 · 1,050 pixels 32 bit colour 1 GB 1 MobileIPv4 1,500 B
fi 2,312 B
Resources
QoS characteristics
Processor – ‘‘ – Communication – ‘‘ – – ‘‘– – ‘‘ –
RemaningCPU RemainingRAM DataRate BER Coverage Availability
50% 300 MB 125 MBps 10–6 p 1p 0.9999 p
fi fi fi fi
validating the generality of the concepts in the combined resource and context model. We modelled in detail the target environment of our scenario, and designed the integrated managers to support a total of 26 properties. Similarly the context dependencies and QoS specifications, i.e., service plans, of the video streaming applications were defined in detail for a total of 266 alternative application configurations [13]. This makes the context dependency filtering and QoS predictions the main task for the management plug-ins. From the validation we showed that only application configurations suitable for the environment were considered and of those the one giving highest utility to user QoS ratio was always chosen. The combined resource and context model is designed to answer the research problem stated in Sect. 1: how to combine resource and context management mechanisms and handle context and resource information in way that contributes towards the selfmanagement vision? This problem is based on the argument that the self-management vision [8] is achieved by applying generic models and mechanisms across all the building blocks in the computing system [9, 10]. From applying the general combined resource and context model and validating the implementation we make the following observations. The combined model helps designers with classification of all entities in the environment and modelling of both resource QoS characteristic and context properties. It simplifies the design of the resource and context managers by allowing for integration of resource and context managers. Most importantly the resulting resource and context manager provide during run-time a complete data set of all relevant resources and context elements in the environment. This ensures that the mobile middleware has a holistic view of the environment and can find suitable configurations and optimise according to the context and resource
123
WLAN
3 MBps 10–2 p 0.89 p 0.995 p
availability. One possible weakness in the validation is that the model is applied to only one scenario. We believe that this weakness is limited, since the mobile domain is associated with a broad range of different resources and context elements and the streaming domain has stringent QoS requirements. Furthermore, there are no limits to the definition of an entity in the combined resource and context model. An entity can range from traditional hardware resources to logical entities like services in a ubiquitous computing system. Hence, it is our assessment that the combined model successfully answers the research problem and contributes towards the self-management vision and in particular QoS management aspects of self-configuration and self-optimisation.
7 Conclusions This paper argues that there is a need to take a holistic view on technologies and mechanisms to achieve the goal of self-configuration and self-optimisation. The scope was limited to context- and QoS-management, which we argue is essential in achieving the self-management property. To answer the defined research problem, we introduce a combined resource and context model that specifies general concepts needed when preparing a domain specific model of the environment. This model is again applied to the design of resource and context managers and specification of context and QoS characteristics of an application. The crux of the proposed combined model is that resource services are provided by the same entities as the context elements are part of. Thus, models of the environment, context dependencies and QoS characteristics specifications, and resource and context managers should include both the QoS characteristics of the resources and properties of the context elements.
Pers Ubiquit Comput (2008) 12:143–153
The implementation and assessment of the resource and context managers showed that the design was both useful and easy to apply on an application with dependencies to context elements and QoS requirements. It is also evident that the presented resource and context management design is one of many solutions. Though, our validation shows that a dynamic mobile middleware platform will benefit from applying a combined resource and context model, since this gives the QoS management mechanisms a complete overview of all relevant entities in the environment and their non-functional properties. Acknowledgments The video streaming scenario that is used to define (realistic) requirements to a dynamic mobile middleware platform has been developed in collaboration with Associate Professors Pa˚l Halvorsen, and Carsten Griwodz from the Informatics department at the University of Oslo, and Post Doc. Ketil Lund from Simula Research Laboratory.
References 1. Emmerich W (2002) Distributed component technologies and their software engineering implications. In: Proceedings of the 24th international conference on software engineering. ACM Press, New York, pp 537–546 2. Davis N, Friday A, Blair GS, Cheverst K (1996) Distributed systems support for adaptive mobile applications. ACMBaltzer Mobile Net Appl 1(4):399–408 3. Noble BD, Satynarayanan M, Narayanan D, Tilton JE, Walker KR (1997) Agile application-aware adaptation for mobility. In: Proceedings of the 16th ACM symposium on operating systems principles. ACM Press, New York, pp 276–287 4. Brewer EA, Katz RH, Chawathe Y, Gribble SD, Hode T, Nguyen G, Stemm M, Henderson T, Amir E, Balakrishnan H, Fox A, Padmanabhan VN, Seshan S (1998) A network architecture for heterogeneous mobile computing. IEEE Pers Commun 5(5):8–24 5. Grace P, Blair GS, Samuel S (2005) A reflective framework for discovery and interaction in heterogeneous mobile environments. ACM SIGMOBILE Mobile Comput Commun Rev 9(1):2–14 6. Chan ATS, Chuang S (2003) MobiPADS: a reflective middleware for context-aware mobile computing. IEEE Trans Softw Eng 29(12):1072–1085 7. The EU project—Madam (2005) Theory of adaptation—specification of the MADAM core architecture and middleware services, sixth framework programme, D2.1 8. Kephart JO, Chess DE (2003) The vision of autonomic computing. IEEE Comput 36:41–52 9. Kephart JO (2005) Research challenges of autonomic computing. In: Proceedings of the 27th international conference on software engineering. ACM Press, New York, pp 15–22 10. Parashar M, Hariri S (2005) Autonomic computing: an overview. International workshop unconventional programming paradigms, Lecture Notes in Computer Science, vol 3566. Springer, Berlin Heidelberg New York, pp 247–259 11. Huang G, Liu T, Mei H, Zheng Z, Liu Z, Fan G (2004) Towards autonomic computing middleware via reflection. In: Proceedings of the 28th international computer software and
153
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
applications conference. IEEE Computer Science, USA, pp 135–140 Solberg A, Amundsen S, Aagedal J, Eliassen F (2004) A Framework for QoS-aware service composition. In: Proceedings of 2nd ACM international conference on service oriented computing Amundsen S, Lund K, Griwodz C, Halvorsen P (2005) QoSaware mobile middleware for video streaming. In: Proceedings of the 31st EUROMICRO conference on software engineering and advanced applications. IEEE Computer Society, USA, pp 54–61 Lu S, Bharghavan V (1996) Adaptive resource management algorithms for indoor mobile computing environments. In: Proceedings of the ACM SIGCOMM ‘96 conference on applications, technologies, architectures, and protocols for computer communication. ACM Press, New York, pp 231– 242 Capra L (2003) CARISMA: context-aware reflective middleware system for mobile applications. PhD Thesis, University College London, University of London Lundesgaard S, Eliassen F (2006) Combined resource and context model for QoS-Aware mobile middleware. In: Proceedings of the 19th international conference on architecture of computing systems, Lecture Notes in Computer Science, vol 3894. Springer, Berlin Heidelberg New York, pp 84–98 Duran-Limon HA, Blair GS (2003) The importance of resource management in engineering distributed objects. Lecture Notes in Computer Science, vol 1999/2001. Springer, Berlin Heidelberg New York, pp 44–60 Object Management Group (2005) UML profile for schedulability, performance, and time specification, v1.1, OMG formal/05-01-02 Watt S, Myrhaug HI, Whitehead N, Yakici M, Bierig R, Nuti SK, Cumming H (2004) An ambient, personalised, and context-sensitive information system for mobile users. In: Proceedings of the 2nd European Union symposium on ambient intelligence. ACM Press, New York, pp 19–24 Hong JI, Landay JA (2004) An architecture for privacysensitive ubiquitous computing. In: Proceedings of the 2nd international conference on mobile systems, applications, and services. ACM Press, New York, pp 177–189 Christopoulou E, Goumopolos C, Kameas A (2005) An ontology-based context management and reasoning process for UbiComp applications. In: Proceedings of the joint conference on Smart objects and ambient intelligence. ACM Press, New York, pp 265–270 Lundesgaard S, Lund K, Eliassen F (2006) Utilising alternative application configurations in context and QoS-aware mobile middleware. In: Proceedings of distributed applications and interoperable systems. Lecture Notes in Computer Science, vol 4025. Springer, Berlin Heidelberg New York, pp 228–241 Corradi A, Montanari R, Tibaldi D (2004) Context-based access control for ubiquitous service provisioning. In: Proceedings of the 28th international computer software and applications conference. IEEE Conference Proceedings, pp 444–451 Chen G, Kotz D (2000) A survey of context-aware mobile computing research. Technical report TR2000-381, Darthmouth Computer Science Object Management Group (2004) UML profile for modelling Quality of Service and Fault tolerant characteristics and mechanisms. OMG adapted specification da Rocha RCA, Endler M (2006) Context management in heterogeneous, evolving ubiquitous environments. IEEE Distributed Syst 7(4), Online
123
