- From: Mark Baker <distobj@acm.org>
- Date: Sun, 18 May 2003 22:22:12 -0400
- To: Jim Webber <jim.webber@arjuna.com>
- Cc: www-ws@w3.org
Relocated to www-ws@w3.org On Sun, May 18, 2003 at 11:24:45AM +0100, Jim Webber wrote: > Mark: > > > I like my lightbulb example. It's worked on two previous > > occasions to give folks epiphanies; > > > > GET on a URI returns "0" or "1" depending on the state of the > > bulb. PUT on that same URI with "0" turns the bulb off, "1" > > turns it on. > > This is a useful example, but I have to ask how I tell a lightbulb service > from something else. My slightly more verbose example uses XML; <lightbulb xmlns="some-uri"> <state>on</state> </lightbulb> So the ns URI would let you know it was a lightbulb, if you knew what "Lightbulb ML" was. There are other ways to find out that information too. > In the SOAP and WSDL view of the world, I can tell > where another service doesn't have the same interface as a lightbulb > service. Although I admit that I cannot understand how to use it without a > priori knowledge of its semantics (just like with the REST approach). Right, but note that HTTP semantics are more widely applicable due to their generality. Deploy them once, and they're good for everything you might encounter (hence "uniform"). The only remaining problem is one of understanding the data, i.e. that you either know, or don't know, what "Lightbulb ML" is; there's no middle ground. But there are well understood solutions to this problem (e.g. RDF or Topic Maps). > Again, I would still like to see the code for this. While the interface > level sounds slightly lighter weight (assuming HTTP where you would use 1 > GET and 1 POST versus my 2 POSTs), how does the implementation of this > service compare to the SOA version? How would it be maintained over time? For some sample code, see Telagent; http://dev.w3.org/cvsweb/2001/telagent/ The implementations are probably not all that different when it comes right down to nuts-and-bolts stuff of making the lighbulb go on and off, or dialing a phone. It's the network interface which differs, just as it is when you build a Web app to wrap an existing system; the existing system need not change. What kind of maintenance did you have in mind? MB -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Web architecture consulting, technical reports, evaluation & analysis Actively seeking contract work or employment
Received on Sunday, 18 May 2003 22:19:53 UTC