Adoption Strategies for XML Standards and the ebXML Infrastructure

1. Introduction

Before we begin...

• Caveats -

• ebXML is a work in progress and the work you see today could be subject to change. (Don't go build an ebXML application server then blame me if it doesn't work because the specs changed)

Initial Thoughts:

• Examine Business Requirements for Global Trade

• Review current XML vocabularies.

• Examine the EbXML Goals and Requirements.

• Show working example of ebXML marketplace (Alpha)

• Look at the overall architecture of ebXML and related initiatives such as UDDI and other XML taxonomies.

Business Needs

• Link traditional data exchanges (EDI or new XML) to business applications

• Create business processes based on smart documents

• Provide means for trading partners to quickly and easily locate re-usable components

• Provide means for trading partners to customize methods to their own internal systems

• Low cost server and client based solutions

In Search of the Silver Bullet

• Flexible Integration Tools

• XML Syntax

• OMG XML Metadata Interchange (XMI)

• Internet Marketplaces

• Standards (EDI, ebXML)

• Published Interfaces in a Registry (ebXML, UDDI)

Figure 1: Data Centric vs. Process Centric

Figure 2: Typical End-to-End EDI Configuration

Thus the need for ebXML

• Through the "Electronic Business XML" (ebXML) Initiative OASIS and UN/CEFACT want to lower the barrier of entry to electronic business in order to facilitate trade, particularly with respect to small- and medium-sized enterprises (SMEs) and developing nations.

XML Problems..

• XML, by itself, does not solve interoperability problems yet it is an important tool for doing so.

• XML gives authors the ability to create their own markup languages (elements and attributes)

• To a human, it is often easy to understand what another persons' XML is trying to accomplish

• To an application, even one letter difference destroys recognition abilities.

Let's look at XML Vocabularies

• XML Vocabularies describe structures and semantics for data exchanges

• Fixed sets of Elements and allowable attributes

• Can be built by anyone

• Examples -> xCBL, cXML etc.

General Considerations for adopting XML

• What vocabulary are my current trading partners using?

• Will adopting a specific taxonomy give me access to new markets or will it limit my exposure to a fixed marketplace.

• Who owns / maintains the XML vocabulary.

• Is the vocabulary extensible - will it meet my needs in five years time.

General Considerations for adopting XML

• Does the vocabulary have widespread endorsements by my vertical?

• Will it allow me to interoperate with other vertical marketplaces (horizontal)?

• What are the benefits/impacts of adopting XML?

• What tools support the XML vocabulary I am adopting?

XML Vocabularies

Let's look at some specific examples

Commerce One - CBL

• Common Business Library

• Current version 3.0 (just released)

• V 3.0 includes a set of business components, a full set of business documents, available in DTD format and Schema format.

• CBL operates within BizTalk framework (available in XDR)

Figure 3: CBL architecture

CBL - Future

• Pledged support for XSDL (current SOX)

• Commerce One involved with and has pledged support for ebXML

• Commerce One looking beyond having CBL be JAS (Just Another Standard).

• http://www.xcbl.org

cXML

• By Ariba (www.ariba.com)

• Commerce XML (cXML)

• Launched in 1998

• Supplier/Marketmaker alliance program to ensure member interoperability

• Simple, lightweight

• Endorsed by Microsoft as XML standard for BizTalk Framework.

cXML Architecture requirements

• The Best of EDI

  • Secure, one-to-one transactions

  • End to end real-time transactions

• The Best of the Web

  • Global reach -- access trading partners worldwide

  • Marketing capability -- integrates marketing with commerce

  • Multi-to-multi transactions -- negotiate/trade with many trading partners at the same time

  • Start at the employee desktop -- work end to end

  • Low-cost installations -- can be as simple as adding browsers

  • Lower-cost integration with XML

  • Integration with vertical marketplaces/content services

RosettaNet

• Begun in 1998 - 350 members.

• XML based.

• Quick to integrate.

• Many aspects of business

• Complete services integration

• PIP's (partner interface process)

• An early XML vocabulary that combined business process analysis with supply chain integration.

• Originally centered on the computer technology industry

• Has become a model for other industries and as a result its influence is felt well beyond its industry boundaries, including the ebXML initiative.

Focus on Business Process

• RosettaNet's use of business process analysis separates it from most other vertical industry vocabularies.

• Rather than jumping immediately into defining XML messages, the group chose to first define its business processes, and in considerable detail.

• The inventories of processes undertaken by RosettaNet serve as a model for other industries using ebXML.

Figure 4: Rosettanet's Role

Rosettanet Implementation Framework

• Well defined guidelines for exchanging messages based on PIPs, called its implementation framework.

• Uses an overall business model that directs how companies interact within the PIPs and with each other.

• Comprehensive and well defined.

• Implementation Framework has five parts:

  • Creation of PIP guidelines that provide detailed specifications to supply chain partners

  • Distribution of those specifications to supply chain partners

  • Validation of the message content exchanged among trading partners

  • Extensions of guidelines for special trading partner implementations, but they cannot override original RosettaNet specifications

  • Exchange of extended guidelines to allow for validation of these special messages

Figure 5: Managing Board

2. BizTalk - the XML Framework

BizTalk

• BizTalk is an industry initiative started by Microsoft and supported by a wide range of organizations, from technology vendors like SAP and CommerceOne.

• BizTalk is not a standards body.

• A community of standards users, with the goal of driving the rapid, consistent adoption of XML to enable electronic commerce and application integration.

What Is BizTalk?

• XML framework for electronic commerce and application integration

• Specifically, a set of XML schemas (XDR) produced by Microsoft, partners and standards bodies.

• Enables well-defined services for exchanging data and integrating them into existing applications

• Transportation and messaging addressed.

• Works well if you own a BizTalk server

Figure 6: Typical BizTalk Server Configuration

Sampling of Current XML Initiatives

There are dozens of XML schema initiatives. Gartner predicts that within 2 years 80% of proprietary XML formats will have fallen by the wayside. For more information see http://www.xml.com/pub/2000/02/23/ebiz/verticals.html

Other XML business vocabularies

• Lots of others <SWIFT, FinXML, Visa)

• All have a problem with semantic interoperability between standards.

• Current solution of hard coding exchanges is ineffective in the long term.

• www.oasis-open.org/cover (1,000+)

• Need for dynamic crosswalk mechanism.

3. The ebXML Initiative

A look at ebXML

• Based on work done in EDI for the past 20 years

• Has approximately 1,800 participants as of Dec 2000.

• Work being done by the worlds' leading experts on E-Commerce and Business Information Management

The Team

• Jointly sponsored by UN/CEFACT and XML OASIS.

• Strong vendor commitment.

• Strong support from industry verticals

• Support from DISA and involvement of X12 members.

• XML/edi Group support.

ebXML Mission and Scope

To provide an open XML-based infrastructure enabling the global use of electronic business information in an interoperable, secure and consistent manner by all parties.

The scope of ebXML initiative is to develop and publish, in the public domain, relevant and open technical specifications in support of domestic and international Electronic Business exchanges.

ebXML project metrics

• 18 month project

• "A single set of internationally agreed upon technical specifications that consist of common XML semantics and related document structures to facilitate global trade."

• Will be submitted to an appropriate internationally recognized standards body for accreditation as an international standard

• Open non-proprietary public specifications

Figure 7: ebXML High Level use case

Concepts

The conceptual overview has therefore introduced the following concepts and architectural components:

1. A standard mechanism for describing a business process and its associated information model

2. A mechanism for registering and storing a business process and information model so that it can be shared/reused

3. Discovery of information about each participant including:

   • What business processes they support

   • What service interfaces they offer in support of the business process

   • What business messages are to be exchanged between their respective service interfaces

   • Technical configuration of the supported transport, security and encoding protocols

4. A mechanism for registering the aforementioned information so that it may be discovered and retrieved

5. A mechanism for describing a Trading Partner Agreement (TPA) which can be derived from the information about each participant from item 3 above

6. A standardized messaging service which enables interoperable, secure and reliable exchange of messages between two parties

7. Mechanism for configuration of the respective messaging services to engage in the agreed upon business process in accordance with the constraints defined in the TPA.

TA Philosophy

Architect ebXML in Layers

The first layer has to recognize the Repository Items that constitute Core Components (ie address, tel).

The second Layer has to recognize the Business Process (BPM)

Third Layer is discovery of what partners require (CPP - Collaborative Process Protocol)

Use existing work - the wheel is already round!!!!

Figure 8: Business Operational View

Figure 9: Functional Service View

ebXML Architecture

• At the heart of ebXML is a powerful system of Registries and Distributed Repositories.

• Repositories contain many different items - Core Components, DTD, Trading Partner Profiles and Business Process documents.

• It is important that we can reference Objects (CC) from Business Process Layer down to the Element Level.

Figure 10: ebXML Registry and Repository

Repository Item Examples

• Registry/Repository systems can contain many types of ebXML documents

  • CPP and CPA templates

  • Business Process Documents

  • Core Components and CC Aggregates

  • DTD's and Schemas

• XML elements in business messages can reference items in a repository.

• Examples (all are the same item!!!):

  • <nameofperson>

  • <nomdelapersonne>

  • <name>

  • <TheThingICallYou>

• XML elements in business messages can reference items in a repository.

• Examples (all are the same item!!!):

  • <nameofperson UUID="myrep:1236">

  • <nomdelapersonne UUID="myrep:1236">

  • <name UUID="myrep:1236">

  • <TheThingICallYou UUID="myrep:1236">

  • XML Elements in document instances contain pointers to RI's

  • Repository Items are metadata - not instances of data

Figure 11: Using the ebXML Registry and Repository

Repositories - new thinking!!!

• Both centralized and decentralized repository models shall be acceptable within the ebXML infrastructure. The ebXML registry and repository architecture shall also support distribution.

• No single point of failure

Centralized Repository

Figure 12: Centralized Repository

Figure 13: Decentralized Repository / Distributed Registry

ebXML - CPP and CPA IP

• Tells you who, interfaces, tModels etc.

• Provide a list of interfaces expressed as Business Processes (ebXML - BP's)

• Each Process has a Globally Unique Identifier (called UUID in UDDI, GUID in ebXML)

• Similar efforts - IBM TPAML, UDDI, eCo.

ebXML Business Process

BP describe document choreography and overall process interfaces.

• Identify which business data needs to be present to ensure requirements of a party is being met.

• Examples can be "Deliver a service" or "Purchase a product"

• Identify DTD's by GUID

Core Components:

• A Core Component captures information about a real world (business) concept.

• A Core Component can be either an individual piece of business information (atomic data element), or a natural 'go-together' family of business information pieces (aggregate data element).

• It is 'Core' because it occurs in many different areas of industry/business information exchange.

ebXML CC and XML Vocabularies

• Vocabularies (eg. xCBL 2.0, Ariba cXML) contain elements that may be semantically identical to some of the common core components. Examples can be an <address> element on a xCBL invoice and the <partyAddress> on a Visa XML Invoice.

• Core Components MAY have contextual behaviour at run time

  • i.e. PurchaseOrder.sendParty(name) != PurchaseOrder.sendParty(name)

Special Considerations for SME's

• SME's will not likely have the expertise to start modeling business processes in UML.

• Address complexity issues - part of the reason why EDI failed to scale/

• SME's need a cost effective solution - plug and play type components.

• ebXML is designed to allow lightweight packages and scaled integration.

How ebXML SME's interact

• SME's will likely use packages from ASP's which will present simple web forms for them to fill out. These will include many stock business processes, identifiable by a GUID (UUID).

• An SME may also identify and use BPM's (Business Processes) and DTD's / Schemas used by its partners.

Figure 14: How ebXML SME's interact

ebXML Business information

Decomposition to the most atomic level is the winning strategy for ebXML. It allows for automated semantic recognition of business information by using Registry services.

Figure 15: ebXML Business information

Figure 16: Business Message References

Figure 17: Putting all the pieces together

Some Final Thoughts..

• ebXML to build an open architecture, not a "Standard"

• Truly interoperable and Extensible (Global)

• Includes everyone from SME's to Fortune 1000

Design and Development by deepX Ltd.