ery shortly after completing step 1 of any development projectgetting the code workinggood software developers will stop to consider the lifespan of the code. They understand that the effort put into the code needs to directly correspond to its anticipated lifespan. Take for example software written as a proof of concept in a pre-sales engagement. All pre-sales engagements have some risk associated with them because the potential client may not go through with the sale, which means the code may not be used at all. In this case, the code is almost certain to have a very short lifespan, so the developer can stop at step 1.
However, code developed for production use needs to go well beyond step 1. The next step is making the code understandable to others who will support and enhance it for years to come. This is a very important step for the following three reasons:
- You may not be available to support and enhance the code.
- You may be in a large software development team, many of whom need to understand and enhance the code as well.
- You may forget what you coded months or years ago.
Using a challenging multithreaded XML schema validation as an example, this article demonstrates how you can easily employ software development practices to make your software more understandable to other developers and to remind yourself quickly of what you did months or years ago.
The Program: Multithreaded XML Schema Validation
Developers often need to validate XML documents sent from a third-party system before processing them in their own systems. The system that produces the XML may have defects in its XML exports that may make it difficult for the receiving system to process that XML. You can avoid creating a great deal of error-handling code in your XML parsing classes if you validate the input XML with a standard XML validation language. Several validation languages are available, but XSD schemas is one of the most popular and powerful. XSD schema validation is also built into the Java standard JAXP implementation.
XML validation is a CPU-intensive process that can hog multiple CPU cores and threads. So for this example you will run XML validations as background threads on a thread pool, but instead of starting the validation process from a Java command line you will write a very simple background thread that will poll a directory for XML files to process. You will start the thread by writing a start-up servlet to run inside a Java Enterprise Edition (Java EE) application server automatically when the application server is started.
The XSD schema for this example is very simple: it just verifies that each record has a set of required XML elements. You will use the following two files for the XSD schema validation (click here to download all the source code):
- Input.xmlThis XML document (see Listing 1) contains a simplified partial extraction of an insurance policy XML file from the sending system. It can have many different records in the same file, each delimited by a Record element. Each record also contains a set of required data to make sure that record is valid.
- Policy.xsdThis is an XSD schema file (see Listing 2) that validates the Input.xml file.
To enhance the XSD schema for your own purposes, you can apply much more sophisticated validations.