On Friday, January 19, 2007, at 05:26PM, "Gregg Wonderly" <[EMAIL PROTECTED]> wrote: >Jan Algermissen wrote: >> On Friday, January 19, 2007, at 09:04AM, "Gregg Wonderly" <[EMAIL PROTECTED] >> <mailto:gergg%40cox.net>> wrote: >> >Jan Algermissen wrote: >> >> The difference is that HTTP is an application interface. It is the >> >> interface of the user's application. >> > >> >RMI/JERI is an application interface. The application uses this paradigm >> for >> >remote data transfer via the parameters of the "invoke" operation. >> >> So you'd never put another layer of semantics on top of that then? What >> does invoke mean? > >I'm not sure what your looking for here. HTTP POST and RMI/JERI INVOKE have >the >exact same capabilities. You can send some content, it is acted on by the >application on the other end, and you get something back. The semantics on >top >of either of those operations are defined by the actions of the service that >the >content is processed by.
The key question is whether these additional semantics are visible to/understood by the client. In the case of REST they are not - the client only knows about the 'process this' semantics, no more. Are you saying that a client that calls INVOKE does not need to know anything beyond INVOKE? It need not specify the operation to invoke?? Jan > >With HTTP POST, I could transfer the same data as RMI/JERI INVOKE. The >additional operations of HTTP are just extensions of this. Sure there is a >specification that says GET can only GET and HEAD only returns the header and >DELETE deletes data etc. But, that description is just a mapping onto a >server >based API such as that a Java Servlet can use. It's a convenience that >provides >a layer of API which can be useful. > >The Java Servlet interface definition shows that there is a mapping of the >HTTP >protocol onto a language API (and the same thing exists in other languages). >So >while you consider it an application interface, I consider it an invocation >layer which has specific semantics limiting its use to the programming model >that is outlined in the HTTP/REST specs. Nothing more. There is no specific >action that the HTTP protocol performs without an application receiving the >invocations on the associated resources. > >> >> When you buy a book at Amazon, the application interface you are using >> >> is HTTP. >> > >> >The application's interface is exported as an HTTP endpoint. >> >> No, HTTP is the application interface semantics. There is no application >> that is mapped or whatever to HTTP (set aside any backend stuff of course). >> >> Is this really impossible to get across? > >If I have a library of software which communicates with devices over the >internet using the MODBUS protocol, and I want to provide a web page which >allows you to enter some numbers into a form, and then submit that data to the >remote device, I can export such a capability with a Java Servlet that would >provide an HTTP endpoint for this library. If in the initialization of the >servlet I also exported a JERI SSL endpoint with a standard JERI invocation >layer factory and registered that with a ServiceRegistrar instance, I will >have >provided two different ways to access the same code. > >"The application's interface is exported as an HTTP endpoint." and a JERI >endpoint. > >Gregg Wonderly > > > >Yahoo! Groups Links > > > > >
