Using XML effectively in eBusiness architectures   Table of contents   Indexes   Information and Content Exchange (ICE) Reference Version

 

Implementing an XML API for an n-tier eCommerce application

Hooker, Kristie
 
 Kristie  Hooker
 Engineering Manager for Ecommerce Systems
 Beyond.com
 California 
 Santa Clara 
 USA 
Beyond.com,  3200 Patrick Henry Drive
Santa Clara  California  95054 USA
Phone: 408 855 2626 Fax: 408 327 6400 email: kristieh@beyond.com web site: www.beyond.com
 Biography
 Kristie Hooker — Kristie Hooker has worked in the Internet and SGML industry for over 9 years and helped define and implement custom DTD's and SGML solutions for Novell, Tandem, SGI, Sybase and many other companies while working at Passage Systems. She also designed and implemented much of the Beyond.com order processing system including an XML interface with a custom DTD for eCommerce data interchange.
 

Abstract

 With the ability to precisely describe and validate data, using XML for data interchange offers many advantages. Since it is a standard with a structured markup, implementers can be assured of high data integrity and be confident of the proper execution of business systems. It is also extremely flexible and allows components to be reused and changed rapidly and easily. This is extremely applicable forn-tier eCommerce systems that pass data between many sources. In this presentation, the audience will learn what is needed to implement XML in an n-tier architecture as a source of interchange.
 

Introduction

 DTD, Document Type Definition 
 
It is important for the reader of this paper to understand the basic concepts and structure of XML as well as understanding the structure and importance of using aDTD . This paper discusses a specific implementation using XML to communicate between the tiers of an eCommerce system. It explains both why and how this architecture should be implemented.
 

Vocabulary

 API, Application Programming Interface 
 
The times are changing quickly and new vocabulary emerges each day. An example of this is the wordAPI - -this is used to describe the layer that is accessible to change the behavior of the application. XML is actually utilized in this way, but the term to describe this is not API, but ratherEAI . In this paper, the emphasis is on using XML to facilitate the EAI, which has a new term associated with it calledXAI . Please consult the following definitions for the latest industry standard meanings to familiarize yourself with the terms before reading this paper.
 EAI, Enterprise Application Integration 
XAI
 
API - Application Programming Interface The interface (calling conventions) by which an application program accesses operating system and other services. An API is defined at source code level and provides a level of abstraction between the application and the kernel (or other privileged utilities) to ensure the portability of the code.
 
n-tier An application which has many levels of communication. An example is a system which has a presentation tier, a process tier, a persistence tier as well as communication with outside 3rd party vendors.
 
eCommerce The conducting of business communication and transactions over networks and through computers. As most restrictively defined, electronic commerce is the buying and selling of goods and services, and the transfer of funds, through digital communications. However it also includes all inter-company and intra-company functions (such as marketing, finance, manufacturing, selling, and negotiation) that enable commerce and use electronic mail, EDI, file transfer, fax, video conferencing, workflow, or interaction with a remote computer. Electronic commerce also includes buying and selling over the World-Wide Web and the Internet, electronic funds transfer, smart cards, digital cash and all other ways of doing business over digital networks.
 
EAI - Enterprise Application Integration The seamless integration of business processes for the purposes of conducting business electronically. The sharing and/or exchange of data between systems for the purpose of providing a unified interface.
 
XAI - XML Application Integration EAI accomplished by using the XML standard.
 
DTD - Document Type Definition A formal definition for the grammar of a markup language. This structure is not in XML, yet it is supported by all XML tools as a standard. When XML markup conforms exactly to the DTD, the markup is considered valid.
 
Schema An XML document which precisely describes how the markup of an XML instance should look. This has the ability to do data typing, and is quickly becoming a new standard with many tools adding support.
 

Why should I use XML to communicate across the tiers of my application?

 When deciding on the format of the EAI, one has to consider many factors. Is there going to be a new communication format defined? Does this format fit the needs of the data? Is it flexible enough to adequately describe the data and so forth. One also has to consider how difficult it is to read and write this new format and if there are any existing standards to support it. It is especially relevant for the eCommerce industry to be able to easily integrate 3rd party applications. ECommerce applications tend to be very specialized and distributed across many different companies and businesses. XML is a great solution for your EAI for many reasons.
 

Markup can be customized to fit the application

 XML is the standard of choice for many companies due to its flexibility, ease of use and powerful data modeling capabilities. Any type of data construct can be mapped into XML.
 

Application/vendor independence

 Once a system is designed using a flexible XML interface between system components, the XML can vary to include industry standards in order to include 3rd party tools and products. This allows the system to be more flexible and able to adapt quickly to changing technology.
 ECommerce systems have many layers and communication tiers. Each of these tiers needs to be capable of communicating with the others and with external systems. Using an XML interface offers the ability to interface with other software packages or applications. This allows the system to grow and extend rapidly with the changing technology.
 

It's a standard!

 Why make up your own format? Standards are great to work with and are usually around for awhile. SGML (the foundation of XML) has been around over 10 years.
 

How can I implement XML in my system?

 Once the decision to use XML to communicate within your eCommerce application has been made, it's now time to build it. Whether this functionality is being added to an existing system or an entirely new application is being built, the following steps are important in ensuring a successful transition.
 

Identify your system

 The first step to a successful integration is to identify the system and its components. You then need to define what specific data is passed back and forth between applications. Let's look at an example for this discussion. The scenario is an eCommerce system, but we're going to focus on the portion that calculates tax. Since the logic of determining tax requires an extensive database as well as frequent data updates, many eCommerce companies choose to communicate with a 3rd party for this type of information. XML offers the ability to have a single communication method internally, which simplifies the system and allows the data to be mapped into any supported external format quite easily. Many outside vendors are beginning to offer XML as a communication mechanism. This will continue to happen, as XML is quickly becoming the standard of choice for the eCommerce industry.
 Below is a picture our how this architecture might look, given that the actual tax calculation is retrieved from a 3rd party system. We will discuss each piece and how it utilizes XML to interact with other parts of the system.
 It is very important to understand the data input and output from each piece of the system. A tax calculation requires the shipping location to determine locality as well as the amount to determine the actual tax to charge. We would send the order request to the internal tax processor component, which would in turn send the shipping address and price to the tax calculator externally. All of this is communicated via a centralRequest Broker as shown in the diagram. The Request Broker is the central component through which each communication is passed. It determines which piece of the system needs to be called to perform the required function. This process is usually called a workflow and can be changed quite easily without affecting any of the other system components. This system should also include aParser/Validator as well as aMapper for transforming the data into other formats. The final result should contain the tax to be collected for the order as well as any response messages from the system. This final response and data would be sent back to the Content Management System for display to the user.
 

Create XML markup

 Once the architecture is designed, one can construct sample XML markup for each component's communication. This will aid in constructing the DTD or schema later. It is important to markup the XML first so that it is very clear what the actual data needs of the system are. Very often, a DTD is created that didn't take into account the true data needs and validating the XML can be quite a chore.
 Below is a sample of XML markup. This markup is passed to the Tax Processor in our example. Of particular interest is the Requestelement . This is used to communicate to the Request Broker what type of processing is going to happen. The sample below is referred to as the Request object. The Request object below would be passed from the Content Management System into the Request Broker for processing by the Tax Processor.
 
<Request id="12345" sourceId="Content Management System"
operation="processTax" dateTime="20001105T09:15:00301"> <Order
store="beyond.com" type="external" date="20001105T08:15:00301"
orderNumber="8939393"> <Contact> <Identity>
<Firstname>Kristie</Firstname>
<Surname>Hooker</Surname>
<Email>kristieh@beyond.com</Email>
<Phone>4085551212</Phone> </Identity> <Address
type="ship"> <AddrLine>322 Mockingbird Lane</AddrLine>
<City>Santa Clara</City> <State>CA</State>
<Postalcode>95054</Postalcode> <Country>USA</Country>
</Address> </Contact> <Item line="1" quantity="1">
<Price><Money currency="usd">43.95</Money></Price>
</Item> </Order> </Request>
 For this example, we would also need a Response object for when the tax call came back. XML would be used to pass information back to the Content Management System as well as to populate the Data Storage.
 

Parse the data

 A necessary step, which allows the XML markup to communicate with your system is to parse the XML into a format that your programming language can understand.
 The following are some parsers available.
 
  • Expat for C++ - http://www.jclark.com/xml/expat.html
  •  
  • SUN Java Parser - http://java.sun.com/xml/
  •  
  • XML:: Parser for Perl - http://www.perl.com/reference/query.cgi?xml
  •  

    Validate the data

     A very important concept in generating XML is to be able to validate that the markup adheres to the data model. The tool that is most commonly used to validate the XML is a DTD. There are many industry DTDs out there. You could choose to incorporate an existing standard or create your own. There are two types of XML markup--valid and well formed. Valid means that the data structures are in accordance to the DTD and well formed means that the markup is syntactically correct. Since XML is a standard and mapping into another version of XML is also standard, the best markup is the one that fits your application.
     Here is a brief discussion on some of some of the more popular standards out there and where to find more information.
     
  • RosettaNet - http://www.rosettanet.org
    A consortium of companies centered on the computer industry focused on totally automating the supply chain. Some of the key players are IBM, Compaq, Dell, Intel, Ingram Micro, Microsoft, etc.
  •  
  • cXML - http://www.cxml.org
    A simple, XML-based protocol for exchanging B2B eCommerce transactions over the Internet. Their focus is on purchasing/procurement message structures.
  •  
  • BizTalk - http://www.biztalk.org
    An industry initiative started by Microsoft and supported by a wide range of organizations, from technology vendors like SAP and CommerceOne to technology users like Boeing and BP/Amoco. BizTalk is not a standards body. Instead, they are a community of standards users, with the goal of driving the rapid, consistent adoption of XML to enable electronic commerce and application integration.
  •  
  • ebXML- http://www.ebxml.org
    This standard is currently being developed. Their goal is to provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties.
  •  The decision to validate your XML markup is an important one. Validation ensures that the markup conforms to the DTD and can prevent incorrect data from entering your system. This is especially important when dealing with XML from 3rd party vendors. Not all parsers, however, contain the ability to validate. Be sure to check that the parser you implement can perform validation if you have decided to validate. If you have strict control over the XML markup within your application, you might want to skip validation especially when performance or scalability is an issue.
     

    Transform XML for partner interchange

     Many 3rd party systems are already supporting the XML standard and many more are soon to follow. This makes interchanging data quite simple. If you've built your system to speak XML, then to talk to an outside party, one simply needs to transform the XML into their format. This can include into any other form of XML, HTML or SGML, as well as other type of markup including EDI, SCMP, etc.
     XSLT 
     
    One such transformation standard isXSLT . This is used to transform the data by using a stylesheet which describes the mapping. For more information on XSLT specifications please consult http://www.w3.org/TR/xslt .
     

    Conclusion

     The new standard for interchange is XML. While many XML markup standards are emerging, there still isn't one with everything that you need to run an eCommerce business and interchange with all partners. As long as your system can communicate in XML, translating into other formats of XML is easy. This enables one to create their own internal XML standard.
     Creating your own markup requires a complete understanding of exactly how the data is structured for the given application. As long as each component communicates the same way, systems can be easily interchanged and sourced by 3rd party vendors. This is very relevant in eCommerce as many of the components are hosted externally. XML is the new standard of choice for the eCommerce industry for Enterprise Application Integration.

    Using XML effectively in eBusiness architectures   Table of contents   Indexes   Information and Content Exchange (ICE) Reference Version