Any cursory glance at a search engine tells you an XML dialect or framework exists for just about every type of business or system on the planet. In order to choose a fitting repository or dialect, you need to model your business or system processes. You may decide that your business largely counts on support for transactions and a reliable communications protocol. Choosing a dialect (or even inventing your own) requires development and enforcement of DTDs or Schema. Additionally, an understanding of the underlying XML technologies to support these activities is warranted. Often, when transferring a human-intensive business process to electronic form, you need to look at the workflow and then determine appropriate integration steps to mimic the process electronically. If there are any analytical or business logic steps involved, you need to incorporate those into the electronic version as well.

Designing a workflow may involve citing a primary objective (such as “complete sales transaction”), which can in turn involve many additional individual steps (“receive purchase order,” “bill customer,” “ship product,” etc.) that can have their own conditional outcomes (“no inventory,” “invalid account number,” etc.). It’s the goal of a system’s architect to integrate the correct components to ensure the desired outcome, or to handle any of the other conditions that may arise.

In small applications (or small organizations), a developer completes much of the system logic. In more complex distributed systems, you frequently find third-party consultants and expensive commercial software involved, but it still comes down to the same technology building blocks. Understanding the objectives of your system may aid in choosing the correct XML dialect and framework. Some of the choices include ebXML, BizTalk, and commercial offerings such as Commerce One’s and Ariba’s proprietary e-business languages.