By itself, XML is a simple syntax for exchanging data and text-oriented documents, but successful business communication involves more than just a lingua franca. Electronic commerce requires shared models of the underlying domain semantics, business processes and policies. These models are the very essence of business-to-business (B2B) integration. A model may be embedded in the code of an application program that processes the XML documents, or made explicit in the definition of the model's concepts, relationships and constraints.

This is the first in a series of articles in which I'll cover three aspects of modeling e-business applications:

(1) Processes and communication policies. B2B interactions are not limited to sending a single message, but require a coordinated sequence of the business partners' activities and expectations.

(2)Business vocabularies. Each message contains information that may be concise or convoluted. Such content documents are defined by a vocabulary that is shared by the parties engaged in the communication.

(3) Web service components. The techniques for applying component-based design to Web services are still emerging, but I'll share some early thoughts about their impact on future development.

XML documents are increasingly used to represent and exchange both process and content information when deploying these applications. Process information includes the messaging infrastructure and workflow control that guide the process execution. Many B2B processes are asynchronous and long running, so the XML-based message header information identifies the parties, process and purpose of the message. Business vocabularies define the heart of the message: its content. For our purposes, I'll use a product catalog as an example content vocabulary. The catalog data is exchanged in messages between business partners when aggregating catalogs from multiple suppliers, or when responding to queries for product specification data. The same catalog content is also transformed into HTML for presentation in customer portals.

But an XML application is much more than structured data—it's part of a broader system that includes both architectural and process requirements. Most e-business applications include requirements from both business and technical stakeholders that are distributed across an inter-enterprise system. Developers of these systems benefit from visual models and a process that encourages active communication. Let's face it—the business world revolves around graphical presentations, so any XML specification diagram is a great help.

In these articles, I'll attempt to walk the middle ground shared by three diverse groups of developers. The first consists of companies that have embraced the Unified Modeling Language (UML) and the Rational Unified Process (RUP) as a foundation for software development, including XML applications. The second comprises those developers seeking lightweight processes—such as agile modeling or extreme programming—but still interested in using UML for well-defined goals. The third group consists of XML application developers who are skeptical about the value provided by any graphical modeling tool or technique, including UML.

I'll gravitate toward an agile modeling process that can be included within a more structured methodology, like RUP, or applied independently for quick results when designing an XML schema or set of Web service messages and workflow processes.

XML in UML Analysis and Design

If we gain a deep understanding of the conceptual models that define e-business processes and related information content, we can transform these logical models into alternative implementation languages, and reverse engineer the implementations into logical models. In my recent work, I've found it helpful to think in terms of model transformation instead of code generation, because implementation languages are also based on their own metamodel definitions. The Unified Modeling Language is a standard representation and graphical notation for describing these shared models. The important point is that we must think about the information content model without getting caught up in the details of implementation syntax.

Conceptual models of XML applications also improve communication with business stakeholders who are unfamiliar with the increasingly complex grammars of new XML schema and Web service definition languages. Whereas the DTD schema standard is easy to learn, the W3C XML Schema offers many more design alternatives, and the growing array of Web service specifications such as SOAP, WSDL and WSFL present further challenges. However, as in database systems, successful deployment of XML in large distributed systems depends on critical design decisions. UML profiles are used to describe these design choices when customizing the UML models for XML schemas and Web services.

But there are also several hundred preexisting XML schemas created by companies and industry consortiums, and the future world of Web services will yield a similar set of competing process and Web service interface specifications. Later in this series, I'll examine various approaches for reverse engineering XML schemas into UML, where they can be leveraged as part of complete e-business system analyses. XML fulfills only one part of any successful e-business application.

E-business integration must support the following general requirements:

(1) Actors agree on message content vocabularies, not APIs.

(2) Documents are validated against a known vocabulary, but should allow for extensions.

(3) Message content can be transformed from one vocabulary to another.

(4) Workflow processes and communication protocols are defined for document exchange.

(5) Legacy system adapters import and export XML.

E-business integration requirements are divided into three categories: shared business vocabularies, process workflow and messaging, and application integration. The use cases corresponding to these requirements are illustrated with a UML use case diagram in the figure above, in which the three categories are differentiated using shaded icons.

E-business Integration With XML

This high-level use case diagram includes three groups of typical XML requirements: vocabulary definition (clear), process modeling (light gray) and system integration (dark gray). (From D. Carlson's Modeling XML Applications with UML, p. 53 [Addison-Wesley, 2001].)

Four of the use cases depicted in the E-business Integration With XML diagram are related to the design of shared business vocabularies and schemas; they're illustrated with no shading in the diagram. The business analyst is responsible for defining one or more business vocabularies that are then used by the system integration specialist. The XML schemas are generated from the vocabulary definition, and are used as the basis for transforming and validating XML message contents. Because the XML schemas are automatically generated from the UML model, that use case doesn't show a direct interaction with an actor.

The light-gray use cases are all related to process workflow and messaging. When coordinating the activities of business partners in a B2B application, shared process definitions are as important as shared vocabularies. The business process definition describes how and when business documents (based on the shared vocabularies) are exchanged, and the workflow model automates those processes by assigning activities to workers. Message protocols define agreements used to control conversation between two or more agents.