Re: [bdx] SMP and CPP

[Kenneth Bengtsson <kenneth@alfa1lab.com>]

Hi Pim

I think you are raising some important and interesting issues. Please see my comments inline as <kebe>...</kebe>

Best regards,

Kenneth Bengtsson

From: Pim van der Eijk <pvde@sonnenglanz.net>
Date: Thu, 16 Jun 2011 23:27:49 +0200
To: 'Mike Edwards' <mike_edwards@uk.ibm.com>, <bdx@lists.oasis-open.org>
Subject: RE: [bdx] SMP and CPP

 

 

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

 

<kebe>

The logic here is actually quite simple. First of all let's talk about buyers and suppliers instead of senders and receivers, since both the buyer and the supplier will at different points be both sender and receiver. The buyer sends an order to be received by the supplier, the supplier sends an invoice to be received by the buyer etc.

Part of that logic is that both parties will at some point be the sending party and will therefore look up the capabilities of the other party, but the real value here is what is called a "business process" (or sometimes just "process") in the current SMP spec - which is the same as is called "collaboration profile" in CEN BII and "BIS profile" in PEPPOL. The "business process" describes both which documents a party is capable of sending and of receiving, and it also describes the party's capability of producing documents with references to existing documents.

We should logically be able to assume that a buyer (or "receiver of invoices"), who wishes to know if the supplier is able to include an OrderReference, is actually himself able to produce an Order document that can be referenced. So the logic begins when the buyer wishes to send an Order to his supplier. Through the SML/SMP discovery he is able to establish if the supplier is capable of receiving his Order document, and also if what business processes the supplier supports. Let's say that both the buyer and the supplier support the same simple business process consisting of Order->Order Response->Invoice. If the buyer sends his Order with reference to the business process he can also assume that 1) the supplier will respond with both the Order Response and eventually the Invoice document via the same channel of communication, and 2) the supplier will include the OrderReference with reference to the original Order document in all future communication. If on the other hand the supplier only supports a business process consisting of receiving an Order and no further transactions, then the buyer will also know that the supplier may not be able to include the OrderReference in future communication.

To put it more functional:

The SML/SMP lookup provides the originator (sender of the first document in a business process) with the knowledge of what types of responses the other party is capable of returning. The "business processes" (or CEN BII collaboration profiles) provides the originator with a tool to communicate to the other party what type of response he expects in return. So if the originator has sent for example an Order document under a business process that does not include any further collaboration, then he has also explicitly communicated that he does not expect any response in return. And if on the other hand the originator has communicated through the use of a business profile that he does indeed expect a response, then the other party can also reasonably to assume that he is capable of receiving it.

</kebe>

  
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>  
 

<kebe>

Why is it an objective in itself to have a signature in the document? Shouldn't the objective instead be to be able to establish with certainty the authenticity and origination of a document?

The START profile includes security that enables an AP to establish both the identity of the AP it communicates with, and to establish that a received document has not been tampered with in the process. How and why the AP's should trust one another is a different concern and would be, I assume, dependent on the formal requirements of any given infrastructure. In PEPPOL this trust is achieved by only issuing certificates to AP operators who have signed a formal agreement governing their responsibilities and use of the infrastructure, so in this case you can say in a way that the document transaction between two AP's has been "signed" and that signing the actual document therefore is redundant. Another application of BDX to establish trust in a different infrastructure could be a formal requirement to sign the actual document.

The current SMP spec supports communicating whether document signing is required or not: ServiceInformation/ProcessList/../Endpoint/RequireBusinessLevelSignature

</kebe> 

 
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>

 

<kebe>

That is an interesting point. I am assuming that the implementation and operating costs are somewhat the same whether you implement "push" or "pull" (at least in a SOA with limited number of endpoints) and that the costs are somewhat somewhat higher if you are to implement both. Do you know why these large companies chose to implement message "pulling" instead of "pushing"?

Anyway, I am not sure of the level of complexity required for implementing this in the 4-corner model. I see at least two challenges:

1) How is the "pulling" initiated? In a large infrastructure with thousands (maybe even hundreds of thousands) of endpoint it is not practical to have to ask each and every endpoint if they have any documents waiting for you to receive, so I guess the sending party has to either send some kind of notification to the receiver saying "here, I have something waiting for you to pull", or you would need to introduce a central registry for messages pending to be received. Right?

2) In the 4-corner model the sending party is capable of discovering the receiver's collaboration capabilities. In this context it seems most logical for the sender to "push" the message to the receiver so as to instantly make sure that the receiver is actually capable of receiving the document, and to negotiate which document (if any) is expected in return. In the "pull" scenario I guess you would either postpone these "negotiations" until the point where the receiver actually connects to the sender, or you would have to trust that the receiver always "pulls" with the same capabilities that he had when the document was sent. Right?

Of course it can be implemented somehow... Also in the 4-corner model. The question really is what it is going to cost in terms of added complexity.

</kebe>

---

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