Gregg,
some more comments:
On Apr 12, 2006, at 4:55 PM, Gregg Wonderly wrote:
>
> 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.
Do all these uses of GET match the defined sematics of GET[1]?
>
> It's a very fragile application because the client/server protocol
> is completely
> unspecified in structure.
You mean the messages, or? I mean, if you used HTTP (and not just (ab)
used it as a transport) the client/server protocol is well specified.
Only the messages can then be unspecified; for example if you put
semantics in the message beyond the actual mime type semantics (e.g.
exchanging structured data using text/plain).
> 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.
I guess you would be beter of if you had used POST and a standardized
(at least across your system) message type to send data to the server.
> Instead, it has created quite a mess, because it does not provide a
> type based
> mechanism to manage content correctness.
Now wait - HTTP does not provide the ability to type the content that
is exchanged between clients and servers? What else are MIME types
for then? Surely your PDF reader can verify if some message is indeed
application/pdf. Or am I missing your point?
>
> 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.
This sounds more like the trouble is the result of layering an
application protocol (your specific one) on top of another
application protocol (HTTP) instead of desiging your application to
properly use that application protocol in the first place (not to
suggest that I haven't made that mistake before also :-)
>
> So, if HTTP is adding value, I'm not seeing it.
If used properly, HTTP induces a certain set of properties into your
system. If you are interested in your system having these properties
then use HTTP.
It is all about enabeling independent evolution of your components.
It is about freeing service developers from coordinating their work
with client developers as long as both stick to standardized message
semantics (MIME types). Especially when client and server live in
different administrative- or trust domains I think it is of huge
value that service developers know they can do whatever they want as
long as they stick to the proper message semantics? What is that
value? Massively reduced coordination cost.
> 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?
Because
- you need an application protocol anyhow, so why not use HTTP
- HTTP is ubiqitous
- HTTP is a really save bet to invest in; it is standardized, has
proven to be sucessful and
the amount of deployment makes it very unlikely it is suddenly
going to change.
Jan
> Humm, I guess that's what the RMI programming model and JERI provide
> isn't it?
>
> Gregg Wonderly
>
>
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
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/
