The following scenario is an example of how the Java APIs for XML might be used and how they work together. Part of the richness of the Java APIs for XML is that in many cases they offer alternate ways of doing something and thus let you tailor your code to meet individual needs. This section will point out some instances in which an alternate API could have been used and will also give the reasons why one API or the other might be a better choice.
Suppose that the owner of a chain of coffee houses, called The Coffee Break, wants to expand the line of coffees that he sells. He instructs his business manager to find some new coffee suppliers, get their wholesale prices, and then arrange for orders to be placed as the need arises. The Coffee Break can analyze the prices and decide which new coffees it wants to carry and which companies it wants to buy them from. The business manager assigns the task to the company's software engineer, who decides that the best way to locate new coffee suppliers is to search a Universal Description, Discovery, and Integration (UDDI) registry, where The Coffee Break has already registered itself.
The engineer uses JAXR to send a query searching for wholesale coffee suppliers. JAXR sends messages using JAXM in the background, which ensures that the registry will be able to receive and understand it.
The UDDI registry will receive the query and apply the search criteria transmitted in the JAXR code to the information it has about the organizations registered with it. When the search is completed, the registry will send back information on how to contact the wholesale coffee distributors that met the specified criteria.
The engineer's next step is to draft a request for price lists and send it to each of the coffee distributors using JAXM. She writes an application that gets a connection to the company's messaging service so that she can send the requests. She then creates a JAXM message, adds the request, and sends it.
Each coffee distributor receives the request, and before sending out current prices, checks with its stock quote service using JAX-RPC to get the latest quotes for the relevant coffee futures. Based on the figures they get back, the distributors send The Coffee Break their newly revised prices in an XML price sheet. The vendors use an agreed upon XML schema for their price sheets because that way they can use a format that is convenient for them and that their buyers can process easily.
Compare Prices and Order Coffees
The engineer processes the price lists using SAX. After her application gets the prices quoted by the different vendors, it compares them and displays the results.
When the owner and business manager decide which suppliers to do business with, based on the engineer's price comparisons, they are ready to send orders to the suppliers. The orders are sent via JAXM, and each supplier will acknowledge receipt of the order via JAXM.
Selling Coffees on the Internet
Meanwhile, The Coffee Break has been preparing for its expanded coffee line. It will need to publish a new price list/order form in HTML for its Web site. But before that can be done, the company needs to determine what prices it will charge. The engineer writes an application that will multiply each price by 125 percent to arrive at the price that The Coffee Break will charge. With a few modifications, the list of retail prices will become the online order form.
The engineer uses JavaServer Pages (JSP) technology to create an HTML order form that customers can use to order coffee online. From the JSP page, she uses SAX to access the name and the price of each coffee, and then she inserts them into an HTML table on the JSP page. The customer enters the quantity of each coffee he or she wants to order and clicks the Submit button to send the order.
Although this scenario is simplified for the sake of brevity, it illustrates how pervasive XML technologies are becoming in the world of Web services. And now, with the Java APIs for XML and the J2EE platform, it keeps getting easier to implement Web services and to write applications that are the consumers of Web services.