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

["David RR Webber \(XML\)" <david@drrw.info>]

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