B2B Integration-A Case Study

This article presents a B2B integration scenario with a case study. Various approaches for integration are considered in the case study before a final solution is presented. The article does not intend to give an overview of the B2B initiative. The intended audience must have an understanding of the B2B paradigm.

Brief Introduction to B2B

Business-to-Business (B2B) e-commerce is a subject that has reached front-page status in the popular press. Although there is confusion between the B2B and B2C integration paradigms, there are differences that go much deeper than the differences between retail and wholesale purchasing. B2B integration is fundamentally about coordinating information among businesses and their information systems.

In today's world with companies operating in a global business environment, B2B integration is a pre-requisite for them to remain competitive. They need to come out of their shell and interact with their suppliers, partners, and customers distributed throughout the world. B2B integration enables a company to focus on its core competencies and offload other services to partners to gain efficiency and reduce cost.

After a decade of spending on expensive ERP systems, Customer Relationship Management, and e-Commerce applications in a departmental manner, companies are turning their attention to integrating these information silos. However, if this integration is done on a point-to-point basis, these companies end up spending up to 35% of their software maintenance budgets on simply maintaining these connections. Simply connecting applications on a point-to-point basis is not enough. Without a thoroughly integrated internal infrastructure, B2B initiatives are sure to provide little value in the best-case scenario, or no value in the worst.

Business Case Introduction

Royal Wallace is a UK-based energy company that has been operating for the last 60 years. Its business model is based on supply chain management. It has disparate business processes within the organization that need to be seamlessly integrated with its Business Associates (BA) as well as the internal users. But, the network bandwidth that is available for this integration scenario is only 64 Kbps. Also, the company wants a synchronous mode of integration rather than an asynchronous one. This is to enable a request-response type of interaction with the company's associates and partners over the network. Because there are hundreds of connection points (target applications at the BA's end) in this scenario, the company wants minimal overhead of installing and maintaining the infrastructure and the software required. And, last but not the least, the company wants a low-cost integration solution.

Figure 1: Business Model of Royal Wallace Company

Approaches Considered

Enterprise Application Integration (EAI)

EAI (enterprise application integration) is a business computing term for the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise. Typically, an enterprise has existing legacy applications and databases and wants to continue to use them while adding or migrating to a new set of applications that exploit the Internet, e-commerce, extranet, and other new technologies. EAI may involve developing a new total view of an enterprise's business and its applications, seeing how existing applications fit into the new view, and then devising ways to efficiently reuse what already exists while adding new applications and data. In the simplest terms, EAI is the process of coordinating the operation of various applications across an enterprise so that it can perform as an integrated enterprise-wide system.

Several EAI tools by leading vendors are available in the market today—TIBCO, Seebeyond, Vitria, and MQ Series to name a few. The underlying architecture in these tools is generally a 'Hub and Spoke' model or 'Integration bus architecture.' These tools work on the control broker-adapter model wherein an application-specific adapter sits in the client end and interacts with the control broker to pass the messages/events to the target applications.

Figure 2 shows a typical integration scenario in one of the most popular EAI tools, called Seebeyond.

Click here for a larger image.

Figure 2: EAI integration using Seebeyond (For more information on Seebeyond, visit the link www.seebeyond.com).

Royal Wallace Company tried the EAI approach for integrating with its internal users. This approach was not quite successful because of the high cost of licensing the software and support that was involved thereafter. Although the approach offered features such as security and guaranteed delivery as part of the product, the hidden costs made it a less viable solution.

Pros

• Relatively less bespoken development on Enterprise and its Business Associates side.
• Transfer of data across different protocols, using different message formats and semantics.
• Offers certain features such as Security and Guaranteed delivery out of the box.

Cons

• High cost of licensing and supporting.
• Need to install sophisticated third-party S/W at Business Associates sites.
• High hidden costs: in-house EAI specialists, support staff, etc.

Electronic Data Interchange (EDI)

Electronic Data Interchange is a subset of Electronic Commerce. It is a set of standardized electronic business documents that are exchanged in agreed-upon formats. It is about doing business and carrying out transactions with your trading partners electronically.

EDI covers most things that are traditionally done using paper-based communication. It is not a new concept or a new practice. EDI has existed for more than two decades in Europe and North America. 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.

Figure 3 depicts an integration scenario with EDI.

Click here for a larger image.

Figure 3: EDI enabled integration over a value added network (VAN)

The major problem that the Royal Wallace Company faced with the EDI approach was to describe the rules and semantics for each piece of information to be exchanged with the BAs. Also, the VAN (Value Added Network) bandwidth requirement was more than that available for the integration scenario (64 kbps). Moreover, the EDI approach is more suited for batch processing rather than a request-reply mode of interaction. The Royal Wallace Company had to do away with the EDI approach.

Pros

• Messaging Standards such as EDIGas could be used.
• Offers security, non-repudiation, and guaranteed delivery.

Cons

• High cost of software and support
• Not suited for real-time processing. The VAN is a store-and-forward network and is more suited to batch processing
• Rules, grammar, and semantics for each piece of information need to be provided to the BAs

Web Services

Web Services is a distributed computing technology, which is defined by loosely coupled, dynamically located software components on the Web. These components break down the larger software system into smaller logical modules, or shared services. These services can reside on different systems and can be implemented by vastly different technologies, but they are packaged and transported using standard Web protocols, such as XML and HTTP, thus making them easily accessible by any user on the Web. Web Services typically work on the Register, Discover, and Invoke models.

Figure 4: Web services deployment model

Royal Wallace Company was skeptical about the Web services approach for its integration requirement. Although Web services are fast becoming a de-facto standard with support from industry heavyweights as Microsoft, IBM, HP, Sun, and Oracle, it is still not widely used for e-commerce–related transactions on the Web. The overhead of the maintenance of IT staff required to maintain the application and the inherent issues associated with Web applications such as availability made the company decide to do away with this cutting-edge technology.

Figure 5 shows the Web services implementation in the Royal Wallace business model.

Click here for a larger image.

Figure 5: Web services implementation in Royal Wallace Business model

Pros

• Open standard for Application-to-Application communication. Based on standard protocols such as HTTP and XML
• Supported by all the leading vendors. Hides complex implementation
• Fast gaining acceptance in the world as a means of communication between applications

Cons

• Not widely used yet
• Higher transmission/processing costs because XML is verbose (at the benefit of being easier to understand and maintain)
• Has all the issues associated with the Web in terms of availability, immutable interfaces, and so forth
• Aspects such as guaranteed delivery, non-repudiation, security, and the like may not be built-in

Compare the three approaches considered here....

Feasible Solution: XML over HTTP

Extensible markup language (XML) is a specification developed by the W3C. XML is a pared-down version of Standard Generalised Mark-Up Language, designed especially for Web documents. XML is a programming language that enables designers to create their own tags to indicate specific information. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

XML is similar to the language used for Web pages, the Hypertext Markup Language (HTML), in that both use markup codes (tags). Computer programs can automatically extract data from an XML document, using its associated DTD as a guide. XML represents complex structures easily and a number of parsers are available off the shelf, free of cost, to parse the XML data.

Advantages of using HTTP as an Interface Protocol

1. HTTP is based on open standard and used widely.
2. HTTP is simple and well understood.
3. HTTP can carry any data type.
4. Implementations of HTTP clients are available in various programming languages such as Java, VB, .NET, PL/SQL, and so forth.

Figure 6 shows the XML over HTTP implementation scenario in Royal Wallace Company.

Click here for a larger image.

Figure 6: XML over HTTP implementation (SiteMinder is a third-party authorization tool)

Because Http clients are available in various programming languages, Royal Wallace Company could easily integrate with all the target applications with any changes at the Business Associate's end. The client sends out a request/message in the form of an XML document to the company. After validating the user with some third-party package at the company's end, Royal Wallace Company could generate the output in the form of an XML document and send it back to the requester (BA) along with the schema DTD. Thus, the company could finally achieve a low-cost, request-reply mode of integration with this approach.

Conclusion

The question that arises is 'Is the XML over HTTP solution a lightweight Web Service?' The following table gives a comparison of the two approaches:

However, in this case study, XML over HTTP gained over other viable solutions in meeting the client requirements for B2B integration.

• The XML over HTTP option was considered to be the best suited for implementation
• Minimum overheads and faster rate of data transfer
• The XML over HTTP solution can be extended to provide a full-featured Web service

The designer of the solution should keep all the pros and cons of each approach in mind and go for the best suited approach/implementation for their requirements.

References

White Papers are posted at the following locations:

http://eai.ebizq.net
http://www.eaijournal.com

Useful Links

www.xml.org
www.knowledgestorm.com

About the Authors

Manoj Seth is a senior software engineer at Hewlett-Packard, India. He is a Post Graduate from the Indian Institute of Information Technology, Bangalore.

Manoj has been involved in designing and developing J2EE-based solutions over various platforms in the domains of Financial/Banking and Middleware for more than two years. He has good exposure to Web Services and their emerging standards in development/deployment and management space. He can be contacted at manoj_seth@hp.com.

Tarun Gupta is an Integration Analyst at Wipro Technologies, India. He is a Post Graduate from the Indian Institute of Information Technology, Bangalore.

Tarun has around four years of experience in the integration domain. He has used various tools such as WebMethods, Seebeyond, and TIBCO to provide solutions in manufacturing and telecomm domains. He can be contacted at gupta.tarun@wipro.com.