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

Fri, 30 Jun 2006 13:34:01 -0700

Title: Message
Anne,
 
When your message came in, I was in the middle of presenting a simple example to get exactly to the same point. I'm reformulating it here in reference to yours.
 
My proposed simple example is a service-oriented lightbulb (to shed some more light :-)
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.
So, Function1 = TurnOn, Function2 = TurnOff, Function3 = Dim (one more than in your example).
Function1in = void, Function2in = void, Function3in = Luminosity.
 
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. If not, there are no outputs Function1out, Function2out and Function3out. If yes, all three are a result value.
In addition, the portType could define a Fault message, but let's keep it as simple as possible.
 
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.
 
Using the REST approach, following your scheme one would define the resources:
 
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:
and include the name of the operation in the POSTed messages.
 
 
But how would one go about to make request and response messages asynchronous?
 
In any case, the fact of having the lightbulb expose a "uniform interface" (GET, POST) doesn't make my client application any simpler. This application is only interested in using the functional interface of the lightbulb service: turning it on, turning it off, dimming it -- these are the taks of the lightbulb's "business process". As seen from the application, whether these tasks are invoked through SOAP messages or through HTTP/POST messages is more of a plumbing issue than anything else.
 
Note that, for the sake of this discussion, my example is deliberately simplistic, but it could easily be made more complex.
 
As a side remark, let me mention a few practical issues.
 
1. The application doesn't know beforehand the identity of the lightbulb it's going to control and maybe it needs to control several lightbulbs, e.g. all those found on the network within a certain scope or of a given type. This is why WS-Discovery is needed -- with or without authentication and authorization (WS-Security).
 
2. Maybe the lightbulb is controlled by a given application while some other application needs to be informed whenever the lightbulb's state changes. WS-Eventing serves such purposes (again, with or without WS-Security). In addition, if these event notifications are vital, WS-ReliableMessaging may be used to ensure event delivery.
 
This shows how the WS-* mechanisms can be composed in various ways according to the application requirements, while using a common protocol substrate and independently of implementation platforms.
 
Harm.
 
 
 
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Anne Thomas Manes
Sent: vendredi 30 juin 2006 02:34
To: [email protected]
Subject: Re: [service-orientated-architecture] Re: SOA Reference Architecture

Perhaps this example might help shead some light.

Let's say you have a service that performs two different functions.

In order to accomplish Function 1, the service requires certain input information (Function1in) and it returns certain output information (Function1out). Likewise, in order to accomplish Function 2, the service requires certain input information (Function2in) and it returns certain output information (Function2out).

When using SOAP, your would define a single interface (portType) with two operations:
- Function1
  - input Funtion1in
  - output Function1out
- Function2
  - input Funtion2in
  - output Function2out

When using REST, you would define two resources:
- http://some-uri/Function1
- http://some-uri/Function2

If you POST Function1in to http://some-uri/Function1, you will receive Function1out in response. You could also potentially encode the information from Function1in into a query appended to the resource URL, e.g, http://some-uri/Function1?foo=abc and use GET rather than POST.

The advantage of using REST is that you can directly reference the resource URI, and (as long as the resource is idempotent) you can cache Function1out for later retrieval. The challenge I see with REST is figuring out what the format of Function1in should be -- or even worse, what the format of the query string appended to the URL should be.

But otherwise, they are semantically equivalent. Either interface can be used to access the service.

So explain to me again why REST is such a paradigm shift?

As Steve says, this argument is really pretty pointless.

Anne

On 6/29/06, patrickdlogan <[EMAIL PROTECTED]> wrote:

> [SJ] An interface defines the FUNCTION as well as the data. Data
> exchange is only one small part of a service definition. Some
> functions never exchange any data for instance. I might be very
> thick, but when I define a service interface I think in terms of the
> capabilities that it provides, these don't often get reduced to just
> resources and data.

In SOAP/WSDL you have the mechanisms to define the interface to any
functions you desire. Your architecture can be a hodge-podge.

In HTTP you *should* use the pre-defined methods to transfer data here
and there. Your architecture can be a hodge-podge, but at least not
because you have a zillion and two interfaces.

Think of the HTTP "functions" along the same lines as the
Linda/Javaspaces "functions". There are just a very small number of
them, and all they do is move things from here to there in a small
number of ways. With these two architectures, you have to understand
the best ways to use them.

With SOAP/WSDL, you have to understand how to define an interface. But
then you also have to understand what your architectural choices are,
and how to implement that. HTTP takes a good bit of that burden off of
you.


> [SJ] But is REST that much better than WSDL? I'm not seeing it

SOAP/WSDL is not an architecture. It is an interface definition
language with which you can define all kinds of architectures. Just
choosing WSDL doesn't solve the architecture question.

REST is an architecture "pattern" if you will. HTTP is an incarnation
of REST. I don't see any way to compare HTTP and SOAP/WSDL. I think
you have to compare HTTP in whole or in part to some other
architecture that you may base in whole or in part on SOAP/WSDL. What
is that other architecture for you?

-Patrick


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to