[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML.COM: How I Learned to Love daBomb
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@i...] > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|