Context-Aware Web Service Composition based on AI Planning

ABSTRACT

A web service is an application that is published on the web and can be discovered and used automatically. In many cases, a web service cannot provide the capability that the user has requested. Therefore, according to the user request, it should be possible to combine various services and produce a new composite service for the user request. Context is the information that can be used to characterize the situation of an entity. In this paper, we present our context model for web service composition and implement the newly proposed framework for context-aware web service composition and show how the newly proposed framework reduces the number of failures and composition time.

Introduction

Web service composition is the process of constructing a composite service from atomic services in order to achieve a specific task. Traditionally, composition requests are precompiled and stored in repositories. This approach is impractical when dealing with a potentially large number of contextual commands. So, automated web service composition is essential (Vukovic 2007). AI (Artificial Inteligence) planning techniques are used for automated web service composition.

Context is the information that can be used to characterize the situation of an entity. An entity is a person, a place, or object that is considered in interaction between a user and an application. A system is context-aware if the context is used to provide relevant information (Dey, Salber, and Abowd 2001).

Context-aware applications are conformed to changes in computing environment. For example, they may react to context changes such as devices available, time constraints, location, and user requirements. A framework was developed for finding a restaurant and this framework includes mechanisms for automatic recovery from failures that may occur during the web service composition and execution process. This framework is based on TLPlan planning and uses user context information and does not consider service context information (Vukovic 2007).

Context-aware web service composition using planning techniques was done based on user requests and user context information, and services context information was not considered. Therefore, the number of failures and composition time were increased.

In this paper, the proposed framework that is called CA-SCP (Context-aware service composition based on planning), the preliminary choice for web services composition is made at the planning stage. Then, the final choice is made from the preselected options based on user context information and service context information. As a result, the appropriate services are run based on the user requests and the quality of services. Also, the number of failures and composition time will be decreased. The proposed framework is based on planning and introduces a new approach for web service composition, wherein both the user context and the service context are taken into account while taking composition decisions.

This paper is organized as follows. First, some background on AI planning and context models are presented. Then, we present our context model and the proposed architecture and introduce a new planning algorithm and discuss the performance of the planners. Finally, evaluation results and related work are displayed. The last section concludes the paper.

Background

Planning

AI planning techniques are used for automated web service composition. Planning is an approach of problem-solving and focuses on selecting suitable actions and ordering them in an appropriate sequence so as to achieve some goals. It allows businesses and organizations to cut costs considerably while at the same time increases their ability to handle the dynamic nature and complexity of today’s business environment (Chan, Bishop, and Baresi 2007).

Hierarchical task network planning

Hierarchical Task Network (HTN) is one of the best methods for planning problems. Simple Hierarchical Ordered Planner 2 (SHOP2) is a domain-independent HTN planning system. The appropriate algorithm for our problem is JSHOP2. The reasons for our choice are detailed below.

HTN planning creates plans by task decomposition. The goal of HTN planners is to produce a sequence of actions that perform some activity or task by using task decomposition. The planning domain describes a set of operators and a set of methods, which define the decomposition of a task into subtasks (Chan, Bishop, and Baresi 2007).

One difference between SHOP2 and most other HTN planning systems is that SHOP2 plans for tasks in the same order that they will later be executed. This reduces the complexity of reasoning by removing a great deal of uncertainty about the domain, thereby making it easy to incorporate substantial expressive power into the planning system. SHOP2 allows use of different types of precondition constraints for service operators. A key idea in using any HTN planner is to design a set of methods that encode something similar to standard operating procedures that capture multistep techniques for refining a task. Some kinds of domain characteristics are much more natural to express in an HTN formalism (Nau et al. 2003).

JSHOP2 is the Java implementation of SHOP2 based on the decomposition of tasks. JSHOP2 knows the current state of the world at each step of the planning process. Also, JSHOP2 in the preconditions of operators and methods can mix numeric and symbolic computations. It can be used to create domain-specific planning algorithms (Ilghami 2006).

JSHOP2 planning consists of the following parts (García 2011; García and Ortega 2009):

1. Tasks: A task represents an activity for execution. A task consists of a task symbol, which is followed by a list of arguments. The task symbol is the name of the planning operator to use, and the arguments are the parameters for the operator. A task may be primitive or complex. A complex task decomposes into smaller tasks by using a method.

2. Operators: Operators show how a primitive task can be performed. They are applied to a system in order to change the situation. Operators consist of a precondition and a list of symbols. The precondition specifies the conditions under which an operator can be performed. In SHOP2, the operator precondition can be omitted, but this is not the case in JSHOP2. Also, the range of possible symbol names in JSHOP2 is not as large as in SHOP2.

3. Methods: Methods show how to decompose a complex task into subtasks. Methods are defined with the precondition and the task list. The precondition describes the conditions under which the decomposition is performed. The task list is the sequence of simpler tasks that is performed in order to apply the method.

4. Axioms: The precondition of each method or operator may include conjunctions, disjunctions, numerical computations, and external function calls. In addition, axioms can infer preconditions that are not explicitly asserted in the current state. These axioms are written in a Lisp-like syntax. For example, (:—head tail) shows head is true if tail is true.

Context models

A context model defines how context data are structured and stored. A context model is needed to define and store context data in a machine processable form. Context modeling approaches are classified based on the data structures used for representing and exchanging contextual information in system (Dustdar, Baldauf, and Rosenberg 2007; Nalepa and Bobek 2013):

• Key-value models. These models represent the simplest data structure for context modeling. They are used in various service frameworks to describe the capabilities of services. The key is usually a name that defines a context property. The value represents current state of the context property. When the keys match the actual context values, an action is triggered. Key-value model does not provide formalization of the model.

• Markup scheme models. These models use a hierarchical data structure consisting of markup tags with attributes and content.

• Graphical models. These models use a graphical notation to express knowledge. For example, UML (Unified Modelling Language) diagrams are used for supporting software development, ERD (Entity Relationship Diagram) diagrams are used in designing relational databases schemes, and BPMN (Business Process Model and Notation) is used in process modeling.

• Object-oriented models. Modeling context by using object-oriented techniques is used in these models. These models use various objects to represent different context types.

• Logic-based models. Logic-based models have a high degree of formality. Typically, facts, expressions, and rules are used to define a context model. These models are used to manage the aforementioned terms and allow to add, update, or remove new facts. The inference process can be used to derive new facts based on existing rules in the systems. These models enable automated inductive and deductive reasoning on context information.

• Ontology-based models. Ontologies represent a description of the concepts and relationships. Therefore, ontologies are a suitable instrument for modeling contextual information and high and formal expressiveness and the possibilities for applying reasoning techniques.

Context modeling

Context model of the issue of this article is the key-value model. The reasoning of choice in key-value model is that this model describes a simple matching engine and the context property and the capabilities of system. The scenario for this article is finding the direction of a restaurant requested by user. The context in this system is represented by three keys: user request, user context information, and service context information. Due to user requests, user context information, and service context information, when the keys match the context values, web service composition is performed and restaurant direction of user requests is specified. User request is finding restaurant direction. User context information includes user location. Service context information includes response time, availability, and throughput. For example, user is located in Loc1 and requests to access the restaurant Name1. Figure 1 shows the context model of the issue of this article.

Figure 1. The context model of the issue of this article.

CA-SCP architecture

This section describes the architecture of the proposed framework that is called CA-SCP. The architecture of the CA-SCP framework for context-aware web service composition consists of two main steps. The first step is the composition request that is created by user. The process of web service composition is started with user requests. The next section includes user context information. Also, service context information is used in the composition request. The next layer uses user requests, user context information, and service context information to produce a planning domain and a planning problem for the service composition. JSHOP2 uses the domain definition and the problem definition and produces a planner to perform list of services. The problem definition defines user requests, user context information, and service context information. In the domain definition, web service composition is based on user context information and service context information. The advantage of the new planning strategy for web service composition is the proposed framework uses user requests, user context information, and service context information. So, the services that do not have the appropriate conditions are not selected in web service composition, and the appropriate services are run based on the user requests and the quality of services. Also, the number of failures and composition time will be decreased. Figure 2 shows the CA-SCP architecture.

Figure 2. Architecture of the CA-SCP framework.

The scenario is finding a restaurant. Web services consist of a restaurant finder service, which provides a directory of available restaurants, a directions finder service, which computes the driving directions to a given restaurant and a translation service. The process of web service composition is started with user requests. For example, user requests for direction to Name1 restaurant. User context information includes user location, and user is driving. For example, user is located in Loc1 and is driving. Also, service context information includes response time, availability, and throughput. The next layer uses user requests, user location, response time, availability, and throughput and produces a planning for the service composition. JSHOP2 planning uses the domain definition and the problem definition and shows direction to Name1 restaurant.

Implementation

Planning in JSHOP2 consists of two files, the domain file and the problem file. The domain file defines the methods and the operators. The problem file defines objects that take part in the problem and the initial state and goals (García and Ortega 2009).

In our new planning algorithm, the problem definition defines user requests, user context information, and service context information. In the domain definition, web service composition is based on user context information and service context information, and both the user context and the service context are considered in service composition. So, the services that do not have the appropriate conditions are not selected in web service composition. As a result, the appropriate services are run based on the user requests and the quality of services. JSHOP2 uses the domain definition and the problem definition and produces a planner to perform list of services. Figure 3 displays steps for planning.

Figure 3. Steps for planning.

Domain definition

The domain defines the methods and the operators. Figure 4 displays implementation of the operators and methods for this example. Figure 5 shows the domain definition. The methods and the operators consist of the following:

• Load-property operator shows response time and availability and throughput if their values do not conform to response time < 128, availability > 98, and throughput > 12. These conditions are for the implementation of appropriate services based on papers (Al-Masri and Mahmoud 2007; Vaadaala, Rajeswara, and Venkateswara 2013).

• Load-direction operator shows restaurant, direction, and user location.

• Get-direction operator shows direction, user current location, and user goal location.

• Translate-direction operator is used for translation of the direction.

• Restaurant-at method finds restaurant and shows restaurant and user current location.

• In-road-delivery method finds direction and translates direction and shows direction, restaurant, user current location, and user goal location.

• Direction-at method finds direction and shows direction and user location.

Figure 4. The implementation of the operators and methods for this example.

Figure 5. The domain definition.

The definition of the problem will change when the user request and goals change. The definition of the domain will be the same, and all the problems are run in the domain.

Problem definition

The problem file defines objects that take part in the problem and the initial state and goals. The problem definition describes the environment that is applied to the domain. It also displays initial value of the variables and the relationships between different models components. It is necessary to define the plan (García and Ortega 2009). Figure 6 displays the problem definition. The problem definition describes restaurant, user current location, user goal location, response time, availability, and throughput.

Figure 6. The problem definition.

In unordered tasks, restaurant-at shows restaurant and user current location. Property-at shows restaurant, user current location, response time, availability, and throughput. The application consists of a series of directions and roads. A direction belongs to a road, and direction cannot get out of that road. Each road is accessed in some locations. For example, road2 is accessed in Loc2-1, Loc2-2, and Loc2-3.

JSHOP2GUI1.0.1

Although the JSHOP2 command line obtains a planning, it is difficult to analyze the different steps during the planning process. The graphical user interface (GUI) for JSHOP2 solves this problem by providing a way to analyze the task decomposition tree. The goal of the GUI is a quick and easy way to work with a program and users can see the graphical stages of the planning. Its main advantage is easy analysis of the results and finds possible errors in the algorithm (García and Ortega 2009). Figure 7 displays JSHOP2GUI program execution. The actions performed by JSHOP2GUI to find plans and a series of steps are represented in the GUI.

Figure 7. JSHOP2GUI program execution.

The main window of the GUI shows the task decomposition tree, and each node represents a task atom, and complex task is decomposed into subtasks. A blue node displays an unordered task, and yellow nodes display the planning process. The leaf nodes have a number surrounded by brackets preceding their task atom name that displays the position of action in the sequence of actions in the planning process. When a plan is found, a dialog box will be displayed that sequentially lists the current plan and how many total plans can be found in the problem (Shin 2006). Figure 8 shows what number the plan can be found in the problem.

Figure 8. Plans are found in the problem.

The current state window displays the state of the world when the selected task atom was encountered in the planning process. The step information window displays related information about the current step in the planning process. In reduced step, this window displays the name of the method used to decompose the complex task. In state-changed step, this window displays the changes made to the current state by the initial task. The control buttons allow the user to iterate through steps of the planning process (Shin 2006).

Evaluation

This section presents the evaluation of the implementation of the CA-SCP framework for context-aware service composition. Experiment environment consists of the following:

1. CPU: Intel Core(TM)i5 (2.40 GHz);

2. MEMORY: 4.00 GB;

3. OS: Windows 7 (64-bit);

4. JAVA: 1.5.0.09.

Experiments

The experiments are similar to the proposed approach by Vukovic (2007). The experimental evaluation shows the framework’s ability in the following experiments:

• the increasing number of composition requests;

• the reduction of number of failures;

• the increasing number of composition requests that have achieved to the goals.

There are two steps in the experiments. First, according to the CA-SCP framework, service context information in service composition is considered. Secondly, service context information in service composition is not considered. The results of the second step are similar to the results of the experiments in base thesis (baseline) (Vukovic 2007). The experiments use QWS dataset developed by Eyhab Al-Masri and Qusay H. Mahmoud. The parameters that are measured in experiments include composition time and the number of failures. Our scenario for the implementation of web service composition is as follows:

1. We are located in Loc8-1 place and want to go Name1 restaurant. Service context information to find Name1 restaurant includes response time which equals 93, availability which equals 96, and throughput which equals 13. This service has the appropriate specifications and runs.

2. We are located in Loc8-3 place and want to go Name2 or Name5 restaurants. Service context information to find Name2 restaurant includes response time which equals 302, availability which equals 89, and throughput which equals 7. Also, service context information to find Name5 restaurant includes response time which equals 102, availability which equals 91, and throughput which equals 15. So, the service that has appropriate specifications is run and shows the direction of Name5 restaurant to the user.

3. We are located in Loc6-5 place and want to go Name7 restaurant. Service context information to find Name7 restaurant includes response time which equals 284, availability which equals 86, and throughput which equals 3. This service does not have the appropriate specifications and does not run.

Figure 9 displays the time that the planner could not find a solution for the composition request and the request has failed. The average time of a failed request takes approximately 333 ms (Vukovic 2007).

Figure 9. The average time of failed requests (Vukovic, 2007).

Experiment-1: Measuring the increasing number of composition requests

This experiment displays composition time to which the system responds to increasing number of concurrent composition requests. The number of concurrent composition requests was increased from 1 to 100. First, according to the CA-SCP framework, service context information and user context information and user requests are considered in service composition. Table 1 shows comparison of number of concurrent composition requests and composition time in the CA-SCP framework.

Table 1. Number of composition requests and composition time in the CA-SCP framework.

Number of composition requests	4	35	50	70	80	100
Composition time (ms)	3000	10,000	15,000	30,000	37,000	58,000

Secondly, according to the base thesis, user context information and user requests are considered, and service context information is not considered in service composition. In the CA-SCP framework, the services that do not have the appropriate conditions are not selected in web service composition. According to the fact that the average time of a failed request takes approximately 333 ms, the time of service composition will increase in the base thesis. So, the composition time in the CA-SCP framework is less than the base thesis and in the CA-SCP framework, for 100 requests, 15% of composition time is improved. Figure 10 shows comparison of number of concurrent composition requests and composition time.

Figure 10. Comparison of number of concurrent composition requests and composition time.

Experiment-2: Measuring the reduction of number of failures

In this experiment, the number of achieved goal conditions was compared to the total number of goal conditions. First, according to the CA-SCP framework, service context information and user context information and user requests are considered in choosing services for implementation. Secondly, according to the base thesis, user context information and user requests are considered and service context information is not considered in choosing services for implementation, and the number of failures in the base thesis will increase. Figure 11 shows the results of this experiment.

Figure 11. Comparison of percentage of number of achieved goal conditions and composition time.

In the CA-SCP framework, the services that do not have appropriate conditions are not selected in web service composition, and the percentage of number of achieved goal conditions is increased. So, the number of failures in the CA-SCP framework is less than the base thesis, and in the CA-SCP framework, for 100 composition requests, 30% of failures is improved.

Experiment-3: Measuring the increasing number of composition requests that have achieved to the goals

This experiment displays increasing number of composition requests that have achieved to the goals on the composition time. The number of composition requests that have achieved to the goals varied from 1 to 60. First, according to the CA-SCP framework, service context information and user context information and user requests are considered in choosing services for implementation. Table 2 shows the number of composition requests and composition time in the CA-SCP framework.

Table 2. Number of composition requests and composition time in the CA-SCP framework.

Number of composition requests that have achieved to the goals	10	20	30	40	50	60
Composition time (ms)	5000	7000	13,000	20,000	31,000	42,000

Secondly, according to the base thesis, user context information and user requests are considered and service context information is not considered in service composition, and a number of requests may fail. According to the fact that the average time of a failed request takes approximately 333 ms, the time of service composition will increase in the base thesis. Figure 12 shows the results of this experiment. So, the composition time in the CA-SCP framework is less than the base thesis, and in the CA-SCP framework, for 100 requests, 17% of composition time is improved.

Figure 12. Comparison of number of composition requests that have achieved to the goals and composition time.

Related work

This section describes related work in two main research categories: planning-based web service composition and context-aware web service composition.

Planning-based web service composition

In the following, we introduce web service composition methods based on AI planning. Table 3 compares the planning methods.

Table 3. Comparison of the planning methods.

system	Golog	PDDL	SHOP2	OWLS-XPlan	Sword
Process generator technique	Logical programming	programming	HTN planning	HTN planning, FF planning	Entity Relation
WS standards support	OWL-S	OWL-S	OWL-S	OWL-S	XML
	WSDL	WSDL	WSDL	WSDL,OWL
Hierarchy	No	No	Yes	Yes	No
Concurrency	Yes	No	No	No	No
Scalability	No	No	Yes	No	No
Automation level	Semi-automatic	Automatic	Automatic	Automatic	Automatic
Composition at runtime	Yes	Yes	Yes	Yes	No
Extended goals	Yes	No	Yes	Yes	No
Complex object	No	Yes	No	No	No

PDDL (Planning Domain Definition Language) is a widely accepted language used in AI planning to make planning problems and domains uniform. Planning tasks specified in PDDL consist of two files, a domain file and a problem file. The domain file is composed of the predicates that are used to describe the knowledge in the world and the actions that can change the world states. The problem file includes objects in the world, initial state, and goal specification (Yang and Zheng 2010). Golog is a logic programming language built on top of the situation calculus. The Golog language is a high-level programming language, and it is particularly designed for the specification and execution of complex actions in dynamic domains. Further, Golog is adopted as a natural formalism for representing and reasoning about problems (Chan, Bishop, and Baresi 2007; Peer 2005). OWLS-Xplan consists of several modules for preprocessing and planning. It takes a set of available OWL-S services, a domain description consisting of relevant OWL ontologies and a planning query as input, and returns a plan sequence of composed services that satisfies the query goal. For this purpose, OWLS-Xplan first converts the domain ontology and service descriptions in OWL and OWL-S, respectively, to equivalent PDDL2.1 problem and domain descriptions using its OWLS2PDDL converter (Klusch and Gerber 2006). SWORD is a toolset for web service composition. In SWORD, a service is represented by a rule that expresses that given certain inputs, the service is capable of producing particular outputs. A rule-based expert system is used to automatically determine whether a desired composite service can be realized using existing services. If so, this derivation is used to construct a plan that when executed instantiates the composite service (Ponnekanti and Fox 2002).

Context-aware web service composition

In this section, we present an overview of the existing context-aware web service composition approaches. Table 4 compares these approaches.

Table 4. Comparison of context-based web services composition approaches.

Approach	Implementation	Description
CA-SCP	JSHOP2GUI	This framework is based on planning and service context information, and user context information and user requests are considered. In this framework, the appropriate services are run based on the user requests and the quality of services, and also the number of failures and composition time will be decreased.
Vukovic (2007)	TLPlan	This framework is based on planning and includes mechanisms for automatic recovery from failures.
Gupta et al. (2014)	SOA	This approach presented a dynamic failure recovery model to replace the subset containing failed subset with QoS equivalent subset. This system thus has the ability to reconfigure and recover from failure at run time.
Nadkarni et al. (2011)	OWL-S	This approach presented a failure analysis technique for composition algorithms that views web service behavior as multiple sequences of input/output events.
CAPSC Zhou et al. (2011)	BPEL	This approach presented a pervasive system to provide user service compositions that are relevant to the situation at hand.
Furno et al. (2013)	OWL-S	This approach presented a model to design context-aware services that can be exploited as a flexible domain to automatically generate context-aware compositions by means of a specific tool.
CRUISe Pietschmann, Voigt, and Meißner (2009)	GoogleMap, HTML	This approach specified a generic model for configurable web components, a corresponding service-based deployment method and a run-time system.
Zeng et al. (2008)	OWL-S	This framework showed that the computation cost is still acceptable when the number of tasks and inference rules are fairly large.
CACS Baidouri et al. (2012)	BPEL	This approach used a strategy pattern that can allow dynamic composition without any duplication or regression risks and generates the Context-Aware Composition Builder tool.
CACS Luo et al. (2006)	Petri net	This framework can perform capability matches based on goal-driven and filter out unsuitable compositions of matched services based on user context information.

Vukovic (2007) developed a framework for finding a restaurant. This framework includes mechanisms for automatic recovery from failures that may occur during the web service composition and execution process. This framework is based on TLPlan planning and uses user context information and does not consider service context information. Gupta and Bhanodia (2014) presented a mechanism for dynamically recovering failure of composite web services. This method is based on the policy of subset replacement in a set of composite web services. This implemented method enables the user to avail the entire complex and intricate services offered by today’s business organizations and thus helps in meeting the user’s requirements. In the case of failure or non-functioning of a web service, the proposed method covers up the failure by replacing the failed web services by their equivalent subset calculated using QoS parameters. Nadkarni et al. (2011) introduced a composition algorithm that can provide feedback to the user regarding the cause of failure in the composition process. Such feedback will help guide the user to reformulate the goal service and iterate the composition process. They proposed a failure analysis technique for composition algorithms that views web service behavior as multiple sequences of input/output events. This technique identifies possible cause of composition failure and suggests possible recovery options to the user. Zhou et al. (2011) developed an architecture for context-aware pervasive service composition (CAPSC), which aims at enabling a pervasive system to provide user service compositions that are relevant to the situation at hand. This architecture enables applications that are flexible and adaptive to changes. Many efforts have been made on context definition, quality of contextual information, context management platforms, and extended context-aware applications. They investigate a design process for building CAPSC applications and categorize these applications into three groups such as peer coordination adaptation, process service adaptation, and utility service adaptation. Furno and Zimeo (2013) presented a design approach that exploits semantics for modeling contexts and related systems behaviors. The context model extends the OWL-S ontology to enrich the expressiveness of each section of an OWL-annotated service, by means of conditions and adaptation rules. These additional descriptions can be exploited by a discovery or composition tool to automatically find the services better-tuned to the requestor’s behaviors and the particular situations of the environment. Pietschmann, Voigt, and Meißner (2009) presented an approach for the service-oriented and context-aware composition of rich web-user interfaces. They specify a generic model for configurable web components, a corresponding service-based deployment method and a run-time system. To validate their approach, they build a prototype illustrating the dynamic composition of the user interface from components of different technologies, and communication via a generic interface. Zeng et al. (2008) presented a new framework for dynamic service composition and optimization. In this approach, individual web services are choreographed into composite Web services whose integration logics are expressed as composition schema. They implemented a prototype to validate the feasibility and benefits of the proposed approach. The results of the proposed approach show that the computation cost is still acceptable when the number of tasks and inference rules are fairly large. Baidouri et al. (2012) introduced an approach for the context-aware composite service metamodel. This approach uses a strategy pattern that allows dynamic composition without any duplication or regression risks and generates the Context-Aware Composition Builder tool. They presented their Context-Aware Composition Builder tool that reposes in a pattern and exploit context-aware composite service metamodel in dynamic composition of services depending on the current user context. Luo et al. (2006) developed a framework that enables context-aware composition of web service. This framework performs capability matches and composes service flow based on goal-driven. Then, it filters out unsuitable compositions of matched services according to available context information. They modeled composite service with Petri nets and validate the correctness of the model by using an analysis method, called reachability tree, thus ensuring a smooth execution of a composite service.

Conclusions

In this paper, we have presented our context model and the CA-SCP framework for context-aware web service composition based on planning. We have implemented a web service composition using JSHOP2GUI. Context helps to identify the appropriate services for the main purpose. In our new planning strategy, at the planning stage, web service composition is based on user requests, user context information, and service context information. The services that do not have the appropriate conditions are not selected in web service composition. As a result, the appropriate services are run based on the user requests and the quality of services. So, the number of failures and composition time will be decreased.

Future work in context-aware web service composition can include that user can directly select the path of tasks decomposition in JSHOP2GUI1.0.1, based on service context information and user context information.