WIXLIB

ebXML Technical Architecture TeamFebruary ) When UML and Object Constrained Language (OCL) are used to specify ebXMLartifacts Capitalization naming SHALL follow the following 22632642652662672682692702712722732745 ebXML System Overview Class, Interface, Association, Package, State, Use Case, Actor names SHALL useUCC convention (examples: ClassificationNode, Versionable, Active,InsertOrder, Buyer).Attribute, Operation, Role, Stereotype, Instance, Event, Action names SHALLuse LCC convention (examples: name, notifySender, resident, orderArrived).3) General rules for all names are: Acronyms SHOULD be avoided, but in cases where they are used, thecapitalization SHALL remain (example: XMLSignature). Underscore ( ), periods ( . ) and dashes ( - ) MUST NOT be used (don't use:header.manifest, stock quote 5, commercial-transaction, use HeaderManifest,stockQuote5, CommercialTransaction instead).Figure 1 below shows a high- level use case scenario for two Trading Partners, firstconfiguring and then engaging in a simple business transaction and interchange. Thismodel is provided as an example of the process and steps that may be required toconfigure and deploy ebXML Applications and related architecture components. Thesecomponents can be implemented in an incremental manner. The ebXML specificationsare not limited to this simple model, provided here as quick introduction to the concepts.Specific ebXML implementation examples are described in Appendix A.The conceptual overview described below introduces the following concepts andunderlying architecture:1. A standard mechanism for describing a Business Process and its associatedinformation model.2. A mechanism for registering and storing Business Process and Information MetaModels so they can be shared and reused.3. Discovery of information about each participant including: The Business Processes they support. The Business Service Interfaces they offer in support of the BusinessProcess. The Business Messages that are exchanged between their respectiveBusiness Service Interfaces. The technical configuration of the supported transport, security andencoding protocols.4. A mechanism for registering the aforementioned information so that it may bediscovered and retrieved.Technical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 7 of 39

ebXML Technical Architecture Team275276277278279280281282February 20015. A mechanism for describing the execution of a mutua lly agreed upon businessarrangement which can be derived from information provided by each participantfrom item 3 above. (Collaboration Protocol Agreement – CPA)6. A standardized business Messaging Service framework that enables interoperable,secure and reliable exchange of Messages between Trading Partners.7. A mechanism for configuration of the respective Messaging Services to engage inthe agreed upon Business Process in accordance with the constraints defined inthe business arrangement.XMLBusiness ScenariosBusiness Profiles1COMPANY ARequest Business Details2ebXMLRegistry3Register Implementation DetailsRegister COMPANY A ScdloawnDo4COMPANY d Local SystemImplementationebXML compliantsystem5entemgnrrass AeniusnBoeeAgrDOSESINSBUNSIOTACNS6ATRFigure 1 - a high level overview of the interaction of two companies conducting eBusiness using ebXML.In Figure 1, Company A has become aware of an ebXML Registry that is accessible onthe Internet (Figure 1, step 1). Company A, after reviewing the contents of the ebXMLRegistry, decides to build and deploy its own ebXML compliant application (Figure 1,step 2). Custom software development is not a necessary prerequisite for ebXMLparticipation. ebXML compliant applications and components may also be commerciallyavailable as shrink-wrapped solutions.Company A then submits its own Business Profile information (including implementationdetails and reference links) to the ebXML Registry (Figure 1, step 3). The businessprofile submitted to the ebXML Registry describes the company’s ebXML capabilitiesand constraints, as well as its supported business scenarios. These business scenarios areTechnical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 8 of 39

ebXML Technical Architecture TeamFebruary 13314XML versions of the Business Processes and associated information bundles (e.g. a salestax calculation) in which the company is able to engage. After receiving verification thatthe format and usage of a business scenario is correct, an acknowledgment is sent toCompany A (Figure 1, step 03313323333343356 ebXML Recommended Modeling MethodologyCompany B discovers the business scenarios supported by Company A in the ebXMLRegistry (Figure 1, step 4). Company B sends a request to Company A stating that theywould like to engage in a business scenario using ebXML (Figure 1, step 5). Company Bacquires an ebXML compliant shrink-wrapped application.Before enga ging in the scenario Company B submits a proposed business arrangementdirectly to Company A’s ebXML compliant software Interface. The proposed businessarrangement outlines the mutually agreed upon business scenarios and specificagreements. The business arrangement also contains information pertaining to themessaging requirements for transactions to take place, contingency plans, and securityrelated requirements (Figure 1, step 5). Company A then accepts the business agreement.Company A and B are now ready to engage in eBusiness using ebXML (Figure 1, step 6).Business Process and Information Modeling is not mandatory. However, if implementersand users select to model Business Processes and Information, then they SHALL use theUN/CEFACT Modeling Methodology (UMM) that utilizes UML.6.1 OverviewWhile business practices from one organization to another are highly variable, mostactivities can be decomposed into Business Processes which are more generic to aspecific type of business. This analysis through the modeling process will identifyBusiness Process and Information Meta Models that are likely candidates forstandardization. The ebXML approach looks for standard reusable components fromwhich to construct interoperable and components.The UN/CEFACT Modeling Methodology (UMM) uses the following two views todescribe the relevant aspects of eBusiness transactions. This model is based upon theOpen-edi Reference Model, ISO/IEC 14662.Technical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 9 of 39

ebXML Technical Architecture TeamBUSINESSTRAN ruary 2001Business Operational ViewComply withBusiness aspectsofbusiness transactionsBOV RELATEDSTANDARDSCovered byInterrelatedFunctional Service ViewInformation technologyaspects ofbusiness transactionsComply withFSV RELATEDSTANDARDSCovered byFigure 2 - ebXML Recommended Modeling MethodologyThe UN/CEFACT Modeling Methodology (UMM) is broken down into the BusinessOperational View (BOV) and the supporting Functional Service View (FSV) describedabove. The assumption for ebXML is that the FSV serves as a reference model that MAYbe used by commercial software vendors to help guide them during the developmentprocess. The underlying goal of the UN/CEFACT Modeling Methodology (UMM) is toprovide a clear distinction between the operational and functional views, so as to ensurethe maximum level of system interoperability and backwards compatibility with legacysystems (when applicable). As such, the resultant BOV-related standards provide theUN/CEFACT Modeling Methodology (UMM) for constructing Business Process andInformation Meta Models for ebXML compliant applications and components.The BOV addresses:a) The semantics of business data in transactions and associated data interchangesb) The architecture for business transactions, including: operational conventions; agreements and arrangements; mutual obligations and requirements.These specifically apply to the business needs of ebXML Trading Partners.The FSV addresses the supporting services meeting the mechanistic needs of ebXML. Itfocuses on the information technology aspects of: Functional capabilities; Business Service Interfaces;Technical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 10 of 39

ebXML Technical Architecture Team363364365366367368369370371372373374375376 February 2001Protocols and Messaging Services.This includes, but is not limited to: Capabilities for implementation, discovery, deployment and run time scenarios; User Interfaces; Data transfer infrastructure Interfaces; Protocols for enabling interoperability of XML vocabulary deployments fromdifferent organizations.6.2 ebXML Business Operational ViewThe modeling techniques described in this section are not mandatory requirements forparticipation in ebXML compliant business transactions.Based on ebXML Meta ModelBusiness ContextCore LibraryBusiness LibraryCore & AggregateComponentsBusiness Processes& BusinessInformationAnalysis ArtifactsDesign ArtifactsActivity DiagramsCollaboration DiagramsSequence DiagramsState DiagramsConceptual DiagramsFinal Class DiagramsBusiness CollaborationKnowledgeRequirements ArtifactsUse Case DiagramsUse Case DescriptionsBusiness Process and Information Models(Compliant to the ebXML Meta Model)377378379Figure 3 – detailed representation of the Business Operational ViewTechnical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 11 of 39

ebXML Technical Architecture February 2001In Figure 3 above, Business Collaboration Knowledge is captured in a Core Library. TheCore Library contains data and process definitions, including relationships and crossreferences, as expressed in business terminology that MAY be tied to an acceptedindustry classification scheme or taxonomy. The Core Library is the bridge between thespecific business or industry language and the knowledge expressed by the models in amore generalized context neutral language.The first phase defines the requirements artifacts that describe the problem using UseCase Diagrams and Descriptions. If Core Library entries are available from an ebXMLcompliant Registry they will be utilized, otherwise new Core Library entries will becreated and registered in an ebXML compliant Registry.The second phase (analysis) will create activity and sequence diagrams (as defined in theUN/CEFACT Modeling Methodology specification) describing the Business Processes.Class Diagrams will capture the associated information parcels (business documents).The analysis phase reflects the business knowledge contained in the Core Library. Noeffort is made to force the application of object-oriented principles. The class diagram isa free structured data diagram. Common Business Processes in the Business LibraryMAY be referenced during the process of creating analysis and design artifacts.The design phase is the last step of standardization, which MAY be accomplished byapplying object-oriented principles based on the UN/CEFACT Modeling Methodology. Inaddition to generating collaboration diagrams, a state diagram MAY also be created. Theclass view diagram from the analysis phase will undergo harmonization to align it withother models in the same industry and across others.In ebXML, interoperability is achieved by applying Business Information Objects acrossall class models. Business Processes are created by applying the UN/CEFACT ModelingMetholodogy (UMM) which utilizes a common set of Business Information Objects andCore Components.Technical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 12 of 39

ebXML Technical Architecture Team412413February 20016.3 ebXML Functional Service ViewBusiness Process and Information Models(Compliant to the ebXML Meta Model)Model to XML ConversionRegistriesRegistrationRetrieval of Profiles &new/updated ebXML ModelsRetrieval of Profiles &new/updated ebXML ModelsRegistry ServiceInterfaceRegisterCollaborationProtocol Profile(CPP)RegisterCollaborationProtocol Profile(CPP)Retrieval of ebXMLModels and ProfilesBusiness rationProtocolAgreement (CPA)Business 6417418419420421422423424425Figure 4 - ebXML Functional Service ViewAs illustrated in Figure 4 above, the ebXML Registry Service serves as the storagefacility for the Business Process and Information Models, the XML-based representationsof those models, Core Components, and Collaboration Protocol Profiles. The BusinessProcess and Information Meta Models MAY be stored in modeling syntax, however theyMAY be also stored as XML syntax in the Registry. This XML-based businessinformation SHALL be expressed in a manner that allows discovery down to the atomicdata level via a consistent methodology.Technical Architecture SpecificationCopyright ebXML 2001. All Rights Reserved.Page 13 of 39

ebXML Technical Architecture TeamFebruary 2001426427428429The underlying ebXML Architecture is distributed in such a manner to minimize thepotential for a single point of failure within the ebXML infrastructure. This specificallyrefers to Registry Services (see Registry Functionality, Section 8.4 for details of 04414424434444457 ebXML Functional Phases7.1 Implementation PhaseThe implementation phase deals specifically with the procedures for creating anapplication of the ebXML infrastructure. A Trading Partner wishing to engage in anebXML compliant transaction SHOULD first acquire copies of the ebXMLSpecifications. The Trading Partner studies these specifications and subsequentlydownloads the Core Library and the Business Library. The Trading Partner MAY alsorequest other Trading Partners’ Business Process information (stored in their businessprofile) for analysis and review. Alternatively, the Trading Partner MAY implementebXML by utilizing 3rd party applications. The Trading Partner can also submit its ownBusiness Process information to an ebXML compliant Registry Service.Figure 5 below, illustrates a basic interaction between an ebXML Registry Service and aTrading Partner.ebXMLRegistryBusinessProcess &InformationMeta brary

213 This specification is designed to provide a high level overview of ebXML, and as such, 214 does not provide the level of detail required to build ebXML Applications, components, 215 and related services. Please refer to each of the respective ebXML specifications to get 216 the level of detail. 217