Towards a Context-Based Service Composition Framework - CiteSeerX

Proceedings of the International Conference on Web Services, ICWS'03, Las Vegas, Nevada, 23 - 26 June 2003. pp. 42-45

1

Towards a Context-Based Service Composition Framework Soraya Kouadri Mostéfaoui, Béat Hirsbrunner Department of Computer Science University of Fribourg Chemin Du Musée 03, Pérolles CH-1700, Fribourg, Switzerland Abstract— Services can be defined as software components, or building blocks that are provided in order to be assembled, and reused in a distributed Internet-based environment. The development of new services through the integration of existing ones (referred to as service composition) is generating considerable interest in recent years in several computer science communities. Existing service composition systems miss out on the opportunity of enormous benefits by exploiting useful contextual information relevant to service discovery and composition. This paper presents the CB-SeC framework (CB-SeC stands from Context Based Service Composition). The approach adopted in this framework is the combination of context-aware computing and agent technology, in order to provide better user-tailored services in pervasive environments. Keywords— Context-aware computing, mobile services, multi-agent systems, pervasive computing, service composition.

I. I NTRODUCTION

S

E rvices can be defined as software components, or building blocks that are provided in order to be assembled, and reused in a distributed Internet-based environment [1] [10]. Development of customized services by integration of existing ones (referred to as service composition) [2], has received lot of attention in the last few years. Existing service composition systems address the problem of composing services that are available over a fixed network infrastructure. However, while computing today becoming increasingly pervasive, there is an unaddressed need of more sophisticated context-aware service discovery and composition support. Our work considers this aspect by combining the agent technology and the context information to build customized composite services. Nowadays, for most of the context-aware applications, the usual context parameter is location. Most of them ignore the temporal aspects of context, including the need to represent histories. The framework presented in this paper overcomes these shortcomings. The context awareness we have promoted considers the user’s context, the computing context, the time context, the physical context and even the context history. The remainder of this paper is organized as follows. Section 2 presents the context modelisation in CB-SeC. In Section 3, the main components of the CB-SeC framework are introduced. Section 4 and 5 describe the context layer and the middleware services layer respectively. Finally Section 6 draws the conclusions.

II. C ONTEXT M ODELISATION IN CB-S E C A. Context Definition in CB-SeC Composed of con (with) and text, context refers to the meaning that must be inferred from the adjacent text. Anind Dey [8] [9], maps this definition to the mobile computing world, and defined context as: "Any information that can be used to characterize the situation of an entity, where an entity can be a person, a place, a physical or a computational object". Given this definition, the amount of information that can be included in context is very vast. However nowadays, for most of the context-aware applications, the usual context parameter is location. As part of our research we needed to clarify the types of context required in a service discovery and composition process. Our context model consists of a set of elements along five axes, (Figure 1). 1. User context: such as the user role, identity, age, location, preferences, social situation...etc. 2. Computing context: such as network connectivity and nearby resources (printers, displays, and workstations) ...etc. 3. Time context: such as time of a day, week, month, and seasons of the year...etc. 4. Physical context: such as weather, temperature...etc. 5. Context history: more importantly, when the user, computing, and physical contexts are recorded across a time span, we obtain a context history [3], which is also useful when discovering and composing services. These are only a slice of all possible elements that make up a full definition of context, but nonetheless potentially useful for the service discovery and composition. B. Mathematical Modelling of Context in CB-SeC In the previous section, we have identified five types of context that are relevant in a service discovery and composition process; using these identified types we model the context information as a recursive1 function as shown bellow: context(t) = f (u, c, t, ph, h), this shows that context is function of users, computing context, the time, the physical context, and the context history2 . And u = f’(role, pref, soc, loc, pm) i.e. the user is in turn represented by its role (student, staff ...etc), its preferences which may vary depending on the devices capabilities and other context conditions. Therefore we should provide for means to ex1 recursivity

Soraya.Kouadri.M, to whom correspondence should be addressed.

2h

is used in order to capture the context history = context(t-1)

2

 

User Context

Computing Context

  Context

role location prefernces social situation permission profile

Time Context

 

The architecture of the CB-SeC framework is depicted in (Figure 2). CB-SeC is composed of four core layers, each of them will be described in turn.

network connectivity device capabilities server load

current time day year month season

Physical Context

A. CB-SeC Architecture

  weather

temperature light

 End-User Applications CB-SeC Midllware

 

Midlleware Services Layer Context Layer

Context History

Physical Layer Fig. 1. Modelling Context in CB-SeC. Fig. 2. The CB-SeC Architecture.

press conditions applying to the preferences attributes. Not all the user preferences will always be satisfiable. Therefore, the user should be empowered to specify preference priorities. A maximum priority means that a particular service or the overall composite service shall not be provided if the preference cannot be satisfied. The user is also represented by its social context, its current location (indoors, outdoors, building, room...etc), as well as what we called the permission profile, i.e. which service can connect the user and when, (e.g. when in class between 8h00 and 12h00 I do not want to by disturbed by SMS messages). We have also: c = f”( s, d ), i.e. the computing context is in turn function of services s, and resources d available during the system’s lifetime. Finally the physical context: is described by any other entities residing in the environment and which could be relevant to the actual application, such an entity can for example be the weather information, the temperature of a room ...etc. Modelling contextual information as shown above allows us to capture many aspects of the context. Firstly both the static and the dynamic parts of context can be expressed, constants define the static part (e.g. date of birth, name...etc), and variables define the dynamic part of context (location, current activity...etc). Temporal aspects are expressed by the context history which is captured by the recursivity of the function (context(t) depends on context(t-1)). Finally the nested form of functions captures the relationships and dependencies that exist between the context information. This contextual information is acquired either through the sensor agents, or through the use of special messaging between the agents in the system.

III. T HE C ONCEPTUAL F RAMEWORK In this section, we describe a general layered architecture that enables a context-based service discovery and composition in pervasive computing environments.

• The Physical layer: the physical layer forms the lowest layer in the CB-SeC architecture, it encompasses all the physical entities of the system. Due to the dynamic changes in the availability of physical devices, network bandwidth and connectivity,the system has to classify those entities monitoring constantly their changes. In such a way the upper layers have always a consistent description of the physical dimension. • The Context layer: this layer is responsible for gathering and processing contextual information. It consists of two modules: the Context Gathering Engine (C-GE), and the Context Data Base (C-DB). We will come back to this layer in greater detail when in section 4. • The Middleware Service layer: this layer is the core part of our framework, it is in turn composed of four modules, the ContextBased Service Discovery module, the Context-Based Service Composition module, the Service Execution module, and the Caching Engine. These modules are tightly coupled with each other due to their inter-dependencies; each of them will be described in details in section 5. • The End-User Application layer: it embodies any software that utilizes our context-based service composition platform. The application layer encompasses different GUI facilities with whom users can customize their applications by setting their preferences, permission profiles, i.e. which service can connect the user and when. In order to provide more personalized and helpful composite services.

IV. T HE C ONTEXT L AYER We have identified two main operations necessary for contextawareness in the CB-SeC system, namely context acquisition and context representation. For each of these components we have associated a computational module, respectively, the Context Gathering Engine and the Context Data Base. A. The Context Gathering Engine (C-GE) The Context Gathering Engine (C-GE) is responsible for gathering, processing and interpreting the users contextual infor-

3

mation. It consists of a Multi-Agent System (MAS), in which each agent is associated with one type of contextual information. The agents are responsible to gather the data provided by the software and hardware sensors, to interpret the gathered raw sensor data into meaningful information and finally to extract the specifications such as time, location. This does not mean that all the contextual data must be gathered and transferred via the wireless link. It may rather contain references to external resources, such as the device defaults that can be retrieved from the device vendor’s web site. B. The Context Data Base (C-DB) The context data base is acting as a bridge repository, it receives the specifications of the contextual information for each user from the agents of the C-GE. These specifications are translated into XML documents for subsequent processing by the Context-Based Service Discovery Module of the above layer. An important part of the context database is the classification of the context information into context types, e.g both the GPS and the network based locator provide location information. The specification of context type is achieved using an XML template that defines the kind of information this type offers. Using this approach, the Middleware Services Layer can retrieve the specific contextual data in a way that is decoupled from the service used for acquiring the data. This method of hiding the actual mechanism for retrieving contextual information, allows the CB-SeC framework to coordinate the access to context for different applications. The first time a user triggers a service composition its context profile is created; later when she triggers another service composition its context profile is not recalculated, but simply updated according to the requirements of the new composite service (i.e. only context information that are relevant for the current composition are updated with the new values). V. T HE M IDDLEWARE S ERVICES L AYER The Middleware Services Layer is responsible for the process of carrying out the discovery, composition and execution of services. It is composed of four modules: the Context-Based Service Discovery Module, the Context-Based Service Composition Module, the Service Execution Module, and the Cache. Each of these modules will be described in turn after introducing how services are modelled in CB-SeC. A. Service Modelisation The service modelisation (description) is a meta-level representation of the actual real world service; it describes the behavior of the service [5]. Discovery of a service involves the discovery of its description that can be used to access the service. In this sub section we take a look at how CB-SeC describes its services. Each service description must contain three parts: the interface description, the capsule, and the constraint description. • The interface: contains information regarding the operations that can be invoked in a service and their respective input and output parameters [5]. • The capsule: gives information on where the service is located (URL) and how it can be accessed, the invocation protocol(s)

(HTTP: HTTPS, SMTP...etc), the types(s) and the port(s). • The constraint description: it is often necessary to describe the constraints regarding the parameters of a service, it may exist two service implementations having the same interface description but having different constraint descriptions. B. The Context-Based Service Discovery Module (C-SD) This module is required for the proper functioning of the service composition module. An important component of the C-SD is the Context Manager Agent, (CMA) that functions is to match and recommend appropriate services among a possibly large set of service instances, taking benefits from context-information. When a client requests a service it may be necessary to compose a complex service out of the registered basic services. The problem of splitting the request into sub services is complex and goes into the domain of planning in AI, which is outside the scope of our present work [6] [7]. The current implementation of our architecture uses UCM’s social laws (UCM stands from Ubiquitous Coordination Model) to decompose complex service requests into basic services, and to determine the process model of execution. However due to the flexibility of our system brought by its layered architecture, it is a straightforward exercise to plug in any other external planning module that will provide it with a process model of execution for a composite service. Due to lack of space we are unable to provide a greater detail of UCM, more details are available in [11]. Clients request services in a context describing characteristics, and time of the requested service, furthermore context contains information about the client and its preferences. The CMA’s first job is to extract the contextual information form the Context-Data Base, then using these information it tries to discover the basic services against the ones registered on its vicinity [7] (using the location attribute), it first matches the user’s query as well as the user’s device capabilities (using the computing context) into the nearby service registry and progressively increases its search radius to discover all the different services necessary for the composition. The CMA has to figure out otherend requirements, i.e device capabilities anticipated by service implementations. It can get such an information from the constraints field shipped with the services. The previous step produces a set of candidate services, the CMA is then responsible for iterating through this set, and for picking the best offers according to the current context and the constraints set by the service providers. In other words services are filtered and ranked according to the evaluation of the context parameters, to ensure that clients are given the best service instances [4]. C. The Context-Based Service Composition Module (C-SC) This module is responsible for carrying out the process on managing the discovery of services to yield a composite service. It further refines the set of selected services using the remaining context parameters that are relevant for the composition rather than for the discovery. Example of such a parameter can be the user preferences that are applicable to the overall composite service e.g. a person planning for her summer vacation wont spend more than 2000CHF for the whole vacation composite service i.e. (hotel service, car rental service, attractions,

4

plane tickets ...etc), another example may be the permission profile set by the user (e.g when in class between 8h00 and 12h00 I do not want to receive SMS messages). The composite service which satisfies all the user preferences is chosen and the corresponding capsules (i.e. information about the services addresses, ports, and invocation protocols) are sent to the Service Execution Module. In the mean time a copy of the process model of the composite service as well as its context is kept in cache. D. The Service Execution Module (SE) This module is responsible for carrying out the execution of the composite service. Prior to this the Context-Based Service Composition module provides a feasible order in which these services can be executed. Mainly two types of execution exist according to the nature of the service, which can be either an e-service (electronic-service) or a m-service (mobile-service) [10]. For mobile services execution is always local to the device of execution since the service itself has been transported to the device. However for electronic services the execution can be remote or local. In the remote invocation the client sends remotely a request to a provider asking the execution of a service. The execution takes place in the provider platform. In local invocation the client asks remotely to transfer a copy of the service to its site. After being transferred, the execution takes place in the client site. E. Caching and Profiling Caching is one of the most frequently neglected aspects of the actual service composition platforms. CB-SeC overcomes this shortcoming by implementing a Caching Engine. The principle of caching is to store expensive (time-consuming) information to create, so it can be automatically reused. For example if a composite service requires a complex calculation, caching may save processing time, speed up the response rate for the client and lessening the burden on the service sever’s CPU. In other words the Caching Engine stores the resulting process model of a query as well as its context, and reuses it for other clients that supply the same query with the same parameters. Caching is also useful when the same client supplies the same query in an other context, first the cache is checked if the same composite service would satisfies the new query needs (according to the new context), if not the composite service is decomposed, services that do not meet the new requirements are composed-out, and a new discovery/composition process is triggered for the composed-out services. The new discovered services are composed-in with the cached ones. Finally the resulting composite-service is recommended to the user, and a copy of the process model is kept in cache as well as its context. VI. C ONCLUSIONS Context-awareness is going to become a major trend in future wireless services. This paper contributes to this topic by specifying a context-based service discovery and composition framework. Unlike others, the approach adopted in our framework is able to capture aspects of context, to enable much more sophisticated composition of services. In other words services are incrementally filtered and ranked according to the evaluation

of the contextual information, in order to ensure that the clients are given the best composite services at the right time in the right place. The context awareness we have promoted considers the user context, the computing context, the time context, the physical context and even other information provided by other entities residing in the system. The main characteristics of the CB-SeC framework are flexibility and adaptability. Flexibility is provided by the layered architecture, allowing tasks and functionalities to be distributed on the different layers of the model. Each layer has certain functions to fulfill, and keeps the processing details in its own layer. Other layers receive only the results they need. Adaptability is achieved by the context awareness mechanism embedded in the system. In conclusion, it should be mentioned that this was preliminary work so there are some aspects that should be the focus of further investigations. We are continuing the development of the CB-SeC architecture. In order to have a verification of the model two projects based on CB-SeC are under the way, emphasizing the use of the framework. One is a diploma project that explores the use of CB-SeC in a library reminder system. The other is a smart campus messenger decks, under development at the Parallelism and Artificial Intelligence Research Group (PAI), at the University of Fribourg. Furthermore, work continues on representing and recognizing context. R EFERENCES [1] B. Pernici and M. Mecella. Designing components for e-services. In proceedings of the VLDB Workshop on Technologies for E-Services, Cairo, Egypt (2000). [2] Benatallah B, Dumas M, Sheng QZ, Ngu A. Declarative Composition and Peer-to-Peer Provisioning of Dynamic Web Services. In the proceedings of 18th International Conference on Data Engineering (ICDE 2002), Eds. Rakesh Agrawal; Klaus Dittrich; San Jose, California USA, IEEE Computer Society, pp297-308, February (2002). [3] Guanling Chen and David Kotz, A Survey of Context-Aware Mobile Computing Research, Dartmouth Computer Science Technical Report TR 2000381, (2000). [4] C. Lee and A. Helal, Context Attributes: An Approach to Enable Contextawareness for Service Discovery, Third IEEE/IPSJ Symposium on Applications and the Intrnet, to be held in Orlando, Florida, January (2003). [5] A. Jagatheesan and A. Helal. Sangam: Universal Interop Protocols for E-service Brokering Communities using Private UDDI Nodes, IEEE Symposium on Computers and Communications -ISCC’2003, to be held in KEMER - ANTALYA, TURKEY, June/July (2003). [6] K. Erol, J. Hendler, and D. Nau. HTN planning: complexity and expressivity, In Proc. AAAI., (1994). [7] Dipanjan Chakraborty, Filip Perich, Anupam Joshi, Timothy Finin, Yelena Yesha, Middleware for Mobile Information Access 5th International Workshop on Mobility in Databases and Distributed Systems, in conjunction with DEXA (MDDS’2002), Aix-en-Provence, France September (2002). [8] K. Anind Dey, D. Gregory Abowd, and D. Salber A Context-Based Infrastructure for Smart Environment . In the proceedings on the first International Workshop on Managing Interactions in Smart Environments (MANSE) (1999). [9] A. Dey Understanding and Using Context. Personal and Ubiquitous Computing, Vol. No1 (2001). [10] Z. Maamar, B. Benatallah, and Q. Z. Sheng. Towards a Unified Composition Framework for E-M Services. In the Proceedings of the First Workshop on Ubiquitous and Embedded wearable and mobile devices.Bologny, Italy, July (2002). [11] M. Courant, A. Tafat, B. Hirsbrunner. A generic Approach of Coordination for Ubiquitous Computing. Technical Report, Number 01-03, University of Fribourg, Switzerland February, (2003).