Jan Algermissen wrote:
> On Apr 13, 2006, at 6:19 AM, Gregg Wonderly wrote:
> > Jan Algermissen wrote:
> >> 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.
>
> What features do you have in mind that are not always available?
HTTP 1.1 features are not available in an HTTP 1.0 server for example. So, any
client application needing 1.1 features, has to deal with this basic issue.
What kind of server am I talking to?
> > 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.
>
> Such as (see above)?
When I send my "GET /", what kind of server am I talking to? How do I know
what
type of GET command to send it? How do I know what response to expect? I have
to expect any all all possibilities, or I have to reduce my expectations from
the server so that I only have to deal with 1.0 for example.
> > Thus the binding of the protocol into the application which I find
> > unacceptable
> > as a general SOA practice.
>
> But it is an illusion that you can have delivery semantics without an
> application protocol (see Mark's reply). So why not use an existing,
> well deployed one instead of rolling yet another one and (ab)using
> the existing application protocols as transport?
The limited "application protocol" that http supports is not sufficent to allow
me to talk to a device that speaks MODBUS, without a "proxy" service in the
HTTP
server for example. How is http anything more than a "transport" in that realm?
I can generalize RMI based programming to be document oriented, MODBUS oriented
or some other protocol because there is no expected structure to the
application
protocol which would confine my opportunities. If I choose HTTP as the only
'network' protocol, then I am limited to what it can do as an application and
interface, and ALL of my clients are now HTTP centric, instead of protocol
agnostic.
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/
