Integrated Management of Smart Spaces Sven VAN DER MEER 1, Brendan JENNINGS 1 1 Waterford Institute of Technology, Telecommunication Software and Systems Group Cork Road, Waterford, Ireland Tel: +353 51 302925, Fax: + 353 51 302901, Email: vdmeer@tssg.org 1. Introduction Abstract: This paper introduces the M-Zones (www.m-zones.org) approach for the integrated management of networks, distributed services and applications within Smart Spaces. The main objective of this approach is to facilitate the realisation of software, systems and services that address composition, scalability, reliability and robustness and self-adaptation. It focuses on middleware for management, control and use of fully distributed resources. The term integrated management is used to highlight the fact that the approach is founded on the unification of existing middleware and management components, not their replacement. Current approaches to Smart Spaces and their management are characterised by the interworking of separate components and systems; we argue that there is a pressing need for the integration of management and middleware concepts. Smart Space applications need to be prepared to be used and operated in a stable, secure and efficient way. To realise this objective for long-time operation, a Smart Spaces, individually and collectively, need to be controlled, administered and maintained in their entirety, creating what we term a Managed Zone (M-Zone), in which each individual component of each Smart Space operates in accordance with user expectations. As with traditional networks the tools employed to achieve this will be Middleware and service platforms. However, there are many unresolved questions, for example: Do current management frameworks provide solutions to meet the (new) requirements? Are they applicable for future applications, services, and resources? Answers to these questions can only be given after evaluating the level of interworking and integration of current management and middleware. We believe the answer is no [1, 2] current systems provide for the interworking, but not integration, of middleware and management systems. A major barrier to integration us the fact that available information sources within most organisations rely on many different solutions for storing data, solutions that have yet to be harmonised [3, 4]. In this paper we first evaluate the areas of concern to extract requirements for the integration of management and middleware concepts and components. Based on this evaluation, a general framework is developed that clearly identifies specific levels of integration, the boundaries of these levels and their individual objectives. The goal of the framework is to establish a software layer between applications and the distributed technologies that can provide integrated management services, without losing the advantages middleware provides. The framework is applied to develop a management architecture for Smart Spaces. The architecture facilitates interoperability, by providing standardised interfaces and protocols, as well as a common information model. A discussion on Smart Space scenarios from a provider point of view can be found in [5] and [6].
2. Tasks, Areas of Concern, Activities and Unified Description In this section we introduce some of the fundamental concepts and terminology upon which the development of the integrated framework is founded. Management systems are designed to carry out a number of tasks. For the perspective of Smart Spaces arguably the most important tasks are use and operation, which are concerned with that part of a system that is seen by users and customers. They are concerned about the system s ability to serve them a company running a system relies on its efficient operation in order to generate revenue. This operation is supported by control of the system, where the term control describes the brief but permanently reoccurring task of keeping the system stable to serve its customers and to generate revenue. This involves, for example, the configuration of system components and the gathering of data for accounting. Administration and maintenance tasks reflect the longer term operation and control of a system. These general tasks can be divided into several individual procedures. Administration starts with the permanent monitoring of the system and the logging of all occurring events to analyse the behaviour of its components and to detect system failures. Three areas of concern for a management system can be identified. s provide the interface to users and customers enabling them to utilise services. s are software assemblies of components that offer functionality for applications and provide the access to resources. Resources are software and hardware components needed for the provision of services and for their execution. In other words, a distributed system employs resources to support realisation of services and applications. The two main activities inside a management system are information mapping and system management. Information is mapped across levels, upwards and/or downwards, for usage, operation and control. The system is managed at each level through control, administration and maintenance. The assignment of individual tasks to one activity depends on the system s purpose. These activities are tightly coupled mapping of information is supported by management activities and the system s management relies on information mapping. A unified description of information mapping and system management can be done in terms of presentation, specification, submission, re-specification, triggering, queuing, access and execution. This approach is built upon small and functionally specialised components that can be reused across multiple systems. Based on the six major questions for a mapping or management activity (Who? identifier; What? request; Where? destination; When? schedule; Why? purpose; How? execution plan), management functionality can be submitted to and re-specified for a specific Smart Space. [7] 3. Conceptual Model for the Integrated Approach The conceptual model introduced in this section provides the basis for realisation of a specific architecture. It presents rules for components of a specific architecture and describes relationships between those components. The definitions of each plane can be employed to describe particular aspects of the architecture. The conceptual model identifies four planes. Each plane is dedicated to a specific problem context, with each problem context describing a particular viewpoint of the tasks and the areas of concern. The planes are used to specify the different types of information that needs to be mapped and the different levels of management.
Plane WWW Monitoring WWW Editing WWW Alert Instant Messaging Home Control Client Client Fantasy Soccer Object Plane Domain A Domain B Domain C Plane Technology Plane CORBA PHP SNMP CORBA SOAP UPnP Jini JNDI.NET A key goal of the conceptual model is the separation of applications from the underlying technologies supporting their delivery; thus applications become technology independent. Since applications are not bound to a particular middleware or management technology, the actual technologies employment become transparent from the application s perspective. The main benefit of this approach is that it allows substitution of middleware and management technologies, without necessitating changes to the applications. However, the conceptual model must not be seen as a dogma for example, certain applications might need direct access to technologies, which is particularly important for the management of resources. The Plane covers business models and processes and presents them in form of functional blocks. An application is a model of a set of functionalities that might fulfil a specific business goal. The design of an application can be derived from a business model. A discussion of business models can be found in [8] and a discussion on how to map this to actual networks in [9]. The Object Plane models functional blocks as computational objects. An object is a part of an application that models a real world entity. It is implemented as a computational, identifiable entity that encapsulates state and operations. Important for this plane are information models [10, 11], languages and interfaces [7], domains, protocols [13] and s [14]. The Plane models a collection of interfaces and objects (services) that provide basic functions for (application) objects. The basic services that must be provided by a specific architecture are a naming service and an event service. Furthermore, the architecture should offer services that combine information about object instances (naming) with information about object classes (specification). This combination allows assembly of repositories that aid the administration and maintenance of a system. Additionally, the architecture should offer functionality for the visualisation of instances and classes in order to support the manual management of a system. The Technology Plane provides an abstraction from the basic technologies that are managed as well as the technologies that are needed to execute Smart Space management.
These technologies cover network environments [12], service discovery and policies [13] as well as software and service development [7]. 4. Components The components of the framework can be classified according to the three stages of development and operation of services for mobile communications and ubiquitous computing. These three stages are modelling, implementation and deployment. Meta Model - Behaviour - Life Cycle Modelling - Views - Language(s) - Knowledge - Policy Tools - GUI - Compilers s Messaging, Specification Visualisation, Database Infrastructure s Naming, Directory, Monitoring Lifecycle, Config, Notification Communication s Control s Protocol s Protocols and Formats Configuration Console Performance Monitoring Administration Tools Model Implementation Deployment The modelling of services follows a business model. The framework should support the modelling with an appropriate formal notation (probably via stratified language, consisting of multiple viewpoint-specific languages with compilers for mapping between them) for the specification of objects. This specification is based on a meta schema (or object model), which needs to be designed in a way that reflects the needs of the target environments. A core model, specified using the formal notation, will provide basic definitions for the framework (such as often used data types and generic objects), which allow objects to exchange information in a standardised way. The formal notation defines the syntax and semantics of a language derived from the object model. Here, the mapping of specifications to concrete middleware technology, programming languages and compilers must be specified by the framework. This mapping can be supported by tools and compilers for an automated processing of specifications. The second step is the implementation of services within the framework. This is supported by the framework in the form of an execution environment, which provides an interface to the communications environment. The interfaces to this environment are provided in form of three layers, with each layer providing access to its functionality via one or more s. The lowest layer realises the communication between objects and between objects and services. For this communication, the framework needs to define one or more protocol(s), associated data formats and control services. The protocol(s) define the communication behaviour, including the transmission of data. The data formats are used by the protocol for the transmission of information specified in the formal notation. The control services can be used to include additional functionality for addressing, security and transactions. A key point is that protocols at thus level must be specified in a technology independent way, to allow usage of many different technologies for the actual exchange of data. It should also be noted that the interface to the communications environment is not purely and exposing network capabilities. Instead, we need to consider here also the mapping of information from and to the communications environment, for example business to network translation and vice versa. Furthermore, it is necessary to respect the heterogeneous character of the communications environment, not only by means of
covering mobile communications and ubiquitous computing but also recognising the multitude of available and installed technologies. The final step is the deployment of the objects and framework and its components themselves. Here, a number of tools should be provided for the configuration of the system. These tools can be offered in form of an administration application. This application should be able to visualise information about the actual state of objects, including instantiated objects, request counts, runtime behaviour, monitoring and log information. The tools should be based on core and/or application services. Following this approach, an administration tool by itself is a distributed application that can be modelled using the conceptual model and the mechanisms of the framework. The services of the Plane can be further classified into two groups. The first group collects core services, which must be present in the execution environment for usage and operation of a distributed system. The second group depicts services that might be present. This second group of services should improve the architecture s ability to support control, administration and maintenance. 5. Architecture Managing Ubiquitous Computing Environments The framework described above has been applied to develop an architecture for management of ubiquitous computing environments the M-Zones Management Architecture (MMA), which concentrates on the two middle planes of the conceptual model and offers six recommendations for integrated management. Directory Notification Naming Monitoring Specification Protocol Visualization Object Object Object Object The basis of MMA is an abstract object model. A concrete object model, called a Meta Schema, is derived from this abstract object model. The Meta Schema defines the basic specification elements of a MMA application. The Definition Language () is a formal notation that is used to express the Meta Schema. This language combines characteristics from middleware interface definition languages, languages for the definition of managed objects and languages used to specify data that is exchanged between applications. objects are specified in. MMA defines a Schema based on and a Core Model that is relevant for all applications and independent of domain specific specifications. The basic part of the Core Model is the identification of a reasonable set of qualifiers providing meta information about typed application objects. An Protocol is responsible for the transport of information among application objects including features that enable the construction of management hierarchies like addressing of hierarchies, scoping, filtering and transactions. An Programming Interface () decouples application objects from middleware technology and enables the seamless integration of management functionality within applications. The offers a small and simple to use set of operations for the parameterisation of the protocol.
services realise the naming of objects, enable the mapping of specified information to directories, and allow usage of type and data repositories for applications and MMA components. The implements standard jobs like lookup for available services and registration. The Meta Schema, the and the Core Model take advantage of existing mechanisms and techniques, but enhance them to meet the requirements and objectives of the MMA. They are specific to neither middleware nor management. The Protocol and the provide a generic interface to the application. Internally, they map this generic interface to middleware specific interfaces that need to be adapted to any employed middleware technology. The protocol and the internal realisation of the are transparent to applications any application developed with MMA is ready to run on any middleware that MMA supports. The support of a new kind of middleware has some requirements. Firstly, the MMA must support the new kind of middleware; this is realised with a specific implementation of the that provides access to the available facilities of the middleware. Secondly, the new middleware must be integrated with pre-existing MMA middleware technologies. The integration reflects the Technology Plane of the Conceptual Model. MMA applications that are designed to communicate with each other must be supported by gateways between the middleware technologies. When these two requirements are fulfilled, the new kind of middleware will be available for all MMA applications. It is possible to substitute middleware types employed within a system with other middleware types without necessitating any changes to the applications. 6. Impacts Adoption of the approach advocated in this paper has the potential to explod the corporate dominated "Tower of Integration" model that characterises the current management platform market, replacing such platforms with open mix and match platforms incorporating middleware and management components from many vendors. More specifically the paper presents an approach for Smart Space management that provides the following benefits: Increased choice and flexibility for software developers Platforms and tools developed with MMA will give developers a wider choice, with the ability to easily change their choice as new offerings appear; Increased developer productivity through rapid access to new middleware and management components as new components appear, developers will be able to use them quickly as MMA compliance will ensure that they can be quickly integrated with existing development environments and deployed systems; Economies of scale for middleware and management system vendors who will no longer need to port their software components to multiple platforms, resulting in increased potential returns on the investment of resources to bring their products to market. This will lead to a re-energised market for middleware and management systems, in which it will become viable for vendors to develop products aimed at niche application domains, like Smart Spaces, where to date support for management tasks has been non-existent. Increased independence of vendors in the current market smaller middleware and management component vendors are compelled to align themselves closely with the major platform vendors. Integrating with a platform typically requires detailed technical knowledge, for which tool vendors may depend on the platform vendor itself. Indeed, technical limitations of particular platforms often place unnecessary constraints on the operation of components, thereby stifling the potential for innovation.
7. Conclusions This paper has proposed an approach for the integration of middleware and management concepts, leading to the development of the M-Zones Management Architecture (MMA), which specifically targets management of Smart Space environments. The paper starts with an initial identification of the major activities of management systems, defines a general framework and derives the MMA from it. The paper demonstrates how the integration of concepts and technologies from both middleware and management areas can be achieved. The challenging aspect of this work has been, on the one hand, the diversity of available concepts and, on the other hand, the fact that emerging concepts and technologies continue to change all facets of software development. Six recommendations form a core part of the MMA architecture, together with a method for the realisation of distributed applications that employs all six recommendations. The architecture enables the substitution of individual, deployed technologies with other, more appropriate or environment specific solutions, without changing the architecture itself and without a negative impact to the other recommendations and technologies. The MMA was defined following the objectives of the general framework to show that the provided recommendations are a solution that is lightweight, open, smart, and service/application generic: Lightweight, as the solution can be widely adopted by vendors and providers of different size and market penetration. This means the solution takes into account commonly accepted principles already adopted by service providers and network operators. Open, as the solution includes well-defined interfaces. Interoperability with legacy systems is a key issue for a smooth integration. The term open is also used to relfect market demands for solutions that offer easy adaptation of new technologies and interworking with other systems. Smart, as the architecture is designed to support intrinsically dynamic aspects (particularly for the subscription, deployment, and session set up process of applications, services, and resources), enabling a flexible adaptation to customer requirements and operator/provider needs. This will is realised through the use of meta-data repositories throughout the whole system life-time, which provide a comprehensive knowledge base improving multi-domain service provisioning. /application generic, as the architecture is independent of the actual services/applications that are offered. The basic result of this work is the conclusion that an approach that integrates basic concepts of middleware and management provides benefits for the management of Smart Spaces. The unification of use, operation, and control with the tasks of maintenance and administration minimises the effort that has to be spent for the mid- and long term operation of Smart Spaces. The independence of concrete middleware and management technologies improves the portability of applications: designers and programmers can concentrate on their primary task the realisation of profitable applications instead of dealing with constantly changing technological issues. The simplicity of the six recommendations of the architecture allowed for a simple and lightweight implementation that can be employed in many different environments, starting from small devices up to complex and huge service platforms.
References [1] Motoshiba Funabashi et.al.: Development of Open Collaborative Platform for Coming ECs. by International Joint Efforts. SSGRR 2000, August 2000 [2] Hegering et.al.: Integriertes Management vernetzter Systeme. 1. Auflage, dpunkt Verlag für digitale Technologie, Heidelberg, Germany, 1999 [3] Kurt Geihs: Middleware Challenges Ahead. IEEE Computer, Volume 34, No 6, June, 2001 [4] Thomas Magedanz: Enhancing Parlay with Mobile Code Technologies. Proc. of the 6 th IEEE Intelligent Network Workshop, IN2001, Boston, MA, USA, May 6-9, 2001 [5] Willie Donnelly, James Clarke: Architecture for Location Based of Third generation Operation Support Systems (AlbatrOSS) Smart Home-based Scenarios. International Conference on Computer, Communication and Control Technologies (CCCT 2003), Florida, USA [6] Sven van der Meer, Stephan Steglich, Stefan Arbanowski: User-centric Communications. In Proc. of IEEE International Conference on Telecommunications, ICT 2001, Bucharest, Romania, June 4-7, 2001 [7] Sven van der Meer, Robert O Connor, Alan Davy: Ubiquitous Smart Space Management. 1st International Workshop on Management of Ubiquitous Communications and s, Waterford, Ireland, December 11th, 2003 (www.m-zones.org) [8] Rober O Connor, Sven van der Meer: Present and Future Organisational Models for Wireless Networks. Workshop on Adaptive Systems for Ubiquitous Computing, in Proc. of the International Symposium on Information and Communication Technologies, ISICT 2003, Dublin, Ireland, September 24-26, 2003 [9] J. Strassner: Architecture for Enabling Business-Driven Networks. IBM developerworks Live! Developers conference, April 2003; [10] J. Strassner: Using an Information Model to Achieve Better Network and System Management. In Proc. of IEEE International Conference on Telecommunications, ICT 2001, Bucharest, Romania, June 4-7, 2001 [11] John Strassner, J. Reilly: Learning the SID. Full day tutorial at the TeleManagementWorld 2003, Spring Session May 2003 and Fall session November 2003 [12] Keara Barrett, Ray Carroll, Sven van der Meer: Investigating the Applicability of Mobile IP and Cellular IP for Roaming in Smart Environments. In Proc. of the 2nd IEE/IEEE Telecommunications Systems Research Symposium, ITSRS 2003, Dublin, Ireland, May 6th, 20003 [13] Samir Ghamri-Doudane, Sven van der Meer, Robert O Connor, Yacine Ghamri-Doudane, Nazim Agoulmine: Resource Discovery and Management Using Policies in Smart Spaces. 11th HP Open View University Association, Paris, France, June 21-23, 2004 [14] Sven van der Meer, Brendan Jennings, Keara Barrett, Ray Carroll: Design Principles for Smart Space Management. 1st International Workshop on Management of Ubiquitous Communications and s, Waterford, Ireland, December 11th, 2003 (www.m-zones.org)