RE: [bdx] SMP and CPP

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

 

 

<pvde>

Comments inline

</pvde>

 

 

---

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: 16 June 2011 16:15
To: bdx@lists.oasis-open.org
Subject: RE: [bdx] SMP and CPP

Pim, 

Some comments inline as <mje>...</mje>

Yours, Mike

Dr Mike Edwards		Mail Point 137, Hursley Park
STSM		Winchester, Hants SO21 2JN
SCA & Services Standards		United Kingdom
Co-Chair OASIS SCA Assembly TC
IBM Software Group
Phone:	+44-1962 818014
Mobile:	+44-7802-467431 (274097)
e-mail:	mike_edwards@uk.ibm.com

From:	"Pim van der Eijk" <pvde@sonnenglanz.net>
To:	<bdx@lists.oasis-open.org>
Date:	15/06/2011 13:30
Subject:	RE: [bdx] SMP and CPP

---

 
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?

<mje> It is not supported </mje>    
 
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.

<mje>
At the moment, PEPPOL tries to avoid this "tower of Babel" problem by insisting on some common interchange format for the invoices.

Frankly, if a receiver wants to support a range of different invoice types, this would really depend on receiving out-of-band information
about the senders and then building code appropriately on the receiver side   PEPPOL really relies on the receiver saying what they
are capable of dealing with.

Of course, in a real system it is very likely that an AP provider would offer conversion services to their clients and as a result indicate
that the receivers can accept a potentially much wider set of document formats than they will actually receive
</mje> 
 

<pvde>

 

First of all, there may be users of BDX that are not PEPPOL. 

 

Even then,  PEPPOL (through CEN BII) allows organizations to support multiple profiled versions of a single document, say the UBL Invoice.  In one profile, the OrderReference is mandatory, in the other it isn't.  As a recipient of invoices, you may want to know if your sender is able to include OrderReferences or not.    If this were irrelevant, there would be just a single PEPPOL profile of the UBL invoice.  I thought the whole point of having multiple profiles in PEPPOL and previously in NES is that some companies support some profiles and others support other profile.

 

Also, why have an SML/SMP for recipients, and rely on out-of-band information for senders?   If the service information would cover both "can send" and "can receive" information, there would be no difference.  Right no the asymmetry seems illogical.   Supporting "can send" information in addition to "can receive" information seems like a simple extension.  A very similar standard like CPP has had this feature for about a decade.

 

 </pvde>  

 

  
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.

<mje>
Ultimately, the received document should have some kind of signature/certificate and it is this signature that needs evaluation - PEPPOL
envisages that this is achieved through a separate service which applies to the signature that the recipient can invoke.  Such separation
of concerns is, I believe, a good thing. 

<pvde>
If there is an assumption that the (ultimate) receiver goes to some document signature validation service separately from the APs, then the START WS-Security profiling (with added SAML tokens that express how the sender authenticated to the sender's AP) is apparently non-critical.  That's good news, as it would mean that a BDX would not require more WSS functionality than required by WS-I.
</pvde>  
 

 
PEPPOL takes the view that all APs have the same level of trust - and in particular the aim is to avoid ANY form of discrimination based on
source access point.  The end recipient is able to reject a document received from any given sender, but should NOT be able to do so
merely based on which route the document took through the infrastructure (ie which AP was used).
</mje>

 

<pvde>

 

I think the market acceptance of e-procurement solutions would increase of participants can express their sender capabilities.  E.g. to express "I'm an SME in country X and I will only send documents through AP Y (usually one in country X or some reputable international AP)".  Or to explicitly express an opt-out:  "I'm not ready for e-procurement yet".  

 

</pvde>

 
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.  

<mje>
In the approach taken by the PEPPOL specifications and the START protocol, the form of exchange between
access points is always of the "PUSH" form.

The low-end pull form of exchange is indeed for low-end endpoint and in the PEPPOL model this is the LIME
protocol used between a "low end" participant and the Access Point to which they are attached.  The assumption
is that no look up is required since the end user is signed up to one access point and has no need to search.
</mje>  

 

<pvde>

As I mentioned, e-business experience in countries where e-business protocols are used that support both push and pull (like Japan) shows that it is NOT just SMEs that want to connnect using pull.  It is also some very large companies exchanging millions of documents that would typically run their own AP.

</pvde>

 

  
 
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.
 
 
 

 
 
 

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU