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

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

I'm not telling THEM to wait.  I'm saying that 
for some of us who are Thralls, we have to wait because 
our tools aren't in yet.  We don't build at the metal; 
we using V*Studio or somesuch because we are a large 
and profitable business with many programmers and need 
the tools.  

Yes, web services work.  RPC has worked for a long time. 
XML simplifies that.  I leave it to Dave Winer to debate 
just how simple it can be. :-)

Some businesses don't hand code their processes. They 
use elaborate policy-driven systems.  Sometimes really 
roccoco stuff, on the other hand, cost and quality often 
have a dimension of complexity (see WBS-based systems) 
that is unavoidable.  All I am saying is the web stuff 
doesn't remove all of that complexity.  It can actually 
make it worse, but at the surface of moving coarse data, 
it makes it better.

I'm proud of the protocol group.  That is experience 
showing and a bit of guts.  The problem of the open 
noisy list is known and it comes down to the skill 
of the chairs.  (XML The Movie wasn't pretty, folks: 
say Planet of the Gapes).   XML Protocol on the other 
hand, like most protocol lists, has to stay open because 
as with any commodity, it needs buy in.  It is actually 
harder to open a list up the narrower the application.

ISO has a role to play.  Go to ISO when you need a 
well-documented repeatable process.  Governance needs 
that kind of organization.  They aren't a research group. 

Leche has a reference to a good article where the author's 
opinions coincide with much of what I've tried to say 
for some years here:  policies of "free and simple" can 
lead directly to the exact opposite results people think 
they are achieving.  There is a mammal and an information 
component to that:  in large distributed systems, you 
choose who chooses choices.  Failure to choose means 
you default to the system choice.

http://www.technologyreview.com/magazine/sep01/mann.asp

Part of the problem is that we are developing a communications 
medium with other communications media watching while 
we attempt to communicate about communicating.  To be trite, 
we are often victims of a "failure to communicate".

But we have more fun these days then when we had to 
cross oceans to meet people we had been exchanging 
letters with.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Michael Brennan [mailto: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