bdx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [bdx] SMP and CPP
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: bdx@lists.oasis-open.org
- Date: Thu, 16 Jun 2011 15:14:32 +0100
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>
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.
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>
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>
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]