> The issue is whether you are using HTTP because:
>
> 1. It is a type of interface you support.
> 2. You are using HTTP features to simplify your software coding.
> 3. You are using HTTP because it's what you know.
>
> 1) is where you should be. 2) starts to provide unnecessary
> coupling. 3) is the point where software architects get mad, and
> other developers call you names.
I agree with this generally, although I may not agree (2) is as far
down the slippery slope as you do.
> The issue with REST is that it considers HTTP as the invocation
layer too, with
> the PUT, GET, POST, etc operations as the fixed set of "functions"
that you can
> invoke. In a more sophisticated invocation layer, you can imagine
the use of
> multiple wire protocols such as HTTP being used to perform a single
server side
> operation.
I agree that more sophisticated models than HTTP can be imagined. I
suspect HTTP has a lot of mileage in it though. What is often left out
of these discussions is the big picture of the architecture. What I
have learned from others over the last year or so, and come to
appreciate quite a bit, is that HTTP is not just about the verbs on
the wire.
One thing that HTTP offers an SOA is a simple model for collaborating
around documents. You don't just design a general RPC, or
fire-and-forget, or pub/sub message passing model with HTTP. These
models are useful and can be modeled in HTTP various ways, some better
than others. But with HTTP you begin by modeling the documents, how
they are represented, and how you intend collaboration to take place
via these documents. Some are long-lived, some are short-lived, and
the goal is to find the right documents and the right collaboration
patterns around those documents using that small number of verbs and
the constraints those verbs present.
That can be very liberating relative to a wide-open SOA where almost
anything goes. Hopefully no one using SOAP, WS-*, etc. would allow
each developer to have it completely their way, capriciously. And
maybe that is an advantage of the SOAP, WS-* approach: there are few
constraints, but you can impose any constraints you find useful.
HTTP tries to impose a small set of constraints that seem useful.
> People still think that it's necessary to bring APIs such as JMS or
> SOAP right up to the door step when they really should be left out
> in the street where all the traffic flows are better managed.
At least JMS imposes a set of constraints that may have
benefits. Using SOAP or RMI or JERI, etc. these are just interface
definition approaches. I think a long-lived, distributed system would
still benefit from adopting certain constraints above those
approaches.
-Patrick
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
