Dynamic e-business

International Journal of Cooperative Information Systems (IJCIS) 2005

TRANSFORMING AGREEMENTS INTO CONTRACTS YIGAL HOFFNER IBM Research GmbH, Zurich Research Laboratory 8803 Rüschlikon, Switzerland SIMON FIELD MatchingSystems Ltd., Switzerland

During the life cycle of a service consumer-provider relationship, agreements are reached in a variety of areas covering technical, service, business and legal issues. Although some of these agreements may be viewed as legally binding, it is unlikely that any of them will constitute a legal contract in the full sense of the word. It is often expedient to gather these agreements and create a legal contract out of them. Automating this process of contract generation can speed up the process and reduce the cost of legal expenses. In fact, the process of automated contract generation can also be useful outside the realm of web services - when agreements are made directly among people. We propose a way of transforming such agreements into contracts in a dynamic, efficient and speedy manner, using advanced forms of matchmaking technology in a novel manner. This complements the other directions in which the agreements are to be used, namely configuration, instantiation, enactment supervision and relationship termination and evaluation. Keywords: contracts; matchmaking.

1. Introduction 1.1.

The case for automation of contract generation

There are a host of situations where an automated process of contract generation can be extremely useful, regardless of whether the relationship establishment between the parties is carried out with computers or directly among people. It is interesting to note that an identical service can be offered in different ways, depending on the business model that is attached to it. The business model may or may not affect the manner in which core and auxiliary services are combined, but it will definitely alter the contract associated with the resulting relationship. For example, a service can be offered as part of a short or longterm relationship. As far as the consumer is concerned, the core service itself is identical. The important point is that the same service can be used differently since it can be engulfed by different contracts. In any case, contracts of different flavours are needed even for relatively simple products, where repair guarantees ‘transform’ a product into a service. Any product that may need a service of some kind is likely to have complex guarantees, conditions of use and restrictions attached to it. Different pricing policies, customised product configurations, different regulations, different geographical sales locations, and remoteness of servicing facilities – all of these factors are likely to cause slight variations in the contract. Instead of creating different fixed contracts for all the possible markets


and circumstances, an easily manageable scheme, supporting automatic circumstancesdriven generation of contracts, is likely to be extremely attractive. In this paper, we focus on the automatic generation of a contract from the agreement that has been reached through the use of computers during the relationship establishment stage. The rest of Section 1 discusses the differences between agreements and contracts, explaining why a transformation process is often needed from agreements to contracts. Section 2 sets the context for the rest of the paper by introducing the e-business relationship life cycle and focusing on the relationship establishment and the resulting agreement. The section then discusses the problems that such agreements raise in detail, strengthening the argument for the automated transformation process. Section 3 provides a high level description of the process of transforming agreements into contracts. Different transformation approaches are described based on the selection and configuration of monolithic templates or the composition of the contract from finer granularity templates - contract clauses. Section 4 shows how the transformation from an agreement to a contract can be automated using matchmaking technology in a novel fashion. The section presents a novel method for generating a legal contract from the agreement reached earlier. This is done by breaking up the constituent parts of the contract into clauses and using matchmaking technology to determine whether a clause is relevant for a given business agreement or not. Section 5 and Section 6 provide two scenarios that help explain how our ideas can be put into practice. Both scenarios are based on providing a translation service as a web service. In Section 5, the scenario consists of two types of relationships and associated agreements – a short and a long-term one, where both agreements relate to the same service. Associated with each of the agreements types is a contract type template. By launching a matchmaking process when the agreement instance details are submitted as a query, it is possible to advertise the templates and have the appropriate one selected and configured. In Section 6, the scenario is made more complex by catering for a wider variety of relationship and agreement types. Each of those agreements requires a different contract. In fact, the same technology used for contract composition is used in the relationship establishment phase to determine, from the business circumstances of the consumer and provider, what type of relationship/agreement the search for the compatible partner should be based on. The relationship/agreement type composition and the ensuing search for a business partner (possibly also using matchmaking technology), results in an agreement instance. In turn, instead of using the monolithic template approach, contract clauses are used as building blocks from which different contracts are assembled. Section 7 summarises and concludes the work presented herein. 1.2.

Agreements, contracts and legal documents

The term contract appears frequently and rather liberally in technical literature.1,2,3,4,5,6,7. Such references to contracts may be better called agreements than contracts. Some work in this area correctly refers to Service Level Agreements8. While agreements may implicitly refer to existing standards or common understanding in certain domains, a contract is expected to turn those assumptions and implicit references into explicit statements. The aim of the contract is to put an agreement into a legal anchor in an explicit form. The term often used in business circles is “to close all the gaps and holes”.


A contract is also expected to state any restrictions and limitations in an explicit form. Furthermore, any penalty clauses are also expected to be present in the contract. We use the term agreement to mean an understanding while we reserve the term contract and legal contract to the signed document that is accepted as a legally binding entity. Thus, an agreement can be legally binding or part of a legally binding document. However, an agreement as referred to in the computer literature, often means the skeleton from which a proper contract can be generated. Another way to look at it is to realise that a contract is a special kind of an agreement. Taking all of the implicit assumptions, indirect references and common practices explicitly into account during the process of negotiations is likely to render the process rather cumbersome, inefficient and slow. Not surprisingly, most dynamic e-business relationships are likely to be carried out within the confines of closed and well-defined and typed domains,9. Such domains create a context in which the implicit understanding and details can be brought into the relationship when needed, rather than from the outset. This helps to make the relationship establishment process relatively lightweight. 2. E-business Relationships Life Cycle and Agreements A Relationship Life Cycle is a description of the steps that two parties have to go through in order to create, carry out, maintain and manage the desired business relationship between them5, 10, 11. While different application domains and degrees of automation will require different flavours of the life cycle, the following is a variation that is particularly suited to extensive use of computers and a high degree of automation of some of the phases of the life cycle, in particular the relationship establishment and deployment12. We call this the E-business Relationship Life Cycle: •

Establish the relationship: this entails finding a potential partner through advertising, querying, matchmaking, exchanging information, negotiating and agreeing. This should result in the establishment of a client-service agreement/contract.

•

Deploy the relationship: the agreement is used as a blueprint for creating and/or configuring the service, client and related infrastructures. Once the components are in place, they can be linked.

•

Enact the relationship: this entails the activation of the client and service using the link established earlier, resulting in the provision and consumption of core and if required, of auxiliary services as promised in the agreement reached earlier.

•

Post-enactment relationship processing: this entails the use of any necessary auxiliary services.

•

Terminate the relationship: this entails agreement on relationship termination and the dismantling of the relationship.

•

Post relationship termination processing: this entails preparing an audit report, evaluating the relationship and providing feedback. In the following section, we concentrate on the relationship establishment.


2.1.

Relationships establishment

The following is a more detailed view of the steps that are taken within the relationship establishment stage in order to reach an agreement between two parties (figure 1): 1.

Making a statement of intent and fact and specifying requirements: this involves specifying the capabilities of a consumer/client and provider/service so that they could be compared with each other to determine whether they are compatible.

2.

Negotiating the terms of the relationship: finding out whether both parties support the same policy or set of policies can be seen as negotiation. This consists of (one or more rounds of) suitability tests (and offer customisation) and exchange of information. One possible implementation of such negotiations is with a matchmaking engine (i.e. a centralised third-party component as shown in figure 1) or can be done using a direct negotiation protocol that specifies the order in which the information is exchanged.

3.

Reaching and signing an agreement: reaching consensus on what each side is expected to provide. If matchmaking is used as the negotiation mechanism, the agreement may consist of the return of one or more matching offers to the client side, the client making a selection and then notifying the other party of its decision. There may be further exchange of information necessary. Q u e ry S ta tem en ts ab o u t th e c on su m er, in c lu d in g its p o lic y, req u irem en ts fro m th e o th er p a rty

C lie n t

M a tc h m a k in g E n g in e

O ffe r(s) N o tify E x ch a n g e

A g r e em e n t

S er v ice C o n su m er

A d v e r tise m e n t S ta tem en ts ab o u t th e serv ic e in c lu d in g its p o lic y, req u irem en ts fro m th e o th er p a rty

S e r v ic e S e r v ic e P r o v id e r

T y p e d D o m a in F ig . 1 . N e g o tia tio n is b ase d o n m a tch m a k in g w ith a n e x ch a n g e o f b u sin ess, c o n tra c tu a se rv ic e a n d tec h n ica l in fo rm a tio n b e tw e en th e tw o p artie s e ith e r d irec tly, th ro u g h a th ird p arty m a tc h m a k in g e n g in e o r a c o m b in a tio n o f b o th .

The resulting agreement embodies the common view two parties have of their relationship. It therefore can be used throughout the rest of the life cycle for a number of purposes:

•

As a configuration directive for each one of the parties, specifying what resources should be allocated and how they should be configured, in order to enact the relationship successfully.


•

As a legal contract, that describes the obligations, responsibilities, liabilities and permissions of each party as well as the acceptable procedures in case of a dispute.

•

As a supervision directive, that enables enactment-time monitoring and control of the service provision-consumption.

2.2.

Problems with agreements

As we will see in Section 6, successful negotiation process within the relationship establishment phase is likely to result in one or more types of agreements. There may be several problems associated with such agreements: •

Different types of agreements will result in different kinds of contracts.

•

They will cover different aspects of the relationship. For example: •

Technical issues e.g. interface or port and binding information, communication protocols.

•

Service issues e.g. service (functionality/ behaviour) descriptions with QoS indications, permissible sequencing specification.

•

Business issues e.g. what will be delivered in terms of consideration – tying together service consumption and remuneration aspects of the relationship.

•

Legal issues e.g. legal issues such as scoping of the relationship, exclusions, legal notices in case of problems, penalties and arbitration.

•

They may include understanding in short-hand or summary form.

•

They may refer to standard or prior agreements, or legislation and precedents.

•

They may refer to additional documents that contain further detail.

3. Automated Transformation of Agreements to Legal Documents Our idea of automatically transforming agreements into contracts (figure 2) is based on a number of observations: • Simple “vanilla trades” can often be handled with straightforward contract templates13, 14 . In fact, this is true for the majority of contracts in existence. The New Jersey Law Revision Commission15, in their report relating to Standard Form Contracts asserts that most contracts are in fact standard contracts. •

Cases that are more complicated can be dealt with by assembling the appropriate contract clauses. In difficult cases, there may be a need to add meta-rules to ensure that the result is a coherent and consistent contract.

•

Difficult or extraordinary circumstances or the detection of possible contradictory or conflicting content can be flagged and subsequently dealt with by the appropriate experts in the relevant legal department.


D o m a in C o n te x t : B u ild in g b lo c k s & in c lu s io n /e x c lu s io n r u le s

+ +

A greem en t

T yped D o m a in

+

L egal docu m ent (C o n tr a c t )

I n p u t fr o m c o n s u m e r / p r o v id e r o r a 3 r d p a r ty

F ig . 2 . T ra n s fo r m in g a n a g re e m e n t in to a le g a l d o cu m e n t o r c o n tra c t c a n b e d o n e a u to m a tic a lly .

3.1.

Input to the transformation process

There are several sources of input to the process of agreement to contract transformation (figure 2): 1.

Domain context: this provides the building blocks for the contract construction, and the rules that determine which building blocks should be included or excluded. Any indirect and implicit references that can be resolved also serve as input.

2.

Input from consumer and provider (and any third parties such as regulatory bodies that need intervene in the process): further information or decisions that are not covered by the input agreements have to be received and used in the transformation process.

3.

Previously reached agreement: covering all that has been agreed in the negotiation process.

3.2. Transformation approaches When transforming agreements into contracts, components with different granularity can be used as the composition building blocks. Three possible approaches are available: •

Monolithic templates: For each type of possible legal contract, there is a template. Agreement details determine the selection of the appropriate template and the contract specific details are computed from the agreement details. This is shown in figure 3.

•

Finer granularity building blocks: Instead of using monolithic contract templates, the contract is composed from clausal type templates that have to be selected and assembled into complete contracts. This is shown in figure 4. In such a case, there is a need to define: •

Building blocks: clause templates of finer granularity than the monolithic templates.


•

•

Composition rules: clause selection and exclusion rules that will use the information from the existing agreement to determine which clauses should be included or excluded.

•

Ordering, consistency checks and restrictions: post clause selection processing to assemble the contract from the clauses in the right order and to check that the contract is valid in the domain.

A Hybrid approach: combining the advantages of a small number of monolithic templates together with a number of clauses of smaller granularity that can be assembled in different ways.

®A

M o n o lit h ic C o n tr a c t T y p e T e m p la t e s

®B

®C

+

A greem en t

S e le c te d C ontract T y p e & s p e c ific v a l u e s fr o m a g r e e m e n t

+

®C

T yped D o m a in Fig. 3. The business related information and requirements of the consumer help select the appropriate monolithic relationship type. This can be used in the matchmaking activity that follows to find the appropriate provider instance or instances.

C1

C o n tr a c t c la u s e (b u ild in g -b lo c k ) t e m p la te s

C4

C2

C5

C3

A greem en t

C6

+

+

S e le c te d C o n tr a c t C la u s e s & s p e c ific v a l u e s fr o m agreem en t

C1 C4

T yped D o m a in

C6

Fig. 4. The business related information and requirements of the consumer help assemble the appropriate relationship type from the building blocks defined by the domain. The description of the building blocks is shown in figure 3.

3.3.

Transformations and feedback

It is often the case that the same service or technical configuration may be associated or engulfed by different kinds of contracts. Interestingly, some contract clauses may also


have an influence on the relationship and more specifically on service and technical configurations (e.g. necessity of including monitoring, auditing and notification services). An example of such a situation arises when the issue of trust is taken into account at contract generation. It may be that this consideration is brought into the establishment of the relationship because it is at this point that the parties have to worry about protecting themselves from problems that may arise. Trust is likely to dictate the kind of guarantees that a consumer and provider may wish to see in a contract associated with a certain relationship. It may also determine the service configuration, i.e. the auxiliary monitoring and auditing services that will be required and also the type of technology needed to encrypt messages. D o m a in C o n te x t: B u ild in g b lo c k s & in c lu s io n /e x c lu sio n r u le s

A greem en t

F eed b ack

+

L egal d ocu m en t (C o n tr a c t)

+ +

In p u t fro m c o n s u m e r / p r o v id e r o r a 3 rd p a r ty

T y p e d D o m a in Fig. 5. The transformation process may cause the prior agreements that are used as input to the process to be modified or expanded.

In other words, it is possible that certain considerations during the creation of the contract will demand the modification of prior agreements thus feeding back into the process of contract creation as shown in figure 5. Such feedback may have several effects on the agreements and the contract creation process: •

Expansion of the agreements by adding more detail.

•

Requirement to include auxiliary services thereby complicating the relationships among the core and auxiliary services.

•

Requirement of additional cycles of agreement resolution, of information provision and decision making to be made by the parties, finally resulting in additional transformations and input to the contract. In fact, this may result in another round of negotiations between the parties.

Where the transformation process provides feedback, there may be different degrees of action required: 1.

One of the parties or both parties have to take some internal action, without affecting the link between them. For example, the inclusion of monitoring or for internal auditing purposes.

2.

One or both parties have to take action, causing a modification of the original agreement in such a way that does not require a change in their run-time interactions, for example, the inclusion of monitoring and auditing, without the transfer of this


information between the parties at agreement enactment time. In addition, the change may include a provision for using such information if disputes occur. 3.

One or both parties have to take action, causing a modification of the original agreement in such a way that requires a change in their interactions. The provision of additional information to each other due to some regulations, or the inclusion of monitoring information during agreement enactment is an example of this.

4. Using Matchmaking Technology for Agreement Transformation A symmetric MatchMaking Engine (MME)16, 17 can be used to carry out the transformation from the agreements to the legal contract. The use of the matchmaking engine for contract generation is a departure from the original and traditional use of it as a broker between service providers and service consumers. Instead of two negotiating parties, the advertisements to the MME consist of contract templates or contract clause templates, while the query that launches the matchmaking process, is a description of an agreement reached earlier. Thus, the matchmaking process is now about selecting the right contract template or collecting the right contract-clause templates, and then populating the variable fields of the template(s) with information from the agreement description, either directly or by transforming it. The main characteristics of a matchmaking process that has to perform the transformation described above from an agreement to a contract are the following: Two-way symmetric selection (figure 6): both sides to the matchmaking process have to describe themselves in terms of what they offer and may specify what they demand of the other party. In fact, the main departure from the asymmetric matchmaking mode of CORBA2 is that the query side can provide information and that the advertising side can supply a rule that examines this information. Advertisement: Contract Clause Requirements from business agreement (Rules) Contract Clause description (Properties)

Query: Business agreement

R

Matchmaking

P

Matchmaking

Matchmaking process

P

R

Business agreement description (Properties) Agreement requirements of contract clauses (Rules)

Fig. 6. The two-way symmetric matchmaking process used to select the contract clauses that are relevant for a business agreement.

Powerful description and requirement language: powerful languages are needed to describe the complexity of agreements and contract clauses. Similarly, powerful languages are needed to describe complex compatibility criteria, i.e. the selection criteria for the advertised contract clauses.


Dynamic evaluation of property values (figure 7): this facility enables the dynamic usage and processing of query details (business agreement information) in filling the fields of selected clauses. This enables the matchmaking process to configure the template or clause that is selected by the rules attached to a query and advertisement. Advertisement: Contract Clause Requirements from business agreement (Rules) Contract Clause description including dynamic ti

Back-End System

Query: Business agreement

R

Matchmaking

P

Matchmaking

Script processing

P

Business agreement description (Properties)

R

Matchmaking Engine

Agreement requirements of contract clauses (Rules)

Request for up-to-date description may contain consumer properties

Resulting description can be consumer specific Fig. 7. Dynamic properties of contract clauses can be calculated at matchmaking time, using information from the business agreement description.

Pre- and post matchmaking processing: Pre-matchmaking processing of queries and post-matchmaking processing of matching offers is shown in figure 8. Pre-matchmaking processing of queries allows credit ratings, party evaluation, personal or commercially sensitive information to be brought into the matchmaking process. Furthermore, special agreements that already exist between the parties can also be brought in and taken into account. Post-matchmaking processing of matching offers provides an opportunity to check for consistency of the selected clauses to see if any conflicting clauses are present. It is also the place where the selected clauses can be ordered before being presented or aggregated into a single contract. 4.1.

Matchmaking as contract composition and configuration process

Many of the features and concepts explored above in the context of service matching can be applied equally to the dynamic selection and configuration of contract clauses – with the clauses taking the place of configurable services: •

A contract clause requires information describing the proposed agreement, and contains structured information, representing the content of the clause – a symmetric exchange of information.


Pre-processing: Requesting Credit ratings or other relevant information on the parties to the business agreement.

Contract Clauses R P

Business agreement

Matchmaking Engine Advertisement Matchmaking Matchmaking

Query Matching contract clauses

P R

Post-processing: checking for consistency of the resulting collection of contract clauses Fig. 8. Pre-matchmaking processing of queries and post-matchmaking processing of matching contract clauses.

• • •

Not all clauses are required in every agreement – a requirement language is needed with which to specify the circumstances in which each clause should be included. The content of clauses will vary according to the individual circumstances of each agreement – clauses must therefore be capable of dynamic configuration. The set of clauses needs to be sorted and brought together to form a complete document – there is a requirement for post-matchmaking processing of the selected and configured clauses.

The matchmaking engines described above has the necessary features for transforming agreements into contracts dynamically. This is achieved by breaking down a contract to a set of configurable clauses that are advertised in the matchmaking engine, and that can be selected and configured by the engine via rules. The matchmaking process, as it relates to the dynamic construction of contracts, is shown in figure 9: 1.

Advertisements that include the dynamic parts of clauses, together with the rules that determine the circumstances in which each clause is relevant to the contract, are submitted to the Matchmaking Engine. At the same time, the static “template” content of each clause is stored in a database or file system.

2.

A business description of the agreement is submitted in the form of a query to the Matchmaking Engine. Like the clause advertisements, this contains named properties, and may also contain rules.

3.

The matchmaking process is triggered by the arrival of the query. Each contract clause advertisement is evaluated, its rules determining whether the clause should form part of the contract or not.


4.

During the process or rule evaluation, dynamic properties belonging to advertisements containing scripts may be evaluated in order to determine suitable values for those properties. This may involve reference to the properties supplied as part of the query, or even reference to external information systems or databases.

5.

The result is a set of offers, each representing the dynamic content of a clause that has been selected for inclusion in the contract. Each offer contains a set of properties with values that have been resolved for this particular query during the matchmaking process.

6.

The contract is assembled by reconciling the dynamic content of the selected clauses

Rules

(1) Advertisement: Clause with Properties, Rules

(2) Q uery: Agreem ent details

A greement Rules

Agreement instance & rules

Rules

Rules

Rules

Rules

Rules (3) M atchmaking process

(1) Template: Store static part of clause

M atchmaking C lause text and structure

M atchmaking (4*) Request value of dynam ic Property Rule/Script processing

M atchmaking Engine

(5) Sequence of clauses: Contain Properties

(6) Document Assembly: Reconcile static and dynam ic

Contract instance

Typed Domain Fig. 9. The sym metric matchmaking process used to generate a contract from a business agreem ent description.

with the static content that was stored separately as a set of templates. The completed clauses are sorted and “stitched together” to form a single document – the completed contract that has been created to suit the circumstances described in the query. The dynamic properties of the Matchmaking Engine are used to process the data from the incoming agreement that is provided by the query. This enables the resulting clauses to be customised to the specific details of the agreement at hand.


4.2.

The scenarios – demonstrating selection and composition

The following sections provide two scenarios9. The first scenario (Section 5) consists of two types of relationships and associated agreements – a short and a long term one, where both agreements relate to the same service. It demonstrates the use of the monolithic template selection. In Section 6, the scenario is made more complex by catering for a wider variety of relationship and agreement types. Each of those agreements requires a different contract. It shows how finer granularity building blocks can be used to generate multiple contracts. 5. Scenario 1: Selecting and Filling the Contract Template In the first scenario, there are two monolithic types of relationships defined in the typed translation-service domain: • A short-term relationship type (®Tshort in figure 10): from a business perspective, this is a ‘per document’ relationship, where the cost is proportional to the document word count. The service offers a first or second-class response, defined by the domain, and can accept several document formats. The technical aspects of the relationship allow a CORBA and Web Services style of interaction and an interface type, which expects the document in the permitted format and a proof-of-credit token. From a legal point of view, associated with this type of relationship is a simple shortterm contract template defined in the domain. This contract template requires at least one arbitration organisation to be recognised by the two parties. ® T sh o rt

R e la t io n s h ip / A g r e e m e n t P a r a m ete r s

S e r v ic e in s t a n c e S 1



T e c h n ic a l

P r o to c o l: S O A P – IO P

IO P

SOAP

IO P /S O A P

I n t e r f a c e : d o c u m e n t, c o n su m er-n a m e, p ro o f-o fc r e d it

v

v

V

No

SSL

SSL

R e s p o n s e : f ir s t /s e c o n d c la s s

F irst

F ir s t , s e c o n d

F irst, sec o n d

L a ngu ages:

A t o B , A to C

A to B , B to A

D o c u m e n t fo r m a t: a s c ii /d o c / p d f

A s c i i/ d o c

A s c i i/ p d f

A t o B , A to C , A to D

R e la ti o n s h i p : p e r d o c u m e n t

v

v

v

C r e d it-p ro o f:

B an k

CC

CC

B a n k , C r e d itr a tin g O r g

0 .1 $ / w o r d

E -c o in , C C

c 3 $ /w o r d

S e c u r e - p r o to c o l : S S L

S e r v ic e

B u s in e s s

P a y m e n t m e th o d : E - c o i n /C C

No

C o s ti n g : p e r w o r d ( p w )

0 .1 5 $ /w o r d

E -c o in , C C Y es

Y es

S e c u r e -lin k : y e s /n o

L egal

C o n t r a c t : S ta n d a rd te r m A r b it r a t io n : tr a n s la ti o n

on

- sh o rt

q u a lit y

of

Y es

Y es

Y es

O rg X

O rg X , O rg Y

O rg X , O rg A , O rg B

F ig . 1 0 . A d e s c r ip tio n o f ® T s h o r t - th e s h o r t- te r m r e la tio n s h ip /a g r e e m e n t s u r r o u n d in g th e tr a n s la tio n s e r v ic e . T h e d e ta ils o f th e r e la tio n s h ip w ill b e p a r t o f th e a g r e e m e n t r e a c h e d b e tw e e n th e p a r tie s . T h e s e d e ta ils w ill d e te r m in e th e s tr u c tu r e a n d d e ta ils o f th e r e s u ltin g c o n tr a c t.


• A long-term relationship type (®Tlong figure 11): from a business perspective, this is a year-long relationship, with a one-off subscription fee and a ‘per-word’ cost. The service itself is similar to the service offered by the short-term relationship. The technical aspects of the service define CORBA and Web Services style of interaction and an interface type that expects the document in the permitted format and customer identification token. From a legal point of view, a long-term contract template defined in the domain is used. This template allows a quality guarantee to be present or not, and encompasses a penalty clause that specifies a fine of so much per day delay in delivery. Finally, the contract requires at least one arbitration organisation to be recognised by the two parties. ® T lo n g

R e la tio n s h ip / P a ra m e te r s

T e c h n ic a l

A greem ent

S e r v ic e in s ta n c e S la

S e r v ic e in s ta n c e S lb

P r o to c o l: S O A P – IO P I n te r f a c e : d o c u m e n t, c u sto m e r-Id S e c u r e -p r o t o c o l: S S L

IO P v SSL

SOAP v SSL

S e r v ic e

R e s p o n s e : firs t /s e c o n d c la s s L a n g u ag es: D o c u m e n t fo r m a t: a s c ii/d o c /p d f

F irs t A to B , A to C A s c ii/d o c

F ir s t, s e c o n d A to B , B to A A s c ii/p d f

B u s in e s s

R e la t io n s h ip : A n n u a l s u b s c r i p t io n S u b s c r ip tio n -fe e : o n e -o ff C o s tin g : p e r w o rd (p w ) P a y m e n t m e t h o d : E -c o in /C C S e c u r e -lin k : y e s /n o

A nnual $100 $ 0 .0 1 / w o r d CC No

A nnual $200 $ 0 .0 2 / w o r d E -c o in , C C Y es

L egal

C o n tr a c t: S ta n d a rd - lo n g te rm Q u a lity g u a r a n te e : T s o c ie ty P e n a lty : la te re s p o n se (p e r d a y d e la y ) A r b itr a t io n : o n q u a lity o f tra n s la tio n

Y es Y es $100 per day O rg X

Y es No $200 per day O rg X , Y

F i g . 1 1 . A d e s c r i p t i o n o f ® T l o n g - t h e s h o r t - t e r m r e l a t i o n s h i p / a g r e e m e n t s u r r o u n d in g t h e t r a n s l a t i o n s e r v i c e . T h e d e t a i l s o f t h e r e l a t i o n s h ip w i l l b e p a r t o f t h e a g r e e m e n t r e a c h e d b e tw e e n th e p a r tie s . T h e s e d e ta ils w ill d e te r m in e th e s tru c tu r e a n d d e ta ils o f th e r e s u ltin g c o n tra c t.

In the case of the short-term relationship, a payment is made at the end of the translation delivery and therefore requires the auxiliary payment service to be set up for each contract. This is different for the long-term relationship, which requires a subscription fee up front, but thereafter expects the payment at the end of the subscription period. The short-term relationship also requires the name of the organisation or person and some proof of payment. The long-term relationship requires the customer identification with the incoming document. Note that an almost identical service is being offered in both the short and the longterm relationship, with some differences in the interfaces. It could be argued that the treatment of the proof of credit and the customer identity should be dealt with by auxiliary services. As far as the consumer is concerned, the core service itself is identical. The important point is that the same service can serve different business purposes since it can be engulfed by different contracts, for example. Slightly different contracts can be


envisaged in the case of the long-term relationship – one with and one without a guarantee of minimum usage during the subscription. While this may not require any changes in the service itself, it may require monitoring. The same service may also be provided by different interfaces and communication protocols. Similarly, different types of services may serve the same business objective. The choice among different relationships may depend on business, legal, service and technology concerns (resources and restrictions). 5.1.

Using monolithic templates in the typed domain

Given the existence of the two monolithic relationship types, the desired relationship can be established by selection of the appropriate one using the information from the agreement as shown in figure 12.

® S h o rt M o n o lith ic C o n tra ct T y p e T e m p la te s

® T lo n g S e le c te d C o n tra ct T y p e & v a lu e s

A g reem en t ® S h o rt

+

+

® S h o rt

T y p ed D o m a in

Fig. 12. The agreement and its details help select the appropriate monolithic contract type.

6. Scenario 2: Composing the Contract from Clauses The scenario is made more complex by catering for a wider variety of relationship and agreement types. Each of those agreements requires a different contract. Instead of using the monolithic template approach, contract clauses are used as building blocks from which different contracts are assembled. This section shows how the rigidity of the monolithic contract types can be relaxed. Instead of using monolithic contract templates, the contract composition process uses contract clauses of smaller granularity that have to be assembled into complete contracts. These can subsequently be used in the matchmaking process and populated with the relevant information from the agreement. This approach requires the following to be defined: •

Building blocks: contract clause template components.

•

Composition rules: contract clause template selection and exclusion rules that will use the information from the agreement to determine which contract clauses should be included or excluded.

•

Ordering, consistency checks and restrictions: post contract clause selection processing to see if the assembled contract is valid in the context of the domain.


When moving to finer granularity building blocks and composition rules for assembling one entity in a system, the number of resulting options and the overall complexity has to be matched in other parts of the system, either by providing this variety exhaustively in a monolithic form, or by also providing finer granularity building blocks and composition rules. The example given is this Section shows that the result of three different binary options consists of eight different agreement configurations. Clearly, managing eight monolithic relationship types is hardly a problem. However, as the number of options increases and will not always be binary, the number of monolithic templates will increase rapidly. At some point it may be better to opt for the more flexible approach. The point at which it is better to produce smaller building blocks and composition rules than to introduce further monolithic types is clearly debatable. However it is clear that adding one more binary option doubles the number of types. When the number of existing types is already big, this may tip the balance in favour of the more flexible approach of composition. The following scenario builds on the scenario described in Section 5, extending its complexity by introducing further variations into several projections. In addition to having the possibility of short- and long-term relationships, it is now also possible to provide: • Payment: conducted using on-line or off-line access (i.e. external payment channels). • Audit: inclusion or exclusion of auditing that in turn uses monitoring of the delivery of service and payment (in the case of the on-line payment). The monolithic relationship/agreement types is being substituted by smaller granularity building blocks that allow the combinations shown in figure 13. The finer granularity and composition rules are kept for the selection of the appropriate type of relationship. The service configuration options, for example, have to be able to provide the functionality promised in the relationship. Whether this is also done by configuring the service from building blocks or whether there are monolithic service templates readily available for each type combination is a provider’s decision. 6.1. The domain space The additional options create eight possible Relationship/Agreement types that are supported by the domain (figure 13). The resulting Relationship/Agreement types are: 1. Relationship/Agreement ®T1 = short-term, on-line payment, delivery and payment audit. 2. Relationship/Agreement ®T2 = short-term, on-line payment, no audit. 3. Relationship/Agreement ®T3 = short-term, off-line payment, delivery audit. 4. Relationship/Agreement ®T4 = short-term, off-line payment, no audit. 5. Relationship/Agreement ®T5 = long-term, on-line payment, delivery and payment audit. 6. Relationship/Agreement ®T6 = long-term, on-line payment, no audit.


7. Relationship/Agreement ®T7 = long-term, off-line payment, delivery audit. 8. Relationship/Agreement ®T8 = long-term, off-line payment, no audit. R e s u lt in g R e la t io n s h ip / A greem en t T yp es

R e la t io n s h ip /A g r e e m e n t T y p e b u ild in g b lo c k s Short O n - lin e

A u d it

L ong

T erm c o n tr a ct

O ff - lin e

P ay m ent m e th o d

No A u d it

D e liv e r y paym ent

®T1

&

®T5

®T2

®T6

®T3

®T7

®T4

®T8

T y p e d D o m a in F ig . 1 3 . T h e r e la tio n s h ip /a g r e e m e n t t y p e b u ild in g - b lo c k s a n d th e v a r io u s r e la tio n s h ip ty p e s r e s u ltin g fr o m th e ir c o m p o s itio n . T h e b u ild in g b lo c k s a r e u s e d in th e c o m p o s itio n p r o c e s s s h o w n in fig u r e 1 4 .

In fact, the same technology used for contract composition is used in the relationship establishment phase to determine, from the business circumstances of the consumer and provider, what type of relationship/agreement the search for the compatible partner should be based on. The relationship/agreement type composition and the ensuing search for a business partner (possibly also using matchmaking technology), results in an agreement instance. The relationship and the agreement type can be generated from the relationship/agreement building blocks by using consumer information and requirements9 (figure 14). It should not come as a surprise that the process of selecting the right type of relationship is likely to be primarily business driven. The technology used to do this kind of transformation can be the same used to transform agreements into contracts, namely, R ela tio n sh ip / A g ree m e n t T y p e B u ild in g -B lo ck s

C o n su m er B u sin ess related in fo & req u irem en ts

S h o rt O ff

L on g On

A

+

No A

+

A sse m b led R ela tio n sh ip & A g ree m e n t Type

A g ree m en t S h o rt ® T 6 On No A

T y p ed D o m a in F ig. 1 4. T h e b u sin ess related in fo rm atio n an d req u irem en ts o f th e co n su m er h elp asse m b le th e ap p ro p riate relatio n sh ip an d ag ree m en t typ e fro m th e b u ild in g b lo ck s d efin ed b y th e d o m ain . T h e d escrip tion o f th e b u ildin g b lo ck s is sh o w n in figu re 1 3 .

matchmaking technology.


6.2. Using fine-granularity contract clauses templates Given the agreement instance that resulted from the relationship/agreement type composition process in (figure 14) and the negotiation process, the desired contract can be established by assembling the appropriate contract clauses and configuring them as shown in figure 15.

C1

C o n t r a c t c la u s e ( b u ild i n g - b lo c k ) t e m p la t e s

C4

C2

C5

C3

C6

A greem en t

+

Short On

+

®T6

No A

S e le c t e d C o n tr a c t C la u s e s & s p e c ific v a lu es fr o m agreem ent

C1 C4

T yp ed D o m a in

C6

F ig . 1 5 . T h e a g r e e m e n t in s ta n c e is u s e d to s e le c t a n d c o n fig u re th e a p p r o p r ia te c o n tr a c t c la u s e s in to a c o n tr a c t in s ta n c e .

7. Conclusions and Recommendations The negotiation process within the relationship establishment phase is likely to result in one or more types of agreements. We proposed a way of transforming those agreements into a contract in a dynamic, efficient and speedy manner, by using matchmaking technology in a novel fashion. The idea is based on advertising contract clauses into the matchmaking engine. Each clause advertisement has the relevant information for specialising the clause (in the form of dynamic properties), and rules that determine the applicability of the clause in the circumstances that are described by the incoming query. Determining the granularity of the contract building blocks and creating the composition rules may prove to be difficult for several reasons. First, it is not clear when a monolithic type should be broken and to what parts exactly. Second, in order to prevent exclusions and invalid combinations, ways of checking the validity of these compositions must therefore be developed. This is particularly important when complex contracts are involved. It is possible that powerful rules will be required to test the resulting type combinations for their validity and practical usefulness. There are a number of initiatives in the area of creating standard document representations such as Microsoft’s WordML - an xml standard for MS Word. The OASIS Open Office XML Format Technical Committee is defining a standard whose purpose is to create an open, XML-based file format specification for office applications19. Such standards will help in defining the kind of XML output that the contract composition has to produce in order to be able to be displayed and used as a proper document. An example of a special language to describe business agreements in the derivative market area is FpML20.


We discussed the composition rules, and the ordering, consistency checks and restrictions briefly in Section 4. The source of these has to be the application domain in which the related business is transacted and its legal anchoring in legislation, precedence or common law. The notion of a closed and typed domain which defines the possible service provider-consumer relationships is aimed at defining and investigating such an environment. The typed domain which can serve as the context for the composition of contracts is described in reference 9. The symmetric matchmaking process we refer to in Section 4, is based on the two parties submitting a description of themselves as well as rules that select the other party. When using the matchmaking process for contract generation, we have found a symmetric exchange of information, i.e. both parties submitting a description of themselves, to be necessary. On the other hand, it is sufficient in most cases for one side only to present rules – the party that advertises the clauses. This is different from the asymmetric model of CORBA Trading Service2 where the information exchange is asymmetric – only one party (the advertiser) submits information while the other party submits rules only (in the query). It is therefore possible that the general purpose matchmaking technology that we are using for this task can be specialised and made simpler and more efficient. One of the problems with the approach of dynamic contract generation is that it is not a stand-alone solution but part of a larger process that has to involve correctness and quality checks. It is therefore likely to expect the composition process to be part of a workflow or a document management system that ensures that the appropriate steps are taken and that the relevant experts can view and validate the automated process. One of the crucial aspects in the success of such a technology is the provision of appropriate tools to define the contract clauses with their dynamic properties and rules, create instances thereof, and test their correctness against business description input. Such tools will have to evolve from the generic tools that are needed for matchmaking technology. In particular, help in creating the consistency checks over the composed contracts will require careful consideration. References 1.

2. 3. 4. 5.

6.

7.

Angelove S. and Grefen P. An analysis of the B2B e-contracting domain: paradigms and required technology, Working Paper 102, Eindhoven Beta Research Programme, Eindhoven, September 2003. OMG, Object Management Group and X/Open Standard: "CORBA Trading Object Service", Document orbos/96-05–6, 1996. ODP, “Open Distributed Processing Reference Model”. ISO/IEC 10476, ITU-T Recommendation X.900, Parts 1–3, 1995. Meyer, Contracts for components, Bertrand Meyer, Software Development Magazine, July 2000. Milosevic Z, Berry A, Bond A, Raymond, K. “Supporting Business Contracts in Open Distributed Systems”. In Proceedings of the Second International Workshop on Services in Open Distributed Processing (SDNE95), Whistler, Canada, June 1995. Hoffner Y, Field S, Grefen P, Ludwig H. “Contract-driven creation and operation of virtual enterprises”. Computer Networks, The International Journal of Computer and Telecommunications Networking,North Holland, Volume 37, pp. 111-136, September 2001. Ströbel Michael "Engineering electronic negotiations", Kluwer Academic Publishers, New York, 2002.


8. 9.

10.

11.

12. 13. 14. 15.

16.

17.

18.

19.

20.

Keller, A and Ludwig, H. The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services. IBM Research Report RC22456. Yorktown Heights, 2002. Hoffner Y., Field S. and C. Facciorusso, “Strong and Flexible Domain Typing for Dynamic EBus”, The 8th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2004). 20-24 September 2004 Monterey, California, USA. Dignum F. “Agents, Markets, Institutions and Protocols.” In Agent Mediated Electronic Commerce, The European AgentLink Perspective, Dignum F. & Sierra C. Editors, Lecture Notes in Artificial Intelligence Vol. 1991. Berlin Heidelberg: Springer Verlag, 2001. Vetter M, Pitsch S. “Towards a Flexible Trading Process over the Internet”. In Agent Mediated Electronic Commerce, The European AgentLink Perspective, Dignum F. & Sierra C. Editors, Lecture Notes in Artificial Intelligence Vol. 1991, Berlin Heidelberg: Springer Verlag, 2001. Hoffner, Y. The e-Business on Demand Life Cycle, PRO-VE'03, IFIP Working Conference on VIRTUAL ENTERPRISES, Lugano 29-30 September 2003. Boundy, A., “A Concise Business Guide to Contract Law”, Gower Publishing Ltd. UK, 1998. Smith, J.C., “The Law of Contract”, 1989, Sweet & Maxwell Ltd., 1989. NJLRC, Draft Final Report relating to “Standard Form Contracts”, 1988, NJLRC – New Jersey Law Revision Commission, John M. Cannel, Executive Director, New Jersey Law Revision Commission, 153 Halsey Street, Box 47016 Newark, New Jersey 07101, email: [email protected], web site: http://www.lawrev.state.nj.us. Field S. and Hoffner Y. "In Search of the Right Partner", in Collaborative Business Ecosystems and Virtual Enterprises, PRO-VE'02, 3rd IFIP Working Conference on Infrastructures for Virtual Enterprises, Editor: Luis Camarinha-Matos, Kluwer Academic Publishers, May 2002. Facciorusso, C., Field, S., Hauser, R., Hoffner, Y., Humbel, R. Pawlitzek, R., Rjaibi. W. & Siminitz, C. (2003). A web services matchmaking engine for web services. In K. Bauknecht, A. Min Tjoa, and G. Quirchmayr (Eds.), Lecture notes in computer science: Vol. 2738. Ecommerce and web technologies: 4th international conference, EC-Web, Prague, Czech Republic, September 2-5, 2003. (pp. 37-49). Berlin Heidelberg: Springer-Verlag. Field S. and Hoffner Y. "Dynamic Contract Generation for Dynamic Business Relationships", Chapter in “Virtual Enterprise Integration: Technological and Organizational Perspectives”, Editors: G. D. Putnik, and M. M. Cunha, , IDEA Group Publishers, to appear in autumn 2004. OASIS Open Office XML Format Technical Committee, open, XML-based file format http://www.oasisspecification for office applications, 2004, open.org/committees/tc_home.php?wg_abbrev=office FpML™ - The XML standard for saps, derivatives and structured products. Retrieved from http://www.fpml.org/