XML

Identifying Information for a Schema

Once you have made the decision to use XML, you will need to decide how to build your schemas. It is likely that you will be using XML to upgrade your current systems and to build new ones. The first step in using XML for these systems is identifying the type of information that is being moved throughout the corporation and what information is being moved across system boundaries.

The best way to begin identifying information is by looking at the forms that are currently being used or that will be used to input and review information. These forms contain fields that represent all the information required to complete a task. If you use Unified modeling language (UML) use cases (a text description of a task that uses a predefined format) to design a system, each use case will represent a task and define the information required to complete that task in business rules. As you look through the forms that exist in the corporation, try to identify general information structures. For example, you might find that a core set of information is used to define a customer throughout the corporation. Based on this core set of information, a base customer schema is created to define customer information. If other applications require additional information, namespaces can be used to include the base customer schema in another schema with the additional information.

Most corporations have generated large quantities of documentation about workflow and batch process. This documentation can be used to identify the information that is being moved through the corporation. Be aware of the fact that processes are often extended, producing two or more similar processes. These extensions are usually the result of new requirements or new systems that perform functions similar to those of existing systems. As time goes on and more and more extensions develop, the batch processes become huge and extremely redundant. Try to find the common elements in the batch processes and build schemas that bring together common elements and simplify the business event model.

The business event model represents the flow of events, from the beginning to the end, for a business process. It is a tool that helps you define your system and the information flowing through the system, but remember that it is only a tool. Modeling the system should be done only to the extent that it helps you understand the system, the information in the system, and the flow of information through the system. Developing a business event model that does this should not take a great deal of time. If you find that a large quantity of resources is being dumped into modeling and nothing is being built, the model has taken on a life of its own and has gone beyond its usefulness. It's often best to start by modeling small parts of your system.

Summary

BizTalk Framework 2.0 provides a means to move information contained in a SOAP document across boundaries. BizTalk document elements are wrapped in BizTags. Each BizTalk document must use the appropriate BizTags in the SOAP Header section and contain the structured business transaction information in the SOAP Body section. The BizTalk message can be defined and validated using schemas. You can use the BizTalk message to create a loosely coupled message that can be sent across any boundary.

Currently, only the Microsoft XML parser can properly validate BizTalk schemas. It is likely that when the W3C schema is complete, all the major software companies will add the capability to validate XML documents with schemas. When this happens, the BizTalk format will provide the capability to move information across boundaries to and from any software platform.