Dear list,
I've created a first formal release of the protocol extension
discussed previously in this thread (Hessian 2.1).
The release is a fork of the Erlang implementation for Hessian 2.0.
I've written an article about it:
http://hopper.squarespace.com/blog/2008/4/17/hessian-21-for-erlang.html
The motivation behind this release is to turn a proof-of-concept into
a proper release and to tidy up some aspects of the protocol.
It also intends to demonstrate a workable trade-off between simplicity
and efficiency whilst retaining robustness and tractability of the
protocol.
The release can be mildly regarded as reference implementation of the
proposed extension.
HTH,
ben
On 4 Mar 2008, at 08:30, Ben Hood wrote:
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
