SBDH 3.0 Project Session

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

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

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 14th CEFACT Forum in Sapporo

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

5. 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. Characteristics of SBDH Architecture Bi-lateral & Multi-lateral 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. An registry in Cloud (static Information ) Business Document SBDH 3.0 SBD (UN/CEFACT,CCL) It has pointers to talk with registry Get static information

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

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 16th 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. Appendix Data Model of SBDH 1.3

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

10. Appendix September, 2009 in Sapporo 1st discussion point Add on Current SBDH (partial view)

11. “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) Appendix September, 2009 in Sapporo 2nd discussion point Abstract (conceptual) Reality Impact by new concept on CCTS 3.0 “package” YES Context expression / value For to know what BSD looks like Current SBDH (partial view)

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

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

14. AppendixUse 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. Appendix CSP data model (tentative) 項目を追加したものを英語化する 会議までに