XML

This article will explain how XML is used to enable businesses to work together via the Internet, in the context of the RosettaNet B2B framework. Looking at proven frameworks such as RosettaNet is important as it provides insight into what works today, and what will become important tomorrow. The article also offers a snapshot of how pervasive XML is in business integration frameworks, and outlines how XML technology can reduce the implementation costs of B2B integration solutions.

RosettaNet

RosettaNet, founded in 1998, is a nonprofit consortium of more than 500 of the world's leading information technology, electronic components, logistics, semiconductor manufacturing, solution provider, and telecommunications companies working to create, implement, and promote open e-business process standards. RosettaNet is named after the Rosetta stone, which is inscribed with the same message in three languages. The Rosetta stone enabled scholars to decipher Egyptian hieroglyphics - something they'd previously been unable to do. In a similar way, the mission of RosettaNet is to establish a common language and standard processes for business-to-business (B2B) transactions. In 2002, RosettaNet merged with Uniform Code Council (UCC), the organization that administers UPC symbols, in an effort to apply the RosettaNet approach to other vertical industries (such as consumer goods).

RosettaNet was founded to improve supply-chain efficiency, to increase supply-chain visibility, and to enhance collaboration in a secure and reliable fashion across trading networks separated geographically. RosettaNet has achieved tremendous adoption of its standards in the high-tech manufacturing supply chain over the past three years, with more than 3,000 documented production implementations and a growth rate of approximately 500% from 2001 to 2003.

As background for discussing the technical components of RosettaNet, it is necessary to define business processes and to distinguish between two kinds of business processes - public and private.

Business Processes

A business process consists of a set of steps that, when executed, accomplish a certain business goal. For instance, a customer issues a request for a product from a supplier by sending a purchase order containing the descriptions of the items to be purchased. The supplier checks for the availability of the items in its inventory before accepting or rejecting the customer's purchase of the specific items. These steps constitute a purchase order business process.

To the customer in the purchasing scenario, some business process steps are neither visible nor particularly relevant. For instance, checking the availability of the items in the supplier's inventory is one such step that is particularly relevant to the supplier but not visible to the customer. The difference in relevance and visibility of the business process steps to the participants is the basis for distinguishing between two kinds of business processes, public and private business processes. Public business processes consist of steps that are visible to both parties conducting the business, whereas private business processes consist of steps that are visible only to one party. As this example illustrates, executing a public business process often requires executing private business processes as well.

Rationale for Specifying Business Processes
In the past, the steps of both public and private business processes were typically undocumented and considered part of a company's "way of doing business." In other words, while each company had business processes that it used to accomplish select business transactions, such as satisfying a customer order, ordering supplies, or responding to requests for support, the actual steps and the software needed to accomplish these steps were internal to the company and its employees. This was not a very satisfactory state of affairs for a number of reasons:

1. When business processes are undocumented, they are not amenable to automation. Automation of business components (such as standardizing business documents using EDI and XML) increases the incentive to automate business processes and increase the effectiveness and efficiency of the business organization.
2. With the advent of the Internet, new ways of doing business are becoming more and more common. Along with these opportunities comes a need to embrace new business processes and to change existing ones. Assessing the impact of modifying an existing business process is difficult when the business process is undocumented.
3. Documenting business processes in a rigorous fashion helps in dividing the labor between business analysts who are familiar with the business processes and technical experts who are familiar with implementing the various steps of the business process in software.

Several languages for specifying business processes have emerged in recent years: BPSS (Business Process Specification Schema) from ebXML (www.ebxML.org); BPEL (Business Process Execution Language) from OASIS (www.oasis-open.org); and BPML (Business Process Modeling Language) from BPMI (www.bpmi.org).

Business Processes in RosettaNet

RosettaNet focuses on standardizing and automating public processes - it does not attempt to standardize private processes. RosettaNet enhances public processes by standardizing the sequence of operations in a business process, the business documents themselves, and the messaging system that sends and receives these documents (see Figure 1). RosettaNet differs from the previous industry standards efforts such as ANSI EDI in that RosettaNet developed its standards using XML for the Internet-based business transactions. The RosettaNet approach also differs from those of other standards initiatives in two distinct ways:

1. RosettaNet provides its members with considerable support while they implement the standards
2. RosettaNet undertakes standardization of a new business process only if the member entities involved commit to implementing the business process.

Standardizing business processes and documents in RosettaNet - PIP
A Partner Interface Process (PIP) specifies the business documents that are exchanged within a business process, the sequence in which the messages are exchanged, and the physical attributes of the messages that define the quality of service. The business documents and the exchange sequence are specified in XML. Today, more than 50 PIPs have been validated by actual implementation between two trading partners, and are freely available for download by the public at www.rosettanet.org. A PIP defines the following:

• Roles for the trading partners that use the business process are defined. For example, PIP3A4, Manage Purchase Order, defines the roles "Buyer" and "Seller."
• The business process is defined in terms of the business activities it requires. For example, in PIP3A4, the business activities are Request Purchase Order and Confirm Purchase Order.
• The messages (business documents) exchanged between the roles are called "action" messages. The Request Purchase Order business activity sends a Purchase Order Request Action Message from the Buyer to the Seller. The Seller activates the Confirm Purchase Order Business Activity and sends a Purchase Order Confirmation Action Message to the Buyer, who acknowledges, at the line level, if the purchase order is accepted, rejected, or pending. The PIP defines the content and format of the action messages in XML.
• The sequence in which these messages is sent and the quality of service attributes for the message exchanges, such as time to respond, authentication, and number of retries in case of an unsuccessful message transmission, are defined. The sequence is currently specified using the business process specification language, ebXML BPSS.

Action messages are acknowledged by positive or negative signals: a Receipt-Acknowledgement signal acknowledges that a message has been received and is syntactically validated, whereas an exception signal indicates the opposite. Error codes identify the types of errors.

Currently, PIPs are available for the business areas described in the honeycomb diagram (see Figure 2). For instance, the area named Forecast can be thought of as standing for collaborative forecasting across the supply chain. Clearly, order management is an integral part of such collaborative forecasting. The area named Manufacture stands for material composition and the exchange of semiconductor test data and so on. From the figure, it is clear that Order Management impinges on a number of areas of the supply chain.

RosettaNet divides the entire supply-chain domain into clusters and segments. Each PIP is categorized according to the cluster and segment to which it belongs. For example, PIP3A4 is the fourth PIP in Segment A of Cluster 3 of the RosettaNet classification system.

RosettaNet-Based B2B Integration Solutions

As the discussion in the previous section shows, a key element of RosettaNet-based solutions is the PIP. To deploy a RosettaNet standard or PIP, several activities need to be executed (not necessarily in this order):

1. Choose the PIPs that will be used in transactions. Design private business processes that work in tandem with the public business process defined by the RosettaNet PIPs.
2. Map the PIP messages to the back-end data structures based on the private process. In particular:
   -Develop the data maps from legacy/packaged application transactions into RosettaNet PIP transactions.
   -Change data from one system or application format to another.
   -Edit data to ensure consistency and remove errors.
3. Develop custom applications or modify existing/packaged applications to support the RosettaNet PIP implementation.
4. Test the private and public business process implementation.
5. Manage and train internal staff and all trading partners affected by the RosettaNet PIP implementation.

Data collected by RosettaNet shows that 20% of the integration effort is spent in the design and implementation of the internal processes (step 1). Roughly, 30% of the effort is spent in managing and training the partners and internal staff involved (step 5), while 50% of the effort is associated with the technical implementation the solution requires (steps 2, 3, and 4).

In a typical RosettaNet B2B integration transaction additional components exist. The discussion of each component contains how using XML in a standardized way can reduce cost. Many commercial systems make use of XML extensively in providing these components.

1. RNIF connections: Implement and establish RosettaNet Implementation Framework (RNIF) connections with the trading partners, and set up appropriate secure network connections across the organizational firewalls.
2. Trading partner profile/contract manager: An important part of the activity in managing the trading partners is managing their technical profiles on connectivity. This profile includes the contact information, digital certificates, and RosettaNet PIP message controls. The effort in managing the profiles is substantial prior to the beginning of the business transactions with a trading partner, and lessens over time. For example, expiration of a certificate requires changing a profile. XML can be used for defining profiles of trading partners. One available format is ebXML Collaboration Profile and Agreement (CPPA). The use of a commonly accepted format increases portability and reduces errors.
3. Execution management interface: This interface helps monitor the execution of PIPs, and also provides tracking and tracing functionality of PIP messages from a specific trading partner. For execution monitoring and for reacting when certain conditions are reached, XML-based languages such as RuleML can play a role. The ebXML BPSS may be used in the verification of the PIP choreography described in a PIP specification.
4. RosettaNet solution administrator: Manageability and configurability of the RosettaNet solution depends on the quality of the facilities available for these activities. This interface can reduce training effort and cost. Currently, there are no XML standards for specifying the management and configurability of RosettaNet.
5. Internal application integration: Often, private processes are integrated with back-end applications such as ERP and CRM. A good solution for this type of integration considerably reduces the effort required to design and implement the private process (steps 1, 2, and 3). For example, XML-based business process languages, such as Business Process Markup Language (BPML) or Business Process 4 Web Services (BPEL4WS), can be used for defining private processes. The use of such languages increases the flexibility of the implemented business process.

Compliance, Cost Reduction, and Automation

For the successful adoption of RosettaNet across a wide spectrum of businesses, a key requirement is that the solution is capable of implementing and exchanging business information using RosettaNet PIPs in a way that complies with RosettaNet specifications. As more components of public processes are standardized in machine-readable language, implementing and executing RosettaNet e-business standards becomes less costly and accessible to more types of businesses (i.e., SMEs).

RosettaNet took the first step in facilitating compliant automation by creating PIPs based on Document Type Definition (DTD). This step allowed trading partners to implement PIPs in a manner that complies with the business document structure specified in the DTD and additional constraints described in message guidelines. This step also defined the choreography of sending and receiving business documents and their responses. In addition to these PIPs, RosettaNet also created the RosettaNet Implementation Framework (RNIF), which defines the infrastructure for transporting PIP messages. The RNIF standard considerably helped solution providers in supplying compliant solutions that are simple to integrate in many environments, leading to widespread adoption of PIPs today.

The recent move from DTD-based PIPs to XML Schema-based PIPs is the second step to increasing automation and to driving down implementation costs. XML Schema-based PIPs can better express constraints that previously required DTDs and message guidelines in free-formatted text. PIPs are now created with reusable components. The PIP choreography described earlier in a UML activity diagram is now described in XML that conforms to ebXML BPSS. The quality of service attributes of PIP messages are also described in ebXML BPSS instead of a table. All of these improvements result in further automation of the implementation of these PIPs.

The RosettaNet industry consortium has undertaken these efforts to reduce the implementation, execution, and administration costs of B2B integration across the global trading network. To reiterate, RosettaNet-based integration solutions employ XML-based standards to enhance portability and interoperability. Thus, the use of XML-based standards reduce costs without compromising integrity and the interoperability of the solutions. There are arguably other means to reduce the cost of solutions; however, each comes at the expense of interoperability.

Conclusion

When standardized e-business processes are applied, they deliver considerable value, as evidenced by the significant number of RosettaNet production implementations in the marketplace. Over the past several years, RosettaNet has been aggressive in applying XML to more areas than representing business documents to increase machine interpretation and use of the specifications. Increased automation in various steps of the implementation process, and the removal of custom code in execution, results in greater reductions in costs, and thus, promotes greater use and applicability of the RosettaNet standard.