9

I have a new project that needs a good binary protocol.

I was thinking of using Hessian, unless anyone has any better ideas.

I was reading through some of their documentation and it's not as straightforward as I thought, so I have a couple of quick questions.

The home page has a section titled "Documentation" that has the following documents:

* Hessian Documentation
* Hessian 1.0.1 spec
* Hessian 2.0 Serialization Draft
* Hessian 2.0 Web Service Draft
* Taxonomy explaining Hessians relationship to CORBA, SOAP, RMI

1) What is the difference between these? I assume that 1.0.1 later becomes 2.0, and that it is correct to use 2.0 today, but I wasn't sure.

2) Would you expect someone to use 2.0 serialization or 2.0 web service? It looks like the web service is just supposed to be a reference to create a new implementation, but again it's not totally clear to me.

3) What about implementing a server that supports Hessian using PHP. Do you need to use a Caucho server, or can you implement the server in PHP on a Fedora Core and connect using a Java client?

David Newcomb
  • 10,639
  • 3
  • 49
  • 62
Hortitude
  • 13,638
  • 16
  • 58
  • 72

2 Answers2

9

Yes, Hessian 2.0 is the one to use. The protocol specifies how a data structure is represented binary, the spec is simple.

The Hessian web service builds on the Hessian protocol, it specifies a number of headers in the Hessian format to describe e.g. the request/response format in the Hessian protocol. It defines the content of the request, the method that should be called and so on. It is not strictly needed because nobody uses it. You can define this yourself by creating a "Request" class and a "Response" class that suits you best and serialize this using Hessian protocol.

Hessian is an alternative for Java serialization, it is slower because not directly supported by the java VM, but it is much (!) faster than XML parsing. It can be used in a cross platform way, although you will have to tweak existing implementations to make them work together, the spec has changed here and there (e.g. length specs) so that implementations tend to differ. The flip side is that it is not Human readable, you always need a tool to convert the Hessian to text.

I have used Hessian in a large corporate application where a Java rich client communicates with a back end in order to make the client JVM version independent of the server JVM version. And it worked like a charm.

Have a look at the implementation Hessian4J. It is open source so you can have complete control over it.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
Bruno Ranschaert
  • 7,428
  • 5
  • 36
  • 46
2

I have not used Hessian in the past and I don't plan on using it in the future either, and my arguments are these:

For a web service, I would try really hard to keep it in plain old XML. In the event that I would choose a binary XML representation, I would probably use Fast Infoset - which is a standard and most likely supported by a much larger set of web service client APIs/libraries/frameworks. I know that the CXF people have talked about fast infoset on their mailing list and it should be supported, even though they have not documented this on their wiki.

If speed is the primary thing, I would probably end up using Protocol Buffers.

Chris Vest
  • 8,642
  • 3
  • 35
  • 43