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

[Anne Thomas Manes]

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

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

---

__,_._,___