1 / 13

Discovery and Capability Matching in ebXML CPP/CPA

Discovery and Capability Matching in ebXML CPP/CPA. Agenda. Discovery in ebXML Collaboration Protocol Profiles and Agreements CPP and SMP “Connect”. ebXML Standards. ebXML RegRep Registry and Repository Registry Services (RS) and Registry Information Model (RIM)

roxy
Download Presentation

Discovery and Capability Matching in ebXML CPP/CPA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Discovery and Capability Matching in ebXML CPP/CPA

  2. Agenda • Discovery in ebXML • Collaboration Protocol Profiles and Agreements • CPP and SMP • “Connect”

  3. 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)

  4. 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

  5. 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

  6. CPP would define the AcceptOrder and RejectOrder actions and associate documents to them SMP would define profiled OrderResponse documents and associate processes CEN BII Example

  7. 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

  8. 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

  9. 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

  10. “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

  11. 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”

  12. 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/

More Related