In last month's e-Java we discussed the technologies and APIs offered by the Java platform that play specific roles in e-commerce solutions for the enterprise. We also took a high-level glance at how they fit in an n-tier commerce application. Java provides substantial support for e-commercebased applications; however, Java alone doesn't provide an end-to-end solution for e-commercebased businesses. Components of the Java platform integrate with complementary technologies to offer complete Internet commerce solutions.
Nowadays the acronym "XML" is found lurking in almost any literature or site that mentions e-commerce. Some consider XML (Extensible Markup Language) to be the enabling technology that will allow the World Wide Web to become a breeding ground for open commerce-based applications. XML helps expand existing technologies into new dimensions of document publishing and content management, addressing the needs of a distributed Web-based environment.
The Java platform and XML are complementary technologies that together can provide a solid foundation for commerce-based transactions across the Internet. This month in e-Java we'll look at how Java and XML can work in the world of e-commerce. Please note that this article doesn't focus on XML itself (although a brief discussion is provided in the next section) or on Java, but rather on how the two technologies provide such a powerful combination for enabling e-commerce applications.
Data Content, EDI and XML
The premise behind Internet commerce is that business transactions can be conducted efficiently and safely over different tiers of the Internet. The evolution of client/server architectures, which are an integral concept behind the Internet, has seen a migration from two-tier architectures to multitier distributed architectures. This places greater demand on the safe and correct passage of electronic data from an Internet source to the corresponding destination. The whole purpose of such commerce transactions is to transfer data content between the two parties participating in the trade.
EDI (Electronic Data Interchange) has been the enabler for electronic transactions for several years now. EDI is a process for exchanging data in an electronic format between heterogeneous applications and/or platforms in an automated fashion, i.e., without manual intervention. However, when applied to an Internet environment, it falls short on several accounts, some of which are:
HTML and XML
- Scalability across multiple tiers of the Internet
- Lack of support for dynamic data content definition
- Slow adoption to standards
- Lack of flexibility in defining business rules
XML leverages EDI technology and adds the necessary pieces to migrate it to an Internet environment. It does so by adding the following:
- Ability to separate the data and structure (electronic content) from the processes
- Ubiquitous interconnectivity between trading entities (this isn't directly provided by XML, but rather by the Internet)
- Support for dynamic data format definitions
- Middle-tier storage for caching data
- Widely accepted standards governed by the W3C (World Wide Web Consortium)
HTML is a presentation markup language that offers a standard format for displaying data in a Web browser. While it provides a standard format for displaying data, the focus is on the visual presentation of data and not on sophisticated data types, as required by e-commerce applications. XML, on the other hand, focuses on data content and provides a clear separation between content and visual presentation. It does this by allowing the applications to define tags that describe the data they're exchanging across the Internet. XML allows the tag information to be embedded in the document itself, so that the document is "self-describing." XML standards allow business partners to define their own self-describing markup languages for supporting electronic commerce.
Both HTML and XML are derivatives of SGML (Standard Generalized Markup Language). However, while HTML is an implementation of SGML for visual presentation, XML is a subset of SGML used for writing markup languages that specify the format for expressing data content. Figure 1 shows the relationship between HTML, SGML and XML.
XML + Java = Portable Objects
So how does all this relate to Java? Well, there are two main aspects of an Internet commerce application. We've taken a look at the first data format and content. XML enables electronic data to be represented in a platform and language-independent manner. This data can be available across several different enterprise domains. However, data by itself doesn't do anything. It needs to be processed by applications. For XML data to be used in a platform-independent manner across the Internet, it needs a hardware-independent environment. The Java platform provides such an environment by offering a distributed, homogeneous computing architecture that resides on the different tiers of the Internet. Java "Internet-enables" XML documents by adding networking and cross-tier transportation capabilities.
Java and XML together address the issue of portability in e-commerce, an issue that's crucial for successful implementation of Internet-enabled commerce applications. XML provides data that's portable across different application domains. It does so by representing data in a common, well-known format. Java provides code that's portable across different hardware and operating systems. The code adds the functionality for processing and manipulating the data. A natural consequence of this alliance is highly robust, componentized and maintainable applications.
The synergy between XML documents and Java code is due to the fact that the data encapsulated by XML tags can be easily expressed as Java objects and vice versa. The entities that take part in an e-commerce application are defined in an object-oriented manner as "data objects." This gives rise to "objects" that are portable across the different tiers of a distributed application. You can almost look at these as "portable objects" that morph into XML elements (defined by tags) when they need to be transported between hosts. They morph back into Java objects when they need to be processed or manipulated.
In other words, working between XML and Java involves the following steps:
The transformations between XML and Java are illustrated in Figure 2.
- Constructing a Java object model from an XML document by creating Java objects from XML tags.
- Using the Java object model to process the data. This should focus on computation-intensive tasks that need to be performed on the data to support the overall business transaction.
- Generating an XML document from the Java object model by converting the Java objects to the corresponding XML data tags.
DOM and SAX
An XML document has to be processed in order to be used. This requires an XML processor that can:
- Parse XML documents an XML parser
- Create XML documents an XML editor
- Provide an API to access the parts of an XML document
The parsers and editors may be written in Java, which makes them portable across various platforms. The real key to the XMLJava interoperability, however, is the APIs used to access the elements of an XML document. An additional advantage Java brings to XML parsers and interpreters is allowing the XML interface with the Java data processing application to be accessible via different Java components server-side Java Servlets, client-side Applets, middle-tier EJBs or JavaBeans in an IDE. Java also adds its robust security services to the mix. As mentioned earlier, Java components reside in different tiers of a distributed application.
The XML APIs are of two types:
- Document Object Model (DOM): DOM is a platform-independent, language-neutral, tree-based API. It compiles an XML document into an internal tree structure and allows an application to navigate that tree based on the API it exposes. One of the specifications of the DOM interface is in Java (the others are in OMG IDL and ECMAScript). The Java API for DOM is known as Java Language Binding and describes the Java DOM interface.
- Simple API for XML (SAX): SAX is a simple, event-based API for XML parsers. SAX doesn't require the creation of an internal tree structure to represent the complete parsed XML document. Instead, when parsing an XML document, it provides events that indicate the detection of the following: start/end of the document, Document Type Declaration (DTD), start/end of elements, element attributes, character data, unparsed entities, processing instructions and more. SAX provides a Java interface that allows any Java application to access any XML parser as long as the parser has a SAX driver.
In a transaction, XML may be used to transport data between the two partners. The data that's obtained at one end of the transaction may be processed but need not be displayed in a UI (indeed, that's the advantage of separating content from presentation).
On the other hand, one of the desirable features of Web-enabled data is the ability to view the data in a Web browser. Such data may be in the form of a catalog, a quote request/response, etc. In a simple client/server scenario, there are several ways of rendering XML data in a browser:
Of these three, the third mechanism makes use of XSL (Extensible Style Language). The other two can be achieved by Java platform components. Java Servlets can be used to process XML on the server and send the output to the client as plain HTML. XML-aware Java Applets can be used to process XML on the client. The applet can bind the required parts of the XML document into particular HTML components for display. Browsers like Microsoft's IE 4.0 support this functionality.
- Process XML into HTML on the server and send to the client browser.
- Process XML into HTML directly on the client and display on the browser.
- Display the XML document directly.
These two mechanisms for rendering XML in a Web browser are illustrated in Figure 3.
Role of XML and Java in Enterprise Application Integration
This is the year in which the Java platform APIs are really making their mark in integrating enterprise applications. Although the definition of Java's Enterprise APIs has been there for a while, they're only now achieving a level of maturity that makes them suitable in real-world enterprises. EAI is the mechanism for integrating several disjointed applications to provide a common application interface. XML allows Java objects to be represented as data that moves across middleware tiers that may not be Java-based.
Remember that XML transports data content, not behavior. The XML/EDI initiative is based on the concept of active objects that have inherent processes associated with them. These are defined by rule templates that can be supplemented by XML/EDI data manipulation agents (DataBots) to ensure that users can express their requirements in high-level, natural language. Currently, the ECMAScript subset of the Java programming language provides the vehicle that permits the DataBots to be deployed and received along with XML/EDI messages.
Java and XML complement each other in facilitating Internet-based e-commerce applications. However, the compatibility between such technologies, their common environments and their complementary role in designing e-commerce applications is largely because they've found a common home in the Internet. In other words, the Internet is the environment that has created the need for, and promoted the wide acceptance of, enabling technologies like Java and XML in the world of e-commerce.
About the Author
Ajit Sagar, a member of the technical staff at i2 Technologies in Dallas,Texas, holds an MS in
computer science and a BS in electrical engineering. He focuses on Web-based e-commerce applications and architectures. Ajit is a Sun certified Java programmer with nine years of programming experience, including two and a half in Java.
You can e-mail him at Ajit_Sagar@i2.com