Jan Algermissen wrote: > On 17.01.2007, at 23:08, Gregg Wonderly wrote: > > Mark Baker wrote: > >> 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. > > You shouldn't blame the architectural style for a bad implementation > of the HTTP connector.
I'm not "blaming the architectural style". I'm just stating that Marks statement is not correct from the "and used" perspective for anything except web browsers. In the SOA world, we have services talking to services and if the toolset are not supporting "persistent connections", then that's an issue that the tool vendors need to address and the users need to be aware of to demand that issue be dealt with for them. People writing applications using simple J2SE based tools are not, in general, going to be using persistent connections without doing the work themselves. The Java API, in particular, is more about URLs opening one-shot connections, because that API was created before HTTP supported persistent connections. >> REST can transport mobile code. It doesn't use it. That mobile >> code doesn't >> allow the transport layer or the interface to "change". > > Why would you want to change the transport layer? And sure, the > interface in a REST conforming system cannot change (must not > change). But mobile code affects an applications hypermedia engine, > so the effect is conceptually the same. I've probably enumerated countless cases of devices and systems which do not have HTTP on one end or the other. And, I've also talked a bit about how to exploit socket connections to provide a number of features that HTTP just doesn't allow for because of its strict conformance to a single paradigm, i.e. transfer. The overhead of HTTP is not a desirable feature for many applications. There are issues of bandwidth, application dependency on http behavior (DNS requried for load balancing or lost hosts using multiple A-records) and numerous other issues. I've yet to see the MODBUS over http protocol support that many embedded devices in existing systems around the world would need. Who would pay for the additional hardware at each site to upgrade or front each device with an HTTP server? What advantage would there be to running these existing services over HTTP, if TCP already transports the application protocol just fine? MODBUS is already a RESTful protocol. The interface never changes. It has a fixed set of operations (and vendor expansion where needed for hardware specific needs when a vendor doesn't understand how MODBUS works). > > 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" > > No, of course not....it would be against REST principles to have > conversations that don't use the uniform interface (HTTP in this case). Okay I'll state this again just to see if you're still not convinced. RMI/JERI is a uniform interface. There is exactly one operation, "INVOKE". That's all there is. The mapping of application operations on the parameters, to software system components is automatically done for you at software compile time, instead of being done by after market tools that might take an XML schema and create a Object mapping for you for example. In SOAP, the description of the invocation layer is done in the XML. In RMI/JERI it is done in Java, and the compiler provides all the information that the endpoint and invocation handler need to map language based operations onto operations related to the service endpoint. That's my argument about how HTTP is not really new in this regard. HTTP has more operations, because it wants to have a service layer that is not part of the users application. With RMI/JERI, that service layer is part of your application so that you don't have to buy something and install it separately from your service/client. You just run your software, and it already has all the features needed to be a "service". Gregg Wonderly
