XML-Based Business-to-Business E-Commerce

Transcription

1 XML-Based Business-to-Business E-Commerce Michael Blank MOST COMPANIES HAVE ALREADY RECOGNIZED THE BENEFITS of doing business electronically. E-commerce takes many forms and includes supply chain integration, procurement, online banking, and shipping and logistics. Solutions such as Enterprise Resource Planning (ERP), Electronic Data Interchange (EDI), and the Web have formed the foundation for E-commerce today. These applications link groups of departments, divisions, and companies that want to buy, sell, and exchange services and products, and that depend on seamless information access. However, in order to remain competitive, companies will have to find solutions to extend their electronic trading networks among companies of all sizes. The technological hurdle to overcome is to find ways to access data that may reside in other complex systems, such as legacy databases, ERP, EDI, and the Web. The goal of this chapter is to explore how XML (Extensible Markup Language) technologies allow businesses to rapidly and easily engage in business-to-business (B2B) E-commerce. It explores how companies can achieve application-to-application integration across highly heterogeneous environments by leveraging existing investments in legacy and Webbased products and technologies. COMMERCE COMPONENTS In order to fuel the growth of electronic trading networks beyond the enterprise, three major sources of information must be unlocked EDI, ERP, and electronic commerce on the Web. A B2B integration solution must allow these disparate systems to communicate with each other, without requiring changes to the systems themselves.

2 EDI EDI is based on a set of computerized forms that automate common business transactions such as package orders, invoices, shipping notices, and requests for proposals. EDI lets companies send and receive purchase orders, sales orders, invoices, and electronic payments. EDI messages consist of agreed-upon data elements that typically appear in commercial business forms: names, addresses, prices, dates, and item numbers. Standardized lists of these data elements comprise forms such as purchase orders, invoice, ship notices, and medical billing forms. Hundreds of these forms have been developed over the past 20 years or so by a committee called X.12 of the American National Standards Institute (ANSI). International EDI standards have been coordinated by a United Nations organization called UN/EDIFACT. EDI documents are essentially flat text files. They must be translated out of and into trading partners internal systems, often at great cost. The widespread acceptance of EDI historically has been hampered by the prohibitive development and maintenance costs. Because EDI is a rigid standard, it requires complicated, proprietary translation and integration software. Furthermore, EDI is typically carried over private value-added networks (VANs), which requires expensive hardware as well as a transaction- and volume-based subscriber fees. As such, EDI solutions have been limited to large companies, while excluding any trading partners that may not have the purse to play along. Because EDI is so expensive, cumbersome, and proprietary, Forrester Research estimates that only 2 percent of electronic transactions are done via EDI. The Internet, with its low cost of entry and ease of use, could change all that; EDI over the Internet currently allows organizations to access a wider range of trading partners. Even though Internet-based EDI would eliminate the need for proprietary VANs, it does not address the need for costly translation software and integration with enterprise applications. Traditional EDI vendors, such as Sterling Commerce, Harbinger, and GE Information Services, have allowed smaller companies to participate in EDI activities by providing Web-based forms for manual entry of EDI information, which is translated to an EDI format and forwarded to a larger trading partner. Internet-based EDI is still very interactive, and allows very little automation in comparison to direct automated VAN access from one company s system to another s. Other forms of Internet-based EDI include sending data through encrypted . While Internet-based EDI is offered by several vendors, they are not interoperable, again due to the lack of standards. Large trading com-

3 panies have coerced EDI standards to conform to their business processes, making it hard for smaller companies to compete. With different standards between trading partners, a company might have to support as many EDI implementations as they have trading partners, making it too costly for smaller companies to participate. While the Internet expands the network reach of EDI, there is still a market requirement for seamless information exchange among all trading partners that extend the reach of proprietary EDI networks. As we ll see, EDI combined with XML-enabled integration solutions holds the promise of leveling the playing field and achieving a high degree of interoperability. ERP The Enterprise Resource Planning (ERP) system is another form of electronic commerce. It seeks to automate business process that span the organization, incorporating functions such as sales and materials planning, production planning, warehouse management, financial accounting, and personnel management into an integrated workflow of business events. ERP applications provide universal access to information across heterogeneous networks and data sources throughout the enterprise. While automating key internal business processes is an important step towards integration, integrating processes and information with the information systems of key customers and suppliers is a real competitive advantage. Sharing ERP data among business partners can streamline value chain processes, automate purchasing or customer service applications for real-time processing, and reduce the cost of order processing and financial transaction management. SAP, one of the leading vendors in the ERP space, has already recognized the need to extend R/3, their ERP solution, to address supply chain management. Unlike ERP systems, supply chain systems must cope with the complexity of integrating information from any number of disparate information systems spanning the entire length of the supply chain. In response, SAP has exposed business components within the R/3 system to applications compliant with open standards such as DCOM and CORBA. Like EDI, ERP installations are not only proprietary but also involve substantial investment, which limits these solutions to larger companies. Because they focus on the enterprise, there are even fewer standards that link the ERP systems of different companies. Technologies and standards that bridge the gap between ERP and EDI or Web-based systems are virtually nonexistent. XML has the promise to extend ERP beyond the bounds of the enterprise to achieve higher levels of intercompany and multivendor interoperability.

4 THE WEB The Web has changed the face of business. Advertisements now feature URLs, and many organizations support sales over the Internet. Consumer Web users can browse catalogs, select items, and make purchases from the comfort of their living rooms. But Web-based shopping is only the tip of the electronic commerce iceberg. While much of E-commerce has been consumer oriented, the Internet can also be used to drastically improve efficiency, reduce costs, and increase sales for an organization by automating the businessto-business relationships with suppliers, distributors, and other partners. Without realizing it, organizations have already established a viable set of services, available on the World Wide Web and addressable by URLs. Existing Web services span the spectrum from package tracking and online banking to procurement and supply chain integration. Companies have looked to the open standards of the Web as a common means to communicate with their trading partners. Legacy databases, mainframes, and even EDI systems have been exposed via HTTP and HT- ML. The Web has truly become an integration platform. However, HTML-based applications assume that a human is interacting with the system through a Web browser, browsing catalogs and placing orders. While this approach is appropriate for a casual shopper, it is not the most efficient design for business process-driven applications such as supply chain management. For greatest efficiency, the intercorporate supply chain should be automated to work without human intervention. For example, as inventory levels are depleted, the ERP system should automatically query suppliers for inventory levels and delivery schedules, and automatically place orders for replacement stock. Although the information and processes to query and place orders might already be integrated with the Web, they aren t designed to support external automated interfaces. Therefore, new interfaces need to be created to support Internet-based supply chain automation. THE NEED FOR BUSINESS-TO-BUSINESS INTEGRATION Solutions such as EDI and ERP focus only on providing software for automating operations within tightly coupled organizations. For an organization to achieve full benefits from electronic commerce, a solution must automate the operations between trading partners. An integration solution must cope with the complexity of integrating information from any number of varied information systems, spanning the entire length of the E-commerce continuum. A solution must provide a secure and reliable mechanism to communicate between applications; the message format must be open and flexible enough for different applications to understand, process, and respond to it.

5 Some users are looking towards XML to solve the problem of businessto-business integration. XML may be the emerging standard that promises to bridge the communication gap between enterprise resource planning, electronic data interchange, and Web-based systems. Its real significance may emerge as a means for making it easier to create, deploy, and manage integration solutions over the Internet. WHAT IS XML? XML (extensible Markup Language) is a universal standard for data representation that can encode documents, data records, structured records, even data objects and graphical objects. XML documents are ASCII files that contain text as well as tags identifying structures within that text. This enables XML to contain meta data data about the content in the document, including hierarchical relationships. As such, XML is a standalone data format that is self-describing. The following example illustrates how a purchase order might be represented using XML. <?xml version=ò1.0ó?> <PurchaseOrder> <OrderNumber>1001</OrderNumber> <Status>Pending</Status> <Company>The ABC Company</Company> <LineItem> <SKU>45669</SKU> <Description>Modem Cable</Description> <Price>9.95</Price> </LineItem> <LineItem> <SKU>35675</SKU> <Description>Modem</Description> <Price>99.95</Price> </LineItem> </PurchaseOrder> A business application can locate a particular element and extract its value, regardless of the order of the elements within the document, and regardless of whether it recognizes all of the elements. INTEROPERABILITY WITH XML XML offers a lot more flexibility and extensibility than traditional messaging. The application that publishes the XML document could add a new attribute to the document, such as Quantity, to support the requirements of another application. The original applications that used the document

6 would be unaffected by the additional attribute since they may only be interested in the SKU, Description, and Price of the Item. An XML document may be fully described by a Document Type Definition (DTD). An XML DTD specifies the format for a particular XML document type and identifies what tags must or may appear within the document. An XML document may contain or reference a DTD, in which case the DTD may be used to validate that the document matches a specific format. DTDs may be utilized to define standard vocabularies, designed for specific communities of interest. For example, the messaging formats for partners along the supply chain could be specified by a common DTD. XML Alone Is Not Enough XML is an open standard, which leads us to a Utopian perception of automatic interoperability. However, XML alone does not provide a complete integration solution, but it represents a central piece of the puzzle. Integrating applications with XML actually requires a fair amount of work. Applications have to be able to understand, process, and respond to XML message formats. Although the two applications do not need to agree on a specific message format, they still must reach consensus on the meaning of the data being passed. The two different applications are very likely to use different DTDs, and they must establish a way to match elements and attributes from one DTD to the entities and attributes in the other DTD. In most circumstances, it is not enough to simply pass information from one application to another. The sending application has to tell the receiving application what to do with the data. Therefore, the two applications need to agree on a mechanism for specifying what should be done with the data. A complete B2B solution would supply mechanisms that relate one application s data structures to those of another. And it would provide a mechanism for requesting specific services to act on the information. Combining XML and integration software brings us closer to a B2B integration solution. AN XML-BASED B2B INTEGRATION SOLUTION Although it is extremely powerful, XML by itself cannot deliver application integration. Application integration involves much more than selfdescribing, extensible message formats. The application must be adapted to learn to communicate using XML. It must be able to route requests, manage tasks, and translate between messages conforming to different DTDs.

7 Exhibit Integration server connecting applications to applications and applications to Websites, over the Internet or an extranet, enabling the integration of business processes between trading partners. A complete solution must also provide the integration between other internal or external systems. We ll refer to the application that implements such a solution as an integration server. The integration server exposes a collection of integration services to XML-enabled clients. An integration service in the most generic sense is addressable by name, and it has a set of inputs and a set of outputs. The integration server provides the mapping of XML messages in and out of integration services. Exhibit 25.1 illustrates how such a solution might support Web and application integration between multiple corporations based on an XML messaging mechanism. The environment provides a central integration point to support XML-enabled client applications and provides access to both internal and external resources. XML AS THE RPC MESSAGE FORMAT An application that requests a service of another application must issue a message to the other application. For the purposes of this discussion we ll refer to such a message as a Remote Procedure Call (RPC). An application issues an RPC by packaging a message, sending the message to the other application, and then waiting for the reply message. Integration servers can combine the power of RPC middleware with the flexibility of XML to build a highly extensible, intercorporate integration

8 system. XML RPC passes data as self-describing XML documents, unlike traditional RPC middleware systems that use a fixed, predefined message format. Formatting the messages using XML makes all B2B integration solutions highly flexible and extensible. XML RPC performs all communications over HTTP using standard HTTP get and post operations. The contents of the XML RPC messages are standard Internet traffic: XML documents. XML RPC obviates the need to open firewalls to traditional middleware protocols such as DCOM or IIOP. MAPPING BETWEEN DIFFERENT DTDS The integration server must be able to map between different XML data formats, or DTDs. WIDL (Web Interface Definition Language) 1 provides such mapping capabilities and allows applications to communicate with each other via XML, regardless of the DTD they conform to. WIDL provides document mapping by associating, or binding, certain document elements with application variables. Data bindings may be used to extract some or all of the information in an XML or HTML document. The following example illustrates the use of a WIDL binding with the XML document presented in the earlier example. <OUTPUT-BINDING NAME=ÒPurchaseOrderDataÓ> <VALUE NAME=ÒOrderNumberÓ>doc.OrderNumber[0].text </VALUE> <VALUE NAME=ÒSKUÓ DIM=Ò1Ó>doc.LineItem[].SKU[0].text </VALUE> </OUTPUT-BINDING> An application would apply this binding to the XML purchase order document in the first example to map the order number and the list of SKU numbers to the variables OrderNumber and SKU. Only the variables defined by the WIDL binding are exposed to the application. The variables within a WIDL binding abstract the application from the actual document reference, even from the XML data representation itself. An integration server would be able to apply similar bindings to a variety of XML formats to achieve the mapping between different DTDs. Exhibit 25.2 illustrates the benefits of this capability. Here, industries and businesses have defined a variety of DTDs to which different RPC encodings conform. The interface defined with WIDL captures a superset of the services and data available through the DTDs. Although different client applications speak different XML encodings, the integration server is able to bridge these differences and to make the application universally accessible. This approach enables different organizations to construct loosely coupled application integration schemes. One organization may want to estab-

9 Exhibit Using WIDL to make different XML messages interoperable. lish electronic integration among many different partners. Each partner maintains electronic relationships with many other partners. It s extremely difficult for such a loose partnership organization to reach agreement on a single set of message formats. But XML DTD mapping bypasses the need to reach total agreement. Each organization can define its own DTD. An integration server would automatically resolve the differences and deliver information to an organization in the format that the organization requires. EXPOSING APPLICATION SERVICES Application services provide access to certain resources, which the integration server exposes to other XML RPC-based applications. The integration server decodes the XML RPC request, identifies the service requested by the RPC, and passes the request on to the service in a data format it understands. It then encodes the output of the service as a properly formatted XML RPC reply that the client is able to understand. The application service provides the actual integration with internal or external resources, such as the Web, databases, EDI, or ERP systems. The implementation of a service, therefore, is completely abstracted from the message format. XML-based integration solutions actually XML-enable the systems they are integrating. For example, an integration solution might support the direct integration of different ERP systems across the Internet. A manufacturer running SAP R/3 can integrate its procurement system with the order processing system at a supplier running Baan. The integration solution is implemented separately from the application systems. No modifications are required within the back-end ERP application systems. In addition to providing a centralized switching system to support intercorporate communications, an integration server might also host business logic modules that tie the entire environment together or that add additional services to the integrated applications.

10 EXPOSING WEB SERVICES An integration solution must also be able to leverage the vast quantities of information available on the Internet. It must provide unmanned access to Web resources, without a browser, and allow applications to integrate Web data and services. Programmatic access to the Web may also be referred to as Web Automation. WIDL enables Web Automation by defining Application Programming Interfaces (APIs) to Web data and services. By using its data bindings, WIDL is able to extract data from fields in an HTML or XML document and map them to program variables. WIDL abstracts the application from the actual document references (that is, where the data being mapped actually exist in a page). Web Automation makes complex interactions with Web servers possible without requiring human intervention. An integration server exposes Web services as regular integration services. With an XML RPC, client applications are able to invoke a Web service, provide a set of inputs, and receive a set of outputs. The client is abstracted from the actual implementation of the service and is not concerned whether data were derived from a Website, a local database, or remote ERP system. AN INTEGRATION STRATEGY Companies must be able to achieve application-to-application integration by leveraging existing investments in legacy and Web-based products and technologies. An integration server provides a transitional strategy for integrating the systems and processes of trading partners into the corporate infrastructure. Let s look at an example. A manufacturer aims to integrate with a number of suppliers. If a supplier does not yet have a Web presence, it would be free to choose a Web-enabling technology that best suits its environment. By deploying an integration server, the manufacturer can incorporate its suppliers Web services into its procurement process, for instance. To accomplish even tighter integration, the supplier could expose internal data by adding XML markup to its existing Web offering. The final step in achieving complete application-to-application integration occurs when a supplier also deploys an XML-enabled integration server. CONCLUSION Business-to-business integration delivers significant cost savings and operational efficiency through business process automation and just-intime supply-chain management. Traditional EDI is cost prohibitive for most organizations, so the industry is turning to Internet-based B2B E-commerce. XML is a tremendous enabler. Using XML, applications can imple-

11 ment loosely coupled integration services that are flexible and extensible. But XML by itself will not provide automatic interoperability. Application integration requires infrastructure services to support reliable and secure performance. An integration server provides the infrastructure services that XML lacks. The growth of electronic trading networks depends on access to diverse data and information sources that reside in various formats in electronic catalogs on the Web, legacy databases, EDI, or ERP systems. Suppliers who can provide solution which interoperate with multiple and diverse trading networks will become the dominant players in the electronic commerce arena. And their customers will become the earliest winners in the extended enterprise. Author s Bio Michael Blank is a Senior Engineer at WebMethods, Inc., the leading provider of Web Automation and business-to-business integration solutions for the Global Prior to joining WebMethods, Blank was a founding member of the Web integration team at America Online, where he was instrumental in engineering currently one of the most trafficked sites on the Web. With BDM Federal, he led some of the major reengineering efforts for the SEC s EDGAR electronic filing system. Blank holds a Master s degree in Computer Science from the College of William and Mary. Notes 1. In September of 1997, WebMethods, Inc. submitted the original WIDL specification to the World Wide Web Consortium (W3C). In October the W3C acknowledged WIDL for its significance as an IDL and for its significance as a technology for programmatically accessing the Web. The W3C makes the submission available at the URL <