slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc . PowerPoint Presentation
Download Presentation
XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc .

Loading in 2 Seconds...

play fullscreen
1 / 111

XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc . - PowerPoint PPT Presentation


  • 514 Views
  • Uploaded on

NACHA Financial EC Council March 29, 2000. XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc . About the Speaker.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

XML for Internet Markets and Trading Communities Dr. Robert J. Glushko Document Engineering Commerce One, Inc .


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

NACHA Financial EC Council

March 29, 2000

    • XML for Internet Markets and Trading Communities
  • Dr. Robert J. Glushko
  • Document Engineering
  • Commerce One, Inc.
about the speaker
About the Speaker
  • Dr. Robert J. Glushko is Director, Document Engineering at Commerce One. He has over twenty years of R&D, consulting, and entrepreneurial experience in online publishing, Internet commerce, SGML and XML. He joined Commerce One in January 1999 when it acquired Veo Systems, which he co-founded in 1997 and where his last position was Director, Information Engineering. Prior to Veo Systems, Glushko was the Chief Scientist and Vice President of Passage Systems, a consulting and systems integration firm specializing in SGML-based publishing (which he co-founded in 1992). He has also worked at AT&T Bell Laboratories and the Software Engineering Institute of Carnegie-Mellon University. He has an undergraduate degree from Stanford, a MS (Software Engineering) from the Wang Institute, and a PhD (cognitive psychology) from UC San Diego.
about commerce one
About Commerce One
  • Company
    • Founded 1996, acquired Veo Systems in 1/99, IPO 7/99 (CMRC)
  • Products
    • Complete “Commerce Chain” Solution for Suppliers, Buyers, Market Makers & Market Operators
    • Provider of “portal services” for a “Global Trading Web”
  • Commitment to Open and Interoperable XML
    • XML end-to-end in products and services
    • Aggressive participation in standards activities
the 1 minute version
The 1-Minute Version
  • XML is the key foundation technology for the Internet and the “web for computers” instead of just the “web for eyes”
  • Interoperability and scalability to create new B2B models like exchanges and trading communities depend on XML
  • Traditional EDI can help XML achieve these goals
topics
Topics
  • Mini-Tutorial on XML
  • Why Electronic Commerce Needs XML: The Integration Challenge
  • The Transition from EDI to XML
  • XML Standards and Industry Initiatives for “Commerce Languages”
  • XML Initiatives for Interoperability among Commerce Languages
  • The Vision of “Plug and Play Commerce” and the Global Trading Web
the xml revolution
The XML Revolution
  • The Web was created to publish information for people
      • “eyes-only” was dominant design perspective
      • hard to search
      • hard to automate processing
  • The Web is using XML to become a platform for information exchange between computers (and people)
      • Overcomes HTML’s inherent limitations
      • Enables the new business models of the network economy
untangling the web 25 april 1998
“Untangling the Web” 25 April 1998

.."But the biggest role that XML is expected to play is in integrating the way that existing paper documents -- invoices, loan applications, contracts, insurance claims, you name it are exchanged between organizations around the world. Imagine what the world would be like if one company's computer system could automatically read any other organization's documents - and make complete sense of them? This is the goal that the technique known as EDI has struggled, unsuccessfully, to achieve for years. Though efforts have barely begun, there is a chance that XML could actually make that happen. If it did, business on the Web could run riot."

laptop computer catalog entry as seen by eye on today s web
Laptop Computer Catalog Entry As Seen “By Eye” on Today’s Web

Laptop Computer

IBM Thinkpad 600E

400 MHz

64 Mb

8 Gb

4.1 pounds

$3200

laptop computer in html
Laptop Computer in HTML

<TITLE>Laptop Computer</TITLE>

<BODY>

<UL>

<LI>IBM Thinkpad 600E

<LI>400 MHz

<LI>64 Mb

<LI>8 Gb

<LI>4.1 pounds

<LI>$3200

</UL></BODY>

airline schedule entry as seen by eye
Airline Schedule Entry As Seen “By Eye”

Airline Schedule

Flight Information

United Airlines #200

San Francisco

11:30

Honolulu

2:30

$368.50

html airline schedule
HTML Airline Schedule

<Title>Airline Schedule</Title>

<Body>

<H2>Flight Information</H2>

<H3>United Airlines #200</H3>

<UL><LI>San Francisco

<LI>11:30

<LI>Honolulu

<LI>2:30

<LI>$368.50

</UL></Body>

html s limitations for commerce
HTML’s Limitations for Commerce
  • HTML is too format-oriented to describe products, services, participants, terms & conditions, etc., in a computer-processable form
  • HTML was designed as a simple markup language
    • simple structures: headings, lists, links
    • strong emphasis on formatting
    • weak for encoding content
markup is information intelligence
Markup is “Information Intelligence”
  • How much you can do with information depends on the extent and explicitness of its markup
  • Markup transforms a flat stream of text into a set of objects or elements that can be manipulated by other applications
  • HTML markup is “rich” or “smart” compared with RTF, which is rich compared with ASCII
  • HTML markup is “poor” or “dumb” compared with a content-oriented data model, such as the markup implied when information is in a database
my info can beat up your info
My Info Can Beat up Your Info
  • Better to make information “smart” and “self-aware” than to bury the intelligence into a custom processing application
    • “Dumb” data programs are always more brittle
    • “Smart” data can be used by multiple applications
xml and information iq
XML and Information “IQ”

Content/structure-based text objects:

XML, SGML, databases

Formatted electronic text:

HTML, word processing files

Easier to translate to

more “processability” / reusability

Unstructured electronic text:

ASCII

Printed text

xml extensible markup language
XML -- Extensible Markup Language
  • a “Webified” simplification of SGML, the Standard Generalized Markup Language, widely used in “high-end” or “database” publishing to separate logical structure from presentation
  • instead of a fixed set of format-oriented tags like HTML, XML allows you to create whatever set of tags are needed for your type of information
  • this makes any XML instance “self-describing” and easily understood by computers and people
  • XML-encoded information is smart enough to support new classes of Web applications
xml s big idea document types
Customer Profiles

Vendor Profiles

Catalogs

Datasheets

Price Lists

Purchase Orders

Invoices

Inventory Reports

Bill of Materials

Payments

Deposits

Credit Reports

Bank Statements

Directories

Transportation Schedules

Receipts

many many more...

XML’s Big Idea: Document Types
document types and dtds
Document Types and DTDs
  • “Document type” captures the distinctions between documents that make a difference
  • The Document Type Definition or DTD defines:
    • the class of documents that shares a common information model
    • permissible elements and attributes, their contents, the order in which they occur
  • The DTD is the “content model” or “document schema” or “document grammar” that makes an instance “self-describing” and turns document collections into databases
dtds parsers and validation
DTDs, Parsers, and Validation
  • From any DTD an XML parser can be generated that:
    • reads a document instance (the XML data stream)
    • identifies the markup in it
    • creates a “parse tree” or “event stream” in which the structured message is arranged to be passed off to applications
  • The parser can also test the XML document for conformance with the rules of the DTD
    • A document instance that follows the rules of the DTD is “valid”
laptop computer in xml
Laptop Computer in XML

<COMPUTER TYPE=“Laptop”>

<MANUFACTURER>IBM</MANUFACTURER>

<LINE>Thinkpad</LINE>

<MODEL>600E</MODEL>

<SPECIFICATIONS>

<SPEED UNIT=“MHz”>400</SPEED>

<MEMORY UNIT=“MB”>64</MEMORY>

<DISK UNIT=“GB”>8</DISK>

<WEIGHT UNIT=“POUND”>4.1 </WEIGHT>

<PRICE CURRENCY=“USD”>3200</PRICE>

</SPECIFICATIONS>

</COMPUTER>

smarter processing enabled by xml
Smarter Processing Enabled by XML
  • <COMPUTER> and <SPECIFICATIONS> provide logical containers for extracting and manipulating product information as a unit
    • Sort by <MANUFACTURER>, <SPEED>, <WEIGHT>, <PRICE>, etc.
  • Explicit identification of each part enables its automated processing
    • Convert <PRICE> from “USD” to Euro, Yen, etc.
airline schedule in xml
Airline Schedule in XML

<TransportSchedule Type=“Airline”>

<Segment Id=“United Airlines #200”>

<Origin>San Francisco</Origin>

<DepartTime TZ=“PST”>11:30 </DepartTime>

<Destination>Honolulu</Destination>

<ArriveTime TZ=“HST”> 2:30 </ArriveTime>

<Price Currency=“USD”>368.50</Price>

</Segment>

</TransportSchedule>

example model for transport
Example: Model for Transport

Using the same model for all scheduled transportation services:

<TransportSchedule Type=“Airline”>

<TransportSchedule Type=“Train”>

<TransportSchedule Type=“Ferry”>

An application could create itineraries that involve more than one service by matching on locations and times

shared semantics for time and location
Shared Semantics for Time and Location

Shared semantics for location and time in related models that need them enables richer “commerce networks” of services:

<TransportSchedule Type=“Airline”> …

<Destination>Honolulu</Destination>

<Accommodation Type=“Hotel”>...

<Destination>Honolulu</Destination>

<Event Type=“Concert”>…

<Destination>Honolulu</Destination>

xml as technology platform
XML as Technology Platform

.. exchange data in an application and vendor neutral format

XML

WEB

EDI

CORBA / COM

Document based

API

based

traditional business models and integration requirements
Traditional Business Models and Integration Requirements
  • Traditional models for electronic business are based on long-term, point-to-point, and tightly coupled relationships
    • EDI is used here because high integration costs can be recovered over time
    • Partners are more willing to invest in compatible IT infrastructure at each end or in middleware that creates a distributed application
traditional integration challenge

Supply Chain

Customers

Enterprise

Indirect Procurement

Traditional Integration Challenge
internet business models and integration requirements
Internet Business Models and Integration Requirements
  • Internet enables new models for marketplaces, trading communities, outsourcing, open sourcing, buying consortia and “virtual enterprises” that are fundamentally different
the internet integration challenge networks of commerce communities

Assembly

Outsourcing

Distribution

Supply Chain

Customers

Enterprise

Indirect Procurement

Markets

Procurement

Outsourcing

The Internet Integration Challenge: Networks of Commerce Communities
internet business models and integration requirements1
Internet Business Models andIntegration Requirements
  • Relationships are experimental and evolving and have shorter lifetimes overall
  • Both initial integration cost and incremental cost to evolve must be low
  • Point-to-point coupling approaches won’t support “describe once, {sell,buy} anywhere” goals
  • Global scalability puts a premium on being able to accommodate variation, and to describe services and business entities with metadata to accommodate dynamic trading
networked trading communities new challenges
Networked Trading Communities: New Challenges
  • Paper-based import/export and regulatory requirements
  • Flexible roles in complex processes (Transport: the buyer may be the shipper, the seller may be the shipper, or it may be a 3rd-party forwarder, and this changes for each leg of the journey!)
  • Descriptions of goods must be flexible (customs) and localized (ordering, payments, etc.)
  • Trading conventions are explicit - not understood across regional boundaries
xml is part of the solution
XML is part of the Solution
  • XML has the potential to enable a standards-conforming, open and extensible architecture for electronic commerce
  • XML standards could enable ubiquitous connectivity and interoperability and create the network effects of “describe once, {sell,buy} anywhere” and reusable marketplace services
but edi is part of the solution too
But EDI is part of the solution, too...
  • We must preserve the business processes and expertise embedded in EDI
  • The transition from EDI to XML must overcome some challenges and must combine EDI expertise with cutting-edgeXML and repository technology
the transition from edi to xml1
The Transition from EDI to XML
  • Business Challenges
  • Technical Challenges from the Perspective of the “XMLers”
  • Technical Challenges from the Perspective of the “EDIers”
perspective of company creating a new internet marketplace

EDI

Benefit of Using XML Syntax

XML

Perspective of Company Creating a New Internet Marketplace

Implementation & Maintenance Cost

Time

perspective of edi enabled supplier

EDI

XML

Cost of creating XML document types and mapping to/ from EDI

Perspective of EDI-enabled Supplier

Implementation & Maintenance Cost

Time

xml edi
XML/EDI
  • Numerous initiatives underway to translate EDI concepts and specifications to XML
  • Some have modest incremental goal of translating X12 or EDIFACT data element definitions to XML syntax
  • Others envision a radical re-thinking of EDI
xml edi efforts
XML/EDI Efforts
  • Associated With “Official” Standards Organizations
    • X12C (and I, H, N...)
    • UN/EDIFACT
      • TMWG
      • SIMPL-EDI (e-Centre, UK)
      • CEN/ISSS
xml edi efforts1
XML/EDI Efforts
  • Industry Initiatives
    • OBI
    • RosettaNet
    • Commerce Net eCo Framework
xml edi efforts2
XML/EDI Efforts
  • Other
    • Common Business Library (Commerce One)
    • “UN XML” (EDI-TIE)
    • XML/EDI Group
    • Frankfurt University
technical challenges for the xmlers
Technical Challenges for the “XMLers”
  • Standards process takes too long
  • EDI subsets not standard and not formally defined
  • No formal starting points -> No standard transformation approaches
  • EDI message architecture mixes content, addressing, and business process choreography
  • Syntactic constructs in EDI messages leads to “anonymous” constructs in XML
technical challenges for the ediers
Technical Challenges for the “EDIers”
  • Anarchy in XML “Standards” -- pick any three letters and it’s an acronym for an XML initiative
  • DTDs, with their roots in structural modeling for publishing, lack sufficient modeling power to model constraints needed in EDI
  • But which XML Schema language to use?
  • Different architectures for separating content, addressing, and business process choreography
xml schema languages
XML Schema Languages
  • XML’s publishing roots give it structural modeling capabilities in DTDs but it encodes content as “just text” and can’t express structural relationships between document types
  • W3C XML Schema effort underway to allow models with strong datatyping and inheritance
goals for an xml schema language
Goals for an XML Schema Language
  • Use XML grammar, tools, and technology more ubiquitously
  • Replace DTDs -- DTDs are strange syntactically, so that XML tools that need information about DTDs don’t need to know how to read them (as long as they can parse an instance)
goals for an xml schema language1
Goals for an XML Schema Language
  • Make XML more friendly to programmers
    • more like database schemas, programming constructs (e.g. Java classes)
    • enable easier reuse of XML and associated code
goals for an xml schema language2
Goals for an XML Schema Language
  • Specify information that can’t be represented in DTDs (prohibited in “vanilla” XML because of SGML compatibility)
    • datatypes, not just strings
    • more constraints
    • inheritance
    • documentation as 1st class information (instead of comments, which can’t be programmatically processed)
xml schemas in electronic commerce
XML Schemas in Electronic Commerce
  • Essential to treat Dates, Monetary amounts, etc. as datatypes to enable validation
  • Schema inheritance and extension mechanisms allow custom versions of same document to co-exist
    • software can distinguish extensions from standard document
    • software can decide whether or not extensions can be safely ignored
the xml standards specifications hierarchy
The XML Standards & Specifications Hierarchy
  • Foundation Standards
    • W3C (www.w3.org): XML, XSL, XLL, Schema, etc.
    • IETF (www.ietf.org): Mime, WEBDAV, URNs, etc.
the xml standards specifications hierarchy1
The XML Standards & Specifications Hierarchy
  • Industry Consortia / Vertical Initiatives / Vocabularies
    • www.oasis-open.org/cover/xml.html#applications
    • www.xml.org/xmlorg_catalog.htm
    • www.biztalk.org
the xml standards specifications hierarchy2
The XML Standards & Specifications Hierarchy
  • Vendor-Driven Specifications
    • some are “quick and dirty” proprietary format in angle brackets (.org doesn’t mean anything!)
    • some are mature with trustworthy pedigree
business goals for industry consortia and vertical initiatives
Business Goals for Industry Consortia and Vertical Initiatives
  • Improve the efficiency of business processes
  • Adopt new Internet technologies in standard or compatible ways
  • Cooperate where everyone benefits to enable competition on a “higher level”
some influential xml specifications for electronic commerce
Some Influential XML Specifications for Electronic Commerce
  • RosettaNet (www.rosettanet.org)
    • IT supply chain
  • OBI - Open Buying on the Internet (www.openbuy.org)
    • B2B purchasing
  • OAG - Open Applications Group (www.openapplications.org)
    • enterprise applications
  • IOTP (www.iotp.org)
iotp internet open trading protocol
IOTP - Internet Open Trading Protocol
  • www.iotp.org
  • Purchasing protocol that is independent of the payment method (and allows for mixed payment models)
  • Started by Mondex and MasterCard, now includes other financial institutions and commerce technology companies
iotp architecture
IOTP - Architecture
  • Protocol defines exchanges between 2 parties: consumer, merchant, value acquirer, deliverer, and customer care provider
  • Transactions are message sequences: purchase, refund, value exchange, authentication, withdrawal, deposit
  • Different sequences implement distinct payment models
iotp and xml messaging

Internet Open Trading Protocol

Specification

(version 1.0)

IOTP and XML Messaging

DomainSpecific

  • How to do purchases
  • How to exchange messages:
    • Digital Signatures, reliable transfer, error reporting, audit trails

Generic

IOTP 2.0 splits in two: IOTP and XML Messaging

observations about xml verticals
Observations about XML Verticals
  • Start vertical, but creep into horizontal
  • Start with content, but creep into architecture
    • Component granularity and hierarchy
    • Envelope or message model
    • Transport and choreography protocols
  • Little success in harmonizing content or architecture even with “nearby” specifications
xml and metcalfe s law
XML and Metcalfe’s Law
  • The value of a language depends on how many people (or computers) understand it
  • How do you encourage and enable others to understand your language?
xml and metcalfe s law1
XML and Metcalfe’s Law
  • Traditional EDI approach:
    • BIG COMPANY: Speak MY language or I won’t do business with you!
    • SMALL COMPANY:Yes, master.
xml and metcalfe s law2
XML and Metcalfe’s Law
  • The XML approach:
    • Excuse me, please, here are the rules of my language if you’d like to speak with me…
interoperability initiatives
Interoperability Initiatives
  • Common Business Library (xCBL)
  • BizTalk
  • XML Registries and Repositories
    • XML.org
    • BizTalk.org
  • CommerceNet eCo Framework
  • ebXML
attacking the interoperability problem
Attacking the Interoperability Problem

XML/ EDI

Pinnacles

OTP

Computer

Automotive

Consumer

OFX

SCOR

OBI

Office

HL/7

Supply Chain

Procure

Retail

Manufacturing

Healthcare

Appliances

CommonBusinessLibrary

the common business library
The Common Business Library
  • www.xcbl.org
  • The first “horizontal” XML specification (started 3/97, partly funded by US Department of Commerce (NIST ATP) program on “component-based commerce”))
    • a set of reusable XML components that are common to many business domains
    • defined using an XML schema language
    • a framework for creating documents with a common architecture
  • Documents built and extended according to the CBL frameworks can be understood from their common message elements
cbl building blocks
CBL Building Blocks

CBL Documents

Business Descriptions

Business Forms

Vendor

Catalog

core

Services

Purchase Order

core

Products

Invoice

Measurements

Locale

Classification

Time

Address

SIC

core

Currency

Country

NAICS

core

Weight

Language

FSC

core

cbl building blocks1
CBL Building Blocks

CBL Documents

Business Descriptions

Business Forms

Vendor

Catalog

core

Services

Purchase Order

core

Products

Invoice

Measurements

Locale

Classification

Time

Address

SIC

core

Currency

Country

NAICS

core

Weight

Language

FSC

core

cbl building blocks2
CBL Building Blocks

CBL Documents

FedEx Airbill

Business Descriptions

Business Forms

Vendor

Catalog

core

Services

Purchase Order

core

Products

Invoice

Measurements

Locale

Classification

Time

Address

SIC

core

Currency

Country

NAICS

core

Weight

Language

FSC

core

cbl document architecture for b 2 b
CBL Document Architecture for B 2 B

Market Registration

Company Name

Address

Agent Name

Title

Role Buyer

Purchase Order

Buyer Name

Address

Product SKU Number

Manufacturer

Model

Order Quantity

Price

Payment Method

Account Number

Catalog Description

SKU Number 10023

Product Type Laptop

Manufacturer IBM

Model ThinkPad 560

Speed 166MHz

List Price $3500.00

Wallet

Card 1 American Express

123-234-4444

Card 2 Visa

001-234-5678

ERP Query

SKU Number 46747456

In Stock 6

Customer Price $1500.00

cbl 1 x example address
CBL 1.x Example -- “Address”
  • Sophisticated structure in physical address
    • building.sublocation ("43rd floor, Suite 100”)
    • city.subentity (“Mission District”)
  • Calculated address in arbitrary coordinate systems
    • GPS
    • GIS
cbl 1 x lessons learned
CBL 1.x Lessons Learned
  • CBL 1.0 too abstract for comfort for XML “newbies” and EDI backgrounds
    • People prefer electronic analogues to familiar business forms
    • Don’t give them more expressive power than they need
  • “Off the shelf” tools weren’t ready for expressive power of CBL 1.-
  • Extensibility mechanisms in DTDs are powerful but extremely complex
cbl 2 0 re design principles 1999
CBL 2.0 Re-design Principles (1999)
  • Less abstraction, even if it means redundancy or less expressiveness
  • Greater compatibility with EDI standards and semantics
  • Harmonize where possible with OBI, RosettaNet, other vertical applications to meet the needs of B2B
  • Design to exploit emerging capabilities of XML Schema languages
xcbl 2 0 document types
xCBL 2.0 Document Types
  • Asynchronous Document Exchange
    • Purchase Order and Response
    • Product Catalog Description and Pricing
    • Invoice
  • Synchronous Document Exchange
    • Price Check Request and Result
    • Availability Check Request and Result
    • Order Status Request and Result
coming soon to xcbl
Coming Soon to xCBL
  • Order Request (“round trip”)
  • Change Order
  • Advance Ship Notice
  • Extended Invoice (to support payment, taxation, etc.)
  • Expanded Catalog Documents
benefits of combining edi and xml
Benefits of Combining EDI and XML
  • EDI standards provide a strong non-proprietary semantic foundation for CBL
  • Companies using EDI today see a clear migration path in CBL for mapping from EDI applications to XML
  • SMEs for whom EDI is not cost-effective can use CBL in simple Web applications to interoperate with EDI partners
marketplace operator s perspective with cbl

EDI

Benefit of Using XML Syntax

XML

Benefit of Using XML Schemas and Component Library (CBL)

CBL

Marketplace Operator’s Perspective with CBL

Implementation & Maintenance Cost

Time

supplier s analysis with cbl

CBL

Benefit of Mapping EDI to/from CBL

Supplier’s Analysis with CBL

Implementation & Maintenance Cost

EDI

XML

Time

domain vertical xml analysis with cbl

Benefits of vertical stds

Vertical XML Standards

Benefit of CBL as the “hub format” (to turn integration from NxN to 2N)

CBL

Domain/Vertical XML Analysis with CBL

Implementation & Maintenance Cost

XML

Time

ebxml
ebXML
  • www.ebxml.org
  • A joint initiative of UN/CEFACT and OASIS to lead a project that brings together the key initiatives throughout the world to harmonize the design principles and specifications for XML/EDI and future XML applications for commerce
  • Commerce One is an active participant in every technical working group
ebxml technical working groups
ebXML Technical working groups
  • Technical architecture
  • Core components
  • Transport, routing and packaging
  • Registry and repository
  • Business process
slide83

MIME Wrapper

Header, Manifest, Routing, Digital Signatures, etc.

Message Envelope

Document Components

Repository

slide84

Business Processes are Document Exchanges

If you send me a request for a catalog, I will send you a catalog

If you send me a purchase order and I can fulfil it, I will send you a purchase order response

the vision of plug and play commerce
The Vision of “Plug and Play” Commerce
  • All Web commerce sites and services are treated as reusable components whose interfaces are expressed as documents
  • These “market participants” interoperate because they share a common semantic framework based on XML
  • They can be linked to create virtual companies, markets, and trading communities
what is an internet market or trading community
What is an Internet Market or Trading Community?
  • The “market maker/operator”
  • The participating businesses
  • The services these businesses provide to each other
  • The messages and documents that are exchanged to request and perform the services
markets or trading communities
Markets or Trading Communities
  • Manufacturing supply chains
    • Computers, electronics, automotive, aerospace, retail ...
  • Financial services
    • Banking, real estate, insurance, securities ...
  • Healthcare
    • HMOs, hospitals, physicians, insurance, labs, ...
  • Travel
    • Hotels, airlines, rental car agencies, travel agents …
  • Publishing and education
    • Publishers, universities, content creators, trainers ...
functions of internet market makers
Functions of “Internet Market Makers”
  • Creating a community based on information exchange standards
    • Aggregating buyers to create new sales channels
    • Aggregating seller catalogs, with semantic integration (standard classification and description)
    • Routing documents between partners
    • Providing standard interfaces for shared services (registration, logistics, taxation, payment, etc.)
shared information models among
Shared Information Models Among...
  • Supply Chains
      • Merchants, distributors, manufacturers, brokers, logistics, shippers
  • Real Estate
      • Brokers, banks, escrow, title, inspection, MLS, government agencies, classifieds, loan aggregators
commerce chain solution
Commerce Chain Solution

Content Management

Transaction Management

Commerce Services

Buyers

Suppliers

BuySite

MarketSite

commerce one s solutions
Commerce One’s Solutions
  • BuySite 6.0
    • Enterprise procurement application (also available as a hosted service through MarketSite)
  • MarketSite 3.0
    • Platform for open business-to-business portals, marketplaces and trading communities
  • MarketSite.Net
    • The first open B-B commerce portal, serving North America
  • Global Trading Web
    • The world’s largest B-to-B marketplace
    • A consortium of regional and vertical portals linked through GTW.net and subscribing to principles of the GTW Council
the marketsite platform
The MarketSite Platform

Content Management

Transaction Management

Commerce Services

Buyers

Suppliers

MarketSite

BuySite

open to all buying applications
Open To All Buying Applications

Content Management

Transaction Management

Commerce Services

Buyers

Suppliers

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

open to all selling applications
Open To All Selling Applications

Content Management

Transaction Management

Commerce Services

Buyers

Suppliers

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

3rd-party Apps

hosted applications
Hosted Applications

Content Management

Transaction Management

Commerce Services

Hosted Applications

Buyers

Suppliers

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

3rd-party Apps

open to third party services

3rd-party Services

Buyers

Suppliers

Capital

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

3rd-party Apps

Open To Third-Party Services
  • Bid & Auction
  • Exchanges
  • Aggregation
  • Settlement
open to commerce portals

Capital

Open To Commerce Portals

3rd-party Services

Commerce Portals

Buyers

Suppliers

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

3rd-party Apps

marketsite net

Capital

MarketSite.net

3rd-party Services

Commerce Portals

Buyers

Suppliers

MarketSite

BuySite

3rd-party Apps

Proprietary Apps

3rd-party Apps

marketsite based trading communities

Supply Chain Portal

Hospitality Portal

MarketSite.net

SME Portal

Healthcare Portal

Automotive Portal

Biotech Portal

Marketsite-Based Trading Communities
marketsite based trading communities1

Supply Chain Portal

Hospitality Portal

MarketSite.net

SME Portal

Healthcare Portal

Biotech Portal

Marketsite-Based Trading Communities

Automotive Portal

global trading web

Cable & Wireless

Global Trading Web

Computers

Electronics

Steel

how xcbl builds an open trading network
How xCBL Builds an “Open Trading Network”
  • Every Marketsite community starts with the core set of xCBL documents and extends them to meet its specialized needs
  • As new services are added to core Marketsite, new xCBL documents are developed to support them
  • Vertical and regional Marketsites interoperate on the basis of their shared xCBL documents
  • Even non-Marketsite marketplaces can interoperate if their services can produce and consume xCBL documents
alternate e commerce standards integration

Alternate E-Commerce Standards Integration

... different Trading Partners will want to use different eCommerce standards …

RosettaNet

BizTalk

EDI

OBI

OAG

ebXML … someday

alternative approaches
Alternative Approaches
  • “Connector” Approach
    • anyone who wants to connect to MarketSite can use Commerce One technology on both ends to send and receive documents
  • “Gateway” Approach
    • Trading partner does no additional work
    • MarketSite accepts or sends the alternative protocol in its native form
    • MarketSite Operators can charge transaction fees for conversion service
the gateway approach continued
The Gateway Approach .. continued
  • Trading Partner sends/receives using alternate E-Commerce standards
  • MarketSite responsible for
    • Document Mapping
      • xCBL as the Lingua France
      • Many to one to Many mapping
    • Understanding the alternate standard
      • Document Choreography
      • Messaging
      • Transport Protocol
protocol handlers

EDI/MSRouter

MS/EDI-xCBL Handler

  • Map EDI Transaction/ Envelope headers to XML
  • Map EDI Transaction Data to XML
  • Construct Message to output format required
  • Identify how to send the message and then . . .
  • SEND IT !!

XCC

Protocol Handlers

MS/EDI-xCBLHandler

protocol conversion what you must get right
Protocol Conversion - what you must get right !!

EDI & xCBL documents must contain equivalent data items. Any missing data items must not result in an invalid document.

Documents

The sequence in which documents are exchanged by the businesses involved must be agreed . This is hard to enforce

Document Choreography

The way documents are wrapped (e.g. MML) must be understood at each end. Reliable messaging (e.g MQ Series) must be compatible.

Messaging

Compatible transport protocols and transport level security are required, e.g. use of HTTPS, etc

Transport Protocols

summary
Summary
  • XML has tremendous potential to enable a standards-conforming, open and extensible architecture for electronic commerce
  • But as “Vertical” or “Industry” XML initiatives continue to proliferate, interoperability has emerged as a challenge
  • Numerous efforts are underway to enable interoperability, especially for XML/EDI
  • The Global Trading Web vision -- based on xCBL and ebXML -- embodies and exemplifies XML support for interoperability