JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.

ORG

COSMPC-COSMOS based Middleware for Pervasive Computing

R. Nagaraja and Dr. G. T. Raju
Abstract Ubiquitous computing environments are characterized by a high number of mobile devices, wireless networks and usage models. Distributed applications for such environments must continuously manage their execution context in order to detect the conditions under which some adaptation actions are required. This execution context contains various categories of observable entities, such as network interface, operating system resources or user preferences. Mobile devices like PDAs or mobile phones have become widespread. Similarly network functionality like GSM, Bluetooth or WLAN has become a standard. Nevertheless, not many applications take mobility into account. An application and its communication component are tightly coupled and the application assumes that network behavior does not change. Here in this paper we propose a new lightweight middleware architecture based on Service Component Architecture (SCA) and COntext entitieS coMpositiOn and Sharing (COSMOS) consisting of a small foot-print core layer and a modularized pluggable infrastructure. The SCA eases the reconfiguration of the components at runtime to support different communication mechanisms and service discovery protocols. Besides, using SCA, new functionalities can be added to the middleware platform that can be provided by remote applications (SCA or not). The architecture presented in this paper is suitable for mobile devices and extensible to make use of abstractions to conquer heterogeneity in mobile devices. Index TermsCDC Connected Device Configuration, CLDC Connected Limited Device Configuration, COSMOS COntext entitieS coMpositiOn and Sharing, SCA Service Component Architecture, Fractal, Composite, Factory Method, Singleton, Flyweight.

1 INTRODUCTION
daptability to changes (bandwidth, peers, network conditions, service) and constant change from one environment to another (different base stations, different domains, etc) are the biggest challenges that mobile devices face today. The growing popularity of distributed middleware systems coupled with their scalability, flexibility and suitability for mobile and wireless architecture has made them dominant methodology for supporting distributed applications. Distributed applications require multiplicity of services in order to accomplish their tasks. In the proposed middleware architecture one or more of the required component services can be loaded and started by a system level entity. This plug and play approach obviates the need for all middleware components to be running on a low power device at all times. Customizable architecture can optimize energy as they can be pruned depending on the workload and devices that can be in contact using the available device network interfaces. The vision of ubiquitous or pervasive computing adds new complexity.

The environment becomes populated with smart devices (PDAs, mobile devices etc.,) integrated into environment and allows the access to real world information as well as control distinct functionality. The heterogeneity in devices, computing power, device interfaces and network topology as well as application changes can be handled effectively by adaptation and configuration of the architecture as compared to classical middleware. To solve this problem, we propose a new architecture for small devices with concepts borrowed from enterprise environments. In such environments, J2EE containers such as JBoss [13] or Weblogic play an important role in supporting the deployment of Java components. In addition, COSMOS [2] techniques can be used to dynamically extend applications within such containers. In order to provide a dynamic architecture for resource constrained devices, we created a dynamic lightweight platform offering enterprise level capabilities for such devices. Fig.1 shows the middleware architecture for local and distributed applications. As shown the applications are assembled of other components depending on context by dynamically loading the components, this is the reason to call our middleware architecture as COntext entiteS coMposition and Sharing Middleware for pervasive Computing COSMPC. Using this architecture we are able to assemble dynamically an application out of components. These components are then adapted at runtime as per the application requirements.

R. Nagaraja is with the Information Science and Engineering Department, Bangalore Institute of Technology, Associate Professor. Dr. G. T. Raju is with the Department of Computer Science and Engineering, RNS Institute of Technology, Professor and Head.

2011 Journal of Computing Press, NY, USA, ISSN 2151-9617 http://sites.google.com/site/journalofcomputing/

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

10

For example, the architecture can be used to select appropriate network interface dynamically according to different criteria like device availability, bandwidth availability, cost of communication etc. The COSMPC platform can be used to create multi-hop and multi-network bridge across devices for seamless communication. The result of combination of service oriented container architecture with adaptation using cosmos can increase the capabilities of small devices beyond the usual applications. The application bootstrapping is done in two components namely the adaptation manager and the core layer. The adaptation manager adapts an application based on context changes and user preferences. The core layer supports different communication mechanisms and service discovery protocols (SDPs) [14]. The paper is structured as follows: section 2 presents the challenges to be addressed in pervasive computing environment. In section 3 the existing middleware capabilities are described. In section 4 we describe the new architecture. Section 5 presents prototype implementation and performance details. In section 6 we finish with conclusion and future work.

vice discovery and service access with different communication paradigms like RPC, event based, requestresponse etc.

2.3 The flexibility due to environmental changes

Customization and functionality extension at run time is essential for an application to adapt to the environmental changes. Hence configuration and dynamic adaptation are essential functionalities in a platform.

2.4 The changes in the service due to mobility

As the user keeps moving from one environment to another, it is essential that the platform must be able to support changes in the services and reduce the impact of such changes in the user activities.

3 EXISTING MIDDLEWARE CAPABILITIES

Several middleware approaches have been proposed to deal with pervasive environments. The trend to build container suitable for small devices had already started in many projects. Many micro kernel based container like Merlin [15], JBoss [13] and Spring [16] are small in size but they still relay on service available in infrastructure network like JNDI in JBoss or heavy use of XML in Merlin and J2EE services in Spring. Micro-kernel architecture design for small devices like OSGi [17] and SCA [1] are available from open service gateway infrastructure and major software vendors. SCA has been selected because of language independence and support for resource constraint CDLC devices. ReMMoc [5] is a reflective middleware to support mobile application development and uses OpenCOM [9] as its underlining component technology. OpenCOM [9] is implemented in C++ and available for few platforms. Another thing about ReMMoc [5] is that it provides dynamic reconfiguration in terms of binding and service discovery protocols. In order to do all the functionalities associated with different communication mechanism and service discovery, they must be available in the device. In our case, the functionality can be loaded either from device or remote repository when it is required. Furthermore, we propose a distributed infrastructure based on message (invocation) protocol which is independent of network technology and operating system. AdaptiveBPEL [3] is a policy driven middleware for the flexible composition of Web Services. This approach is more focused on the automatic service integration, according to the application needs, than the middleware adaptation. Prim [18] is a software architecture which provides programming language-level constructs for implementing components, connectors, configurations and events. The middleware is assembled before deployment according to the required components. So far no runtime changes can be performed as required in a dynamic reconfigurable middleware.

2 CHALLENGES TO BE ADDRESSED
Portable devices exhibit different properties like sometimes stationary and sometimes moving as they are carried by users. The device complexity varies from simple to stand-alone systems. There will be large variation in resources, capabilities and communication patterns. Thus the mobile devices have variation in functioning, mobility and accessing methods. The networking interface used by these devices range from infrared communications to wifi communication. The device interfaces used also changes due to the mobility. A device may change the network due to non-availability, cost of network and power requirement of the network. Distributed applications in this scenario are structured as application objects and services interacting with each other. Services in turn use device capabilities or further services of local device or of a remote device. Hence, the context-aware application has to tackle the following challenges.

2.1 The retrieval of context information

The context information required for application adaptation in both the device level (e.g., device interface, memory, computing power, battery etc) and application level (user preference, additional functionality requirement, mobility etc) can be handled by suitable data representation and distribution to the appropriate entities, for application configuration, service configuration and dynamic adaptation.

2.2 The heterogeneous protocol service discovery and service access

The heterogeneity in protocols to discover [4] and access service is handled by accommodating multiprotocol ser-

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

11

GaiaOS [8], [11] is a component based meta-operating system that runs on top of existing systems, such as Windows2000, WindowsCE, and Solaris. It is used in a middleware infrastructure for active spaces. The system focuses on the management of active space resources and provides location, context and event services. Jadabs [6] is a dynamic lightweight platform for adhoc infrastructure based on component based container and aspect programming. The platform gives access to both local applications using local infrastructure as well as other devices using distributed infrastructure. It is developed for CDC compatible devices. Our platform is based on language independent SCA framework [23] and can configure applications using COSMOS to CLDC compatible devices also. The Middleware architecture can adapt itself to the situation due to context changes.

Fig.1. COSMPC middleware architecture with dynamic resources

DESIGN RATIONALE

combined. Furthermore, components behaviour and interaction can be configured to different contexts, using the policy framework defined by SCA. The core layer and adaptation manager forms the adaptation part of the architecture. CoreLayer: This layer contains the functionalities associated with communication and device capabilities. The communication section is composed of components, each supporting different communication mechanism. The communication components are dynamically loaded as per the device requirement, context changes, policy based etc. A session can use more than one component for communication, for example, one for sending request and another for receiving reply. Thus a session can be supported by more than one network interface. Context Manager: Context manager collects information about device resource availability (network interface) and other defined events through COSMOS. Cosmos is component based framework used for managing context in pervasive environments. The framework is used to collect context information from available devices about their network interfaces, device capabilities and process them to configure application accordingly. Fractal [11] hierarchical component model is used in implementing the context nodes for context management. The four design patterns of cosmos component architecture namely composite, factory method, singleton and flyweight are used to facilitate efficient resource management, dynamic reconfiguration and evolution of policies. The collected information is used to identify a situation. Cosmos is used for this purpose because it is component based, facilitates reuse of policies, less memory, resource consumption and instance management. It detects new devices and identifies network interfaces of the devices and informs service manager. Cosmos is used by Context Manager to collect information about context changes like change in network interface and updates the service managers device details table to facilitate adaptation. Service manager uses this updated device details table to send network interface details to adaptation manager. Adaptation manager loads appropriate transport protocols for communication with remote devices using the network interface details.

4.1 Requirements
Fulfilling the following criteria is the main goal in designing new middleware. Reduced Footprint: The infrastructure should be small enough to fit into small devices without affecting the working environment of the devices. Dynamic Adaptation: The adaptation must be dynamic, automatic without user integration. Required functionalities should be added and removed as per the requirement without stopping the application. Flexible Architecture: The functionalities required for adaptation (components, services etc) can be provided by related connected devices. Platform Independent Implementation: The platform independent architecture provides standard abstraction for vendor specific applications and makes implementation of these applications a lot easier.

4.2 Middleware Architecture

The two main components of the middleware are Middleware architecture Fig.1 and Invocation architecture Fig. 2. Fig.1 shows the structure of new middleware architecture. It contains the infrastructure for local sevices/application access and distributed service/application access. Explanation of components of the middleware architecture is given in the following sections. SCA runtime: The lightweight of middleware is achieved by using SCA runtime with basic functionalities to run SCA applications. By creating basic SCA runtime we can support devices with limited capabilities. Service Oriented Architecture is a set of specification for building SCA applications. Services are modelled as components in SCA. SCA is designed to be language independent. SCA supports protocol independent communication between remote components. Thus, service can be described using different service descriptive languages. With SCA, components built using different technologies can be

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

12

with a unique DeviceID forms a unique ID globally. The message IDs are used for synchronization issues. A service context field allows the specification of additional parameters that indicate the properties relevant to the processing of the invocation in the architecture such as synchronization issues or quality of service parameters. Basically, the context is a name-value list where parameters are added freely. The payload contains the operations and parameters.

Fig.2. Invocation Object Structure

Adaptation Manager: The adaptation manager decides about loading appropriate components for communication or extends functionalities to access remote service as per the situation identified by service manager. These components and functionalities can be loaded either from local storage or from remote repository. It supports different service SDPs [14] to support communication in pervasive computing. The functionality associated with each protocol is provided by a set of components. Service Manager: Service Manager handles invocations for local services as well as remote services. It receives invocation from a local application, service or a remote device. If the service is local or device capability, it invokes the service or dispatches the invocation to remote devices through adaptation manager. The dispatched invocation will be interpreted in the remote device. It can handle synchronous and asychronous invocation with different interoperable protocols. Local Device Infrastucture: This infrastructure provides platform for local services and device capabilities. Local Service Interface is used to convert invocation to method execution. There are two types of device applications namely services and device capabilities. Services are registered as interfaces and can be accessed by either local invocation or by a remote invocation. Similarly the device capabilities are registered as interfaces and are accessed either by local invocation or by remote invocation. The Local Service Interface provides abstraction of these services to applications. Local Applications/Services: A programming absraction is provided for local applications to invoke device services as well as local services. Local Application Interface converts method calls of local Applications/Services into invocation to be interpreted by Service Manager.
Fig.3. COSMPC Middleware Implementation

In a point-to-point communication the operations and parameters are interpreted as a remote method invocation. In case of event based communication no receiver needs to be specified and the operation denotes the eventtype on which application can subscribe. The distributed infrastructure consists of messaging modules and event systems. The messaging system forms the first level in the distributed infrastructure and uses a basic message oriented communication. This allows nodes to communicate each other through a simple interface. This message system is our earlier work of communication framework MCMD [22] using multiprotocol concepts. The framework was tested and has given satisfactory result and the same concept is used in the messaging system for communication among different devices. The messaging system is very simple and can run on J2ME/CLDC devices as well. As this messaging system is very general and independent of a specific communication protocol, it can be used to communicate in adhoc manner with any platform. The messaging system uses invocation object structure of Fig. 2 for sending request and receiving reply between devices. The messaging system uses the new extension at run time, provided by service manager to configure the devices depending on available network interface. We use UDP, TCP and Bluetooth protocols to access devices with different infrastructure facilities. UDP is

4.3 Invocation Architecture

The Invocation architecture Fig.2 is used for network independent communication [12]. The Fig.2 shows the elements of an invocation. DeviceID and ServiceID are used to denote a sender and receiver of an invocation. ServiceIDs are unique and local to a device and this ID along

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

13

used to reach the device using W-LAN, Bluetooth to reach the device using Bluetooth protocol or only bluetooth enabled devices and TCP to connect gateway to the internet. Each one of these extensions is independent of the other and packed as components in the adaptation layer. The messaging system uses context manager to indentify the network interface available at that instance on a particular device. The adaptation manager is used to load required components in core layer for communication by messaging system.

Fig.5. Context Nodes for selecting BT Devices

Service Manager is implemented as a part of service handler and interprets all invocations (local and remote). It uses Local Service Handler to serve local service requiests and Remote Service Handler to serve remote service requests. Adaptation Manager Component handles the adaptation part of application. We implemented three network interfaces namely bluetooth device, adhoc cells and wireless access points. Adaptation Manager receives a remote invocation object and destination device details from Service Manager through Remote Service Handler. The invocation object contains destination device details and communication pattern (Fig.2.) with remote device. The invocation is dispatched by dynamically loading appropriate transport plug-in components. Two components namely sync.call and async.call are implemented to handle synchronous and asynchronous invocations. Context Manager is implemented to detect available devices and their interfaces and update the device details table of Service Manager. Context Manager sets policies to detect devices and collects their availability and network interfaces regularly and updates the device details table in service manager. Two sets of context nodes (Fig.4. and Fig.5) are implemented to detect Bluetooth and WiFi devices.

Fig.4. Context Nodes for selecting WiFi Devices

Once a new network layer is available, for example a device comes in the range of W-LAN, the UDP implementation can be set up. The UDP implementation can be deployed from a locally available copy or it can be obtained from an external device (a peer, a base station etc,).

IMPLEMENTATION AND PERFORMANCE

A prototype implementation of middleware COSMPC is shown in Fig.3. The middleware components are implemented using fractal and cosmos. Fractal is framework for component programming. The components Service Handler, Service Manager, Adaptation manager and Context Manager are implemented.

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

14

TABLE 1 ADAPTATION OVERHEAD FOR LOCAL SERVICES

TABLE 2 PROXY OVERHEAD FOR DISTRIBUTED SERVICES

One set of context nodes (Fig.4) detect WiFi devices (adhoc cells and access points) and another set of context nodes (Fig.5) detect bluetooth devices. The device details obtained from these two sets of context nodes are combined and stored in device details table by context manager. Fig.6 shows the complete context management implemented with active notification and observation at different context nodes. A prototype was tested using Sony vaio VPCS137GG laptops, with Intel Core i5-560 processor @ 2.6GHz Turbo boost up to 3.20GHz, 4GB RAM, J2ME-Platform-SDK-3.0, Java: 1.6.0.-18, client VM 16.0.b13, CDC-1.1 running on fedora OS and Samsung Galaxy pro B7510 android phones with android OS ver 2.2 (Froyo), 512 Memory, Wlan Wi-Fi 802.11 b/g/n, BT-v3.0, running @ 800MHz. The performance of the architecture was tested with adaptation overhead and without adaptation for local service (TABLE 1) and remote service access (TABLE 2) for both laptop and mobile environments. The performance of the context manager to detect the device availability for Bluetooth and WiFi are also shown in TABLE 3. As a first benchmark we measured the performance of the middleware including Service Manager, Adaptation Manager, Context Manage and Core Layer. We analyzed the overhead of the adaptation involving Context Manager and Adaptation Layer in different platforms Java Runtime Environment (jre) and J2ME/CDC cvm. The adaptation performance is measured to monitor the overhead associated with method calls with varying number of arguments. The values shown in TABLE 1 are the average of 20,000 runs on laptop and 2000 runs on the packet pc. In the first measurement TABLE 1 (Normal) we measured the time of one run under normal circumstances without adaptation. In the second method (Proxy) measurements are taken after adaptation with empty components. The measurement of last column (Adaptation Time) indicates the time with code in the components for adaptation.

TABLE 3 PERFORMANCE OF CONTEXT MANAGEMENT

As can be seen the adaptation has significant impact on the execution time. The overhead of using adaptation varies: laptop/jre is 12.5%, laptop/cvm is 14.3%, mobile device/jre 20% and mobile device/cvm is 6%. The overhead is more in case of mobile device/jre due to slow running of jre on mobile device. The adaptation performance to dispatch invocation to remote device and to get respose from a remote device is measured to monitor the overhead involved in adapting the middleware for accesing remote service. In this benchmark we measured the adaptation overhead of COSMPC middleware architecture with three transport plug-ins. The values shown in TABLE 2 are the average of 20,000 runs on laptop and 2000 runs on the mobile device. We also measured the performace of Conext Manager in push and pull operations in both modes and the results are tabulated in TABLE 3. The performace of the Context Manager to detect nearby device is satisfactory. The measurement for Bluetooth devices excludes device discovery time. The device discovery time for Bluetooth devices can be reduced using IR interfaces in association with RF interface.

JOURNAL OF COMPUTING, VOLUME 3, ISSUE 10, OCTOBER 2011, ISSN 2151-9617 HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING WWW.JOURNALOFCOMPUTING.ORG

15

[11]

6 CONCLUSION
In this paper, we have introduced a middleware for mobile devices to communicate using different protocols depending on the context. The context may be user defined or available network interfaces. With this middleware, multihop and heterogenous communication is possible. Portable devices communication can be extended using this middleware and a device can continue to communicate until one network interface is available. Thus the middleware can extend the available range for a device and can communicate with device having different platforms. We in future want to extend middleware with protocols to include devices beyond mobile phones like sensors, settop boxes etc., having low computing and memory. We are planning to use model driven engineering [7] for application adaptation for resource poor devices as well as heterogenous devices, considering variation of resources available in these devices.
[12] [13] [14]

[15] [16] [17] [18]

[19]

[20]

REFERENCES
Service component architecture specifications. http://www.osoa.org/display/Main/Service+Component+Ar chitecture+Specifications, 2007 [2] D. Conan, R. Rouvoy and L. Seinturier, Scalable processing of context information with cosmos, In J. Indulska and K. Raymond, editors, Proceedings of the 7th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS07), volume 4531 of Lecture Notes in Computer Science, pages 210224, Paphos, Cyprus, Jun 2007, Springer [3] A. Erradi and P. Maheshwari, Adaptivebpel: Policy-driven middleware for flexible web services composition, In MWS 2005 Workshop at EDOC 2005, pages 512, Enschede, The Netherlands, 2005 [4] C. A. Flores-Cortes, G. S. Blair, and P. Grace, A multiprotocol framework for ad-hoc service discovery, In MPAC 06: Proceedings of the 4th international workshop on Middleware for Pervasive and Ad-Hoc Computing (MPAC 2006), page 10, New York, NY, USA, 2006, ACM [5] P. Grace, G. S. Blair, and S. Samuel, Remmoc: A reflective middleware to support mobile client interoperability, In CoopIS/DOA/ODBASE, pages 11701187, 2003 [6] Jadabs, Dynamic Lightweight Infrastructure for Small Devices, http://jadabs.berlios.de [7] C. Parra and L. Duchien, Model-driven adaptation of ubiquitous applications, In 1st International Workshop on Contextaware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS 08), pages 97102, Oslo, Norway, June 2008 [8] R. Cerqueira, C. K. Hess, M. Roman, and R. H. Campbell, Gaia: A Development Infrastructure for Active Spaces, In Workshop on Application Models and Programming Tools for Ubiquitous Computing (held in conjunction with the UBICOMP 2001), Sept. 2001 [9] M. Clarke, G. Blair, G. Coulson, and N. Parlavantzas, An Efficient Component Model for the Construction of Adaptive Middleware, Proceedings of Middleware 2001, Nov. 2001 [10] Fractal. ObjectWeb, Open Source Middleware, 2004. http://fractal.objectweb.org
[1]

M. Roman, and R. H. Cambell, GAIA: Enabling Active Spaces,Proceedingsofthe9thACMSIGOPSEuropeanWork shop,pp.229234,Kolding,Denmark,September2000 Object Management Group, CORBA Messaging, report or bos/980506,1998 J.Group.Jboss.http://www.jboss.org Y. D. Bromberg and V. Issarny, Service discovery protocol interoperability in the mobile environment, In T. Gschwind andC.Mascolo,editors,SEM,volume3437ofLectureNotesin ComputerScience,pages6477,Springer,2004 Merlin, The Apache Avalon Project, 2004 http://avalon.apache.org/merlin Spring. Java/J2EE Application Framework 2004, http://www.springframework.org OSGi, Open Service Gateway Initiative. OSGi Service Platform, IOSPress,release3edition,Mar.2003 M. MikicRakic and N. Medvidovic, Adaptable Architectural Middleware for ProgrammingintheSmallandMany, In Proceedingsofthe4thACM/IFIP/USENIX R. Nagaraja and Dr. G.T. Raju, SCA based Dynamic Light Weight platform for mobile device, ICCIC2010, December 2010 R.NagarajaandDr.G.T.Raju,SCAbasedMultiprotocolCommu nicationformobiledevices,ICETECT2011,March2011

R. Nagaraja received the B.E., M.E., and M.S degrees from Bangalore University in 1985, 1989 and from BITS 1998. He is presently working as Associate Professor in Information Science and Engineering Department at Bangalore Institute of Technology, Bangalore Karnataka INDIA. His research interest includes building adhoc infrastructure for mobile devices, building self-adaptive systems, protocol independent communication, component based design for heterogeneous devices and model driven engineering. He is a member of IET, ISTE and IACSIT.

Dr. G. T. Raju received the B.E., M.E., and Ph.D from Bangalore University in 1992, 1995 and 2008 from Visvesvaraya Technological University. His is currently working as Professor and Head, Computer Science and Engineering Department at RNSIT, Bangalore. His research interest includes data mining, artificial intelligence and neural networks. He is a member of CSI and ISTE.