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:
- 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.
- 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.
- 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:
- Actors agree on message content vocabularies, not APIs.
- Documents are validated against a known vocabulary, but should allow for extensions.
- Message content can be transformed from one vocabulary to another.
- Workflow processes and communication protocols are defined for document exchange.
- 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 [click for larger image] 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.
The dark-gray use cases represent requirements for application integration. The creation of application classes can often be automated based on either the vocabulary definition or the XML schema. The details of legacy system adapter creation vary widely and are determined by platform, architecture, middleware, vendor APIs and so on. At this high-level view, the System Integration Specialist is responsible for ensuring that these adapters are able to import and export XML messages conforming to the required schemas and are compatible with the message protocols used by the workflow.
When reviewing the overall use case diagram, notice that all requirements depend on the "Define Business Vocabulary" use case. In application environments in which the XML vocabulary is provided by an outside entity, development activities are driven by that definition.
XML Vocabulary Development Process
A vocabulary definition is the heart and soul of an XML application, but there's
no single right way to create it. What's more, many applications share parts
of larger XML vocabulary definitions without requiring the entire schema. This
modularity of XML vocabulary design—implemented via the XML namespace standard—is
essential for enabling reuse across a range of applications, just as good object-oriented
design is essential for enabling class and component reuse. When XML vocabularies
are designed using UML class, package and component diagrams, it becomes much
easier to apply similar concepts of reuse to both XML and object technology.
Commerce One's XML Common Business Library (xCBL), designed to support B2B e-commerce (www.xcbl.org), provides a good example of an XML vocabulary. Like many contemporary XML schemas, the xCBL vocabulary is defined using one very large namespace of elements. (This is because many schemas were developed prior to completion of the XML namespace standard and its support in development tools.) The modularity of its components is not explicit, but is informally (and incompletely) annotated with comments in the schema file. There is, however, a set of core element definitions that are reused in several other message types; for example, Catalog, Trading Partner, Auction, Order and Invoice.
I have reverse engineered several modules from the xCBL 3.0 schema into UML class diagrams, which are now used by the OASIS Universal Business Language (UBL) technical committee (http://oasis-open.org/committees/ubl) to assist review and redesign of the xCBL XML vocabulary as part of an open standards process. One of the primary goals of this redesign effort is to specify the vocabulary as part of the emerging ebXML core components library (http://www.ebxml.org).
The class diagram entitled XML Vocabulary Model From xCBL Schema (below) represents a very small subset of xCBL, showing several identification elements from the core module and their use within the TradingPartnerOrganizationHeader element. The header also includes other elements not shown here. I wrote an automated transformation from the SOX schema language used by xCBL to an XMI document conforming to UML 1.3, which I then imported into Rational Rose.
XML Vocabulary Model From xCBL Schema This very small subset of xCBL shows a reusable Identifier model and its use in the TradingPartnerOrganizationHeader element definition. |
As part of this reverse engineering, I gave careful attention to producing a UML model that emphasizes a platform-independent information model of this domain. This approach is aligned with the Model Driven Architecture initiative of the OMG (http://www.omg.org/mda), in which UML profiles or other model transformations are used to produce several alternative platform-specific models for implementation. For example, this one model might be used to generate both Java EJB and Microsoft.NET application classes, in addition to the XML schemas used for B2B exchange or application integration.
Designing Applications With XML
Many developers, myself included, are skeptical of the claim that you can fully
generate complete business applications from UML models. Although this is an
intriguing long-term goal, I'm not aware of any modeling tools that make it
practical today (see "Executable Models
are Inevitable," Sept. 2001). Modeling and generating the business
logic and algorithms of execution are frequently the most difficult tasks, and
it's often easier and faster to just write the code in Java or other implementation
languages. UML is, however, very useful when modeling and generating the class
structures and EJB or .NET framework implementation.
When it comes to XML schemas, I find that automatically generating them from UML is quite practical, as the schema describes static data structure and constraints, not fine-grained application logic. This object-oriented approach to schema design is new for some XML developers, who are accustomed to thinking about hierarchical grammars. Object-oriented models may not be a good fit for some text-oriented XML grammars, but, in most cases, I've found the mapping to be straightforward.
An additional benefit of automated schema generation is that it's relatively easy to apply a consistent set of best practices and schema design guidelines. The recently standardized W3C XML Schema language (www.w3.org/XML/Schema) includes many alternative representations, some of which are easy to misapply. Tricky areas include the use of global or local element declarations, single-inheritance extension and restriction, and XML attributes or child elements. There are also stylistic choices concerning when, or if, anonymous complex type declarations should be used. Many organizations and standards groups are creating specific guidelines on designing and writing their XML schemas. See, for example, design guidelines created by the OASIS Universal Business Language (UBL) committee at http://oasis-open.org/committees/ubl/ndrsc/.
One relevant standard that should contribute to these design guidelines is the OMG's XML Meta-data Interchange (XMI) specification. Many developers are familiar with XMI as the interchange format for UML models, but the specification is much more general. Although its name suggests that XMI is applicable only to meta-data, this specification includes production rules that can map almost any UML class model to a DTD or W3C XML Schema, which can be used to validate XML documents containing serialized object instances.
Another new, but untested opportunity lies in using UML to model the business processes that are an integral part of many Web service applications. UML activity diagrams are a good match for these process models, but this task is often performed by a business analyst via graphical development tools, such as the business process orchestration tool provided by Microsoft's BizTalk Server. The challenge for UML tool vendors is to make activity modeling available without intimidating new users unfamiliar with the language's finer points and its nine diagram types. Special-purpose tools should be based on standard UML and share a common model repository with general-purpose modeling tools such as Rational Rose or TogetherSoft. I've created a Web portal, at http://XMLmodeling.com, that focuses on the topics introduced here. It includes case-study white papers about creating UML models for several widely used XML schemas, such as UDDI and XHTML, and many links to related products and open source tools. I also provide a Web-based tool for generating XML schemas from UML models that have been exported to the standard XMI interchange format.
In order to help you apply these ideas to your own e-business projects, I offer these tips for success:
- Contrary to popular belief, thoughtful analysis doesn't mean slow development.
- UML is a large and sometimes complex language; use only what you need and ignore the rest.
- Create a common UML model that drives both the XML schema definition and other non-XML system components. Many systems use XML in a subset of their components, but the analysis must be done holistically.
- Define the conceptual model of your XML vocabulary before, or in parallel with, its implementation in the XML schema.
|
References
|
