Hi Pim,
In Sweden, SFTI (Single Face To Industry) has set up a capability registry with information about which standards, contact persons, identifiers the trading partners supports. We didn’t receive any requirements for it to be machine-to-machine accessible (at this point at least) so it does not currently support runtime look-up of technical addresses. https://partsregister.sfti.se/Unsecure/Pages/ListAllActors.aspx
We have found the SML/SMP solution to be very straight-forward and effective (and easy to understand and implement) and many operators are seeing the SML/SMP as a solution to the routing and addressing issues that we have today. I’m sure there are different reasons for this but some positive things that I have heard are:
· You don’t have to expose the full registry – all look-ups are done against a one identifier at a time (so no wild card searches)
· You can describe in sufficient detail the technical stuff that is needed (transaction, process, syntax, contextualization, transport profile)
· You only expose the service details, not end users business information (like contact persons). It is often considered a problem if competitors can search your registries for your customers contact details.
I can personally see a use case for REST-full interfaces using the SMP structure. Gov-data for example is often made accessible for download. The SMP could store the REST-url and the type definition and the client then Gets/Pulls the document from the registered address.
So a service registered in a SMP does not necessarily have to be a “send-to” service, right?
/Martin
Från: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Skickat: den 15 juni 2011 14:30
Till: bdx@lists.oasis-open.org
Ämne: 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?
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.
