On 02/07/06, Jan Algermissen <[EMAIL PROTECTED]> wrote: > > > > > > > > > > On Jul 2, 2006, at 10:58 AM, Harm Smit wrote: > > > > BTW, in your setup, how would you make the interactions asynchronous? > > > 1) Async+Poll:
Ahhh polling, the old running a watcher thread in the consumer, which of courses more complexity on the caller. > > ---> > PUT /bulbs/1 > > [state data] > > <--- > 202 Acepted > Location: /bulbs/1 > > ...poll /bulbs/1 with GET until you see that state has changed... Where as this bit places more demands on the server. > > 2) Asynch+Notification > > PUT /bulbs/1 > > [state data] > > <--- > 202 Acepted > Location: /bulbs/1 > > ---> > WATCH /bulbs/1 > Reply-To: mailto:[EMAIL PROTECTED] > > ...wait for mail to arrive.... > > (WATCH is non standard HTTP; this is no problem if you control the > whole system (e.g. inside an intranet)) But doesn't this break the whole principle that HTTP is all you need? I'd have expected something like PUT <watch query="lightbulb/state" respond="http://me.com/listener> Which would make a call to my server via a PUT statement with the current state. Either way leaves the big question of whom is calling me when I receive the event. > > Presumably, Polling with HEAD doesn't even have the overhead to > justify the complexity of the notification based > solution (the server maintaining the subscribers, the watcher > maintaining a server to manage the Reply-To URI.) But the polling approach has the main overhead on the consumer, assuming that the number of consumers > number of publishers then polling is going to be a poor solution. > > And, BTW, the architectural style of a system does indeed make a > difference regarding the assumptions one can make about certain of > its properties such as performance!, maintainability or evolvability!! I don't disagree, paticularly about the last two. Personally I'm still struggling to see REST as anything beyond yet another A->B comms implementation. > > Tell me, can the client component cache the return value of > srv.GetBulbState()? Are you sure you can re-do the srvSetBulbState() > function as often as you like? There really isn't any difference in either model in terms of re-entrance and data latency, neither REST nor SOAP/WSDL address either of those two problems. For instance, lets assume that you are using REST to write to compact flash and you call it 1 billion times, after a certain point it ceases to be re-entrant as the compact flash can no-longer accept updates. > > Both of these for example come for free with HTTP - zero design- and > zero implementation cost! No they don't, see above. HTTP specifies nothing about data latency or re-entrance, that is purely a systems design element. Unless you are claiming that by using HTTP you can just keep calling back to the server.. which means you fall into the trap of the trap of the eight fallacies of network computing http://www.java.net/jag/Fallacies.html > > Jan > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
