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

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

Thank your for sharing your thoughts. I agree with you 100%

On Wed, Sep 30, 2009 at 12:06 AM, Matt MacKenzie <mattm@adobe.com> wrote:
> 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
>



-- 
Venlig hilsen Mikkel

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