Web Things, by Mark Baker

Please consider submitting something! Eye candy, RESTful services, Semantic Web, and yes, even Web services stuff… As long as it’s of interest to developers!

Call for Participation
Developers' Day
World Wide Web Conference 2005
Feb 28, 2005

Developer's Day at WWW2005 promises to be the most exciting yet.  We
have arranged a keynote talk by Makoto Murata and two special all day
sessions for those interested in dynamic Web Design.   However, to make
the day even more exciting, we are soliciting ideas for topics and
presentations.   In particular, we are requesting proposals for
individual presentations or, preferably, multi-talk tracks.  It is
expected that four or five parallel sessions will be offered, with
presentations in each focusing on tools and techniques for the World
Wide Web.  Preferred tracks and presentations will be of interest to a
wide range of participants working on Web-related development.

Potential topics and tracks may be for a particular area of Web
development -- Web Services, Semantic Web, RDF or XML tools, etc. -- or
for cross-cutting topics that may be of interest to those in multiple
areas -- forms, compound document and multimedia integration, so-called
"rich web apps" making innovative use of Javascript, new developments in
search tools, best and/or advanced practices in Web application
development, etc.

Submissions should be in the form of an abstract of no more than 500
words for an individual presentation.  For multiple-presentations or
tracks, please be sure to indicate the approximate length and how many
presentations, and include up to a 1/2 page on each planned
presentation.

Submissions will be accepted on a rolling basis with a final deadline of
March 25 2005.

The Developer Day 2005 home page is; http://www2005.org/dday/
Submissions should be sent to chair_dev@www2005.org

Just like they dropped their XML search capability (http://www.google.com/xml) a few months after deployment. Sigh.
(link) [del.icio.us/distobj]

Update; mea culpa, it was of course Steve’s post, not Tim’s. My apologies to both. One of the disadvantages of reading blogs through Bloglines, since all the styling is lost.

A thoroughly enjoyable post from Steve. After a preamble on isomorphism, he presents an example SOAP message and asks;

So, an open question to the audience: are the SOAP messages I described above more “RPC style” or “document-oriented?” Are these services talking to each other, or stateful objects? Are you a good witch or a bad witch? To all these questions and others I answer: mu.

My answer is that they are RPC style. Let me explain further in response to his conclusion, which reads;

Amazon.com’s e-commerce implementation is one of the most successful and highly touted REST API’s in existence today. The implications of the fact it’s also 100% structurally isomorphic to SOAP + WS-Addressing are left as an exercise to the reader.

Actually, it’s not isomorphic in that sense since the contract is very different in the REST and WS/SOA cases (does that fall under “structurally isomorphic”? dunno).

Let me start by tweaking Steve’s example to be what I would call a “document-oriented” style interaction;

<S:Envelope xmlns:ht="http://schemas.hyperthink.net/" ... >
   <S:Header>
     ...
    <wsa:To>http://hyperthink.net/xml</wsa:To>

    <wsa:MessageId>uuid:123...</wsa:MessageId>
    <wsa:ReplyTo> ... </wsa:ReplyTo>
    <ht:Service>CommerceService</ht:Service>

    <ht:SubscriptionId>12ABC</ht:SubscriptionId>
     ...
   </S:Header>
   <S:Body>
     <ht:CartId>47</ht:CartId>

     <ht:HMACToken>[blah]</ht:HMACToken>
   </S:Body>
</S:Envelope>

Notice the difference? wsa:Action has been removed. So I could submit that message to a service, and it could return exactly the same response as Steve’s example service does (though I’d remove the wsa:Action from it too).

Document in, document out. Simple.

Now, back to Steve’s Amazon URI based example. My claim is that the contract is different, just as the contract is different between Steve’s GetCart example and mine above. Specifically, with the SOAP message, the request semantics are “GetCart”, and the response semantics are “GetCart was successful”. But in the URI example, the response semantics are “GET was successful” since the request semantics are GET. In other words, with the URI, the client has zero visibility into the semantics of the “GetCart” string (aka the URI is opaque), but in the SOAP message, it has full visibility.

So rather than provide homework as Steve did 8-), I’ll ask a single multiple choice question; what’s the operation in my SOAP message example above? Is it;

• A. GetCart
• B. ProcessMessage
• C. POST
• D. B and C
• E. There is no operation

Hint; there’s always an operation, since something has to succeed or fail.

An interesting presentation from Sam upcoming at ETech. It’s titled ‘”Just” use HTTP’, and this is said about it;

Unlike other talks about newly emerging topics, Ruby’s centers around the reemergence of appreciation applications centered around the venerable HTTP protocol[sic]

Sam has this to say about it;

I’m planning on depressing a lot of people there. ;-)

Au contraire, my friend. 8-)

Update; as pointed out by Robert I think I totally misinterpreted the presentation. I can see now that it’s about the practical problems with HTTP/XML development. You can probably guess what I thought the main point of the talk would be. 8-)

I met Paul in Honolulu at WWW2002 where he and his partner Chris Sukornyk were working on developing what turned out to be Semaview. Unfortunately things didn’t work out there, and Semaview recently ceased operations. But coincidentally, I happened to catch a pointer on the SWIG chump yesterday to an article written by Paul some time ago. It’s about Semantic Web Services, which immediately brought to mind an exchange we had a couple of years ago where I told him I thought it was great that he was planning to expose the functionality of their software, but suggested it be done over the Web rather than with Web services, which they did end up going with. Well lo-and-behold, but Paul has just resurfaced and written about his experience with Web services, and how he has now seen the value in the REST architectural style. He concludes;

Lesson learned. Keep it simple stupid.

Amen.

I’m going to be hitting some XML users group meetings in the North East US over the next couple of weeks, for my client Justsystem. If you’d like to meet with me to chat about XML, compound documents, or anything else Web-related for that matter, that’d be excellent.

My current schedule is;

• the Tri-XML meeting on Feb 8 in RTP
• the inaugural meeting of the Philadelphia XML Users Group on Feb 9
• the Washington Area SGML/XML Users Group meeting on Feb 16

I’ll keep my schedule up-to-date in this entry; there’s more to come.

Via Edd, a link to an interview with Stewart Butterfield. It’s a great interview all-round, but here’s a couple of points on topic for my weblog;

People who would be reluctant to provide metadata most of the time do so on Flickr because there’s a payoff for them. A) other people see their work–work is probably the wrong word because I don’t think most people see it as work in a serious artistic sense– but people see what they’re up to, see what they’re creating. And B) because they derive some pleasure from building value in the global collection.

I think this point is often missed by those who hold the “no cheap metadata” position. Turning “metadata” keywords into dereferencable URIs – as Flickr (among others) does – provides the means by which these “payoffs” that Stewart refers to, can be realized, cheaply. For me, it also helps drive home the point that one person’s metadata is another’s data, as this feedback loop is exactly the same one that exists when you publish any data behind a dereferencable URI. Taking it further, one might, for example, provide metadata for the Flickr metadata, which this is, if you squint a bit (not literally 8-). And to complete the loop and emphasize the point, one could easily republish many of these new images as new squared circles. Fractal!

As pointed out by Edd, Stewart also had this to say about Web services/REST;

I think we had one person inquire about using the SOAP version of the API. I don’t know if any apps were actually built. There is at least one application built on XML-RPC. But all the others–I don’t even know how many there are–are built on the REST API. It’s just so easy to develop that way; I think it’s foolish to do anything else.

Ah, gotta love permathreads. 8-)

Stefan did such a fine job with his response, that I think I’ll just “+1” it (yes, including the agreement with Chris, gasp! 8-) rather than respond myself. Thanks, buddy.

I also wanted to add, in response to Chris, that I only brought caching up as an example of something in HTTP that wouldn’t make sense to have if its application semantics didn’t include GET. I didn’t mean to imply that caching couldn’t be implemented without modifications to SOAP. I was actually specifically thinking about two changes to SOAP which would be required for a couple of important optimizations, both having to do with coarse grained messaging, as SOAP is intended to support. The first would be a framing optimization, the “jump” feature (akin to a chunked transfer encoding). The other would be a push away from strictly interpreted XML, since XML doesn’t support streaming due to the fact that an application can’t make much in the way of forward progress until the end of the message has arrived, lest the message end up malformed.

I also just noticed this MEST response from Steve where he realizes that MEST seems familiar;

The issue was that for at least some people, that paradigm shift had already happened and confusion arose when it was given an unfamiliar name.

Hmm, there’s seems to be a lot of that going on. 8-) It’s why I’ve claimed for about 5 years now, that the Web is what Web services is trying to be. It’s also why I argue that MEST is a specialization of REST. Or, in Steve’s words, that “every behavioral entity works by processing messages” is a special case of “every resource is a container for state”.

It goes live! It’s too bad it uses SOAP/WSDL rather than HTTP/XML or SOAP/HTTP, but hey, it’s some form of access to something that was previously unreachable (unlike their search APIs), so therefore a Good Thing.
(link) [del.icio.us/distobj]

With the publication of this trio of specs, I expect the WG is now finished. Phew!

Pay close attention to their work, in particular SOAP, MTOM, and XOP (RRSHB can safely be ignored). If anything remains of Web services in five years, this’ll be it.