On 11/07/06, Peter Madziak <[EMAIL PROTECTED]> wrote: > > > > > > > > > > >>Nope, that is the INVOCATION mechanism > > No. If you think this then I feel that you missed the key concepts of REST. > REST is an architectural style focused on the "transfer of state" and NOT the > invocation of operations (and it also presents a uniform interface > (GET,PUT,POST,DELETE) for transferring that state). To think REST you have > forget about invoking operations on a "business service" and focus soley on > transferring state between consumers and providers. > > I am not sure if this is related or not, but I find that people have no > trouble with REST when they are talking about "services" providing access to > "nouns", i.e. what people like Pat Helland call resource-oriented services > (or Erl's entity-centric services) but do have trouble when they try to > translate that to "verbs", or what others call activity-oriented (or > task-centric for Erl) services. > > Consider this paper by James Snell > http://www-128.ibm.com/developerworks/webservices/library/ws-restvsoap/ in > which he puts forth the claim that REST aligns well with resource-oriented > services and WS-* aligns well with activity-oriented services. What Snell > missess, IMO, is that REST can align perfectly well with activity-oriented > services, it's just that when it does, the resources become more verb or > action based. For instance, in a RESTful "car repair service" scenario, the > consumer might be PUTing/POSTing resources like "AutomotiveServiceRequest, or > some such action-focused beast. > > Having said that, when attempting to align your architecture with the > business, do you want to be talking about state transfer? Definitely not; and > on this front I must admit that I quite like Microsoft's Motion ( > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/MotionLite.asp) > approach where they focus on talking soley about capabilities and > connections between capabilites. This model can be translated equally well > into both WS-* and REST worlds. And yes I know they are not the only ones > talking this way ( e.g. see also > http://www.amazon.ca/exec/obidos/ASIN/0321205766/qid=1152632342/sr=1-1/ref=sr_1_0_1/702-6428237-7324800 > ). >
Which is my point.... when you deal at this level the actual execution context doesn't matter a jot. The capabilities are constant, the connections are constant and the technology doesn't matter a damn. I'm not arguing that REST is rubbish, just that its ONE implementation choice and that the producers and consumers couldn't care less about what you choose, as long as you pick one, define things in a consistent way, publish them in a consistent way, and make it simple for them to be consumed and invoked. When you think of applications and enterprises at the Motion level (which is IMO where SOA should be) then arguing about the execution context (where SOAP v REST lives) is pointless. I think I'll stop now. > Peter > > > > On 7/11/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > On 10/07/06, Mark Baker <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 7/10/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > That's difficult to quantify, of course. It depends a lot on the data > > > > > itself. As a low watermark though, we know; > > > > > > > > > > work(Web services) = work( solving interface problem) + work ( solving > > > > > data problem ) > > > > > work(Web) = work( solving data problem ) > > > > > > > > Do we? I certainly don't. You still have to define the operational > > > > interface, even though it is a document post rather than a defined > > > > interface document. If you don't define the operations available to > > > > consumers then THEY WON'T KNOW ABOUT THEM. > > > > > > > > > Steve - it is *axiomatic* in REST that all services expose the same > > > "operational interface", so yes, we do know that. > > > > > > http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_5 > > > > > > > Nope, that is the INVOCATION mechanism (the execution context to use > > the SOA RM term), that isn't the operational interface that consumers > > use. > > > > With our lightbulb we have > > 1) The URI > > 2) The data format of the request/response > > 3) The meaning of that request/response > > > > "PUT" is not an operational interface for a service consumer, it is > > the execution context that enables the consumer to be connected with > > the producer. > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
