A JESS-enabled context elicitation system for providing context-aware Web services

Providing context-aware Web services is an adaptive process of delivering contextually matched Web services to meet service request-ers’ needs. We deﬁne the term ‘‘context’’ from two perspectives: one from service requesters; and the other from Web services. From the former perspective, context is deﬁned as the surrounding environment aﬀecting requesters’ services discovery and access, such as request-ers’ preferences, locations, activities, and accessible network and devices. From the latter perspective, context is deﬁned as the surrounding environment aﬀecting Web services delivery and execution, such as networks and protocols for service binding, devices and platforms for service execution, and so on. This paper presents a Java Expert System Shell (JESS)-enabled context elicitation system featuring an ontology-based context model that formally describes and acquires contextual information pertaining to service requesters and Web services. Based on the context elicitation system, we present a context-aware services-oriented architecture for providing context-aware Web service request, publication, and discovery. Implementation details of the context elicitation system and the evaluation results of context-aware service provision are also reported.


Introduction
When a Web service is developed, it typically has its most suitable context (e.g., platforms and devices) for the best execution performance.For example, a Web service may be developed oriented to desktop browsers instead of PDA browsers.As people are constantly on the move in nowadays heterogeneous working environment, resources (e.g., computational devices and communication network coverage) are more frequently prone to change due to physical location changes.Therefore, in the process of a service consumption, a service requester may need to smoothly switch to different services adapting to the ever-changing environment (i.e., context), especially when a gross mismatch between resources requirements and supplies occurs (Satyanarayanan, 2004).Providing context-aware Web services is an adaptive process of delivering contextually matched Web services to service requesters.In our research, context-aware Web services emphasize not only on people's mobility and physical location, but also on people's contextual information about their temporary situations (e.g., whether they are in a meeting).We envision that providing context-aware Web services is the first step toward ubiquitous Web services to enhance current e-services by finding right partners, right information, and right services in the right place at the right time.
In this paper, we present an ontology-based context model to formally define contextual descriptions pertaining to both service requesters and Web services.For context elicitation, we implement the ontology-based context model into a rule-base system using Java Expert System Shell (JESS) (Ernest, 2003), which uses an algorithm called Rete to match rules.The Rete algorithm makes JESS much faster than a simple set of cascading if-then statements adopted in conventional programming languages.A JESS-enabled context elicitation system has been developed with the consideration of truth maintenance, due to potentially constant changes of requesters' and services' contextual information.Newly detected contextual information must be consistent with the existing ones; thus, a rule base needs to perform truth maintenance to preserve its correctness.Based on the context elicitation system, we present a context-aware services-oriented architecture (CA-SOA) for providing context-aware services request, publication, and discovery.
To facilitate presentation, let us consider a Web meeting scenario that demanding context-aware Web services as an illustrative example throughout this paper.Steve is a product manager on site of a trade fair.He is hosting a Web meeting with his remote colleagues.Since he needs to transmit some real time materials, the ''availability'' of the Web meeting services must be 99% or above.Thirty minutes after the Web meeting starts, Steve needs to drive to a client for another pre-scheduled visiting.He wants to continue this ongoing Web meeting in a voice-based format while he is driving.This scenario obviously requires context-aware services, which can automatically detect Steve's contextual changes.For example, a location tracking service needs to detect Steve's position change while he is moving.Meanwhile, an adaptation service needs to adjust Web meeting formats to match Steve's contextual changes due to location, activity, network and device changes.Format changes include from indoor meeting to outdoor meeting, from fixplace meeting to driving-based meeting, from wired-to wireless-based meeting, from notebook-to PDA-based meeting, and from video-based to voice-based meeting.
The remainder of this paper is organized as follows.Section 2 addresses related research.Section 3 presents JESSenabled context elicitation system featuring a context model for context description and contextual information collection.Section 4 presents our CA-SOA for contextaware Web service provision.Section 5 demonstrates the system along with experiment results and discussions.We conclude this paper in Section 6.

Web services and service oriented architecture
The emerged Web services technology provides a flexible and efficient approach to reuse existing Web-based applications and services.Web service technology concentrates not only on interoperability but also on how to describe, publish, locate and invoke Web services.A number of stan-dards and specifications created from industry and academia have contributed to the development of Web services, such as WSDL (http://www.w3.org/TR/WSDL) and UDDI (http://www.uddi.org/).Service providers can describe services in WSDL to specify what a service can do and how to invoke the service.A UDDI registry creates a standard interoperable platform that enables businesses and applications to quickly, easily, and dynamically locate Web services over the Internet.However, the above Web service infrastructure can only behave well in syntactical level and is lack of semantic information to support inferential capability.This motivates Web service a step further to semantic Web (Berners-Lee, Hendler, & Lassila, 2001).
Semantic Web description languages, such as DAML + OIL (http://www.daml.org/)and Web Ontology Language (OWL, http://www.w3.org/TR/owl-features/), provide predicate-like and description logic-based annotation of Web services to encourage inferential procedures on annotated Web services.The combination of semantic Web's expressive power and Web service infrastructure results in the concept of semantic Web services.As the first step toward semantic Web services, OWL-S (http://www.daml.org/services/owl-s/1.1/overview/) is a specific application for Web services by applying OWL on a service's capability representation.It supports Web service providers with a core set of markup language constructs for describing properties and capabilities of their Web services in an unambiguous, machine interpretable way.We choose OWL-S as the implementation language of our contextaware Web services.
Service oriented architecture (SOA) is a conceptual model that inter-relates services through well-defined interfaces and contracts between these services.The interface is defined in a neutral manner independent of hardware platforms, operating systems, and programming languages in which the services are implemented.This allows services built on a variety of such systems to interact with each other in a uniform and universal manner.Three fundamental roles exist in SOA -service providers, service requesters, and service matchmaker.The service providers publish services to the matchmakers.The service requesters send requests to the matchmakers when they need services.The matchmakers perform service matching to find available services and bind the services from the providers to the requesters.While Web services are moving toward semantic Web, the matchmakers in SOA are also favor semantic-based service matchmaking.
LARKS is a semantic matchmaker that performs both syntactic and semantic matching (Sycara, Klusch, & Lu, 2002).It can identify different degrees of partial matching based on five filters: context matching, profile comparison, similarity matching, signature matching, and constraint matching.Requesters can select any desired combination of these filters based upon different concerns, such as efficiency and computation cost.DAML-S/UDDI is another semantic matchmaker that expands UDDI to provide semantic matching (Sycara, Paolucci, Ankolekar, & Srinivasan, Author's personal copy 2003).It can perform inferences based upon subsumption hierarchy leading to the recognition of semantic matches regardless of their syntactical differences.DAML-S/UDDI adopts a flexible matching strategy based on inputs and outputs to identify similarities between requests and service's advertisements.However, although DAML-S/UDDI matchmaker expands functionality of UDDI registry to enable capability match, it does not take requesters' contextual information into account.Requesters may receive some invalid services, and they need to manually verify all matched services.In contrast, our context-aware SOA can provide automatic and better contextually matched services to meet requesters' context changes.

Context and context-aware applications
Context can be interpreted differently from various perspectives.In this research, we will address context from the aspect of mobile and pervasive computing.Schilit, Adams, and Want (1994) point out that one of the major challenges of mobile computing is how to exploit the changing environment with a new class of applications that are aware of context.They believe context encompasses more than just people's location; instead, context should also include environment's lighting, noise level, network communication, and even people's social situation.They also believe that context-aware applications should be able to adapt to changing environment according to the location of use, the collection of nearby people, hosts, and accessible devices, as well as changes to such things over time.Dey and Abowd (1999) define context as ''any information that can be used to characterize the situation of an entity.An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves''.They point out that certain types of context that are, in practice, more important than others, such as identity, location, activity, and time.Given a person's identity, on can acquire many pieces of related information, such as the person's contact information and preferences.Given a person's location information, one can determine what other resources or people are nearby and what activity is occurring close to the person.Given a timestamp or period of time, one can find out what events are taking place or what activities have occurred at the same time.Based on the four primary context types, Dey and Abowd (1999) further define context-aware system as ''if it uses context to provide relevant information and/or services to the user, where relevance depends on the user's task''.They also refer contextaware applications as applications that automatically provide information and take actions according to the user's present context as detected by sensors.In addition, context-aware applications look at who's, where's, when's and what's (that is, what a person is doing), and use this information to determine whythe situation is occurring.
In addition to the aforementioned definitions, there are many comprehensive survey articles and special issues on journals covering context and context-aware applications, readers can refer to articles such as Dey and Abowd's (1999) ''Toward a Better Understanding of Context and Context-awareness'', Korkea-aho's (2000) ''Context-Aware Applications Survey'', and Chen and Kotz's (2000) ''A Survey of Context-Aware Mobile Computing Research''.In addition, two special issues on journals can be found on ''Context-aware computing'' on IEEE Pervasive Computing (Abowd, Ebling, Hung, Lei, & Gellersen, 2002) and Human-Computer Interaction (Moran & Dourish, 2001), respectively.
In order to promote context-aware service provision, Kwon et al. have applied context-aware multi-agent approach for personal reminder and negotiation support systems (Kwon, Choib, & Park, 2005;Kwon, Shin, & Kim, 2006).They also utilize context-aware and ubiquitous computing technologies on decision making applications (Kwon, Yoo, & Suh, 2005;Kwon, 2006).Mostefaoui and Hirsbrunner (2004) propose a formal definition of service contexts to model a service's contextual information.Lemlouma and Layaida (2001) propose a framework to assert metadata information of Web contents.They both use Composite Capabilities/Preferences Profiles (CC/PP) as interoperable context representation to enable communication and negotiation of device capabilities and user preferences in terms of a service invocation.Zhang, Zhang, Quek, and Chung (2005) further propose extensions to CC/PP to enable transformation descriptions between various receiving devices.Besides, several OWL-based context models are presented (Broens, Pokraev, Sinderen, Koolwaaij, & Costa, 2004;Khedr & Karmouch, 2004;Khedr, 2005) to provide high-quality results of service discoveries beyond the expressive limitations of CC/PP.These researchers all utilize ontology to describe contextual information including location, time, device, preference, and network.
However, existing context definitions either focus on service requesters or on services alone.We argue that effective and efficient context-aware service provision needs to consider from both sides.In contrast to aforementioned related work, our approach stands out from three aspects: First, we formalize an ontology-based context model considering both service requesters and services.Second, we provide a JESS-enabled context elicitation with tailored contextual information collection.Third, we employ semantic matchmaking to enhance the recall and precision of context-aware service provision.

JESS-enabled context elicitation system
Context-aware Web service provision can be implemented by an event-driven reactive system.If an event is triggered when a context changes (e.g., location change), then a corresponding reaction to the changed contextual information is provided (e.g., providing a contextually matched Web services).Thus, we have designed our context-aware service provision as an event-driven rule base for responding to people's context changes, including the changes of condition, location, activity, device, network, and time.Since the construction of a rule base is incremental, new facts will be asserted when new contextual information is acquired, and new context elicitation rules will be inserted when new context types are considered.In contrast, facts and rules will be removed when they are no longer being true when people's contexts change.Since any insertion and deletion of facts and rules to an existing rule base may result in inconsistency or conflict, truth maintenance is needed to ensure the consistency of a rule base.We have developed a truth maintenance mechanism for verifying rule base concerning redundancy, inconsistency, incompleteness, and circularity to ensure the incrementally constructed rule base is sound and complete.For readers who are interested in this subject, please refer to our previous research of truth maintenance (Yang, Tsai, & Chen, 2003).

Ontology-based context model
Based on the four primary context types (i.e., identity, location, activity, and time) defined by Dey and Abowd (1999), we have developed an ontology-based context model, which is illustrated in Fig. 1.Two types of context ontologies -requester ontology and service ontology are developed for describing requesters and services, respectively.The major differences between the two ontologies are the definition profiles.The requester ontology contains profiles describing the four primary context types.A personal profile is used to describe requester's identity and preference; a location profile is used to describe location; a calendar profile is used to describe what, when, and where an activity occurred as well as whom are with the requester.The service ontology is OWL-S based, which contains service profiles describing the input, output, precondition, and effect of service execution.Please be noted that the attributes listed in Fig. 1 is selected for ease of illustration; the actual contextual information will be much more complicated in the real world.
Other than the profiles, both requester ontology and service ontology define Quality of Services (QoS) and environment profiles.A QoS profile contains functional and nonfunctional constraints.Functional QoS constraints can be described by response time and throughput; non-functional QoS constraints can be described by reliability, availability, and cost.An environment profile is used to describe computing and communication environment that contains network constraints, situated condition, and device constraints.Network constraints can be used to describe the types of communication protocols, such as GPRS, 3G, VoIP, and WiFi.Situated condition can be used to describe requesters' situation, such as in a meeting or driving condition.Device constraints are used to describe device's hardware and software configurations, which can be defined by Composite Capabilities/Preferences Profile (CC/PP) and User Agent Profile (UAProf).

Rule-based context elicitation with JESS
Context elicitation is a process of deriving the values defined by the pairs of (attribute, value) in the context ontology.As shown in Fig. 2, a JESS-enabled context elicitation system is designed comprising three phases -formfilling, context detection, and context extraction.In the form-filling phase, contextual information is acquired directly from requesters' inputs.In the context detection phase, we utilize various sensing and positioning techniques (e.g., GPS, RFID, and sensor networks) for location detection.In the context extraction phase, we utilize JESS rules to derive contextual information from both requester ontology and service ontology.
We use form-filling to construct requester ontology based upon requesters' inputs, e.g., personal, environment, calendar, and social profiles.As shown in Fig. 2, we implemented an ontology editor to prompt, receive, and organize input information.We also designed a portal service to keep historical contextual information that can be used to predict people's requesting behaviours and patterns.In other words, the portal helps to construct requesters' context automatically.In the form-filling phase, obtained requester-inputted contextual information is stored in the portal.
The goal of the context detection phase is to collect requesters' dynamic contextual information.We have designed and implemented two Web services to facilitate the process: requester context detection service and service context detection service.For example, we utilize smart devices and sensor networks to detect requesters' surrounding environments.When requesters log in, our engine detects and analyzes the kind of devices and network they are using so as to build environment profile.The information retrieved is then stored in the portal too.
We equipped our environment with a set of location detection services, which can be automatically invoked based on requesters' actual contexts.For example, if a requester, Steve, is outside of a building, a GPS location detection service will be invoked to return his location in terms of the building name.If Steve is inside of a building, an indoor tracking service provided by RFID will be invoked to return his location in terms of the room number.Once the location is positioned, our location detection services will decide whether to disclose the location based on requester's privacy preferences.One thing worth noting is that in our design, we consider privacy preferences in a dynamic manner and can be adjusted based on location and temporal constraints.For example, if Steve is in his office during his office hours, he is willing to disclose his office number to his colleagues.If he is out of town in a trip, however, he may only disclose his position to his family members.
If form-filling and context detection can not obtain requesters' contextual information, then we need to derive such information by context extraction.We define context extraction as a process of deriving contextual information from requesters' context ontology.Comprehensive contextual information can be extracted combining static and dynamic approaches.The static context extraction elicits a requester's default context from his/her predefined preferences and personal profiles.The dynamic context extraction deduces a requester's actual context from his/her calendar profile and social profile.
In the static approach, except for those required attributes that requesters must specify, other attributes defined in personal profile and preferences have predefined default values.As a result, our approach is to fill in the default values on behalf of requesters if they do not explicitly specify attributes' values.We refer this process as context wrapping, and we will address it in detail in Section 4. Service agents are designed to help service providers formally describe and wrap Web services with contextual descriptions obtained from the service ontology.Request agents are designed to help service requesters formally describe and wrap their service requests with requesters' contextual information obtained from the requester ontology.On one hand, broker agents take services' publishing requests from service agents and save service descriptions and contextual descriptions into service profiles; on the other hand, broker agents take requests from request agents and initiate context-aware matchmaking, which consists of two phases-capability matchmaking and semantic matchmaking.
As shown in Fig. 3, our service repository is designed to encompass a general UDDI Registry associated with service profiles.If the required services cannot be found by a capability matchmaking process in the UDDI Registry, the semantic matchmaker will be invoked.The semantic matchmaker will decompose service requests into a set of sub-requests, and then schedule an integrated composite service based on the decomposed requests.
Based on the CA-SOA, we present how to provide context-aware service request, publication, and discovery in the following sub-sections.

Requests' contextual description and wrapping
Service requests are generally specified with keywords or descriptions regarding inputs, outputs, pre-conditions, and effects of the requests.However, it will cause tremendous overhead if requesters need to manually input much contextual information.Thus, we utilize request agents to automatically wrap requests' contextual information.Fig. 4 indicates a step-wise procedure to describe and wrap requests' contextual information and transform it into a request package.
1.A request agent provides a request parser as an interface (shown in Fig. 5) for guiding requesters to input their request descriptions.2. The request parser transforms request descriptions to OWL-S. 3. The request agent instantiates the requester ontology to generate instances of requesters' static context profiles.4. The request agent provides a context wrapping service for obtaining requesters' static contextual information by tagging the attributes defined in requester's instances of static context profiles.5.The request agent enacts a context elicitation service for obtaining requesters' dynamic contextual information.6.The request agent wraps and packages the request along with requesters' contextual information.7. The request agent sends the request package to a broker agent.
A request package in OWL-S as shown below is wrapped to describe a request's contextual information.This partial OWL-S description denotes three conditions: first, the requester is willing to disclose his/her profiles since the value of attribute, Privacy, is ''Public''; Second, the requester is equipped with a ''PDA'' device connected to the Web through a ''wireless_LAN'' network; third, the requester is in a ''Driving'' situation and he/she is requesting for a Web service with ''99%'' availability.the found services that are considered as relevant; Recall is the fraction of the relevant services that has been found.We formally define them as follows: where A contains a set of relevant services been found, jAj is the number of services in A; R contains a set of services been found that are considered relevant, jRj is the number of services in R; and Ra contains a set of services as the intersection of the sets R and A. jRaj is the number of services in Ra.
We have implemented and compared three approaches of service discovery -keyword search, capability matching, and semantic matching.Let a service request of a Webbased meeting over the Internet is described by the following four service descriptions, Web meeting, net meting, tele-meeting, and wireless-meeting, respectively.The search results of using the three approaches are summarized in Table 1.Figs. 8 and 9 illustrate the results in diagrams.
As indicated in Figs. 8 and 9, for the three service discovery approaches, the Precision and Recall of semantic matching has better performance than the others.This indicates that the services discovered by semantic matching are more relevant because these services have similar contextual descriptions, and they are more likely to be in the same context domain.

Conclusion and future research
In this paper, we have presented a context model to formally define contextual description pertaining to service requesters and services.A JESS-enabled context elicitation technique is designed for collecting contextual information.Based on the context model and the JESS rule base, we presented our context-aware service oriented architecture (CA-SOA) for context-aware Web services provision including service request, publication, and discovery.We utilize OWL-S as a vehicle to carry contextual information.Although OWL-S is a known tool from the semantic Web society tailored for Web services descriptions, our context model and CA-SOA are not limited to OWL-S.For instance, we can use Web Services Agreement Specification (WS-Agreement) from Global Grid Forum or Web Service Level Agreement (WSLA) from IBM to carry the knowledge.
In our future research, we will continue to enhance our CA-SOA in the categories of rule base truth maintenance, request decomposition, service planning, and service verification.We also plan to conduct more experiments to examine performance metrics including efficiency of service composition, effectiveness of service verification, and reliability of service execution.

Fig. 4 .
Fig. 4. Procedure of wrapping requesters' contextual information into a request package.

Table 1
Service description and search results corresponding to the three approaches