Logan, Patrick D wrote:
> > A protocol influencing an architecture is a specific example of
> > tight-coupling. That means that any change to protocol requires
> > change to architecture. Hoo-boy, that's badness.
>
> That's arguable. A protocol like HTTP has been around the globe a
> while. One can assume fairly safely it will not change in a backward
> incompatible way. An architecture that takes advantage of the HTTP
> definition then might be a fairly stable one.
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.
What is at issue is that typically, a software platform/language does not have
a
reasonable level of abstraction and SPI style APIs that provide you the ability
to not have coupling to the transport or invocation semantics or messaging
layer.
In the Java world, the RMI interface was the first attempt to create an RPC
abstraction. It works for Java to Java and CORBA IIOP. The people that
created
RMI came back with version 2 in the form of the Jini Extensible Remote
Invocation stack. They did attempt to pitch as 2 JSRs, but the CORBA and app
server folks still didn't understand the issues. With JERI, the abstraction
layer is RPC using RMI semantics. You can plug in an invocation layer that
translates that to SOAP, or something else. You can plug in an endpoint
implementation that connects using a wide range of wire protocols, including
HTTP.
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.
It is the specific ability of the API to handle multiple implementations of the
semantics of the API that provide the level of decoupling that helps make it
more likely that you can plug in a new protocol. The conversion of the data
from one format to another by the invocation layer is a good thing.
The issue I have with SOAP use is that the typical SOAP based application is
dealing with XML in the programming environment directly, so if you want to
plug
in a native interface to the same programming language on the other end, and
the
language platform supports over the wire serialization/marshalling, you suffer
from the overhead of multiple conversions when you really could just pass it
natively.
If you are doing Java, you should be using just RMI based API interfaces to
everything, and making using use of JERIs pluggable stack to give you the SOAP
or other WS-* support you need to talk to non-Java clients/servers on the other
side. 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.
Gregg Wonderly
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/
