bdx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [bdx] SMP and CPP
- From: "Pim van der Eijk" <pvde@sonnenglanz.net>
- To: "'Mike Edwards'" <mike_edwards@uk.ibm.com>, <bdx@lists.oasis-open.org>
- Date: Thu, 16 Jun 2011 23:27:49 +0200
<pvde>
Comments inline
</pvde>
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]