RE: [service-orientated-architecture] Re: SOA Reference Architecture

[Harm Smit]

Title: Message

To Anne:   You're missing the point or, at least, you're changing the problem. It's as if I was talking about stamps and you respond in terms of post offices. My focus is on a device (lightbulb) that acts as an individual, autonomous service provider. Of course, once you have that elementary service, you may use it to create higher-level services, such as querying a set of lightbulbs. You may even use orchestration or choreography mechanisms combining the services of a set of lightbulbs, such as for animating a Christmas tree or theater spotlights. IOW, using your terminology, in my example the center of the design is the capability of an individual lightbulb. This capability is exposed through three operations: turning it on, turning it off, dimming it. I don't see how this misses the mark on SOA.   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. 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?   Harm.       -----Original Message----- From: service-orientated-architecture@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Anne Thomas Manes Sent: samedi 1 juillet 2006 16:05 To: service-orientated-architecture@yahoogroups.com Subject: Re: [service-orientated-architecture] Re: SOA Reference Architecture Spot on, Mark. Harm's example not only missed the mark on REST, it also missed the mark on SOA. In REST, the center of the design is the resource (the lightbulb). As you've described below, each lightbulb has a unique URL, you retrieve its state via GET, and you set its state via PUT. You might use POST to add additional state, such as its location and its wattage. In SOA, the center of the design should be the capability (managing lightbulbs). A service exposes that capability through a set of operations: - locateLightbulbs   - input (query parameters)   - output (array of lightbulb identifiers that match the query parameters) - queryLightbulbs   - input (array of lightbulb idenitifers)   - output (array of lightbulb states) - setLightbulbs   - input (array of lightbulb identifiers and state settings)   - output (void or confirmation/fault) One major distinction, here, is that you can manage multiple lightbulbs through this one service. The service has a unique URL. You identify the lightbulb(s) that you want to query or set as part of the content of the message. If you want to make it a RESTful service (e.g., apply the REST implementation pattern to this service), then the lightbulb identifier should be a URL, and once you have located a service, you should be able to GET and SET the lightbulb state using GET and PUT in addition to using the service API. Anne On 6/30/06, Mark Baker <[EMAIL PROTECTED]> wrote: Lightbulbs! My favourite REST example. See for yourself; http://www.markbaker.ca/2002/08/Rest/ > Using the REST approach, following your scheme one would define the resources: > http://example.lightbulb.net/TurnOn > http://example.lightbulb.net/TurnOff > http://example.lightbulb.net/Dim > > and the light would be turned on, turned off and dimmed by HTTP/POSTing a message to each of the respective resources. > > An alternative scheme would be to have just one resource: > http://example.lightbulb.net > and include the name of the operation in the POSTed messages. > > Or one could HTTP/GET "queries" like http://example.lightbulb.net/TurnOn and http://example.lightbulb.net/Dim?Luminosity=.75. None of those are RESTful. AFAIK, REST suggests just one solution for that problem. A single identifier for the lightbulb; http://example.net/lightbulb1234 and the use of PUT to turn the bulb on and off, ala; PUT http://example.org/lightbulb1234 Content-Type: application/lightbulb+xml <lightbulb state="on"/> Simple, no? Mark. __._,_.___ SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture 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. __,_._,___