RE: [ubl-dev] SV: Where to next? - It's not the traction, nor supporting two stacks, nor any of this!

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

Mikkel,   

That was a not-so-short short note!   I'll try to be shorter too - there
is really no excuse for selling only one kind of "ice cream".    

I believe you are kidding yourself if you think this will make adoption
easier and go faster.  History, life, and prior experience tell us
otherwise.   

You key statement was "I hope that we can all agree that as long as UBL
payload can flow from one framework to another in a reliable and secure
fashion, then we are all OK!".  Re-reading the CBDI report - and that
line "while the ebXML stack is working to be interoperable, the same is
not true for WS-*" - oh really?   

We have learned over 20 years that there is no "magic" to B2B.  I can
give you the exact formula - and indeed that formula was embedded into
ebXML - partners, transactions, process, context, transport,
authentication, security, reliable messaging, queues and open
marshalling/unmarshalling.  You need to manage all those pieces.   

Problem is the W3C is not about B2B - so they built WSDL for
point-to-point - mono-structure exchanges.  So - horror of horrors -
web services are only a subset of what B2B requires.  Problem.  Enter
WS-I to "fix it".   

What does work here is the approach that Oracle and other vendors of B2B
solutions ALL HAVE today.  Basically they all have the ability to use
the B2B formula above - and because the transport is pluggable - they
can simply add in EDI, AS/2, ebXML, RosettaNet, HL7, etc, etc.   But
that is the rub - when they do that - there has to be compromise - and
they make their own mini-standards - that cause incompatiblities and
lack of full functional behaviour and interoperability across those
interfaces.   

Then along came ebXML - and everyone realized - YES - we can make this
so that it is an open, standard and everyone can support it.  When I
used BPEL and ebXML B2B together on the Helena project is worked
seamlessly because of this very reason - the CPA-based approach already
has all the B2B-formula baked in.   

But unfortunately WS-* is taking us back into those same dark
mini-standard caves again...of 100 customizations and extensions for
this and that and the other.  All broken down into mydrid fragments of
XML functionality that each have their own fiefdoms.  And conveniently
enough the "Big 6" have teams owning and working on building more
complexity into each...   

I hope you implementation is going well - I too have implemented an open
B2B and web service solution for NIH eReceipts - and it supports BOTH
the WS-* interfaces and ebXML seamlessly out of the box.  It's all
about open design, open queuing systems and status control, and simple
use of XML enabled mechanisms.   

I just question why - when I can do this with a team of 12 people - AND
develop a full eGrants system at the same time - that NES and the whole
of the Danish Government - and their consultants - cannot do it as well?
  

I hope that "baker on the corner" is going to be able to do UBL himself
- without needing a team of Big-6 consultants to push the buttons and
hold his hand.  But I fear that is not the case - instead he will be
calling the 800-# help hot-line A LOT and getting very frustrated
compared to just printing an invoice and mailing or faxing it.  

And your online forms - well - those will not cover everyones needs
easily - the Grants.gov approach has already gone down that path -
because the rules have to be too open, and no context can be applied -
because XSD has no context mechanisms...and without context central
rules cause downstream errors and failures.

Again - been there done that - seen it already for the eReceipts
project.     

Offering "treatments and pills" and people to talk to - to take the pain
away - is no substitute for good simple design that prevents the pain in
the first place.   

Cheers, DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

 -------- Original Message --------
Subject: [ubl-dev] SV: Where to next? - It's not the traction, nor
supporting two stacks, nor any of this!
From: "Mikkel Hippe Brun" <MHB@itst.dk>
Date: Mon, February 05, 2007 4:38 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "ubl-dev" <ubl-dev@lists.oasis-open.org>,
<fulton.wilcox@coltsnecksolutions.com>, "Roger Bass"
<roger@traxian.com>, "Sacha Schlegel" <sacha_oasis@schlegel.li>,
"Stephen Green" <stephen.green@bristol.gov.uk>

Dear David et al

This will be a short post since I have to get back to work on rolling
out UBL
infrastructure. 

I think that we share the same goal: 

1. That it should be possible to exchange business messages with very
low
barriers 
2. and that it should be possible to do this on an open standards based
and
freely available platform.

We are establishing this freely available platform. I think of this as
putting up an ice cream machine with free ice cream. The ice cream comes
in
two variations, but we have to pick one of them: 

We have the choice of an ebXML organic flavor and the WS-* synthetic
flavor
with lots of GMO's. The kids says "Give us the WS-* flavor and we will
eat
lots of ice cream. We will integrate the ice cream in the heart of our
applications and do all our home work." I don't mind serving synthetic
ice
cream if it can motivate my kids to do their homework.

Once we get the ice cream flowing it will affect the ways we do business
immensely. Adoption rate is critical because the business case for
establishing an infrastructure is incredible. But we have to act fast!
Public
sector institutions are building infrastructure from the ground up every
day
based on WS-* standards and we have to stop the insane redundancy of
efforts
and waste of tax payers money. We can save 300 million USD every year in
the
public sector by establishing a shared infrastructure (We are only 5.5
million inhabitants in Denmark). It makes a world of a difference how
fast we
can establish the infrastructure. We do not have the luxury to choice of
the
organic road because it will affect adoption. We have support from very
small
companies as well as big enterprises. The toolkit that we are developing
will
make it very easy to use our infrastructure. I do not share the concern
that
our approach will only be to the benefit of governments and large
enterprises. It's a business requirement that the baker on the corner
should
be able to plug into our infrastructure with OSS components. We have
demonstrated that this can be done.

Well - I am getting back to work. I am so thrilled by what's happening
to UBL
at the moment. NES has invited other EU member countries to a workshop
in
Brussels on February 15th to get more support. The UBL TC has succeeded
in
creating a viral technology and I congratulate all of the hard working
TC
members for their contribution. You have given us the payload, which
will
drive the establishment and roll out of infrastructure in Denmark and
around
the world.

I hope that we can all agree that as long as UBL payload can flow from
one
framework to another in a reliable and secure fashion, then we are all
OK!

Best regards
Mikkel

>