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

["Roger Bass" <roger@traxian.com>]

Mikkel,
 
thank you for your, and Christian's, very sensible presentation of the thinking here.  It makes perfect sense to me - and I say that speaking as someone who very much has SME needs and interests at heart. I think there is a way to reconcile the different views here, and perhaps take some of the heat out of this.
 
From a business perspective, as you're saying, what creates value is interoperability - not standardization per se.  Standardization is a means to an end - broadening interoperability and reducing its cost. It's not, in my view (though some here may consider this heresy), an end in its own right.
 
In the end, I think that standards that are lighter-weight, and interoperable at Internet-scale will win out - and that may not be WS-* at least in its present form.  But we're not at "the end", we're at the beginning - and interoperability between large classes of deployed technology (such as Microsoft WCF and Sandesha) creates significant value.
 
I also see the wisdom of the Danish government (as with most large enterprises) optimizing for a consistent internal SOA architecture - which as one requirement, is exposed to the outside world.  Also, as with most large enterprises, this is not surprisingly based on the stack by the major vendors to large enterprises, namely WS-*  From my perspective, delivering interoperability with the systems large enterprises use is a (perhaps the) key to delivering value to SMEs - and as such, I'm very pleased to hear about you holding Microsoft accountable for Sandesha interoperability.
 
However, as we continue scaling up, I expect two things to happen.  First, we will find other communities (probably including some that are ebXML-based), and will build connections there too for our customers.  But secondly, we will continue developing our *single stack* of internal technologies, to manage the scaling issues across increasingly large numbers of trading partners, with heterogeneous protocols, formats etc.  Since that will be internal, basing this on standards will not initially be a primary goal.  But over time, I expect it will make sense, even though I'd expect our technologists to make those decisions, not me.  And I'd expect that set of technologies to be based on simple, lightweight standards - quite possibly more like the ebXML stack than WS-*.
 
So, for me personally, that's why I'm glad ebXML exists, and expect to do more there at some point.  And as you say, I think the business needs will lead to the creation of gateways.
 
For this whole debate though (and not so much me personally) - did I understand Christian to say that the Danish government would be building (or funding) an ebXML gateway to your WS-* infrastructure?  And if so, when?  Those seem to me to be the only important question here from an end user perspective.
 
Regards,
Roger
 

________________________________

From: Mikkel Hippe Brun [mailto:MHB@itst.dk]
Sent: Mon 2/5/2007 12:42 AM
To: ubl-dev
Subject: VS: [ubl-dev] Where to next? - It's not the traction, nor supporting two stacks, nor any of this!



Forward from Christian Lanng

-----Oprindelig meddelelse-----
Fra: Christian Lanng
Sendt: 5. februar 2007 09:40
Til: 'David RR Webber (XML)'; Mikkel Hippe Brun
Cc: ubl-dev; fulton.wilcox@coltsnecksolutions.com; Roger Bass; Sacha
Schlegel; Stephen Green
Emne: SV: [ubl-dev] Where to next? - It's not the traction, nor
supporting two stacks, nor any of this!


Dear David

You probably don't know me, im the person responsible for the danish
infrastructure implementation effort. I've been following what have evolved
into a full fledged flamewar on this list and thought it was time to add a
few points you guys seem to be missing.

1) Denmark has nothing against ebXML or EBMS infact I was the one arguing for
adoption of UBL 2.0 within UN/CEFACT, at the UN/CEFACT plenary in Geneve, the
plenary that led UN/CEFACT acknowledging that UBL 2.0 was a steppingstone
towards a common UN/CEFACT/UBL standard and part of the ebXML framework. We
would neither commit a lot of ressources to building gateways towards other
infrastructures if we did not believe that ebXML was important.

2) Neither do we have anything against the "big six" as you name them. We
believe that they very much are an important part of digitizing our country,
but we are not afraid of them and we will continue to use our power as
government to pressure them towards open standards, full disclosure of specs
etc.. We know the challenge lock-in poses, both in the open-standards world
as well as in the closed, but right now we are fighting our battles one at
the time. Personally I think that your analysis of what is happening to what
is "REALLY" going on here is a little bit skewed, but you are probably right
in some aspects.

3) Mikkel and our government center is not charged with building the best
e-business infrastructure possible, we are charged with building the best SOA
infrastructure for the whole public sector as well as the private sector.
This a very ambitous project and like it or not and success is dependent on
convincing the "big six" that the cake is bigger for everyone if we create
interoperability. Microsoft is an important part of this interoperability,
right now 98% of the danish companies OS is from Microsoft and 63% of their
ERP systems are from Microsoft. That is a hefty bias in the decision proces
in Denmark, that doesn't mean we compromise everything and just jump on the
Microsoft bandwagon, we have chosen the WS-I stack because all the major
players have comitted to it and we have held Microsoft responsible for the
interoperability problems we have found between Sandesha and WCF adn vice
versa, which is why Sandesha and WCF are interopable in their newest build. I
know you might not like this or think that it would have been better to
choose the more "open" approach, but frankly speaking this is business
requirements and WS-I where we found the largest overlap between what the
businesses in Denmark where already running and the need for open standards.
It's not about the TRUEST open standard and it has never been for the danish
government, it's about fulfilling business needs preferably on
open-standards.

David it's okay you don't like the danish choice of standards for the
infrastructure, but you seem to be confusing vendor strategy with danish
government strategy. And the answer is same, as when I was blamed to be an
UBL sales representative at the Geneve plenary. Denmark is neither, we are
not a UBL representative or a WS-I representative we are representing users
and the market and business requirements. We believe UBL to be the best
choice for payload and therefore have committed a lot of energy and
ressources into UBL and we believe WS-I to the best choice for infrastructure
to fulfill the danish business requirements, yours might differ or might not
agree, but please don't make this a ideological issue, because that will hurt
UBL and it wil hurt ebXML as well.

Regards

/Christian Lanng



-----Oprindelig meddelelse-----
Fra: David RR Webber (XML) [mailto:david@drrw.info]
Sendt: 5. februar 2007 01:15
Til: Mikkel Hippe Brun
Cc: ubl-dev; fulton.wilcox@coltsnecksolutions.com; Roger Bass; Sacha
Schlegel; Stephen Green
Emne: [ubl-dev] Where to next? - It's not the traction, nor supporting two
stacks, nor any of this!

Mikkel,

It's much simpler than all of this.  We've been fighting this
"self-fulfilling prophecy" stuff from Microsoft and IBM especially for the
past five years - when they decided they wanted to step out from supporting
ebXML  for whatever reasons and agendas they had (sure - they had plenty -
but few they wanted to admit to - more on this below).

For me this is exactly the same battle and arguments that were thrown at
UNIX/LINUX for exactly the same reasons.

The double standard and hypocrisy are there for everyone to see.  

If the roles were reversed - do you think we'd be hearing any of these
arguments?  No - it would sooo eassy to put WS-* alongside SOAP/ebXML, no
problems.  Do you think we'd be hearing "traction" mentioned if WS-* had 11%
and ebXML 17% according to CDBI?

And project costs - I've seen first hand that maintaining the messaging stack
takes less than 10% of the project resources - the other 90% is all on
application support, XSD issues, java null pointers, database issues, and
performance tuning.  Also we know from the EDI world - once the messaging is
running - its very stable.  And we know this stuff just plain works - as
Norway can see from their NIA solution.

You have to look at what is REALLY going on here.  It's all about money,
contracts and lock-in.  I've been doing this consulting all now too long to
not realize this was why IBM got "cold feet" over ebXML - when someone said
"wait a minute, why are we doing this?  This undermines why customers need
Websphere, AND worse means all our competitors know
how to do all this - not just our engineering teams".   And Microsoft
said - "this undermines BizTalk server and our developer re-sellers" - so
they formed an unholy alliance - because they said they had "simple web
services that in six months would replace complex ebXML". Do you remember
that pitch?  Ironic is'nt it - five years later and their WS-* stack is way
more complex than ebXML.

Look if you want standards - anyone can BUY an ISO standard these days -
Microsoft just did it for OOXML... and now all the big guys have open source
solutions.

So what is the TRUE MEASURE of open public standards and solutions?

Does one segment of the marketplace gain significant lock-out by imposing
their standards on the remainder?  Open standards only benefit customers when
they create a broad marketplace - where costs over time are reduced and
implementers can easily deploy the technology.

So using ebXML here is your insurance policy. What if there are no
alternatives to WS-* ? Whatif WS-* v3+ is even more complex so that only the
few trained consultants know how to make this all work together? I'm sure the
sales organizations from the Big-6 are hoping for exactly that!!!

And notice that there has been a HUGE TREND ALREADY toward complexity with
XML.  UBL is a case in point.

What happened to the whole vision that Tim and Jon had back in 1997 - that
XML would be simple and human manageable and work with existing tools and
editors?

You cannot even OPEN a UBL schema and understand it - without using a $200
tool now...

(unless you are using a CAM template to guide you on your use model...is this
telling you something?)

Mikkel - please do not be blinded by this. 

I can give you 50 whitepapers that argue about the pro's and con's of ebXML,
WS-* and more - but the reality is that one technology is designed from its
foundation to be inclusive and accessible and totally public and neutral.
The other - well only "professional drivers on closed courses can be driving
those cars".

And since UBL is supposed to be the "Volks-Technology" enabling everyone to
do e-Invoicing - if I were you I'd be including that little piece of ebXML
"insurance policy" in your implementation mix.

But of course, when you do that, you will hear a chorus of wailing and dismay
from the "Big-6" partners - and that should be telling you something also.

The irony is that Oracle has the most to gain and to offer here to its
customers - and I beleive they sense that here.  This is simple value-add
that any Oracle customer can get right away for a small effort and cost.  And
Oracle is being very saavy these days in maintaining customer loyality by
emphasizing inherent benefits from their solution suite.

You maybe just so surprised here - to discover as the Canadian Government did
- that by including the use of ebXML - they suddenly found it makes total
sense and dramatically lowers the costs for their partners...

Thanks, DW

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



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org