Integrating UPnP in a development environment for service-oriented ...

Integrating UPnP in a development environment for service-oriented applications Jianqi Yu and Philippe Lalanda Laboratoire Informatique de Grenoble F-38041, Grenoble cedex 9, France {firstname.name}@imag.fr Abstract- Composing software services is a challenging activity that requires solving both low-level technical problems and highlevel semantic issues. In this paper, we present a tool allowing service composition within domains. A service composition is described with a model description language with domain concepts. The tool integrates multiples technologies like UPnP or DPWS to automate the development of service composition for a developer without any specific technology knowledge. This environment has been used successfully for the development of Internet gateways in the building computing field. Keywords:

Service composition, domain-specific tools, UPnP. I. INTRODUCTION

The development of sensor networks and electronic devices opens new horizons to many application fields. The exploitation of data embedded in such electronic devices is an important point of interest for diverse industries like automation, building surveillance and power distribution [1, 2]. Connecting smart devices permits to integrate low-level gathered data with high-level business processes. The development of such integrated systems is however extremely difficult. The major difficulty is to build large, heterogeneous distributed systems needed to achieve this integration. But also to meet stringent requirements specific to each application field, regarding for instance security or evolution. In order to satisfy such requirements, new development paradigms have been proposed. The Service-Oriented Computing (SOC) paradigm is one of them. It promotes the use of well-defined composition units – services – to support the rapid development of applications. The central objective of this approach is to reduce dependencies among composition units, where a unit is typically some remote functionality accessed by clients. By reducing such dependencies, each element can evolve separately, so the application is more flexible than monolithic applications [3, 4, 5]. Services are assembled in a service-oriented architecture (SOA) that provides mechanisms and rules to specify, publish, discover and compose available services. However, service composition turns out to be complex for several reasons. First, there are today many technologies for describing, publishing and composing services. Depending on the target application domain, different protocols and mechanisms are used to implement SOA. For instance, Web Services (www.w3c.org) are dominant to integrate IT applications. UPnP (www.upnp.org) or DPWS (Devices Profile for Web

Services) are preferred in small area networks. OSGi (www.osgi.org) is often used in centralized, embedded equipments. These technologies require deep expertise. Crosstechnology applications require almost unavailable skills. In addition, as of today’s state-of-the-art, service composition cannot be based only upon service specifications. Syntactic compatibility does not ensure semantic compatibility. In practice, service composition is based on unexpressed assumptions and rules allowing reaching the expected results. A composition of services has also to reach a set of predefined non functional qualities (like security for instance) which requires the production of complex, often non flexible code. In the general case, such code cannot be automatically generated at composition time. This paper presents a tool allowing the specification of service-oriented applications through abstract services composition. Executable applications, made of concrete services, are automatically generated and deployed. This tool can be customized with domain-specific knowledge. In this paper, we focus on the building computing domain and show how the UPnP technology has been integrated in the tool. The work presented hereafter has been carried out in collaboration with Schneider Electric, within the SmartElectricity national project. The paper is organized as follows. Domain background is first provided. Then our tool, based on abstraction and domain-orientation, is presented. Section 4 presents the way the UPnP technology has been integrated in the tool. Section 5 develops an industrial example in the home domain. Sections 6 presents related work. II. BACKGROUND

The development of Internet services based on data continuously collected on physical environments, like plant floors, residential networks or shopping malls, is gaining tremendous importance today. For instance, in the electrical power distribution industry, manufacturers are developing Internet services to help customers better manage their electrical equipment and optimize their power usage. Providers must put forth services that are both attractive to their customers and economically viable. The latter is complicated by the complexity of the software suite and the environment. To keep costs under control, providers need business-oriented tools to help them deploy new developments over an existing infrastructure. Furthermore,

they should be able to manage the infrastructure remotely over the Internet from a single location so that energy and software experts can work together in a cost effective structure. The infrastructure must also be scalable, flexible, and transparent to handle technical and business changes and to ensure that energy experts can develop and manage services as easily as possible. Most systems delivering Internet services using environmental data are based on n-tier architectures in which a dedicated Web application runs on an Internet server and is connected to gateways through HTTP or other protocols over IP. Gateways, connected to the physical devices through field buses, regularly collect, transform and send data to the Internet server, which stores all information regarding the remote industrial processes and runs the services. SOC provides many of the properties that are needed in these architectures. UPnP, OSGi or Web Services have been indeed recently used in architectures integrating IT and industrial applications [6]. We are actually investigating architectures including these three technologies. In this paper, however, we focus on building Internet gateways and connected UPnP devices. As illustrated by Figure 1, we are working on innovative architectures where devices are represented as service providers and requesters [7]. Devices are structured into 3 categories: • Electronic devices incorporated in buildings (controllable shutters or lights for instance) providing basic services through UPnP to sense and act on the environment, • Gateways providing computing resources allowing to run high level services aggregating basic services brought by the previous type of devices, • Rendering devices (TVs, smart phones or PDAs for instance) allowing users to interact with home services and, possibly, to administrate them. In our architecture, gateways are running an OSGi framework. These gateways run service-oriented applications connecting devices and IT but also orchestrating the devices’

Fig. 1. Building computing architecture

actions. Let us remind that OSGi is an open service platform defining a minimal service-oriented component model, a small framework for administering components and a set of standard services. Using a service-oriented framework like OSGi allows developers to implement highly flexible applications where devices and applications can change over time. Unfortunately deep technical knowledge is needed to design, implement, assemble, deploy and maintain such service-oriented applications. Thus, most programmers do not take full advantage of the SOC capabilities. III. APPROACH

We have implemented a domain-oriented generative approach [8] where applications are generated from abstract service compositions. We have also added domain specialization capabilities to the tool in order to facilitate the developers’ work. This additional feature is not presented in this paper. More information can be found in [9]. We have defined the notions of abstract and concrete services. An abstract service is a service specification independent of any given implementation technology. It retains the major features of the service orientation and ignores low level technological aspects. In our model, an abstract service is defined in the following terms: • Functional interfaces specifying the provided capabilities, • Properties including service properties and configuration properties representing the data needed to configure a service before using it, • Configuration templates define the syntax of the service’s configuration file. A concrete service is an implementation of an abstract service in a given service technology. For instance, a concrete service can be a Web Service, an OSGi bundle or an UPnP service. Several concrete services can be made available for a single abstract service. A concrete service is also characterized by a set of dependencies which can take the form of libraries or other abstract services. An application is represented as a set of abstract services that are connected through abstract connectors. Once a composition is specified, concrete services and connectors have to be selected in order to form executable applications. Although connectors themselves can be implemented as services, some glue code is generally necessary to allow the interaction between potentially heterogeneous services. We readily acknowledge that executable applications cannot be automatically generated in the general case. However, we strongly believe that this is very possible as soon as this approach is applied in a restrained area, i.e. a domain. This tool has the following components: • An abstract service repository, • A composition editor, • A concrete service repository, • A deployment manager.

Both repositories (abstract and concrete) are structured elements that can be browsed or searched. They are managed by the tool administrator who is in charge of the creation, modification, suppression of services, being abstract or concrete. The abstract service repository is directly used by the application assembler through the composition editor. The editor allows the assembler to select abstract services and to connect them with connectors. The concrete service repository is hidden to the application assembler. It is used by the deployment manager which purpose is first to select concrete services implementing an abstract composition. This selection phase takes into account multiple constraints expressed in the abstract composition (security and logging requirements for instance) and the current status of the physical targets. The deployment manager has also to generate the glue code necessary to run the concrete composition [10]. In the first implementation, we essentially dealt with the OSGi technology. Concrete services appeared as “POJOs”, that is Plain Old Java Objects, characterized by various properties like their owner, their level of security and the required resources. Given an abstract composition and a set of targets, the deployment manager selected the appropriate POJOs and, using JET templates (Java Emitter Templates), produced the OSGi-conform description of services, the metadata that controls and automates service bindings, etc. It finally ensured the monitored installation of OSGi bundles on the physical targets. Similar code has to be produced for each service technology to be included in our environment. We have recently developed generative facilities for the UPnP and DPWS technologies. The purpose of this paper is to present these new facilities. IV. UPNP INTEGRATION

As previously said, our tool allows the composition of abstract services and the generation of runnable applications connecting concrete services. The main difficulty to integrate UPnP in such a tool lies in the dynamic nature of UPnP. It is necessary to express variability in the applications specification and to generate some code that is able to deal with devices that can join or leave a network without notice. A. UPnP (Universal Plug and Play) UPnP is a set of computer network protocols promulgated by the UPnP Forum [11]. The goals of UPnP are to allow devices to connect seamlessly and to simplify the implementation of networks in the home (data sharing, communications, and entertainment) and corporate environments. UPnP achieves this by defining and publishing UPnP device control protocols built upon open, Internetbased communication standards. The UPnP architecture allows peer-to-peer networking of networked appliances and

wireless devices. It is a distributed, open architecture based on TCP/IP, UDP and HTTP. An ad-hoc UPnP network is composed of two types of nodes: device and control points. A UPnP device can dynamically join a network, obtain an IP address and convey its capabilities. A control point is a controller capable of dynamically discovering and controlling other devices in the UPnP network. UPnP devices are getting very popular on domains like smart building or automation. B. Integration principles In order to deal with UPnP devices in our tool, we had to implement two major evolutions concerning: • the management of the repositories of abstract and concrete services, • the code generator producing runnable applications integrating OSGi services and UPnP devices. Regarding the first point, abstract services are still created by the domain expert who specifies the types of services that can be expected on the network (through UPnP devices). However, concrete services are now created by the system on the appearance of UPnP devices. These concrete services have to be conformed to previously abstract services specified. Similarly, a concrete service is removed from the repository when all the corresponding UPnP devices leave the network. Due to the strong dynamicity of the UPnP devices, we decided not to manage the UPnP concrete services at the tool level. On the contrary, we have chosen to manage UPnP concrete services at the gateway level: on each gateway, a specific bundle called RGP (for Repository Gathering Pojo) contains the list of all the accessible UPnP services. This bundle follows all the UPnP events in order to stay synchronized. It is based on a standard bundle called “UPnPBaseDriver” which allows an OSGi service to recover services and invoke the actions provided by the device. It also implements an interface “UPnPEventListener” to notify device states on the network. It can filter a specific service “UPnPDevice” required with some UPnP device properties in its configuration. The second major evolution of the tools concerned the code generation part. In order to generate the application code, the status of the target gateway, that is the UPnP devices that are currently connected, is taken into account in order to include communications proxies. We had to make the distinction between specific and generic proxies. This is detailed in the coming section.

C. Implementation The purpose of the code generator is to generate code of OSGi services on target gateways and the glue code needed to interact with UPnP devices on the local network. To do so, the code generator requests from the target gateways the currently connected UPnP devices and creates a generic proxy to communicate with these devices. In some cases, the UPnP devices are perfectly known by the generator and specific proxies are available for the communication. These specific proxies have been developed by a domain expert and stored in the remote registry. As illustrated by figure 2, these specific proxies are then inserted and configured by the generic proxy. Otherwise, if no specific proxy has been found, the generic proxy factory instantiates a generic service that is able to invoke a list of the operations provided by the device with their parameters. Therefore, all the concrete services with an UPnP implementation will reference to the generic proxy and all UPnP devices with new type emerging in the network will be accepted and added in the concrete service repository. This generic proxy could be also used to control the DPWS devices or Web Services. A value joining on to an instance proxy configuration will be able to determine if the instance proxy must to be connected to an UPnP device or DPWS device. Let us see two important actions in the system: the creation of a new UPnP concrete service and the monitoring of an existing concrete service. First, let us see what happens when a new UPnP device arrives in the network. A service “UPnPDevice” is created and registered by the UPnPBaseDriver. The bundle RGP is immediately notified and recovers all useful information of the “UPnPDevice” service. Then it informs the concrete service repository by sending an xml file through internet. Then a new concrete service is created in terms of SOC model corresponding to “UPnPDevice” service by the concrete service repository of the specific domain model. All information of “UPnPDevice” service are described as concrete service properties, including the concrete service name, the implementation type “UPNP”, a version, a device type and a service description described if it has been specified in the domain model by the domain expert. Let us see now the monitoring part. The UPnP devices appear and disappear dynamically in the network. To add a new UPnP device type in the concrete service repository, RGP has to recover the device type of a new instance UPnP device appearing in the network and check that is a new device type. But when all instance devices of an UPnP device type disappear from the network, RGP will remove the concrete service describing this UPnP device type from the concrete service repository. If an instance device of the UPnP device type represents in the network, RGP will redo the accession. At the implementations selection phase, the UPnP generic proxy researches an appropriate UPnP specific proxy

Fig. 2. Generated code

depending on the given “UPnPDevice” type in the remote repository. If it found an appropriate UPnP specific proxy implementation, the code generator gets implementation of the UPnP specific proxy to properly interact with the corresponding UPnP device at runtime. By contraries, it generates once implementation of the UPnP generic proxy that is able to invoke a set of operations provided by an arbitrary UPnP device. V. APPLICATION

We have successfully used our tool in order to automate the development of application in the domain of building automation. This has been done in the context of the European ANSO project (for Autonomic networks for SOHO). To do so, we have first specified a model of this domain. The purpose of this model (which is out of the scope of this paper – see [9]) is to specify the service compositions allowed in the domain. The house comprises all necessary devices (alarm sensors, internet connection, presence detector, and so on). Figure 3 presents an example of service composition. One alarm manager service “AlarmManager” aims to manage the alarm system of the house by detecting intrusion. If intruders are detected, the service informs inhabitants through sending a mail service by MailSender or sending a SMS by SMSSender. At this time, if an UPnP device “Set Top Box” presents in the home network, a message will be shown from the TV screen while the TV is opening by the UPnP device. The service “PopupSender” is using to inform the device “Set Top Box” and ask it to show the warning message on the TV screen. In order to get code of this application, the developer has to specify this service composition conforming to the architecture reference of the domain ANSO with the domainspecific development environment. The development environment provides a code generator to automatically select service implementations, and then generate an executable application from the application specification. At the implementations selection phase, the code generator collaborates with the concrete service repository and the bundle RGP. In our example, the generator researches all available service implementations from the remote repository. According to the service configuration properties, it found appropriate OSGi implementations for services “PresenceDetection” and “AlarmManager”. However, the UPnP service implementations selection is complex because

REFERENCES

Fig. 3. An example of the domain ANSO application (C/S: client/server)

of dynamic quality. The bundle RGP handled the dynamic problem. It is monitoring at the home network, when the UPnP device “Set Top Box” is detected, RGP informs the availability of this device to the concrete service repository and updates it. Then, the UPnP generic proxy researches an appropriate specific proxy implementation for the device “Set Top Box” in the remote repository. (As the part of implementation mentioned above, an UPnP generic proxy points to all UPnP devices presenting in the concrete service repository.) Finally, it found an UPnP specific proxy named “PopupSender”, and then code generator inserts the selected specific proxy implementation in the application. Similarly, the code generator found a Web Service implementation for “MailSender” service and a DPWS implementation for “SMSSender” service. The heterogeneous problem among OSGi, UPnP and WS technologies has been handled transparently due to generic proxies. VI. CONCLUSION

In this paper we have shown how an environment transparentizes difficulties of service composition development on different domains by using a specific repository. This repository integrates UPnP technology into an existing service platform OSGi to adapt dynamic natures of various devices on networks. It remotely supervises devices in a local network and dynamically manages the corresponding concrete services plus connections between service types. This environment has been used successfully for the development of Internet gateways in the home computing field. Future work needs to extend this environment to complement the software development chain. It means that a services development perspective will be added in our tool. This environment would make it possible a developer to fast development of new concrete services by using some generic domain specifications and service implementations, as well as easy configuration.

[1] I. F. Akyildiz and al., "A Survey on Sensor Networks" in IEEE Communication Magazine, 2002. [2] P. Lalanda. "E-services Infrastructure in Power Distribution". In IEEE Internet Computing, May-June 2005. [3] M. P. Papazoglou, "Service - Oriented Computing: Concepts,Characteristics and Directions" wise , p. 3, 2003. [4] SECSE team, "Toward service-centric system engineering", ICSOC, Trento, Italy, 2003. [5] C. Escoffier, R. Hall and P. Lalanda, "iPOJO: an extensible service-oriented component framework", IEEE SCC, Salt Lake City, USA, 2007. [6] F. Jammes and H. Smit, "Service-oriented paradigms in industrial automation", IEEE Transactions on Industrial Informatics, vol. 1, no 1, February 2005. [7] A. Bottaro, J. Bourcier, C. Escoffier and P. Lalanda. " Context-Aware Service Composition in a Home Control Gateway". In IEEE ICPS, Istanbul, July 2007. [8] K. Czarnecki. "Overview of Generative Software Development", UPP, Mont Saint-Michel, France, LNCS 3566, pp. 313–328, 2005. [9] P. Lalanda and C. Marin, "Domain-configurable development environment for service-oriented applications", To appear in IEEE Software, 2007. [10] A. Chazalet and P. Lalanda, "Deployment of ServiceOriented Applications Integrating Physical and IT System", IEEE AINA, Niagara Falls, Canada, 2007. [11] UPnP™ Forum, "UPnP™ Device Architecture1.0" Document Version 1.0.1, 20 July 2006