Dynamic service composition in home appliance networks | SpringerLink

Multimed Tools Appl (2006) 29: 257–284 DOI 10.1007/s11042-006-0018-2

Dynamic service composition in home appliance networks A. Mingkhwan & P. Fergus & O. Abuelma’atti & M. Merabti & B. Askwith & M.B. Hanneghan

Published online: 7 July 2006 # Springer Science + Business Media, LLC 2006

Abstract The proliferation of networked appliances and the complex functions they provide make it ever harder for a specialist, let alone an ordinary home user, to configure them to provide a given service. The use of flexible middleware architectures, combined with application level services will allow for better exploitation of these features both for the benefit of performance and simplicity. For example, a TV, DVD player and radio all have output speakers and are capable of producing sound, however there is no common framework to harness this functionality. In this paper we address this issue and propose a home network architecture that interconnects home appliances and their associated services using descriptive ontologies to guide the composition process itself. In this network, home appliances are interconnected using a Service Integration Controller (SIC), which discovers and dynamically composes the services they provide and efficiently coordinates the communications between all services independent of the protocol being used. The prototype we implemented uses a home entertainment system as a case study and shows that this framework fulfils the requirements of the system design. A. Mingkhwan (*) Faculty of Industrial and Technology Management, King Mongkut’s Institute of Technology North Bangkok, 1518 Pibulsongkram Road, Bangsue, Bangkok 10800, Thailand e-mail: [email protected] P. Fergus : O. Abuelma’atti : M. Merabti : B. Askwith : M.B. Hanneghan Networked Appliances Laboratory, School of Computing and Mathematical Sciences, Liverpool John Moores University, Byrom Street, Liverpool( L3 3AF, UK P. Fergus e-mail: [email protected] O. Abuelma’atti e-mail: O.E.Abuelma’[email protected] M. Merabti e-mail: [email protected] B. Askwith e-mail: [email protected] M.B. Hanneghan e-mail: [email protected]

258

Multimed Tools Appl (2006) 29: 257–284

Keywords Networked appliances . Service descriptions . Dynamic service composition . Home networking . Interoperability . Networked entertainment systems . On-demand service discovery

1 Introduction For more than a decade, home and building automation and subsequently networking have received many considerations by homeowners, industry and academic researchers [1, 2]. This includes the introduction of a wide spectrum of wired and wireless infrastructures and network protocols such as LonWorks, CEBus, SmartHouse, VHN, HomePNA, HomePnP, IEEE1394 (Firewire), X-10, IrDA, IEEE802.11b, Bluetooth and HyperLAN/2 [3]. Despite the long list of advantages they provide, several challenges need to be considered, most notably, interoperability [4, 5] and the difficulties associated with the integration of combined functionalities, including the use of vocabularies to discover and describe devices and the services they provide. Current approaches are striving to develop universally agreed vocabularies to describe services, however this is a very difficult challenge, if not impossible, since no universally agreed service description or taxonomy is available to describe services homogeneously. Researchers within the Semantic Web community are trying to address this limitation by developing an alternative approach that performs semantic interoperability between different Web vocabularies using ontologies [6–9]. However the major difficulties that still need to be addressed are how ontological structures are distributed, managed and evolved over time, based on general consensus [10]. Many other industry efforts have evolved to create interworking solutions, which include the Home Electronic System (HES) [11], Home Audio–Video Interoperability (HAVi) [12], Universal Plug and Play (UPnP) [13, 14] and its Intel Digital Home [15] implementation and the Open Services Gateway Initiative (OSGi) [16]. Additionally, research efforts within Networked Appliances and Service Discovery disciplines are trying to provide solutions, which define scenarios for new and emerging network configurations [17, 18]. Furthermore the provision to monitor and control the home using TV sets and set-top boxes has advanced rapidly in recent years because the TV is considered as the central appliance within a typical home environment [19–21]. However, these solutions do not provide any capability for composing services between and across connected appliances. Imagine the scenarios illustrated in figure 1. While you watch a DVD using the TV’s visual and audio services, the TV’s Teletext function is displaying a recipe on the intelligent fridge screen, which is being used by the person who is preparing dinner in the kitchen. Simultaneously, the TV’s receiver unit can be used to stream the signal of a documentary to the upper floor where it is displayed on a small window on the children’s personal computer (PC) screen as illustrated in figure 1(a). The phone rings and the person who is reading a book in the bedroom picks it up, and although a physical intercom system does not exist, the phone is capable of broadcasting a message to the household, using the available audio appliances found within the home environment, to inform the relevant person that they have a phone call as illustrated in figure 1(b). These scenarios illustrate how the functions provided by devices can be combined to create implicit functions, which are defined as functions configured on demand


259

Fig. 1 (a) Appliances function utilisation. (b) Creating a virtual appliance

without any expressly stated characteristics. An implicit function defines instantaneous profiles which can be built and used accordingly. This concept has evolved from our ongoing research in the field of distributed semantic unstructured services [22, 23]. In this paper we propose a dynamic service composition framework to dynamically incorporate the services and controls provided by appliances within a home network, called the Home Appliance Integration Unit (HAIU). Our framework makes three novel contributions:

& & &

Functionality Utilisation—Composite appliances like TVs and Hi-Fis can semantically expose their resources as software services using ontology engineering principles. Dynamic Composition—The ability to semantically compose and use the services provided by appliances when they are readily available. Virtual Appliance—The ability to create an Fimplicit_ appliance that does not physically exist using the available services.

260


In short, Functional Utilisation enables Implicit Functionality, which combined through Dynamic Composition, creates Virtual Appliances. What makes this work novel is the use of ontologies for the purpose of service descriptions and composition. Our research utilises the management of services provided by devices in home appliance networks by semantically discovering and integrating the services and controls they provide [24]. In the rest of this paper, Section 2 gives an overview of the proposed framework and its usage scenarios. Section 3 discusses our system design and describes how we address service descriptions, semantic service matching, device capability matching and the creation of Implicit Functionality profiles. Section 4 describes our working prototype and Section 5 discusses our conclusions and proposed future work.

2 Dynamic services composition The availability of highly independent services offered by appliances enables us to map different types of services to form an Implicit Function. This is illustrated in figure 2. The Service Integration Controller (SIC), which resides in the Home Appliances Integration Unit (HAIU), is the central component. The HAIU has the ability to connect to all the appliances in the home network. The design allows for future extensions widening the possibilities of providing high definition interoperable networking [25]. The appliances can discover and advertise their services and the SIC coordinates the relations between the services in accordance with the user’s requirements. Imagine the scenario of figure 3, whereby all the appliances within the home are connected together using a network infrastructure. Each appliance exposes its capabilities by advertising its services to all the appliances within its immediate environment. Using your 3G mobile phone, you make a call to your friend, and participate in a video conversation. In the course of your conversation, you arrive home. While

Fig. 2 The home appliances services composition concept


261

Fig. 3 Appliances dynamic composition

entering the house the phone registers its services including 3G receiver, video, microphone and speaker with the HAIU. You now have the capability to create or invoke an Implicit Function in order to determine better services to support the video conversation. You could integrate the visual service of the TV with the audio of the Hi-Fi and still use the microphone and communication channel of your mobile phone in a single integrated profile and activate it seamlessly without any disruption to the conversation. From the example scenarios described above, our novelty resides in the ability to capitalise on device redundancy and offer all the services provided by these appliances. The high independence of services enables users to compose numerous Implicit Functions such as the intercom system described in the second scenario, or to typically provide better services as described in the third scenario. Additionally one can also make use of the unused services within any device. For example if the TV is used to play a DVD all its other services, such as the Teletext and RFReceiver, are normally disabled. In our system the receiver can still be used to broadcast the signal to other visual displays, whether it is a computer or another TV, without disrupting the person watching the DVD as described in the first scenario. In this case, the user utilises an unused service instead of buying a new TV receiver card for the PC. Virtual Appliances, such as the intercom system illustrated in figure 1(b), remove the need to physically install custom solutions. In this instance the appliance does not have to exist, it can be built by combining the available services provided by other registered appliances. In this case the microphone from the telephone and the speakers provided by audio appliances throughout the home, such as a TV, Hi-Fi and PC, can be combined to produce a virtual intercom. In order to achieve this, the system interrupts the required services and allows other appliances to take control according to some user defined priority classification. Another example of a virtual appliance is a virtual remote control capable of discovering and invoking all the functions provided by each appliance in a given profile configuration.

262


In the next section we describe the system protocol design including, service descriptions, semantic service and device capability matching and our implicit functionality creation mechanism.

3 System design The system we have designed ensures the integration of services provided by service-enabled appliances. A service-enabled appliance is defined as a device with a network interface and several services that allow the functions it provides to be accessed and controlled. The service integration process is based on Implicit Functions, which discovers and integrates services to form a specified configuration. The Implicit Functionality is devised from the user’s requirements at any given time to form an abstract integration of services. To further ground our idea we define the abstraction itself as a profiled list of required services, which are combined in such a way to define a high-level concept, such as a FTheatre._ This brings with it additional challenges, which we describe below:

&

&

&

We envisage a home networked environment that consists of distributed appliances, which share information and host services [26]. The challenge is to provide effective mechanisms to discover and use these services, based on the capabilities they offer. Typically an appliance such as a TV is incapable of simultaneously offering the functions it has to other appliances nearby. For example, it is not possible to watch a movie on the TV and simultaneously allow your PC located upstairs to discover and use the FTeletext_ service—at present appliances do not work in this way. The challenge is to expose the functionalities offered by appliances as independent software services that can be simultaneously discovered, composed and invoked by other appliances [26]. We do not know how service providers will structure the concepts they use to describe the services offered by appliances, therefore mechanisms need to be developed that allow devices to resolve differences between the different vocabularies used [10]. As such mechanisms need to be developed that provide semantic interoperability mechanisms, which ensure that the domain ontology implemented in the SIC, continually evolves over time to include the terminology used by other devices [27, 28].

These challenges form the basis of our approach and in the following sections we discuss how they have been addressed within our system. 3.1 Protocol design Our protocol uses service descriptions that must be implemented by participating service-enabled appliances. Each appliance situated within the environment must conform to description rules that specify how the service registers itself and how the operations it offers are described. An appliance provides one or more services and specifies the information each service must contain to successfully register itself. Services are described using service ontologies, as illustrated in figure 4. The collective use of these ontologies


Describes

1

263

1

1..*

Capability Model 1

1 Device

1

Supports

Process Model

Supports

Provides

1

Presents

1..*

Service

1

1..*

Grounding

Profile

Fig. 4 UML class definition for service ontologies used by service-enable appliances

describes the service as a whole and provides the basis for automatic service discovery, composition and execution. The Service Ontology, describes the high-level semantics of the service and contains references to a Service Profile, a Service Process Model and a Service Grounding, which collectively describe the service’s capabilities. The service descriptions themselves are described at an abstract level in terms of the Inputs, Outputs, Preconditions and Effects (IOPE) as in [9]. The IOPEs that a service supports are defined within the ontologies, whereby the IOPEs in the Service Profile Model form implicit relationships with signature definitions defined in the service interface, via the Service Process Model and the Service Grounding. Figure 4 also illustrates that a Device has a Capability Model. This model is used to describe the capabilities the appliance supports in terms of the hardware, software and networking capabilities it has. Every appliance that wants to register with the SIC must provide a Capability Model. The Capability Model and the Service Ontologies allow the SIC to semantically match services and determine whether the device that provides the service, will maintain or increase the overall quality of service. For example a PDA and a TV may both provide FVisual_ services, however, the TV may be more capable of processing large multimedia streams received from a DVD player, than the PDA. In this instance the SIC selects the appliance that provides the best quality of service. Service and appliance registrations are automatically managed by the SIC. When a device connects to the HAIU it provides the Capability Model and the Service Ontologies, which are validated and added to the SIC’s lookup registry. Before the Service Ontologies are registered the SIC checks that no previous registrations exist—if registrations do exist then they are overwritten with new Service Ontologies. Devices will come and go over time and in controlled disconnections, devices must send a message to the SIC requesting that the services it has registered are unregistered. However, there may be instances when a controlled disconnection is not possible, for example a device suddenly loses power without notice. Consequently, the SIC periodically attempts to poll each of the registered devices, to determine if they are still alive—if any device cannot be contacted, each registered service associated with that device is removed.

264


The Service Ontologies and the Capability Model are the part of the protocol that enable appliances to describe their capabilities and the services they provide in conformance with the SIC registrations. This allows each device to:

& &

Describe each of the software services it provides using ontologies, which allow services to be more accurately matched by the SIC and composed based on the Bwhat^ part of the composition rather than the Bhow.^ Determine the capabilities other devices support before committing to using the services they provide. For example, a mobile phone may offer a media transcoding service but it may not have the power or computational capabilities to perform the transcoding.

The remaining part of the protocol concerns itself with how the Service Ontologies are defined, how service requests and service descriptions are semantically matched, which takes into account the capabilities the appliance supports, and how Implicit Functionality profiles are created.

3.2 Service descriptions Within our system one of the key requirements is to create a level of abstraction that describes services semantically in order to overcome the inherent problems associated with key-value pair matching. We use a set of generic ontologies that describe services homogeneously using Web Ontology Language for Services (OWL-S) [9]. The service ontologies we developed, describe services from a number of viewpoints, that allow them to be automatically discovered, composed and invoked. Figure 5 illustrates, in part, one of our service descriptions used to describe FVisual_ services provided by devices within our system. The FVisual_ service uses four service ontologies to create the description; the Service Ontology, Service Profile, Service Process Model and the Service Grounding. The top-level ontology element is Fservice:Service_ that describes the high-level semantics of the service. This may contain device and versioning information as well as service creator details, such as the developer’s name, email and Web address. The Fservice:Service_ element also groups the remaining ontology elements used to describe the service as a whole. More specifically it describes what the service presents, how it is described and the grounding the service supports. The Fservice:presents_ element points to the Service Profile that describes the service in terms of the IOPEs it supports—this element forms an explicit link to the Fprofile:Profile_ element using basic Resource Description Framework (RDF) [29] constructs. In order to simplify the service descriptions the datatype information associated with the inputs FVCD,_ FHeight_ and FWidth,_ have been omitted. However, in the complete description, datatypes are described using the FcomplexType_ constructs defined in the XML Schema specification. These descriptions describe the datatype including the attribute’s associated multiplicity. The Fprofile:Profile_ element describes the capabilities the service supports in terms of all the inputs it can take and the outputs it generates. It also describes the preconditions required by the service before it can be executed and the effects that occur as a result of executing the service. These descriptions are typically used to aid discovery, whereby a service request that contains the same IOPEs as a Service Profile is said to describe the same capabilities.


265

Visual Service version:1.0 developed by Paul Fergus Movie Format Screen Height Screen Width &livjmVisual; &livjmVisual;#PlayPortType &livjmVisual;#Play &livjmVisual;#PlaySoapIn &livjmVisual;#vcd &livjmVisual;#height &livjmVisual;#width

Fig. 5 Service description using OWL-S ontology

Although the Service Profile describes the capabilities, it does not provide any information regarding which methods in the service interface the IOPEs belong to. For example, the IOPEs in the service request could have matched IOPEs in the Service Profile, however the IOPEs could belong to different signatures. Using the Fprocess:ProcessModel_ and Fprocess:AtomicProcess_ elements the Service Process Model extends the semantics of the Service Profile by grouping the IOPEs into

266


atomic processes. These are analogous to the body part of a signature that does not contain a method name. In this instance, if an atomic process exists that contains all the Inputs, Preconditions and Effects, described in the service request, and produces the required Output, then a signature exists within the service interface. The Service Process Model provides a mechanism to group the IOPEs, however it does not provide any mechanisms to describe the concrete service bindings contained in the service interface. It only provides a high-level semantic description of the signatures, without knowing what the implementation details are for the specific service technology being used. Bridging the gap between semantic descriptions and concrete bindings is achieved using the Fgrounding:WsdlGrounding_ element illustrated in figure 5. This element forms part of the Service Grounding specification, that provides a bridge between the atomic processes described in the Service Process Model and concrete signatures described in the service interface using Fgrounding:WsdlAtomicProcessGrounding_ elements. The Web Service Description Language (WSDL) [30] provides the service interface abstraction irrespective of the service technology being used. Service interface interoperability between WSDL and other service interface technologies can be achieved via service adaptation mechanisms [31]. Using the service ontologies we have developed, enables services to be automatically discovered using the Service Profile; and then semantically matched and invoked using the Service Process Model, Service Grounding and the service interface, which we describe in detail in the following section. They allow the functions provided by devices to be semantically described in terms of the capabilities the device supports, which enables the SIC to select services that best match the required capabilities defined in the service request. 3.3 Service integration controller (SIC) The SIC acts as the central point of contact for home appliances and graphical user interfaces, to register services and invoke profiles—the architecture is illustrated in figure 6. The graphical user interface is defined, within our framework, as any appliance capable of viewing and interacting with the user interface provided by the SIC to install and view profile templates or create new user defined profiles. The HAUI unit provides commonly used profile templates, however the user will have the ability to create their own templates from scratch or download previously created profiles from the Internet provided by other users. An appliance will be placed within the home environment and switched on. This enables it to discover and connect to the SIC and initiate a request to register its services. Discovering the SIC is achieved by multicasting an XML message requesting its endpoint address. For example this could be the IP address and Port, if devices integrate at the IP level. If a return message is received, the IP and Port address are extracted and used to bind to the SIC. Once a connection has been established the device sends the appliance capability description including all the service ontologies for each service the device provides. Before the services are registered, the SIC ensures that the structure of the service descriptions conform to the ontology specifications, ensuring that they can be understood and processed by any other appliance within the environment. If the appliance’s capability advertisement is invalid or missing then the SIC disconnects the device and none of its services are registered. Devices must provide a capability


267

Fig. 6 The HAIU in operation

description so that the SIC can determine if the device can effectively execute the service based on capability preferences described in service requests. If the service ontologies are valid, the appliance’s services are registered. The registration process itself involves adding the information about the appliance and its associated service descriptions to a centralised lookup table, which are linked to the devices ID. Each appliance added to the environment will perform this process and register its existence, its capabilities and the services it provides. 3.3.1 Semantically matching services in the SIC We have developed an algorithm called Semantic Interoperability and Signature Matching (SISM) [24], and implemented it in the SIC. SISM is a semantic matching service that determines if service descriptions hosted by a device match service requests it receives from appliances in the network. This is achieved by processing the metadata used to describe the service and the service request, including the signatures described in the service interface. Service descriptions and service requests are described at an abstract level in terms of the IOPEs. Using IOPEs provides the basis for signature matching within the SISM algorithm and is described in more detail in the following sections.

3.3.1.1 The IOPE matching process Using the SISM algorithm the SIC can determine if any two terms match using a number of techniques. One possible match occurs when any two terms are equivalent, which is illustrated in figure 7. In this instance the precondition Ftelevision_ in the service request is equal to the precondition Ftelevision_ in the service description. Another possible match can be achieved via subsumption. For example an input in the service

268


Fig. 7 Illustrates IOPE matching

request may be called FMovie_ and an input in the service description may be called FFilm_—if FMovie_ is either a Fsubclass,_ Fsuperclass_ or Fequivalent_ to FFilm_ then a conceptual relationship has been found that links the two terms together. However this example is problematic because the term FFilm_ could mean FMovie_ or FSlideshow._ In this instance the name of the inputs and the outputs are used to help determine the context in which the term is being used. This matching process in SISM is described below:

& & & &

If the IOPE in the service request is the same as the IOPE in the service description then this constitutes an exact match. If the IOPE in the service request has an FequivalentTo_ relationship with the IOPE in the service description then this constitutes an exact match. If the IOPE in the service request is a subclass of the IOPE in the service description then this constitutes an exact match. If the IOPE in the service description subsumes the IOPE in the service request then this constitutes a plug-in match [6].


& &

269

If the IOPE in the service request subsumes the IOPE in the service description then this constitutes a subsumption relationship [6]. Anything else fails.

For the case where terms or relationships cannot be found we have developed an algorithm called Distributed Emergent Semantics (DistrES) [10], which propagates unknown terms within the network. This results in the DistrES algorithm receiving zero or more semantic structures that describe how the term is defined. If no structures are returned then this means that devices within the network do not understand the terms or no explicit relationship exists that links the terms together. If structures are received, they are evolved, using statistical programming techniques, until the most optimal structure is produced and merged into the DistrES service’s ontology. Once the structure has been merged the above matching process is repeated. This process continues until all the IOPEs in the service request have been processed—if all the IOPEs are matched this constitutes an abstract match. When abstract matches are found, SISM retrieves the service ontologies, along with the service interface and creates a table containing the matching IOPEs from the service request. The matched IOPEs act as keys in the table and have corresponding values, which represent the names of the IOPEs used in the service ontologies. SISM uses the DistrES ontology to resolve terminology differences, therefore the service request may refer to an input as FMovie,_ whilst the input in the service ontologies may be referred to as FFilm_—the table of key-value pair IOPEs creates a semantic mapping between the different terms used. The following section describes how abstract matches are used to find concrete matches

3.3.1.2 The signature matching process The signature matching process tries to determine if the IOPEs in the service request can be directly mapped onto concrete bindings in the service’s interface file by processing all the service ontologies. SISM processes the Service Profile and retrieves the values associated with the FhasInput_ element. These values specify which FAtomic Process_ each IOPE belongs to in the Service Process Model. The IOPEs may have been matched at an abstract level, however they may belong to different atomic processes, therefore SISM needs to determine if a single atomic process exists that supports all the IOPEs in the service request. If an atomic process is found this means that an operation in the service interface exists that supports all the IOPEs in the service request. In this instance SISM extracts the operation name from the Service Grounding and retrieves the parameter order and the endpoint address from the service interface file, which are used to describe how the service is invoked. During this process the table of matched IOPEs are used to bridge between the different terminologies used in the service request and the service ontologies. If SISM maps the IOPEs in the service request to IOPEs in the Service Process Model it tries to determine if the datatype information supported by both sets of IOPEs match. This matching process is described below: & &

An FAtomic Process_ in the Service Process Model for FService A_ has associated input elements that conceptually match the inputs described in the service request. The datatype information associated with the FAtomic Process_ for FService A_ conceptually match the datatype information for inputs described in the service request.

270

& &


The FAtomic Process_ in the Service Process Model for FService A_ has an associated output element that conceptually matches an output described in the service request. The datatype information associated with the FAtomic Process_ in the Service Process Model for FService A_ conceptually matches the datatype information for the output described in the service request.

If a match cannot be found due to datatype conflicts then an attempt is made to resolve the conflict using some intermediary service which can explicitly convert the datatype into the required format. This could then be substituted with the conflicting IOPE and the service could be invoked [24].

3.3.2 Considering appliance capabilities The service discovery and matching process may result in several candidate services that provide the same functionality. In this instance, services provided by devices that best match the appliance capability requirements, as described in the service request, will be added to the Implicit Functionality Profile. For example a typical home environment may provide several FVisual_ display services capable of processing streamed data—typically you will select devices that will provide the best quality of service, e.g., a FVisual_ service provided by a TV may be selected instead of a FVisual_ service provided by a mobile phone to view the latest DVD Movie. However, if the mobile phone is the only device available, then an intermediary service may be discovered to transcode the DVD movie into a format that can be readily processed by the mobile phone. As a result each appliance that joins the network within our system must describe and register the hardware, software and networking capabilities it supports. Figure 8 illustrates the process used that matches the Device Capability Preferences (DCP) described in the service request, with the Device Capability Model (DCM) used to describe a particular device’s capabilities. A service request is submitted to the Formulator Manager (user interface) when a user requests a service. The manager retrieves the DCP used to describe the required capabilities that candidate services must support, from the devices persistent storage. The DCP is inserted into the service request and submitted to the SIC. The SIC begins by trying to find a service that semantically matches the service request using SISM and the matching algorithm described in Section 3.3.1. If a service is found, its DCM is extracted and passed along with the DCP to the Device Capability Service (DCS) implemented in the HAIU. The DCS calculates the resource expense incurred when the service is executed by adapting the formulas defined in [32, 33]. The formula defined in Eq. 1 calculates the percentage of a resource required, where a resource r offers a service s that requires acs, r units of some total resource value trr. rescs;r ¼

acs;r trr

ð1Þ

This formula allows the SIC to determine what percentage of some resource will be used given the total value of the resource available. For example, if a service requires 1 MB of RAM and the device provides a total of 32 MB, then the service is said to require 3.1% of that.


271

Fig. 8 Device capability matching

However it is not enough to only calculate the value for the resources needed to execute a service. The SIC will need to determine if the device is overloaded, consequently we also need to calculate how much of the available resources on average are used by the appliance. For example, if the device on average runs it’s CPU at 75% then we can infer that the device may struggle to take on the increased computational overhead if our service is to be executed. Furthermore it is possible that the quality of service will be affected because the computation may be shared across a large number of processes. When this is the case, the SIC must calculate the overhead for each resource the service requester deems important and compare it to the desired capability defined in the service request. The DCS achieves this using a technique called the Multi-Attribute Utility Theory (MAUT) [33]. This algorithm is implemented in the DCS and is used to produce an overall capability score for some device D given the attributes defined in the device’s DCM. This formula is defined as Eq. 2, DCScoreðD; DCMÞ ¼

d X

cwi ðDCMÞDðvi Þ

ð2Þ

i¼1

where DCScore is the overall capability score for device D according to the device capability model DCM, d is the number of capabilities for the type of device, cwi(DCM) is the importance rating of attribute i according to device DCM, and D(vi) is the status rating for attribute i. The importance rating describes how important a given attribute is in relation to all the attributes used, e.g., the CPU attribute may be

272


the second most important attribute with an importance rating of 30, which means that the CPU is considered three times more important than an attribute with an importance rating of 10. The status rating describes how well the device supports a particular attribute, e.g., a device may have BExcellent^ for its CPU attribute, which may equate to a value of 75—therefore calculating a capability score for CPU, could be achieved by multiplying 30 75 which is equal to 2,250. Given the two formulas, the appliance calculates the service ratings programmatically by estimating the average attribute values from the operating system itself and assigning the appropriate status rating. For example, if the device uses on average 25% of its CPU when the required service is executed we may assign the CPU_Load a status assessment of BExcellent^ with a status rating of 75. The equation defined in Eq. 3 illustrates that the MAUT formula has been amended to take into account the current resource load and the load required to execute a service. In this instance the DCScore and the rescs, r are added to give a combined resource load value, indicating whether the device can effectively execute a service it provides. DCScoreðD; DCMÞ ¼

d X

cwi ðDCMÞDðvi Þ þ rescs;r

ð3Þ

i¼1

When the terms in the DCP and the DCM are processed any ambiguities that are encountered are resolved using the DistrES algorithm. When the formula in Eq. 3 is used to calculate the score for the DCM, it is compared with the score generated for the DCP. If the DCM score is equal to or greater than the score for the DCP then the device is said to be capable of effectively executing the service, whilst ensuring the quality of service is maintained. In this instance the service details are returned to the Formulator Manager. 3.3.3 Processing profile invocations The user begins by asking the SIC to run, for example, the FTheatre_ profile illustrated in figure 6. The SIC processes the Service Grounding associated with the service and formulates the signature used to invoke the required service method. Using the Service Grounding the SIC processes the service interface and extracts the endpoint used to bind to the service; this could be the IP and Port address. Once the endpoint has been extracted the SIC binds to the FPlayer_ and invokes the required method. This invocation specifies that the player should begin to broadcast the audio and video information it has. In parallel the SIC discovers two additional services capable of processing broadcasted audio and video content and binds to them, before instructing the services to process the audio and video data. If a service becomes unavailable, the SIC automatically extracts the next service described in the profile and binds to it, before again instructing the service to process the multimedia content. For example if the surround sound audio speakers become unavailable, the SIC will bind to the TV speakers—which are deemed less capable, but functionally equivalent. 3.4 Implicit function profiles Implicit Function profiles contain information about the services used in a particular configuration. Figure 9 illustrates, in part, a simple service profile.


273

a SELECT ?operationName WHERE (?x profileHierarchy:ServiceRequest ?y), (?y profile:hasInput ?z), USING profile FOR “”

b public QueryResults executeQuery(OntModel ontModel, String queryString){ Query query = new Query(queryString); query.setSource(ontModel); QueryExecution qe = new QueryEngine(query); QueryResults result = qe.exec(); return result; }

c Fig. 11 Illustrates the how RDQL queries are formulated and executed using the Jena 2.3 API

to determine the relationships that exist between two terms. For example, the service request IOPEs and the service description IOPEs were extracted using RDQL queries and relationships between the terms were determined using the DistrES ontology and the InfModel. When a service request is received from the Implicit Functionality Formulator, the SIC attempts to match the service request against each of the Service Profiles it has for each registered service. This is achieved using our SISM algorithm. Resolving ambiguities between terms that are syntactically distinct but semantically equivalent is known as semantic interoperability. Within our system this is achieved using an OWL ontology we developed, which is illustrated, in part, in figure 12. The SISM algorithm was developed using Java and uses the Jena API in conjunction with the OWL-S API [35]. The Domain Ontology allows the SIC to determine if any terms are conceptually related. This functionality overcomes the inherent limitations associated with attribute-value pair matching and provides a level of flexibility that does not constrain the service developers to one specific vocabulary. We used the Jena API to load the ontology, which provides a number of methods that enable the subsumption relationships to be determined. For example, the code used to determine if a term X is a subclass of a term Y is illustrated in figure 13. This example also illustrates how an equivalence relationship is determined between two

276


Fig. 12 OWL domain ontology

…..