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?
>
> FTP's probably the most similar protocol we have to HTTP, but it's
> missing the semantic equivalent of POST. IMAP too. NNTP has POST,
> but no equivalent of PUT.
>
> HTTP is special amoungst application protocols because it's the only
> one that knows URIs.
These are all inter-dependencies. You are taking advantage of URIs as a
namespace by using HTTP. Because you've got HTTP everywhere you're dependent
on
having URIs.
Mark, I know that most all of your argument and emphasis is based on the fact
that HTTP exists as a spec, HTTP servers exist as a platform, and URI handling
is available on most software development platforms. That is all true and
beneficial. With HTTP the "transport" and the "content", were tied together
because of the influence of other protocols, such as gopher, with a document
focus. So, now we have the view that large scale transfers are "better" than
small scale exchanges, because it is easier to get a document with HTTP than do
do many other things that have been used in the passed for client server
computing. The problem is that large scale exchanges expose large scale
implementation details when sometimes those dependencies (document
content/structure) should not be revealed, or used for many different reasons.
But, that's a whole other argument.
I'm specifically focused on the issue of worrying about the "specific" protocol
as the premise for your software design, instead of the "semantics" of delivery
of data in both directions. HTTP should be used as an enabler not as a
premise.
Because there is data available via HTTP, and there are very useful sources
at
that, many people write software hardwired to HTTP and the content delivered,
and then are frustrated when the document changes, the URI changes, or
something
else hardwired, and unspecified in the "contract" changes.
By going through rigorous software design, and abstracting the protocol and
invocation layer away from the software system being designed, you force
yourself to confront all of the dependencies on the semantics and either
provide
an abstraction or an argument against/for the dependency on the implementation
details.
But, perhaps the throw away code crowd has a little more ability to accept the
fragile nature of this than I do.
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/
