![]() |
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 |
Abstract |
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 |
|
|
|
|
|
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. |
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. |
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. |
A simple, XML-based protocol for exchanging B2B eCommerce transactions over the Internet. Their focus is on purchasing/procurement message structures. |
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. |
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 | ![]() | |||