FROM NEGOTIATION TO RENEGOTIATION USING A FEATURE …

IADIS International Journal on WWW/Internet Vol. 9, No. 2, pp. 1-16 ISSN: 1645-7641

1

FROM NEGOTIATION TO RENEGOTIATION USING A FEATURE-BASED BPM INFRASTRUCTURE

Daniel Avila Vecchiato. University of Campinas. Institute of Computing, University of Campinas, Av. Albert Einstein, 1251, Campinas - SP, Brazil.

Maria Beatriz Felgar de Toledo. University of Campinas. Institute of Computing, University of Campinas, Av. Albert Einstein, 1251, Campinas - SP, Brazil.

Marcelo Fantinato. University of São Paulo. School of Arts, Sciences and Humanities, University of São Paulo, R. Arlindo Béttio, 1000, São Paulo - SP, Brazil.

Itana Maria de Souza Gimenes. University of Maringá. Department of Informatics, State University of Maringá, Av. Colombo, 5.790, Maringá - PR, Brazil.

ABSTRACT

Electronic contracts (e-contracts) usually describe inter-organizational business processes composed of electronic services (e-services) to be provided and consumed as well as non-functional requirements such as Quality of Service (QoS). Organizations involved in a cooperation need to provide explicit guarantees in an established e-contract after a negotiation process. These guarantees can involve renegotiation of contractual clauses, penalty application or intervention in the business process execution. In this paper, feature modeling is used as a negotiation tool to represent and select e-services, QoS attributes as well as control operations to be triggered when QoS attribute levels are not met. In addition, it describes FeatureContract, an extended toolkit to support contract establishment based on features and a new component of this toolkit to deal with the renegotiation phase. The overall approach includes a BPM infrastructure for contract establishment, business process execution, service monitoring and contract renegotiation. An application example is also exploited to show the proposed approach feasibility. The main contributions are an improved structure that enables reuse of information throughout e-contract establishment.

KEYWORDS

Business Process Management; e-contracts; contract negotiation; contract renegotiation; e-services.

IADIS International Journal on WWW/Internet

2

1. INTRODUCTION

The Internet and the Service Oriented Computing (SOC) paradigm (Papazoglou 2007) can facilitate service exchange, thus increasing the scope of Business Process Management (BPM) from intra-organizational services to inter-organizational cooperation. The current BPM scenario includes: i) one or more organizations that provide and/or consume electronic services (e-services); ii) negotiation and establishment of electronic contracts (e-contracts), including Quality of Service (QoS) attributes and levels; iii) definition, enactment, monitoring, and auditing of business process; and, iv) process analysis and optimization. E-contracts between two or more partners interested in an inter-organizational business process define the activities to be performed and the obligations, permissions and rights related to each involved party. Throughout a contract enactment, if a party is unable to fulfill contractual clauses, a contract renegotiation may be triggered.

Fantinato et al. (2010) have developed a new approach to reduce complexity in the management of e-contracts for Web services, here called as WS-Contract. The approach, based on Software Product Line (PL) concepts (Pohl et al. 2005), is named Product Line for Business Process Management (PL4BPM). A predominant part of the PL4BPM approach is the WS-Contract establishment process (Fantinato et al. 2008), focused on providing improved information reuse and structuring based on feature modeling.

This paper discusses the e-contract life cycle which consists of negotiation, establishment, enactment and renegotiation, within the context of a feature-based BPM infrastructure. It focuses on a WS-Contract metamodel to deal with e-contract establishment and renegotiation and its support toolkit. The main contributions of this paper are: i) an extension of pre-existent feature metamodel and a pre-existent WS-Contract metamodel (Fantinato et al. 2008) to include the control operations to be performed in the case of e-contract violation representing them using the WS-Agreement specification; ii) an extended infrastructure to support e-contract negotiation and renegotiation, including the corresponding extension of the FeatureContract toolkit; iii) a more efficient management, organization and reuse of the information necessary for the establishment and renegotiation of e-contracts; and, iv) an example of the approach showing the various stages of an e-contract establishment between a travel agency and an airline company.

The feature modeling technique used in the representation of e-services and QoS attributes has shown the following advantages (Fantinato et al. 2008): flexibility for e-services specification; modularization facilities for QoS attributes specification; and structured representation of the optional and mandatory WS-contract elements. Taking these concerns into account, feature modeling may also be successful in contract renegotiations especially in respect to control operations for contract violation.

The paper is organized as follows: Section 2 presents basic concepts; Section 3 presents some related work; Section 4 presents the extended Feature and WS-Contract metamodels; Section 5 presents the overall extension made on the FeatureContract toolkit, within the proposed BPM infrastructure; Section 6 presents an application example using the proposed approach; Section 7 presents a renegotiation protocol and the prototype for automating the renegotiation process. Finally, Section 8 concludes the paper.


3

2. BACKGROUND

This paper focuses on WS-Contracts to be contracted and guarantees about their execution specified in WS-Agreement. Firstly, e-contracts are described and then feature modeling concepts are presented as the technique used to represent information to be included in e-contracts.

2.1 E-Contracts

Organizations interested in Internet business partnerships must define details of the business process to be enacted and express them in e-contracts (Fantinato et al. 2008). An e-contract defines details about the organizations, the activities to be executed and the contractual clauses that must be met during process enactment (Grefen et al. 2001). The clauses could be of three types: obligations, rights and prohibitions. The obligation clauses include QoS of e-services within the inter-organizational process. In addition to the functional aspect of e-contracts, there is also the legal aspect that will not be considered is this paper.

The activities to be contracted are e-services that may be implemented as Web services; in this case, e-contracts are called WS-Contracts. Web Services (Alonso et al. 2004; Papazoglou 2007) have spread as a promising technology for the effective automation of inter-organizational interactions. The major benefit of this technology is the wide standardization including: a language to describe service interfaces (Web Services Description Language - WSDL), a service directory structure and APIs for service publication and discovery (Universal Description, Discovery, and Integration - UDDI) and a communication protocol (Simple Object Access Protocol – SOAP) for exchanging structured information in the eXtensible Markup Language (XML).

The contractual clauses may be specified in languages such as WS-Agreement (Andrieux et al. 2007), a specification offering assurance about the Web Services execution. It was developed to represent and establish agreements between two parties, usually a service provider and a consumer. The specification uses XML to structure an agreement that is composed by: i) Name, this is an optional element that can be given to an agreement; ii) Context that contains information about the involved parties, the services in the agreement and the agreement expiration time; and, iii) Terms that define one or more services and none or more guarantees, composed by: a) Service Terms that describe the services that will be contracted under the agreement; and, b) Guarantee Terms that define the assurance on service quality (QoS) associated with the services described by the service definition terms.

WS-Agreement also allows the definition of service level objectives and qualifying conditions associated with importance, penalties and rewards representing the business value to the provider.

2.2 Feature Modeling

Feature modeling captures and manages common points and variabilities in software product lines (Pohl et al. 2005). A feature model represents properties of some entity of interest. It can denote any functional or non-functional property in the requirement, architectural or other levels. Features can be mandatory, optional or alternative (Czarnecki et al. 2005). They are


4

organized into a tree-like diagram in which a node represents a feature and each feature can be described by a set of sub-features represented as descendant nodes.

A feature model describes a system family. A family member can be configured by selecting the desired features from the model within the model variability limits. This is called feature model configuration.

3. RELATED WORK

The CrossFlow project (Grefen et al. 2001) is pioneer in the area of inter-organizational business process. Like some other earlier works, they use metamodels and templates to facilitate e-contract establishment.

More recently, Angelov and Grefen (Angelov & Grefen 2008b) defined an e-contract metamodel with different perspectives such as function and communication perspective. They identify four e-contract lifecycle phases: i) information that describes services and possible partners; ii) pre-contracting that customizes business operational aspects; iii) contracting that establishes how the business process between provider and consumer will be carried out; and iv) enactment that comprises the execution of the contracted e-services, according to the defined business process and the established terms in the e-contract.

Bacarin et al. (Bacarin et al. 2008) put forth a negotiation protocol with some primitive actions to assign property values, to send offers, request for proposal (RFP) and votes. They identify the following phases: negotiation announcement, leader determination, objective announcement, negotiation setup, restriction announcement, core negotiation, commit attempt, contract (re)construction. Those phases can be used for both contract negotiation and renegotiation.

Angelov and Grefen (Angelov & Grefen 2008a) define a reference architecture to contract systems development, using a component-based approach. This architecture provides a component for each phase of e-contracting (information, pre-contracting, contracting and enactment).

Hanson and Milosevic (Hanson & Milosevic 2003) propose a negotiation model that can be applied at different levels: contract model, clauses and variables. During negotiation, the contractual clauses can be modified using insertions, updates or deletions. Values can also be assigned to variables. The renegotiation process is similar, but only clauses or variables can be reassigned.

Some works (Angelov & Grefen 2008b; Bacarin et al. 2008; Grefen et al. 2001; Hanson & Milosevic 2003) use e-contract template to facilitate e-contract reuse. Feature models are used in the present work as a basis to generate the e-contract template and manage the obligations, permissions and prohibitions of each party. They facilitate e-contract information organization and reuse by structuring common and variable points. In a general way, the renegotiation issue is still not completely addressed in a proper way by the works proposed in the literature. Some architectures and frameworks (Angelov & Grefen 2008a ; Bacarin et al. 2008) allows contract update during process execution. However, none of them specifies the actions to be performed in the case of contract violation. This work addresses the issue of control operations to handle contract enactment in the case of any clause violation.


5

4. FEATURE AND WS-CONTRACT METAMODELS

The BPM context involves business process composed by e-services. The collaboration between providers and consumers of e-services must be regulated by an e-contract between the involved parties. Our approach considers e-services implemented as Web Services and hence the WS-Contracts. The WS-Contract is composed of: parties, e-services, contractual clauses and a business process. WS-BPEL (Alves et al. 2007) is used to define the parties and the orchestration of the e-services within an inter-organizational context. E-services and QoS attributes are described in WSDL and WS-Agreement (Andrieux et al. 2007), respectively.

The WS-Contract metamodel, presented in Figure 1, represents the structure that supports the creation of e-contracts. Originally, it was proposed by Fantinato et al. and, in this paper, it was extended to represent control operations. The metamodel comprises: i) Web Services described in the WSDL; ii) Business process specified in the WS-BPEL; iii) QoS attributes of Web Services, described in WS-Agreement; and, iv) Control operations to be handled in case of contract violation, also described in WS-Agreement.

Figure 1. WS-Contract metamodel

The WS-Contract is composed of three sections, as follows: • WS-BPEL definitions: this section defines the business process using the terms

Variable, Partner Link and Activity (including Basic Activity and Structured Activity);

• WSDL definitions: this is the services section, it contains the base elements Message Type, Partner Link Type, Port Type and Operation. The last two describe the Web Services;

• WS-Agreement definitions: it defines the business terms. The following elements are used to define QoS levels: Service Property (including Variable) and Guarantee Term (including Service Scope, Service Level Objective and Business Value List). It also includes:


6

• Control operations: represented within the WS-Agreement definitions, more specifically in the Business Value List section using the “penalty tags” as illustrated latter in Figure 3.

Different e-contracts can be reused in different cooperation opportunities, thus a useful strategy explored in our approach is the use of contract templates. An e-contract template is defined only once, but allows distinct and similar contract instances to be created from the same template. To facilitate the creation of e-contract templates, we use feature models to represent information provided by the involved organizations in a high level of abstraction. The feature metamodel for e-contracts has been proposed by Fantinato et al. (Fantinato et al. 2008). It originally consisted of two sub-trees, e-services and QoS-attributes, but it has been extended to include a Control Operations sub-tree. The feature diagram structure and sub-trees are shown in Figure 2. The acronyms depicted in this Figure are used to identify the feature type in the feature models. These acronyms appear later in Figure 4.

Each sub-tree is described as follows: • E-Services sub-tree (SS): this root feature is mandatory. It contains features

representing the e-services offered by an involved organization; • QoS-attributes sub-tree (SA): this root feature is optional. It contains features that

represent the QoS attributes. These attributes are attached to e-services defined into the E-Services sub-tree. It includes choices of QoS attribute levels;

• Control-operations sub-tree (SC): this root feature is optional. It specifies control operations to be executed when QoS attribute levels are not met. These attributes are attached to e-services defined into the e-Services sub-tree and to QoS attributes defined into the QoS-attributes sub-tree. The Control Operation and Activity are depicted latter in Figure 3, each control operation has a possibility to be controlled or not by an activity. The element Value, in dark gray color, will only exist in the fine application activity and is used, to represent the fine value.

Figure 2. Feature Metamodel for e-Services, QoS and Control Operations

The control operation sub-tree can be associated directly to an e-service or to specific QoS attributes of an e-service. The former case is used as a default option whereas the latter case is


7

used as a specialization option. When a QoS attribute is not met, if there are control operations settings defined specifically for it, they are triggered; otherwise, if there are control operations settings defined generically for the associated e-service, these control operations are triggered instead. With this feature structure support, a unique set of control operations options, defined only once, can be reused by all the QoS attributes and levels associated to all the e-services. During feature model configuration, specific control operations options can be selected for each QoS attribute or for each e-service.

Figure 3 illustrates the possible control operations and how they are represented into the WS-Agreement section. The control operations are the following:

• Renegotiation: used for contract update in three ways: i) Clause (QoS attribute) that can be removed, added or updated. It can be

necessary if new requirements in the inter-organization cooperation appear; ii) Variable (QoS level) that can be renegotiated when triggering a penalty or

control operations on a process are not necessary; iii) Price when a service or a QoS level price can be renegotiated. This can be

applied in services that are not having QoS attribute levels as expected. • Penalty Application: used to apply a penalty to the offending party. The penalty is

a fine to compensate some eventual loss. It can be selected, for example, if the QoS attribute “availability” is not fulfilled causing loss of money or clients.

• Process: used to directly influence the business process execution. The available operations are: i) Rollback that undoes operations already executed by the business process. It

can be selected, for example, for atomic e-services executed in a transactional way;

ii) Suspend that stops the business process execution until some condition is reached. It can be selected, for example, for the QoS attribute “security”, since the process can be suspended until some security level is fulfilled;

iii) Termination that terminates the business process execution. It can be selected, for example, when clauses related to important e-services cannot be fulfilled and the process cannot proceed.

In the right side of Figure 3, the Business Value List is composed as follows (Andrieux et al. 2007):

Figure 3. Mapping between control operation elements regarding both metamodels


8

• Penalty: This element defines an expression to be assumed when an associated objective is not met;

• Value Unit: This element, of type xs:string, defines the unit for assessing penalty. It is used, in this work, to represent a currency in the case of penalty application or a control operation such as renegotiation or process;

• Value Expr: This element, of type xs:any, defines the assessment amount, which can be even a domain expression. It is used, in this work, to represent a value in the case of penalty application or a control activity such as variable, price or clause renegotiation;

• Assesment Interval: This element defines the interval over which a penalty is assessed. It can be one of the following: i) Time Interval that defines the assessment interval as a duration. For example,

a weekly or monthly interval for defining the assessment; ii) Count that defines the assessment interval as a service specific count, such as

the number of invocations. When the Contract Renegotiation operation is chosen, a negotiation protocol must be

specified. It will be performed after a notification sent by the monitor to the collaborating parties. In Section 7 the Bargain style of negotiation is used in the prototype tool implemented to support the renegotiation process. Other operations such as Process Terminate, Process Rollback and Process Suspend will be executed by the WS-BPEL server. The monitor and WS-BPEL server are elements of the infrastructure described in Section 5.

5. BPM INFRASTRUCTURE AND THE FeatureContract TOOLKIT

The proposed BPM infrastructure comprises four organizations: consumer, provider, negotiator and monitor. The Consumer Organization includes: i) a structure called WS-Contract Definition responsible for negotiation and establishment of WS-Contracts based on features; ii) a structure WS-Contract Execution responsible for the business process execution; and, iii) a SOC System necessary if the consumer services are parts of the business process to be executed. In the Provider Organization, the SOC System control the Web Services subcontracted by the consumer. The Monitor Organization has one structure WS-Contract Monitoring that follows the business process execution guided by the QoS terms contained in the WS-contract for service monitoring. The Negotiator Organization has one structure WS-Contract Negotiation that uses a set of protocols responsible to (re)negotiation of contracts between providers and consumers.

To establish cooperation, a negotiation is initiated between the Consumer and Provider generating the feature model diagram and the WS-contract defined according to those feature models and their respective configurations. Contract parties are sent to the interested organizations. The WS-BPEL server interprets the business process, and invokes local or contracted Web Services. If monitoring is specified, the monitor organization receives the QoS terms in the WS-contract. If any contracted term is not satisfied, the control operation, as specified in the contract, is performed. For (re)negotiation, the WS-Contract Negotiation uses a set of predefined protocols, if the contract has to be finalized the WS-BPEL server is informed to stop the enactment.


9

With respect to the infrastructure implementation, the FeatureContract toolkit prototype (Fantinato et al. 2008) has already been developed to support the WS-Contract Definition. The prototype support of the WS-Contract Negotiation is discussed in Section 7. The WS-Contract Monitoring are under development.

Regarding the FeatureContract toolkit (Feature Modeling based Web Services E-Contracts establishment toolkit), it is better described as follows, since it supports the definition of the control operations as presented in the previous section and important for the negotiation and renegotiation phases. Examples of produced artifacts are presented in section 6.

The FeatureContract has the following functionalities: i) Feature models creation and management; ii) Services section, business process and agreement terms creation from the feature model; iii) Contract model management through edition of its services section, business process and agreement terms; iv) Feature model configuration that represents the services and related QoS levels to be contracted; and v) E-contract model instantiation. The FeatureContract has a set of components that supports the different stages of contract establishment. Most of them are Eclipse plugins, some were reused from other research and development groups FeaturePlugin (Antkiewicz & Czarnecki 2004), Eclipse BPEL (Eclipse Foundation 2010a) WSDL Editor and XML Editor (Eclipse Foundation 2010b) whereas the Feature Model Parser and the WS-Contract Factory were developed by our research group. A description of each component is presented as follows:

• FeaturePlugin: this component supports the elaboration of feature models and also the configuration of such models. It was developed by Czarnecki research group (Antkiewicz & Czarnecki 2004), as an Eclipse plugin, and it implements cardinality-based feature modeling. Only a few adaptations were necessary in order to incorporate it as a component of the FeatureContract toolkit;

• Feature Model Parser: this component supports the automatic transformation from e-service feature models to an initial version of a WS-contract template. It was specifically developed to be a component of the FeatureContract toolkit. This component works as a document parser, it has been implemented as Java code that is responsible to transform the XML exported by the FeaturePlugin in the services section, business terms and business process;

• WSDL Editor : this component supports the graphical visualization and edition of WSDL specifications. It is used to edit the services section - represented by the WSDL definitions - of the WS-contract template generated by the Feature Model Parser, if necessary. WSDL Editor is an Eclipse plugin, part of the Web Tools Platform (WTP);

• XML Editor : this component supports the graphical visualization and edition of XML specifications. Since there is no particular tool for editing WS-Agreement specifications yet, this tool is used to edit the business terms section - represented by the WS-Agreement definitions - of the WS-contract template, if necessary. It is also an Eclipse WTP plugin;

• Eclipse BPEL: supports the graphical visualization and edition of WS-BPEL specifications. It is used to edit the business process of the WS-contract template generated by the Feature Model Parser, which is created in a basic way. It is always necessary to edit it to fix the process logic.

• WS-Contract Factory: this component supports the automatic WS-contract instantiation, based on the WS-contract template and on the e-services feature model configurations. It was specifically developed to be a component of the


10

FeatureContract toolkit. This component works as a document parser, which removes all the parties of the template linked with features not present in the feature models configurations. This removal process is carried out following the hierarchical levels of the contract parties, i.e. when an upper-level template element has to be removed, all its internal lower-level element are removed as well.

The FeatureContract toolkit is considered a prototype as not all the functionalities have been implemented yet, but it can express the feasibility of this approach as showed in the next Section. The extensions proposed here were developed and an application example was chosen in order to be a complex task, but due to lack of space it was simplified.

6. APPLICATION EXAMPLE

This section presents a summary of an application example to show the feasibility of the proposed approach. This example requires a contract to be established between two fictitious organizations: A Travel Agency and an Airline Company, as described below:

• Travel Agency - Consumer: System that supports tourism packages sale by composing third-party services. E-services provided by the travel agency include: customer notification, offers advertisement and travel packages that consume Airline Company e-services.

• Airline Company - Provider: System that supports flight ticket sale and booking. E-services provided by the airline company include: flight booking and purchase; seat and food selection.

Due to lack of space, the following sections will present the stages for e-contract establishment only in the Airline Company perspective.

6.1 Services Feature Model Elaboration

In this stage each company must elaborate a feature model to represent: the provided e-services; the QoS levels related to each service; and the control operations related both to e-service and/or QoS levels.

Figure 4 (a) presents a feature model example for an Airline Company built with the FeaturePlugin (Antkiewicz & Czarnecki 2004), which has two service groups: flight services group and services selection group. This first group has the following services: timetable query, flight purchase and flight booking; and the services selection group has seat selection and food selection. Only some items are expanded.


11

Figure 4. (a) Feature model; and, (b) Feature model configuration for the airline company

The Airline Company feature model gives the consumer (Travel Agency) a structured overview of which e-services, QoS levels and control operations are offered by the provider. During the feature model configuration stage described in subsection 6.3, with the control operations associated to the feature model, the consumer can choose e-services and their QoS levels with control operations to be applied when QoS levels are not met. With the services feature models elaborated, XML files can be exported by the FeaturePlugin to be used in e-contract template creation.

6.2 E-contract Template Creation

The XML files exported from the feature models are used by the FeatureContract to extract the WSDL and WS-Agreement sections of the e-contract template. Moreover, the Eclipse BPEL plugin is used to define the business process flow. However, this paper does not address the BPEL and WSDL sections of the e-contract since the proposed extension focuses on e-contract establishment and negotiation that is more closely related with the WS-Agreement section.

The template is composed by all the services and related QoS levels offered to be contracted with the respective control operations in the case of contract violation, as present in Figure 4 (a). The main idea is to create one template that can be instantiated many times with different feature configurations.

Figure 5 shows a WS-Agreement excerpt that represents renegotiation related to a QoS Level. Not all the possible values are depicted due to lack of space. Latter they will be removed, only the level chosen in the feature model configuration will be left as described in the following subsection.


12

Figure 5. WS-Agreement Template Excerpt

6.3 Services Feature Model Configuration

In this stage the Travel Agency system selects the e-services to be contracted from the Airline Company system, QoS levels and control operations related to these services are also configured. As depicted in Figure 4 (a) by the • symbol, all the features of the flight services group are mandatory, the symbols ο and □ represents optional features that can be chosen by the contracting party.

Figure 4 (b) depicts an example of a feature model configuration. The control-operations sub-tree is associated to the flight-purchase e-service and its QoS attributes. The renegotiation of price is defined as the default control operation for the flight-purchase service, which must be triggered if any QoS attribute - for which there is no specialized control operation - is not met. Latter in the e-contract instantiation the penalty tags - related to the flight-purchase e-service - that represents renegotiation of clause and variable will be removed from the e-contract template. Only the penalty that represents price renegotiation will be left.

6.4 E-contract Instantiation

The service feature models configurations of the Airline Company and Travel Agency systems indicate which information are relevant to a specific e-contract instance. From the feature models configurations, new XML files are generated. Using the WS-Contract Factory, of the FeatureContract toolkit, all the information related to e-services, QoS attributes and control operations not selected during feature models configuration are removed from the e-contract template. New WDSL, WS-Agreement and WS-BPEL files, containing only the information necessary to the specific agreement, form a new e-contract instance, including control operations information related to Web Services and QoS levels.

7. RENEGOTIATION PROTOCOL AND SUPPORT TOOL

This section discusses a renegotiation protocol proposed to complements the PL4BPM approach and presents an overview about the prototype tool developed to automate the


13

renegotiation process. This prototype implements some functionalities allowing the parties to conduct a renegotiation in order to respond to an e-contract violation.

Bargain is the simplest negotiation style (Bacarin et al. 2009). It is a negotiation protocol between two participants in which they agree about the value of a property. This protocol is characterized by a sequence of offers and counter-proposals until the negotiators reach an agreement or give up from negotiation process (Bacarin et al. 2007). Since in the PL4BPM approach, cited above, it is possible that the contract is established between only two parties, this protocol was chosen to demonstrate the feasibility of performing a semi-automated renegotiation between two parties.

Table 1 shows the types of messages exchanged during a renegotiation process in the PL4BPM approach using the Bargain protocol.

Table 1. Bargain protocol messages

Operation Parameters Pre-condition Post-condition Start renegotiation Organization, date, service Waiting for renegotiation Wait / Send proposal Send (counter) proposal Renegotiation, organization, date,

value Renegotiation already initiated Wait proposal

Accept proposal Renegotiation, organization, date Renegotiation already initiated / at least one proposal received

Amend contract

Refuse proposal Renegotiation, organization, date Renegotiation already initiated Finalize contract Each one of the operations described in Table 1 has some parameters that must be sent and

some associated pre- and post-conditions. For the operation Start renegotiation, it is necessary to know which of the two 'organizations' (consumer or provider) started the renegotiation process, as well as the start 'date' and the 'service' for which the renegotiation applies. After the renegotiation started, a party may submit a proposal or wait for the other party to send one. In the operation Send (counter) proposal, the 'organization' performing the proposal must be identified, as well as the proposal 'date' and its 'value', and the 'renegotiation' identifier should also be assigned since a single organization can participate in multiple renegotiations. In the operation Accept proposal, the 'organization' finalizing the 'renegotiation' must be identified, since the value will be closed on the last bid received; it is also necessary to know the 'date' when renegotiation is terminated. After the proposal acceptance, the contract must be properly amended. Finally, in operation Refuse proposal, it is necessary to identify the 'organization' refusing to continue the 'renegotiation' process as well as the 'date' on which it was refused, thereby ending the e-contract.

The renegotiation process is composed by four states, presented as follows. First the renegotiation starts in the state Waiting for renegotiation. From this point, a change in state only happens when one of the parties involved in the renegotiation authenticates itself in the system. The system verifies which services have any pending renegotiation and changes the state to Renegotiating, so that proposals and counter-proposals can be exchanged between consumer and provider. This state is maintained until one of the parties decides to accept or to refuse the last received proposal, changing the state to Renegotiation finalized with agreement, or Renegotiation finalized without agreement respectively.

According to the metamodel present in Section 4, prices, variables or clauses can be renegotiated. The price and variable renegotiations are similar as the parties exchanges proposals aiming to reach a new agreement on a common value. The clause renegotiation allows sending three types of proposals: i) canceling service contract; ii) canceling only the


14

contracted QoS attribute which has failed; and, iii) keeping the contract unchanged. If the consumer, in case of failure, desires to contract another service, it should, in the renegotiation step, cancel the service contract and initiate a negotiation in order to find another convenient service.

Table 1 presents the parameters of the messages exchanged during a renegotiation process. Those parameters are objects that contains information about what is being renegotiated, which are the involved parties, the values being offered and the date of each event. To better explain the objects and their relationships, Figure 6 illustrates the Class Diagram that represents the Model Layer of the renegotiation prototype which was developed to implement such renegotiation protocol. The Class Diagram depicted in Figure 6 has six classes and two enum types that are listed as follow:

• Organization: responsible for representing information related to the e-contract parties;

• Renegotiation: responsible for representing the renegotiation, this class contains the service that is being renegotiated, the parties, proposals exchanged between the parties and, finally, the start and final date of the renegotiation;

• Service: responsible for representing information related to services consumed and provided by the e-contract parties, a service may have several QoS variables;

• Failed service: class that extends Service and represents the goal (object) of the renegotiation. It contains the failure date and the QoS variable responsible for the e-contract violation;

• Proposal: responsible for representing information related to proposals exchanged between the parties during a renegotiation process. Each proposal must have, date, value and the proposal party;

• QoSVariable: class responsible for representing information related to the QoS attributes. It contains the attribute name and value;

• Role: enum type used to represent the possible roles (Consumer or Provider) that a party can assume during an e-contract;

• Status: enum type used to represent the possible states of the renegotiation.

Figure 6. Renegotiation support class diagram


15

8. CONCLUSIONS AND FUTURE WORK

This paper has presented an infrastructure that supports e-contract negotiation, establishment, enactment and renegotiation. The emphasis was in the WS-Contract metamodel; control operations; and, the support FeatureContract toolkit. The main advantages of the proposed infrastructure are: i) efficient management, organization and reuse of the necessary information for the negotiation and renegotiation of e-contracts based on feature modeling; ii) identifying all possible alternatives to dynamically adjust the e-contract during renegotiation; iii) information organization and presentation of e-services and QoS attributes linked with control operations using feature modeling; and, iv) extension of the WS-Contract metamodel to include the control operations elements already supported by the feature models.

The use of feature models to represent control operations makes information related to renegotiation easier to understand, simple and systematic. It can bring benefits for distinct stakeholders, at different levels, as it has a high level of abstraction and structured way for representing information. However, some disadvantages or limitations of the approach can be pointed out: i) necessity of knowledge about feature modeling; and, ii) negotiation is still made in an offline way; negotiation protocols have not yet been included to automatically perform negotiation.

Future works, in addition to overcoming the weaknesses mentioned above, include: full implementation of the WS-Contract negotiation component with some example protocols; and integration with the WS-Contract monitoring tool which has been developed by the same research group.

ACKNOWLEDGEMENTS

This work was supported by The State of São Paulo Research Foundation (FAPESP) and The National Council for Scientific and Technological Development (CNPq), Brazil.

REFERENCES

Alonso, G. et al, 2004. Web Services: Concepts, Architectures and Applications. Springer-Verlag, Berlin, Germany.

Alves, A et al. 2007, Business process execution language for web services version 2.0, OASIS, Available from: <http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html>. [22 July 2010].

Andrieux, A et al. 2007, Web services agreement specification (ws-agreement), Open Grid Forum, Available from: <http://www.gridforum.org/documents/GFD.107.pdf>. [22 July 2010].

Angelov, S & Grefen, P 2008, An e-contracting reference architecture, J. Syst. Softw., Vol. 81, No. 11, pp. 1816–1844.

Angelov, S & Grefen, P 2008, Supporting the diversity of b2b e-contracting processes, Int. J. Electron. Commerce, Vol. 12, No. 4, pp. 39–70.

Antkiewicz, M & Czarnecki, K 2004, FeaturePlugin: feature modeling plug-in for Eclipse, in Proc. of the 2004 OOPSLA workshop on eclipse technology eXchange, New York, USA, pp. 67–72.


16

Bacarin, E et al. 2007, Towards modeling and simulating a multi-party negotiation protocol with colored petri nets. in Proc. CPN 07 - Eighth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, pp 29–48, 2007.

Bacarin, E et al. 2008, Contract e-negotiation in agricultural supply chains, Int. J. Electron. Commerce, Vol. 12, No. 4, pp. 71–98.

Bacarin, E et al. 2009, Spica’s multi-party negotiation protocol: Implementation using yawl. In Technical report, Unicamp.

Czarnecki, K et al. 2005, Staged configuration through specialization and multi-level configuration of feature models, in Software Process Improvement and Practice, Vol. 10, No. 2, pp. 143-169.

Eclipse Foundation 2010a, BPEL Project, Available from: <http://www.eclipse.org/bpel/>. [22 July 2010].

Eclipse Foundation 2010b, Web Tools Platform, Available from: <http://www.eclipse.org/webtools/>. [22 July 2010].

Fantinato, M et al. 2008, Ws-contract establishment with qos: an approach based on feature modeling, Int. J. Cooperative Inf. Syst., Vol. 17, No. 3, pp. 373–407.

Fantinato, M et al. 2010, Product line in the business process management domain, in Applied Software Product Line Engineering, eds K C Kang, V Sugumaran, & S Park, Auerbach Publications, pp. 497–530.

Grefen, P et al. 2001, CrossFlow: Cross-Organizational Workflow Management for Service Outsourcing in Dynamic Virtual Enterprises, Data Engineering Bulletin, pp. 52–57.

Hanson, J. and Milosevic, Z. 2003, Conversation-oriented protocols for contract negotiations, in Proceedings of the 7th International Conference on Enterprise Distributed Object Computing. Washington, USA, pp. 40.

Papazoglou, M 2007, Web Services: Principles and Technology, Prentice Hall. Pohl, K et al. 2005, Software Product Line Engineering: Foundations, Principles and Techniques, 1st ed,

Springer.

Documents

FROM NEGOTIATION TO RENEGOTIATION USING A FEATURE …