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

[Mikkel Hippe Brun <mhb@schemaworks.com>]

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%20architecture%2C%20design%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-conference
> You may register here: http://spreadsheets.google.com/a/peppolinfrastructure.com/viewform?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-conference
> You may register here http://spreadsheets.google.com/a/peppolinfrastructure.com/viewform?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