لطفا منتظر باشید ...
Chapter 16: Developing an XML Gateway Application with SOAP and AQ
While XML generally has become the language of choice for e-business, many companies have not adopted it, typically because they perceive that adding this functionality to currently working applications is difficult. Many applications still depend on manually keying in data, such as a purchase order (PO), and businesses neither want nor can afford to have two entirely different applications to perform the same function differing only in their input methods. Additionally, many companies have brick-and-mortar stores and simply want to extend their presence by plugging in the Internet application into exiting applications. In this chapter, you will build an application that provides this functionality by leveraging the Oracle XDK, Oracle Streams Advanced Queuing (AQ), and Oracle XML Database 10g.
Designing the Framework
For the example scenario in this chapter, assume that you work for a widget business that has a perfectly satisfactory order-entry application. This application works as follows: When a clerk receives a PO via mail or the phone, the clerk types the information into a form provided by the order-entry application, which in turn creates a database entry for each PO. This application has been working fine for years and the company has no interest in rewriting it or deploying a new one; however, it does want to begin using the Internet to accept orders.This company has several requirements that this new functionality must satisfy. First, the company does business with a wide range of companies and organizations, including the government, but is not big enough to require customers to use a particular format for the PO. The information the company needs to capture is quite simple: the customer’s Bill To Address, Ship To Address, and Items ordered. Optionally, a customer can specify which carrier to use to deliver the order. In the past, the widget company’s clerks extracted this information from a variety of POs, but now this must be handled electronically. Therefore, the application has to be able to extract information from POs in various schemas. Second, the requisite confirmations, notifications, etc., need to be generated and sent electronically.To implement this application, you will be using a little-known but very useful and robust feature of the Oracle database called Oracle Streams Advanced Queuing(AQ). This feature, which was developed to implement replication, provides a rich and secure messaging infrastructure to connect the database to the outside world. AQ is capable of natively understanding SOAP messages, as discussed in Chapter 6, and you will be using that capability in this chapter. You will also be using new interfaces within the Oracle XDK XML Schema processor.
A Conventional Solution
A conventional way to design this application would be to have companies supply an XML schema for their POs when they open an account. Each company’s XML schema would then be used to validate the POs received from that company via SOAP messages. Once validated, the PO would then need to be transformed into an XML document that is compliant with your database schema, before the data could be inserted into database tables. This would involve designing an XSL stylesheet that is specific to each PO type, which would then be applied to a DOM of the PO.The conventional approach presents a number of issues. First, it involves creating a stylesheet for every PO type and updating those stylesheets whenever there are changes. Secondly, XSLT requires building DOM for the entire PO, which can be expensive because it generally requires up to ten times the memory of the original PO text file. Finally, for every PO, your application must load and parse its schema to validate it, and then load and parse its stylesheet to transform it. These operations take both time and memory, thus degrading performance and scalability.
You may be wondering why you cannot use the native capability of the XML database to register these PO schemas and directly insert them into the database. There are several reasons why you can’t:
You need to use the existing database schema, because that application still needs to work. Registering a PO schema would create a new database schema that would be difficult to integrate into the old one.
There is also the problem of dealing with any changes in companies’ XML schemas over time. Your company is not big enough to dictate which schema customers must use.
You are going to need to process POs from a variety of customers and companies; this would mean registering PO schemas for each, which would quickly become a nightmare for the DBA.
A Stream-Based One-Step Solution
The previous, conventional solution focused first on the input XML and then on defining an approach to transform it into a compatible database format. An alternative is to start with the XML requirements for your database schema and build the system from there. First, you know which information you need from each PO for your application to work. Any other information in the PO is not useful, as it cannot be consumed by your application. Therefore, validating the entire PO is unnecessary and may actually cause you to reject a PO that has an error in a portion that you don’t even use. Instead, your design needs to validate only the data that your application requires. It also needs to extract only the needed data. This can be done in one processing step by using Oracle XDK 10g.Figure 16-1 shows the process flow of the application. First, note that it uses SAX-based processing, thus eliminating expensive DOM construction. Second, only the XML Schema processor is employed. This processor is unique in its ability to perform XML Schema validation using SAX and expose the status of its validator through APIs. When an XML document is validated, the processor starts validating once it finds a type that is included in the XML schema, and can ignore parts it knows nothing about. What makes this design effective is that the XML schema is not simply the one associated with the submitted PO. Instead, it is a master schema that includes only those types you are interested in, but from every customer and company you do business with. Therefore, you need to load and parse only one schema at initialization time, with every type being a very quick hash table lookup.
Figure 16-1: Stream-based XML processing solution
Now that your application can do very efficient streaming validation, you need to handle the transformation into your database schema–compatible format. This can be done by communicating with the processor during validation and adding annotations to the schema types to indicate the necessary transformation. As the gateway processor gets events from its SAX handler, it queries the schema processor to find out whether validation has started. If it hasn’t started, the parsed content is just skipped. If it has, it buffers the content from the type until it receives a successful validation response after the last element of the type. It then queries the schema processor for the type annotation that tells it the type of transformation it needs to perform to make the type acceptable to the database. Finally, it marks off that type from its list of required types for a complete PO. Once all types are satisfied, the document is inserted into your database for further processing.
Interfacing to the Internet
Now that you know how the processing is done, you need to be able to receive and send messages using the Internet. To do this, you will use AQ’s capability to receive and unpack SOAP messages, send confirmations, perform workflow within its message queue, and send e-mail responses. Figure 16-2 shows the entire system.
Figure 16-2: PO messaging gateway architecture
SOAP messages that contain POs are sent across the Internet to your company, where they pass through the firewall and are received by the AQ servlet that unwraps the PO and places it in its queue. Once a PO is received, it triggers the validation and gateway process that either rejects or transforms and inserts the data. For this deployment, you will be using Oracle JVM, which is a Java VM that runs within the Oracle database. This application easily could be built to run in the middle tier by using the XDK’s SOAP implementation and inserting data using JDBC.
It is important to note that this design satisfies the requirement to maintain the existing database schema and application while providing a high-performance and scalable Internet gateway. Thus, your company can painlessly expand its business to a whole new range of customers.
