RE: [bdx] SMP and CPP

["Pim van der Eijk" <pvde@sonnenglanz.net>]

 

Hello,

 

I am doing some further work on this topic and have a related question:

 

With SML and SMP,  a sender can look up information about a recipient,  such as where its Access Point is that messages can be sent to,  and the types of documents the recipient is able to process.

 

How about the reverse:  a receiver wants to find out which documents a sender is able to send,  and from which Access Point those messages will come.  Is this supported in the draft SML SMP documents.  If not,  why not?    

 

Here are some reasons why a discovery process for receivers may be relevant:

 

1)   A company that is looking to implement an e-invoicing solution wants to know what sort of invoices his top 100 suppliers are able to send.  He could send out 100 queries and get the relevant information.

 

2)   In real life, not all APs may have the same level of trust.  As a security check,  a company (or its AP) could validate that document it receives from some other AP on behalf of some sender are indeed from the AP that this sender uses, and a type of document that the sender is registered to be able to send.

 

3)   Communication between APs could be push" based (i.e. sender connecting to recipient to transfer message), but also "pull" based (a recipient connecting to a sender to poll for messages).  (Pull is typically associated with supporting low-end endpoints (e.g. of SMEs),  but experience shows even some large companies (and potentially APs) prefer pulling).  This requires a lookup of connection details for the sender by the recipient. 

 

In CPP terminology,  the mechanism could be supported by including not just "CanReceives" in the participant profile (as in SMP), but also "CanSends", as in CPP/CPA.  The DNS-based discovery would not require any changes.

 

Pim

---

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 28 March 2011 17:53
To: bdx@lists.oasis-open.org
Subject: [bdx] SMP and CPP

 

To follow up the presentations of some time ago,  here is some information on the SML/SMP concept and the ebXML Collaboration Protocol Profile (CPP) concept.  

 

Mike's employer developed precursors of CPP/CPA and submitted these concepts to OASIS during the ebXML project.

 

CPP references below are to the version 2.0 OASIS Standard: http://www.oasis-open.org/specs/#cppav2   

(There is a newer version 3.0 in progress, which has many potentially relevant extensions, but it is still in draft).

 

First of all similarities:  there is very much overlap: 

party info, services, business processes, messages exchanged,  schemas of those messages, endpoints and protocols supported.

 

There are some differences. 

 

1)  SMP has metadata for a particular document type that a partner can receive, in the context of specific business processes.

A CPP defines which messages a partner can receive or send, in one or more specific business processes, and associated business documents or composites.  

 

2) In a CPP, the nesting hierachy is PartyInfo > CollaborationRole > ServiceBinding > (CanSend | CanReceive) > Channel > Packaging, Endpoint information etc.    

In SMP the hierarchy seems to be Party > Document > ServiceInformation > Process > Endpoint.

 

CPP seems to be a bit more service-oriented  (you interact with a service by invoking actions on it), whereas SMP is more resource-oriented (where somehow the resources are documents), but the differences are minor.  It may even be possible to write an XSLT that transforms an SMP to a CPP or the other way round ..

 

Below is a visual representation of the version 2.0 CollaborationProtocolProfile XML scheme element, and attached is a(n ancient) example CPP.