Re: [service-orientated-architecture] RESTful lightbulb

[Peter Madziak]

>>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="">) 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 ).

 

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 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.

---

__,_._,___