RosettaNet is a widely adopted standard that provides message content, choreography and transport specifications for high-tech manufacturing companies. It is slightly more mature than ebXML, and its standards development process is targeted at the high-tech industry. Although RosettaNet publishes messaging specifications (such as RNIF2.0) but its vision is to develop standards that pertain to the industry processes. This involves creating message content specifications and choreography with a reduced focus on the infrastructure that supports such activities.

ebXML is a set of standards developed to enable enterprises to conduct business over the Internet. Its stated goal is similar to RosettaNet, although the specific standards developed are different. It produces specifications for messaging, registries, and business processes. Unlike RosettaNet, ebXML is a horizontal standard - it is not targetted towards any particular industry.

As a conceptual model for discussing differences between standards, RosettaNet uses the B2B conceptual model by the Business Internet Consortium. This model identifies the different layers and stacks required for performing B2B commerce. Each layer describes a different level of abstraction that builds on the lower layer.

The lower three layers - Network Transport, Service Oriented Architecture and Backend Integration - can be classified as infrastructure layers. They describe the lowest level of technology required for applications to communicate over the Internet.

The middle five layers fall can be described as the technical specifications for describing data and processes. The XML and messaging standards provide for the transport and packaging of data. The repository and registry contains the definitions required to connect to the various services provided each partner. The content and the process description identify common data formats and technical processes.

The upper four layers of the model describe the business specifications. Each business specification can be described in terms of the content and the process. The content can be universal, or it can be specific to a particular industry. The same applies to a business process - it can be universal such as a simple invoice process, or it can be extended to fit the way an industry employs it.

Under this model, the standards published by ebXML and Rosettanet can be categorized as in the respective layers.

For reasons of conciseness, the full specifications are not described here, these are available on the Internet (see references below)

The objective of convergence is to bring together different standards to eliminate duplication of work and inconsistencies. This occurs when the market realises the need to reduce the multiplicity of standards and the proliferation of incompatibility amongst products.

However, convergence is not inevitable nor unavoidable. If a standard is too entrenched, the cost of change may exceed any possible benefits, for example the use of different power frequencies in different countries. Or in other cases, the effort to support a new standard might be trivial, as for example in the use of different power plugs in the industries.

In this case, B2B standards work without regards to geographical boundaries and with little existing infrastructure in place to affect the decisions. The result is that there is a strong impetus for B2B standards to come together. This is important during the early adoption phase where the cost of implementation high and the market is small.

Standards that do not adapt or succeed in attracting adherents eventually become irrelevant and finally obsolete. This form of Darwinism ensures that only the standards that meet the needs of the community proliferate and become successful. The new crop of Internet and XML based standards are facing this particular obstacle now - if they do not gain acceptance, they will fade away. The cost to the community may be another generation of high-cost implementations and fragmented trading networks - a losing proposition to all involved.

The RosettaNet organisation itself is keenly aware of the need for convergence. Its various committees have been investigating the use of ebXML and Web Services in order to complement its current offering. Although this decision had been made two years ago, none of these other standards have been formally adopted yet. The programs that have been initiated are finally being concluded and will begin to specify the use of other standards within the RosettaNet community.

The convergence of standards have been occurring in related organisations. The success of RosettaNet has caused several industry organisations to adopt the RosettaNet messaging specification as an industry standard. The Chemical Industry Data Exchange has defined the CIDX protocol which is based on RNIF1.1 and the American Petroleum Industry has defined the Petroleum Industry Data Exchange (PIDX) based on RNIF2.0 specifications.

The public process configuration of RosettaNet is described in the RosettaNet PIP specifications. These PIP specifications are distributed by RosettaNet and they consist of the following items.

The public configuration of the gateway is configured using parameters from the PIP definition. This includes extracting the roles, activity identifiers, process identifiers and codes from the document and configuring these into the software. At best it is a tedious process that is error prone. At worst, there will be misinterpretations of the values to be used when configuring the software. These misunderstandings will have to be resolved before the partners can connect with each other.

There is a need to optimize this process of reading the process configurations from a RosettaNet PIP by providing a machine-readable form. ebXML's Business Process Specification Schema (BPSS) provided a suitable fit for this information.

The BPSS Schema allows us to specify the collaboration between two parties. The schema can contain elements for specifying the roles, activities, and other parameters needed to configure the process.

<BusinessTransaction name="Notify of Invoice" 
  nameID="NotifyOfInvoice_tx" isGuaranteedDeliveryRequired="true">
  <RequestingBusinessActivity name="Invoice Notification Action" 
    nameID="InvoiceNotificationAction" 
    isAuthorizationRequired="true" 
    isIntelligibleCheckRequired="true" 
    isNonRepudiationReceiptRequired="true" 
    isNonRepudiationRequired="true" 
    timeToAcknowledgeReceipt="PT2H" 
    retryCount="3">
  <DocumentEnvelope name="Invoice Notification" 
    nameID="InvoiceNotification_doc" 
    businessDocument='//BusinessDocument[@name="Invoice Notification"]' 
    businessDocumentIDRef="PIP3C3InvoiceNotification" 
    isAuthenticated="persistent" 
    isConfidential="transient" 
    isTamperDetectable="persistent"/>
  </RequestingBusinessActivity>
</BusinessTransaction>
        

The information supplied in BPSS can easily be mapped into a software configuration for a PIP. A PIP configuration like the one below can be read from a BPSS document.

A normative specification for the use of ebXML BPSS to RosettaNet PIP is being undertaken by the RosettaNet PIP Specification program. It will produce BPSS specifications for future PIPs and therefore address the issue of producing machine-readable specifications for PIPs.

The configuration of system connectivity is an implicit requirement for RosettaNet. This configuration contains information about the identity of their partners, the necessary certificates for security purposes, as well as the network endpoints. The exchange of this information is currently informal - for example, by exchange of emails, or softcopy documents.

The use of ebXML's Collaboration-Protocol Profile and Agreement (CPP/A) can be applied to this scenario. The CPP document defines the message exchange capability of a partner. This information includes details of transport, messaging, security constraints and public process bindings (described by the BPSS document).

The information about the DeliveryChannel, Transport and DocExchange allows the configuration of the partner identity and the endpoint to be configured the B2B gateway. The CollaborationRole describes the participation in the transaction - whether the Party can be the sender or the receiver. The SecurityDetails along with the Certificates provide the configuration for the secure message using SSL and S/MIME as specified by RosettaNet.

The task of configuring the private process is a daunting one. It requires that the implementor has comprehensive understanding of the company's private process, and this may mean connecting to an Enterprise Resource Planning (ERP) system, or mapping XML elements to a simple relational table. Either way, this is often the most expensive (in terms of effort) portion of the rollout.

Often, the cost of this alone is so significant that many smaller companies have avoided implementing B2B as a result. Their typical volumes (for an order-to-cash scenario) will be relatively low. Furthermore, the skill set required to implement is significant - the company needs to identify and allocate key resources to this task.

Unfortunately, there are no direct maps of ebXML standards to aid in this category of work. However, there are several alternatives that can have been attempted, although each have their own shortcomings.