Implementing an XML API for an n-tier eCommerce application
Kristie Hooker
Find

Abstract
No abstract was provided for this paper.

Contents
  1. Abstract
  2. Introduction
  3. Vocabulary
  4. Why should I use XML to communicate across the tiers of my application?
    1. Markup can be customized to fit the application
    2. Application/vendor independence
    3. It's a standard!
  5. How can I implement XML in my system?
    1. Identify your system
    2. Create XML markup
    3. Parse the data
    4. Validate the data
    5. Transform XML for partner interchange
  6. Conclusion
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 for n-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.
Previous Previous Table of Contents
Introduction
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 a DTD. 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.
Previous Previous Table of Contents
Vocabulary
The times are changing quickly and new vocabulary emerges each day. An example of this is the word API - -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 rather EAI. In this paper, the emphasis is on using XML to facilitate the EAI, which has a new term associated with it called XAI. Please consult the following definitions for the latest industry standard meanings to familiarize yourself with the terms before reading this paper.
API - Application Programming InterfaceThe 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-tierAn 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.
eCommerceThe 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 IntegrationThe 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 IntegrationEAI accomplished by using the XML standard.
DTD - Document Type DefinitionA 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.
SchemaAn 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.
Previous Previous Table of Contents
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.
Previous Previous Table of Contents
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 central Request 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 a Parser/Validator as well as a Mapper 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 Request element. 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.
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.
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.
One such transformation standard is XSLT. 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.
Previous Previous Table of Contents
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.
Previous Previous Table of Contents