RE: [service-orientated-architecture] Zapthink on SOA/REST

[Harm Smit]

Title: Message

So be it :-) To avoid any misunderstanding, though, let me recall what I mean by 'lightbulb10.TurnOn()'. This statement simply means that a SOAP message comprising a parameterless operation 'turnOn' is sent to lightbulb10. Why? Because that's how I defined the lightbulb scenario two weeks ago:   <quote> My proposed simple example is a service-oriented lightbulb. It exposes an interface comprising the (self-explanatory) operations 'TurnOn', 'TurnOff' and 'Dim'. (This supposes the lightbulb has some intelligence built in, which may seem absurd, but isn't.)   Using WS-*, one would define a WSDL with a single portType comprising the above three operations.   The interaction pattern may be either request-response or one-way, depending on whether or not the service consumers are supposed to be informed of the results of the requested operation.   Note that the operations are *not* meant to be remote procedure calls: a 'TurnOn' request is an asynchronous SOAP message and so is the corresponding response, if any. WS-Addressing is used to correlate the response with the request. Depending on the environment, various protocols can be used to transport these messages, including TCP and UDP. Note further that the operations are supposed to be stateless. <quote/>   I suspect that some people are uncomfortable with the idea of a smart lightbulb. They could take the example of a networked printer that exposes a service with operations 'SubmitPrintJob' and 'CancelPrintJob'. I didn't take this example because I would have had to factor in the print job itself (communicated as an MTOM attachment to the 'SubmitPrintJob' message), so it's slightly more complicated than the lightbulb, but totally equivalent in nature. The printer example would have had the advantage, however, of showing the necessity of an asynchronous event notification mechanism for signaling the end of a print job, for which the REST approach has no solution other than clumsy, non-standard polling mechanisms.   We call this "SOA for devices". The prevailing specification in this space is the Devices Profile for Web Services (DPWS), which includes WS-Discovery for dynamic device discovery and WS-Eventing for pub/sub event notification. DPWS is supported by Windows Vista, of which it will become the preferred method for interfacing network-connected devices. DPWS will enable some interesting scenarios for integrating device-provided services with higher-level business applications.   Harm.       -----Original Message----- From: service-orientated-architecture@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Tilkov Sent: vendredi 14 juillet 2006 14:18 To: service-orientated-architecture@yahoogroups.com Subject: Re: [service-orientated-architecture] Zapthink on SOA/REST On Jul 14, 2006, at 9:52 AM, Harm Smit wrote: > The latter is rubbish. It should read: lightbulb10.turnOn() > Each lightbulb is an independent, autonomous service provider. That's the first time I've seen someone make that claim for SOA-style services. Stefan -- Stefan Tilkov, http://www.innoq.com/blog/st/ __._,_.___ 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. __,_._,___