1. 1 SBDH 3.0 Project Session SBDH 3.0 Project leader Shingo Sakaguchi Oslo, Norway 21-24 June 2010

2. 2 SBDH Agenda Completion of Requirement list Milestone Chart for path forward

3. 3 Requirements - from project proposal - Brief requirement lists –Extension from the current SBDH Requirement from new technologies such as cloud computing –Idea from Open Service Repository Task Force - Service Integration Requirements –Need to be conformant with: UN/CEFACT SBDH Specification V 1.0 UN/CEFACT Core Components Technical Specification V3.0 UN/CEFACT Unified Context Methodology latest draft UN/CEFACT XML NDR V3.0 UN/CEFACT Core Data Type Catalogue V 3.0 UN/CEFACT Business Message Template Presented at 14 th CEFACT Forum in Sapporo

4. 4 Discussion of an additional Requirement A collaboration framework of SBDH working with a registry or data center in a cloud computing.

5. 5 Characteristics of SBDH Architecture Bi-lateral & Multi-lateral Bi-lateral –All information which is predictable between business partners such as processing and routing parameters are contained in SBDH. Multi-lateral –Some static information which is unpredictable between partner retrieve from registry in cloud. Business Document SBD (UN/CEFACT,CCL) SBDH 3.0 An registry in Cloud (static Information ) It has pointers to talk with registry Get static information SBDH, as a business document header, needs to support enormous and various types of standard business documents, it’s difficult to cover all information as in header information.

6. 6 Standardization of Business transaction Bi-lateral & Multi-lateral Standard Format Standard Format Non-Standard Format Multi - Lateral Bi - Lateral Our Approach Service Standard Format EDIFACT BASE EDI MESSAGES (a domain standard) Order document A major comp. EDI Message Delivery plan confirmation Document Automobile Major company XML BASE EDI MESSAGES (a domain standard) Order document Delivery plan confirmation Document A contactor of electric industry domain Service Classical Style –Establish business agreement between business partners. –Define an EDI choreography. –Develop the EDI systems on each partner side. –Start Business. Classical Approach Cloud computing –Establish business agreement between business partners. –Find out an appropriate service from cloud. –Subscribe the service. –Start Business.

7. 7 SBDH Projects Task List ODP Step 2 –Finish to create requirement list ODP Step 3 –Control Project Create project member lists Define WBS Create issues list –Progress Project To have Conference calls –Two times in July and one time in August (Before coming 16 th CEFACT forum) »propose day and time. –Communication tool and screen share tool. –Rule for notification for Conference call –Open currently working artifacts Managing rule (who will put them on the server.)

8. 8 Appendix Data Model of SBDH 1.3

9. 9 Appendix Illustrative process for SBDH 1.3 - not normative -

10. 10 Appendix September, 2009 in Sapporo Service in SBDH 1.3Extended Service in could computing entity ・ Service Name and Action name in the Service information class. ・ entities in Service Transactional information. Name and Identifier in composition Service, Software application, and interface (or Action) class. Entity preservation place c.f. values in the BPSS instance. a service registry in the cloud Add on Current SBDH (partial view) 1st discussion point

11. 11 Appendix September, 2009 in Sapporo 2nd discussion point “A BIE will be part of a package within a library The package represents a set of BIEs being used in a specific context and tailored to meet the unique requirements for the package. BIEs are semantically unique within a package, but may be semantically similar in name and definition to, albeit with a different content model than, BIEs in other package” (CCTS 3.0 sec7.1) Core Component Business Information Entity With Package ContextNeutralSpecific- Semantically uniqueness -weakstrong Usage RealityAbstract (conceptual) Current SBDH (partial view) For to know what BSD looks like Context expression / value Impact by new concept on CCTS 3.0 “package” YES

12. 12 Appendix September, 2009 in Sapporo Developing a message with CSP Message Standard Header Body processingrouting Auth. (SSO) Profile of Message Body Organization Collaboration SBD (Business Payloads) Connection Error SBDH Etc. Message Layer Transport Layer Message Standard HTTP Binding FTP Binding SMTP Binding Etc. Binding ・・・ Physical Message IPAddress encryption Dialect in Specific Protocol such as HTTP Document Layer Business Document SBD (UN/CEFACT,CCL) SBDH CSP (static Information ) ebMS 3.0 & WSDL 2.0

13. 13 Appendix January, 2010 in Vienna EDIFACT BASE EDI MESSAGES (a domain standard) Order document A major comp. EDI Message Delivery plan confirmation Document Automobile Major company XML BASE EDI MESSAGES (a domain standard) Order document Delivery plan confirmation Document A contactor of electric industry domain Document Layer Message Layer Transport Layer Target Normalization layers / de- Normalization layer Information stack of physical message Normalized form normalizeDe-normalize normalize Information from BOV ↓ UN/CEFACT Information from SFV ↓ TBR National Update flow of EDI Service - a case of Ordering

14. 14 Appendix Use Cases for CSP Use case –A subscriber looks into the CSP to find out an appropriate service. –A service provider registers service catalogue into the CSP. –A platform / infrastructure provider registers those catalogue into the CSP. –Service, such as SaaS, retrieve information to achieve runtime condition from the CSP.

15. 15 Appendix CSP data model (tentative) 項目を追 加したも のを英語 化する 会議まで に