The Source for Java Technology Collaboration
User: Password:



Michael Champion

Michael Champion's Blog

Xml 2003 Reflections - Adam Bosworth Keynote

Posted by mchampion on December 19, 2003 at 06:58 AM | Comments (8)

[Another look back at the XML 2003 conference last week. I feel sortof blogspherically incorrect in waiting a week to write down these thoughts, but I wanted to let them bounce around a bit, and look at what others wrote.]

Adam Bosworth of BEA delivered the opening keynote address on Wednesday. He started by reminding us of the dream that XML geeks shared back in 1998: Information should not get lost in presentation. Actual XML practice has to some extent diverged into two separate streams -- documents on one hand, and application data on the other -- but together they have helped take back the world from the "hideous complexity and fragility" of information presented in .DOC, .EXE, etc. files.

I started to summarize the talk itself, then came upon Matt May's excellent near-transcript . I'll just elaborate on a few points that resonated with me.First, Bosworth notes that one of the negative aspects of the current XML world is that the KISS (Keep It Simple, Stupid) principle is being widely ignored, as XML and Web services technologies are becoming extremely complex. Bosworth has pointedly noted the complexity of W3C XML Schema and XQuery in the past; this time he said something like "there's only one guy in our company who *really* understands WSDL" ... and "we don't need all these layers of coordination/orchestration specs on top of SOAP, we need something like a 'SOAP cookie'." It's heartening to see more and more people pick up on the theme that the XML family of specifications is too complex, since I've been beating this drum for a long time now. It's definitely time for some serious refactoring of the the family of XML specs, and that won't happen until more people of Bosworth's stature start telling the unpleasant truths about what a few thousand person years of Design By Committee will do to a technology that used to be simple. The video clip from Bosworth's presentation in Jon Udell's weblog has my favorite quote from the talk: After admitting that 50 people would come up with 75 different ways of building distributed systems ."Some will win, some will lose. That's just fine. It's called evolution. It works really well. It's why we're all sitting here today." Maybe a bit of Darwinian Refactoring is what is called for on this stuff.

Another major theme in the keynote was that XML developers are asked to use "APIs from Hell." For example, a programmer working with a purchase order in XML format must deal with events, or child/sibling nodes in a tree, rather than application-level concepts such as products and quantities. Hmm, that's a posting in and of itself, because it ties in with a town hall meeting on storing/querying XML that turned into a discussion of XML APIs. More later.

Probably the most unconventional topic Bosworth spent time on was the importance of getting XML data models and APIs suitable for handling the synchronization of intermittently connected devices to Web-based master databases or applications. He noted that he spends much of his business week using only his Blackberry device. Effective use of such web-enabled, but slow and UI-challenged devices will require better synchronization tools: queries are difficult to generate with a handheld UI, and their limited bandwidth (if connected at all) means that it is important for queries to be very optimized to return back only the information the user really wants. Since this is so far beyond the state of the art, it may be easier for the device to anticipate the types of data the user will want, and trickle than information into the device in advance, as bandwidth is available, rather than on demand.

Bosworth presented a slide outlining a "Mobilized Data Model" that might help guide work on this. I suspect that many other listeners were also intrigued, but a bit mystified by this-- a planned demo wasn't ready in time for the conference. It has, however, generated some interesting discussion on the Web, not so much on the still-fuzzy details of the data model, but on the deeper issues. For example, Tim Bray notes that he is skeptical of the basic assumption behind the widespread need for synchronization, since "the trend is clear: anyone who wants to will be able to have a fast pipe that's always on." I'm not sure which side I come down on, but there is definitely two world views here: Those who assume that there will be a significant amount of data on the handheld device that must be synchronized with a central repository, and those who assume that in general the remote device will be able to query the central repository for the data it needs for a given task. Bosworth did offer one data point that might argue against Bray's position: At best, in the best-served places in the world a GPRS (General Packet Radio Service -- used for "always on" connection to the Internet by mobile devices) request takes 1 second to fulfill, and more if any significant amount of data is transmitted. Unless we get a WiFi network that is as extensive as the GPRS network today, it's not clear that the "fat pipe" assumption is realistic.

Another point that Bosworth has explored, not so much in his speech but in his weblog. How can one address the difficult challenge of synchronization without falling into the trap of complexity that will not scale to the Internet, or even work on a limited power and bandwidth device? He's asking a lot of questions about REST in the weblog, getting lots of answers, but one gets the impression that they are not satisfactory.

Inspired by a posting by Vanessa Williams, I'll put in a plug for the ideas behind JXTASpaces (sortof tuplespaces/Javaspaces using XML rather than objects) as a way of bridging the gap between the web services ideas that Bosworth talked about and the REST stuff that intrigues him. (Williams doesn't make the link to Bosworth in the posting, but has done so privately) . Kimbro Staken picks up the thread and mentions how an XML DBMS that supports XPath can make the template lookup feature of tuplespaces easy to implement if XML documents are the "tuples." I think they are definitely on to something here -- See Robin Cover's summary of some technologies and discussions, including some comments by me. The one point that's most relevant to synchronizing mobile devices is that coordination via "spaces" allows loose coupling in time as well as space -- not only can components in a distributed system employ different platforms, languages, and native data formats, they don't even have to be running at the same time. On the other hand, product ideas such as Ruple went nowhere and even the open source JXTASpaces project is a not exactly thriving. Is this just an idea whose day has not yet come, perhaps like hypertext before HTML? Or is there not really a "there" there? I'm pretty sure that if any application domain is tailor made for an XML Spaces approach, it's intermittently connected mobile devices!

Finally (just when I thought I was finally done blogging this speech!), Joe Chiusano asks about the apparent contradiction between Bosworth's focus on simplicity and BEA's co-authorship of a somewhat daunting list of Web services specifications. It will be interesting to see if Joe gets an authoritative answer from BEA; my guess is that they are telling it like it is in a recent press release that suggests [at least in my reading between the lines!] that customers are giving them the message that the current way of doing things is too complex.


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • Tuple spaces
    Wait a sec ... REST itself is very much like a tuple space based architectural style, only a whole lot better in many different ways IMO. I consider it "tuple spaces done right".

    All the good things you have to say about tuple spaces are generally applicable to REST (loose coupling in time and space, etc..).

    Posted by: distobj on December 19, 2003 at 10:33 AM

  • XML 2003 Reflections


    My non-expert take is that the "spaces" stuff could be layered on REST (with liberal use of POST, see Vanessa's post that I linked to) but that spaces have additional semantics that are important. For example, REST says nothing about querying other than that it happens with URIs and GET if the query is safe. The various tuplespace stuff defines a template lookup, associative memory like operation. As Kimbro notes (and as a prototype Ruple-Tamino integration proved), this can be easily and effectively implemented on top of XML DBMS technology.

    There's also the "take" operation, which is an atomic GET/DELETE in REST terms. That gets tricky to implement in REST, but is pretty critical to Linda-like coordination languages AFAIK. Timing and error handling is absolutely critical, so the usual REST arguments about safetyy/idempotency seem a bit strained, at best to me. For example, what happens if two clients GET the same resource they really want to "take", and are in a race to see who can DELETE it? I think you need at least WebDAV functionality to do this well in a purely RESTful way without using POST. Again, see Vanessa's post for a nice discussion of this in REST terms.

    Posted by: mchampion on December 19, 2003 at 10:49 AM

  • Tuple spaces
    Oops, I posted my reply to the original comment, not this one. See below.

    Posted by: mchampion on December 19, 2003 at 10:50 AM

  • Tuple spaces
    Hmm, I think we've had the microscopic discussion of REST vs. tuple spaces before, but the point I'm making relates more to the macro view. i.e. if tuple spaces can be considered some sort of unifying architecture for integrating other systems together (as you mentioned), why can't REST be that too? That's what the Web was designed to be; a system of systems.

    Posted by: distobj on December 19, 2003 at 01:26 PM

  • Fat pipes and mobile devices
    For what its worth, I began to grok the distinction between synchronization vs realtime data access from a mobile device today while sitting in a movie theatre waiting for LOTR III to start. (Even on a Sunday morning, it seemed like a good idea to get there way early, and I was right). I was trying to read the NYT book review section on my Treo device to fill in the time sitting there in the dark with ads on the screen. It worked OK, but sssssllllllooooowwwwwwlllllllyyyy. I was thinking -- "If I could have asked for it to "trickle" the book reviews while I was driving to the theatre so I could read them when I got there, I would have gotten thru a lot more before the movie starts."

    Not that this requires a new XML data model or XML tuplespaces rather than the Web, but it does indicate that the information on demand approach that the browser paradigm builds on isn't optimal for today's wireless technology. Also, a data model that let me get the raw text information rather than than all the ads, links, etc. that are approppriate on the Web but not a wireless PDA would help.

    Anyway, the experience led me to give one more point to Bosworth in the "fat pipes make synchronization irrelevant" argument. Of course, WiFi everywhere would make that point irrelevant, but why would a movie theatre have an incentive to offer WiFi access to patrons? I'm not holding my breath for that, but I'm now in the market for something like what Adam Bosworth described.

    Posted by: mchampion on December 21, 2003 at 06:23 PM

  • Tuple Spaces
    Ruple had some good ideas. The implementation was awful. I'm not sure how much Rogue Wave was or could have been truly behind the effort.

    I do think the concept of a tuple space is powerful and can be implemented in lieu of much of the WS-xxx complexity. Moreover it can be implemented and deployed and experimented with to form the basic substrate upon which the basic process-to-process evolution can take place.

    Posted by: patrickdlogan on December 23, 2003 at 04:45 PM

  • wow power leveling
    wow powerleveling
    wow power leveling
    wow gold
    wow items
    feelingame.com
    wow tips
    Most Valuable WOW Power Leveling Service
    wow power leveling faq
    cheap wow power leveling
    wow power leveling
    wow powerleveling
    wow power lvl

    Posted by: wowleveling3 on December 13, 2007 at 07:32 PM

  • 网络营销软件
    网络营销软件
    网络营销软件
    群发软件
    群发软件
    ---
    群发软件
    网络营销软件
    论坛群发软件
    网站排名软件
    群发软件
    推广小助手破解版
    论坛群发软件
    网站排名软件
    群发软件
    推荐给你很好的群发软件和信息群发软件和供求群发软件
    推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
    网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件

    群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
    信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
    网站排名软件
    博客群发软件
    网站排名软件
    网站推广软件
    群发软件信息群发软件
    免费论坛群发软件
    论坛群发软件
    网站排名软件
    免费博客群发软件
    网站推广软件

    群发软件
    博客群发软件
    网站排名软件
    网站推广软件
    群发软件信息群发软件
    免费论坛群发软件
    论坛群发软件
    网站排名软件
    免费博客群发软件
    博客群发软件
    信息群发软件
    论坛群发软件
    信息群发软件
    博客群发软件
    qq群发软件
    邮件群发软件
    博客群建软件
    企业名录搜索软件
    信息群发软件
    邮件群发软件
    论坛群发软件
    博客群发软件
    网站推广软件
    网络营销软件
    全能营销破解版
    网络营销软件
    论坛群发软件
    论坛群发软件
    论坛群发软件
    网络营销软件
    信息群发软件
    信息群发软件
    信息群发软件
    群发软件
    论坛群发软件
    群发软件
    网络营销软件
    网站推广软件

    Posted by: u89io98 on December 25, 2007 at 11:51 PM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds