Business Process Specifications

Standards provide an independent roadmap for developing systems, not just independent of specific vendor products, but also of the underlying technologies. One of the key objectives of ebXML is to capture trading partners ' business practices and interactions systematically, and represent them accurately and independently of any specific ways of implementing those transactions.

One of the key objectives of ebXML is to capture trading partners' business practices and interactions systematically, and represent them accurately and independently of any specific ways of implementing those transactions.

In ebXML, the business process specifications also provide the connection between business practices and their technical implementation.The specifications define the ways in which trading partners engage each other, to the point of configuring their respective systems to actually do business, at what technicians call runtime. ebXML expresses these business process specifications as XML document type definitions ( DTDs ), and later as XML schemas, or in the Unified Modeling Language (UML).[1]

Chapter 4, "The Promise of XML," discusses XML and UML in some detail, but we can provide a little background in UML here as well. A number of good modeling methods exist. Many ebXML participants recommend the approach adopted by UN/CEFACT, one of the sponsoring organizations of ebXML. This approach, called the UN/CEFACT Modeling Methodology, relies heavily on UML that represents business processes graphically and at various levels of detail. The UN/CEFACT approach, in turn , is based on the Open-EDI Reference Model, as defined in ISO standard 14662.[2]

ISO standard 14662 establishes a reference model, which means a framework for further standards work. In this case, the reference model outlines a different approach to EDI, based on business scenarios rather than the traditional EDI concept of individual transaction sets or messages. The basic scenarios cover much of the interactions between companies and, as a result, the extended period and lengthy development cycle needed to establish an e-business relationship can be reduced significantly.

One particular value of UML is its ability to represent the interactions of objects in different ways, which at a high level it calls views. ISO 14662 defines two ways of looking at the interactions among companies: a business operational view ( BOV ), and a functional service view ( FSV ). The BOV captures the business relationships among companies, while the FSV concentrates on the information technology aspects of the relationship ”service capabilities, interfaces, and protocols.[3]

The BOV focuses on high-level interactions among companies and related requirements. It covers the semantics of business data (the terminology used in an industry), as well as accepted conventions and agreements. For example, a common practice in an industry may require the manufacturer to pay for transportation; thus, a price quotation would need to include a separate line item for transportation.

An important characteristic of the BOV, at least as far as ebXML is concerned , is the collection of specific interactions into overall scenarios or processes. A scenario would cover delivery of related services or interactions to meet specific objectives, and thus would include a series of related transactions among trading partners. A purchasing scenario or process, for example, would account for the series of interactions beginning with the price quotation, and continuing through purchase order, purchase order change, and purchase order acceptance.

The functional service view addresses system interactions and requirements. It includes issues such as message syntax, naming conventions, and communications protocols. While the FSV is not unimportant in the reference model, clearly the intention of the standard is to have the BOV requirements drive the implementations expressed in the FSV.[4]

Businesspeople may legitimately ask whether the business process specifications are really necessary, especially where industries already have defined their processes and developed messages in EDI or XML vocabularies. Remember that the ebXML specifications are designed as modules. If an industry has already defined its processes, messages, and core components , businesses may be able to skip this step. However, if the industry is in a state of rapid change or needs to work with other industries with different processes, it may find the business process methods and models useful.

Modeling Requirements and Analyzing Processes

The BOV begins with the knowledge and experience companies bring to interacting with each other. In some cases, the trading partners can capture that knowledge and experience in a set of business requirements. UML employs use case descriptions and diagrams for documenting and visually representing these requirements.

Individual companies probably will not need to perform the kinds of analyses that generate the business models stored in ebXML repositories. Most of these tasks will be undertaken by industry associations or consortia that can devote the resources required.

Use cases describe the activities of one or more actors that engage the system in question, to return some value to the actors as a result of that system. Use case diagrams are visual representations of a set of business scenarios showing the relationships and interactions among the actors.[5] See Chapter 5,"The Road Toward ebXML," for more discussion and examples of use cases and use case diagrams.

Companies wanting to do business with each other rarely need to start from scratch in defining their relationships, but more often than not can rely on a base of experience already established by years of interactions, sometimes electronic (with EDI) and sometimes in hardcopy form. In some cases, experience can be drawn from multiple industries; for example, accounting or transportation practices adopted by most businesses.

In ebXML, this store of basic knowledge on business collaboration is captured in a core library that connects a specific industry's terminology to more generic business models. This core library includes industry terminology, data and process definitions, established relationships, and cross-references to commonly accepted industry classifications or taxonomies. Where industries have already defined core libraries, companies will likely use them. If industries don't have this core library defined, they'll need to establish one and register it for use with ebXML.[6]

For example, in the paper industry (at least outside North America), both producers and consumers use ISO-defined standard sizes for office and printing plant paper stock. This industry-defined scheme is used throughout the business for ordering and production management, and is reflected in machinery and systems using cut- size paper, such as that for computer printers and copying machines.The paper industry will likely register these standard paper sizes for ebXML-compliant exchanges among paper companies, printing plants, and copy machine and computer printer manufacturers.

Individual companies probably will not need to perform the kinds of analyses that generate the business models stored in ebXML repositories. Most of these tasks will be undertaken by industry associations or consortia that can devote the resources required. In this chapter, however, we outline the steps in the process to show the nature of the thinking behind the ebXML specifications, and perhaps give a small head start for those in the business world who want to get involved in these industry-wide efforts. Also, when industries cannot agree on common definitions of processes or semantics, companies may need to develop their own process models.

Please note that the examples and illustrations in the following discussions are only illustrative of the process and are not intended to serve as a complete tutorial. The references at the end of the book can give the reader more details about UML.

The analyses of business processes themselves will generate UML activity, sequence, and class diagrams. Activity diagrams show the flow of business-level events among the actors and system, and show both the actions taking place at a high level and their sequence.[7] Figure 8.1 shows an example of an activity diagram, illustrating part of the inventory-replenishment process from the Marathoner running store case study described in Chapter 3, and portrayed in a use case in Chapter 5.

Figure 8.1. UML activity diagram example.

Sequence diagrams illustrate the interactions taking place both among objects within a system and with parties outside the system. In a sequence diagram, the actors and objects are arrayed horizontally and the time sequence is represented vertically.[8] Figure 8.2 gives an example of a sequence diagram, again from the Marathoner running store case study.

Figure 8.2. UML sequence diagram example.

Design Tools for Business Messages and Services

With the scenarios identified, processes defined, and interactions documented, enough material is available to design the individual transactions and services used by the trading partners. A key product of this design phase is UML class diagrams, which show the different kinds (classes) of data objects and their relationships to each other. Classes include definitions of the data objects themselves, as well as operations or functions performed on those objects.

Class diagrams also show the relationships among data objects, in what UML calls associations. Associations show the connections between objects, give a verbal description of the relationship, indicate whether the relationship is mandatory or optional, and specify whether the relationship allows for multiple objects.[9] Figure 8.3 gives an example of a UML class diagram, using a few items from the traveler database outlined in Chapter 3.

Figure 8.3. Example of UML class diagram.

Class diagrams can start defining the messages exchanged between trading partners. They identify the individual pieces and collections of data that are needed by the trading partners to perform their business tasks. In Figure 8.3, for example, a travel agent would need the identity and location data from a customer to put together a traveler profile that the agent could then use for reservations , confirmation messages, and delivery of tickets.

Class diagrams provide another critical function for ebXML; namely, the ability to compare processes from different industries at the data-element level. Comparing similar kinds of business scenarios at this level of detail shows where industries have comparable processes and where the terms used by the different industries may be functionally identical.[10]

Other products of the design phase include collaboration and state diagrams. Collaboration diagrams are similar to the sequence diagrams just discussed, but they show the behavior of groups of objects (rather than individual pieces), as well as the links between them. As a result, collaboration diagrams do a better job of showing how the collections of objects interact with each other, and thus are useful in defining messages and services.[11]

Figure 8.4 shows an example of a collaboration diagram, using the same inventory-management scenario described in Figure 8.2.

Figure 8.4. Example of UML collaboration diagram.

In Figure 8.4, the inventory system generates a confirmation message to the inventory manager. The confirmation tells the inventory manager that the inventory database now contains an item, represented by the product identifier, along with a quantity, and probably a text description (even the best inventory managers cannot commit all of their product codes and descriptions to human memory). You can imagine a class diagram (refer to Figure 8.3) for the confirmation message with those pieces of data.

Now imagine a similar kind of scenario, in which a supplier (manufacturer or distributor) receives an electronic message that the customer has unloaded the truck and entered a series of delivered items into inventory, or returned incorrect or damaged items. This kind of message, generated routinely and delivered automatically, can enable a supplier to manage the inventory of a business customer, delivering only the items that the customer needs to service its end users that day or week. The results are a more collaborative relationship between supplier and customer, with lower inventory costs, significantly reduced paperwork, and a greater level of customer service, without the supplier having to add significant new resources. This is what ebXML is all about.

State diagrams, also known as statechart diagrams, show the change in status of an object as a result of an action in which the object is involved. When an object receives an event it can do nothing and maintain its current state, or take actions of its own and change its state. In our inventory scenario, for example, a UML state diagram could show the change in state of the inventory database with the addition of new items to the inventory, as well as generating an action of its own, a confirmation message to the inventory manager.[12]

Companies use the metamodel to define business processes and subsequent schemas, patterns, elements, and core components. Users then can store these objects in registries, in either automated or human-readable form, for retrieval by current or potential trading partners.

Putting It All Together in a Metamodel

In ebXML, the specifications take the various tools offered by UML and others, and put them together in a package that allows industries or trading partners to document the interactions among companies doing business electronically . Note that ebXML calls this package the eBusiness Process Meta Model.

This metamodel ”literally, a model of models ”supports the requirements, analysis, and design phases described earlier, and results in a set of business processes, individual messages, and data items in those messages.

Each process includes the actors and choreographed series of transactions. The actors are the parties in the transactions, and the transactions themselves represent exchanges of electronic business documents. Business documents are composed of business information objects, which may be reusable in other processes or even in other industries. In turn, these business information objects are made up of core components, also reusable within or between objects, transactions, or industries. Business information objects may also, of course, have industry-specific business objects. For example, the paper industry computes the weight of paper using a measure called basis weight, which is unique to that industry.

The metamodel also provides a facility for putting a set of data items into messages on demand. This capability, called the specification schema, allows for definition of these collections either in UML or XML. The transactions may, if applicable , follow standard patterns of interactions for the industry. Also accompanying the specification schema is a set of common modeling elements to help populate the messages.

Translating from UML to XML requires production rules that specify the precise XML semantics for each UML object. For example, UML classes become XML elements and UML attributes are represented as XML attributes. Aggregate associations in UML become parent and child elements in XML.[13]

The documentation of these interactions through the specification schema becomes part of the collaboration protocol agreements ( CPAs ) between trading partners. The capabilities of companies to provide the messages or services described in the schema become part of the collaboration protocol profiles ( CPPs ), as they're known in ebXML.[14] Figure 8.5 shows the relationships among the metamodel and these components.

Figure 8.5. ebXML eBusiness Process Meta Model.

The ebXML specifications tell how the metamodel works in practice. Users such as industries or companies can use the metamodel to define their own business processes and the subsequent schemas, patterns, elements, and core components described earlier. Users then can store these objects in registries, in either automated or human-readable form, for retrieval by current or potential trading partners.

These business processes will define the roles of the trading partners and provide the sequence of message exchanges, called choreographies, among them. The processes will also provide the context for defining core components (described shortly), offer a framework for defining collaboration protocol agreements, and specify a responsible party for the process along with relevant contact information.[15]

Functional Service View

As mentioned earlier, the modeling methodology used by ebXML offers not only a business operational view that discusses business processes, but also a functional service view that describes e-business activities from the standpoint of the technology. The functional service view uses the same terms to describe ebXML components and services as the business process view, but it shows the relationships between the different systems, as well as the interfaces and protocols that need to be in place and operational. This view helps define the precise technical implementation of ebXML-compliant systems. Figure 8.6 provides a functional service view of the ebXML architecture.

Figure 8.6. ebXML functional service view.

The functional service view shows the importance of the ebXML registries in the architecture. The registries store the business process models, either converted to XML syntax or in the native modeling language, most likely UML. The registries also list the profiles of companies with the capability to provide the messages and services registered in this repository.

Companies that want to register their capabilities at this site work through the registry interfaces. These interfaces also provide access to the other company profiles stored at this site, as well as the industry processes, schemas, and other data objects on deposit. The important functions of the registries are defined in more detail in the next part of this chapter.

Once trading partners complete the retrieval, registration, and discovery process, the business service interfaces of the company systems deal directly with each other, first to exchange the collaboration protocol agreements, and then to exchange the actual payloads with the business content.[16]