UN/CEFACT‘s Modeling Methodology (UMM 1.0) towards UMM 2.0

1. UN/CEFACT‘s Modeling Methodology (UMM 1.0)towards UMM 2.0 DissertantInnen Seminar – Mo, 21.05.2007 Christian Huemer Marco Zapletal Philipp Liegl Rainer Schuster

2. Outline • Introduction to UMM • UMM 1.0 by Example • A Business Service Interface for Business Transactions • Limitations of UMM 1.0 • Modeling Business Documents • Call Behavior and Alternative Responses • UMM Choreographies and Business Entity States • Re-packaging the UMM • Multiparty Collaborations and Local Choreographies • Summary

3. We are going to talk about … UN/CEFACT‘s Modeling Methodology (UMM)

4. UN and e-Business? • To maintain international peace and security • To develop friendly relations among nations • To achieve international co-operation;

5. UN Layout Key

6. Electronic Data Interchange (EDI) Goal: Exchange of business related data, independent of Software, Hardware and Communication Protocols Application Application EDI EDI

7. UN Layout Key UN/EDIFACT ebXML UMM & CC United Nations Centre for Trade Facilitationand e-Business (UN/CEFACT]

8. UN/CEFACT`s Modeling Methodology (UMM) UN/EDIFACT Web Services ebXML Open-edi Reference Model – ISO 14662 Business Operational View Business Operational View BOV Related Standards Comply with Business aspects Business aspects of of business transactions business transactions Covered by BUSINESSTRANSACTIONS Transformed To Viewed as as Functional Service View Functional Service View Comply with Information technology Information technology FSV Related Standards aspects of aspects of Covered by Covered by business transactions business transactions

9. UMM BDV BRV BTV BSV Business Business Business Business Domain Requirement Transaction Service View View View View UN/CEFACT´s Modeling Methodology • Customizing UML for modeling inter-organizational processes • Concentrates on business semantics • Independent of the IT platform • Describes a choreography from a global perspective • UML Profile: Stereotypes, Tagged Values, Constraints on top of the UML Meta Model

10. Outline • Introduction to UMM • UMM 1.0 by Example • A Business Service Interface for Business Transactions • Limitations of UMM 1.0 • Modeling Business Documents • Call Behavior and Alternative Responses • UMM Choreographies and Business Entity States • Re-packaging the UMM • Multiparty Collaborations and Local Choreographies • Summary

11. UN/CEFACT‘s Modeling Methodology (UMM) • Customizing UML for modeling B2B • Concentrates on business semantics • Independent of the IT platform • Describes a choreography from a global perspective • UML Profile: Stereotypes, Tagged Values, Constraints on top of the UML Meta Model • ~ 40 stereotypes defined in the meta model UMM BDVBusiness Domain View BRVBusiness Requirements View BTVBusiness Transaction View

12. UMM by example • European crossborder waste management Import Authority Export Authority Notifier Notifiee Announce Transport Arrival Announce Waste Transport

13. Top-level UMM Packages <<BusinessDomainView>> <<BusinessArea>> <<BusinessRequirementsView>> <<BusinessProcessView>> <<BusinessEntityView>> <<TransactionRequirementsView>> <<CollaborationRequirementsView>> <<CollaborationRealizationView>> <<BusinessTransactionView>> <<BusinessInteractionView>> <<BusinessChoreographyView>> <<BusinessInformationView>>

14. UMM by example - BRV <<mapsTo>> <<mapsTo>> <<mapsTo>> <<mapsTo>>

15. <<BusinessPartner>> <<BusinessPartner>> <<BusinessPartner>> <<BusinessPartner>> UMM by example – Business Partner Import Authority Export Authority Importer Exporter

16. UMM by example - BRVSubview: CollaborationRealizationView

17. Top-level UMM Packages <<BusinessDomainView>> <<BusinessArea>> <<BusinessRequirementsView>> <<BusinessProcessView>> <<BusinessEntityView>> <<TransactionRequirementsView>> <<CollaborationRequirementsView>> <<CollaborationRealizationView>> <<BusinessTransactionView>> <<BusinessInteractionView>> <<BusinessChoreographyView>> <<BusinessInformationView>>

18. UMM by example - BTV <<mapsTo>> <<mapsTo>> BTUC BTUC <<mapsTo>> BCUC

19. The UMM Add-In • First prototypical implementation which supports the UMM approach • Developed by the University of Vienna in cooperation with the Research Studios Austria • Available for free from the project’s website • http://ummaddin.researchstudio.at • Extension of the Enterprise Architect • Developed in C# • Current version: 0.8.2

20. UMM Add-In Overview

21. Requirements Engineering – UMM Worksheets <<BusinessPartner>> <XML> UMM-specific toolbar

22. Semi-automatic generation of UMM artifacts <BPEL> <BPSS> [yes] [no] Valid? Transformation into Choreography Languages UMM Add-In – BPEL/BPSS Generator Validating UMM Model UMM Validation

23. Outline • Introduction to UMM • UMM 1.0 by Example • A Business Service Interface for Business Transactions • Limitations of UMM 1.0 • Modeling Business Documents • Call Behavior and Alternative Responses • UMM Choreographies and Business Entity States • Re-packaging the UMM • Multiparty Collaborations and Local Choreographies • Summary

24. timeToRespond: 24 hrs timeToAcknowledgeReceipt: 1 hrs timeToAcknowledgeProcessing: 4 hrs isAuthoriztionRequired: yes isNonRepudiationRequired: yes isNonRepudiationOfReceiptRequired: yes isIntelligibleCheckRequired: yes retryCount: 3 : Buyer : Seller isConfidential: no isTamperProof: yes isAuthenticated: yes :OrderResponseEnvelope place order [Control Fail] [Success] :PurchaseOrderEnvelope <<RespondingBusinessActivity>> process order timeToAcknowledgeReceipt: 2 hrs timeToAcknowledgeProcessing: 8 hrs isAuthoriztionRequired: yes isNonRepudiationRequired: yes isNonRepudiationOfReceiptRequired: yes isIntelligibleCheckRequired: yes isConfidential: no isTamperProof: yes isAuthenticated: yes Business Transaction <<RequestingBusinessActivity>>

25. :SellerService :BuyerService PurchaseOrderEnvelope AcknowledgmentOfReceipt AcknowledgmentOfProcessing OrderResponseEnvelope AcknowledgmentOfReceipt AcknowledgmentOfProcessing Old Business Service View

27. State Machines • Describes the Business Service Interface of a participating partner • Unambiguous definition on how to react on • Incoming messages • Messeages expected, but not received • Resulting State Machines: • The state machine of the initiator • The state machine of the responder

28. Outline • Introduction to UMM • UMM 1.0 by Example • A Business Service Interface for Business Transactions • Limitations of UMM 1.0 • Modeling Business Documents • Call Behavior and Alternative Responses • UMM Choreographies and Business Entity States • Re-packaging the UMM • Multiparty Collaborations and Local Choreographies • Summary

29. Limitation 1 • Vague guidelines on modeling business documents

30. | Limitation 2 • Work-around to support call behavior in UML 1.4 <<mapsTo>> <<mapsTo>>

31. Limitation 3 • Inability to model alternative responses

32. Limitation 4 • Flow may be well interpreted by humans • Fails to give an unambiguous machine-processable definition

33. Limitation 5 • Split of strongly related artifacts into different packages

34. Limitation 6 • No multi-party choreographies • No nested business transactions

35. Outline • Introduction to UMM • UMM 1.0 by Example • A Business Service Interface for Business Transactions • Limitations of UMM 1.0 • Modeling Business Documents • Call Behavior and Alternative Responses • UMM Choreographies and Business Entity States • Re-packaging the UMM • Multiparty Collaborations and Local Choreographies • Summary

36. Enterprise Application Enterprise Application EnterpriseApplication Enterprise Application Motivation for standardizing the exchanged data Customer Y Order processing of enterprise X request for quote WSDL WSDL SOAP message place order WSDL SOAP message check order status WSDL WSDL SOAP message UDDI registry

37. Enterprise Application Enterprise Application Enterprise Application EnterpriseApplication Enterprise Application Motivation for standardizing the exchanged data Customer Y Order processing of enterprise X request for quote WSDL WSDL SOAP message SOAP Message place order WSDL SOAP Header WSDL SOAP message SOAP Body check order status Message Body WSDL WSDL WSDL SOAP message UDDI registry

38. Motivation • Problem domain • Business documents exchanged in a business process in a service oriented context • UN/CEFACT provides a generic solution • Core Components Technical Specification (CCTS) • Almost no tool support possible – CCTS are standardizes as spread sheets • UML Profile for Core Components • Seamless integration into UML modeling tools possible • Seamless integration into e.g. process modeling specific models possible

39. Harmonizing the exchanged data • Known standardization efforts • UN/EDIFACT • XML based solutions (RosettaNet) • Known issues of these efforts • Multitude of different and competing standards • Inclusion of every possible element that may be required – strong overhead • Changes in the transfer syntax would require a complete reegineering • Solution • Platform independent resuable building blocks for creating shared libraries of business documents developed by UN/CEFACT

40. Core Components • Are the central building blocks of the Core Component Technical Specification • Platform independent • Used to create shared libraries of interoperable business documents • The ontological base of the CCTS is the United Nations Trade Data Element Dictionary (UN/TDED) • Initially started as part of ebXML standards suite • Now a dedicated project independent of ebXML

41. Core Component (CC) example • No business context • Independent of industry or domain ACC Aggregate Core Component BCC Basic Core Component ASCC Association Core Component

42. Business Information Entity (BIE) example • Core Components in a specific business context (e.g. travel industry) • BIEs have a specific business semantic • Qualifiers (US_) help to define and differentiate a BIE from ist associated CC and other BIEs ABIE Aggregate Busines Information Entity BBIE Basic Business Information Entity ASBIE Association Business Information Entity

43. By introducing the business context core components become business information entities Core Components (CC) Business Information Entities (BIE) BIEs are derived from CCs by restriction

44. Dependency between Core Components and Business Information Entites

45. Data Types • Qualified Data Types (QDT) are derived from Core Data Types (CDT) by restriction • Business Information Entities use QDT and CDT • Core Components use only CDT

46. The core component meta model

47. A UML Profile for Core Components • Flaws of the Core Components Technical Specification • Standardization process of Core Components is based on spread sheets • No direct integration into modeling tools possible • UML Profile for Core Components • Independent project based on the CCTS • Set of stereotypes, tagged values and OCL constraints • Can be integrated into a modeling tool of choice • Proof of concept based on UML modeling tool Enterprise Architect • UML class diagrams are used for the modeling of Core Components

48. UML profile for Core Components - Stereotypes

49. Assembling a business document using the different libraries of the UML profile for Core Components Business Library Business document DOCLibrary BIELibrary QDTLibrary ENUMLibrary CCLibrary CDTLibrary PRIMLibrary

50. Derivation of XSD artifacts Naming and Design Rules XSD Schema generator Core Component Model <xsd:complexType name="US_PersonType"> <xsd:sequence> <xsd:element name= "DateofBirth" type="udt1:DateType"> <xsd:element name="FirstName" type="udt1:TextType"/> <xsd:element name="US_Work" type="bie1:US_AddressType"/> <xsd:element name="US_Private" type="bie1:US_AddressType"/> <xsd:sequence> </xsd:complexType> <xsd:complexType name="US_AddressType"> […] </xsd:complexType>