[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issues with Lawrence Wilkes CDBI document and analysis of ebXML and WS-* (WS-I)
Mikkel, Unfortunately the analysis here by Lawrence contains some significant wrong turns IMHO. It starts out OK - but there are some underlying premises that I believe, even back in September 2005, if he had a better understanding of the ebXML work - he would have seen differently. http://www.oio.dk/files/ebxml-og-webservices-soa-rapport-mvtu-v1.0.pdf I'm particularly troubled by the Table on page 8 - because there is a critical missing column - "Linkage" - to indicate where compatibility / complementary use can occur. The most glaring is the BPSS / BPEL row - which is marked as "different" in the Overlap colum. As Oracle showed in the Helena Chemical implementation - BPEL / CPA / ebXML transaction model / BPSS are highly compatible and offer major ease of deployment and leverage between them. Table 5 on page 12 fails to make any sense given this real world production deployment and success that Oracle has shown. And the whole development of BPEL and BPSS v2.0.4 in OASIS has been carefully done so that these are clearly COMPLIMENTARY since they serve two very different needs. It is obviously significant that the table on Page 9 omits BPSS completely!?! Table 9 is also at odds with Table 8 - since ebMS v3.0 is noted supporting WS-* interoperability - but Table 8 notes "different". The Table 5 on page 12 is then hopelessly wrong and miscued. His comments on Convergence on Page 11 are insightful and poignant! However again - he mis-reads BPSS / Registry needs. Registry is in fact 100% interoperable already with UDDI mission and storing WS-* artifacts. BPSS is already covered above. I commend his comments on Page 13 - this is sensible. Forrester singularly failed to comprehend this in their flawed analysis. Another factor is what I call "DIY web services". This skews the figures. Many respondents are using DIY (Do It Yourself) Web services for internal and local point solutions - this is not formal eBusiness or eCommerce - has nothing to do with WS-I - but the components show up in these analysis reports - because noone is differenciating WHY they are using them. Infact the table shows that WS-I and ebXML - 17% and 11% - actually are very similar here - because of their specialized nature. Page 16 is not completely accurate in comparing Apache for OSS - since freebXML.org is equivalent. Unfortunately as I have discovered first hand Apache is now dominated by the "Big 6" - so any incubator projects that do not have a "Big 6" sponsor are simply NOT going to get accepted, or even considered. Page 18 makes a self-fulfilling statement: "b. The recommendation of both is likely to result in a status quo where neither appears to prevail. The result is increased cost and effort to support both standards" I find this is NOT compatible with my project experience. Many many other factors drive costs on the projects that are completely de-coupled from the standards selection aspects. In fact - I've seen first hand where ebXML was functioning well - and significant costs were expended to attempt to replace the functionality. What this tells us is that WS-I and ebXML are actually COMPLEMENTARY TECHNOLOGIES and you need BOTH - because their mission profiles fulfil different needs. Wilkes talks about this - but does not have the project experience to see why and how. Paradoxically we have been here done this before. Realtime EDI when it emerged was slated to replace Batch EDI within 5 years. Fact is it does not happen. WS-I is the new "realtime EDI". Bottom line is - there are a whole raft of business reasons why you do "batch B2B" - that result in secure reliable and predictable partner interactions. Yes - there are things you need to do in realtime - but that does not mean EVERYTHING - that gets you into many legal and process problems. The conclusion is that B2B is an integral part of SOA - adding significant value - and ebXML is the definitive method for B2B. It's very strange that of all people IBM fails to admit this! 20:20 hindsight says it would have much more sense to ask the OASIS ebXML JCC to comment on the report BEFORE you bought the "new airplane" from the WS-I vendors... Lawrence Wilkes from CDBI has published many articles for the "Big 6" on SOA and WS-I - several at their websites - but this report of yours is the only peice I could find that he's done that references ebXML. : -( I appreciate your openness here. DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework From: "Mikkel Hippe Brun" <MHB@itst.dk> Date: Thu, February 01, 2007 4:53 pm To: "David RR Webber (XML)" <david@drrw.info>, "Sacha Schlegel" <sacha_oasis@schlegel.li>, "ubl-dev" <ubl-dev@lists.oasis-open.org> Dear David and Sacha, Thank you for your comments. I suggest that we continue this discussion on ubl-dev. I was personally one of the promotors of using ebMS in the VAN infrastructure in Denmark. The National IT and Telecom Agency facilitated a process, where the VAN-operators developed the ebMS profile, and we were very happy with the outcome. ebMS is a simple and easy to read spec. However - we have not chosen to go with ebXML in the public sector for a number of reasons. * We had CBDI analyze and compare ebXML and the WS-* standards. See "The Role of ebXML and Web Service Protocols" at http://www.oio.dk/files/ebxml-og-webservices-soa-rapport-mvtu-v1.0.pdf The pdf contains a Danish introduction but the rest is in English. The report emphazises that the WS-* standards has more traction and vendor support than ebXML. * We asked the industry and the public sector in Denmark to come up with business requirements for an infrastructure. We also asked them about their preference in regards to the choice of standards. We made it clear that the easy choice (from a technology viewpoint) would be to go with ebXML. The feedback we got was that they wanted us to follow the WS-* road rather than an ebXML road because large suppliers like BEA, IBM, Microsoft and Oracle were supporting the WS-* stank of standards and the resolution of interoperability issues in WS-I. Denmark is part of the NES group and discussions about infrastructure is also an important part of the collaboration. We have spent considerable time on discussing how we ensure that messages can flow freely between different network infrastructures (ie. and ebXML framework and a WS-* based framework). It is our goal that it should be possible to exchange UBL messages across borders and between networks. Sweden has been using an ebXML infrastructure and now Denmark is building an WS-* infrastructure. Denmark has a strong PKI infrastructure and Sweeden does not. None of this matters because the establishment of gateways will ensure that messages can flow freely. We are currently establishing gateways to the VAN-operators such that UBL messages will be able to flow between the networks. It would be possible for us to make a similar gateway to a pure internetbased use of ebXML her in Denmark should anyone request it. We have invested lots of resources in ensuring interoperability between the .Net platform and the Java platform (Axis Sandesha and Rampart). Supporting SMTP in addition to HTTP in combination with WS-Security and WS-ReliableMessaging has also been a difficult nut to crack. It has been difficult to achieve some of the same capabilities that we meet in ebXML. But it was a deliberate choice we made. We support the use of open standards and every line of code we produce in this projcet is donated to open source. We are in no way relegious about these issues. I do not beleive that Europe will have one homogenious infrastructure because of national and regional differences in how security is handled. I congratulate the people behind ebXML for producing high quality standards and free tools. I would love to see more use of UBL around the world on any infrastructure. Best regards Mikkel Mikkel Hippe Brun Chief consultant, M.Sc. Direct: +45 3337 9220 Cell: +45 2567 4252 E-mail: mhb@itst.dk <mailto:mhb@itst.dk> National IT and Telecom Agency Center for Service Oriented Infrastructure Holsteinsgade 63 DK-2100 Copenhagen Ø Denmark Tel: +45 3545 0000 Fax: +45 3545 0010 www.itst.dk <http://www.itst.dk>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]