|
From IEEE Intelligent Systems
The Semantic Web Enhancing Residential Gateways: A Semantic OSGi Platform •
A service registry that supports the application of semantic reasoning to discovery and the automation of invocation turns OSGi into a semantic OSGi platform. The OSGi (Open Service Gateway initiative) service platform specification is the most widely adopted technology for building a control system for the networked home.1 Three main features contribute to its success. First, it supports various well-known protocols, simplifying communication among home devices. In addition, it defines a cooperative model for applications to dynamically discover and use services provided by others. Finally, it allows flexible remote management of these applications and the services they provide. So, an OSGi solution supports decentralization, diversification, and ubiquity not only in smart homes but in pervasive environments generally. However, OSGi service discovery and use assume the client has a great deal of information about the service it wants to use. Although a client might be unaware of the service's location, it must know the service's interface name (for discovery) as well as its method signatures (for invocation). Surprisingly, these requirements conflict with the remote management of OSGi applications, one of the platform's mainstays. How can OSGi applications be remotely deployed and work properly on every customer platform if home devices can differ from one customer to another? What's more, as the OSGi specification notes, customers can use the home service platform to run services from different service providers. So, it's hardly realistic to suppose that a specific provider knows, a priori, the interfaces that match other providers' services. In this context, OSGi's simple syntactic name matching isn't enough. A smarter discovery mechanism could make an open residential gateway possible. This problem isn't specific to OSGi. It's another example of the problems that motivated the Semantic Web,2 a Web in which information is well-defined, resulting in better cooperation between computers and people. We propose a semantic approach to service discovery that turns OSGi into a semantic OSGi platform. In this new platform, OSGi services describe their properties and capabilities so other software elements in the residential gateway can automatically determine their purpose (semantic discovery) and how to invoke them. Both tasks involve the semantic markup of OSGi services through appropriate ontologies, which is the core of the Semantic Web and, by extension, of our semantic OSGi platform. An OSGi overviewThe OSGi platform consists of a Java virtual machine (JVM), a set of running components called bundles, and an OSGi framework.1 A bundle is a Java archive (JAR) and the minimal deliverable application in OSGi. Bundles have a restricted life cycle that's externally managed by the OSGi framework. In OSGi, the minimal unit of functionality is a service. So, a bundle is designed as a set of cooperating services, which any application might discover after the services are published in the OSGi service registry. An OSGi service is defined by a service interface, which specifies the service's public methods and is implemented as a service object, which is owned by, and runs within, a bundle. The bundle registers the service object with the OSGi service registry so its functionality is available to other bundles. In general, registered services are referenced through service reference objects, which maintain the properties and other metainformation about the service. Registering OSGi servicesWhen a bundle registers a service object (by calling the registerService() method), it specifies the service interface name and might also further describe the service using a collection of key/value pairs (a dictionary object). For instance, in figure 1, bundle A registers the service object (serviceobj) jointly with a dictionary object (props) under the printing service interface as register Service("Printing", serviceobj, props).
Figure 1. Registering and obtaining OSGi services. Obtaining OSGi servicesBundles can obtain an OSGi service through an active search or by using the framework's event mechanism (the service listener). The listener automatically notifies bundles when a service is registered, modified, or in the process of unregistering. It can also filter these events. In the example in figure 1, bundle B might create a service listener to obtain information only about printing services: addServiceListener(listener, Bundles can also actively search the service registry for specific services using the getServiceReference() method. The input parameter is the name of the service interface. For instance, bundle B can use ref = getService Reference("Printing") to obtain the service reference object corresponding to the service registered by bundle A. Using OSGi servicesAfter bundle B obtains the service reference object, it must obtain the service object itself to be able to use the required method—colorPrinting in this case: printer = getService(ref) The OSGi framework also lets bundles refine the search using the getServiceReferences() method, whose input parameters are the service interface name and filtering information to help the matching process. The filter syntax is based on the Lightweight Directory Access Protocol language.3 For instance, to get the list of all PostScript services belonging to the printing service interface, a bundle could use ref = getService References("Printing","(type = PS)"), where the filter type = PS is matched against the dictionary of properties provided on registration. Why a semantic OSGi platform?A mechanism for automating service discovery and invocation, such as the one the OSGi service registry supports, is essential in ubiquitous environments such as a smart home. Drawbacks of OSGi mechanismsOSGi mechanisms have several drawbacks, mainly caused by syntactic match making. Discovery. OSGi's current discovery mechanism doesn't consider the semantics of the requested service and requester query. Instead, it uses syntactic matchmaking. So, the discovery phase can only retrieve service references that exactly match the service interface name in the query or whose properties include the same syntactic keywords when using a filter. This mechanism has several drawbacks, including problems with synonyms (semantically similar but syntactically different services) and homonyms (syntactically equivalent but semantically different services). For example, a search for a Printing service might miss a service registered under the service name print. Selection. OSGi discovery might result in a list of matched services—for instance, when several home printers register under the Printing service interface name. Adding filtering information at the discovery phase ((type = PS) in our example) can aid the selection process. However, OSGi filtering is again based on syntactic comparisons. That is, the properties are simply strings with no meaning, so the synonym and homonym problems appear again. What's more, without a semantic interpretation of the service's properties, the OSGi platform can't perform a smart selection of the best service. Invocation. OSGi needs a more flexible approach to service invocation. Not only does the requester bundle have to know the service interface name (Printing) but, to invoke the service, it must also know the method's name (colorPrinting) and the number and type of parameters (File). This is clearly an obstacle in a pervasive environment because it prevents unaware bundles (that is, bundles without prior knowledge of the service interface) from dynamically invoking the service. Key elements of the semantic OSGi platformThe problem of automatic service discovery and invocation isn't new. In fact, researchers in the Web services field, where service composition and monitoring are also critical, have repeatedly analyzed the problem.4 These analyses concluded that service discovery should involve ontologies. An ontology—"a formal, explicit specification of a shared conceptualization"5—facilitates knowledge sharing by providing a common understanding for both a service requester and a service provider. So, in a home environment, domain-specific ontologies that semantically organize typical home services can provide the key. This semantic conceptualization can also help select the most appropriate service, especially if it's applied not only for service classes but also for service properties. An ontology-based search can refer not only to one or more class names (if inheritance) but also to specific property values, constraints on property values, or any combination of these. So, for a complete semantic solution, these properties should be described according to other domain-specific ontologies that conceptualize the parameter values. Although ontologies are developed independently, you can explicitly express relationships between their classes. For instance, if you semantically classify print quality, a filter based on this criterion could be unambiguous. In general, with a knowledge base for service properties, a bundle can reason about the available services to intelligently select the most appropriate one. Finally, to solve the service-invocation problems, the OSGi service description should include not only the service's semantic classification (category and properties) but also enough information for a requester bundle to automatically construct the invoking primitive and process the response. So, we replace the table-based structure in the OSGi service registry with an ontological structure integrating semantic classification, semantic property description, and invocation information. Within this context, any software element (bundles or other software in the platform) could not only determine an OSGi service's purpose and select the most appropriate according to its interests, but also automatically invoke the service in the new framework. Previous approaches have tried to promote smart spaces using OSGi (see the "Related Work in OSGi Services" sidebar). However, no work has focused on the semantic description of in-home services. For this, we exploit previous Semantic Web efforts focused on appropriate service description. The most salient initiatives are the Web service modeling ontology (WSMO, www.wsmo.org/TR/d2/v1.2) and OWL-S (www.daml.org/services/owl-s/1.1). Although both approaches cover the same field and have the same goals, OWL-S is more mature in certain aspects and expressive enough to apply in the smarthome environment.6 (The OWL-S coalition is currently working on OWL-S 1.2, whose details are available at www.ai.sri.com/daml/services/owl-s/1.2.) We opted to extend the OWL-S ontology to support the appropriate description of OSGi services by defining the OWL-OSGi services ontology (OWL-OS). However, the right description of OSGi services isn't enough. We also need to let OSGi bundles register their services semantically and get the correct references to needed services. Together, the OWL-OS ontology and our new methods for registering and discovering services support the OWL-OS/OSGi framework.
Several researchers have proposed using the Open Services Gateway initiative in smart spaces. For example, Choonhwa Lee, David Nordstedt, and Sumi Helal propose using OSGi as an infrastructure for integrating various devices and sensors to provide pervasive computing environments.1 However, they don't resolve the service search and invocation problems. Pavlin Dobrev and his colleagues tackle these two problems directly, but not from a semantic perspective.2 They import services from and export them to Jini and UPnP technologies using OSGi to bridge multiple discovery protocols. Tao Gu, Hung Keng Pung, and Da Qing Zhang define a semantic environment for describing contextual information that context-aware applications can use.3 However, they employ OSGi only as a support layer, without improving the OSGi framework at all. Our review of current research found no proposals integrating semantic reasoning within the OSGi service registry to avoid the service discovery, selection, and invocation problems we've described. Some initiatives have addressed the research issues of ubiquitous computing and user modeling for the ontological description of the smart home. For instance, UbisWorld represents parts of the real world (a house, a shop, and so on) and all the individuals and elements belonging to it.4 Two ontologies under development model knowledge in UbisWorld: the general user model ontology (GUMO)5 and UbisOntology, the ontology for ubiquitous computing. The Standard Ontology for Ubiquitous and Pervasive Applications is another relevant approach for modeling and supporting pervasive computing applications.6 SOUPA consists of two sets of ontologies: core ontologies, which define generic vocabularies that are universal for different pervasive computing applications, and extension ontologies, which define additional vocabularies for specific application types. Unlike our approach, however, none of these projects focuses on the semantic description of in-home services. References
The OWL-OS ontologyOWL-S is an OWL-based ontology that provides a semantic markup language for specifying Web services in an unambiguous and computer-interpretable form. OWL-S provides three essential types of knowledge about any service provided by a resource (upper part of figure 2):
Figure 2. The OWL-OSGi services ontology (OWL-OS). Following the OWL-S specification's recommendations, we exploit OWL subclassing to create a specialized vision of OWL-S services by defining an OSGiService. As figure 2 shows, instances of the devices-in-home ontology provide the OSGi services. This ontology embraces the typical home devices and appliances (heating, dishwasher, doors, blinds, and so on), unifying this field's conceptualization. In addition, we use subclassing to capture the peculiarities of OSGi services by defining a specific OSGi service profile and a service grounding. Because the OWL-S ServiceModel fits perfectly with the OSGi perspective, we don't restrict it—that is, a ServiceModel can describe any OSGi service. Describing services: OSGi profilesAn OWL-S ServiceProfile draws together information about the entity providing the service, the service's functional description (such as inputs, outputs, and preconditions), and a description of additional features that the service might want to specify. Two attributes store the latter information:
In the OWL-OS ontology, the OSGiServiceProfile inherits these attributes, although we've particularized them, as figure 3 shows, by defining an OSGiServiceCategory and an OSGiServiceParameter. For the OSGiServiceCategory, we defined the operations-at-home ontology, representing typical smart-home services (see figure 2). An OSGi service profile should provide one or more categorical descriptions taken from the operations-at-home ontology, because a single service can often be categorized by more than one functionality (for example, "opening a window" can be an airing service or a lighting service). Any service provider can also describe services by ontologies from third-party providers.
Figure 3. Detailed view of the OWL-OS ontology. The OSGi service provider might specify additional information to enrich the OSGi service-selection process. A list of properties of the type OSGiServiceParameter maintains this information. An OSGi service profile should provide at least one OSGiServiceParameter in the subclass OSGiLocation, which stores the service location using the locations-at-home ontology. This data is essential for de- fining a context-aware framework, because the service location might be a determining factor in the selection process. Moreover, an OSGi service profile can specify other parameters which, depending on the service type, it can take from external ontologies (downloaded on demand from the service provider). Accessing services: OSGi groundingsIn OWL-S, both the ServiceProfile and the ServiceModel are abstract representations, while the ServiceGrounding deals with the concrete level of specification. Consequently, we defined an OSGiServiceGrounding (subclass of ServiceGrounding) that lets us map the OSGiServiceProfile to the functionality offered, through a service interface, by a bundle running in the OSGi framework. An OSGiServiceGrounding instance contains a list of OSGiAtomicProcessGrounding instances—one when the instance corresponds to a public method in the bundle's service interface; more than one when we use service composition, which is part of our future work. An OSGiAtomicProcessGrounding instance (see figure 3) refers to a specific OSGi service invocation—that is, a specific public method in a running bundle's service interface. This OSGi service invocation implements an OWL-S atomic process (from the process subontology) by defining the following properties:
As we show in the following section, this information is enough to automate an OSGi service's invocation. A semantic OSGi service in OWL-OSFigure 4 shows an OWL-OS semantic representation of the Printing service interface in figure 1. In the OSGi syntactic approach, bundle A registers a service object serviceobj in the framework, which implements the Printing service interface with a set of properties Props. In current (nonsemantic) OSGi platforms, the service registry stores a table-based representation of the OSGi service (identifier 131 in figure 4), which bundles inspect when they look for services. The discovery process is based on syntactic matching against the interface name and properties fields. In view of the limitations we described earlier, we aim for a new semantic OSGi service registry that stores the OWL-OS instances corresponding to that OSGi service.
Figure 4. A semantic printing service in OWL-OS. Ellipses represent classes, squares represent instances. OSGi and OWL-OS differ in their conceptions of "service." An OSGi service is a Java object, registered in the OSGi framework, which implements the public methods in a service interface. In our example, bundle A offers an implementation of the Printing service interface through the service object serviceobj. So, OSGi treats the individual service invocations colorPrinting and b&wPrinting as a whole in the table-based registry—the properties are bounded to the interface and it's impossible for bundles to specify different properties from one invocation to another (such as a different response time for colorPrinting and b&wPrinting). Surely, when a bundle registers a service interface and its properties, the objective isn't to offer the parameters of a service, but of a service interface, which is a clear limitation. Besides, you can't search for a specific type of invocation inside the service interface—that is, you can't distinguish different functionalities (color or black-and-white printing) in the same interface. In the OWL-OS conception of service, the Printing service interface offers a set of printing methods (services in OWL-OS) with different category values (such as printColor, printB/W, and printSimplex in the operations-at-home ontology) and different service parameters values (such as printing format, quality, and response time). Moreover, OWL-OS lets you search for a specific printing method instead of searching for the service interface as a whole. So, two different services will represent the Printing service interface in the OWL-OS ontology (see figure 4): one for the interface method colorPrinting (OSGiService instance Service131-1) and one for the interface method b&wPrinting (OSGiService instance Service131-2). In this case, the same service model, PrintFileModel, describes each service instance. This model is an atomic process directly invokable and executed in a single step. At the OWL-OS level, the differences between these two services are their profiles (that is, their semantic characteristics) and groundings (that is, the details for invoking the service). Take, for instance, the colorPrinting service (Service131-1). We describe its OWL-OS representation as follows:
In our example, bundle A registers the Printing service interface with a dictionary of properties that include type = PS and location = spare room. We intentionally use the same parameters in the service's semantic description (see SrvParam131-1-1 and SrvParam131-1-2 in figure 4). In the semantic description, however, these parameters are linked to a specific invocation in the service interface. Moreover, we take the service parameters and their values from an ontological conceptualization of the in-home domain. So, we avoid the problems arising from syntactic matchmaking and open the doors to an intelligent and automatic service-selection process using semantic reasoning. The OWL-OS/OSGi frameworkAs we discussed earlier, the OWL-OS ontology plays an essential role in the new OSGi framework because it enables a more appropriate description of OSGi services. However, you must relate any OSGi service with constructs in OWL-OS to manage the OSGi services semantically—that is, to indicate the correspondence between a particular method in an OSGi service interface and an OWL-OS ServiceModel, and to semantically specify the OSGiServiceProfile. But, who offers this semantic information about OSGi services? And how does the OSGi framework receive it? In our extension, the bundle developer specifies this information in the bundle's manifest file by defining a set of new manifest headers, which the OSGi specification allows. We refer to these headers collectively as OWL-OS headers. For a specific bundle, these new headers describe the model and profile correspondence of every method in the bundle's service interfaces. Registering semantic OSGi servicesThe semantic OSGi service registry creates new individuals and classes when a new service is registered in the ontology. To do so, the registry uses the information in the manifest OWL-OS headers of the bundle registering the service, so the registering methods in the BundleContext interface are the same as in the current OSGi specification. As figure 5 shows, the bundle uses the same registering method, but because the bundle includes a manifest file with a semantic section, the semantic registry can store much more useful information to manage these services. We maintain the dictionary of properties in the registering method for compatibility with the standard service registry.
Figure 5. The OWL-OS/OSGi framework. We assume that OWL-OS service parameters, such as OSGiLocation or other service-dependent parameters (printFormat in our example), are managed inside the OWL-OS ontology. We extract their initial values, if any, from the manifest file (for instance, the value #PS for printFormat). Although out of this article's scope, a monitoring agent would watch these services to update the parameter values in the OWL-OS ontology when the parameters are dynamic—for instance, response time. Discovering semantic OSGi servicesBecause obtaining OSGi services requires the requesting bundle to know too much information in advance, we propose using the knowledge stored in the OWLOS ontology to facilitate OSGi service discovery. This fact is reflected in the querying methods, which we modified slightly to support more flexible queries. So, drawing an analogy with current OSGi methods, we propose adding the following methods to the BundleContext interface: semGetServiceReference(String
OntologyURI, The first two parameters provide a flexible service discovery. So, instead of providing the service interface's name, the requesting bundle uses the classification provided by the OWL-OS ontology to specify the kind of service needed. The requesting bundle specifies which ontology it's using to classify the required service (the first parameter, OntologyURI) and the name of the appropriate service category in that ontology (the second parameter, Category). Finally, the semanticFilter parameter in the second method defines filtering information to aid the search process. For instance, figure 5 shows how a bundle can discover the colorPrinting service by asking for any service belonging to the printColor class defined in the operations-at-home ontology. Similarly to the current OSGi specification, the second method returns an array of service reference objects satisfying not only the search criterion (OntologyURI#Category) but also the selection filter, which is specified in the semanticFilter parameter. However, the first method returns only one service reference object. So, if multiple qualifying service interfaces exist (satisfying the search criterion OntologyURI#Category), the framework must decide which of them is the most convenient. Currently, the OSGi specification lets bundles specify a service_ranking number when registering a service object. So, a service with the highest service_ranking number determines which service object the framework will return. We propose a more flexible environment in which the service ranking depends on the requester bundle's criteria instead of the criteria of the bundle offering the service. Consequently, we obtain the service ranking using both implicit and explicit reasoning. Implicit reasoning is supported by the properties among instances or classes in the operations-at-home ontology—for instance, the inhibit relationship specified between the service for turning on the TV and that for turning on the vacuum cleaner. Explicit reasoning is provided through inference rules that support selecting and marking potentially useful services according to the criteria defined by the service requester—for instance, energy consumption and frequency of use. The current OSGi specification defines a syntactic filtering based on the LDAP language. However, basing the filtering on semantic reasoning could enhance the query's flexibility. So, we propose the semanticFilter to be an OWL query about individuals, which pertains to the Category specified in the method's second parameter. Because query-answering dialogues among Semantic Web agents using knowledge represented in OWL typically use the OWL Query Language,7 we propose replacing LDAP with OWL-QL to express semantic filters. Invoking the OSGi serviceOnce the bundle has found the desired service, it uses the information in the service grounding to invoke the service. For this purpose, we extended the OSGi framework specification's ServiceReference interface to both get the service object and examine the service properties. We added methods to obtain the OWL-OS information linked to the service. These get-set style methods (see getMethodName and getInputParameter in figure 5) let the requester bundle discover the public method's name and the parameters to construct the invoking primitive (serviceobj.colorPrinting(file) in the example). Implementation and use caseTo implement our proposal, we selected the Open Source Container Architecture (OSCAR, http://oscar.objectweb.org), an open software implementation of the OSGi framework. To manage the local OWL-OS ontology and provide the proposed semantic OSGi services, we use the Protégé OWL API (http://protege.stanford.edu/plugins/owl/api). This open source Java library provides classes and methods to load and save OWL files, query and manipulate OWL data models, and perform reasoning. We implemented a semantic version of the OSCAR registry that interprets the new bundle manifests and manages the OWL-OS ontology to accomplish service registration (populating the ontology) and search (querying the ontology) as described earlier. To include query processing in our framework, we use the OWL-QL toolkit, which provides a Java implementation of an OWL-QL server by integrating Java theorem prover (JTP)—both from Stanford University's Artificial Intelligence Laboratory (www.ksl.stanford.edu). For reasoning, we used Jess (http://herzberg.ca.sandia.gov/jess), a rule engine for the Java platform that can reason from knowledge expressed in declarative rules. JessTab (www.ida.liu.se/~her/JessTab) is a plug-in for Protégé that lets users interact with Jess. Over this software prototype, we designed a bundle implementing the following use case. John has signed a maintenance contract for his OSGi residential gateway. As part of this contract, John receives a human-presence simulator at his home. This bundle's functionality is to dissuade potential burglars by turning some appliances (lights, TV, and so on) on and off, as though someone was in the home. In this scenario, we assume that the provider broadcasts the same bundle to all subscribers' homes. However, the interactions with lighting devices (such as lights and blinds) or sounding devices (such as stereos or TVs) at each house can differ slightly, depending on the number and sophistication of the home's devices. The human-presence-simulator bundle must interact properly with the appliance controllers, accounting for their peculiarities and acting accordingly. If the broadcast bundle was programmed according to the current OSGi specification, it wouldn't work properly in every home. However, in our OWLOS/OSGi framework, the bundle can obtain the services it needs and know how to use them without having a lot of advance information. In our framework, bundles select potentially adequate services according to their requirements. For instance, IF ((8:00am AND working_day) OR (10:00am AND nonworking_day)) THEN (active sounding services) is a behavior rule programmed in our bundle. So, the bundle starts looking for sounding services in the operations-at-home ontology. After that, it marks these services according to its criteria to obtain a service ranking. In this scenario, the programmer has decided that the more noise the sounding service makes and the less energy it consumes, the better qualification it receives. For instance, the vacuum cleaner (80 dB), stereo system (70 dB), TV (60 dB), and washing machine (54 dB) produce the most noise; and the TV (0.065 KWh), stereo (0.07 KWh), vacuum cleaner (0.67 KWh), and washing machine (0.88 KWh) use the most energy. Because the TV, stereo, and vacuum cleaner are the top-ranking services, the bundle activates them. So, having applied explicit reasoning through behavior rules and data type properties stored in the service ontology (energy consumption and noise level), the bundle selects a set of appropriate services. However, the ontology also maintains properties (relationships) among instances or classes—for example, relationships such as entails and inhibits (simultaneously or sequentially)—that the selection must also account for. These properties enable implicit reasoning—for example, TV inhibits simultaneously stereo system or blinds down entails simultaneously lights on. So, because the TV and the stereo can't be activated simultaneously, the bundle might decide not to use one of them, or start them in turns, depending on how it's programmed. Finally, additional factors, such as, an intruder has been detected, can modify the service ranking. In this case, the bundle wouldn't consider the energy level. Instead, to make as much noise as possible, it would simultaneously connect the vacuum cleaner, stereo system, and washing machine. One step further, and part of our future work, is improving the semantic OSGi platform to infer knowledge about the smart home. For this, the ontological structure should also store information about the use of services, so the framework can acquire extra knowledge about the use of sound and lighting devices in the smart home. From this knowledge, the framework could reproduce the inhabitants' everyday habits when they're on holiday, providing an intelligent human-presence simulator able to decide when to start and stop which services—for instance, the vacuum cleaner usually starts at 10:00 on nonworking days. We've identified another important issue in our ongoing OWL-QL work: introducing semantic service listeners as an analogy to current service listeners. The OSGi platform would notify these semantic listeners when a new service registers in a specific framework category, or even when a new service of this category is registered with a concrete value for a service parameter. Composition and monitoring of OSGi services are part of our future work. Specifying a desired service's requirements is only the starting point in developing a semantic service discovery system. Ideally, from these service requirements, a reasoning engine will select the services that meet, or most closely meet, the requirements. Previous work on applying semantic reasoning to develop TV recommenders can serve as a point of reference.8 Also, in the service selection field, we could supplement the semantic registry with different specialized software agents that account for other factors (ambient intelligence) to automate service selection. For instance, a personalization agent that stores historic information about a user's preferred devices and services could contribute to the decision. A semantic OSGi framework could also incorporate context-aware computing, in which a specialized software agent would be aware of the particular context (time, location, mood, and so on) and react by discovering services meeting that context. Last but not least, by automating OSGi services composition,9 we open the platform to ambitious applications that rely on the idea that different home services usually form a pool committed to various home activities, such as energy control, security, and healthcare. Acknowledgments The Spanish Ministry of Education and Science R&D project TSI 2004-03677 and the EUREKA ITEA Project PASSEPARTOUT partly supported this research. References
|
