-------- Original Message --------
Subject: Re: [ebxml-dev] PEPPOL and ebXML opportunities - Call for
participation at PEPPOL conference
From: Mikkel Hippe Brun <mhb@schemaworks.com>
Date: Thu, October 01, 2009 5:37 pm
To: Pim van der Eijk <lists@sonnenglanz.net>
Cc: Farrukh Najmi <farrukh@wellfleetsoftware.com>,
ebxml-dev@lists.ebxml.org
Hi Pim,
I am sorry about my incomplete previous post. I got distracted and
pushed the send button. Let me try again.
You put it very clearly. It is the exact same reasoning that we have
been through. I must admit that we in Denmark did not fully understand
that the differences in business requirements expressed by SME's and
the business requirements expressed by large organizations cannot be
solved by technology alone. We did a SOAP-2-SMTP binding but as you
say even reliable messaging has a timeout if the "baker" never opens
his laptop. Large organizations are very reluctant to support an
otherwise reliable protocol but with an unreliable business partner
(in the sense that you never know when he will turn on his PC).
So what is the solution to this in PEPPOL?
PEPPOL is basically a Service Provider model. A Service Provider may
use any protocol to connect to his customers. One standard protocol
would be better, but that is a different story. So we have a strong
focus on making it easy to interconnect service providers and we do
not want to be disruptive by breaking their existing business models.
What about the SME's? I realize that just interconnecting service
providers does not make it any easier for an SME to connect. Service
providers have traditionally been protecting their markets by
supporting many protocols with an effecitve lock-in effect. In PEPPOL
we have addressed this by profiling WS-Transfer in a profile we call
LIME*. This is a protocol that can be implemented using HTTP and TLS -
the tools that the Python (etc.) communities are familiar with.
Similar to the ebMS 3.0 pull feature, but super lightweight. The
challenge is to pursuade the service providers to offer such a
standardized lightweight protocol that will make it easier to change
service provider and thus create greater competition. It is not really
in their interest. Demand has to come from customers. We have to
engage the suppliers of business software in this. "Off the shelf"
business software should support such a protocol.
Some years ago I would have argued that we do not need service
providers in order to do eBusiness. The Danish infrastructure is an
example of this approach. The result has been that the public sector
and larger private organizations can send and receive eInvoices. SME's
can only sende eInvoices because larger organizations will not send to
SMTP endpoints. But effectively this model is also a service provider
model. Even SMTP servers are offered as a service - it is just your
ISP serving you.
I am expecting that we with the PEPOL approach will see a lightweight
protocol being a standard offering from service providers. It could
even be offered by ISP's just like they offer flat rate use of SMTP as
part of your Internet subscription. It is not many years ago that we
paid for these services.
Best regards Mikkel
On Wed, Sep 30, 2009 at 8:25 PM, Pim van der Eijk <lists@sonnenglanz.net> wrote:
>
> 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
>
>
--
Venlig hilsen Mikkel
-----------------------------
Mikkel Hippe Brun
Resedavej 21, 2820 Gentofte
Denmark
@hippebrun
blog.schemaworks.com
Mob: +45 25674252