|
[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
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@a...] 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
|
|||||||||

Cart








