This article was downloaded by: [University of Chicago Library]On: 19 November 2014, At: 14:08Publisher: Taylor & FrancisInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Enterprise Information SystemsPublication details, including instructions for authors andsubscription information:http://www.tandfonline.com/loi/teis20

Towards policy driven context awaredifferentiated services design anddevelopmentAries Tao Tao a & Jian Yang aa Department of Computing , Macquarie University , Sydney,AustraliaPublished online: 23 Oct 2008.

To cite this article: Aries Tao Tao & Jian Yang (2008) Towards policy driven context awaredifferentiated services design and development, Enterprise Information Systems, 2:4, 367-384, DOI:10.1080/17517570802382590

To link to this article: http://dx.doi.org/10.1080/17517570802382590

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis,our agents, and our licensors make no representations or warranties whatsoever as tothe accuracy, completeness, or suitability for any purpose of the Content. Any opinionsand views expressed in this publication are the opinions and views of the authors,and are not the views of or endorsed by Taylor & Francis. The accuracy of the Contentshould not be relied upon and should be independently verified with primary sourcesof information. Taylor and Francis shall not be liable for any losses, actions, claims,proceedings, demands, costs, expenses, damages, and other liabilities whatsoever orhowsoever caused arising directly or indirectly in connection with, in relation to or arisingout of the use of the Content.

This article may be used for research, teaching, and private study purposes. Anysubstantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &Conditions of access and use can be found at http://www.tandfonline.com/page/terms-and-conditions

Towards policy driven context aware differentiated services design and

development

Aries Tao Tao* and Jian Yang

Department of Computing, Macquarie University, Sydney, Australia

(Received 7 February 2008; final version received 1 August 2008)

In the dynamic e-business environment, it is desirable for a service with differentinterfaces to meet the requirements of different users. Within the context of the currentlyavailable technologies, it is usual to make several unrelated services available, each ofwhich supports a specific interaction path. However, as the number of users increases,such design makes it difficult to maintain the large number of services. In this paper analternative service design method is proposed, ‘service differentiation’, which allows asingle service to be differentiated with interface variation to meet the differentinteraction requirements. Inspired by the concept of abstraction and polymorphism inobject oriented computing, service differentiation allows an ‘abstract business process’class to be configured by policy, hence multiple business processes can be derived tomeet different user interaction requirements.

Keywords: web service; differentiation; configurable business process; service interface;usage context

1. Introduction

As the global economy has evolved rapidly in recent years, traditional business modelshave been replaced or complemented by e-business models that bring more worldwidebusiness opportunities. e-business requires rapid, low-cost and easy composition of looselycoupled distributed software applications. Service technology meets the demands of e-business by making network resources available as services that can be accessed withoutknowledge of their underlying platform implementation (Channabasavaiah et al. 2003). Aservice is a business concept that should be specified with an application or the user of theservice in mind (Papazoglou and Yang 2002). In order to understand how services aredesigned and developed, it is necessary to take a close look into the relationships betweenservice, service interface, and business process:

. A service is an abstract business concept that represents the functionalities of abusiness.

. A service interface is a specification for users (client programs) to interact with theservice. It is supported by underlying business processes, and consists of operationsthat are implemented by the corresponding tasks of the business processes.

*Corresponding author. Email: ariestaotao@gmail.com

Enterprise Information Systems

Vol. 2, No. 4, November 2008, 367–384

ISSN 1751-7575 print/ISSN 1751-7583 online

� 2008 Taylor & Francis

DOI: 10.1080/17517570802382590

http://www.informaworld.com

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

. Business processes implement the operations of a service. A business process consistsof activities that perform service functions. From a service interface developmentpoint of view, we can classify two types of business process activity:(1) User invisible activities that are hidden behind the service interface in order

to hide internal business logics and certain implementation details from theusers.

(2) User visible activities that are presented in the service interface and used by theuser/application for interaction purposes.

In the e-business world, the main aim of a business is to provide flexible services to meetthe needs of different users. Quite often we find that different users with the same goal mayneed to interact with the same service differently. Therefore, from a service design point ofview, the service needs to support different interfaces that allow users to access the sameservice through different interaction paths. Taking an online pharmacy service (OPS) as anexample, different approval procedures are required for different types of medicine thatcustomers intend to purchase:

(1) For prescribed medicine, a doctor’s prescription is required.(2) For un-prescribed medicine, no approval is required.

Given the fact that different users or applications may often have different (butoverlapping) requirements in terms of interaction patterns, it is a good idea to providea single service with variations rather than several unrelated services because normallyit is easier and cheaper to maintain a single service than multiple services. We referto this design principle as service differentiation. The way we want to realiseservice differentiation, i.e. having a single high-level service specification with differentassociated interaction paths for users/applications, presents an interesting analogy toobject orientation in terms of overloading and polymorphism. The determining rule for‘binding’ a specific interaction with a user is governed by business policies, e.g. a policythat defines different discount rates for customers: (1) 10% discount for a ‘loyal customer’and (2) no discount for a ‘normal customer’. In this paper user profile, location, andpurpose of interaction are considered as usage contexts. Business policies are applied onthese usage contexts. As a result, different service invocations for different users can besupported.

Now let us have a close look at current service design approaches in relation to internalbusiness process and service interface design, and then analyse their deficiencies insupporting service differentiation. As illustrated in Figure 1, business policies or rules arehard coded in the business process as conditions for different activity execution. As aresult, service is supported by a fixed business process that provides the same serviceinterface to all users. However, in order to support differentiated service design, it isrequired that: (1) business policies be separated from business processes; (2) usage contextsbe separately maintained and linked with interfaces so that different users/applications canbe ‘treated’ differently by the same service in terms of different interfaces.

Our basic design philosophy, and one that distinguishes our work from that of others,is that abstract business processes are used to support common functionalities provided toall users. Different context configured business processes are generated to support servicedifferentiation for users who have different usage contexts and require different interactionpaths. This requires a new service design approach that separates the generic businessactivities that are applicable in all circumstances from those only applicable to particular

368 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

groups of people or under specific conditions. Thus we propose a new service designapproach that supports single service with multiple business processes to support servicedifferentiation. The proposed design method is built upon the following components:

. An abstract business process (ABP) consists of either of two types of activity –concrete activity or abstract activity (see Figure 2). Concrete activities performcommon tasks regardless of usage context, while abstract activities are linked withpolicy, and rely on the interpretation of the policy to perform different tasks basedon the usage context. For example, ‘login’ is a concrete activity that allows all usersto login; ‘provide discount’ is an abstract activity that relies on policy to providedifferent discount rates to users.

. Policy is bound to abstract activities in ABP. By replacing an abstract activity withdifferent tasks according to usage contexts, differentiated functions can be providedto users. Taking the policy associated with the abstract activity ‘provide discount’ asan example, the policy provides that ‘no discount’ is given to a ‘normal customer’but a ‘10% discount’ is given to a ‘loyal customer’.

Figure 1. Current service design approach.

Enterprise Information Systems 369

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

. Multiple context configured business processes (CCBPs) are generated to supportdifferent groups of users. Based on a particular context, one CCBP can be generatedby replacing all abstract activities in an ABP with different tasks according to thepolicies in the process.

. Service interfaces are derived from CCBPs by filtering out user invisible activities forsecurity or privacy reasons.

In summary, our focus in this paper is to present a design method in which:

(1) Usage contexts and policies are separately maintained from the business process.(2) CCBPs are dynamically generated if necessary.(3) Different service interfaces are presented to users/applications based on their usage

contexts.

The paper is organised as follows. Related work is discussed in Section 2. In Section 3,a case study is introduced. Service design and related algorithms are specified in Sections 4and 5. Finally, we conclude our work in Section 6.

2. Related work

In this section we discuss five aspects of related work. First, we review research workrelevant to service differentiation. Secondly, we take a general look into the research workin context. Thirdly, we review the state of the art in the area of applying usage context inweb services. Fourthly, we review current service design, arguing that it cannot effectivelysupport service differentiation. Finally, we analyse related web service standards that canbe used in our work.

The idea of applying the concept of differentiation in the software field was firstproposed by Kang et al. (1990) in the study of feature-oriented domain analysis, whichwas based on abstraction and refinement in a domain. In their work, abstractionrepresented generic domain products; refinement was used to extend the abstraction to

Figure 2. Abstract business process and policy.

370 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

support different domain applications. Cao et al. (2003) further extended the workin feature-oriented domain analysis by providing an algorithm to automateabstraction refinement. The idea of service differentiation (DiffServ) was first proposedin the area of managing traffic streams in networking applications (Blake et al. 1998).For example, certain types of traffic are treated better than others in terms of fasterhandling, more average bandwidth, and lower average loss rate. Veryard (2000) arguedthat differentiated services should be used as a design pattern in the SOC area. Hepointed out the need for service differentiation in e-business using an airport example –airport services need to meet different passenger requirements in terms of security,performance, etc. However, no design method was provided to realise this servicedifferentiation.

Context is widely applied in the area of computing: Want et al. (1992) introduced an‘active badge’ system that forwards phone calls according to user context such as location.Abowd et al. (1997) applied context in implementing a tourist guide system calledCyberguide. Cheverst et al. (2000) also made use of context in their tour guide applicationnamed ‘the GUIDE project’. By using an object-oriented approach, the ContextToolkit(Dey et al. 2001) provided a framework and a number of reusable components to supportrapid prototyping of sensor based context aware applications.

The importance of applying contexts to SOC has been addressed in recent researchwork: Baldauf et al. (2007) discussed the close relationships between context and servicesin their survey. Hough et al. (2007) examined the way services are effected by contextualfactors through a case study in the oil and gas industry. Mammar et al. (2005) clearlystated the needs of contexts in order to derive personalised service. They also classifiedcontext into three categories in terms of their effects on services. Hong et al. (2005)proposed a model for analysing the effect of contexts on service. Popova andSharpanskykh (2008) use contexts to model the structural and behavioural constraintsapplied on the services. Gu et al. (2005) proposed a formal context model based onontology using Web Ontology Language to address issues including semantic representa-tion, context reasoning, context classification and dependency. However, their work doesnot use context for the purpose of service differentiation. While aiming for developingdifferentiated service, our work provides a working mechanism to derive contextconfigured business processes for a business service, based on which differentiated servicecan be provided through context aware service interfaces. In the SOC area, Graml et al.(2007) proposed an agile and adaptive business process design by separating contextrelated business rules from the business process. Compared with Graml’s design, whichmade use of context based business rules to support users with different internal businesslogics, our research uses context based policy to derive different interfaces for meeting theneeds of different user interactions.

We now look at the work that has been done in the area of interface design. Chiu et al.(2002) presented a meta-model of the service interface in terms of workflow views, whichprovide a novel approach for deriving a workflow view from a workflow. By abstractingservice interface as a subset of service, it allows internal information to be hidden fromexternal users. However, their work only focused on abstracting a single service interface.In order to support users playing different roles in business collaboration, Zhao et al.(2005) proposed the concept of relative workflow view by explicitly specifying visibilityconstraints (invisible, traceable and contactable) on the activities of workflow. Based ondifferent visibility constraints for different users over the same workflow, multiple relativeworkflow views could be derived for different users who have different relationships withthe service (e.g. the retailer service has different relationships with the customer and the

Enterprise Information Systems 371

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

wholesaler). Having a completely different purpose, our work supports users who have thesame relationship with the service but demand differentiated service in terms of interactionpaths (e.g. the retailer service has to provide a further discount for VIPs compared withnormal customers).

Now let us have a look at current relevant web service standards. BPEL(Andrews et al. 2003) allows multiple service interfaces to be described as abstractbusiness processes, each of which is a subset of a BPEL process. However, the BPELspecification does not provide any mechanism to generate multiple service interfaces,which is often required by business as illustrated in our example. Several Semantic WebService Description standards such as OWL-S (Martin et al. 2006) and WSMO (de Bruijnet al. 2005) have been proposed. Compared with WSDL and BPEL, the Semantic WebService provides better support regarding a common understanding of context semanticsand reasoning with respect to complex relations between contextual concepts (Mokhtaret al. 2005). However, in their work, service is designed to have only one service processmodel. Such a design places limits on service flexibility to support different user interactionrequirements.

In order to incorporate the policy with web services, WS-Policy (Bajaj et al. 2006) wasproposed by the World Wide Web Consortium (W3C). It is a general framework forspecifying various web service properties in a way that complements WSDL and BPEL.WSPL (Anderson 2004) was proposed by the Organization for the Advancement ofStructured Information Standards (OASIS). It is suitable for specifying a wide range ofpolicies, e.g. acceptable and supported encryption algorithms or privacy guarantees. BothWS-Policy and WSPL focus on supporting security policies. WSOL (Tosic et al. 2005)extends the WS-Policy for web services monitoring and adaptation. WS-Context (Littleet al. 2004) and WSDL-S (Akkiraju et al. 2004) provide a base to allow contexts to bedescribed under the web services execution environment. However, their work does notsupport service differentiation. We believe our work can be built upon the above work tosupport context aware service differentiation.

3. A motivating example

In order to understand the issues involved in differentiated service development, weconduct a simplified case study in online pharmacy service (OPS). Owing to limited space,we only consider the Checkout process. The Checkout business process consists of thefollowing activities, some of which may not be available to all the users:

(1) Login – receives the user name and password in order to identify the user.(2) Display Goods – displays a list of goods that can be selected by the user.(3) Display Total – displays the total price that the customer needs to pay for the

goods.(4) Provide Discount – provides a discounted price depending on the customer’s

profile:(a) For normal customers, there is no discount available.(b) For loyal customers, 10% discount is offered.(c) For VIP customers, 15% discount is offered.

(5) Require Approval – extra approval may be required depending on the type ofmedicine purchased:(a) For prescribed medicine, a prescription from a doctor is required.(b) For un-prescribed medicine, no approval is required.

372 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

(6) Receive Payment – receives payment from user and hence returns invoice.(7) Delay Payment – is only available for customers with usage context ‘VIP

customer’.(8) Deliver Goods – contacts delivery company to deliver the product to the

customer.

The Checkout process performs different tasks according to two types of usagecontext: customer profile and type of medicine purchased. Our goal is to develop adifferentiated Checkout service that provides context aware interfaces. These interfacesprovide explicit service usage information to their users in terms of conditions, restrictions,benefits, etc. Users can choose different service interfaces based on their usage contexts.With different discount rate information associated with the service interface description,customers can be encouraged to join the loyal or VIP membership instead of the normalmembership. In the following sections we will show how this goal can be achieved basedon the above example.

4. Specifications for differentiated services development

Instead of supporting a service with one monolithic business process andsingle service interface, our design method is to separate the generic tasks thatare available to all users from the specific tasks with certain context dependentrequirements. The main issue is to find a way of identifying and mapping betweenprocess logic, usage context, inputs and outputs. The design consists of four components:abstract business process, policy, context configured business processes and serviceinterfaces.

4.1. Abstract business process

Abstract business process (ABP) consists of a set of activities and relevant edges linkingbetween activities. There are two types of activity: (1) concrete activity that actuallyperforms general tasks for all users (e.g. the login activity in the Checkout process inFigure 2); and (2) abstract activity that executes different tasks, or even different processes,depending on policy. For example, the require approval activity in the Checkout process(see Figure 2) is required to execute different approving procedures. Abstract activities arelinked to policy (which will be discussed in Section 4.2), which defines how context awaretasks (or processes) should be performed.

An abstract business process is denoted as:

ABP ¼ ðA; E; T ;PÞ; ð1Þ

where:

. P is the policy that defines how different tasks (or processes) should be performed forabstract activities (see Section 4.2).

. T is a set of tasks that can be performed by concrete activities.

. A is a set of activities. Note that 8a 2 A, a has an attribute ‘ref’. For a concreteactivity, a.ref refers to a task in T . For an abstract activity, a.ref refers to a templatethat will be described in policy P.

. E v A �A is a set of directed edges that connects elements in A.

Enterprise Information Systems 373

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

Based on the definition provided above, we can model the ABP of the Checkoutprocess as depicted on left side of Figure 2 as:

Example 4.1 ABPcheckout ¼ ðAcheckout; Echeckout; T checkout;PcheckoutÞ.T checkout ¼ {tlogin, tdisplay–goods, tdisplay–total, treceive–payment, tdeliver–goods}Pcheckout contains three templates – mpprovide–discount, temprequire-approval, and

tempdelay–payment. The details will be discussed in Section 4.2.Acheckout ¼ {alogin, adisplay–goods, adisplay–total, aprovide–discount, arequire–approval, areceive–payment,

adelay–payment, adeliver–goods}, where alogin.ref ¼ tlogin, adisplay–goods.ref ¼ tdisplay–goods,adisplay–total.ref ¼ tdisplay–total, aprovide–discount.ref ¼ tempprovide–discount, arequire–approval.ref ¼temp

require–approval, areceive–payment.ref ¼ treceive–payment, adelay–payment.ref ¼ tempdelay–payment, and

adeliver–goods.ref ¼ tdeliver–goods.Note that aprovide–discount, arequire–approval and adelay–payment are abstract activities that are

referred to the templates in Pcheckout. The other activities refer to tasks in T checkout.Echeckout ¼ {(alogin, adisplay–goods), (adisplay–goods, adisplay–total), (adisplay–total, aprovide–discount),

(aprovide–discount, arequire–approval), (arequire–approval, areceive–payment), (arequire–approval,adelay–payment), (areceive–payment, adeliver–goods), (adelay–payment, adeliver–goods)}.

4.2. Policy

Policy provides the mappings between usage contexts and tasks (or external businessprocesses). For example, in the Checkout process, the ‘customer profile’ as a usage contextcan be retrieved from the ‘login’ activity. By applying the ‘provide discount’ policy, a ‘VIPcustomer’ will get a further 15% discount by invoking the ‘offer 15% discount’ task.Depending on the usage context values, the policy determines how to plug different tasks(or business processes) into the ABP, and generate context configured business processes(see Section 4.3), which perform different business functions. For example, if the userwants to purchase a prescribed medicine, an additional approval task is executed thatrequires the user to present a doctor’s prescription.

Policy P is a set of templates. Each template is referred by an abstract activity in anABP. A template is denoted as temp:

temp ¼ ðCOND;BPSÞ; ð2Þwhere temp provides mappings between context conditions (denote as COND) and BPS.Each element bp 2 BPS refers to a task, an ABP or a concrete business process withoutany abstract activity. Since each task (or business process) can only be associated with onecontext condition, different tasks will be executed based on different context conditions.8cond 2 COND, the cond either returns a Boolean value by comparing the contextagainst a simple variable (e.g. string, int, float) with comparison operators (e.g. 5, 4,¼ ¼, �, �), or by composing multiple conditions with logical operators (e.g. ^, _).

Example 4.2 Ccheckout ¼ fcloyalty; cmedicineg.There are two usage contexts that cause the Checkout process to perform different

tasks:

(1) cloyalty represents the status of customer loyalty. The value of cloyalty can be:(a) dnormal to represent a normal customer.(b) dloyal to represent a loyal customer.(c) dvip to represent a VIP customer.

374 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

(2) cmedicine represents the type of the purchased medicine. The value of cmedicine can be:(a) dun–prescribed to represent medicine purchased that does not require a doctor’s

prescription.(b) dprescribed to represent medicine purchased that needs a prescription from a

doctor.

Example 4.3 Pcheckout ¼ ftempprovide�discount; temprequire�approval; tempdelay�paymentg.As illustrated in Figure 2, the policy P contains three templates that correspond

to the three abstract activities in the main abstract business process – aprovide–discount,arequire–approval, and adelay–payment. As discussed before, templates provide mappingsbetween conditions and business processes or tasks. However, in this paper, for simpleillustration purposes, we only provide mappings between conditions with singletasks instead of business processes. The detailed example of context policies is depictedin Figure 2:

(1) As shown at the top of policy in Figure 2, tempprovide–discount defines discount ratesfor different customers. The discount rate is determined by the value of the usagecontext cloyalty, and the value of cloyalty can be dnormal, dloyal, or dvip, which representsthree loyalty levels: normal customer, loyal customer and VIP customer. As aresult, the template tempprovide–discount defines three relations:(a) (cloyalty ¼ ¼ dnormal, tnil) – OPS provides no discount to a normal customer.

Notice that tnil means no task is performed in the business process.(b) (cloyalty ¼ ¼ dloyal, toffer–10%–discount) – OPS provides 10% discount to a loyal

customer.(c) (cloyalty ¼ ¼ dvip, toffer–15%–discount) – OPS provides 15% discount for VIP

customers.(2) As shown at the middle of policy in Figure 2, temprequire–approval represents the

policy to perform different approving procedures for customers purchasingdifferent categories of medicine in the activity arequire–approval. It consists of thefollowing two tuples:(a) (cmedicine ¼ ¼ dun–prescribed, tnil) – OPS does not require approval for un-

prescribed medicine purchases.(b) (cmedicine ¼ ¼ dprescribed, tconfirm–doctor) – OPS requires confirmation from a

doctor for prescribed medicine purchases.(3) As shown at the bottom of policy in Figure 2, tempdeplay–payment represents the

policy to perform different payment procedures for customers with different loyaltylevels in the activity adelay–payment. It consists of the following two tuples:(a) (cloyalty ¼ ¼ dnormal _ cloyalty ¼ dloyal, tnot_available) – OPS does not offer a

payment delay service to normal customers or loyal customers.(b) (cloyalty ¼ dvip, tdelay–payment) – OPS allows VIP customer to delay payment.

4.3. Context configured business processes

After introducing the basic elements of ABP, context and policy in the previous sections,we can now provide a complete picture of how a ‘concrete’ business process – contextconfigured business process (CCBP) – is generated. As discussed before, an ABP is aprocess that contains abstract activities, which refer to policy templates. A templateconsists of a set of mappings between context values and business processes (or tasks in a

Enterprise Information Systems 375

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

simple situation). The number of tuples (mappings) in a template determines the numberof tasks that can be performed for the corresponding abstract activity. By replacing all theabstract activities in ABP with policy specified tasks that come with different contextconditions, multiple CCBPs can be generated. CCBPs support users with differentfunctions, and thus realise differentiated services based on usage contexts. For example, ina Checkout process, the loyal customer and normal customer will be supported bydifferent context configured business processes. The relationships between abstract businessprocess, context, policy, template and context configured business process are summarised inFigure 3.

Each CCBP is denoted as:

CCBP ¼ ðT ;S;cÞ; ð3Þwhere:

. T is a set of tasks.

. S � T � T is a directed edge that connects two tasks in T .

. c represents usage context conditions that attach to the T . Each context conditionj 2 cbp must be satisfied in order to access the corresponding task.

Example 4.4 CCBP1 ¼ ðT 1;S1;c1Þ, where:

. T 1 ¼ (tlogin, tdisplay–goods, tdisplay–total, treceive–payment, tdeliver–goods).

. S1 ¼ ((tlogin, tdisplay–goods), (tdisplay–goods, tdisplay–total), (tdisplay–total, treceive–payment),(treceive–payment, tdeliver–goods)).

. c1 ¼ ((treceive–payment, cloyalty ¼ ¼ dnormal ^ cmedicine ¼ ¼ dun–prescribed)).

Example 4.5 CCBP6 ¼ ðT 6;S6;c6Þ, where:

. T 6 ¼ (tlogin, tdisplay–goods, tdisplay–total, toffer–15%–discount, tconfirm–doctor, treceive–payment,tdelay–payment, tdeliver–goods.

Figure 3. Proposed service design method.

376 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

. S6 ¼ ((tlogin, tdisplay–goods), (tdisplay–goods, tdisplay–total), (tdisplay–total, toffer–15%–discount),(toffer–15%–discount, tconfirm–doctor), (tconfirm–doctor, treceive–payment), (tconfirm–doctor,tdelay–payment), (treceive–payment, tdeliver–goods), (tdelay–payment, tdeliver–goods)).

. c6 ¼ ((toffer–15%–discount, cloyalty ¼ ¼ dvip), (tconfirm–doctor, cmedicine ¼ ¼ dprescribed),(tdelay–payment, cloyalty ¼ ¼ dvip)).

This design has two features. Firstly, a business service is supported by multipleCCBPs that are generated based on the context conditions. Take the Checkout service asan example: since the context cloyalty can have three values, and cmedicine can have twodifferent values, there are six possible context value combinations as conditions for policytemplate instances. Therefore six possible CCBPs can be generated accordingly. Owing tolimited space, we only show two CCBPs in Examples 4.4 and 4.5 in Figure 4: CCBP1

supports normal customers who purchase un-prescribed medicines; CCBP6 supports VIPcustomers who purchase prescribed medicines.

Secondly, as depicted in Figure 4, policy conditions are attached to the tasks as thecontext requirements for users to interact with these CCBPs generated. The configurationfrom ABP to CCBP is a recursive procedure by unfolding abstract activities in BPs until allof them are replaced by concrete tasks and labelled with context conditions.

4.4. Service interface

Each service interface corresponds to one CCBP. Each interface allows a group of userswho satisfy the same context conditions to interact with the service in a particular way. Asa result, differentiated services are supported to users through different interfaces. ‘Serviceinterface’ can be specified as:

SI ¼ ðuserCond;VT ;VSÞ; ð4Þ

Figure 4. Context configured business processes and service interfaces.

Enterprise Information Systems 377

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

where:

. userCond is a set of cond(s) that extracts from the tasks of the corresponding CCBP.It represents the contexts the user must hold in order to access this specific interface.

. VT � T . For security and privacy concerns, the service interface hides invisible tasksfrom users. In other words, the service interface only releases visible tasks from itscorresponding CCBP.

. VS � VT � VT is the set of directed edges that connect two visible tasks in VT .

Example 4.6 SI1 ¼ ðuserCond1;VT 1;VS1Þ, where:

userCond1 ¼ (cloyalty ¼ ¼ dnormal ^ cmedicine ¼ ¼ dun–prescribed)VT 1 ¼ ðtlogin; tdisplay�goods; tdisplay�total; treceive�paymentÞ andVS1¼ðtlogin;tdisplay�goodsÞ;ðtdisplay�goods;tdisplay�totalÞ;ðtdisplay�total;treceive�paymentÞ;ðtreceive�payment;tdeliver�goodsÞ:

Example 4.7 SI6 ¼ ðVT 6;VS6Þ, where:

userCond6 ¼ (cloyalty ¼ ¼ dvip ^ cmedicine ¼ ¼ dprescribed)VT6 ¼ (tlogin, tdisplay–goods, tdisplay–total, toffer–15%–discount, tconfirm–doctor, treceive–payment,tdelay–payment) andVS6 ¼ (tlogin, tdisplay–goods), (tdisplay–goods, tdisplay–total), (tdisplay–total, toffer–15%–discount),(toffer–15%–discount, tconfirm–doctor), (tconfirm–doctor, treceive–payment), (tconfirm–doctor, tdelay–payment).

Examples 4.6 and 4.7 correspond to the two service interfaces shown in Figure 4; wecan see that multiple service interfaces can be derived from CCBPs. Every service interfacesupports a group of users who satisfy the same context conditions. This service interfacedesign benefits users for the following reasons:

. It allows users to check if their contexts satisfy the cond as an extra step in processmatching before the users establish interaction with the service.

. During service invocation, it provides guidelines for proper user–service interactions,and prevents exceptions caused by unexpected context conditions.

5. Differentiated service design

In the previous section we introduced four components of differentiated service: abstractbusiness process, policy, context configured business process and service interface. In thissection we demonstrate how these components are designed and developed.

5.1. Abstract business process design

This is the process for the design of abstract business process (ABP). As shown in Figure 5,ABP is an object class that has the following elements.

(1) Concrete activity is a normal class that provides generic functionality to allusers. In checkout_process, there are five concrete activities: loginAct, display-GoodsAct, displayTotalAct, receivePaymentAct and deliverGoodsAct. Notice that

378 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

deliverGoodsAct is a private activity because it interacts with the external deliveryservice, which should be hidden from the user.

(2) Abstract activity provides differentiated functionalities to users regardingthe contexts. Abstract activity is an abstract class so that service differentiationcan be realized by policy. There are three abstract activities in checkout_process:provideDiscountAct, which provides different discount rates for users;requireApprovalAct, which requires a doctor’s approval for prescribedmedicine purchase; and delayPaymentAct, which allows VIP customers to delaypayment.

(3) Task defines the tasks can be executed by concrete activities.(4) Policy supports the differentiated functionalities required by abstract activities, e.g.

DiscountPolicy supports the functionality required by provideDiscountAct.(5) Edges indicate message sequence.

5.2. Context policy design

Contexts, conditions, templates and policies that consist of mappings between contextconditions and BPs that need to be stored. Business policies can change frequently,therefore modifications are expected and should be supported. We implement policy as anarray of PolicyTemplate classes. As in the example shown in Figure 6, each PolicyTemplateclass has the following elements:

(1) Extends is used to denote the corresponding abstract activities. For example, theMedicalApprovalPolicy is extended from the abstract activity named requireAp-provalAct, which is defined in the checkout_process (see Figure 5).

Figure 5. The checkout process.

Enterprise Information Systems 379

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

(2) DependsOn is used to represent the context that can be retrieved from thecorresponding AbstractBusinessProcess class, e.g. MedicalApprovalPolicy dependson the context named ‘medicineTypeData’, which represents the type of medicinepurchased by the user; medicineTypeData can be retrieved from the displayGood-sAct in the checkout_process.

(3) Differentiation is used to perform different tasks (or business processes) for thecorresponding abstract activity, e.g. in MedicalApprovalPolicy, if ‘medicineType-Data’ is prescribed, then the business process ‘requireDoctorConfirmation’ will beperformed for ‘requireApprovalAct’ to acquire a doctor’s confirmation from theuser. Otherwise the business process ‘nil’ will be performed, which requires noapproval from the user.

5.3. Context configured business process (CCBP) determination

CCBPs are generated based on ABP and policy templates defined in Sections 5.1 and 5.2.The algorithm for generating CCBPs consists of two steps: Find Available Graph and FindExecutable Business Process.

Figure 6. The approval policy.

Algorithm 1 FindAvailableGraph

Require: INPUT: ABP, cc (context conditions), ti�1 2 T , ai 2 A, and ag1: if ai ¼ nil then2: return

3: end if

4: if ai is concrete activity then

5: bpi ¼ ai.ref6: else7: bpi ¼ DeriveServiceInterface(ai, cc)8: end if

9: add bpi into ag.T10: add bpi related edges into ag.S11: add bpi related context conditions into ag.psi12: next_activity_set ¼ get_next_activity_set (ai, ABP)13: if bpi ¼ tnot_available then

380 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

Find Available Graph traverses the ABP, retrieves different business processes fromtemplates based on context values, plugs those business processes into the correspondingabstract activities, and finally derives available graph as ag; ag represents the tasksavailable to user groups; ag is in the same structure as the CCBP that contains twocomponents: (1) T – the tasks that can be accessed by the specific contexts; (2) S containsthe corresponding edges to link the tasks. As shown in Algorithm 1, in order to deriveavailable graph from ABP, the function FindAvailableGraph starts from the root activitywith available graph (ag) as an empty graph, and traverses each activity of the ABP asfollows:

. If the activity is a concrete activity, its referred task and related edges would be addedinto the available graph; if the activity is an abstract activity, the correspondingbusiness process from policy as bpi must be derived, and then plugged into the ag(Lines 4–11).

. This function will recursively call itself to traverse every activity until it: (1) reachesthe end of the ABP (Lines 1–2), or (2) finds a broken branch caused by tnot_available,then stops further traversing on the branch (Lines 13–14).

Find CCBP. Some branches of ag may contain the task tnot_available; these branches areconsidered as broken branches because they do not lead to the proper end of a businessprocess. In order to avoid these exceptions, the function FindCCBP deletes all the broken

14: return

15: else if bpi ¼ tnil then16: for all ai þ 1 in next_activity_set do17: FindAvailableGraph(ABP, context_conditions, bpi71, ai þ 1, ag)18: end for

19: else20: for all ai þ 1 in next_activity_set do21: FindAvailableGraph(ABP, context_conditions, bpi, ai þ 1, ag)22: end for

23: end if

Algorithm 2 FindCCBP

Require: INPUT: CCBP, ag, ti, tiþ1 2 T1: if ti ¼ nil then2: return

3: else if ti ¼ tnot_available then4: return

5: else6: add ti, it’s related edges and context conditions into CCBP7: end if

8: prev_task_set ¼ get_prev_task_set (ti, ag.S)9: for all ti71 in prev_task_set do

10: FindCCBP (CCBP, ag, ti, ti71)11: end for

Enterprise Information Systems 381

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

branches from available_graph, then derives CCBPs. As shown in Algorithm 2, in order toderive CCBP from available graph, the function FindCCBP works as follows:

. It starts from the last task in available graph (ag), and reversely traverses theavailable_graph (Lines 8–10) until the root is reached (Lines 1–2).

. It ignores the broken branch that includes tnot_available (Lines 3–6).

5.4. Service interface derivation

Service interfaces are derived from CCBP by hiding invisible tasks from users. Each serviceinterface (si) enables a group of users who satisfy common context conditions to interactwith the service in certain ways. As shown in Algorithm 3, FindServiceInterface works asfollows:

. It recursively traverses CCBP from the root task (Lines 11–20) until it reaches theend of the CCBP (Lines 1–2).

. It extracts the context conditions (Line 5).

. It hides the invisible tasks and related edges from users (Lines 12–15).

6. Conclusion

Service users or applications can often have the same goal but different interactionrequirements. In this paper, we proposed and argued the need for service differentiation toserve the purpose mentioned above. We believe multiple interfaces supported

Algorithm 3 FindServiceInterface

Require INPUT CCBP, si(service interface), ti�1 2 T , ti 2 A1: if ti ¼ nil then2: return

3: else if ti.visibility ¼ visible then

4: add ti into si.VT5: add ti related context conditions into si.userCond6: let ti related edges to be trs7: for all tr in trs do8: add tr.s into si.VS9: end for

10: end if

11: next_task_set ¼ get_next_task_set (ti, CCBP))12: if ti.visibility ¼ invisible then

13: for all ti þ 1 in next_task_set do14: FindServiceInterface (CCBP, si, ti71, ti þ 1)15: end for

16: else17: for all ti þ 1 in next_activity_set do18: FindServiceInterface(CCBP, si, ti, tiþ 1)19: end for

20: end if

382 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

by different underlying business processes should be provided for the same service.The design is developed around the concept of usage context, based on which concretebusiness processes and interfaces are generated and labelled with the relevant contextconditions.

Currently we are investigating a mechanism to extend our work on servicedifferentiation to support business collaboration. In the setting of business collabora-tion, the partners’ interfaces can mismatch with each other in terms of message,process and policy. We are working on mechanisms and algorithms to identify mismatchpatterns and provide solutions to overcome the mismatches, and negotiate possiblecollaborations.

Acknowledgements

This research was partially supported under the Australian Research Council’s Discovery Projectsfunding scheme (project number DP0771612).

References

Abowd, G.D., et al., 1997. Cyberguide: A mobile context-aware tour guide. Wireless NetworksJournal, 3 (5), 421–433.

Akkiraju, R., et al., 2005. Web Service Semantics (WSDL-S) 1.0 [online]. W3C organization.Available from: http://www.w3.org/Submission/WSDL-S/ [Accessed 1 November 2006].

Anderson, A.H., 2004. An introduction to the web services policy language (WSPL). In: D. Vermaand M. Devarakonda, eds. Proceedings of the 5th IEEE international workshop on policies fordistributed systems and networks (POLICY 2004), 7–9 June 2004. Yorktown Heights, NY.Washington, DC: IEEE Computer Society, 189–192.

Andrews, T., et al., 2003. Business Process Execution Language for Web Services (BPEL) version 1.1[online]. W3C organization. Available from: http://www.ibm.com/developerworks/library/specification/ws-bpel/ [Accessed 25 April 2006].

Bajaj, S., et al., 2006. Web services policy (WS-Policy) [online]. W3C organization. Available from:http://www.w3.org/TR/ws-policy [Accessed 15 November 2006].

Baldauf, M., Dustdar, S., and Rosenberg, F., 2007. A survey on context-aware systems. InternationalJournal of Ad Hoc and Ubiquitous Computing, 2 (4), 263–277.

Blake, S., et al., 1998. RFC247: An architecture for differentiated services. Technical report [online].Torrent Networking Technologies. Available from: http://rfc.net/rfc2475.html [Accessed 11December 2007].

Cao, F., et al., 2003. Automating feature-oriented domain analysis. In: B. Al-Ani, H.R. Arabnia, andY. Mun, eds. Proceedings of the international conference on software engineering research andpractice (SERP’03), 23–26 June 2003. Las Vegas, NY, Vol. 2. CSREA Press, 944–949.

Channabasavaiah, K., Holley, K., and Tuggle, E., 2003. Migrating to a serviceoriented architecture.IBM DeveloperWorks Journal [online]. Available from: http://www-128.ibm.com/developerworks/library/ws-migratesoa/ [Accessed 10 December 2007].

Cheverst, K., et al., 2000. Experiences of developing and deploying a context-aware tourist guide:The GUIDE project. In: R. Pickholtz, et al., eds. Proceedings of the sixth annual internationalconference on mobile computing and networking (MOBICOM), 6–11 August 2000, Boston, MA.ACM, 20–31.

Chiu, D.K.W., et al., 2002. Workflow view driven cross-organizational interoperability in a web-service environment. In: C. Bussler, R. Hull, S.A. McIlraith, M.E. Orlowska, B. Pernici, and J.Yang, eds. Proceedings of web services, e-business, and the semantic web, CAiSE 2002international workshop (WES 2002), Toronto, Canada, 27–28 May 2002, Lecture Notes inComputer Science Vol. 2512. Berlin: Springer-Verlag, 41–56.

de Bruijn, J., et al., 2005. Web service modeling ontology (WSMO). W3C organization. Availablefrom: http://www.w3.org/Submission/WSMO [Accessed 11 December 2007].

Dey, A.K., Salber, D., and Abowd, G.D., 2001. A conceptual framework and a toolkit forsupporting the rapid prototyping of context-aware applications. Human–Computer Interaction,16 (2–4), 97–166.

Enterprise Information Systems 383

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14

Graml, T., Bracht, R., and Spies, M., 2007. Patterns of business rules to enable agile businessprocesses. In: D. Sparrow, et al., eds. Proceedings of the 11th IEEE international enterprisedistributed object computing conference (EDOC 2007), 15–19 October 2007, Annapolis, MD.Washington, DC: IEEE Computer Society, 365–378.

Gu, T., Pung, H.K., and Zhang, D., 2005. A service-oriented middleware for building context-awareservices. Network and Computer Applications Journal, 28 (1), 1–18.

Hong, D., Chiu, D.K.W., and Shen, V.Y., 2005. Requirements elicitation for the design of context-aware applications in a ubiquitous environment. In: Q. Li and T.P. Liang, eds. Proceedings of the7th international conference on electronic commerce (ICEC 2005), Xi’an, People’s Republic ofChina, 15–17 August 2005, ACM International Conference Proceeding Series Vol. 113. ACM,590–596.

Hough, J.R., Haines, R., and Giacomo, S., 2007. Contextual factors affecting the integration ofenterprise systems in post-merger oil and gas companies. Enterprise Information Systems, 1 (4),421–441.

Kang, K.C., et al., 1990. Feature-oriented domain analysis (FODA) feasibility study. Technicalreport, Carnegie-Mellon University Software Engineering Institute.

Little, M., Newcomer, E., and Pavlik, G., 2004. Web services context specification (WS-Context)[online]. W3C organization. Available from: http://xml.coverpages.org/WS-ContextCD-9904.pdf [Accessed 11 December 2007].

Maamar, Z., Mostefaoui, S.K., and Mahmoud, Q.H., 2005. Context for personalized web services.In: R.H. Sprague, ed. Proceedings of the 38th Hawaii international conference on system sciences(HICSS-38 2005), 3–6 January 2005, Big Island, HI. Washington, DC: IEEE Computer Society.

Martin, D., et al., 2006. OWL-S: Semantic markup for web services [online]. W3C organization.Available from: http://www.w3.org/Submission/OWL-S/ [Accessed 15 November 2006].

Mokhtar, S.B., et al., 2005. Context-aware service composition in pervasive computing environ-ments. In: N. Guelfi and A. Savidis, eds. Proceedings of rapid integration of software engineeringtechniques, second international workshop (RISE 2005), Heraklion, Crete, Greece, 8–9September 2005, Lecture Notes in Computer Science Vol. 3943. Berlin: Springer-Verlag,129–144.

Papazoglou, M.P. and Yang, J., 2002. Design methodology for web services and business processes.In: A.P. Buchmann, F. Casati, L. Fiege, M. Hsu, and M.C. Shan, eds. Proceedings oftechnologies for e-services, third international workshop (TES 2002), Hong Kong, People’sRepublic of China, 23–24 August 2002, Lecture Notes in Computer Science Vol. 2444. Berlin:Springer-Verlag, 23–24.

Popova, V. and Sharpanskykh, A., 2008. Process-oriented organisation modelling and analysis.Enterprise Information Systems, 2 (2), 157–176.

Tosic, V., et al., 2005. Management applications of the Web Service Offerings Language (WSOL).Information Systems Journal, 30 (7), 564–586.

Veryard, R., 2000. Design pattern: differentiated service (fewer interfaces than components). CBDIJournal, 1 (1), 1–16.

Want, R., et al., 1992. The active badge location system. ACM Transactions on Information Systems,10 (1), 91–102.

Zhao, X., Liu, C., and Yang, Y., 2005. An organisational perspective on collaborative businessprocesses. In: W.M.P. van der Aalst, B. Benatallah, F. Casati, and F. Curbera, eds. Proceedingsof business process management, 3rd International Conference (BPM 2005), Nancy, France, 5–8September 2005, Vol. 3649. Springer-Verlag, 17–31.

384 A.T. Tao and J. Yang

Dow

nloa

ded

by [

Uni

vers

ity o

f C

hica

go L

ibra

ry]

at 1

4:08

19

Nov

embe

r 20

14