Philosophical Excursus IV The picture of an ironist who is ...
The Universal Business Language: An Excursus Eve Maler Sun Microsystems.
-
Upload
bennett-oneal -
Category
Documents
-
view
220 -
download
6
Transcript of The Universal Business Language: An Excursus Eve Maler Sun Microsystems.
The UniversalBusiness Language:
An Excursus
Eve Maler
Sun Microsystems
A little about me
• My specialties are:– XML information modeling– Standards development and facilitation
• I’m on the OASIS UBL Technical Committee and I chair one of its major subcommittees
• I fill several key roles on the SAML standard effort• In previous lives I helped develop DocBook, XML
itself, XLink, Pipeline, and more– And wrote a book on SGML DTD design methodology
Overview
• Promises, promises• EDI and ebXML• The UBL problem space• Making UBL happen• ebXML Core Components• The UBL modeling methodology• Designing the UBL schemas• Contextualizing UBL• UBL status• Resources• Summary
Promises, promises
The promise of XML fore-business?
• Plug ‘n’ play electronic commerce• Spontaneous trade• No custom programming• Ubiquity on the Internet• Dirt-cheap tools• Complete platform independence
Unfortunately, it’s not that simple
• It’s very difficult, and maybe not even desirable, to take the humans out of business– Building trust relationships– Exception handling
• XML is just a metalanguage– Tag soup doesn’t give you interoperability– Seamless communication requires shared meaning– Shared meaning requires semantic standardization across
whole industries– This is where UBL comes in
The Universal Business Language
• An XML-based business language standard-in-progress
• Leverages existing EDI and XML B2B• Applicable across all industry sectors and domains of
electronic trade• Actually modular, reusable, and extensible• Non-proprietary and committed to freedom from
royalties• Intended to become a legal standard for international
trade
UBL offers some realistice-business promises
• Genuine advantages over EDI and proprietary/vertical XML B2B:– Lower cost of integration, both among and within enterprises– Lower cost of commercial software– Easier learning curve– Lower cost of entry– Quicker adoption by small and medium-size enterprises
(SMEs)– Standardized training– Universally available pool of skilled workers
EDI and ebXML
The EDI stack
VANPackaging/transport
CASE toolBusiness processes
Ad hoc TPABusiness agreements
EDIFACT,X12
Standard messages
MIGsMessage
contextualization
Infra-structure
Payload
Some EDI pressure points
• It’s hard to get in the game• Private networks are expensive• You need to do extensive point-to-point
negotiation• The interchange pipe is large, with infinite
possible subsets• You use a “soft” mechanism for adapting to
special business contexts
The ebXML initiative
• A joint 18-month effort, concluding in May 2001, of:– OASIS (Organization for the Advancement of Structured
Information Standards)– UN/CEFACT (United Nations Centre for Trade Facilitation
and Electronic Business)
• Over 1000 international participants• The vision: a global electronic marketplace• Enterprises of any size, anywhere, can:
– Find each other electronically– Conduct business by exchanging XML messages
• ebXML work continues in several venues
The ebXML stack
Packaging/transport
Business processes
Business agreements
Standard messages
Messagecontextualization
MessageService
BPSS
CPP/CPA
CoreComponents
Contextmethodology
Reg/Rep
Discovery/retrieval
ebXML status
• The infrastructure specifications are all maturing; most are past V2.0– The Reg/Rep spec has been approved as an OASIS
Standard
• The payload specs are in active development• Conformance tests are being developed• Industry groups are endorsing ebXML
– OTA, AIAG, RosettaNet, and more
• Products, open source implementations, interop events, and pilots are happening
• Both “sanction” and “traction” are well on their way
The UBL problem space
Some basic requirements
• Semantic clarity through a binding from Core Components to a syntax
• Choosing XML as that syntax!• Royalty-free IPR• Usable “on the cheap”• No ties to particular back-end
implementations• Urgency
The requirement for context
• “Standard” business components need to be different in different business contexts– Addresses differ in Japan vs. the U.S.– Addresses in the auto industry differ from those for
other industries– Invoice items for shoes need size information; for
coffee, grind information
• These differences need to be accommodated without sacrificing interoperability
UBL proposes to meet all these requirements
Packaging/transport
Business processes
Business agreements
Standard messages
Messagecontextualization
MessageService
BPSS
CPP/CPA
Core Components
Context methodology
Reg/Rep
Discovery/retrieval
UBL Library
UBL context meth
Where UBL can fit into existing XML B2B
ChemicalMfr C
C’s industrypartners
CIDX
Hospital B
B’s industrypartners
HL7
ElectronicsMfr A
A’s industrypartners
RosettaNet
Making UBL happen
The standards venue
• UBL is being developed in an OASIS Technical Committee– Like most of the follow-on ebXML infrastructure projects– The follow-on Core Components and Business Process
projects are in UN/CEFACT
• OASIS offers:– An objective process– Openness of its work to public view in real time– Easy and inexpensive opportunities to join
• Jon Bosak is the chair and main founder
Some UBL participants
APACSBoeingCommerce OneDanish Bankers AssociationFrance TelecomGeneral ElectricGovernment of HongkongGovernment of KoreaHPIntuitKPMGLMI
Northrup GrummanOraclePricewaterhouseCoopersSAPSeeBeyondSterling CommerceSun MicrosystemsUK Cabinet OfficeUnited Parcel ServiceU.S. GSAU.S. NavyVisa International
UBL’s relationship with ebXML
• UBL is not actually an “ebXML deliverable”• UBL mandates no particular messaging
framework• But we hope the combination will enable the
“B2B web”– HTTP + HTML = web publishing– ebXML + UBL = web commerce
Development strategies
• Start with the low-hanging fruit– The 20% of documents and business objects actually used
by 80% of electronic business partners
• Defer the rocket science to later phases– Produce useful, concrete outputs ASAP
• Don’t start with a blank slate– We are working from xCBL 3.0– But with no expectations of backwards compatibility
• Take advantage of domain expertise– Get XML experts and business experts together and form
liaisons
Formal liaisons so far
– ACORD (insurance)– ARTS (retail sales)– e.centre (UK EAN.UCC)– EIDX (electronics)– HL7 (healthcare)– NACS (convenience stores)
– RosettaNet (IT)– SWIFT (banking)– VCA (optical supplies)– XBRL (accounting)– ASC X12 (EDI)– UN/CEFACT (EDI)
UBL subcommittee organization
• Modeling and content– Library Content SC– Context Drivers SC– (future domain-specific)
• XML representation and mechanisms– Naming and Design
Rules SC– Context Methodology SC– Tools and Techniques
SC
• Administrative functions– Marketing SC– Liaison SC– Subcommittee chairs SC
Planned deliverables
Phase 1: 2002• The UBL Library
– Reusable building blocks and standard document types
• Schema design rules– How to represent UBL in
XML/XSD
– How external modules can best work with UBL
• Simple context methodology– How to add context-based
extensions to UBL
Phase 2: 2003• Full-blown context
methodology– How to describe your
extensions in “recombinant” fashion
Basic UBL Documents
• Order
• Order Response (simple)
• Order Response (complex)
• Order Change
• Despatch Advice (shipping notice)
• Receipt Advice
• Invoice
More about the UBL Library deliverables
• The normative W3C XML Schema (XSD) modules• Documentation• Potentially several non-normative forms:
– UML– ASN.1– Other schema representations– Modified XSD
• Potentially stylesheets for:– Viewing and printing UBL documents– Generating EDI-compliant instances
• A secondary deliverable will be Core Components feedback
Design principles
• Straightforward Internet use• “Various and sundry” tools• Legibility• Simplicity• 80/20 rule• Component reuse• Provide one way to encode
information• Customization and
maintenance• Context sensitivity
• Prescriptiveness, tempered• Content orientation• XML technology• Namespace dependency
caution• Legacy format non-goal• xCBL subset non-goal• (Schema generation)• …• …
ebXML Core Components
Core Components status
• The Core Components Technical Specification, Part 1, is at V1.8– Known as CCTS
• Some features are still a matter of hot debate• Additional Core Components Supplementary
Documents work is ongoing– Known as CCSD
• Today’s tutorial reflects the current CCTS specification and not the newer or more controversial areas
A primer
is definedin context
as
is definedin context
as
Core ComponentType (CCT)
Aggregate CoreComponent (BCC)
Basic CoreComponent (BCC)
Aggregate BusinessInformation Entity
(ABIE)
Basic BusinessInformation Entity
(BBIE)is of type
Core Business
Message/Document
More on Core Component Types
• CCTs are conceptually similar to the notion of built-in datatypes in XML– The spec offers a closed set of them– But this comparison says nothing about their schema
representation, such as simple vs. complex types
• Current CCTs:– Amount – Measure– Code – Numeric– DateTime – Picture– Graphic – Quantity– Identifier – Text– Indicator
Mapping to data elements
• CCTS constructs follow ISO 11179– Semantic clarity of data elements (CCs and BIEs) is
achieved through careful naming and definition in a dictionary
• A CC or BIE gets a tripartite dictionary name– The object class to which the data element belongs– A term reflecting its function as a property or distinguishing
characteristic of the object class– A representation term (RT) defining the data element’s
valid values
• RTs are closely related to CCTs• Example dictionary name: Car.Colour.Code
More on the notion of business context
• An example of an ACC might be “address”– It’s aggregate because it’s a collection of other
CCs– As a CC, it strives to be semantically unique and
useful
• An example of an ABIE might be “buyer address”– As a BIE, it strives to identify the business
circumstance in which the CC is used– The dictionary name would be Buyer.Address.Details
Mapping the CC world to XML and XSD (1 of 2)
• XSD has an indirect cascade of types and elements– With attributes working pretty much the way
elements do
Element declaration
Type definition
Type definition
references
is bound to
Mapping the CC world to XML and XSD (2 of 2)
• XSD’s OO-like approach can neatly be mapped to ISO 11179 object classes and properties
Property(element decl)
Object class(type defn)
Object class(type defn)
has
is defined in terms of
The UBL modeling methodology
The approachConceptual View (BOV)
logical models
Technology View (FSV)physical models
The Real Worldmessages/documents
UNSM
Forms XML
DBs
Directories
Schemas
Core ComponentCore ComponentCore Component
anal
yze
BIEsBIEsBIEContextContextContextdesign
UNSMDirectories
Schemas
enco
de
imp
lemen
t
form
at
Forms XML
DBs
The inputs
• Documents/expertise from:– The members of the Library Content SC– Organizations with a liaison to the UBL TC– Feedback from the general public
• xCBL 3.0– A working XML business vocabulary for several years– Has lots of EDI knowledge baked into it
• ebXML CCs– Ultimately, as many UBL constructs as possible will be
mapped to the final form of CCs– Where there’s no match, this will be fed back to the CC
project
The modeling steps
1. Working from an xCBL document type, analyze its constituent constructs to identify BBIEs and ABIEs
2. Establish each BIE’s dictionary name, UBL name, definition, and business context
3. Establish its cardinality/optionality within its object class
4. Identify missing BIEs
5. Identify which BIEs are reusable
6. Assemble an appropriate UBL document type from the BIEs
The formalism
• A spreadsheet with carefully designed columns
The back end
Spreadsheet Schema modulefor CCTs
Schema module forreusable BIEs
Schema modules forfunctional areas
(e.g. Order)
automated process
modeling handcrafting
Samples
• Schema
Designing the UBL schemas
How the design rules fit into schema creation
Spreadsheet Schema modulefor CCTs
Schema module forreusable BIEs
Schema modules forfunctional areas
(e.g. Order)
automated process
modeling handcrafting
Rules
RulesGuidelines
Some major design rules developed so far
• The choice of normative schema language• Naming and construction of elements,
attributes, and types (mostly done)• Modularity, namespaces, and versioning
(partial)• Embedded schema documentation (draft)• Handling code lists
The choice of schema language
• We chose W3C XML Schema (XSD)– The other seriously considered choices were RELAX NG
and Schematron
• Main positives:– Traction in the industry– Tools availability
• Main concerns:– Interoperability– Lack of support for Boolean operations
• We have not foreclosed on generating other schema versions– But they would be non-normative
A taste of the naming rules
• Dictionary entry names are fully qualified with object class names
• But using these full names would result in hundreds of extra elements
• We get reusability by allowing properties (elements) to “inherit” parent object classes (types), XPath-style– Delivery schedule IDs and order IDs could both be called
<ID>– Each would be identifiable by means of //Order/ID and
//DeliverySchedule/ID respectively
Schema modularity
Order
= RootSchema
= namespace
urn:oasis:names:tc:ubl:<version?>:
CommonAggregateTypes
CommonAggregate
Types
urn:oasis:names:tc:
ubl:<version?>:Payment
Invoiceetc.
urn:oasis:names:tc:
ubl:<version?>:Procurement
POetc.
urn:oasis:names:tc:ubl:<version?>:CommonLeaf
Types
Common LeafTypes
urn:
= InternalModule
= import
= include
. . .
Embedded documentation
• Datatypes are annotated with UBL-related metadata
• XHTML Basic is used in a conventional way to indicate the fields <xsd:documentation>
<xhtml:div class=“Object_Class"> <xhtml:p>Delivery</xhtml:p> </xhtml:div> <xhtml:div class=“Property_Term"> <xhtml:p>Schedule</xhtml:p> </xhtml:div> . . .<xsd:documentation>
Encoding code lists
• UBL will seek to import external datatype definitions in a conventional XSD form– Helping external
organizations to create rigorous schemas
– Defining a unique UBL element for each kind of code
• We hope to promote a global code list marketplace with this idea
<CountryIdentificationCode>
<ISO3166CountryCode
xsi:type=“iso3166:CodeType”>
BE
</ISO3166CountryCode>
</CountryIdentificationCode>
UBL country code element
UBL ISO 3166 element(bound to iso3166:CodeType)
Contextualizing UBL
Context drivers
• The ebXML work identified eight top context drivers:– Business process– Industry– Product classification– Geopolitical region– Primary and supporting business roles– System capabilities– Official constraints
• For example, “selling nuclear cereal to Finland” will have specific values along these axes
• This set probably needs to be extensible
The “eight-space”
• UBL defines BIEs, not CCs – they have a bit of real context in them– Typically just the
business process– Everything else should
ideally be “zeroed out”
• A set of eight values identifies a unique business context– A trading community can
associate their schema customizations with it
A
BC
Phase 1 – context disclosure
• Customizers will be expected to:– Handcraft an XSD
derivation, adhering to XSD extension and restriction rules
– Provide context driver metadata, adhering to UBL context derivation rules
• A context hierarchy will mirror the XSD type hierarchy
UBL purchase orderline item
U.S. purchase orderline item
Japan purchaseorder line item
U.S. purchase orderline item for shoes
geo="US"
(geo="US")prodclass="shoe"
geo="Japan"
Phase 2 – machine application of context
• Customizers will be able to describe the desired schema changes in an abstract, “recombinant” way
• These context rules will be applied by an engine to input schemas to get contextualized schemas
• A subtle and difficult problem!
UBL status
Completed work
• The procurement document types are well along
• The payment document types will be next• The common aggregate types (reusable
BIEs) grow with analysis of every document• The common leaf types (CCTs) are
perfunctory right now• The NDR SC intends to put itself out of work
by the end of 2002
Meeting schedule
• The UBL TC meets only F2F– Email ballots are allowed by our rules
• The larger SCs meet frequently by phone and do some work by email– Library Content (LC) and Naming and Design
Rules (NDR) are the hot areas right now
• If you’re interested in joining, let me know– You must be an organizational or individual OASIS
member– Individual membership is US$250/year
Resources
Where to find more information
• OASIS UBL TC– www.oasis-open.org/committees/ubl/– www.oasis-open.org/committees/ubl/lcsc/– www.oasis-open.org/committees/ubl/ndrsc/– www.oasis-open.org/committees/ubl/cmsc/– White papers, presentations, and specifications are available– All mailing list archives are open to public view
• ebXML– www.ebxml.org
• Core Components– www.ebtwg.org
How to comment
• The UBL comment list is open to all– Archive:
lists.oasis-open.org/archives/ubl-comment– Signup:
lists.oasis-open.org/ob/adm.pl
• The Library Content and NDR SCs have spreadsheet forms for providing feedback
Summary
I hope you feel UBL has what it takes to be successful
• User-driven, with deep partnership resources to call on
• Focused on global requirements, with a commitment to true horizontal trade
• A transparent standards process• Reuse of existing standards• A modularized structure based on a crucial B2B data
dictionary• Dedicated to interoperability, even in customized
form
Thanks!Questions?