Jan Algermissen wrote:
> Gregg,
>
> On Apr 12, 2006, at 4:55 PM, Gregg Wonderly wrote:
>
> > 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.
>
> Hmm....but HTTP *is* an application protocol.
>
> IOW, HTTP is not about getting data across a network, it is about
> invoking methods with explicit *application semantics* on objects[1].
>
> Do you disagree?
I believe that this starts to speak to our differing opinions. HTTP has a lot
of different features that are not always used, and not always available.
Because of this, the application has to take all of these things into account,
and handle them correctly. Thus, I don't consider those things to be part of
"the protocol" that is "usable" for ALL applications. Instead, they are things
that every single application that uses HTTP has to deal with.
Thus the binding of the protocol into the application which I find unacceptable
as a general SOA practice. I have used HTTP for simple and complex dedicated
applications because the data I needed was only available via HTTP. But from a
practicle SOA architecture perspective, HTTP would not be a "specified" part of
the "architecture" of my SOA for anything other than web pages delivered to
users, and I would not include forms or AJAX because of the dependency on
browsers doing the right thing.
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/
