RE: [ebxml-dev] PEPPOL and ebXML opportunities - Call for participation

["Pim van der Eijk" <lists@sonnenglanz.net>]

Hello Mikkel,

Thanks for the invitation, and thanks for your continued
efforts to involve ebXML users and implementers in
e-invoicing. Unfortunately I will not be able to attend as I
will be at the eBIZ TCF conference in Brussels (*).
Hopefully some other people involved in ebXML can attend. 

I would personally agree that the requirements of SMEs,
which were central in the original ebXML project, have not
been taken into account much in some more recent standards.
For instance reliable messaging: the efficiency benefit of
setting up sequences for reliable messages (which typically
expire in 12 hours or so) are at best irrelevant to the
majority of those 23 million SMEs that may only send
business documents once every few days to most of their
business partners.  And sequence acknowledgements, even when
signed, do not support non-repudiation so they have limited
business value.  Newer is not always better.

It is also probably true that recent specifications have
been more difficult to implement than some others,
especially because there are some many of them nowadays
needed for a "full stack" solution. It explains the
popularity of protocols like AS2 and OFTP for EDI, despite
the massive vendor push for SOAP-based protocols.  But the
toolkit argument is also true.  As an example: everybody
uses SSL (TLS), which is in fact definitely not a simple
protocol and very few developers (let alone users) know much
if anything about cryptography.  There are just a few widely
used SSL implementations, but they very are easy to use
(and/or open source) and have a simple interface, so SSL is
everywhere.  SGML, another complicated spec from my personal
past, was basically saved by one free, high quality, open
source implementation, developed by one individual, which
everybody in the niche SGML community used. Very few people
were be able (or patient enough) to understand and implement
SGML, the initial market was small, the few commercial
parser toolkits could cost a thousand euros.  

But even if WS-* and eb* toolkits were as widespread and
simple to use as SSL toolkits are, a problem seems to be
that large communities of developers are just not
interested.  For instance, hundreds of thousands of Internet
developers use Python, and there are excellent libraries for
just about everything including networking, XML and
cryptography, but for WS-* there is almost nothing. Perhaps
there just is not a lot of demand for it and WS-* is hype
like eb* was 8 years ago .. 

With respect to SMEs and ebXML, it is worth pointing out
that the ebXML Messaging TC in the last two/three years has
in fact been working on extended functionality that attempts
to address their needs. The ebMS 3.0 Core Specification has
the "pull" feature, already in ebMS v3 part 1, which allows
small companies to engage in messaging in "client only"
mode.  With part 2 we are adding intermediary ("multi-hop")
functionality that extends this functionality significantly.
Appendix A of
http://www.oasis-open.org/committees/document.php?document_i
d=34174&wg_abbrev=ebxml-msg has a Peppol-like scenario.

Pim

(*) TCF is about e-business for the textile, clothing and
footwear industries, an industry that is mainly SMEs, and
employs millions of people in Europe. TCF has delivered an
architecture that also uses a UBL profile and supports
multiple communication protocol bindings, one of which is
based on ebXML. There are ongoing pilots that uses ebMS and
UBL with some small textile industry companies.

-----Original Message-----
From: Mikkel Hippe Brun [mailto:mhb@schemaworks.com] 
Sent: 29 September 2009 23:46
To: Farrukh Najmi
Cc: ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] PEPPOL and ebXML opportunities -
Call for participation at PEPPOL conference

Dear Farrukh,

Thank you for your questions.

> I am curious what the rationale was in PEPPOL to define a
new 
> specification for a registry model and interface rather
than building 
> a profile of an existing registry standard such as ebXML
RegRep. I can 
> certainly see value in defining a specialize
domain-specific client API but I am not sure I see the value
of defining a new registry model and interface.
> Can you share the thought process that led to such a
decision in PEPPOL?

The short answer is the following: We are not trying to
specify a new registry model but rather an interface that
can easily be implemented on top of existing registries. We
want something really simple that can be implemented on the
basis of ebXML RegRep, UDDI, some of the new REST-based
registries or even on top of LDAP or Active Directory.

The situation is the following:
* There are at least 300 service providers in Europe:
* There are 23 million SME's in Europe that within the next
5-10 years will be exchanging all their invoices
electronically
* Service providers are struggling to interconnect using ad
hoc technical solutions
* Service providers are struggling to interconnect using
bilateral agreements
* Service providers are not using a standardized addressing
scheme

You, me and others have tried to solve this problem with
various frameworks like ebXML or WS-*. And to be honest we
have only had moderate success with our attempts. We have
not been able to create a viral technology. We are not
seeing the adoption rate that we see with truly viral
Internet technologies (e.g. torrents).

I am sure that we can come up with a long list of reasons
for this situation, but I think that it is even more
interesting to try to identify the characteristics of
successful Internet technologies, and then try to build a
new framework that share the same characteristics.

So here is my poor attempt to come up with such a list.
Viral Internet technologies are characterized by the fact
that they:
* are really simple to implement (at lest in the first
generation until toolkits makes it easy to add more advanced
features),
* are highly scalable (a viral technology can handle mass
adoption and may even strive from it),
* have a good balance between cost and benefit for all
parties,
* are robust (hard to break or take down even if you wanted
to).

So getting back to the 300 European service providers. They
don't want a complicated registry architecture. They don't
want to put up an ebXML RegRep compliant registry or an UDDI
compliant registry. They want the simplest possible solution
based on the technology they know.
To achieve this we have now gone a step further to simply
our "Service Metadata Locator" specification by basing it on
DNS. A look up to this interface could be something like the
following:
http://5798000416642.ean.peppol.eu. DNS will resolve this
into an IP-address for a Service Metadata Publisher which
will return a signed XML-response via http. The XML-response
will contain all the information needed in order to exchange
business documents according to a well defined business
process. This approach enables global addressing on a really
simple and robust scheme and will be presented at our
conference. A DOS attack will be able to take down one of
the decentral Service Metadata Publishers operated by a
service provider, but it will not be possible to take down
our Service Metadata Locator.
Or rather - if this is taken down - then we are faced with a
bigger problem that will be resolved by someone else.

I hope that you can see that we are not trying to replicate
efforts here. I have not seen anyone solving the "global
addressing problem"
in a way that has really caught on. I hope that you would
agree with me that it is a "no brainer" to implement our SMP
interface on top of an ebXML RegRep product. People will
argue that this interface is too simple and that we will
soon be missing features and extension methodologies. And I
think that they are right - but I would just love to see
this problem show up - because it would mean that we have
succeeded in what we are pursuing. I truly believe that we
have a fair chance of succeeding with our approach. And I
would love if you can point out weaknesses as it would help
us steer in the right direction
- it will benefit any ebusiness framework.

Best regards
Mikkel


On Tue, Sep 29, 2009 at 4:13 PM, Farrukh Najmi
<farrukh@wellfleetsoftware.com> wrote:
>
> Hi Mikkel,
>
> I am curious what the rationale was in PEPPOL to define a
new specification for a registry model and interface rather
than building a profile of an existing registry standard
such as ebXML RegRep. I can certainly see value in defining
a specialize domain-specific client API but I am not sure I
see the value of defining a new registry model and
interface. Can you share the thought process that led to
such a decision in PEPPOL?
>
> ebXML RegRep has been adopted by various communities such
as Open Geospatial Consortium (OGC) [1], HL7, IHE etc. due
to its flexible and extensible information model (ebRIM) and
protocols (ebRS). Was there a reason why PEPPOL felt that
was an inadequate approach?
>
> [1] OGC ebXML RegRep SWG
>
http://portal.opengeospatial.org/?m=projects&a=view&project_
id=290
>
> Thanks for sharing the thought process.
>
> Mikkel Hippe Brun wrote:
>
> Dear ebXML community,
>
> I have once in a while been posting about PEPPOL (Pan
European Public Procurement Online). To put it shortly: It
is a 30 million Euro project with participation from 14
countries (with the recent enlargement). The project started
May 2008 and will end in November 2011. Our goal is to make
it possible for the 23 million SME's in Europe to exchange
business documents with any public sector organization in
the EU. Our focus is on eProcurement (pre-award and
post-award) however - our infrastructure is content neutral
and the European focus is just a matter priority for the
sponsors (The European Commission).
>
> The model that we are promoting is basically a four corner
service provider model. This implies that an SME should
connect to the infrastructure through a service provider and
that all service providers are connected to each other
through the PEPPOL infrastructure. The interconnection
between service providers is regulated by a mulitlateral
peering agreement and trust between service providers is
ensured through the issuance of a certificate to compliant
service providers.
>
>
> So why is this relevant to the ebXML community?
> -----------------------------
> The heart of the PEPPOL Infrastructure is two service meta
data 
> interfaces (basically an interface to a registry). Behind
this 
> interface could be an ebXML registry or an UDDI registry.
Current 
> specifications for these interfaces are published here: 
>
http://www.peppol.eu/Work_packages/wp8-Solutions%20architect
ure%2C%20d
>
esign%20and%20validation/specifications/v0-9-specifications/
> The idea behind the infrastructure is also that different
transport protocols can be used. The first transport that we
have introduced is the START specification (Secure Trusted
Asynchronous Reliable Transport (START) 0.9) but any
transport protocol could be used by service providers (e.g.
ebMS or even a proprietary protocol).
>
> I believe that there is an opportunity for the ebXML
community to piggyback on the trust set-up and the
governance set-up that we are implementing as part of
PEPPOL. I would therefore like to invite all interested
service providers and middleware suppliers from the ebXML
community to our next conference in Copenhagen on October
21th - 23nd. Participation is free of charge.
>
> For more information about the conference and the program
see: 
>
http://www.peppol.eu/News/events-1/peppol-innovation-confere
nce
> You may register here:
http://spreadsheets.google.com/a/peppolinfrastructure.com/vi
ewform?formkey=dGpHM3QtRGpQNnJQZU5jekRwXzBmckE6MA.
>
>
> Who should attend?
> -----------------------------
> You should attend if you have an interest in supporting
post-award processes and fall into one of the following
categories:
> ·         Service provider (E.g. Bank, VAN, eProcurement
solution 
> provider), ·         Provider of ERP and business software
·         
> Provider of Middleware solutions ·         Government
organization ·         
> Large private companies with many cross-border
transactions
>
>
> Would you like to exhibit or co-sponsor?
> -----------------------------
> The conference is co-sponsored by OASIS. If you would like
to exhibit at the conference and become a co-sponsor please
contact Jane Harnad from OASIS (jane.harnad@oasis-open.org).
>
> The conference:
> -----------------------------
> In overview the conference is structured in the following
way:
> *       PEPPOL executive day - Wednesday October 21st
> *       PEPPOL architecture day - Thursday October 22nd
> *       PEPPOL Middleware demonstrations and Programmers
"Hands-on" - 
> Friday October 23rd
>
> More information:
> -----------------------------
> For more information about the PEPPOL project see: 
> http://www.peppol.eu For more information about the
conference and the 
> program see: 
>
http://www.peppol.eu/News/events-1/peppol-innovation-confere
nce
> You may register here
http://spreadsheets.google.com/a/peppolinfrastructure.com/vi
ewform?formkey=dGpHM3QtRGpQNnJQZU5jekRwXzBmckE6MA..
>
> Please forward this invitation to your colleagues and
relevant public and private sector organizations in your
country.
> I look forward to welcoming you in Copenhagen
>
>
> --
> Regards,
> Farrukh
> Web: http://www.wellfleetsoftware.com



--
Venlig hilsen Mikkel

-----------------------------
Mikkel Hippe Brun
Resedavej 21, 2820 Gentofte
Denmark
@hippebrun
blog.schemaworks.com
Mob: +45 25674252