RE: [service-orientated-architecture] RESTful lightbulb

[Harm Smit]

Title: Message

Just returned from a trip and had to wade through a flood of messages sparked by my lightbulb example. Looks like Steve, Radovan and others have put forward most of the relevant arguments.   [Mark Baker] Sure, but your service oriented approach also has to define those things *and* the operations. That's extra agreement that my solution doesn't require, because my solution reuses existing pervasively understood operations. I'd call that simpler. My solution - defines a Lightbulb service with the operations 'TurnOn' (no parameters), 'TurnOff' (no parameters) and Dim (with parameter 'luminosity') - uses WSDL to formally define the service contract (service interface messages and associated data) - doesn't need to know about PUT (may not even use HTTP) - relies on asynchronous message exchanges and uses WS-Addressing to manage them   Your solution - defines a Lightbulb resource with state attributes 'state' (values 'on' and 'off') and 'luminosity' (with corresponding value) - has no formalized interface beyond GET, PUT, POST and DELETE, hence the use of hard-coded names and values of state attributes and the risk of inconsistency between client and server - has no standard provisions for asynchronous message exchange, hence relies on clumsy workarounds for achieving something remotely similar   It seems to me that your solution's apparent simplicity is just that: apparent. The "uniform interface" is the tip of the iceberg, the actual complexity is in handling the state representations -- some say "the data", but is it reasonable to handle all data as state representations?   Let me extend the example a bit by making the lightbulb more intelligent, in such a way that it can optimally adjust its luminosity (and maybe other characteristics such as its color) according to the profile of the person sitting at the desk that the bulb illuminates. (BTW, this is not an academic example). In the service-oriented approach, one would extend the lightbulb interface with a 'Personalize' operation to which a complex data type representing a person profile would be associated. When receiving a 'Personalize' message, the lightbulb would examine the profile, extract the relevant information and set its luminosity accordingly. How would you handle this RESTfully? One could add a MIME type 'profile' and send the lightbulb an HTTP/POST message containing something like 'personalize' together with the profile data. But that wouldn't seem very RESTful since the profile represents a person, not a lightbulb.   But whatever your solution, with both approaches the actual complexity resides in the processing of the profile. In comparison, whether you make the 'personalize' operation explicit or put it inside the message in the form of a state attribute seems a fairly minor aspect to me. Harm.       -----Original Message----- From: service-orientated-architecture@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mark Baker Sent: dimanche 2 juillet 2006 16:09 To: service-orientated-architecture@yahoogroups.com Subject: [service-orientated-architecture] RESTful lightbulb > To Mark: > > The REST approach you're proposing is simple, but no simpler than a service-based one. > In your solution, you still have to formally define 'lightbulb' and 'state', as well as something like 'luminosity', so that there is a common understanding on both sides of the wire. Sure, but your service oriented approach also has to define those things *and* the operations. That's extra agreement that my solution doesn't require, because my solution reuses existing pervasively understood operations. I'd call that simpler. > IOW, you need to define the contract. If you don't, the two approaches aren't comparable. If you do, they are more or less equivalent. > BTW, in your setup, how would you make the interactions asynchronous? The bulb could return a 202 to indicate that it will process the request some time in the future. Or the client could just fire-and-forget the request, and then reuse the fact that PUT is idempotent to resend, say, every few minutes to ensure it stays on or off. Or an intermediary - proxy or surrogate - could handle the request and retries in the case of failure or delay. All of those are asynch options. Mark. ,_.___   . __._,_.___ YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. __,_._,___