Discovery and Capability Matching in ebXML CPP/CPA

Agenda

• Discovery in ebXML

• Collaboration Protocol Profiles and Agreements

• CPP and SMP

• “Connect”

ebXML compliantsystem

Business ProfilesBusiness Scenarios

ebXMLRegistry

XML

Request Business Details

1

Build Local SystemImplementation

Register Implementation DetailsRegister COMPANY A Profile

3

2

5Agree on Business Arrangement4

Query about COMPANY A profile

DownloadScenarios and Profiles

DO BUSINESS TRANSACTIO

NS

6

COMPANY A

COMPANY B

ebXML compliantsystem

Business ProfilesBusiness Scenarios

ebXMLRegistry

XML

Request Business Details

1

Build Local SystemImplementation

Register Implementation DetailsRegister COMPANY A Profile

3

2

5Agree on Business Arrangement4

Query about COMPANY A profile

DownloadScenarios and Profiles

DO BUSINESS TRANSACTIO

NS

6

COMPANY A

COMPANY B

ebXML compliantsystem

Business ProfilesBusiness Scenarios

ebXMLRegistry

XML

Request Business Details

1

Build Local SystemImplementation

Register Implementation DetailsRegister COMPANY A Profile

3

2

5Agree on Business Arrangement4

Query about COMPANY A profile

DownloadScenarios and Profiles

DO BUSINESS TRANSACTIO

NS

6

COMPANY A

COMPANY B

ebXML Standards

• ebXML RegRep– Registry and Repository– Registry Services (RS) and Registry Information Model (RIM)– Supports Registry Federation– RS has REST and SOAP bindings– Currently OASIS Standard at version 4.0, active OASIS TC– Main current uses outside e-business (healthcare, geographic

data and others)• ebXML Messaging

– OASIS Standard Version 2.0 (2002) and 3.0 (2007)– OASIS Committee Specifications Part 2, Advanced Features

(2011), and AS4 profile (2012) • Collaboration Protocol Profiles and Agreements

(CPP/CPA)

CPP/CPA

• Collaboration Protocol Profiles and Agreement• Version 2.0 is an OASIS Standard (2002)

– Support ebMS 2.0

• A Version 3.0 has been available in draft for some time– Adds extensibility to other protocols (Web Services,

AS2)– Support ebMS 3.0 (including Advanced Features)– Completion postponed until completion of ebMS 3.0

CPP and SMP

• CPP structure is Service-oriented– Metadata about services and actions a partner can

consume or produce, in one or more specific collaboration contexts, and associated business documents or composites

– PartyInfo > CollaborationRole > ServiceBinding > ActionBinding > Channel > Packaging, Endpoint information

• SMP structure is Document-oriented– Metadata for a document type that a partner can

receive, in the context of specific business processes – Party > Document > ServiceInformation > Process >

Endpoint – Largely a notational variant of a subset of CPP

CEN BII Example

• CPP would define the AcceptOrder and RejectOrder actions and associate documents to them

• SMP would define profiled OrderResponse documents and associate processes

CPA

• Collaboration Protocol Agreement (CPA) defines how two parties agree to collaborate

• Contains two PartyInfo structure for the two parties

• Identified using a cpaid attribute that can be referenced in an ebMS 3.0 AgreementRef.

CPA Formation

• Conceptually, a CPA can be formed by matching (“intersecting”) two CPPs– Functional specification in appendix– Implementations exist (e.g. Norwegian Healthcare, ENEA) but

are not widespread

• OASIS TC considered, but did not finish, a CPA formation business process

• Template-based approach is common– CPA is largely fixed with variables PartyId, cpaid, endpoint URL,

certificates– Implemented in open source CPA toolkit at Joinup

• Agreement Formation Description Document (AFDD)– Mechanism to describe how to set up a collaboration with a party

Status

• CPP/CPA 3.0 status – Work has been transitioned to ebCore TC – 3.0 draft schema supports ebMS 3.0 processing

modes, including AS4 and Part 2 Advanced Features (multi-hop, bundling, splitting, joining)

– Specification document not fully up-to-date with schema

– Spec would benefit from simplification and profiling– Needs resources to be completed

“Connect” Protocol

• Connect to a business partner using a message protocol– The registry would serve only to discover the endpoint

for the “connect” message, not to retrieve an SMP or CPP

• Services to be considered– Authorize an identified party (possibly for some

subset of services)– Obtain profile information from a party (capabilities

and/or delivery channels)– Provide profile information to a party– Publish profile updates to a party– Create/terminate a named agreement

Benefits

• Profile confidentialy– Hide endpoint information – Hide capability information

• Access control– Allow anyone but .. (blacklisting)– Allow nobody except .. (whitelisting)

• Personalization – Display different capabilities depending on who wants

to connect– Handle “experimental” or “deprecated” services or

services restricted to a “closed community”

Related Work• Initialization messages exists in many protocols:

– TLS handshake – Sequence lifecycle messages in WS-ReliableMessaging, WS-

SecureConversation• WS-MetadataExchange

– Has a GetMetadata operation to obtain service metadata for an endpoint

– Would need extensive profiling to fit in a four-corner model, e.g. by using ebMS headers; no concept of an “agreement”

– http://www.w3.org/TR/ws-metadata-exchange/ • Web Services Dynamic Discovery

– Find services by type or name by sending “probe” messages or by listening to multicast groups

– Provides a managed mode using discovery proxies– http://docs.oasis-open.org/ws-dd/discovery/1.1/os/

• OASIS Energy Interoperation– Party Registration Service– http://docs.oasis-open.org/energyinterop/ei/v1.0/