Business-to-business integration with tpaML and a business-to-business protocol framework

Business-to-businessintegration withtpaML and abusiness-to-businessprotocol framework

by A. DanD. M. DiasR. KearneyT. C. Lau

T. N. NguyenF. N. ParrM. W. SachsH. H. Shaikh

In business-to-business interactions spanningelectronic commerce, supply chain management,and other applications, the terms and conditionsdescribing the electronic interactions betweenbusinesses can be expressed as an electroniccontract or trading partner agreement (TPA).From the TPA, configuration information andcode that embody the terms and conditions canbe generated automatically at each tradingpartner’s site. The TPA expresses the rules ofinteraction between the parties to the TPA whilemaintaining complete independence of theinternal processes at each party from the otherparties. It represents a long-running conversationthat comprises a single unit of business. Thispaper summarizes the needs of interbusinesselectronic interactions. Then it describes thebasic principles of electronic TPAs, followed byan overview of the proposed TPA language. Thebusiness-to-business protocol framework (BPF)provides various tools and run-time services forsupporting TPA-based interaction and integrationwith business applications. Finally, we describeexamples of solutions constructed using TPAsand BPF.

As we enter the new millennium, fundamentalchanges are happening to trade and the way it

is organized. There is a growing shift toward an elec-tronically connected world in which ideas, informa-tion, and services are replacing the traditional re-liance on physical goods production as the primarygenerator of wealth and employment. In this neweconomy, market dynamics will dictate a businessmodel that provides for the integration of differentpartners in a value chain. Using a variety of tech-nologies from information technology (IT), thismodel can enable highly coordinated trading com-

munities, each with the ability to operate like a “vir-tual enterprise.”

The emerging e-business Web economy requires anagile enterprise that can work more directly with sup-pliers and customers and respond more rapidly andintelligently to change. Technologies such as the In-ternet are beginning to transform traditional busi-ness models. Business pressures—margin erosion,channel proliferation, rising customer expectations,time-based competition, and faster product com-moditization—are placing increased emphasis onhow organizations operate and interoperate withother enterprises.

To enable customers to adapt to these dramaticchanges in the business environment, middlewarewill increasingly be required to provide dynamic andflexible integration between partners in the valuechain. Although new technologies will be needed toenable such integration, they will have to work seam-lessly with existing interenterprise business processes(e.g., EDI—Electronic Data Interchange) and lever-age investments in existing enterprise application in-tegration (EAI).

This paper describes new middleware technology forbusiness-to-business integration developed and pro-totyped by IBM Research. The central innovationis trading-partner agreement Markup Language

rCopyright 2001 by International Business Machines Corpora-tion. Copying in printed form for private use is permitted with-out payment of royalty provided that (1) each reproduction is donewithout alteration and (2) the Journal reference and IBM copy-right notice are included on the first page. The title and abstract,but no other portions, of this paper may be copied or distributedroyalty free without further permission by computer-based andother information-service systems. Permission to republish anyother portion of this paper must be obtained from the Editor.

DAN ET AL. 0018-8670/01/$5.00 © 2001 IBM IBM SYSTEMS JOURNAL, VOL 40, NO 1, 200168

(tpaML)—an Extensible Markup Language (XML)1,2

grammar for expressing electronic trading-partneragreements and a candidate for standardization. IBMResearch has also designed and prototyped the busi-ness-to-business protocol framework (BPF). This run-time framework enables business protocols expressedin tpaML to be automatically deployed. We describeBPF and its use in some example scenarios to makethe case that tpaML-based integration is both fea-sible and effective.

In the next section of the paper, we detail the issuesthat need to be addressed in business-to-business in-teractions. Subsequently, we discuss the principlesof business-to-business electronic trading-partneragreements (TPAs). Then we describe our TPA lan-guage. The fifth section describes the architectureand initial implementation of BPF. Afterward, we de-scribe the tools for creating TPAs and generating codefrom them. Finally, we describe application exam-ples that illustrate the use of the TPA and BPF.

Interbusiness electronic interactions

In this section, what is required for electronic inter-actions between businesses and the technical pro-cedures to implement the interactions are described.

Business requirements. Facilities such as EDI havesuccessfully provided electronic document inter-change between companies and their suppliers fora number of years. However, the high cost of EDIand its dependency on specialized deployment skillshave always proved a barrier to adoption by all butthe largest enterprises. Although EDI will continueto evolve, utilizing pervasive networks such as theInternet to reduce costs, complementary technolo-gies are emerging that are able to provide some ofthe key capabilities necessary to enable dynamic bus-iness process integration. The basis of these tech-nologies is the formulation of:

● A “common language” that can be employed byexisting or potential trading partners to specify howthey will interact

● An “electronic contract” that employs this com-mon language in order to define and enforce theinteraction protocols with which they will do bus-iness

Business-to-business protocols such as Open Buy-ing on the Internet** (OBI**)3 and RosettaNet**4

are beginning to set a standard for business inter-actions (albeit currently fragmented). Our research

work has demonstrated that tpaML and BPF providea comprehensive tool set for the specification, con-figuration, customization, and execution of electronicTPAs.

Business-to-business interchanges based on EDI havelong been defined by informal textual documentscalled TPAs. These TPAs are contracts that define boththe legal terms and conditions and the technical spec-ifications that both partners must implement to putthe electronic trading relationship into effect. Theyare given to each partner’s programmers to imple-ment the technical specifications and are thereforesubject to misinterpretation, resulting in implemen-tation errors that must be corrected before electronicexchanges can begin. In contrast, an electronic TPAcan be used to automatically generate (using suit-able tools) the necessary customization informationin each partner’s system, thus assuring that the sys-tems are compatibly and correctly set up for elec-tronic business.

IBM has submitted a draft of tpaML to the ElectronicBusiness XML (ebXML) initiative5 for standardiza-tion. Standardization of the TPA language is a keyelement of interoperability between the business-to-business servers of different vendors.

Technologies such as XML and TPAs, coupled withadvances in middleware and workflow software, pro-vide the key building blocks needed to underpin anelectronic business-to-business integration infra-structure. Supporting the extensible and easy-to-useTPA format with the BPF framework and middlewarefrom IBM’s MQSeries* and WebSphere* families en-ables dynamic business process integration by pro-viding:

● Integration of internal processes, using modifiable“business rules” to route information between thevarious internal business information systems

● Secure, reliable, and auditable e-document inter-change between organizations

● Externalization of appropriate business functionsand processes to suppliers, customers, and part-ners

In addition, this infrastructure can provide supportfor:

● The use of a broad range of standard message for-mats, transport and business protocols, and net-work connections with the capability to dynamicallyconnect new trading partners

IBM SYSTEMS JOURNAL, VOL 40, NO 1, 2001 DAN ET AL. 69

● Easy-to-use, business-oriented “single point of con-trol” for interactions across an extended or virtualenterprise

● Extensible open interfaces with flexible connectorsto link to existing applications

The BPF addresses these requirements. Figure 1 il-lustrates the use of BPF for communication betweentwo trading partners. The trading partners are onthe left and right sides of the figure, connected byBPF, shown as a lightning bolt. Each partner has abusiness-to-business server that hosts the applicationand includes either BPF or equivalent compatiblemiddleware. At each partner the business processcan be seen, consisting of one or more applicationsand some back-end processes such as workflow.Listed in the center are three requirements for suc-cessful business-to-business middleware: no sharedmiddleware, long-running conversations, and sup-port for untrusted access. These requirements arediscussed later.

Technical basis for interbusiness electronic inter-actions. Contracts describe legally enforceable termsand conditions in all kinds of interactions between

people and organizations. Examples of interactionsare marriage, employment, real estate purchases, andindustrial supply arrangements. In business-to-busi-ness electronic commerce, there is a need to agreenot only on the traditional terms and conditions butalso on IT procedures ranging from communicationprotocols to business protocols.6 Today such con-tracts, the trading-partner agreements, or TPAs, aregenerally written in human languages and thenturned into code by programmers.

Adoption of business-to-business electronic com-merce will be considerably accelerated by express-ing the IT terms and conditions as electronic TPAsfrom which the code to perform the terms and con-ditions can be automatically generated at each par-ty’s business-to-business server. Use of electronicTPAs will speed up the reduction of the terms andconditions to code and ensure that the code at eachbusiness partner’s site will accurately embody the de-sired terms and conditions. In the longer term, elec-tronic TPAs will also facilitate electronic negotiationof terms and conditions, at least for the simpler sit-uations that need not involve extensive legal nego-tiation. Electronic negotiation in turn opens the pos-

NO SHARED MIDDLEWARE TRADING PARTNERTRADING PARTNER

UNTRUSTEDACCESS

BPF

LONG-RUNNINGCONVERSATIONS

BACK-END PROCESSES

BACK-ENDINTEGRATION

BEP

BEP

BACK-END PROCESSESBEP

WORKFLOW

BUSINESSPROCESS

APPLICATION

APPLICATION

APPLICATION

BACK-ENDINTEGRATION

BUSINESSPROCESS

APPLICATION

APPLICATIONAPPLICATION

XML

TPAs

WORKFLOW

BEP

DAN ET AL. IBM SYSTEMS JOURNAL, VOL 40, NO 1, 200170

sibility for spontaneous electronic commerce, i.e.,quick and easy setup of business-to-business dealson the Internet.7

In recent years, there has been much activity in mod-eling and analyzing various electronic commercemethods using contract or agreement approaches.Dan and Parr8 and Weigand and Ngu9 discuss howinteroperable transactions in electronic commercediffer from traditional ACID (atomic, consistent, iso-lated, durable) transactions10 and the importance ofdistinguishing between the contract (communicationbehavior) and the task (the meaningful unit of work).They propose a scheme for specifying the contractthat is suitable for analyzing the process.

Ajisaka11 discusses software as an object of electroniccommerce and proposes an architecture for manag-ing custom software development by contract. Sand-holm12 describes algorithms for modeling electroniccommerce transactions that do not require enforce-ment. Sandholm and Lesser13 discuss issues in au-tomated negotiation among agents whose rational-ity is bounded by computational complexity. Konanaet al.14 describe an approach to improve quality ofservice in multimedia information delivery based onconceptual contracts between end users and surro-gate servers and among the surrogate servers.

Many of the publications cited above discuss con-ceptual contracts as part of their models, but theydo not suggest a specific business-to-business con-tract language or discuss embodiment of a systembased on such a contract. Dan and Parr6 discuss thegeneral principles in business-to-business electroniccommerce and mention the use of a business-to-busi-ness electronic contract but provide no details. Danet al.7 discuss the specific functions needed in a busi-ness-to-business electronic contract and describe thearchitecture of the prototype of a business-to-busi-ness server built at IBM Research but do not describea specific contract language. In this paper, we dis-cuss the language for an electronic TPA and the toolsto assist in composing the TPA and generating codefrom it.

Increased automation of business processes withina business organization leads naturally to automa-tion of business-to-business interactions.15 The is-sues of privacy, autonomy, heterogeneity in softwareand platforms and, more importantly, managingcomplexity of interactions, however, make this a chal-lenging task. Some of these issues, e.g., heterogene-ity of programming languages and platforms in which

the application components are developed, andstateful interactions across program components, arealso addressed in the automation of business inter-nal processes and integrating application compo-

nents. Total knowledge and control in the design ofthe business process within an organization make thisa manageable task.

Component architectures such as Common ObjectRequest Broker Architecture** (CORBA**)16 andEnterprise JavaBeans**17 provide middleware forintegrating application components written in dif-ferent languages. For the purpose of interaction, anapplication component needs to know only the in-terfaces to other components written in a suitablemiddleware integration language (e.g., interface def-inition language, or IDL, in CORBA). In such envi-ronments, typically, the applications are executed asshort ACID transactions. The underlying middlewareprovides necessary run-time services, e.g., naming,transaction, and resource allocation. A long-dura-tion application is modeled as a sequence of shortindependent steps invoked either manually or in anautomated manner.15,18,19

Most methodologies reported in the academic lit-erature propose a specific request protocol or “soft-ware bus” for automating the internal processes ofindividual businesses. These methodologies are notdirectly applicable to the automation of business-to-business interactions. First and foremost, no com-mon shared underlying middleware can be assumedfor distributed applications spanning organizationalboundaries. Setting up such a common software busrequires tight coupling of the business partners’ soft-ware platforms (e.g., consider the issues on security,naming, and component registration).

Second, even if such a software bus can be estab-lished, ACID or complex extended transaction mod-els of stateful interactions, or both, are not appro-priate for such business-to-business interactions.Implementation of such protocols necessitates tight

The invocation ofapplication components

across organizationalboundaries needs to be

controlled and monitored.


coupling of operational states across business appli-cations, which is highly undesirable. The applicationcomponents in one organization may hold locks andresources in other organizations for an extended pe-riod of time, resulting in loss of autonomy. Rollbackor compensation of application steps, or both, is nolonger under the control of a single organization. Inreal-world business operations the states alwaysmove forward, and explicit recourse actions are takenby business partners to move to a more desirable op-erational state. An example is cancellation of a priorpurchase or reservation.

As discussed in Dan and Parr,8 the middleware andTPA provide a conversational model of interactionswherein, based on the conversation history, eachpartner explicitly specifies the permissible opera-tions. We refer to such a model as a long-runningconversation. The long-running conversation is themodel by BPF of a single unit of business. The long-running conversation is not an ACID transaction; itis simply a grouping of the related operations thatcomprise the unit of business. Each partner’s systemtracks the state of the conversation and maintainsa log that can be used for purposes such as audit trailand recovery.

For management purposes, the internal business pro-cess is separated from external interactions. Eachtrading partner manages and is responsible for itsown internal activities in the business-to-business ap-plication and may use ACID transactions within itsown domain. The model furthermore structures theexternal interactions as actions consisting of requests,responses, modifications, or cancellations, groups ofactions that together satisfy certain interaction rules,and conversations demarcating interaction contexts.Interactions in one conversation may trigger actionsin other conversations via execution of internal bus-iness logic. In this way, BPF can manage a supply-chain situation in which a business partner, duringa long-running conversation, may call upon subcon-tractors.

The invocation of application components across or-ganizational boundaries needs to be controlled andmonitored.6,7 First, without rigorous testing andcooperation in software development across orga-nizations, the correct execution of such complex dis-tributed applications cannot be assumed. Second, insuch automated interactions, trust becomes an over-arching concern. During run time, explicit checks arenecessary to ensure that business partners are notviolating any policy constraints (e.g., cancellation of

a reservation must be within the allowable time win-dow).

Principles of business-to-businesselectronic TPAs

The purpose of the electronic TPA is to express theIT terms and conditions to which the parties to theTPA must agree in a form in which configuration in-formation and the executable interaction rules canbe automatically generated from the TPA in each par-ty’s system. It should be understood that the infor-mation in the TPA is not a complete description ofthe application but only a description of the inter-actions between the parties. The application encod-ing the endpoint business logic must be designed andprogrammed in the usual manner. As a simple ex-ample, the TPA may define requests such as “reservehotel.” The “reserve hotel” function must be de-signed, coded, and installed on the hotel server. Thatfunction may, in turn, invoke various site-specificfunctions and back-end processes whose details arecompletely invisible to the other party to the TPA.

We emphasize that the TPA is formulated to ensurethat each party maintains complete independencefrom the other party both as to the details of the im-plementations and as to the nature of the businessprocesses and back-end functions (database, trans-action monitors, enterprise resource planning func-tions, etc.) used. For example, as previously men-tioned, the TPA neither requires, nor provides themeans for, ACID transactions involving both parties.

In describing the TPA language, we use the terms “cli-ent” and “server” in the usual way. A client requestsservices of a server. However, we envision applica-tions in which a given party may play both server andclient roles at different times. In other words, a partymay both request services of the other party and re-ceive service requests from the other party. In thesimplest applications, there are two parties, one ofwhich is always a server and the other always a cli-ent. An example is a travel application involving atravel agency (client) and an airline company (serv-er). Even in such a simple case, however, the partiesmay exchange roles. For example, the airline com-pany may issue requests to the travel agency for moreinformation about the traveler or itinerary.

In our implementation, the TPA is represented in therun-time system at each party that acts as a serverby an object, called a TPA object. The TPA object per-forms rule checking and translation of the request


messages from the form defined in the TPA to theactual method calls at the parties that act as servers.A similar TPA object, generated at each party, thatcan act as a client to the other party, performs theinverse translation, from local method calls to therequest messages, as defined in the TPA, which aresent to the other party. A party that can act as botha client and as a server has both kinds of TPA object.Use of the TPA objects is illustrated in the examplesgiven later in the paper.

The TPA execution instance represents a single long-running conversation, which is a set of related in-teractions, dispersed in time, comprising a single unitof business. For example, in a travel application, theTPA might define the interactions between the travelagent and a hotel company starting from the pointwhere the different reservations needed by the trav-eler are made, to the check-in processes during thetrip, and ending when the traveler checks out at thelast stop. This sequence of steps is a single long-run-ning conversation. A unit of business is performedunder the TPA by instantiating the TPA as a long-run-ning conversation. To perform many units of bus-iness, the TPA may be instantiated as many long-run-ning conversations (serially or concurrently) as isappropriate to the application and the processing ca-pabilities of the parties’ systems.

Figure 2 shows the main information content andfunction provided by the TPA. We now give a briefoverview of these functions. The next section de-scribes the actual TPA language.

Overall properties of the TPA include its name, part-ner names, starting and ending dates, and similarglobal parameters. Definitions of roles are also pro-vided. Communication and security properties in-clude communication protocol (e.g., HyperTextTransfer Protocol, or HTTP, and Simple Mail Trans-fer Protocol, or SMTP), communication addresses, au-thentication and nonrepudiation protocols, and cer-tificate parameters.

For each party that can act as a server, there is anaction menu listing the actions that the other partycan request and defining various characteristics ofthose actions. Sequencing rules specify the order inwhich actions can be requested on each server. Er-ror handling rules are various conditions related toerror conditions, such as the maximum waiting timefor the response to a request.

Today’s informal trading-partner agreements ofteninclude terms and conditions related to the appli-cation protocol. For example, a procurement TPAmight include price lists and requirements on deliv-ery time. In contrast, at this time, tpaML is concernedonly with the protocols for the message exchangesbetween the partners in performing the applicationprotocol. Higher-level issues (i.e., matters relatingto the content of the message payloads) are the re-sponsibility of the application program or higher-level application framework, or both.

Business-to-business TPA language

The TPA is an XML document from which code is gen-erated or customized at each of the trading partners’computer systems. Authoring and code generationor customization tools are provided, as will be de-scribed later. The TPA document is described by anXML document type definition (DTD) or XML-Schemadocument, which defines the tree structure of theTPA tags and XML syntactic rules. Some rules defin-ing specific values of the tags or the semantic inter-relations among the tags can be defined in the DTD,and more can be defined using XML Schema. How-ever, some TPA semantics defined in the tpaML spec-ification cannot be defined in the DTD or XML Sche-ma; these semantics are understood by the authoringtool, which uses them to aid in the creation of a valid

Figure 2 Key elements of TPA

OVERALL PROPERTIES

ROLE

IDENTIFICATION

COMMUNICATION PROPERTIES

SECURITY PROPERTIES

ACTIONS

SEQUENCING RULES

ERROR HANDLING


TPA. In this section, the term “framework” is usedto represent the generic run-time code (such as BPF)that supports the TPA and the interactions betweenbusiness partners.

Overall structure. The overall XML structure of theTPA is as follows. Each of these tags is the top levelof a subtree of tags (subelements). We illustrate thefollowing discussion with snippets of XML.

,TPA.

,TPAInfo. ,!-- TPA preamble --.

... ,!--TPAname, role definitions,participants, etc.--.

,/TPAInfo.

,Transport.

... ,!--communication and transportsecurity information--.

,/Transport.

,DocExchange.

... ,!--document-exchange andmessage security information--.

,/DocExchange.

,BusinessProtocol.

,ServiceInterface. ,!-- for eachprovider--.

... ,!--Action definitionsetc.--.

,/ServiceInterface.

,/Business Protocol.

,/TPA.

Layer structure of TPA. The ,BusinessProtocol.,,DocExchange., and ,Transport. sections above de-scribe the processing of a unit of business (conversa-tion). These sections form a layered structure some-what analogous to a layered communication model.

Business protocol layer. The business protocol layerdefines the heart of the business agreement betweenthe trading partners: the services (actions) that par-ties to the TPA can request of each other and sequenc-ing rules that determine the order of requests. Thebusiness protocol layer of BPF is the interface be-tween the TPA-defined actions and the business ap-plication functions that actually perform the actions.

Document exchange layer. The document exchangelayer defines various general properties of the doc-uments exchanged by the parties. The document ex-change layer of BPF accepts a business documentfrom the business protocol layer, optionally encryptsit, optionally adds a digital signature for nonrepu-diation, and passes it to the transport layer for trans-

mission to the other party. The reverse process takesplace for received messages.

Transport layer. The transport layer defines the com-munication protocol. Transport security (encryptionand authentication) definitions are also included.The transport layer of BPF is responsible for mes-sage delivery using the selected communication andsecurity protocols.

TPA information. Overall properties of the TPA in-clude its name, partner names, starting and endingdates, and similar global parameters. The role sec-tion provides the means to define a TPA in terms ofgeneric roles such as airline and hotel and to producea specific instance of the TPA by substituting specificparties for the role parameters. The identificationsection specifies the organization names of the par-ties and contact information such as e-mail and postalservice addresses. It also optionally specifies an out-side arbitrator to be used for settling disputes.

When a given TPA can be repeatedly reused for dif-ferent pairs of parties, a prototype TPA or templatecan be written in terms of role parameters rather thanspecific party names. The authoring tool can thengenerate a specific TPA by substituting party namesfor the role parameters and filling in specifics of thoseparties such as their electronic addresses. The roledefinitions are included under the ,TPAInfo. tag.Each ,RoleDefn. tag supplies a pair of role param-eters and the actual name. The ,RoleName. tag de-fines the name of each role. The ,RolePlayer. taghas a blank value in a TPA template and the nameof an actual party in a specific TPA. Following is theXML for the role definitions for a TPA between anarbitrary airline (airline) and an arbitrary hotel (ho-tel). In this example, the tags under ,Role. par-ticularize the TPA to an agreement specifically be-tween entities named Hotelco and Airlineco.

,Role.

,RoleDefn. ,!--one or more--.

,RoleName.hotel,/RoleName.

,RolePlayer.Hotelco,/RolePlayer.

,/RoleDefn.

,RoleDefn.

,RoleName.airline,/RoleName.

,RolePlayer.Airlineco,/RolePlayer.

,/RoleDefn.

,/Role.

When the authoring tool replaces the role param-eters by actual party names, it either asks the author


for party-specific information or finds this informa-tion in a previously built database.

Transport layer. In the transport layer, the commu-nication properties section (,Communication. tag)defines the details of the system-to-system commu-nication used in the application. These details includethe protocol to be used by both parties (e.g., HTTPand SMTP), each party’s address parameters, max-imum allowed network delay, and other parameters.Following is an example of the communication def-inition for HTTP:

,Communication.

,HTTP.

,Version.version,/Version.

,HTTPNode. ,!--One for each party--.

,OrgName Partyname5name/.

,HTTPAddress.

,LogOnURL.url,/LogOnURL.

,RequestURL.url,/RequestURL.

,ResponseURL.url,/ResponseURL.

,/HTTPAddress.

,/HTTPNode.

,NetworkDelay.time,/NetworkDelay.

,!--Optional--.

,/HTTP.

,/Communication.

The transport-security properties tags (not shown)define the security protocols to be used in transport-ing messages. Protocols are defined for encryptionand authentication. Encryption information includesthe name of the encryption protocol and various pa-rameters defining the certificates. Information sup-plied for authentication includes the type of authen-tication (e.g., password or certificate), the specificprotocol (e.g., Secure Sockets Layer, or SSL), and thecertificate parameters.

Document exchange layer. Information included inthe document exchange layer includes the message-encoding choice (example: BASE64), whether or notduplicate messages should be detected, and the mes-sage-security definition. Message security may be ei-ther or both of digital-envelope (symmetric encryp-tion using certificate-based encryption to exchangethe shared secret key) and certificate-based nonre-pudiation. Any document formats agreed to by thetwo parties may be used. We discuss the action def-inition in a later subsection.

Delivery channels. A delivery channel consists of onetransport definition and one document exchange def-inition. It corresponds to a single communication and

document-processing path. The TPA may includemore than one transport definition and more thanone document exchange definition. These definitionscan be grouped into delivery channels with differentcharacteristics. Each action definition may specify aparticular delivery channel, thus allowing the bus-iness partners to specify a different path for each mes-sage if necessary. The definition of delivery chan-nels also permits the TPA to specify that theframework may dynamically choose a delivery chan-nel for each message based on conditions such aspath congestion and failures.

Business protocol layer. The ,BusinessProtocol.

tag defines the section of the TPA that contains allthe business protocol definitions that support thebusiness application. Under ,BusinessProtocol. isthe service interface definition for each party. Eachservice interface contains some overall parametersand the action menu, which contains the set of def-initions of the actions that this party will accept asservice requests. The syntax is:

,BusinessProtocol.

,ServiceInterface. ,!--one or two--.

... ,!-- action menu and otherdefinitions--.

,/ServiceInterface.

,/BusinessProtocol.

Action definition. For each party to the TPA, an ac-tion menu identifies the permissible action requestsand their characteristics. We discuss the main ele-ments of an action definition using the following OBIbuyer action definition (see section on applicationexamples).

,Action.

,Request.

,RequestName.processOBIPOR,/RequestName.

,RequestMessage.OBIPOR,/RequestMessage.

,!--OBIPOR is a keyword whichspecifies the format of the message,in this case a purchase order request

from seller to buyer--.

,/Request.

,Response.

,ResponseName.handleOBIPO,/ResponseName.

,/Response.

,ResponseServiceTime.

,ServiceTime.3600,/ServiceTime.

,!-- 1-hour maximum time --.

,/ResponseServiceTime.

,/Action.


The request name is processOBIPOR, i.e., the actiontransmits a purchase-order request to the OBI buyer.The ,Response. tag indicates that the response isby means of a message from the OBI seller server tothe OBI buyer server and that the response causesthe handleOBIPO action to be invoked at the issuerof the request (here, the OBI seller server). The re-sponse transmits a completed purchase order(OBIPO). The ,ResponseName. tag identifies an ac-tion at the other party that will process the responsemessage. The ,ResponseServiceTime. tag specifiesthe worst case service time for the server (in this onecase, the OBI seller server) until the response is re-turned. Here, it is 3600 seconds, i.e., one hour. Ifthe specified time is exceeded, it is up to the request-er’s application logic to decide what to do next. Notshown here is the definition of the handleOBIPO ac-tion in the seller’s service interface.

The value of the ,RequestMessage. tag defines theformat of the business document sent in the mes-sage. For XML documents, the value may be the uni-form resource locator (URL) of the document typedefinition document or XML-Schema document thatdefines the document format. Alternatively, the valuemight be a keyword that could represent an entry ina local (at each business partner) dictionary that de-fines the agreed-to format. Both tpaML and BPF can,by means of plug-in parsers and document gener-ators, support any document format, standardizedor not, agreed upon by the partners. With the ap-propriate plug-ins, even traditional EDI messages canbe supported. In future applications, it is expectedthat XML will be the language of choice for struc-turing documents. However, other formats, such asthe current EDI formats, must also be supported to-day.

Sequencing rules are used to specify the permissibleorder of action invocations on a given server. Thepermissible initial action or actions is specified as fol-lows, specified under the ,ServiceInterface. tag.

,StartEnabled.

,RequestName.action_name,/RequestName.

,!--one for each action permittedas the initial action--.

,/StartEnabled.

There is one ,StartEnabled. tag for each party thatcan act as a server. Only one of the actions whosenames are specified under ,StartEnabled. may beinvoked as the first action in a given conversationon that server.

Within each action definition, a sequencing rule spec-ifies which actions can no longer be invoked follow-ing the completion of the particular action, and whichactions become permissible following the particularaction. The specification is as follows:

,Sequencing.

,Enable. ,!--actions permitted afterthis one--.

,RequestName.name_of_action,/RequestName.

...,/Enable.

,Disable. ,!--actions not permittedafter this one--.

,RequestName.name_of_action,/RequestName.

...,/Disable.

,/Sequencing.

The ,Enable. tag specifies which actions are per-missible following the action whose definition con-tains the ,Sequencing. tag. The ,Disable. tag spec-ifies which actions are no longer permitted after thisaction.

Many error conditions are handled in standard waysby the framework, and their handling is not spec-ified in the TPA. For example, the framework auto-matically retries for failures to receive transport-levelacknowledgments. Some errors, such as sequencingerrors, may be severe enough for the parties to con-tact an arbitrator to determine whether a TPA vio-lation occurred. A tag in the ,TPAInfo. section iden-tifies the arbitrator. Duplicate messages are mostlikely to arise during recovery, when incomplete ac-tions are retried. The TPA can specify that the du-plicate can be ignored if the recipient recognizes aduplicate message. If the duplicate is a request mes-sage, the server can then resend the response mes-sage.

Business-to-business protocol framework

BPF is a general mechanism to support various bus-iness protocols and business-to-business processes,both custom-designed and existing protocols such asOBI. Dan et al.7 describe a prototype of such a mech-anism that was developed in a research project atIBM Research. In the BPF architecture, each businessprotocol is supported by creating a personality forit, based on the specification in a TPA. We describethe use of the TPA with OBI later in this paper. Manybusiness-to-business processes, such as request for


quote (RFQ), request for information (RFI), and otherprocesses, are similar to the OBI flow and can be im-plemented by the same framework. These other pro-cesses will be implemented largely by changing theTPA. Tie-in to back-end systems is provided by in-voking an extensibility framework from the “busi-ness logic interface” that is triggered by incomingrequests, such as partial or completed purchase or-ders in the case of OBI.

BPF provides the following functions, among others:TPA installation, routing of messages to the speci-fied action at the destination, sequencing rules, bus-iness document generation and parsing, security, cor-relation of conversations, logging, and recovery.

It should be understood that if two partners haveagreed on a TPA specifying how they will interact,they are still free to choose how to provide the im-plementation of the business protocol. A BPF can beused to generate the implementation. The partnerscould have different BPF frameworks supporting theTPA standard or could deploy any business protocolimplementation consistent with the TPA specifica-tion. This independence is essential for doing bus-iness over an open medium such as the Internet. Oneshould not dictate to others which technology to useto send and receive messages. BPF is an open andextensible framework in which various functions de-fined in the TPA can be supported by plug-ins. Ex-amples of functions conveniently provided by plug-ins are document parsers and generators and securityfunctions. Therefore, BPF is ideal for setting uploosely coupled trading agreements in which, for ex-ample, a business is free to replace suppliers by oth-ers without having to make a large IT investment tosupport the new supplier. As long as the businessprotocol, and hence the TPA, does not fundamen-tally change, replacing business partners by othersis practical.

BPF architecture. Figure 3 illustrates the role of BPFas the gateway, coordinator, and control point ofchoice between intrabusiness and interbusiness pro-cesses. It is positioned between the buy and sell com-ponent of a local business, the remote businesses,and the back-end systems. The applications spanningmultiple businesses (e.g., procurement and supplychain management) are numerous and can be builtusing this framework.

Figure 4 depicts the generality of BPF for differentkinds of business protocols. With OBI as an exam-ple, the middle node in the figure could be a bus-

iness sell-side OBI server, with requests coming fromthe requisitioner (top left). The server on the left ofthe figure would then be the OBI buy-side server, andthe server on the top right would be the paymentgateway. The local business process at the sell-sidenode (middle) could be the fulfillment process, whichis invoked using the BPF framework. As another ex-ample, the figure could be the case of an RFQ pro-cess in which the buyer (node at the lower left) couldsubmit an RFQ request to the seller or supplier (mid-dle node). The seller would invoke its local businessprocess to determine whether to respond to the RFQ;this may, in turn, involve requests to remote suppli-ers (on the right), which would be done using BPF.The seller could then send a response to the RFQ tothe buyer. The buyer, in turn, could select from theresponses received and send a purchase order to theselected seller.

A version of BPF is built on top of an Enterprise Java-Beans (EJB) server and employs a diverse set of tech-nologies for providing various functions and services.Although IBM WebSphere* can be used as the EJBserver, there is no specific dependency on Web-Sphere. A business may communicate with its part-ners using one of the several protocols such as HTTP,SMTP, and IBM MQSeries*. It may even use differ-ent protocols for different sets of actions on a per-TPAbasis. Security technologies include transport secur-ity (SSL), authentication using digital certificates, aswell as digital signatures for nonrepudiation (usingMD5, SHA-1). Various data formats include EDI,XML-EDI, or other XML formats. Appropriate mes-sage parsers or message generators are provided forconverting these documents into an internal format.Independent software components providing manyof these technologies can be plugged in to the BPFframework via a vendor-neutral open applicationprogramming interface (API), thus allowing imple-menters to customize solutions of their choice.

BPF provides many different services to the businessapplications running on this platform. In additionto the basic TPA service, BPF provides services suchas time-stamped logging, recovery services, public-private key cryptography, reliable document ex-change, and document repository.

Layering. The functionality provided by BPF is lay-ered, as shown in Figure 5, in order to provide dif-ferent levels of abstraction for the business data flow.Furthermore, the layering, along with well-definedinterlayer APIs, minimizes the spread of specializedcode across the framework. The business data flow


through the layers is driven by the TPA that governsthat particular protocol.

The lowest level of the BPF stack is the transport layer,which contains protocol-specific modules that allowthe business processes to communicate with the ex-ternal world using any of the supported communi-cation protocols, including communication-relatedsecurity such as authentication and encryption. Thetransport layer interfaces with the document ex-change layer, which supports the abstraction of a bus-iness document (e.g., EDI document). The documentexchange layer provides common document-relatedfunctionality such as message data mapping, non-repudiation, time-stamping, logging, and audit trail.The document exchange layer interfaces with the

business protocol layer that provides document-typeand trading-partner-specific data-handling function-ality based on the business protocol section of theTPA. The business protocol layer in turn provides thebusiness logic interface that connects to the specificbusiness application that may implement the highest-level business logic or serve as a bridge to back-endbusiness processes such as enterprise resource plan-ning, or both. It is the business logic that processesthe payloads of the messages exchanged under theTPA. This processing is not governed by the speci-fications in the TPA but is the responsibility of theapplication design.

BPF components and flow. The components of BPFare shown schematically in Figure 6. The BPF func-

Figure 3 BPF as business-to-business coordinator

BUSINESS3

COMMUNICATIONS

ECSUITE

BACK-ENDSYSTEMS

BACK-ENDSYSTEMS

SELLING

BPFBPF

BUSINESS2

BUSINESS4

BUYING

BUSINESS 1


tions can be broadly categorized as those related tosetting up the BPF environment and those related torun-time operations for business-to-business inter-actions. Above the horizontal line in the figure arethe various helpers and tools; these will be discussedbelow. The tools cause information to be placed inthe registration database for use during run time bythe BPF manager. Below the line are the run-timefunctions, managed by the BPF manager, which alsoencompasses recovery management. In the middleof the section below the line are the major compo-nents of message flow. From left to right, messagesarrive from the network into the transport function.From there, each document is passed through thefunctions that implement the rest of the functionallayers, described previously. The business logic in-terface provides the interface to the business appli-cation that implements the business logic and toback-end processes such as enterprise resource plan-ning. Finally, the run-time services are indicated atthe bottom.

To support recovery and audit, all requests and re-plies (i.e., inbound and outbound messages) are time-stamped and logged. The information to be logged

Figure 5 BPF functional layers

DOCUMENT EXCHANGELAYER

BUSINESS LOGIC

TPA

BUSINESS PROTOCOLLAYER

TRANSPORT LAYER

Figure 4 General process flow for BPF

LOCAL BUSINESSPROCESS

TPA

TPA

TPA

OBI BUYER OBI SELLERSELLER-SUPPLIER

SERVICE PROVIDERAGENCY

MERCHANTCONSOLIDATOR ...

PAYMENT GATEWAYREMOTE SUPPLIERSUBCONTRACTORSERVICE PROVIDERPAYMENT...


includes the document received, request time, doc-ument sent, reply time, owner of the document, in-ternal service to be invoked, etc. The informationcould be used later for audit trail purposes and forrecovering the state of a BPF server. The state of theTPA instance is recorded in an underlying persistencemedium. On startup and after restart following a fail-ure, recovery services are invoked to recreate thestate of the TPA instance and associated BPF conver-sations. All incoming messages are analyzed, check-ing for duplicate copies as well as for allowable se-quences specified in the TPA. If the message isacceptable, it is enqueued for handling asynchro-nously.

When BPF is deployed with IBM WebSphere Com-merce Suite (WCS), the components of BPF work withWCS in order to provide functions such as commu-nications (e.g., HTTP), user directory and access con-trol, logging and error reporting, various application

commands, and back-end system functions such asthe connection to SAP**.

TPA authoring and code generation

In order to utilize an electronic TPA, the TPA mustfirst be composed and agreed to by the participatingparties. Because the TPA is a complex document, anda new TPA is needed to do business with each newtrading partner, an authoring tool that understandsTPA semantics and assists the author in providing thecorrect information is essential in preparing a TPA.

Once the TPA is verified as valid and agreed to byboth parties, it is passed to the TPA registration toolat each party’s site. This tool extracts some of thecontent and stores the content in the registration da-tabase. The business-logic registration tool is usedto associate actions that were specified in the TPAwith business functions of each business partner, so

Figure 6 Business setup and operations components

NETWORK

BUSINESS SETUP

HELPERS

• PARSERS• DOCUMENT GENERATORS• SECURITY HANDLERS• ENCODERS

• TPA REGISTRATION• MAPPING INFORMATION• CODE GENERATION• RUN-TIME INFORMATION

• BUSINESS LOGIC REGISTRATION• HELPER REGISTRATION

TPA

BUSINESSLOGIC

• REGISTRATIONDB

BUSINESS OPERATIONS

• DOCUMENTREPOSITORY

• LOGGING• QUERY SERVICES

BUSINESSPROTOCOL

TRANSPORT DOCUMENTEXCHANGE

BUSINESSLOGICINTERFACE

BUSINESSAPPLICATIONS

RUN-TIME SERVICES

REGISTRATION TOOLS

TPA AUTHORINGTOOL

BPF MANAGER

RECOVERY MANAGEMENT


that when an action is requested of a partner, thecorrect sequence of business functions is called.

There are many possible designs for the tools. Thedesign choices for the code generator and registra-tion tool, in particular, depend on the specifics ofthe system in which they work. There can be no re-quirement that both parties to the TPA use the samecode generator and registration tool. We here de-scribe the tools we developed as part of a project inIBM Research.7 In our project, these tools are im-plemented in the Java** programming language.

The code-generation tool uses specification infor-mation from the TPA and the registration databaseto generate the TPA objects that are needed for eachTPA to interface with the application. The tool mayproduce specific code for each TPA, or it may pro-duce the information needed to customize a genericTPA object.

Authoring tool. TPA authoring tools play an impor-tant role in preparing TPAs. A TPA authoring tool un-derstands TPA semantics. It guides the author in theprocess of creating a TPA. It validates the informa-tion that the author enters to create each tag in theTPA.

A TPA contains information about the agreed-uponinteraction protocol (e.g., messages and allowablesequences) as well as the details of the interactingpartners (e.g., contact information, URLs, and cer-tificate parameters). In order to guide the creationof a TPA, the authoring tool captures the tpaML rulesfor creating TPAs in the form of models of individualtags and of the TPA as a whole.

The models contain this semantic information in aform that can later be used to construct a TPA. Amodel contains information that describes the de-tails that the author must provide at each point inthe TPA. For example, a model for HTTP indicatesthat URLs must be supplied as communication ad-dresses. A model may also contain information froma specific TPA (e.g., specific URLs). A model basedon information from a specific TPA can be used tocreate a similar new TPA such as a TPA between adifferent pair of partners. The authoring tool usesthe information in the model to guide a user in cre-ating a correct TPA. Thus, the authoring tool pro-vides a way for an expert to prepare a model fromwhich someone can construct a TPA with far lessknowledge of the required semantics.

A model of a TPA consists of a collection of modelsof the tags to be used in the TPA. The models arein a tree structure that corresponds to the tree struc-ture of the tags in the TPA. Each model of a tag isan example of the subtree under the tag. For exam-ple, a tag representing a communications protocolsection has, as its subtree, information specific to aparticular protocol. A model of a tag can be simple,or it can contain multiple submodels for a particulartag. For example, a general model for the ,Commu-nication. tag contains a submodel for each of thesupported communications protocols.

In many instances, a business partner (e.g., a sellerorganization) may use a standard application pro-tocol (e.g., procurement protocols such as OBI,Ariba** cXML, and Metiom**) for interacting withmany different partners. Authoring a new TPA basedon a standard protocol requires only that the partner-specific information and certain choices (e.g., server-to-server versus server-browser-server in OBI) be up-dated. The TPA authoring tool can create a modelfrom a sample TPA or a TPA template and can usethis model to guide a user to create a TPA based onthe sample.

The authoring tool starts with a document type def-inition or XML-Schema document, which providesthe syntactic structure of the TPA. Then it constructsa model of a general TPA by asking the model makerto provide examples (semantics) of all parts of theTPA. Once a model is complete, it is available to anyauthor who, by answering a few specific questions,can create a very complex TPA with a high proba-bility of success. Figure 7 illustrates the process ofcreating a model and a TPA.

The TPA author starts the authoring procedure af-ter a model has been loaded. The authoring tool nowuses the model to drive the authoring procedure andguide the author in making choices and entering in-formation. Starting with the root of the model, theauthoring tool examines the choices for models be-neath the root. If there is no choice to be made, theauthoring tool accepts the model, proceeds to thenext level, and repeats the above procedure for eachchild. If choices are to be made, a panel is displayedasking the user to select the correct model or fill inthe needed information. The authoring tool thencontinues with that choice.

Code generation or customization. The code gen-erator or customizer transforms the TPA into reg-istration information and code that enforces the rules


of interaction. A TPA object is created at the site ofeach party to the TPA. Generation of specific codefrom a TPA is illustrated in Figure 8. Generation ofspecific code starts from a set of templates that con-sist of a combination of native (Java or any other)language and macro-style directives. These directivesare written in a macro language consisting of infor-mation such as a basic set of data types, a basic set

of functions used to obtain information from the TPAand other external sources, declaration statements,assignment statements, and conditional statementsthat change the execution flow, depending upon val-ues of variables and functions.

A macro processor scans the template looking fordirectives. It executes any directives it encounters andhandles any native language statements as charac-ter strings, performing any needed processing, andwriting the processed statements to a file.

The code customization approach starts with a ge-neric TPA object. The registration tool then gener-ates a TPA instance object that contains all the char-acteristics of each action along with all other run-time information from the TPA. At run time, thegeneric TPA object is used in conjunction with theTPA instance object, resulting in the behavior thatsupports the specific TPA.

Application examples

IBM WebSphere Commerce Suite, or WCS (former-ly known as IBM Net.Commerce*), is a business ap-plication product for merchants to build on-linestores on the Internet. Many such stores are for con-sumer shopping. However, a growing market seg-ment is the support of business buyers, as well as thesupport of business-to-business electronic transac-tions between the merchants and their business part-

Figure 7 Creating a model

CREATING A TPACREATING A MODEL

TPADTD

NEWMODEL

EXISTINGMODEL

TPADOCUMENT

EXPORTEDMODEL

IMPORTEDMODEL

AUTHORINGTOOL

NEW TPADOCUMENT

AUTHORINGTOOL

Figure 8 Code generation

INFORMATIONFILE

OTHERSOURCES

TPADOCUMENT

REGISTRATIONINFORMATION

MACROPROCESSOR

TEMPLATE OUTPUT


ners. Figure 9 illustrates some basic scenarios of amerchant WCS system dealing with its business part-ners. These scenarios are:

A. WCS merchants supporting business buyers, e.g.,creating purchase order requests

B. WCS merchants dealing with their suppliers, e.g.,checking for inventory

C. WCS dealing with their business buyer systems,e.g., requesting approval of purchase order re-quests

WCS in conjunction with IBM Commerce Integrator,Seller Edition (CISE) facilitates the support of thesebusiness scenarios when possible through the adop-tion of both open (e.g., OBI) and de facto (e.g., Ariba)business-to-business “standards.” For example,WCS/CISE supports the OBI standard (Open Buyingon the Internet), thus allowing any OBI-compliantbusiness buyers to place purchase order requests withan OBI-enabled merchant and interacting to respondcorrectly to the approval process of the buying or-ganization (i.e., scenarios A and C). Other examplesof business protocols are cXML (supported by Ariba),Metiom (formerly known as Intelisys), and MySAP**(supported by SAP). A merchant chooses the bus-iness protocol to be used with a business buyer part-ner and then installs the specific CISE connector tech-

nology required by the customer. Electronic TPA andBPF technologies were used as a base to develop thetooling and run time for the CISE OBI support an-nounced in September 2000.

The following subsections describe in more detailthe OBI business protocol, which is supported inWCS/CISE, and an OBI-like on-line procurement ap-plication of WCS.

Open Buying on the Internet. We now describe anexample of the TPA and server structure for an ex-isting public protocol, OBI.

Open Buying on the Internet (OBI),3 is a protocolfor business-to-business Internet commerce. It wasdesigned by the Internet Purchasing Roundtable andis supported by the OBI Consortium. OBI defines theprocedures for the high-volume, low-dollar purchas-ing transactions that make up most of the purchas-ing activity of an organization. Here we present OBI,how it can be described by a TPA, and a schematicview of a possible implementation.

Figure 10 illustrates the participants in an OBI trans-action and the basic information flows. The requi-sitioner is a member of the buyer organization (e.g.,an employee of a company) and is permitted to place

Figure 9 WebSphere Commerce Suite and Commerce Integrator, Seller Edition

MERCHANTBUSINESS BUYERS

WCS

LEGACYBACK END

BUSINESS BUYERS SERVERS

A

INTERNET

INTERNET

INTERNET/VAN EDI. ..

INTERNET/VAN EDI. ..

C

SUPPLIERS

BCISE


orders directly with the merchant server of the sellerorganization. The requisitioner can browse a cata-log and place an order with the seller organizationby means of a browser. When the requisitioner hasplaced an order, the server of the seller organiza-tion sends a partial purchase order (purchase orderrequest) to the server of the buyer organization. Thebuyer organization validates the purchase order re-quest and transforms it into a complete purchase or-der that it returns to the seller organization. Theseller organization then prepares an invoice or oth-erwise arranges for payment and ships the orderedmerchandise. The payment process handles elec-tronic payments. Using the browser, the requisitionercan also view and update information at the buyerorganization server such as the requisitioner’s pro-file, outstanding requests, etc. The requisitioner canalso check the status of an order at the seller orga-nization.

An additional possibility is to have the buyer orga-nization send an “unsolicited” purchase order to the

selling organization without a prior request and par-tial purchase order initiated by a requisitioner. Thismode might be used, for example, when a purchas-ing department buys large volumes to supply a stockroom.

As shown in Figure 10, there is a TPA between thebusiness-to-business servers of the buyer organiza-tion and the seller organization. The payment pro-cess is outside the scope of the two-party TPA be-tween buyer organization and seller organization. Itis a back-end process of the seller organization.

Following are the main functions included in theOBI TPA:

● Organization names of the parties to the TPA● Communication protocol definition, which in this

case is HTTP and includes the specific URLs of thebuyer and seller

● Security information such as the protocol (SSL inthis case) and various certificate parameters

Figure 10 Open buying on the Internet

WEBSERVER

BUYER ORGANIZATION SELLER ORGANIZATION

OBI SERVER

REQUISITIONER

PAYMENT PROCESS (SET)

FULFILLMENTPROCESS

OBISERVER

SHOP IN CATALOGMERCHANTSERVER

VALIDATION

APPROVALPROCESS TPA

COMPLETE PURCHASE ORDER

PARTIAL PURCHASE ORDER


● Action menus for the buyer and the seller. The ac-tion list for the buyer is illustrated in the earliersubsection entitled “Action definition.” It consistsof one action, “Process OBI Purchase Order Re-quest.” The completed purchase order is returnedto the seller by means of an action request to theseller organization, “Handle OBI Purchase Order.”The buyer organization may also use the “HandleOBI Purchase Order” action to submit an unsolic-ited purchase order to the seller organization.

Figure 11 depicts the basic system structure and flowof an implementation of OBI based on BPF. Shownin the figure are the TPA objects generated from theTPA at the buyer and seller servers. These objectsprovide the interfaces between various processescontrolled by the TPA (in particular, the action re-quests) and the application logic at each server.

The process starts when a requisitioner contacts (1)the buyer server via a browser and is redirected (2)to the URL for the seller’s catalog and purchasingfunctions. The requisitioner is shown the suppliercatalog appropriate to the requisitioner’s organiza-tion. When the requisitioner makes a selection, therequest is communicated to the TPA object. The TPAobject communicates the purchase request to the lo-cal business processes via one of the gateways seenat the far right in the figure. A partial purchase or-der is returned to the TPA object via the gateway.The TPA object then issues the processOBIPOR ac-tion request (3) to the buyer server, sending a par-tial purchase order to the buyer server.

This request arrives at the buyer’s TPA object, whichevaluates the rules defined in the TPA and then sendsthe partial purchase order to the buyer application

Figure 11 OBI implementation

SELLER ORGANIZATION

(3) PARTIAL PURCHASE

ORDER

(5) COMPLETED PURCHASE

ORDER

(1) LOG IN

BUYER

SELLER

REQUESTPURCHASE ORDER

PARTIALPURCHASE ORDER

COMPLETEDPURCHASE ORDER

LOCAL PROCESSES

(2) REDIRECTED TO PREFERRED SUPPLIER CATALOG

PARTIALPURCHASE ORDER

(4A) CONFIRM (4) REQUESTAPPROVAL

CATALOG AND PURCHASING FUNCTIONS

REQUISITIONER

COMPLETEDPURCHASE ORDER

APPLICATIONLOGIC

GATEWAY LOCALPROCESSES

GATEWAY

GATEWAY

TPAOBJECT

TPAOBJECT

BUSINES-TO-BUSINESSMANAGER

BUSINESS-TO-BUSINESSMANAGER


logic. In processing the partial purchase order, theapplication logic communicates with local businessprocesses, via the gateway shown at the lower leftin the figure, to request approval (4) of the purchaseorder. If the purchase is approved (4A), the approvalarrives at the application logic, which completes thepurchase order and passes the completed purchaseorder to the buyer’s TPA object. The TPA object thenissues the handleOBIPO action request (5), sendingthe completed purchase order back to the seller.

The completed purchase order arrives at the sell-er’s TPA object, which passes it to the local processesvia the gateway at the lower right. The local processeshandle fulfillment (e.g., shipping) and invoicing andpayment. They also initiate a confirmation messageto be returned to the requisitioner via the browser(not shown in the figure).

IBM-customer pilot on on-line procurement. IBMand a large bank collaborated on a pilot of on-lineprocurement. The bank wanted to reduce its pro-curement costs by automating direct purchases ofIBM computers by its employees. Bank employeescan use this system to purchase IBM personal com-puters and accessories directly from the IBM PersonalSystems Group (PSG).

The selling organization (IBM PSG) system was basedon BPF alpha code and WebSphere Commerce Suite.It maintained the catalog of products and prices foruse by the purchasing organization (the bank). TheIBM platform consisted of an IBM Netfinity* serverrunning the Microsoft Windows NT** Server oper-ating system, IBM WebSphere Application ServerAdvanced Edition Version 3, the IBM HTTP ServerWeb server, and IBM Universal Data Base.

The procurement system of the bank was based onthe Metiom Enterprise Purchasing System**. TheMetiom system provided services for creating, ap-proving, tracking, and modifying purchase orders.It provided a single point of access, with a single sign-on, to all supplier catalogs used by the bank. IBM pro-vided a personal-computer catalog. Bank employ-ees could browse this catalog and then place orders.

The message exchange protocol between the buyerand seller systems is a private protocol designed byMetiom, which is based on OBI, and is enhanced forthis application with the addition of order-acknowl-edgment and invoice messages. A TPA was writtento describe the process and used to configure BPF atthe IBM PSG server.

Figure 12 shows the main components and messageflows. The IBM PSG server consists of BPF and WCS.Following are the blocks in the BPF part of the server.Supplier Business Logic is the procurement appli-cation. The OBI business-to-business protocol blockis the TPA object. The OBI messaging block is the doc-ument-exchange layer of BPF. The HTTP/HTTPS blockis the BPF transport layer. The IEC-Link** is Metiom’sEnterprise Commerce Link**, which is a mailboxcommunication system. A poll message is passed tothe IEC link, which polls the mailboxes for messagesand returns them to the procurement system. Theuse of the IEC link in this application will be discussedbelow.

The employee (requisitioner) who wants to purchasea personal computer contacts the bank purchasingsystem using a browser. The purchasing system pre-sents the employee with a list of suppliers that areapproved by the bank. The employee selects IBM PSG.The purchasing system then logs onto the IBM PSGsystem (1) via BPF. BPF in turn contacts the catalogsystem in WCS (2), which returns the URL for theIBM PSG catalog appropriate for this bank (3). TheURL is passed to the requisitioner’s browser (4).

The requisitioner is now enabled to shop (5, 6) andfill a shopping cart. The WCS server creates an or-der, based on the shopping cart, and passes it to theseller server (7), which generates a purchase orderrequest as an OBI Purchase Order Request messageand returns it to the buyer server (8). An approvalprocess now occurs at the bank system, which mayinvolve a human approver at a browser (9). Whenthe approval process is completed, the bank serverissues a purchase order (10) to the IBM PSG server,which responds with an HTTP acknowledgment (11).The purchase order is passed to the order fulfillmentand payment subsystem (12), and the purchase isshipped directly to the requisitioner. The bank sys-tem then polls the IBM PSG system for messages (13)and receives an EDI 855 order-confirmation message(14).

We have demonstrated end-to-end operation of thepilot. At the time this paper was written, the pilotwas ready to be put into service by the bank for ac-tual purchases by employees.

This example shows that a practical e-commerce ap-plication will often have localized but significant dif-ferences from the documented standard. In this ex-ample, the Metiom system requires the use of a useridentifier and password for authentication instead


of certificate authentication, probably because it iseasier to administer than client certificates. It alsorequires the use of a server-browser-server protocolin which response messages from the selling orga-nization are returned to the buying organization viathe requisitioner’s browser in order to support thefirewall of the bank. Further, the Metiom system re-quires the use of the EDI 855 order-confirmation mes-sage, which is not part of the OBI standard. The flex-ibility in tpaML, combined with the TPA authoringtool and its tag models, exactly meets the need foreasy local tailoring of the protocol and specific part-ner addressing information defined by a standardprotocol.

Summary, conclusions, and future work

A large number of business-to-business interactionprotocols have emerged in recent years for automat-ing various e-commerce processes, such as OpenBuying on the Internet (OBI), cXML supported byAriba, Commerce One RoundTrip** Service, andRosettaNet Partner Interface Processes** (PIPs**).In keeping with this pace of automation, many morebusiness protocols in the form of new protocols, en-hancements to existing protocols, and even privateprotocols across a set of businesses will be used inthe future. The complexities of these protocols arealso expected to increase in order to capture many

Figure 12 On-line procurement study

REQUISITIONER BROWSERREQUISITIONER BROWSER

TPA

WEBSPHERE COMMERCE SUITE

METIOMPURCHASINGSYSTEM

APPROVER BROWSERAPPROVER BROWSER

(9) APPROVE PURCHASE ORDER

CATALOGOF GOODSAND PRICES

PURCHASEORDERREQUESTGENERATION

(1) LOG IN

(4) CATALOG URL

(5) SHOPPING

(8) OBI PURCHASE ORDER REQUEST

(13) POLL

(14) EDI 855

(11) HTTP 200 OK

(10) OBI PURCHASE ORDER

ORDERFULFILLMENTAND PAYMENT

OBI B2BPROTOCOL

SUPPLIERBUSINESSLOGIC

OBIMESSAGING

HTTP/HTTPSTRANSPORT

IEC LINK

MAILBOXES

FIREWALL FIREWALL

(2)

(3)

(6)

(7)

(12)

BPF

IBM PSG SELLING ORGANIZATION

BANK BUYING ORGANIZATION


more aspects of the real-world interactions. Imple-mentation of all such protocols from the start is time-consuming and expensive. BPF provides a compre-hensive set of tools and enablers for ease ofspecification, configuration, plug-in, and customiza-tion for setting up such business-to-business inter-actions. To use BPF, electronic TPAs, which may spec-ify either standard or custom application protocols,are created according to the tpaML specification andregistered to BPF along with the internal business pro-cesses to be invoked using these TPAs. BPF generatescode for linking and enforcing these TPAs and pro-vides many other services (e.g., conversation corre-lation, cancellation, and rule-based invocation ofmultistep logic) for writing complex business appli-cations. We have described two applications of TPAand BPF that use OBI or a variant of OBI. As e-com-merce becomes pervasive, many new applications(marketplaces, agencies, distributors, etc.) will bebuilt on this foundation.

We are extending the TPA ideas and language to ar-eas such as TPA hierarchy, linking of multiple TPAs,TPA life-cycle management, and dynamic negotiation.We are also investigating TPAs in which there aremore than two parties.

In addition, we are investigating how to incorporatebusiness constraints into the TPA. Business con-straints are conditions placed on data items in re-sponse messages. The results of these tests may mod-ify further processing within the TPA. An exampleis a test of whether a cancellation action (e.g., to can-cel a reservation) was issued during the allowed timerange after the original action.

Acknowledgments

The authors express their appreciation to the follow-ing for contributions to the design of BPF and theformulation of the TPA principles and language:Satwinder Brar, Catherine Crawford, ChristineDraper, Christopher Gibson, Vibby Gottemukkala,John Ibbotson, Richard King, George Kleon, LinhLam, Keith Mantell, Paul Norris, Stewart Palmer,Chris Sharp, and Colin Thorne. The authors alsothank Nagui Halim and Anant Jhingran for theirmanagement vision.

*Trademark or registered trademark of International BusinessMachines Corporation.

**Trademark or registered trademark of OBI Consortium, Roset-taNet Consortium, Object Management Group, Sun Microsystems,Inc., SAP AG, Ariba, Inc., Intelisys Electronic Commerce, Inc. nowMetiom, Inc., Microsoft Corporation, or Commerce One, Inc.

Cited references and note

1. XML is a “meta-language” that can be used to define anddescribe markup languages for various classes of documents.It is based on Standard Generalized Markup Language(SGML), an international standard used to define electronicdocuments.

2. Extensible Markup Language (XML), 1.0, World Wide WebConsortium (1998).

3. Open Buying on the Internet Technical Specifications, ReleaseV1.1, The Open Buying on the Internet (OBI) Consortium,http://www.openbuy.org (1998).

4. RosettaNet Specifications, RosettaNet Consortium, http://www.rosettanet.org (1999).

5. Electronic Business XML initiative established by the UnitedNations body for Trade Facilitation and Electronic Businessand the Organization for the Advancement of Structured In-formation Standards, http://www.ebxml.org (2000).

6. A. Dan and F. Parr, “An Object Implementation of NetworkCentric Business Service Applications (NCBAs),” OOPSLABusiness Object Workshop, Atlanta, GA (September 1997).

7. A. Dan, D. Dias, T. Nguyen, M. Sachs, H. Shaikh, R. King,and S. Duri, “The Coyote Project: Framework for Multi-Partye-commerce,” Proceedings of Research and Advanced Tech-nology for Digital Libraries, Second European Conference,ECDL’98, Heraklion, Greece (September 1998), Springer-Verlag, Berlin (1998), pp. 873–889.

8. A. Dan and F. Parr, “The Coyote Approach for Network Cen-tric Business Service Applications,” HPTS Workshop, Asilo-mar, CA (1997).

9. H. Weigand and A. Ngu, “Flexible Specification of Interop-erable Transactions,” Data and Knowledge Engineering 25,327–345 (1998).

10. J. Gray and A. Reuter, Transaction Processing: Concepts andTechniques, Morgan-Kaufmann, San Mateo, CA (1993).

11. T. Ajisaka, “Electronic Commerce for Software,” Proceed-ings of Research and Advanced Technology for Digital Librar-ies, Second European Conference, ECDL’98, Heraklion,Greece (September 1998), Springer-Verlag, Berlin (1998),pp. 791–800.

12. T. Sandholm, “Unenforced e-commerce Transactions,” IEEEInternet Computing 1, No. 6, 47–54 (November–December1997).

13. T. Sandholm and V. Lesser, “Issues in Automated Negoti-ation and Electronic Commerce: Extending the Contract NetFramework,” Proceedings of First International Conference onMulti Agent Systems, ICMAS 95, San Francisco, CA (June1995), AAAI Press, Menlo Park, CA (1995), pp. 328–335.

14. P. Konana, A. Gupta, and A. Whinston, “Digital ContractApproach for Consistent and Predictable Multimedia Infor-mation Delivery in Electronic Commerce,” Multimedia Com-puter and Networking 1997, San Jose, CA (February 1997),Proceedings of SPIE—International Society for Optical Engi-neering 3020 (1997), pp. 275–281.

15. A. Dan and F. Parr, “Long Running Application Models andCooperating Monitors,” HPTS Workshop, Asilomar, CA(1999).

16. The Common Object Request Broker Architecture and Spec-ification, Rev. 2.2, Object Management Group, http://www.omg.org (1998).

17. Enterprise JavaBeans Specification, ver. 1.1, http://www.javasoft.com/products/ejb (1999).

18. The Workflow Management Coalition Specification, http://www.wfmc.org (1998).


19. H. Garcia-Molina and K. Salem, “SAGAS,” Proceedings ofACM SIGMOD Conference, New York (1987), pp. 249–259.

Accepted for publication October 10, 2000.

Asit Dan IBM Research Division, Thomas J. Watson Research Cen-ter, P.O. Box 704, Yorktown Heights, New York 10598 (electronicmail: [email protected]). Dr. Dan has been with IBM Researchsince 1990 and currently manages the business-to-business inte-gration department, working on the development of infrastruc-ture for supporting business-to-business e-commerce applications.He is at the forefront in the research and development of trans-action processing architectures and video servers. He holds sev-eral top-rated patents in these areas and has received two IBMOutstanding Innovation Awards, seven Invention AchievementAwards, and the honor of Master Inventor for his work in theseareas. Dr. Dan received a Ph.D. from the University of Massa-chusetts, Amherst. His doctoral dissertation, Performance Anal-ysis of Data Sharing Environments, received an Honorable Men-tion in the 1991 ACM Doctoral Dissertation Competition andwas subsequently published by the MIT Press. He has publishedextensively, including several book chapters, and a book on mul-timedia servers.

Daniel M. Dias IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 704, Yorktown Heights, New York (elec-tronic mail: [email protected]). Dr. Dias received the B. Tech.degree from the Indian Institute of Technology, Bombay, India,and the M.S. and Ph.D. degrees from Rice University, all in elec-trical engineering. He has been with the IBM Research Centerin Yorktown Heights since 1983. He manages the Parallel Com-mercial Systems department, which currently has projects focus-ing on scalable and high-performance Internet servers, business-to-business e-commerce, and performance management. Hisrecent work includes scalable and highly available Web servers,frameworks for business-to-business e-commerce, high-perfor-mance scalable Web caches, scalable video servers, highly avail-able clustered systems, and performance analysis. Technologiesdeveloped in these projects have been used for the 2000 Olym-pics Web site and large customer sites. Some are now availableas IBM products such as Network Dispatcher, Web Cache Ac-celerator, and HACMP ES. Dr. Dias has published more than100 papers in refereed journals and conferences. He has won twobest paper awards, IBM Outstanding Innovation and Outstand-ing Technical Achievement Awards, ten Invention AchievementAwards, and Research Division Awards. He holds 18 U.S. pat-ents, with 15 additional patents pending.

Robert Kearney IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 704, Yorktown Heights, New York (elec-tronic mail: [email protected]). Dr. Kearney has been employedat IBM for 30 years, with the last 18 at the Research Center. Heis currently working in developing e-commerce frameworks. Priorto this work, he helped develop frameworks for clinical informa-tion systems, networked document retrieval and processing sys-tems, and insurance industry systems, all as partnerships betweenindustry, government organizations, and IBM Research. His ed-ucation is in mathematics, having attended the University of Mas-sachusetts, University of Wyoming, and Pennsylvania State Uni-versity.

Terry C. Lau IBM Canada Laboratory, 1150 Eglinton Avenue East,North York, Ontario, Canada M3C 1H7 (electronic mail:[email protected]). Dr. Lau is a senior system architect in the

Department of Electronic Commerce Development at the IBMCanada Laboratory. His current activity is business-to-businesse-commerce. Previously, he has been in various technical and man-agement positions in the areas of data communications, imaging,and graphical user interface application development tools. Be-fore joining IBM, he was a faculty staff member at the Universityof Hong Kong and a development manager at Northern Tele-com in data communications. Dr. Lau received a B.Sc. from theUniversity of Hong Kong and a Ph.D. in computer science fromthe University of Waterloo.

Thao N. Nguyen IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 704, Yorktown Heights, New York 10598(electronic mail: [email protected]). Dr. Nguyen received aB.S.E.E. degree from the University of New South Wales, Aus-tralia, and M.S.E.E. and Ph.D.E.E. degrees in microelectronicsfrom Stanford University. Since joining the Research Center in1983, he has worked on a broad range of research and develop-ment projects and held various technical and management po-sitions. During the first six years he performed and managed re-search in VLSI processing technologies and material, and processcharacterization. He spent the next two years in semiconductorproduct development at the IBM East Fishkill semiconductor fa-cilities, first as an executive technical assistant and later as seniorengineering manager of process integration. From 1991 to 1996he participated in the development of an advanced RISC micro-processor for RS/6000TM and then led the floorplanning and chipintegration work in a project to produce a highly successful single-chip CMOS microprocessor for S/390TM systems. His recent ac-tivities are focused on software and systems for business-to-busi-ness e-commerce. He has worked on the development of aframework for business-to-business applications and integrationas well as an OBI supplier solution package. He is currently en-gaged in an effort to develop and deploy business-to-business com-merce servers for IBM as a supplier to large enterprises and e-marketplaces. Dr. Nguyen has authored or coauthored more than40 technical papers and has been awarded several patents in sil-icon and circuit technologies. He is a recipient of several ResearchDivision Awards, a Technical Group Award, and two IBM Out-standing Technical Achievement Awards. He has served on theTechnical Program Committee of several IEEE conferences in-cluding the Symposium on VLSI Technologies and Symposiumon VLSI Circuits.

Francis N. Parr IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 704, Yorktown Heights, New York 10598(electronic mail: [email protected]). Dr. Parr is a research staffmember in the Computer Sciences department at the ResearchCenter and also responsible for the Transaction and MessagingTechnology Institute—a joint program between IBM Researchand the IBM Hursley Development Laboratory. He is currentlyengaged in research on business-to-business middleware with pre-vious interests in messaging and message brokering, object middle-ware, parallel database, and scalable transaction systems. Beforejoining IBM, Dr. Parr was a lecturer in computing at ImperialCollege of Science and Technology, London University. He re-ceived a Ph.D. in applied math from Harvard University and aB.A. in mathematics from Cambridge University.

Martin W. Sachs IBM Research Division, Thomas J. Watson Re-search Center, P.O. Box 704, Yorktown Heights, New York 10598(electronic mail: [email protected]). Dr. Sachs is a researchstaff member in the Department of Computer Sciences at the Re-search Center. His current activity is business-to-business e-com-


merce, focusing on electronic trading-partner agreements. He isleading the ebXML team that is developing the specification forthe standardized version of the IBM tpaML electronic trading-partner agreement language. Previously, he specialized in I/O in-terconnect architecture including contributions to the IBMSystem/390 fiber-optic ESCONTM I/O Architecture and the ANSIFiber Channel standard. Before joining IBM, he worked in nu-clear reactions and in computer-based nuclear data acquisitionat the Weizmann Institute of Science, Israel, and Yale Univer-sity. Dr. Sachs received an A.B. degree in physics from HarvardUniversity and M.S. and Ph.D. degrees in nuclear physics fromYale University. He is an IEEE Fellow and a member of SigmaXi, the ACM, and the American Physical Society.

Hidayatullah H. Shaikh IBM Research Division, Thomas J.Watson Research Center, P.O. Box 704, Yorktown Heights, New York10598 (electronic mail: [email protected]). Mr. Shaikh is anadvisory software engineer in the Parallel Commercial Systemsdepartment at the Research Center. His current activity is busi-ness-to-business e-commerce, focusing on defining a flexible andscalable framework for new and existing business-to-business pro-tocols. His contributions include ebXML header specification andIBM tpaML electronic trading-partner agreement language. Pre-viously, he has been involved in the architecture and design ofthe IBM Supplier Live solution for Ariba Buyer and implemen-tation of Java Transaction Services. Mr. Shaikh received an M.S.degree in computer engineering from Syracuse University.


Business-to-business integration with tpaML and a business-to-business protocol framework

Documents