RosettaNet

RosettaNet, in its basic form, is just another trading community standard. However, its innovative approach to managing trading communities at both the information and process levels makes it particularly important to application integration and supply chain integration.

The RosettaNet consortium was created to define standard processes and interfaces to manage supply chains within the high-technology industry. Building on the successes of RosettaNet, a movement is now under way to leverage the same or similar standards in other industries. The innovation within the RosettaNet community has been in defining how other trading community standards, typically structured around verticals, will operate.

For all its strengths and innovations, RosettaNet is still in its early stages of development. A proof-of-concept prototype, running in early 2000, demonstrated that the concept will work. Indicators point to enough interest from the partners to make production systems inevitable. At this point, things bode well for RosettaNet.

RosettaNet History

RosettaNet was officially formed in 1998 to standardize e-Business activities in the high-technology industry (e.g., computer manufacturing and reselling). It defined open interfaces between manufacturers, distributors, resellers, and other participants in the supply chain. Indeed, close to 300 vendor members are participating in the development of the RosettaNet standard. (More information about RosettaNet is available at www.rosettanet.org.)

The high-technology industry provided a good testbed for the RosettaNet concept. The industry uses many of the same component suppliers (semiconductors, ICs, peripherals, etc.) and thus could quickly agree about information formats. Catalyzing RosettaNet's development was the perception that EDI had largely failed because of its expense, its proprietary nature, and its inability to adapt to changes in B2B processes. In addition, EDI was weak at real-time information exchange and was unable to keep up with high-volume information flows (although XML has not yet proved its viability here, either).

What's RosettaNet?

Despite the common belief that RosettaNet is all about XML, it is not. RosettaNet is a set of standard mechanisms processes, really that allow companies to agree upon the processing of standard business transactions. XML was added to take the place of EDI as a mere data interchange standard.

Because RosettaNet is about processes rather than data, the most important aspect of RosettaNet is the development of common Partner Interface Processes (PIPs) and common dictionaries. RosettaNet provides a master dictionary to define properties for products, partners, and business transactions. This master dictionary, coupled with an established implementation framework, can be used to support the application integration dialog. PIPs provide alignment within the overall supply chain process, allowing businesses to interact at a number of levels to support the processes of common trading communities.

For example, PIP2A2, Query Product Information, defines a common process between companies. Because each company adheres to this common process, or PIP, there is no confusion about what this particular process does. Common semantics and common mechanisms automatically carry out the process.

The real value of RosettaNet is the common agreement on "which processes do what, and where." Although we long ago established processes for executing common business activities, there has been little agreement about common processes that exist between companies or a common set of application semantics (dictionaries). It should be apparent that, as we have suggested, RosettaNet is less about technology and all about creating PIPs, which are really contracts or agreements.

Fundamentally, creating PIPs is a matter of understanding a process in detail, finding a way to make it more efficient, and defining it by using the standard PIP framework that RosettaNet offers. The process to create PIPs is depicted in Figure 14.2.

Figure 14.2. RosettaNet development process.

graphics/14fig02.gif

The stages to the process include

  • Business process modeling

  • Business process analysis

  • PIP development

  • Dictionaries

Those who want to leverage RosettaNet use business process modeling to identify and quantify the properties and behaviors of a particular business process. This is a laborious process of documenting what happens while selling a product, checking inventory, or shipping a product to a customer. Each stage is a process, and each stage may have hundreds of steps. Each step must be inventoried, defined in detail, and completely understood, with the goal of automating the process based on an agreement between companies. The output of this effort is a model that reflects every detail of a particular process using a common framework.

Business Process Analysis

Once the business process model is understood, we must realign the process in the form of a PIP target list. This step determines how much value this process will have when automated by RosettaNet.

PIP Development

Each PIP provides a common business/data model and documents that enable system developers to leverage RosettaNet interfaces. Each PIP includes

  • XML documents using a particular DTD, specifying PIP services, transactions, and messages, including dictionary properties

  • Class and sequence diagrams in the Unified Modeling Language (UML)

  • A validation tool

  • An implementation guide

Dictionaries

During the development of RosettaNet, two data dictionaries were created to provide a common set of properties that exist within PIPs a technical properties dictionary and a business properties dictionary. The technical properties dictionary provides the technical specifications for all product categories. The business properties dictionary describes attributes used to define supply chain partner companies and business transaction properties. These dictionaries, when bound to the RosettaNet Implementation Framework (exchange protocol), become the basis for each PIP.

It's the PIP

The real value of PIPs is the ability to allow manufacturers to seamlessly add new products to their partners' catalogs for example, adding a new part number using a common format and information interchange standard.

A PIP specification (see Appendix A for an example) comprises three views of the e-Business PIP model.

The Business Operational View (BOV) provides the semantics of the business data entities and their exchange flow between roles during normal operations. The content of the BOV section uses the PIP Blueprint document created for the RosettaNet business community.

The Functional Service View (FSV) defines the network component services, agents, and functions required to execute PIPs. These include all transaction dialogs in a PIP protocol. The FSVs are semantically derived from the BOV and include two major components: the network component design and the network component interactions.

The Implementation Framework View (IFV) defines the network protocol message formats and communication requirements between protocols supported by network components. These messages are exchanged when software programs execute a PIP.

There are several categories, or clusters, of PIPs, such as the following (see the tidbit "RosettaNet PIP Clusters and Segments" for a complete listing):

  • Cluster 1: Partner, Product, and Service Review

  • Cluster 2: Product Introduction

  • Cluster 3: Order Management

  • Cluster 4: Inventory Management

As you might expect, there are several subcategories within each cluster (see the tidbit "RosettaNet PIP Clusters and Segments," and the tidbit "Published RosettaNet PIPs within Clusters and Segments"). Note that Clusters 1 through 3 are extensions, or a rehashing, of processes already specified in EDI during the past quarter century. Also, Cluster 4 PIPs are much like the VICS Collaborative Planning, Forecasting, and Replenishment standards administered by the Uniform Code Council.

RosettaNet PIP Clusters and Segments

Cluster 1: Partner, Product and Service Review

Segment A: Partner Review

Segment B: Product and Service Review

Cluster 2: Product Introduction

Segment A: Preparation for Distribution

Segment B: Product Change Notification

Cluster 3: Order Management

Segment A: Quote and Order Entry

Segment B: Transportation and Distribution

Segment C: Returns and Finance

Segment D: Product Configuration

Cluster 4: Inventory Management

Segment A: Collaborative Forecasting

Segment B: Inventory Allocation

Segment C: Inventory Reporting

Segment D: Inventory Replenishment

Segment E: Sales Reporting

Segment F: Price Protection

Segment G: Ship From Stock and Debit/Credit (Electronic Components)

Cluster 5: Marketing Information Management

Segment A: Lead/Opportunity Management

Segment B: Marketing Campaign Management

Segment C: Design Win Management (Electronic Components)

Cluster 6: Service and Support

Segment A: Warranty Management

Segment B: Asset Management

Segment C: Technical Support and Service

Published RosettaNet PIPs within Clusters and Segments

Cluster 0: RosettaNet Support

Segment A: Administration

PIP0A1: Notification of Failure

Cluster 1: Partner, Product and Service Review

Segment B: Product Review

PIP1B1: Manage Product Information Subscription

Cluster 2: Product Introduction

Segment A: Preparation for Distribution

PIP2A1: Distribute New Product Information

PIP2A2: Query Product Information

PIP2A5: Query Technical Information

PIP2A8: Distribute Product Stock Keeping Unit

Cluster 3: Order Management

Segment A: Quote and Order Entry

PIP3A3: Transfer Shopping Cart

PIP3A4: Manage Purchase Order

PIP3A5: Query Order Status

PIP3A6: Distribute Order Status

The Technology

RosettaNet's technology is nothing new or revolutionary. Its implementation is based on CommerceNet's OBI specification, XML, X12 EDI, and PKCS#7 digital signatures.

The OBI specification was established to allow companies to use the Internet to purchase products that might not be part of their core business, such as coffee for the office coffee machine. OBI uses HTTP for communication between companies, Secure Socket Layer (SSL) for security services, PKCS#7 for digital signatures, and X12 for purchase orders.

The RosettaNet communication model specifically defines the behavior that should occur within the OSI application and session layers, dividing the application layer into the action, transaction, process, service, agent, message handling, transfer, and security layers (see Figure 14.3).

Figure 14.3. ISO/OSI and RosettaNet communication reference model.

graphics/14fig03.gif

The action layer provides business actions that act upon or in conjunction with accompanying information.

The transaction layer provides transaction monitoring for sequences of message exchanges that support a unit of work. Either every party commits to the transaction or the transaction is rolled back completely.

The process layer encapsulates the conditional choreography of a transaction for executing a PIP.

The service layer provides network resources that perform network and business-related functions.

The agent layer provides a communication interface for other applications.

The message handling layer provides asynchronous delivery of information.

The transfer layer provides a mechanism for information transfer between uniquely named network resources.

The security layer allows for a secure communication connection, which leverages digital signatures to implement authorization and authentication.

RosettaNet uses OBI as a subset of its enabling technology, adding more functionality within the data formatting area. It leverages XML rather than EDI (OBI was created to use EDI) to move information from point to point. (Although many EDI-like semantics are maintained, XML was selected for its compact and simple nature, and its acceptance in the market.)

PIP Communication

As we noted earlier in this chapter, the fundamental requirement of a PIP is to exchange business data between trading partners. RosettaNet-compliant networked applications receive data using a standard format that all systems and humans in the loop can understand.

Those who created RosettaNet PIPs created RosettaNet messages by using the set of elements and codes defined in the RosettaNet business and technical dictionaries. The set exists as a baseline from which PIP teams create message-exchange specifications and precisely define the values and codes that are assignable to each of the data elements all of which are part of the PIP implementation guidelines.

These guidelines are sent as a document from RosettaNet to trading partners and RosettaNet solution partners. The guidelines define the vocabulary, structure, and allowable data element values and value types for each message exchange.

Moreover, PIP specifications enable the development of interoperable applications. Each message has three parts: the Preamble Header, the Service Header, and the Service Content. This information is typically packaged for exchanges as MIME messages.

PIP Message Structure

RosettaNet business messages consist of a message header and a message body, and both the header and body are a well-formed XML document. The header and body are encoded inside a multipart/related MIME message. The message preamble section of the MIME message contains elements that are global to the RosettaNet service, and those that are common to the Service Header and Service Content. This information is specified as a DTD that is common across all messages.

The message header is also specified using a DTD that is also common across all messages. There is a separate DTD or XML schema for each message, and that DTD or XML schema is used to validate the body of the messages. The idea behind a common message header DTD that is separate from the message content DTD is to support the logical segmentation of validation steps, which include validation of grammar, sequence, schema, and content. Grammar and sequence validations are performed against the message header DTD, and validation of message content is deferred until the schema validation step. When this mechanism is used, the message header may be valid even when the content is not. RosettaNet has this structure in place so trading partners can send failure messages. The message content is specified in individual PIPs, and each PIP has one or more "actions" that are defined by the schemas or DTD contained in the message.

RosettaNet Networked Application Protocols

RosettaNet leverages most native Internet protocols, including HTTP and TCP/IP. The TCP/IP protocol provides the functionality defined for the transport layers. Sockets and SSL are OSI session layer protocols.

RosettaNet and B2B Application Integration

It is a safe bet that RosettaNet will shape the way we view intercompany process integration as it supports the goal of supply chain integration. To date, it is the most sophisticated standard available. This sophistication is due to the fact that it takes both processes and data into account, defining common processes and points of integration within a vertical industry. Other trading community standards have yet to deliver both layers and won't, unless they can get everyone on the same page for both application semantics and technology.

Sometimes we forget that even in the world of high technology we still have to deal with the psychology of people. The real strength of RosettaNet is not the technology, it is the fact that this organization got many people in a larger vertical industry (high technology) to define and agree upon a standard. What's more, it has succeeded at clearly defining the value of using such a standard as well as how new technology, including XML, fits into the framework. To its credit, RosettaNet built upon past success, reusing what worked with EDI.

The future is clear in RosettaNet. As organizations seek to open automated trade, they have to agree upon processes and semantics, an agreement that has thus far been frustratingly elusive.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net