The ebXML Technical Architecture Presented by: Duane Nickull CTO, XML Global Technologies May 2001

1. The ebXML Technical Architecture Presented by: Duane Nickull CTO, XML Global Technologies May 2001

2. Before we begin… • Caveats – • ebXML is a work in progress and the work you see today could be subject to change.

3. Presenter – Duane Nickull • Co-lead/Chief Editor - ebXML Technical Architecture, ebXML Steering Committee • Founder and CTO of XML Global Technologies (www.xmlglobal.com) • Co-engineered / invented • GoXML – First Context based XML Search Engine. • First XML e-Commerce Pro (launched Mar 1999). • Working with OAG, OASIS, UDDI, HRXML, WSDL • Built a reference implementation of ebXML • Technical Editor / Director of XSLT.com duane@xmlglobal.com

4. Initial Thoughts: • Examine some business technical needs • Look at the overall architecture of ebXML. • Show working example of XML Global ebXML marketplace • Discuss implementing ebXML today Followed by: • ebXML Proof of Concept Demonstration

5. Business Technical 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.

6. The need for XML • It is desirable to transport data around networks (including the internet). • Ideally, that data should be self describing. • SGML was too complex, HTML not robust enough.

7. What is Self Describing??? ST*323*712990413 V1*7039610*NEW ZEALAND QUEEN*D*104N*SCAC***L LS*0100 R4*D*D*JAX*JACKSONVILLE FL**** V9*EAD**920819**JACKSONVILLE FL***A26 R4*D*D*ORF*NORFOLK, VA**NORFOLK INTL TERMIN** V9*EAD**920817**NORFOLK, VA***A26 R4*L*K*MEB*MELBOURNE, AUST**** V9*EDD**920712**MELBOURNE, AUST***A40 R4*L*K*SYD*SYDNEY, AUST**** V9*EDD**920715**SYDNEY, AUST***A40 R4*L*K*WLG*WELLINGTON, NEW ZEALAND**** V9*EDD**920721**WELLINGTON, NEW ZEA***A40 LE*0100 SE*25*712990413 This is not self describing data!

8. XML is Self Describing <?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>

9. XML issues… • XML is a markup language • XML, by itself, does not solve interoperability problems yet it is an important tool for doing so. • Using XML alone, does not provide semantics • XML is a not programming language • XML is not a fixed element language • XML is not difficult to understand • XML will not replace HTML • XML does not solve business problems • XML Schemas do not provide semantics or solve business problems. • What we really need is a dynamic cross-walk mechanism for XML based vocabularies.

10. ¢ ¢ ¢ ¢ ¢ ¢ ¢ ¢ 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.

11. The ebXML Technical Architecture

12. Business Operational View Comply with Business aspects of business transactions BOV related standards* Covered by Viewed as Functional Service View Information technology aspects of business transactions Comply with FSV related standards Covered by Ebxml Architecture design B U S I N E S S T R A N S A C T I O N S * UML Models

13. Business Operational View

14. Business Operational View (BOV) The BOV addresses the semantics of: 1) The semantics of business data in transactions and associated data interchanges 2) The architecture for business transactions, including: i) operational conventions; ii) agreements; iii) mutual obligations and requirements. These specifically apply to the business needs of ebXML Trading Partners.

15. FSV Architecture CPA Interface Interface

16. Functional Service View (FSV) The FSV addresses the supporting services meeting the mechanistic needs of ebXML. It focuses on the Information Technology aspects of: i) functional capabilities; ii) service interfaces; iii) protocols.

17. TA Philosophy Architect ebXML in Layers Start with the high level use cases 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!!!! Write test code (informally) to test concepts!!!

18. ebXML High Level use case

19. 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 (BPSS) 2. A mechanism for registering and storing a business process and information model so that it can be shared/reused (Registry) 3. Discovery of information (from the CPP) 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

20. Concepts (continued) 4. A mechanism for registering the aforementioned information so that it may be discovered and retrieved (Registry Client or Interface) 5. A mechanism for describing a Trading Partner Agreement (CPA) which can be derived from the information about each participant from their CPP. 6. A standardized messaging service which enables interoperable, secure and reliable exchange of messages between two parties (ebXML TRP) 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 CPA.

21. ebXML Architecture At the heart of ebXML is a powerful system of Registries and Distributed Repositories. The Registry is really the interface to the documents. Registries contain pointers and meta information about many different items - Core Components, DTD, Trading Partner Profiles and Business Process documents. It is important that we can reference items (CC) from Business Process Layer down to the most atomic Element Level. Repository Synchronization Registry I / O API

22. Repository Item Examples • Registry systems can give you information about many types of ebXML documents - CPP and CPA templates - Business Process Documents - Core Components and CC Aggregates - DTD’s and Schemas (Assembly documents)

23. Registry Item Examples • XML elements in business messages can reference items callable from a Registry. • Examples: • <nameofperson> • <nomdelapersonne> • <name> • <TheThingICallYou> All are the same item!!!

24. Registry Item Examples • XML elements in business messages can reference items in a registry. • Examples: • <nameofperson UUID=“myrep:1236”> • <nomdelapersonne UUID=“myrep:1236”> • <name UUID=“myrep:1236”> • <TheThingICallYou UUID=“myrep:1236”> All are the same item!!!

25. XML Elements in document instances contain pointers to RI’s Registry Items are metadata – not instances of data <?xml version=“1.0”> <GUID>12345</GUID> <Element>name</Element> <EQ org=“yourOrg”> PersonName </EQ> Repository Item <?xml version=“1.0”> <name GUID=“FooRep:12345”> Duane </name> Document Instance Registry API API Managed object Managed object Managed object

26. Registries – deployment • Both centralized and decentralized RegRep models shall be acceptable within the ebXML infrastructure. The ebXML registry architecture supports distribution. • No single point of failure

27. User User User User User User Registry (API) Repository Centralized System

28. Decentralized Repository / Distributed Registry Repository Items Registry (subscribes to decentralized Repository Items Repository Items User sync User Repository Items Registry (API) Repository Items User Searching and indexing only User Repository Items User Repository Items User

29. ebXML – CPP and CPA • Tells you who, interfaces, tModels etc. • Provide a list of interfaces expressed as Business Processes (and binding’s) • Each Process has a Globally Unique Identifier (called UUID in UDDI, GUID in ebXML) • Similar efforts – IBM TPAML, UDDI, eCo. CPP Preview

30. 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 BPM Preview

31. 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. CC Preview

32. 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.buyerParty(name)

33. ebXML Phases Phases of implementing and running ebXML..

34. RequestSpecification() ReceiveSpecification() RequestLexicon() ReceiveLexicon() RequestBusinessObjectLibrary() ReceiveBusinessObjectLibrary() RequestSomeOnesBusinessProcessInformationModel() ReceiveBusinessSomeOnesBusinessProcessInformationModel() SendOwnBusinessProcessInformationModel() ReceiveAcknowledgementForOwnBusinessProcessInformationModelAcceptance() SendOwnTradingPartnerProfile () ReceiveAcknowledgementForOwnTradingPartnerProfile () Implementation Phase ebXML Specification ebXML Registry Business Process and Information Models Request / Send Lexicon (Core Component) Content Receive ebXML Business Service Interface (application) Business Object Library

35. Some examples of possible access service methods RequestSomeOnesTradingPartnerProfile() ReceiveSomeOnesTradingPartnerProfile () RequestSomeOnesNew/UpdatedBusinessProcessInformationModel() ReceiveBusinessSomeOnesNew/UpdatedBusinessProcessInformationModel() SendTradingPartnerAgreement() ReceiveAcknowledgementForTradingPartnerAgreement() RequestLexiconUpdate() ReceiveLexiconUpdate() RequestBusinessObjectLibraryUpdate() ReceiveBusinessObjectLibraryUpdate() Discovery Phase Business Process and Information Models ebXML Registry Lexicon (Core Component) Content Business Object Library Request Receive Update ebXML Business Service Interface (application) TPP Registry List of Scenarios Query Retrieve (abstract) Messaging Constraints Send ebXML Service Interface (application) Security Constraints

36. ebXML Run Time Phase ebXML Business Service Interface (application) ebXML Business Service Interface (application) Send Retrieve SendBusinessMessage() ReceiveBusinessMessageAcknowledgement() ReceiveBusinessMessage() SendBusinessMessageAcknowledgement() GenerateErrorMessage() ReceiveErrorMessage() Some examples of possible transport methods

37. Business Profile Document (XML) Indexes XML instances based on rules and meta data in index.xml Business Process Document (XML) DTD’s / Schemas GUI Reg Business Profile Registry Trading Partner “A” Big Co. Business Process Registry Trading Partner “B” Big Co. DTD / Schema Registry Registry Abstract Layers. Core Component Library Registry Core Component Library

38. 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. • DEMO – ALPHA (online)

39. 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. Trading Partner (ebXML Compliant) GUI Tool Trading Partner Profile Repository system API Human Interface SECURITY LAYER Registry

40. Collaboration Protocol Profile (CPP) Supported Business Process 1.. <<References>> 1.. <<Constructed From>> DTD’s Schemas? DTD’s Schemas? DTD’s Schemas? <<Constructed From>> Common Business Objects <<Constructed From>> Core Comp. Core Comp. Core Comp. Core Comp. Core Comp. Core Comp. Core Comp 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.

41. Business Message References Examples: eCo.xml UDDI Partner Discovery Layer Examples: ebXML BP Syntax Business Process Layer Business Messages Business Info Layer Contain Examples: xCBL, cXML Visa Inv. References to: Human Search Interface Registry Repository Items Business Application Interface API Human Actors

42. Building an ebXML Marketplace • Caveat – do not claim you have an ebXML compliant marketplace until the spec is done and conformancy tests are available. • Start with slow transition. • Adopting ebXML is not really complex but needs to be well though out. • Some specific tools are needed.

43. ebXML Marketplace Architecture • Registry/Repository is used as a central mechanism for Registration and subsequent discovery of XML meta data. • XML Global uses XML Search Engine tightly coupled with Native XML Database. • Facilitates ebXML TRP as messaging.

44. ebXML Marketplace Architecture • Tools on front end allow companies to Register their CPP’s. Register CPP

45. Building an ebXML Markeplace • Once a Skeleton CPP is built, the user may add one or more Business Processes

46. CPP Registry XML Global ebXML Marketplace • Users’ CPP is now complete with BP’s and other participants can query the Registry using published API. ebXML Users

47. Registry XML Global ebXML Marketplace • Another User can now retrieve and examine the CPP if they are wanting to do business with the first user. CPP

48. Building an ebXML Marketplace • As long as they know some basic information, they can compose a CPA and propose it to the first organization. Self(CPP) other(CPP) CPA Propose() TRP_Packaging Verify()

49. Building an ebXML Marketplace • The recipient can then examine the CPA and check it. If it is acceptable, they may wish to sign it. A business Agreement is now in place. ReceiveProposedCPA() Validate() Recognize BP() Accept() | Reject() | CounterPropose()

50. Proprietary Data Format ebXML Marketplace • Once a CPA and BP have been recognized (by GUID or by query), business information can be transformed using a declarative transformation tool. Data Exchange ebXML Compliant XML Syntax Backend System