[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdx] SMP and CPP
I think I agree with all you say.
Little XML structures that can be retrieved using some party identifier key and
that describe a minimal subset of service configuration information about that
partner. The point is that I don't see why that minimal subset
should be limited to information about the documents that partner can receive
and not include information about the documents that partner can
send.
By the way, GS1 GEPIR is less limited that SML in having
contact details. I just looked up some companies that I
know, found (from their web site, or the phone book, street address not
required) or guessed the city for on http://gepir.gs1.org/v31/xx/search_by_name.aspx?Lang=en-US and
did find contact details (names, phone numbers, email addresses). If
I somehow know the GLN for those companies, I find that information
too. So GS1 has a different view on this? Your business register is
like GEPIR and does have names, phone numbers and email addresses
too.
Wouldn't it be useful to be able to have some contact details,
as an option, in SML/SMP? What if you retrieve an address via
SML/SMP, then send your first invoice and don't get a reply. Who do
you contact? Your (business) contact at the recipient company
may have no clue who in their organization is responsible for their
e-procurement messaging.
Pim From: Martin Forsberg [mailto:martin.forsberg@ecru.se] Sent: 16 June 2011 16:54 To: Pim van der Eijk; bdx@lists.oasis-open.org Subject: SV: [bdx] SMP and CPP 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] 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] 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]