Discovery and Capability
Matching in ebXML CPP/CPA
Agenda
• Discovery in ebXML
• Collaboration Protocol Profiles and
Agreements
• CPP and SMP
• “Connect”
XML
Business Scenarios
Business Profiles
1
COMPANY A
Request Business Details
2
ebXML
Registry
3
Build Local System
Implementation
Register Implementation Details
Register COMPANY A Profile
ile
of
pr
A
Y
s
AN
ile
MP
of
Pr
CO
nd
ut
bo
sa
io
ya
ar
er
en
Qu
Sc
ad
lo
wn
Do
4
COMPANY B
ebXML compliant
system
nt
e
gem
5
n
rra
A
ess
n
i
us
nB
Ag
o
ree
DO
S
BU
I
SS
E
N
AN
R
T
S
N
IO
CT
A
S
6
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, WSSecureConversation
• 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/