[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework
David, re your Sandesha comments, not sure I get it. a) you say database persistence is "essential"... is it? Sure, there needs to be some ability to recall "did I get this message already", but if a goal is lightweight implementation (and I'm suggesting it should be), then a full embedded database maybe overkill. It needs to be a black box, automatically purging any history beyond some short period. b) if Sandesha is delivering reliability, surely it must be doing something like what I describe above, even if there's no db. If you think it falls short feature-wise, can you say exactly where? c) is it an implementation of WS-Reliability or not? if so, surely it interoperates with other such implementations, or at least will do once interop testing happens Aside from that, your description of the NIH client seems to acknowledge that it's not actually doing secure, reliable P2P messaging - the servers are doing much of the work. For a lightweight client, I think the model used for online banking / payment services can apply - i.e. the server is the definitive record, the client just needs a robust way to recover if there's an error. Roger ________________________________ From: David RR Webber (XML) [mailto:david@drrw.info] Sent: Fri 2/2/2007 10:20 AM To: Roger Bass Cc: ubl-dev Subject: RE: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework Roger, Super questions and notes - see my responses in-line. Thanks, DW "The way to be is to do" - Confucius (551-472 B.C.) -------- Original Message -------- Subject: RE: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework From: "Roger Bass" <roger@traxian.com> Date: Fri, February 02, 2007 12:31 pm To: "David RR Webber (XML)" <david@drrw.info> Cc: "ubl-dev" <ubl-dev@lists.oasis-open.org> David et al, As you know, my company is probably a reasonable proxy for what's easy for SMBs to implement here, since we are actually deploying systems for such businesses today. Strategically, I'm very inclined to like the whole ebXML stack, and hope it gains traction. From a pragmatic perspective today, however, I have some questions as to what actually does make more sense for us to do. All this comes with the caveat that I am not a technologist, so some of my impressions here may be mistaken. 1. Ease of implementing secure, reliable messaging. We've not had to do this yet - we have successful, fairly high volume implementations all working just using https posts of XML via our Apache server. We'll doubtless want to add security / reliability features at some point soon, as volume ramps. Given that, Axis Sandesha looks like a reasonable option... and to me at least, appears easier than, say, Hermes for ebMS. Comments? >>> Sandesha is not yet supporting database persistence as default - that's essential - we're using DerbyDB embedded for Hermes. Most important difference though (because Sandesha is using very similar technical approach) is that Sandesha will only work with Sandesha - you have to have it on both ends. Whereas Hermes, or any other ebMS - will work together - so because the mechanism is a standard - its widely supported - independent of what ebMS engine(s) are involved on each end. <<< 2. Architecture/ P2P Messaging. For SMBs especially, low cost and simplicity are key. Minimizing complexity on the client side is a key element of that, we've found (leveraging services in the cloud to handle complexity). For the time being, to us, that points to secure, reliable delivery being a feature of your hosted mailbox, not the client. I don't exclude the possibility of large scale P2P infrastructure taking off - but not with technologies like Hermes that require an app server. Something more IM or Skype-like would be required, and I'm not aware of any such ebMS implementation. Consistent with the "hosted messaging mailbox" notion, I think there's a good argument that says this stuff will scale in a similar way to the operational map of the Internet itself - ie most traffic being via peering interconnects of a relatively small number of aggregators (tens-hundreds) of B2B aggregators. (BTW, there seems to be some work going on around open source P2P, but perhaps not quite with a B2B messaging angle. Intel released the open source Peer-to-Peer Trusted Library back in 2001... not sure where it's all at now). Any thoughts or pointers from anyone here on a lightweight ebMS P2P open source implementation? >>> Essentially this is what CDC/PHIN is doing here in the USA. Their ebMS client is what you are describing indirectly. Rather than the NIH appliance - which can initiate exchanges - the CDC/PHIN is a push/pull delivery client only - targetted to the CDC/PHIN servers. They provide hospitals with that client - and its gets stuff out of their ebMS "mailbox" and drops off the hospitals data. Big difference compared to SMTP of course is reliable delivery, and binary attachment handling, and dsig, SSL, et al - all of which CDC/PHIN is using. BTW - the CDC/PHIN system is mission critical for Homeland Security - it supplies all the raw feeds from the emergency response centers and hospitals across the US - in realtime 24x7. There is an OASIS member company supporting them now - and offering that toolkit independently - they are part of the ebMS TC.<<< 3. The stacks (centralized vs decentralized). I'm not sure we're far enough along that I get the difference between the heaviness (and proprietariness) of the centralized infrastructure required in the two cases. In particular, I'm not seeing why the messaging protocols (note the plural) that will be used to do these connections necessarily imply one or other registry model being used centrally (eb vs WS) - which almost by definition, needs to describe the heterogeneity of what's in use at various end points. >>> Agreed on the registry models. In most cases the end users see only registration web pages, and then REST api's for system-2-system lookups - they have know idea a registry is behind that. But - and its a big BUT - what I've seen in practice is that government systems today and security paranoid. So - its NOT simple to deploy to an external partner, even just using plain SOAP and SSL. The challenge is the INTERNAL Ops procedures to get a new partner stood up on both test and production systems. And the more parameters and files and extras you add to that process - the more chasing you do to support it - on both ends - the client and server. And then of course - once its all working - the following week - ops deploy some new release of the OS, database, firewall software - and the whole pack of cards stops working. Then of course - you have maintenance, bug fixes, upgrades. This is why I said - the real cost of supporting two standards is a flea bite compared to all of this other essential nonsense - that keeps the bad guys from hacking into your government systems. Therefore the fact that ebXML works based on just TWO parts - certificate and CPA - is vital. And greatly eases the central and remote maintenance burdens. That's the weight of infrastructure footprint I'm referring to. Again PDC/PHIN is a point in case - they are doing it on a relatively light budget - and certainly hospitals cannot afford highcosts - they want install and forget simplicity and reliability. <<< Hope that helps! Best, DW ________________________________ From: David RR Webber (XML) [mailto:david@drrw.info] Sent: Fri 2/2/2007 7:38 AM To: Mikkel Hippe Brun Cc: Sacha Schlegel; ubl-dev Subject: RE: SV: [ubl-dev] Danish implementation of UBL published as Good Practice Case in the EU eGovernment Good Practice Framework Mikkel, I checked out CBDI's credentials and for once they appear to be a balanced body. Unlike the recent Forrester report that was clearly little more than an infommercial that we have had to refute and debunk elsewhere. However it is totally frustrating to see the criteria used to support the decision - and I question the depth of research and sources used to obtain the outcomes. Obviously, as you note, alot of this is preferences - but if you ask mostly Catholics about religion - you will get certain answers. What I do see is that the WS-I* stack (I had to smile at your Freudian "stank" typo) - is significantly complex with many many more parts to it - and completely controlled and dictated by the "Big 6" you indicate. Also - in terms of the "Big 6" support for ebXML - only Microsoft is the hold out - all the others have solid implementations - and in the case of Oracle - their's is brand new and very good - see : http://dotnet.sys-con.com/read/318418.htm . And of course there are open source solutions that do work well in the .NET environment. When we look at the business drivers - one clearly is to enable small business participation. I fear that WS-I* is a technology stack for large corporates and military and government use where the requirements are for top-end levels of security and authentication - and costs and resources are not an issue. The OMG is a major driver in WS-I - and all their key members primary customers are US DoD and battlefield type deployments. The use case for small businesses is completely out of alignment with this. While clearly the barge has moved down the canal here - in terms of the WS-I decision - I would urge the NES to look again at adding ebXML capabilities - because this seems to be a low-hanging fruit, low risk option, that they can add - without major extra cost. 1) The two technologies can as you note - coexist together - and in fact, as you also noted, ebXML has certain unique features that are important - and you are already building this in for intra-country use (the new ebXML v3.0 adds significantly to this as well BTW). 2) Offering people the ebXML option empowers smaller businesses - both as service providers and users - and excluding particularly small service providers by going with a "Big 6" only solution - appears fraught and likely to be challenged as creating a closed restricted monopoly marketplace. 3) Having two solution stacks is very prudent - not putting all your eggs in one basket. We've already seen cases where one web-based infrastructure suffers some kind of network failure / attack - and then the alternative is able to offer relief and coverage, particularly if it is batch push/pull based as ebXML is. 4) Costs, scalability and delivery. One major benefit of the approach I outlined is that unlike the WS-I system where the central services require major infrastructure - the ebXML based one is distributed - so the demands on the central systems are massively less. We have to note here that the "Big 6" want to sell WS-I precisely because it is the opposite - and therefore up sells for them. Any installation already running Oracle AS today can immediately add ebMS support - takes less than a day to install and configure. 5) Extensibility. The ebXML option allows businesses to operate in a P2P way between each other without involving the central system. This has a huge incalculatable upside way beyond eInvoice - that clearly is missing from a WS-I centralized approach. I sincerely hope that NES can add back in an ebXML approach to compliment their WS-I decision - because two years from now - they will be thanking us for our foresight and vision - and counting the infrastructure cost savings and smiling. 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> --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]