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

[Matt MacKenzie <mattm@adobe.com>]

I agree with Farrukh, more or less.   While ebXML and WS-* haven't  
become viral, they are well thought out standards, probably because  
Farrukh and I were involved :p.   One of the reasons ebxml and ws-*  
didn't take off is because there has never been much industry harmony,  
too many bright people wasting time creating alternative  
implementations of the same thing.   It's not about the standard you  
use, it ends up being about the providers of that technology and their  
will to increase profit through differentiation. New standards that do  
the same thing merely narrow the field and create too many niche  
implementations, which in turn makes solutions more costly because  
their developers have to make up for volume. I would applaud your  
effort for leveraging existing standards which some of us have already  
spent a fortune standardizing.


Disclaimer: neither myself or my employer is actively involved in the  
ebXML market place and this is my opinion, not corporate policy.

matt mackenzie | sr. manager,
software development | adobe systems
office: 613.940.3631 | mobile: 613.884.6843

Sent from my iPhone, please excuse mistakes :)

On 2009-09-29, at 5:46 PM, "Mikkel Hippe Brun" <mhb@schemaworks.com>  
wrote:

> 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 transacti 
>> ons
>>
>>
>> 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