Jan Algermissen wrote:
> Gregg,
>
> On Apr 10, 2006, at 11:44 PM, Gregg Wonderly wrote:
>
> > Mark Baker wrote:
> >> On 4/7/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> >>> I did say that HTTP was really immaterial. Other protocols can
> >>> provide the same
> >>> semantic features as HTTP.
> >>
> >> Such as?
> >>
>
> I still wonder....what are the protocols "that privide the same
> semantic features as HTTP"?
Let's first agree on the semantics of HTTP that I am considering. The only
things that I depend on HTTP for are:
1. a document namespace
2. TCP based socket controls
3. simple credential based security
The POST vs GET differences are somewhat interesting from finding an "existing"
protocol. As Mark said, FTP doesn't have a direct match for POST. My argument
about HTTP being immaterial is really stacked in the direction of basic
transport interfaces. If we go on about the GET vs POST issues and some of the
semantics of the HEADER fields (redirection responses) etc, I consider this to
be more about application supported features than about typical "protocol"
supported feature.
Because I try very hard to focus on protocol independence, I'm reluctant to
wire
dependencies of particular protocol features into an application, unless that's
all that works. I'll tell a story about why.
We have an old servlet based application that we originally deployed using the
Sun Java Webserver in 1998 or so. One of our clients uses the servlet via an
applet (when away from the office) and from my Jini Desktop interface, when
local. Its the same UI just instantiated in a different container. This
"application" uses HTTP GET based access to the servlet for all data exchanges.
It uses properties based documents (we did this before XML existed or Jini
was
"available") to transfer values to the client, and huge, long GET URLs for
sending requests from the client to the server.
It's a very fragile application because the client/server protocol is
completely
unspecified in structure. The property value names have to be typed correctly
into the source code. You have to be sure to send all the right values in the
GET URL, or the server will be missing information. Using HTTP here has not
added any value into the integrity or maintainability of the application.
Instead, it has created quite a mess, because it does not provide a type based
mechanism to manage content correctness.
One has to add such things into the transport/invocation layer. I'd have to
create a very large amount of specification and a layer of abstraction to
remove
the HTTP dependency from the application. It would be faster for me to convert
it to use an RMI programming model. Then, I'd have complete compile time type
verification.
At some point, I will in fact do this. We haven't had to make too many changes
to this application over the years, but everytime we do, it's a royal pain to
get the client/server exchange right. Many, many more details to manage
because
the application has the protocol imbedded in it.
So, if HTTP is adding value, I'm not seeing it. It's only the tools and layers
of abstraction on top of HTTP that would provide any additional value, and then
you're not using HTTP as anything more than a transport, so why not just use
TCP
sockets in a layer of abstraction that would allow you to plug in something
else
if needed? Humm, I guess that's what the RMI programming model and JERI
provide
isn't it?
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/
