Many enterprises are eager to take advantage of the emerging "Internet Economy". Internet based commerce offers more potential than just online storefronts (a.k.a. Business-to-Customer (B2C)) and auction sites (a.k.a. Customer-to-Customer (C2C)), it also offers opportunities in Business-to-Business (B2B) e-commerce. B2B covers the area of online exchange of information between trading partners. Some examples of B2B include:
• Trading partner integration between enterprises, forming supply and value chains and allowing automated coordination of business operations (e.g. order management, invoicing, shipping and government procurement).
• Business process integration. Integration of commerce sites, Enterprise Resource Planning systems and legacy systems. • Business-to-business portals enabling formation of trading communities, electronic catalog management, content syndication, and post-sale customer management. Example sites include www.mySAP.com, www.I2I.com and www.ariba.com.
A fundamental issue faced by many developers of B2B systems is how to ensure that you can trust a party that you are dealing with at arms length. The primary mechanism for doing this is by setting up a business contract and depending on the law to enforce the terms of the contract. The aim of this paper is to provide mechanisms to facilitate electronic business contracting. This involves support for electronic contract representation and also support for various contract operations. Typically, these include contract negotiation, validation, signing, tracking, monitoring and enforcing contract terms and conditions Section 2 starts this paper off by stating the requirements for business contracts in the context of B2B. Section 3 outlines a role-based architecture to support typical contract operations. Section 4 explains how XML can be used for the specification of business contracts. Section 5 presents an approach of using BizTalk technology to support the monitoring of business contracts. Section 6 concludes the paper.
A contract is a legally enforceable agreement in which two or more parties commit to certain obligations in return for certain rights [R89]. In a B2B context this can range from a simple one-page purchase order for the sale of goods, to an extremely complex thousand-page document for a trade level agreement between multinational businesses.
In general, most B2B scenarios can be generalized to a 5-phase trading process, of which contract formation is one phase [C93]:
• Pre-contractual phase: customers identify products or services and possible sources of supply; • Contractual phase: creation of a formal relationship between buyer and seller, covering contract negotiation and validation operations; • Ordering and Logistics phase: placing of purchase order, delivery of goods and services;
• Settlement phase: invoicing, payment authorization and payment; and • Post-processing phase: gathering information for management reports, e.g. trade statistics.
The focus of this paper is on the contractual phase and in particular supporting electronic contract representation and contract monitoring and enforcing operations.
There are up to four elements needed to create a valid business contract [R89]. First, an agreement has to be reached on all essential conditions of the contract.
The second element is the notion of consideration.
Each party establishes the obligation to give something to each other. Consideration can take the form of money, services rendered, property or individual rights. The third element is that of capacity (or competence): ensuring that parties entering into the contract are lawfully capable of agreeing to contracts (e.g. whether an individual has the authority to represent their organization). Finally, the legal purpose of the contract must be established. A contract cannot be enforced unless the actions agreed upon are legal in the jurisdiction where the contract is made.
In general, each of these elements will appear in a business contract as clauses covering [FL96]:
• The description of parties involved, including: names, addresses, roles etc; • The definition and interpretation of terms used in the contract; • The jurisdiction under which the validity, correctness, and enforcement of the contract will operate; • The duration and territory1 of the contract, which defines the times and places at which the contract is in force; • The nature of consideration e.g. fees, services rendered, goods exchanged, rights granted, etc; • The obligations associated with each role, which is expressed in terms of the criteria over the considerations. This includes terms and conditions for invoicing and payment such as warranties, delivery, liability, rejection, termination and accounting provisions.
A sample contract illustrating these elements is provided in appendix A.
In the context of B2B, many of the terms and conditions in the contract will form part of the software requirements that specify behavior of a B2B system. For example, terms and conditions associated with invoicing and payment will dictate what forms of electronic invoices are acceptable, when they are to be received, and how the payment is to follow. There will also be many terms and conditions that cannot be implemented (or are only partially automatable) and would require human actions and interventions.
In some business environments, such as insurance, cargo, real estate and banking, it would become highly complicated and costly if the terms of every contract had to be newly settled for each transaction. Significant savings can be achieved by reusing standard form contracts for newly established contract agreements [T95]. The terms of such standard contracts can be dictated by one party (e.g. the seller) or by a third party (e.g. in Queensland the Rental Tenancy Authority sets out a standard lease agreement for all leases in Queensland). Standard form contracts are also available for a fee from commercial organizations2 , which will provide general-purpose contracts for many business situations.
In some instances, new contracts can include standard contract clauses [FL96]. For example, some large institutions, like universities and government departments, may outline policies on standard contract clauses to be included in all contracts of a certain nature. In some cases standard contract clauses are defined by a standards body and are in use between many businesses. For example, the International Chamber of Commerce (ICC) 3 has outlined a set of "Incoterms" for use in specifying departure, shipment and arrival terms in international sales contracts. In terms of B2B, standard form contracts are essential, as they allow business to confidently operate at arms length. A business can deal with another business without the need to negotiate a new contract for each transaction. Furthermore, the standardized nature and the regular use of standard form contracts means that many elements are stable enough to be implemented as components in a B2B system. Finally, as many standard form contracts share similar elements and contract clauses, there exists the possibility to reusing components in different B2B systems.
The discussion in the above subsection suggests that the availability of electronic representation of standard contract forms and clauses can bring significant savings to the process of creating and negotiation contract terms. Electronic contract forms can be stored in an electronic repository that can be subsequently accessed and used by businesses to facilitate the definition of their mutual obligations.
It is important to note however that by electronic contracting we do not only mean an electronic version of contract forms but also a wide range of possibilities related to the automation of the typical contracting procedures or processes such as:
• location of suitable contract templates and/or contract clauses, • electronic negotiation of contracts,
• electronic signing of a contract, and having this as an evidence of the agreement; this can bring significant savings, in particular in cases where contracts involve multiple, geographically distributed trading partners, such as those related to international contracts, • electronic tracking -This allows timely reaction to some important deadlines such as contract termination, thus making it possible to renegotiate a subsequent contract and put it in place, before or immediately after the existing contract terminates. • monitoring of the behaviour of the trading partners who have entered in contractual relationship and, possibly, • enforcing behaviour of trading partners so that their contractual operations are met.
An essential element of trust in a B2B system is the legal enforceability a contract. In order to create certainty for electronic contracts, legal groups, such as American Bar Association (ABA), have established several rules for enforcement of a contracts in the B2B area [W94]. These rules cover issues such as fraud, transmission and receipt of messages, evidentiary concerns, prior terms and conditions, and liability due to failures or malfunctions. Discussion of these rules and their implications is out of the scope of this paper.
Based on the above requirements for business contracts in B2B systems, we have identified the basic roles needed to support typical operations associated with contract establishment, monitoring and enforcement [MB95,MAL96]. These roles are:
The Contract Repository (CR) is needed to store standard form contracts and standard contract clauses.
The Notary is used to store signed instances of standard form contracts which, can later be used as evidence of agreement in contract monitoring and enforcement activities.
The Contract Monitor (CM) enables monitoring of the activities of parties by measuring their conformance to contractual terms and conditions and signals the contract enforcer if it detects a violation.
The Contract Enforcer (CE), upon being signaled by the CM, performs enforcing actions such as sending a message to various parties informing them of the violation and possibly preventing further access to the system by non-conforming parties.
The Contract Validator (CV) ensures the creation of legally valid contract instances by checking the four aspects of contract validity (discussed in 2.1):
• Competence. To accomplish this, the CV verifies the capacity of parties willing to enter a contractual relationship. • Clarity. In most cases the contract semantics will be unambiguous if it is derived from a template in the CR. The CV can be used to provide additional checking if needed. • Legal purpose. The legal purpose of a clause or contract can be validated based on information in a repository of legal rules. • Consideration. The CV can ensure the contract contains contract elements describing what is exchanged between the parties. Some elements of contract validation are very difficult for a computer to perform. For example, the clarity and legal purpose elements are very difficult to model and verify. Attempts have been made in the area of deontic logic, however, this work is still preliminary [TT98]. One approach to address this problem is to establish some systems of credentials that would guarantee legal validity of contract templates.
Some elements of contract validity are possible to automate, such as checking the consideration aspects (by inspecting signed contract instances) and competence aspects (by enforcing rules for signing contracts by people with the legal authority to do so, as discussed in [MAL96]).
The Contract Negotiator (CN) is an optional role that can be used to mediate the negotiation of contracts in the pre-contractual phase. Automated contract negotiation is another area with significant challenges as much of this work requires reasoning about the effect of obligations outlined in a contract and then negotiating based on this. Some attempts to solve related problems have been made in the area of intelligent agents [S96].
Based on the analysis of contracts presented in section 2.1, we have defined a model for contracts.
The model (shown in figure 1) for a contract is broken down into the following elements:
• A preamble which outlines the parties involved in the contract and the nature of the consideration; • A list of contract clauses, clustered in logical groups. In some cases, a contract clause itself may be a pointer to a standard contract clause provided by an external institution;
• An approval section which enumerates whom from each party approved the contract; and • A digital signature section with digital signatures from the appropriate parties listed in the approval section; and • Finally, a separate section contains a list of policy specifications stating contract enforcement rules according to the agreed contract clauses. This aspect will be explained in detail in section 4.2.
In this paper, we will be encoding this model using XML. Given the textual nature of business contracts, XML is the logical choice for capturing the structure of a contract while preserving the text of the contract. Furthermore, essential pieces of emergent XML infrastructure can be used to advantage, namely: CBL, XML-DSig, XSLT, and XML repositories as will be discussed in the following sections. • Documents to send, reply to and check the status of purchase orders; • Documents related to invoices;
• Documents used to check the price and availability of goods; and • Documents used to maintain product catalogs.
Each of these documents is built out of smaller elements, such as elements for customer details, delivery information, product descriptions, names, addresses, list of part numbers, prices, currencies, countries, dates, etc. This is an important feature as it already provides elements that can be reused in a business contract specification.
CBL also provides the concept of a contract, which is very brief and only includes a contract identifier and start and end dates. In this paper we have taken the CBL contract and extended it to include the additional elements illustrated in figure 1. Appendix B provides an example of a CBL-based description of the contract introduced in Appendix A7 .
The standard form contracts are stored in the Contract Repository. This can be implemented using any number of existing XML-enabled repositories, such as relational databases provided by Oracle, Informix, Sybase and Microsoft. Specialized XML repositories can also be used.
The agreed upon and signed contract instances are stored in a Notary repository, which can be implemented using the same repository implementation choices as above.
The signing of contract instances can be facilitated using XML-DSig compliant signatures. XML-DSig8 is a digital signature standard currently being jointly worked upon by the W3C and IETF. The use of such signatures will prevent fraud by providing mechanisms to guarantee integrity, authenticity and privacy of XML documents. Further protection can also be achieved by using a third party, such as Verisign9 , as a certificate authority to prevent the tampering with of signatures by one of the parties.
Finally, to facilitate human user viewing of contracts, an XML contract can be rendered in HTML by using a transformation technology like XSLT10 . This implementation detail is beyond the scope of this paper.
In this paper, the contractual terms and conditions are modeled as a policy which specifies that a role is either forbidden or obligated to perform actions under certain conditions. Each of the contract clauses can be regarded as a high-level policy statement. However, these statements need to be further refined so that they express constraints on the actions that parties involved in contract need to fulfill -as a result of their contractual obligations. These actions can then be monitored, if required, and if they do not comply with those agreed in the contract, then the Contract Monitor can signal this non-performance to the Contract Enforcer to perform an action on a specified role.
The formulation of this policy system has been influenced jointly by the Event-Condition-Action (ECA) paradigm from active databases [UW97] and the ODP enterprise language [SD99]. The core part of the grammar for this policy system is formulated as: To illustrate the various parts of this grammar consider the following policy statement: This policy statement encodes clauses 2.1, 3.1, 3.2, 4.1 and 7.1 in the contract in Appendix A. These clauses collectively specify that a purchase order must be sent within 7 days of the commencement of the contract, otherwise a notice of breach will be sent. The policy statement starts out by defining a number of convenient variables, such as P, S, start_date, etc that can be used throughout the policy statement. These variables actually refer to values within the contract. For example, the variable P is defined as the purchaser within the contract.
The second part of the policy specifies when a policy should be checked. In the example above the when condition specifies that the contract is in its initial state, i.e. no actions have occurred yet, it should be checked. Note that for the when statement to be effective the system needs to be able to query the state of a contract. Therefore, the contract monitor needs to maintain the state of a contract and make it accessible for policy evaluation. Through the state mechanism it is also possible to specify sequences of actions that must occur by using a set of policy statements linked by changes of state.
The third part specifies that an action called send_purchase_order must be performed by an actor called P (the purchaser) on an audience S (the supplier) at time stored in the variable t1 with the body of the message stored in variable b1.
The fourth part specifies that the action must occur within 7 days of the contract start date and the body of the purchase order must use the valid price list and specify the delivery terms for the goods. Note that in this section it is possible to specify that operations may not occur.
The fifth and final part of the specification nominates the action that must be triggered if this policy is not met. In this case, a notice of breach is sent to both parties informing them that the purchaser failed to send a valid purchase order.
Policy statements can be embedded in XML. The benefits of doing this are that additional annotations, such as references to clauses in the main contract can be added. For example, the above policy could be embedded as follows Annotations to policies can be used later to help diagnose the nature of the violation. For example, the system could provide a user with the text of violated clauses by following the clause references.
The policy specification language included in this paper is our first step towards developing a more well 11 Note that the schema for this XML document has not been included here to save space. This schema is available upon request. Also note that it is possible to define the syntax of the policy language in XML. This has certain advantages in terms of processinghowever, we have not done that here, as a textual form is more readable. defined language. There are a number of issues yet to be considered including: Termination: Can we guarantee that if policies cause other policies to be triggered that eventually the system will reach a steady state and no more policies will be triggered? • Confluence: Is the order of evaluation of policy statements relevant? • Practicality: Does the underlying B2B infrastructure provide enough information to enable policy statements to be evaluated?
In future work we hope to address some of these issues by establishing a model and formal semantics for this language, and then demonstrate its feasibility through an implementation.
Previously, we have implemented a prototype of various business contract application roles using standard CORBA technology [M95]. We are currently in the process of porting it to component technologies such as J2EE and Microsoft's Windows DNA. This paper reports on our work in progress related to the use of DNA's BizTalk12 . We are experimenting with the BizTalk technology as it offers facilities to support rapid prototyping of B2B specific services and utilities. These services are COM+ extensions that use the underlying storage (SQL Server), transport (HTTP, SMTP, MSMQ, SOAP, etc) and formats (XML, HTML, EDI X12, EDIFACT, etc) to build B2B systems. The utilities include: BizTalk XML Schema Editor to create and modify XML schema specifications; a BizTalk Mapper to provide data transformations; and other administration tools, that provide control over document flow, document tracking, business analysis and troubleshooting.
In the following section, we will describe how the role of a contract monitor can be implemented. Other roles will not be discussed. Some roles such as the contract repository and notary can be implemented in a straightforward fashion using SQL Server. Other roles such as the contract negotiator and validator are complex and are out of the scope of this paper.
As illustrated in figure 2 the contract monitor could be implemented by using some of the existing BizTalk services. The central piece to this system is a Contract Monitor Manager (CMM). The main role of the CMM is to manage the various settings within the SQL server and message queue. Over time as new contracts are formed and old contracts are amended or terminated each of these items will need to be added to, updated and removed.
When the CMM receives a policy statement, the CMM analyses the <action> section of each policy and installs triggers on a message queue. As each party communicates messages to one another using the message queue, the triggers will search for appropriate messages to be archived on an SQL server.
Once a history of messages has been archived on the SQL server, the sequence can be analyzed to determine if the contract has been violated. This is done in a two step process. First, triggers which are designed to determine the state of the contract as messages archive are created on the message archive, This state is then stored in a contract state table . A second set of SQL triggers are defined on the state table and are based on the when <action> part of a policy. When fired, these state-based triggers call stored procedures, which inspect messages in the message archive to determine their validity based on the must [not] occur when <condition> part of the policy statement. Finally, if the condition is violated then the stored procedure raises a message on the message queue based on the otherwise <trigger_action> part of the policy.
Finally, note that one of the advantages of defining policy statements in a declarative fashion is that it enables us to separate policy specification from how the applications are actually built. This means that it should be possible to build a contract monitor for a system built on other methodologies such as Workflow or RPCs without changing the policy specification language.
This paper has outlined our work in progress, which uses: 1) an XML-based business extension to describe business contracts and 2) BizTalk server capabilities to facilitate the process of encoding policies for monitoring and enforcing contracts. The novelty of our approach is that we provide support for a declarative way of specifying policies for contracts. The main benefit of this is that it enables a separation between enforcement policy specification and the functional specification of the operations needed to support contract operations. The use of the BizTalk platform enables flexible updates of contract enforcement rules to accommodate changes in business policies related to contract enforcement.
Our XML-based approach for specifying contracts is similar to some of the results from the CrossFlow13 project, with the additional feature of using an XML extension (i.e. CBL) to embody some business documents semantics. Furthermore, our approach of defining and implementing the roles needed to support of contract operations has some similarity to recent IBM work on contracts14 . Unlike the IBM approach, our approach is focussed on supporting business and in particular legal views on contracts and thus our business contract architecture does not include low-level concerns such as security and transport mechanisms used to support contract operations. These can be regarded as implementation choices specific to the deployment environment.
In this paper, we have also identified several open issues that we plan to investigate in the future. Examples of these issues include better support for contract negotiation, conflict detection and resolution of the legal rules when composing customized contracts, and better support for policies to govern service provision through cross-organizational business process. with respect to this agreement.
The commencement date is scheduled as [date].
The completion date is scheduled as [date].
The schedule may be modified by agreement as defined in Section 9.
The (Purchaser) shall follow the (Supplier) price lists.
The (Purchaser) shall present (Supplier) with a purchase order for the provision of (Goods) within 7 days of the commencement date.
The purchase order shall nominate the method of delivery as defined in Section 4.
Purchase orders are to be sent electronically, and are to be interpreted under standards and guidelines outlined in Supplement A.
The (Purchaser) shall arrange for delivery to be made according to one of the following terms: (a)
The shipping and insurance of the (Goods) shall be the sole responsibility of and entirely at the expense of the (Purchaser). (b)
The shipping and insurance of the (Goods) shall be the responsibility of the (Supplier). The (Purchaser) shall provide the (Supplier) at least [days] days notice and pay the carriage and insurance costs from the (Supplier) delivery price list.
The payment terms shall be in full upon receipt of invoice. Interest shall be charged at [percentage] on accounts not paid within 14 days of the invoice date. The prices shall be as stated in the sales order unless otherwise agreed in writing by the (Supplier).
Payments are to be sent electronically, and are to be performed under standards and guidelines outlined in Supplement B. 6. Rejection 6.1
If the (Goods) do not comply with the Order or the (Supplier) does not comply with any of the conditions, then the (Purchaser) shall at its sole discretion be entitled to reject the (Goods) and the Order. The (Purchaser) shall return the rejected (Goods) to the (Supplier) at the (Purchaser) risk and expense or notify the (Supplier) to collect the (Goods). The (Supplier) may use its discretion to replace the (Goods) according to the invoice or refund any monies paid.
If (Purchaser) fails to carry out any of its obligations and duties under this agreement (Supplier) may issue a notice specifying the breach and request that it be remedied within 14 days after receipt of such notice.
If (Purchaser) fails to provide adequate remedy within the specified 14 days the agreement may be terminated forthwith. 8. Disputes 8.1 (Supplier) and (Purchaser) shall attempt to settle all disputes, claims or controversies arising under or in connection with the agreement through consultation and negotiations in good faith and a spirit of mutual cooperation.
This method of determination of any dispute is without prejudice to the right of any party to have the matter judicially determined by a [Country] Court of competent jurisdiction. 9. Amendment 9.1
This agreement may only be amended in writing signed by or on behalf of both parties.
In witness whereof (Supplier) and (Purchaser) have caused this agreement to be entered into by their duly authorized representatives as of the effective date written below.
The authors would like to thank Andy Bond and Linda Bird for their comments on this paper.
The work reported in this paper has been funded in part by the Co-operative Research Centre Program through the Department of Industry, Science & Tourism, Australia.
The shipping and insurance of the <itemref ID='I1'/> shall be the responsibility of the <partyref ID='P1'/>. The <partyref IDREF='P2'/> shall provide the <partyref IDREF='P1'/> at least <days> </days> days notice and pay the carriage and insurance costs from the <partyref IDREF='P1'/> delivery price list. </clause> <clausegroup ID='G5 ' title = 'Payment'> <clause ID='C5.1' behavior = ' '/> The payment terms shall be in full upon receipt of invoice. Interest shall be charged at <percentage> </percentage> on accounts not paid within <days> </days> days of the invoice date. The prices shall be as stated in the sales order unless otherwise agreed in writing by the <partyref IDREF='P1'/>. </clause> <clause ID='C5.2'> Payments are to be sent electronically, and are to be performed under standards and guidelines outlined in <supplementref IDREF = 'SupplementB'>.</clause> </clausegroup> <clausegroup ID='G6' title='Rejection'> <clause ID='C6.1'> If the <itemref IDREF='I1'/> do not comply with the Order or the <partyref IDREF='P1'/> does not comply with any of the conditions, then the <partyref IDREF='P2'/> shall at its sole discretion be entitled to reject the <itemref IDREF='I1'/> and the Order. The <partyref IDREF='P2'/> shall return the rejected <itemref IDREF='I1'/> to the <partyref IDREF='P1'/> at the <partyref IDREF='P2'/> risk and expense or notify the <partyref IDREF='P1'/> to collect the <itemref IDREF='I1'/>. The <partyref IDREF='P1'/> may use its discretion to replace the <itemref IDREF='I1'/> according to the invoice or refund any monies paid.</clause> <clausegroup ID='G7' title = 'Termination'> <clause ID='C7.1'> If <partyref IDREF='P2'/> fails to carry out any of its obligations and duties under this agreement <partyref IDREF='P1'/> may issue a notice specifying the breach and request that it be remedied within <days> 14 </days> days after receipt of such notice. </clause> <clause ID='C7.2 '> If <partyref IDREF='P2'/> fails to provide adequate remedy within the specified <days> 14 days </days> the agreement may be terminated forthwith. </clause> </clausegroup> <clausegroup ID='G8' title = 'Disputes'> <clause ID='C8.1'> <partyref IDREF='P1'/> and <partyref IDREF='P2'/> shall attempt to settle all disputes, claims or controversies arising under or in connection with the agreement through consultation and negotiations in good faith and a spirit of mutual cooperation. </clause>