[
Lists Home |
Date Index |
Thread Index
]
HST. I like that. I still find it hard to believe that all the complexity of
SOAP+WSDL+UDDI (or pick any other acronyms from the list [1]) is a net
benefit. Or a Net benefit.
Standards bodies have an unwholesome (and largely unavoidable, though there
are exceptions) dynamic towards complexity. All I want to do is hook my
stuff together.
So, what can we do to get those calling the shots in Web Services standards
to:
1. Define a layered system, where the simple cases really are simple
2. Defend the complexity they introduce; explain the phenomenal benefits
that more than offset the complexity
3. Work with vendors to produce useful tools for "hooking stuff together"
with XML (including "low-tech" methods like XMLchucker or XMLbaton)
I don't even care if this comes out of the W3C or the WSIO. Developers need
this far worse than another 200 page spec.
.micah
[1] http://www.xml.com/pub/a/2002/01/09/soap.html
-----Original Message-----
From: Joshua Allen [mailto:joshuaa@microsoft.com]
Sent: Tuesday, February 12, 2002 10:57 AM
To: Micah Dubinko; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Principle of Sustainable Complexity
> Also with interest I observed Simon's thoughts on an 'XMLchucker'
> protocol--a simple send with (at most) a checksum back. I don't doubt
that
> such a straightforward protocol is already in use today, though it's
Yeah, there are plenty of ways to do this today. I still like DIME and
WS-Routing, because they anticipate a lot of problems that you run into
if you aim at an endpoint that doesn't have a direct TCP connection for
you (now we have proxies and NAT and other stuff all over the net, so
just "chucking" some XML to an endpoint in a totally generic fashion is
not so trivial anymore).
> file in a well-known file system location; process B reads, handles,
and
> deletes the file. Call it XMLbaton.]
Good point; this is very common and useful. Both of these get at what
Pat Helland calls "HST", or "Hook the Stuff Together". XML is great for
low-tech HST, and often all of the complication atop miss that point.
> There isn't a rich set of technical writings behind the simple
concepts
> like XMLchucker or XMLbaton. For one thing, the concepts are so simple
Again, a good point. It seems like everyone just rolls their own
implementations of XMLChucker and XMLBaton without necessarily having a
lot of knowledge of the best practices that other people are using. I
think that this sort of file-based HST in the Unix world evolved
splendidly with tools like grep, cut, etc. mixed with various network
copy mechanisms like FTP or NFS. I think that an actual
*implementation* of an XMLChucker or XMLBaton would exist more at the
level of something like GNU wget (which reminds me a lot of robocopy,
which many people use to chuck around XML batons). Having a set of
widely used (and no cost) tools for reliable copying, detection of files
being dropped in a directory, etc. would probably be quite helpful,
although I bet that Perl and things like wget would be sufficient. In
addition to the tools for chucking around XML batons in HST work, I
think there is another big gap that HST people run into, which is that
most of the existing HST tools for Unix are based on text files that are
delimited by LF. Things like grep, cut, and wc are workhorses of HST,
but totally inapplicable to XML. A set of similar command-line tools
that operate on XPath instead of LF would be a huge help in encouraging
adoption of XML, I think. I am aware that PaulT, Simon, and maybe some
others have toyed with these ideas, but I still can't download my
"mks-tools for XML". What gives?
|
