Practical ebXML Registry uses for interoperable eBusiness

1. Practical ebXML Registry uses for interoperable eBusiness Open Forum 2003 on Metadata Registries 8:40am to 10am January 22, 2003

2. Presenter • David Webber • co-author of ‘ebXML – the new global standard for doing business via the internet’, New Riders Publishing • Chair of the OASIS CAM TC • Co-chair of OASIS/CEFACT ebXML JMT • Pioneering XML eBusiness drrwebber@acm.org http://drrw.net

3. Agenda • Part 1 – XML integration • W3C approach – web-centric • ebXML approach - • Registry-centric / assembly / core components • Upcoming Registry developments • ebXML V3.0 enhancements • Partner discovery / UDDI • Part 2 – Demonstration / Technologies • Review of OAGIS V8.0 technology • ebXML Registry and Content Classification • Summary / Q&A

4. ebXML Registry Part 1

5. Electronic Business Technologies

6. ebXML Adoption Q4 - 2002

7. Standards Chemistry Traction XML W3C web services SOAP v1.1 SOAP v1.2 W3C BPSS CEFACT eb MS v2 OASIS ebXML spec’s Market Adoption WSDL v1.2 W3C WSDL v1.1 CCSD CEFACT OAG BODs eb Reg v2 OASIS UMM/ UML UDDI v3x OASIS UDDI v3 UDDI.org Content Assembly UBL XML SGML ISO UN/EDIFACT Proprietary JCV Consortia SDO Standing Open Standardization

8. W3C approach Web-centric

9. The need for XML • XML – eXtensible Markup Language. • XML makes data portable. • XML is a global standard with pervasive use. • XML can be built from any structured data (DB’s, EDI, TEXT).

10. XML is self-annotating <?xml version=“1.0”?><Data> <Item ID=“112”> <Name>Rod</Name> <Price>12.00</Price> <Units>1</Units> </Item> <Item ID=“114”> <Name>Reel</Name> <Price>15.00</Price> <Units>1</Units> </Item> <Item ID=“120”> <Name>Bait</Name> <Price>24.00</Price> <Units>3</Units> </Item> </Data>

11. XML Management Challenges <lat_deg>30N</lat_deg> <latitude units=“degrees” hemisphere=“north”>30</latitude> <latitude> <hemisphere>N</hemisphere> <degrees>30</degrees> </latitude> • These 3 XML fragments are: • Equally valid ways to express the same data in XML • Well-formed per W3C Specification • Different terms and syntax NOT INTEROPERABLE!

12. Lessons Learned Expect Heterogeneity! • No Single Standard can be imposed! • Various industry communities will adopt multiple “standards:” • Government (message, database, symbology), Commercial, International, de facto/legacy etc.

13. W3C Schema Provides • Definition of all permitted element structural combinations • Ability to define local typing constraints • Ability to create re-usable chunks of structure elements

14. W3C Schema weaknesses • Permitted combinations of attributes within elements • Content assembled from multiple namespaces and cross-associations • Context mechanism has to be externally resolved using XSLT • All semantics are in the schema

15. ebXML Approach • registry-centric • assembly and context • core components • legacy non-XML payloads

16. What does ebXML do? • “Who, What, When, How” • Trading Profile Management and Discovery. • Assembly of transaction content. • Establishing consistent data definitions • Business Process Collaboration. • Message Handling Services • Web Services

17. ebXML Registry Mission • Collaboration - give industry groups and enterprises the ability to share business semantic information and business process interfaces. • Semantics - provide universal infrastructure that seamlessly delivers semantic integration into business applications. • Interfaces - open deployment machine-to-machine and user web enabled visual.

18. Registry Interactions : Interchange XML/ EDI Information Profiles and Transform Mapping Templates Industry Business Standards Registry Protocol Standards ebXML, ISO11179, OASIS, UDDI, xCBL, RosettaNet, Biztalk Registry User Interface Registry Search Tools and Information Engine Business Analyst Access Content / Rules Program Level Semantics Software Developers / Tools

19. ebXML Registry capabilities • Provides services for sharing information • Provides publishing and discovery of information • Accessible as a web service • Communicates using XML based request and responses • Provides mechanisms to store and retrieve persistent information • Includes a Repository

20. XML itself is not enough • XML, by itself, does not solve interoperability problems yet it is an important tool for doing so. • XML does not provide semantics. • XML by itself is not the magic bullet. • What we really need is a consistent set of methods for building interoperable eBusiness systems using XML – “railroads and telephony”.

21. XML Information Exchange Quality (and long-term consistency) ebXML Secure Authenticated Delivery and Tracking: ebXML Messaging system, envelope format and payload with exchange source profile (CPP) controls Delivery Assembly XML Content Assembly: Business logic for content structure decisions and explicit rules to enforce content, and interdependencies, with business exchange context, and content definition UID references Schema: Content structure definition and simple content typing Schema Registry/ Dictionary business information UID content referencing system ensures consistent definition usage UID

22. Consistent Meaning Business Collaboration Partner #1 Collaboration Partner #2 XML Instance XML Instance Data <ListPrice>9.99</ListPrice> <UnitPrice>9.99</UnitPrice> Machine-to-Machine <Currency>$</Currency>

23. Context Everywhere! Registry OAG304 Collaboration Partner #2 UnitPrice Dollars Collaboration Partner #1 ListPrice Currency Schema or Template Schema or Template <Rep href= “http://www.oag.org”>OAG</Rep> <ELEMENTrep= ‘OAG’name=‘ListPrice’uid =‘OAG304 > <Rep href= “http://www.oag.org”>OAG</Rep> <ELEMENTrep= ‘OAG’name=‘UnitPriceuid =‘OAG304 > XML Instance XML Instance Data <ListPrice>9.99</ListPrice> <UnitPrice>9.99</UnitPrice> <Currency>$</Currency> UIDs allow for domain crosswalks and light transactions

24. Classification Structure Taxonomies e.g. Dewey Decimal Industry HealthCare Automotive Retail Geography USA Japan Europe Toyota:object Ford:object BMW:object Nissan:object Chevy:object

25. Information Methodologies BOTTOM UPAPPROACH TOP DOWNAPPROACH UMM / UMLModeling UN/CEFACT CoreComponents Payload Metadata Final BusinessPayload PayloadMetadata Information Components LegacyData

26. Registry-centric benefits • Legacy payloads can be used “as is” • Supports vocabulary alignment and multi-lingual element tags • Minimizes overhead in payload itself – can be just simple structure • Provides ability to do automated mapping • Uses Content Assembly Mechanism to capture business rules and context parameters (OASIS CAM TC)

27. Business Process Pyramid Collaboration Partner Agreements Collaboration Partner Profiles 5 Contract Business Integration Registry Taxonomy BP Specification 4 Workflow Process XForms 3 Specifications Schema Messages Assemblies Artifact relationships Web Services 2 Motivation Time People Presentation Roles Rules Events Directory Services Technology Integration Data/Codes Services/Functions Network 1 ebMS/SOAP Nouns Verbs Secure content delivery

28. eBusiness delivery flow Collaboration Partner Profiles 1 Business Process Catalogue 2 Collaboration Partner Agreements To/From Partner Registry Events Roles Context Rules Messages 5 Verbs BP engine Messages Nouns 3 Verbs 5 Nouns Process Payload Content Assembly Templates 6 Secure Content Delivery 4 Messaging Assembly Templates Business Application Content Mapping Adaptors

29. Concept to Runtime Approach Business Re-usable Information Components- BRICs Registry Components Vocabularies and Industry Dictionaries Physical Conceptual Application Database Structure Choices 1 2 Required Content Structure 3 Payload Mapping Content Assembly Mechanism Template Process Engine Content References Context Values Payload / Rendering Logical

30. Assembly components

31. Registry Lookup

32. eBusiness Runtime Components Registry Server CPP/A BP Rules BPEE ebXML Message Content BPSS ebXML MS URL config Port Security I/O App Server Payload(s) O/S

33. Backend Integration Assembly Templates CPP/A BP Rules BPSS BPEE TRANSFORMS API ebXML MS I/O App Server Instance values Transform Templates O/S

34. Part 2 Upcoming Features, Implementing ebXML, and Registry Demonstration

35. Upcoming Registry Developments V3.0 ebXML, UDDI, ISO11179

36. New Features in Version 3.0 • Cooperating registries • Event notification • HTTP interface to registry • Content management services • Iterative query support

37. Cooperating Registries • Enables multiple ebXML Registries to work together to address user needs • Based on a loosely-coupled federation model • Allows local autonomy to each registry operator • Enables smaller registries to access resources of larger registries • Enables federated queries to multiple registries • Inter-registry object references • A registry may belong to multiple Federations

38. Event Notification • Enables notification of events regarding registry objects • Clients may be registry users or other registries • Leverages existing Registry Services interfaces • Subscription Service registers clients for notification • Supports e-mail notification and programmatic • Flexible notification options • References to event • Actual event • Objects affected by the event

39. HTTP Interface to Registry • Provides a pure HTTP interface to Registry • Does not require SOAP • Registry objects and Repository items addressable via URLs • Allows ebXML Registries to interoperate with other types of registries • Improves access to Registry content

40. Content Management Services • Enables content management based on object type • Content cataloging and validation • Validate on submission • Cataloging metadata applied on submission • Content-based publish, discovery and subscribe • User-defined relationships between content • Associations of internal and external classification • Invocation control file defines rules for cataloging service

41. Cataloging Invocation Model

42. Deploying ebXML Technologies Planning and Implementation Guide

43. Deployment Planning • Incremental adoption of components and operational maturity • Plan 1 year, 2 year and 5 years out. • Issues, implementation criteria, ROI, support, interoperability, XML. • Schema neutral content assembly. • Separation of business semantics from XML mechanics. • Web services and discovery.

44. Implementing ebXML roadmap I N C R E A S I N G M A T U R I T Y

45. Some ebXML selection metrics • B2B or large A2A Environments— extending or integrating enterprise systems, or when loosely coupled messaging is desirable • Need Reliable Messaging— when enterprise services perform updates, insert, or deletes to the underlying data model, reliable messaging becomes critical • Security is a Concern—when different security profiles and requirements exist between trading partners • High scalability requirements—ebXML’s loosely coupled messaging architecture allows for horizontal scalability, queuing, and clustering • Want to Leverage Industry Standards—XML grammars, business process modelling and trading partner agreements

46. Main ebXML concepts • Business Processes – defined as models in UMM, scripted in XML • Business Messages – content agnostic - exchanged using ebMS • Trading Partner Agreement – specifies parameters for businesses to interface with each other – expressed in XML • Messaging Layer – moves the actual XML data between trading partners – ebMS • Core components – library of pre-defined business vocabulary artifacts • Collaboration Registry - Provides a “container” for process models, vocabularies, assembly templates, partner profiles + discovery.

47. Additional Information • OASIS ebXML Registry Technical Committee • http://oasis-open.org/committees/regrep/ • OASIS CAM (assembly) Technical Committee • http://oasis-open.org/committees/cam/ • ebXML.org • http://www.ebxml.org/ • Version 2.0 Implementations • Open Source Implementation • http://sourceforge.net/projects/ebxmlrr • ebxmlsoft Inc. Implementation • http://www.ebxmlsoft.com/ • XMLGlobal Implementation • http://www.xmlglobal.com/

48. Thank you Pioneering XML eBusiness http://www.ebXML.org http://drrw.net