Architecture

So far, most chapters have included a UML model of the application under development. However, in this chapter, the application consists of two servlets, several style sheets, and one HTML page, so a class diagram is not helpful. Figure 7.3 illustrates the various pieces and their relationships.

Figure 7.3. The various components of the e-commerce application.

The tree applications are as follows :

• Post ”A servlet to accept XML documents, such as orders and invoices. You can think of it as an XML shopping cart.

• Ship ”A servlet to prepare invoices, after the goods have been shipped.

• EditOrder ”An JavaScript application to create orders.

XML Modeling

The main challenge when building an e-commerce solution with XML is not programming but the creation of good, stable, and complete data models. The programming is straightforward.

The challenge is that you're modeling documents to use within and outside your organization. This impacts modeling in the following ways:

• The model must be well thought-out to cover the needs of all the parties.

• The model must be thoroughly documented because it will be widely distributed.

Let's look at the first requirement: the need to account for third-party needs. When modeling documents for internal applications, you are concerned with only your own business. If your business needs a tag, you add it. Conversely, if you never use certain tags, you toss them.

This, however, is not true with e-commerce. The documents must account for your needs as well as the needs of your customers or suppliers.

Let's look at an example: In the textile industry, vendors use sizes (such as small, medium, and large T-shirts). Their orders, invoices, packing lists, catalogs, and other documents include size information. Therefore, they need a <Size> tag. However, this need is specific to the textile industry.

If yours is a pharmaceutical company, you typically wouldn't include a <Size> tag in your document. But what happens when you order gloves for the lab?

Likewise, requirements vary in an international context. The address is a good example ”U.S. addresses include a state (or province in Canada). There's no such thing in many other countries .

When we turn to the second requirement, documentation, we hit a very costly, and often underestimated, issue. The ultimate purpose of this exercise is to communicate. When you adopt an XML model, you want your partners (customers and suppliers) to understand it.

The alternatives are either to offer expensive support in the form of corporate training and assistance to development or to develop top- notch documentation. Although developing quality documentation is expensive, it is cheaper in the long run.

To save themselves some work, many organizations turn to existing models developed by standard bodies or vendors. Oasis runs a repository of XML models, available online from http://xml.org. A quick search for invoices turns up a dozen hits by the likes of Commerce One, http://cXML.org, IBM, and Visa.

If you nevertheless decide to model your own documents, be sure your team includes experienced modelers, preferably with experience modeling open systems, and technical writers.

I also recommend working in a high-level modeling language, such as UML. UML models buy you a certain level of independence from XML. It makes it easier to design and maintain the documents.

Furthermore, UML was designed for communication. It is a universal language readily understood by all developers. It won't save you from serious technical writing, but it will reduce the effort.

In this chapter, we'll use simplified models for the order and invoice. In UML, they look similar to Figures 7.4 and 7.5. Listing 7.1 is a sample order. As you can see, there's nothing fancy here: just a list of products.

Warning

You will notice that this order differs from the order introduced in Chapter 6, "Import from Any Format." That order was modeled after the EDIFACT order. The order in this chapter was modeled independently and aims to be as simple as possible. In practice, as discussed in the next section, you will find that you must deal with different documents.

Figure 7.4. A model for a simple purchase order.

Figure 7.5. A model for a simple invoice.

Listing 7.1 A Simple Purchase Order in XML

 <?xml version="1.0"?><Order>    <Date>2000-03-31</Date>    <Reference>AGL153</Reference>    <Buyer>       <Name>Playfield Books</Name>       <Address>          <Street>34 Fountain Square Plaza</Street>          <Locality>Cincinnati</Locality>          <PostalCode>45202</PostalCode>          <Region>OH</Region>          <Country>US</Country>       </Address>    </Buyer>    <Seller>       <Name>QUE</Name>       <Address>          <Street>201 West 103RD Street</Street>          <Locality>Indianapolis</Locality>          <PostalCode>46290</PostalCode>          <Region>IN</Region>          <Country>US</Country>       </Address>    </Seller>    <Lines>       <Product>          <Description>XML by Example</Description>          <Quantity>5</Quantity>          <Price>24.99</Price>          <Total>124.95</Total>       </Product>       <Product>          <Description>Applied XML Solutions</Description>          <Quantity>10</Quantity>          <Price>44.99</Price>          <Total>449.90</Total>       </Product>    </Lines>    <Total>574.85</Total> </Order>