Enterprise Resource Planning

ERP Journal on Ulitzer

Subscribe to ERP Journal on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ERP Journal on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


ERP Journal Authors: Progress Blog, Automic Blog, Janakiram MSV, Louis Nauges, Jason Bloomberg

Related Topics: XML Magazine, ERP Journal on Ulitzer

XML: Article

Business to Business Integration with Trading Partner Agreements

Business to Business Integration with Trading Partner Agreements

IBM recently submitted a specification for defining and implementing electronic contracts to the Organization for the Advancement of Structured Information Standards (OASIS), a vendor-neutral standards body. The specification, called tpaML (Trading Partner Agreement Markup Language), uses XML and was submitted to OASIS for standardization within its XML.org initiative. This article describes why and how electronic trading partner agreement documents in tpaML can be used for business-to-business integration.

The new economy is here and trade is being transmogrified in fundamental ways. In particular, we're no longer dependent on the physical production of goods as the primary engine of wealth and jobs. Increasingly, employment and wealth now derives from the new electronically connected world - where what we produce and consume are ideas, information and services.

In this growing shift toward e-commerce, business rules are changing. As traditional industries start to face nontraditional competition, the vertically integrated corporation - in which a single organization spans and controls an entire value chain - is becoming the exception rather than the rule.

In the new economy, market dynamics already dictate a business model that provides for the integration of different partners in a value chain. Using a variety of IT technologies, this model enables highly coordinated trading communities to operate like a "virtual enterprise."

Technologies to Support the New Economy
In the emerging Web economy, what's needed is an agile enterprise, one that can work more directly with suppliers and customers and respond more rapidly and intelligently to change. Business pressures - margin erosion, channel proliferation, rising customer expectations, time-based competition and faster product commoditization - are placing increased emphasis on how organizations operate and interoperate with other enterprises.

These profound changes in the business environment demand dynamic and flexible integration between partners in the value chain. While new technologies will be needed to enable such integration, they will need to be able to work seamlessly with existing interenterprise business processes such as EDI and leverage investments in existing enterprise application integration (see Figure 1).

IBM is currently developing new technologies designed to support precisely this type of business-to-business (B2B) integration; they constitute a key component of IBM's application framework for e-business. I'm going to discuss these technologies in this article and I'll be looking too at how they can be used with IBM's MQSeries and WebSphere middleware to build robust and flexible integration solutions. Using this approach, both traditional enterprises and Internet-focused dot-coms alike can more fully exploit the exciting business opportunities of the twenty-first century.

What Are the Requirements?
While facilities such as EDI (Electronic Data Interchange) have been successfully providing document interchange electronically between companies and their suppliers for a number of years, their high cost and inflexible structure have proved a longtime barrier to adoption by all but the very largest enterprises. While EDI will continue to evolve, utilizing pervasive networks such as the Internet to reduce costs, complementary technologies are emerging that are able to provide some of the key capabilities necessary to enable dynamic business process integration.

The basis of these technologies is the formulation of:

  • A common language that can be employed by existing or potential trading partners to specify how they'll interact
  • An electronic contract that employs this common language in order to define and enforce the interaction protocols with which they'll do business.

    While XML-based B2B protocols such as OBI and RosettaNet are beginning to set a standard for business interactions (albeit currently fragmented), IBM has been expanding on this base through the development of flexible electronic documents termed Trading Partner Agreements (TPAs). These TPAs operate within a Business-to-Business Protocol Framework (BPF) that provides a comprehensive toolset for the specification, configuration, customization and execution of electronic contracts between business partners.

    Technologies such as XML and TPAs, coupled with advances in middleware and workflow software, provide the key building blocks needed to underpin an electronic B2B integration infrastructure. Supporting the extensible and easy-to-use TPA format with the BPF framework and middleware from IBM's MQSeries and WebSphere families enables dynamic business process integration by providing:

  • Integration of internal processes, using modifiable "business rules" to route information between the various internal business information systems
  • Secure, reliable and auditable document interchange between organizations
  • Externalization of appropriate business functions and processes to suppliers, customers and partners
  • Use of a broad range of standard message formats, transport and business protocols and network connections with the capability to dynamically connect new trading partners
  • Easy-to-use, business-oriented single point of control for interactions across an extended or virtual enterprise
  • Extensible open interfaces with flexible connectors to link to existing applications

    Integration of Internal Processes
    The first step toward B2B integration is successful integration within the enterprise. Proven technologies for enterprise application integration include connectors for coupling to databases and ERP systems, message handling including flexible message transformation and routing, and workflow management for coordination and control of business processes. TPA documents and supporting BPF infrastructure, coupled with the services in IBM's MQSeries middleware and WebSphere application servers, enable these integration styles to be extended to operate between businesses and across firewalls.

    Secure, Reliable and Auditable Document Interchange
    A critical concern for interactions between business partners is security, particularly across publicly accessible networks. Features such as reliable sender authentication, audit trails, and secure logging and checking for permissible messages are crucial to secure business trading. Historically, capabilities such as these have been enabled through value-added networks (VANs), often with EDI interactions. To fully exploit pervasive networks such as the Internet, it's important that these types of security features be maintained.

    Externalization of Business Functions
    When a business externalizes automated functions to make them available to business partners, several new issues must be addressed that were less important - or could be solved more simply - within a single enterprise. If the function becomes accessible via a public network, how will it be reached, who'll be allowed to use it, and how will these users identify themselves? What do both parties in the resulting long-running conversation commit to in terms of behavior, responsiveness and recovery from error situations? How can rules of interaction be specified even when the partners have no shared middleware? The TPA is structured to gather the information needed to address these issues and hence provides the basis for middleware that constructs wrappers allowing business functions to be externalized safely.

    Broad Connectivity
    Communications support that enables interaction between potential trading partners - no matter what transport protocol or network they use to connect - is a key requirement for participation in dynamic business value chains. In practice, this means that a B2B infrastructure must support:

  • A wide set of common transport protocols including HTTPS (for secure Internet interactions), SMTP (for mail interactions) and reliable messaging such as that provided by IBM's MQSeries
  • A wide range of message formats including those based on industry standards for exchanging XML documents
  • Existing and emerging B2B protocols including EDI, OBI and RosettaNet
  • Transcoding from one message format to another

    It must also be possible to merge additional libraries into the middleware base, to support any specialized message formats and protocols that may be needed for specific interactions.

    As more dynamic business chains emerge, it will become increasingly important to be able to implement new electronic trading arrangements easily and quickly. This is enabled by providing dynamic connectivity and by leveraging trading partner information in publicly accessible registries and LDAP directories to help identify and locate new potential business partners.

    "Single Point of Control" and Extensibility
    With any extended or virtual enterprise, it becomes necessary to have a consolidated, business-oriented "single point of control." This facility can help gather together templates for e-business interactions and helps accelerate the connection to new partners and the start of trading interactions with them.

    Open and Extensible Interfaces
    As dynamic business value chains evolve, the protocol interaction styles in general use will be extended and specialized to encourage increasingly sophisticated interactions between partner businesses. While each business retains specialized individual capabilities, businesses are enabled to act together as a virtual enterprise to meet the needs of specific industries and business contexts. By providing open interfaces, extensibility points and services to enable the use of XML technology in messages and interfaces, IBM's BPF provides support for these types of extension (see Figure 2). Trading Partner Agreements
    TPAs are XML-based documents used to specify the business interaction between trading partners. A TPA defines how trading partners will interact at the transport, document exchange and business protocol layers. Declarative documents, TPAs specify these roles and responsibilities as a set of attribute value pairs. The document is completed by providing specific attribute information for a particular pair of interacting trading partners.

    IBM submitted the specification of tpaML to OASIS for consideration by its XML.org initiative on Jan. 31, 2000. The full text of the proposal is available at www.xml.org/tpaml/tpaspec.pdf.

    How Are TPAs Used?
    A business uses a TPA document to define the agreed model of interaction with a specific trading partner. The TPA represents a single long-running conversation consisting of a set of related interaction steps, distributed over time but constituting a single Unit of Business (UOB) - a term that can be defined as "a set of actions grouped by the user as associated with achieving a specific business result such as a sale and fulfillment."

    Take the example of the conversation between a traveler and travel agent to arrange an itinerary. A TPA is used to define the allowable interactions - that is to say, making reservations, modifying or cancelling them, issuing tickets and confirmations, and making payments. In handling this UOB, the travel agent process will start its own conversations with partner hotel and airline businesses. Each of these subordinate B2B conversations is governed by its own TPA.

    One TPA can be used for many independent UOBs between the same trading partners - either serially or concurrently. A single TPA can include definitions for multiple interaction sequences and multiple message formats, any of which can occur in a UOB instantiated from it. Effectively, a TPA acts as the "control center" for all system-mediated interactions with an external entity.

    Over time, the accumulation of TPAs can become an effective repository of enterprise interbusiness process descriptions, providing a major tool for enabling process enhancements.

    How Are TPA-Specified Interactions Organized?
    The TPA simplifies the specification of a B2B interaction by organizing the information into separate functional layers. Dataflow through the runtime layers is governed by specifications in the TPA. This layering provides appropriate abstractions for business dataflow and minimizes the need for specialized coding. Three functional layers are specified in a TPA and supported in underlying BPF runtime processing, as follows:

  • Transport: Handles the selected transport protocol, network connection and basic security
  • Document Exchange: Provides document abstraction, including message data mapping, nonrepudiation, time-stamping, logging and auditing
  • Business Protocol Rules and Interface: Provides message sequence and responsiveness checks, document type and trading partner-specific data handling, together with interface logic to connect to specific local business applications

    How Are TPAs Structured?
    A TPA document contains the following five categories of information:

  • Overall Properties: This includes TPA name, starting and possibly ending dates for validity of the agreement and other global parameters.
  • Role and Identification: This category identifies the parties to the TPA as logical roles such as "buyer," "seller," "airline," "hotel" and so on. Specific organization names and contact information such as e-mail and postal service addresses are then provided for each role. The allowable actions under a TPA are organized by role, making it easy to modify an existing TPA to specify identical interaction rules but with a different partner. An optional role is that of external arbiter for use in resolving disputes.
  • Communication and Security: These attributes specify the communication and interaction protocols to be used. The specification is layered into transport, message handling and higher-level conversational sections. Protocol choices and parameters for security functions are available, such as authentication, certificate handling and nonrepudiation.
  • Action and Sequencing: For each identified role this is a menu of the actions that can be performed on request from the partner. A signature is specified for each action defining the parameters and their data types. Sequencing rules specify constraints on the order in which actions can be requested. In the case of the travel agent process interacting with a hotel, example actions would be requests to make a room reservation and subsequently to modify it.
  • Cancellation and Error Handling: Cancellation rules indicate whether the result of a completed action can be cancelled, and if so, the constraints under which such a cancellation is permissible. Error-handling rules manage error conditions (such as the maximum waiting time for the response to a request). Commentary text can be added to the TPA to cover other negotiated, but not processed, issues

    (see Figure 3).

    TPA Preparation and Setup with BPF
    BPF includes a suite of tools to support the TPA life cycle including preparation, setup and generation of new TPA documents and the generation of interaction processing from them. The tools are used as follows:

  • Authoring Tools assist the creation of new TPAs. In many cases it may be convenient to construct a new TPA by combining elements from those previously deployed, tailoring the result for the new target interaction. The authoring tools for TPA include modeling and template functions to simplify TPA assembly from preexisting parts.
  • Registration Tools are used to populate a registration database with interface information identifying the user application logic to be bound into the business-to-business interactions and user-provided helper functions such as specialized parsers, security handlers and encoders.
  • Code Generation Tools use the TPA and information from the registration database to generate program objects (executable files) that, together with the runtime BPF, support and implement the required B2B interaction processing.

    Hence, starting from a TPA authored with the tools described above, and using a combination of generated and runtime logic, BPF provides a complete implementation of all message and interaction logic needed for a particular trading partner interaction. As TPAs are XML-based, the strong syntactic checking available within advanced XML editors can be used in these tools to diagnose and warn of inconsistencies

    (see Figure 4).

    At runtime, the BPF Manager uses the data in the registration database and the generated program objects to manage information flow through the system and to control execution of the business rules in the TPA. In addition, functions such as event handling, security services and logging are handled by BPF's runtime services. The BPF-generated code enables interenterprise integration, alleviating the need to develop custom programs to manage networking, business event handling, message processing and sequencing.

    Generating interaction code from TPAs allows appropriate security validation and message logging steps to be added systematically. Hence the level of security is adjusted to the communication context of each business partner connection, providing appropriate protection for secure interactions across a publicly accessible network. BPF-generated checks for responsiveness of the partner and valid message sequences improve reliability further.

    As noted earlier, to provide an effective single point of consolidation for interactions, a B2B infrastructure needs to provide a broad range of connectivity options. It's also important to provide services for defining, parsing and manipulating XML messages, together with facilities for importing other message libraries and services. This can simplify the mapping of other existing application and message formats both into and out of XML messages.

    BPF Runtime Services
    When interacting with business partners across open networks such as the Internet, there are likely to be considerable variations in request/response times. In these cases a single business flow requiring responsive interaction with multiple partners, such as in the travel example above, will need to employ parallel concurrent conversations. During these types of conversations, partners may detect unexpected conditions requiring specialized action by the interaction or business logic software. The BPF provides services that map interaction events from message processing into business events that can be meaningfully handled in the business applications. These services enable the coupling of application processing to appropriate interaction processing, with the ability to control how interaction events are filtered and combined.

    Other BPF services provide support for the following five services:

  • Synchronous call requests: This will allow business applications to make simple synchronous calls requesting an interaction. The framework transparently maps these into asynchronous messaging interactions, preserving the synchronous appearance to the application.
  • Interaction event definitions: A service to allow the definition of interaction events and event-combining rules that result in applications being "called back" only when a specified set of interaction events or time-outs has occurred.
  • "Callback" rules: This service indicates which application methods should be invoked when a particular business event occurs.
  • Subordinate conversations: This provides logic that specifies that a subordinate conversation with a new partner is to be started and considered part of the one currently in progress.
  • Cancellation and compensation: A cancellation/compensation framework facilitating cleanup when a business interaction has to be cancelled.

    Each of these services contributes toward providing a simplified and generic view of external events to internal business applications. Information about the conversation state is available to internal applications to assist in event management. The combination of user-provided interface and rules code with the BPF services mediates between the entirely generated interaction handling support derived from a TPA, and business logic written as a standard application or business workflow.

    Using the BPF
    Successfully building B2B IT solutions involves a need to understand in detail how to interact and exchange messages with applications and business processes owned by external trading partners. However, the variety of protocols needed for this messaging is innately complex and related to technology rather than to the structure of a particular business process. Defining interaction styles using TPAs, together with BPF runtime services and support from appropriate middleware, provides a rapid, easy-to-use and flexible approach to the development and deployment of B2B solutions.

    Utilizing the BPF can improve and accelerate development of new interenterprise e-business solutions in a number of ways, including:

  • Interaction definition simplification: Structures and simplies the definition of interactions with trading partners, specifying what each party will expect of the other
  • Choice of connections: Handles all popular modes of communication to enable interaction and data interchange with any potential trading partner
  • Automated code generation: Automates the generation of connection and interaction logic enabling rapid commencement of trading interactions with new partners
  • Code reuse: Allows generic logic within existing business processes and applications to be reused for various partners using different types of interconnection
  • Evolutionary approach: Enables a smooth transition to broader e-business capabilities by building on any existing EDI or message-based integration capabilities

    The Value of TPAs
    XML-based TPA documents provide value in that they capture the essential information that trading partners must agree on in order for their applications and business processes to communicate. In integrating the business process of multiple partners, there's value in distinguishing "interaction" information - on which there must be agreement - from more private design and implementation decisions - which can be made autonomously and independently by each participating partner.

    TPAs and their associated authoring and registration tools can help speed the process of defining how new trading partner interactions should take place. Since the TPA is a formal XML document, XML tools can provide a valuable level of consistency checking to detect obvious mismatches immediately. In many cases the definition of the interaction style can be further simplified by starting from a sample TPA template as a model, or by basing the TPA on one of the emerging standards for e-business such as Open Buying on the Internet (OBI) or RosettaNet.

    Support for all widely used communication modes makes it possible to reach an agreement on interaction rules - and therefore a TPA - with almost any trading partner. This ability to interact with any potential partner provides the opportunity to attract and select e-business partners from the broadest possible marketplace.

    The Value of the BPF
    Using the BPF tools, a TPA document can be rapidly created to define the interaction between an enterprise's business systems and those of a trading partner. Subsequent automatic code generation from this TPA - combined with runtime services - provides a complete implementation of the required interaction and communication logic. Therefore, within a relatively short space of time, an enterprise can be ready to connect with a particular partner.

    When partners have been identified and an agreement reached to conduct e-business - assuming an agreed interaction mode is also ready - conversations can be quickly and easily initiated and business trading begun. This ability to start conducting e-business with new trading partners immediately, without waiting for programming help, provides the ability to attract and select e-business partners in real time. To be able to move quickly and leverage full advantage from these new trading interactions, the programs implementing internal business processes need to drive generic "reusable" B2B interactions.

    Choosing new trading partners and starting interactions dynamically also depends on being able to support a range of interaction choices. Since all the necessary protocol checking and messaging logic needed for any one TPA is automatically generated, internal applications issuing higher-level interaction requests will be able to reflect just the business process steps. This separation of partner interaction from business logic flow makes it easier to dynamically add or change partners and helps simplify the logic within business applications. This makes it easier to evolve and extend the function of automated business processes.

    BPF helps separate network interaction processing cleanly from business processes. This is more important in B2B integration than within an enterprise because of the greater variety of interaction technologies involved.

    Summary
    Here's what a tpaML document and a B2B Protocol Framework can provide:

  • Tools for authoring or assembling electronic TPA documents and generating interaction code from them
  • The runtime system to support the automatically generated interaction code
  • Operational tools for managing and monitoring e-business operations with trading partners
  • Tools, APIs and services for interfacing existing applications and business processes to the generated logic for interacting with trading partners.
  • More Stories By Francis Parr

    Francis Parr is a staff member at the IBM Thomas J. Watson Research Center in Yorktown Heights, New York, and is currently responsible for technology transfer activities involving joint work between IBM Research and IBM Transaction and Messaging Products in Hursley, UK. He's been involved in e-commerce, messaging and integration products, parallel DB, scalable object technologies and distributed processing. Francis joined IBM Research in 1979.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.