1

SBDH 3.0 Project Session

SBDH 3.0 Project leaderShingo 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

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 DocumentSBD (UN/CEFACT,CCL)SBDH 3.0

An reg

istry in Clou

d (static Inform

atio

n )

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

Standardization of Business transaction Bi-lateral & Multi-lateral

StandardFormat

Standard FormatNon-Standard Format

Multi - Lateral

Bi - Lateral

OurApproach

Service

StandardFormat

EDIFACT BASE EDI MESSAGES

(a domain standard)

Order documentA 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

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

Service in SBDH 1.3 Extended 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

㩷

cd CSPSub

SBDH

<<abstract>>Business Scope

+ Identifier: String+ InstanceIdentifier: String+ Type: String

<<abstract>>Correlation Information

+ Expected Response Date and Time: Identifier [0..1]+ Requesting Document Creation Date and Time: Identifier [0..1]+ Requesting Document Creation Instance: Identifier [0..1]

<<abstract>>Service Information

+ Business Process Identifer: String+ Business Process Reference: String+ Business Process State: String+ Business Service Action: String [0..1]+ Business Service Name: String [0..1]

Service Transaction

- IsNonRepudiationRequest: String [0..1]- TypeOfServiceTransaction: boolean [0..1]

0..*

Scope

㩷

cd CSPSub

Composite Service

+ Identification: Identifier+ Name: Text

Software Service

+ Identification: Identifier+ Name: Text

Interface

+ Identification: Identifier+ Name: Text

+Connecting

0..*

+Consiting

1..*

+Application 0..*

Add onCurrent SBDH (partial view)

1st discussion point

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 us

ed 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

Context Neutral Specific -

Semantically uniqueness - weak strong

Usage RealityAbstract (conceptual)

Current SBDH (partial view)For to know what BSD looks like

㩷

cd SBDH core

SBDH

Document Identification

PartnerManifest

<<abstract>>Business Scope

0..*

0..1

reciever sender

㩷

cd SBDH core

Package

Business Constraint

Business Context Context expression /

value

Impact by new concept on CCTS 3.0 “package”

YES

12

Appendix September, 2009 in Sapporo Developing a message with CSP

Message Standard

Header Bodyprocessing routing Auth.(SSO)

Profile of Message Body Organization CollaborationSBD

(Business Payloads)

Connection Error

SBDH

Etc.

Messag

e Lay

erT

ransp

ort L

ayer

Message Standard

HTTPBinding

FTPBinding

SMTPBinding

Etc.Binding

・・・

Physical Message IPAddress

encryption

Dialect in Specific Protocol such as HTTP

Do

cum

ent

Layer

Business Document

SBD (UN/CEFACT,CCL)SBDH

CS

P (static Inform

ation )

ebMS 3.0 & WSDL 2.0

13

Appendix January, 2010 in Vienna

EDIFACT BASE EDI MESSAGES

(a domain standard)

Order documentA 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

Normalizedform

normalize De-normalize

De-normalize normalize

Information from BOV

↓UN/CEFACT

Information from SFV

↓TBR

National Update flow of EDI Service

- a case of Ordering

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.

㩷 uc CSP Users

User

subscriber Service Provider Platform / Infrastracture

provider

Service

㩷

<<Registry>>CSP

(Composit Service Profile)<<use>>

15

Appendix CSP data model (tentative)

項目を追加したものを英語化する

会議までに