On 3 Mar 2008, at 17:26, Scott Ferguson wrote:
I was just thinking about a variant which uses the current
transmission scope as it is now, but instead of sending the type
information, you send a small hash of the type information.
The receiver would then query the sender for the key that that
created
that hash value.
But adding extra requests complicates the protocol tremendously. In
particular, a HTTP server doesn't necessarily have the ability to
query the client.
I agree that using HTTP as transport will only allow TCP connections
to be initiated in one direction but that doesn't necessarily limit
the Hessian protocol.
With HTTP for example,
you can use the HTTP response to send a query from the receiver to the
sender, just as you currently use it for the Hessian reply;
you can use a long running TCP connection similar Ajax or Comet based
applications.
You don't necessarily need to bind the Hessian request/response cycle
to the HTTP request/response cycle in a 1:1 fashion.
So it's best to treat Hessian as a single unidirectional stream, which
also has the advantage that it works for different call or messaging
styles.
With messaging you have the ability to set up multiple endpoints, one
of which you can use a endpoint for type queries. It is not difficult
to implement an omnidirectional RPC mechanism on top of MOM. Most MOM
APIs will allow to neatly perform selective message consumption based
on a predicate, which in this case you can use to defer the
consumption of instance data until you have successfully queried the
type information in a much cleaner fashion that using HTTP as a
transport.
Furthermore, if you do treat Hessian as a unidirectional stream, you
will have to manage the following issues:
You need maintain coherency of type references across time, different
consumers and potentially across multiple producers. In this case, the
simplicity of the protocol puts a large onus of the sender, thus
making the implementation complicated.
You need to make sure that you send all of your type information at
the beginning of your transmission context. This means you will have
to know when you are starting an interaction with a particular peer,
hence limiting Hessian to specific peer to peer relationships. How can
you guarantee this in a messaging scenario?
What happens if the type information and instance data arrives out of
order?
What happens if a receiver loses a type reference during a long
running interaction? Do they need to cancel the entire transmission to
recover this?
Some of these points are discussed in this article:
http://hopper.squarespace.com/blog/2008/3/3/hessian-type-negotiation-protocol-flow.html
Ben
_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest
