Introduction to Trading Partner Integration, Part 1

by Hussein Badakhchani
09/19/2005

Abstract

The goal of trading partner integration (TPI) is to streamline and automate the business processes that trading partners participate in, in an effort to reduce costs and create a strategic advantage. This article introduces trading partner integration with BEA WebLogic Integration (WLI). I start by exploring the history of trading partner integration (also known as B2B integration) and defining what I mean by the term. I then examine the requirement for TPI and the challenges and benefits it brings to businesses. Next, I identify the key concepts in trading partner integration. Finally, I show how BEA WebLogic Integration implements these ideas and simplifies the integration process. It should be noted that TPI is only a part of the WebLogic Integration suite of tools.

Introduction

As enterprise Java developers coding business logic, many of us have faced the challenges posed by integrating trading partner services into our applications. Some of us turned to Web services for the solutions. Those among us who have managed to find the time to do a little Web surfing have probably noticed a few other terms and acronyms starting to find their way onto Java technology Web sites; these include BPEL, ebXML, RosettaNet, and WS-CDL. These specifications are all related in one way or another, and it's no coincidence that we're hearing more about them because they have the potential to make profound changes in the way we approach trading partner integration. Take RosettaNet, for example. This set of specifications (now arguably a standard) allows trading partners to automate their supply chains. By creating a common "language," RosettaNet lets trading partners communicate supply chain movements, orders, invoicing, and payments with each other. Manual processes that were time consuming and error prone can be streamlined into fast, secure, and fault-tolerant automated processes. Before I discuss the benefits of trading partner integration in more detail, let's take a brief look at its history.

A Brief History of Trading Partner Integration

Electronic Data Interchange (EDI) is widely considered the first technology that gained major acceptance in the field of trading partner integration. EDI technology has been around since the late 1960s, with the first implementation of an EDI-compliant system emerging in 1970 by the Bankers Automated Clearing Service (BACS), now VOCA. This set of standardized electronic business documents is exchanged in agreed-upon formats. EDI exploited the benefits of doing business and conducting transactions with your trading partners electronically and covered most things that were traditionally done using paper-based communication—but it wasn't all plain sailing.

Early electronic interchanges used proprietary formats agreed upon between two trading partners requiring new programs each time a new partner was added to the existing system. Later on, some industry groups began a cooperative effort to develop industry EDI standards for purchasing, transportation, and financial applications. Many of these standards supported only intra-industry trading, which led to a large number of EDI formats. By the 1980s, EDI was an established technology among large corporations, but high implementation and maintenance costs as well as a variety of competing standards hindered its widespread adoption among small- and medium-sized businesses. EDI remains at the heart of many B2B integration efforts; however, the arrival of Web services that enable real-time processing as opposed to the batch processing of traditional EDI applications and adherence to accepted open standards has made EDI a legacy technology in many organizations.

The advent of Web services, which I define as using SOAP and WSDL to describe and access services over the network, reignited interest in trading partner integration by promising to deliver the benefits of integration more efficiently than previous initiatives. Among the key advantages offered by Web services are:

• A simplified mechanism to connect applications regardless of the underlying technology or devices they use, or their location
• Their use of industry-standard protocols and open standards
• Universal vendor support
• Their ability to leverage the Internet for low-cost communications, as well as other transport mechanisms
• The loosely coupled messaging approach supports multiple connectivity and information-sharing scenarios through services that are self-describing and can be automatically discovered
• Real-time processing
• Multiple levels of security

The use of industry-standard protocols and open standards deserves some elaboration as you can argue that without these, Web services would suffer from the same restrictions of EDI. Vertical standards (industry-specific standards) such as RosettaNet remove the burden of having to develop a new solution for each new trading partner we wish to trade with, as these are built on horizontal standards (not specific to any sector or industry) such as BPEL and WS-CDL. These standards facilitate integration across sectors for cross-cutting concerns such as billing. A good example of this is the SWIFT message models already adopted by RosettaNet for corporate-to-bank payments and the work being done by TWIST to allow market participants to communicate with each other.