[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]