RE: XML.COM: How I Learned to Love daBomb

[Michael Brennan <Michael_Brennan@allegis.com>]

The challenge of orchestration is a big one. But telling real world
programmers to wait and not use available technologies until this rather
esoteric problem gets sorted out is not realistic. 

Before programmers started using XML over HTTP to handle integrations across
the internet, programmers were left with the choice between complex,
inordinately expensive EDI technologies, or simply resorting to batch
transfers of data files over FTP. With XML over HTTP, the bar has been
lowered and distributed messaging is within the reach of those with even the
tightest of budgets. In addition, they are able to forge integrations with
far richer semantics than those relying upon the batch transfer of data
files. Services can collaborate in real time over the Internet, and the
technology is within the reach of even those with rather modest IT skills.

This is not being driven by the "web for web's sake", but by these very
practical concerns. Sure, as with every new thing that gets aggressively
marketed and overhyped, there is some fetishism of the new trend that is
happening. But there is also considerable real world benefit from all of
this, and that is the real driver.

And for at least the near term future, orchestration will be managed largely
by hand-coded logic, just as almost every real world business system does.
And so we proceed with small iterative steps, and build on top of the real
world experiences with proven implementations. That's what SOAP is all
about, and I think that's a perfectly reasonable approach.

And you are right, simple won't stay simple for long. Already there are
activities at OASIS to establish security-related protocols that can be
layerd atop SOAP. And XAML is supposedly working on protocols for
transactional semantics that can be layered atop SOAP. But SOAP will remain
SOAP (hopefully), and the solutions for these more complex problems can be
ignored by those who don't need them. And some criticize these industry
consortiums, but I'm much happier with new technologies being incubated by
implementors who build tools and work with them to validate the
specifications and gain real world experience before taking their proposals
to bodies seeking standardization.

The XML Protocol activity at the W3C is proceeding with a degree of openness
that is unprecedented for the W3C. No other WG has been willing to conduct
its work in public on a mailing list open to anyone. The WG has gone out of
its way to solicit input from anyone who wishes to offer it, and has
regularly approached the community of implementors on the soapbuilders list
(http://groups.yahoo.com/group/soapbuilders) to solicit input based on their
real world experience in working towards interoperability.

I understand your views of the ISO vs. the W3C. You take a reasonable
position in this matter. But within the framework of the W3C's
self-annointed role as a consortium that "develops interoperable
technologies (specifications, guidelines, software, and tools) to lead the
Web to its full potential as a forum for information, commerce,
communication, and collective understanding" (to quote the W3C's own home
page), the XML Protocol activity is a model for how such activities should
be pursued, IMO. And given that the XML Protocol WG is building on top of
real world experience with proven implementations, and given the active
collaboration within the SOAP community between large vendors such as
Microsoft and IBM and smaller vendors like Userland and independent authors
of open source tools, and given the unprecedented openness with which the WG
is pursuing this activity, I think holding this community up as an example
of how the "largest companies propose something, and everybody else rushes
to agree by joining the relevant Working Group" (to quote Edd Dumbill's
words) is simply disingenuous and insulting. 

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Friday, August 17, 2001 9:51 AM
> To: Dave Winer; Al Snell; Michael Brennan
> Cc: xml-dev
> Subject: RE: XML.COM: How I Learned to Love daBomb
> 
> 
> Good one, Dave.  Six.  We train ourselves not to 
> see commonplace things (of).  (A hint for such puzzles: 
> habit blinds you.  Read it bottom to top, right to 
> left.)
> 
> The web service challenge is to figure out 
> orders of events (orchestration).  The basic 
> interop based on sending essentially documents 
> back and forth has worked for non-digital systems 
> for hundreds of years (maybe thousands).  The 
> task is identification of the right service and 
> coordination given a complex task.
> 
> Simple tools for simple tasks, but simple won't stay simple 
> if it is all you know how to apply.   Most markup apps 
> start simple, then the requirements pile up.  If the 
> design is good, it grows gracefully.  Otherwise, it 
> becomes kudzu and you rebuild at tremendous costs.  
> Doubt it?  Gencoding is over 30 years old.  Why are 
> we using XML?
> 
> Hypertext became commonplace because of the 
> HTTP protocol and staying away from the requirements 
> of complex layout apps the requirements of which 
> were derived from 1000dpi print systems for 
> military manuals.   The system limits drive the 
> design.  The web designers weren't clever or 
> enlightened.  BBN and 72dpi screens had made 
> the hard choices.
> 
> Make sure the technology chosen is up to the 
> challenge of the task and that the task 
> is real.  Resist web for web's sake.
> 
> Len 
> http://www.mp3.com/LenBullard
> 
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h