Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Analysis
The obvious question to ask in this phase is "What do you want the application to do?" An equally important but sometimes neglected question is "What are the constraints?" You need to deal with both.
Beyond the broad requirement that the application must produce or consume XML, the first step in this phase is to determine the overall business or system process involved and the specific data to be processed. If the purpose of XML-enablement is to integrate the application with another in-house application, the data requirements are probably specific and fixed. On the other hand, if you need to enable an application to process XML for electronic commerce involving a number of different trading partners, the data requirements may not be so obvious. Despite years of efforts toward normalization, different organizations in the same industry routinely use different sets of data items for the same business transaction. The differences may be slight or great, but you need to be prepared to accommodate them all. There are two good rules for such situations:
Put every data item that a trading partner might ever want into the XML documents you're producing.
In the XML documents you're consuming, be prepared to process any data item that a trading partner might send you.
The next step is to identify the schema or schemas that will be involved. These will almost certainly be written in the W3C's XML Schema language. Similar to the first step, if you're being asked to integrate with another in-house application, you'll probably be using the schemas associated with that application. Again, electronic commerce situations probably won't be so cut-and-dried, as different trading partners may be using entirely different schemas. To handle this situation, you need to address both analysis and design considerations. The most expedient approach probably is to create your own generic schema for the data directly produced or consumed by your application, and to build in a facility to perform XSL transformations to and from the formats used by your various trading partners.
The last step of this phase, determining your constraints, has a direct effect on design. Beyond the routine constraints of time and budget for the project, you need to consider a wide range of issues. The list below is by no means exhaustive, but it covers some of the major issues frequently encountered:
Nature of the interface. Is a real-time interface, perhaps based on SOAP, required for web services enablement? Or is this a more traditional batch interface for electronic commerce documents, such as invoices, that are not very time-critical?
Whether, where, and when to validate. In situations where you have a great degree of control over the systems, such as in-house integration, the XML documents being produced and consumed may be so predictable and reliable that schema validation is merely an unnecessary drag on performance. However, in electronic commerce situations, your organization's policy (or that of your trading partners) may require rejecting documents that don't comply with their schemas. Yet, even if your application offers a facility for putting problem documents "in suspense" for human review and correction of errors, you may want to perform schema validation as a way to identify and flag problem documents.
Document size. As computer systems progressively get more memory and faster CPUs, document size becomes less of an issue, but it's still a consideration. Relatively small documents can be handled by all the popular XML parsers, while huge documents may be a problem for some of them.
Portability. Again, this may affect your choice of API. If you develop for a single operating system or don't mind being tied to one vendor, this is probably not a consideration. However, if you develop for multiple, somewhat disparate platforms, you probably want to choose an XML parser API that runs on all of them. Even the W3C Document Object Model (DOM) isn't completely generic, and dealing with two different implementations will cost you more effort than dealing with just one.
Let's examine how these constraints affect your design decisions.