SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework

["Mikkel Hippe Brun" <MHB@itst.dk>]

Dear all,

 

What a discussion we have started here. I have been away for the weekend and
will try to address some of the comments on my earlier post.

 

Concerning circular argumentation

------------------------------------------

Stephen expresses confusion about my apparent circular argumentation. I do
not disagree with Stephen and I understand why Stephen and others may be
confused by my argumentation. It's the dilemma of sanction vs. traction. I
was very inspired by Tim McGrath's presentation from UBL 2006 in Copenhagen
"UBL and UN/CEFACT - adding sanction to traction"
(http://www.ublconference.com/200611/programme.html).

 

Tim presented a slide with the following content:

 

What makes a standard

----------------------

* Formalized...

  * Has sanction, De Jure.

* Widely adopted ...

  * Has traction, De Facto.

* History tells us traction is more important than sanction

  * Internet versus ISO/OSI.

* So sanction is only a means to achieve traction

  * not a goal in itself.

* What makes a standard is adoption.

 

 

As I see it from a Danish perspective. We have a choice of two stacks of
standards which support the same business requirements. Yes - I know - ebXML
is more mature and has ISO standard status. And the individual standards in
the WS-* stack has varying degrees of maturity and are (mostly) standardized
under OASIS. Web service standards from the WS-* stack are being used all
across the public and private sector in Denmark. EbXML is being used by the
VAN-operators and by some companies in the Medico Industry in their exchanges
with some hospitals.

 

The point is that ebXML has more sanction (ISO) compared to WS-* (OASIS), but
ebXML has less traction than WS-*. Remember that I am talking from at Danish
perspective, but it is my gut feeling that this trend applies for most parts
of Western Europe. I know that this is not so in South East Asia.

 

Getting back to our choice of the WS-* stack. We are building an
infrastructure, which must support the exchange of business documents across
the public sector and in the private sector. We have to listen to our
software companies, which has already been using WS-* standards to integrate
applications. It is a fact of life that Windows Communication Foundation
(WCF) now supports WS-Security and WS-ReliableMessaging out of the box. The
"big 6" has been pointing in this direction for years. In the mind of the
Danish National IT and Telecom Agency, the WS-* standards developed under the
auspice of OASIS, are sufficiently open for us to support them. 

 

We would be criticized (and with good reason) if we were pushing ebXML to a
market which was already using WS-* standards. We have tried to swim against
the tide with X.25 and X.400 with little success. It is our job to make
profiles on top of prevailing standards (i.e. our RASP profile) to support
specific business requirements requested by the public and the private sector
in Denmark. We have great support for doing this work her in Denmark. I
believe that we need to develop a couple of other profiles supporting other
business requirements. Choosing which profile to develop next is something
that we will prioritize in collaboration with public sector institutions and
representatives from the private sector. It is not enough that only a few
companies asks us to support ebXML.

 

But we would support anyone who would like to build a gateway between our
RASP-profile and ebXML. We even support OSS initiatives in our Centre for
Software in the IT and Telecom Agency.

 

Concerning Axis Sandesha and Rampart

------------------------------------

Interoperability between Windows Communication Foundation and Axis (Sandesha
and Rampart) has the highest priority. We have been sponsoring and are
sponsoring parts of this work. It is not correct that "Sandesha will only
work with Sandesha". This may have been the case but it is no longer so.

 

 

Concerning the CBDI report
(http://www.oio.dk/files/ebxml-og-webservices-soa-rapport-mvtu-v1.0.pdf
<https://mail.vtu.dk/exchweb/bin/redir.asp?URL=http://www.oio.dk/files/ebxml-
og-webservices-soa-rapport-mvtu-v1.0.pdf> )

--------------------------

I will relay your comments to Lawrence Wilkes. I am sure you are correct in
your observations, but it still does not alter the balance of traction. 

 

Concerning NES

--------------

The North European Subset is a group of independent countries. There is no
intention to build a shared infrastructure. As I stated in my earlier post -
the collaboration deals with creating a common subset of UBL and ensuring
that messages can flow between the different countries. The important thing
is addressing and the exchange of addressing information between registries.
The main concern is interoperability, and we (Denmark) do not seek to promote
WS-* and WS-I in opposition to ebXML. We welcome adoption of ebXML in any of
the NES countries. It should not affect our ability to exchange UBL-messages
across borders.

 

The problem of CPA's

---------------------------

Admittedly - I do not have practical experience with ebXML CPA's. My ebXML
experience relates to ebMS and CCTS (which we try to incorporate in our use
in the public sector in Denmark). However - I have always been very concerned
with the whole concept of CPA's and we have been trying to avoid them in our
design of our infrastructure. We ask anyone using our infrastructure to sign
our multilateral exchange agreement (umbrella agreement). I guess would
compare to a Multilateral Profile Agreement (MPA?). We have 191 million
paper-based orders and invoices to digitize in the private sector in Denmark.
They are exchanged among 400,000 companies and I cannot see how we cannot do
CPA's prior to exchanging business documents. It is not doable! So in this
case some dictatorship is needed, and that's where our RASP-profile comes
into play. You basically have the option of specifying what protocol you
endpoint is exposed at (HTTP-endpoint or an SMTP-endpoint). The registry
contains information about what UBL profile (business process) you support
(in addition to version information).

 

I believe that we will get high volume rapidly with this KISS approach.

 

 

Best regards 

Mikkel