Mark Baker wrote:
> On 1/17/07, Gregg Wonderly <[EMAIL PROTECTED] <mailto:gergg%40cox.net>> wrote:
> > I think it should be fairly obvious that "slow" on a network is almost
> always
> > related to "latency" of transfer/transport between systems. There are a
> couple
> > of issues to consider, for me. One is connection setup time for a
> > transfer/transport operation. Many HTTP based systems will experience this
> > latency on every remote operation unless some very specific features of
> HTTP are
> > configured/available.
>
> That's no longer the case; persistent connections are pervasively
> supported and used and have been for many years.
The last time that I monitored the exchange of a web document retrieved from
java code invoking;
URL url = ...
InputStream data = url.openStream();
There was no use of persistent connections. An application would have to
perform some very specific actions, as I said to make this work. It doesn't
happen out of the box from a clients perspective as it will with JERI after the
server is deployed with such a configuration.
> > The other is what coding/decoding is needed which
> > represents overhead in the exchange between remote systems.
>
> That's an issue too, yes.
>
> In general, I think the issues described in RFC 817, and the
> meta-issue of layering, is as much to blame as anything... though of
> course, for any particular protocol, the relative importance of the
> issues will vary.
>
> http://www.ietf.org/rfc/rfc817.txt <http://www.ietf.org/rfc/rfc817.txt>
If an application simply opens a socket and transports data, then it is
ultimately responsible for latency, and the ideas and concepts outlined in 817
are certainly important issues.
If an application is written using a toolkit or platform or standard which
doesn't provide a level of control that allows the developer/architect to deal
with performance at the appropriate level, then that is where the problem lies.
> > WS, REST and IIOP, because they lack mobile code
>
> FYI, REST includes a mobile code constraint;
>
> http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_7
> <http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm#sec_5_1_7>
REST can transport mobile code. It doesn't use it. That mobile code doesn't
allow the transport layer or the interface to "change". One might use
REST/HTTP
to load a webpage with an applet or javascript which uses NO HTTP to talk to
the
server. But, I don't consider that a "feature of REST" as much as a "feature
of
Java" or a "feature of javascript" (the feature is the ability to vary
transport/transfer techonology based on need).
Gregg Wonderly
