Jan Algermissen wrote:
> In RMI, I belive the client has very detailed expectations beyond
> 'invoke' and it would lead to
> many surprises if INVOKE( foo.getStockQuote) launches a missile, or?
> In fact, when you POST your order to e.g. Amazon, it would be perfectly
> fine (from an HTTP POV)
> for the server to launch that missile.
The HTTP operations, GET, PUT and DELETE do have more exact descriptions than
POST. This is just an simplification of the interface that an HTTP client would
deal with. It indicates a more focused application group that HTTP can be used
from. POST represents the generic "punt" that creeps into software when
developers decide that they can't provide some needed functionality in an
existing implementation. It's a very pervasive thing.
The RMI INVOKE operation, as I said, is what allows the Java programmer to
access remote objects with the same programming paradigms as they do local
I'm not sure that the 'launch a missle' example really applies here. Unless you
wrote the software on the other end, you don't really know what happened. Even
with GET, PUT and DELETE there's no guarantee about anything, we just have, as
the greater software development society, largely been truthful, trustworthy and
faithful, recognizing the benefits of that premise.
> That is (and this is how this thread started, BTW) why it is so
> important that what the client says
> is self describing. - It keeps you from being responsible for that launch.
The Java progamming language provides as much self description in the
specification of an API design as any other textual representation of similar
information. Developers describe their intent with software in whatever
language they use. Currently, we don't have a silver bullet language that can
provide any real guarantees about what happens remotely.
However, the JERI stack, does include the ability for the client to assert
contstraints that the server must meet. Those constraints are validated by the
ProxyPreparer. The ProxyPreparer can be told to perform proxy verification.
The existing implementation of this knows how to validate that the proxy
verification is happening with the appointed classes from the desired class
loader. Once the validation occurs, then the client can assume that the proxy
preparation included validation of the specified constraints which includes
thigns like server authentication (Kerberos or X.500 types of things), proper
integrity of the downloaded classes (httpmd: protocol handler), proper integrity
of the data path (SSL vs TCP endpoint) etc.
HTTP and web clients don't really allow users to specify this kind of fine
grained control in the typical installation. Instead, we rely on the browser to
tell us when a form is being submitted on a non-https connection etc.
I think that there's a much bigger picture than just the HTTP protocol.