As big vendors wrestle with useful Web services for users, here is a new popular contender. Caucho has released the Hessian 1.0 specification. Popular technologies such as Spring and Thinlets make use of it. Would you use a binary Web services protocol?

Spring uses it, Thinlets use it, Infonoia uses it and I use it in my JDNC project at boardVU.com.

It may become the "Struts" of SOA: A corporate standard, with vendors only giving it lip service. It's fast and easy to do "complex" collection transfers for things like data grids. It has been ported to other languages.

This should be your first choice for SOA since it works, and then you can move on to others.

An example use is to create a Hessain to iBatis, so you can access your DAO remotely from RiA or legacy HTML applications.

By having a simple SOA, you can then build more complex applications. As Lentzsch (of JGoodies) says: "If simple things are hard, then complex applications are almost impossible".

Hession 1.0 Press Release

.V

Thnlets use it

Nope, it doesn't. Thinlet apps may use it, but they can use full-blown WS if they want to ;-)
BTW, Hessian didn't work well with more than 2k long streams neither was able to serialize Hibernate collections, which made it useless to me last time I tested it. Does anyone knows whether it's been improved in that areas?

We will most probably use the Hessian protocol for an application where a mobile device has to talk to an Application server (still evaluating though). As we run J2ME on the mobile phone, technologies like RMI or such are not present. Because we have to keep the size of the messages and the overhead of marshalling and unmarshalling as small as possible, SOAP is definitely no option. Therefore, a thin binary protocol like Hessian perfectly fits our needs.

Its fast and EASY to do "complex" collection transfers for things like data grids. It has been ported to other langages. This should be your first choice for SoA since it works, and then you can move on to others.

Congratulations! Hessian is very easy to use and it is fast enought:
http://kgionline.com/articles/protocol_compare/doc/index.jsp

Its fast and EASY to do "complex" collection transfers for things like data grids. It has been ported to other langages. This should be your first choice for SoA since it works, and then you can move on to others.

Congratulations! Hessian is very easy to use and it is fast enought:http://kgionline.com/articles/protocol_compare/doc/index.jsp

I did not see the link opening?

I want to know how it is better than XMLRPC(ws.apache.org/xmlrpc)???

Appriciate your help

I want to be quite honest. I would not spend even a minute in adopting a binary WS protocol. It is as interoperable as RMI/IIOP is and it still does not address many issues (orchestration, security, etc.).

I want to be quite honest. I would not spend even a minute in adopting a binary WS protocol. It is as interoperable as RMI/IIOP is and it still does not address many issues (orchestration, security, etc.).

What the *heck* are you talking about ?

Wait, nevermind, anyone writing RMI/IIOP is most likely ignorant.
And anyone saying IIOP does not provision for interop is sublimely ignorant.
But honest though ! That's gotta count for something, right ?

Sorry, I guess I have missed your point.

RMI over IIOP is based on two specifications of the Object Management Group:

• Java Language Mapping to OMG IDL Specification
• CORBA/IIOP 2.3.1 Specification, formal/99-10-07

So, how does the term "RMI/IIOP" give proof of ignorance?

By the way, a binary protocol could lead to a vendor lock-in unless it is publicly adopted. This is what WS were meant for, right?

By the way, a binary protocol could lead to a vendor lock-in unless it is publicly adopted. This is what WS were meant for, right?

They didn't say 'WS', they said 'SOA'. WS may be used to implement SOA, but a binary protocol, if it is portable to any platform, may also be used to implement it. And, if the protocol spec is publicly available (and there's no 'embrace and extend'), with an opensource implementation, where's the vendor lock-in?

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it. Don't mix the issues, readability x portability

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it. Don't mix the issues, readability x portability

sorry, but don't mix the issues here either. XML is designed for data interchange (common rules for parsing, validating, serializing, and representing data). XML is designed for computers, as well as humans.

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it.

I never looked and debugged TCP/IP package.
I forget when last time I looked at assembly code for CPU.
I never looked at bytecode that Javac produces.

I do not understand WHY people insist on human readability of computer-to-computer RPC protocols? I do not get it. The layer simply should work, conveniently and fast.

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it.

I never looked and debugged TCP/IP package.I forget when last time I looked at assembly code for CPU.I never looked at bytecode that Javac produces.I do not understand WHY people insist on human readability of computer-to-computer RPC protocols? I do not get it. The layer simply should work, conveniently and fast.

Must be nice to not have to ever debug what you write.

I sometimes need to look at the data going into and coming out of a module, to see why it's not working. I'd much prefer something I can read to looking up hex codes.

I agree, the layer should simply work. It usually doesn't at first. Some poor slob (other than you, obviously) will have to figure out why. If you're going to fob off some of your work on someone else, at least give him a chance...

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it.

I never looked and debugged TCP/IP package.I forget when last time I looked at assembly code for CPU.I never looked at bytecode that Javac produces.I do not understand WHY people insist on human readability of computer-to-computer RPC protocols? I do not get it. The layer simply should work, conveniently and fast.

Must be nice to not have to ever debug what you write.

The only advantage of WS (more specificaly, XML) over the binary format is that it is possible for a *human* to read it.

I never looked and debugged TCP/IP package.I forget when last time I looked at assembly code for CPU.I never looked at bytecode that Javac produces.I do not understand WHY people insist on human readability of computer-to-computer RPC protocols? I do not get it. The layer simply should work, conveniently and fast.

Must be nice to not have to ever debug what you write.

I seldom debug code. No, I do not write bug free code, but normally stack trace or bug appearance allows locating problem easily.

Necessity of deep and long debug sessions mostly indicates problems in code clarity and application logic.

I sometimes need to look at the data going into and coming out of a module, to see why it's not working. I'd much prefer something I can read to looking up hex codes.

Take a PDF document as an example and pretend it comes into a module and comes out processed. Do you really want to see PDF as text for debug purposes? Or PDF viewer is more convenient for use?

I agree, the layer should simply work. It usually doesn't at first. Some poor slob (other than you, obviously) will have to figure out why.

Exactly. Do you want to debug and fix JDBC driver, or prefer it simply works?
Why such honor for RPC?
RPC must work. Period.
Certain techniques eliminate need for debugging and guessing: take compiler as an example, it will not compile incorrect source, therefore there is no need to check and debug compiler's output for ordinary developers, it is responsibility of compiler creators.

By the way, a binary protocol could lead to a vendor lock-in unless it is publicly adopted. This is what WS were meant for, right?

There is no forced lock-in as long as protocol is open.
There is nothing proprietary in being binary. IIOP is _standard_ and it is open, and it is much more standard than XML based crap.
Hessian spec is open too. Implement it and lock yourself in own implementation.

Personally, I gladly lock myself into libraries, OS and other stuff, which I probably _could_ do, but others do way better.

<quote>There is no forced lock-in as long as protocol is open.</quote>

That's way I said "could lead".

<quote>There is nothing proprietary in being binary. IIOP is _standard_ and it is open, and it is much more standard than XML based crap.</quote>

That's exactly what I meant. But my question is why do you need to create another binary protocol if one (and possibly many) exists already?

But my question is why do you need to create another binary protocol if one (and possibly many) exists already?

I am CORBA fan, but IMO:
1. Hessian is extremely easy to deal with in Java.
2. Hessian uses http(s) ports. By mysterious reasons it seems not possible to open standard IIOP port on firewall despite lack of any reasons to do so. Quite contrary, it is harder to control all the zoo that creeps over port 80.

If we were open IIOP ports than I would say there would be little practical reasons for other than IIOP protocols.
ICE ( www.zeroc.com ) guys would probably disagree ( http://www.zeroc.com/iceVsCorba.html ), and where I have found their arguments compelling I still regard CORBA higher than anything widely used to date.

There is no forced lock-in as long as protocol is open.There is nothing proprietary in being binary. IIOP is _standard_ and it is open, and it is much more standard than XML based crap.

Well, basically you contradict yourself: IIOP is open and led to a MASSIVE vendor lock-in. Anyone ever tried to switch Corba Implementations from one ORB to the other?

There is no forced lock-in as long as protocol is open.There is nothing proprietary in being binary. IIOP is _standard_ and it is open, and it is much more standard than XML based crap.

Well, basically you contradict yourself: IIOP is open and led to a MASSIVE vendor lock-in.

Please do not mix interoperability and API compatibility. Using one vendor on server does not preclude from using another on client.

Implementation libraries do not have to provide the same API, and it not necessary.

Anyone ever tried to switch Corba Implementations from one ORB to the other?

I tried and it was not that bad. On client it is about supplying org.omg.CORBA.ORBClass, org.omg.CORBA.ORBSingletonClass + other stuff. Was doable in 1999.

Please do not mix interoperability and API compatibility. Using one vendor on server does not preclude from using another on client.Implementation libraries do not have to provide the same API, and it not necessary.

Oh, don't get me started on the (formerly) underspecified CORBA language bindings. But still, this only works if both the client and server support the same functionality and can work with the same optional packages. This is more often than not the real problem. Core Corba (so to speak) is fairly sweet, but soon you want to use things like security, load balancing and so on and suddenly it becomes _way_ harder to interoperate.

Please do not mix interoperability and API compatibility. Using one vendor on server does not preclude from using another on client.Implementation libraries do not have to provide the same API, and it not necessary.

Oh, don't get me started on the (formerly) underspecified CORBA language bindings. But still, this only works if both the client and server support the same functionality and can work with the same optional packages. This is more often than not the real problem. Core Corba (so to speak) is fairly sweet, but soon you want to use things like security, load balancing and so on and suddenly it becomes _way_ harder to interoperate.

The same is true for other types of protocols ( take XML-SOAP zoo as an example).

Do not get me wrong; I am not trying to say that CORBA is perfect and problems free. My point is that CORBA is very good as is and provides much healthier basis for improvements than anything else.

I want to be quite honest. I would not spend even a minute in adopting a binary WS protocol. It is as interoperable as RMI/IIOP is and it still does not address many issues (orchestration, security, etc.).

Not all web services need to be interoperable. I would even venture to say that most web services deployed today in enterprises are not meant to be interoperable; ours certainly aren't meant to be. We use them for our SOA for common data access but our clients are always java-based web clients. We have no .Net, perl or any other client nor do we intend to.

Web services are also good when you want to communicate via HTTP and don't want to mess with RMI over HTTP or something like that. I've worked with customers that had users outside the firewall but still needed to run applications, and a web service did just that. In those kinds of cases something like Hessian is quite appropriate.

I want to be quite honest. I would not spend even a minute in adopting a binary WS protocol. It is as interoperable as RMI/IIOP is and it still does not address many issues (orchestration, security, etc.).

This thought is as old as the left over chinese food in my fridge. You don't need the complexities of SOAP and WS-* specifications to enable web services. Utilizing well established standards, and proven implementations you can develop scalable, reliable, secure web services. Last time I checked, I felt safe using using my credit card to purchase a book, or manage my bank accounts.


Here's an old but excellent article. I highly recommend reading it:
http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html


Keep in mind, it's all about choosing the right tool for the right job. You don't need a sledge hammer to hang a picture. Hessian provides a great straight forward, easy to use protocol for many situations.


For example, I can use Glade, Python bindings, and Hessian to create a robust GTK+ application that integrates with an java enterprise backend service. I can easily take advantage of local c libraries, and corba components. Or I can enhance security with SSL transport layers, entrprise authentication and authorization services (via PAM _or_ JAAS), etc..... very very quickly.


BTW - Hessian is great when you are deailing with firewalls, or proxies. It is also nice when you can take advantage of HTTP 1.1 keep alive, or do some clever DHTML with XMLHttpRequest -- situations where you need to use HTTP as a transport and want to limit the bandwidth used.

I'm a bit puzzled.

Hessian has existed for years. The license copyright years are 2000-2004.
I've seen Hessian for the first time more than a year ago.
According to http://www.caucho.com/resin-3.0/protocols/hessian-1.0-spec.xtp, this is version 1.0.1; also the last modification date of that page is "May 22, 2004".

So how come there's a press release about 1.0 in 2004-10-20 ?

We're using it in an interative application, wrote the C++ client side impl. and also use a modified version that does gzip past a message size threshold.

Anyways, Hessian is fast, lean and so far required no stupid tweaking of data structures or custom serialisers like Axis does (or did).

I find a lot of good work and common sense in this one.
Thanks to Caucho for doing this, it helps to have a major vendor supporting a binary protocol for WS ;^)

I'm a bit puzzled. Hessian has existed for years... So how come there's a press release about 1.0 in 2004-10-20 ?

Because Hessian has never actually been announced, and we finally figured we should get around to writing an announcement. Since the number of people using Hessian has increased recently, it seemed a good time to let others know that it exists.

Also, Hessian had stayed in draft form for a long time. Since changing a protocol is almost impossible once it's published, it seemed better to wait until it had proved itself over time before casting it in stone.

The main reason, of course, is that the massive marketing hype surrounding SOAP has finally died down, so people can now evaluate competing protocols more rationally. Announcing Hessian when it was developed would have been nearly pointless, like lighting a match in the middle of a forest fire.

I've been using Hessian (and Burlap as well) in several projects now and it has suited my needs well.

The caller as well as the callee should however not be bothered with what protocol is used, be it Hessian, Burlap, JAX-RPC or RMI. This enables you to choose whatever technology you like and fits your requirements.

Hessian and/or Burlap are perfect solutions for situations where you control both the 'client' and the 'server'. It's fast, ligthweigth and when making it part of the a web application, you don't have to worry about security also!

RMI and the different HTTP-invocations strategies out there (Spring and for example JBoss) are more suited for demanding situations. You should for example be careful with using Hessian (and/or Burlap) in combination with Hibernate lazily mapped collections. Transporting them over the wire using Hessian will not work, since Hessian uses its own serialization protocol.

When you need to be interoperable with different platforms, the obvious choice is to use something like SOAP.

Again, in ideal circumstances, code shouldn't be tied to one specific RPC protocol to allow for easy switching when needed!

But again,

Hessian and/or Burlap are perfect solutions for situations where you control both the 'client' and the 'server'. It's fast, ligthweigth and when making it part of the a web application, you don't have to worry about security also!

Yes. Java Web Start clients connected with Hessian - extremely convenient to develop and deploy.

Are there limits to the types of classes that can be serialized by Hessian?

Specifically, we use some really old JGL "collection" classes (e.g .OrderedMap) quite a bit. They gave us more powerful Hashtable-type functionality in the old days before HashMap/TreeMap. (Dang I'm old). Will Hessian properly marshall/unmarshall these guys?

It looks great. Can't wait to try it!

I use Hessian with all kinds of nested collections and with Jakarta collectiosn orderd map and it works.

Here is a tutorial on Hessian:
http://www.caucho.com/hessian/#Introduction-to-Hessian

.V

Hessian is a great choice for java clients. We tried Axis and the rest of the WS-* soup and it was just too bulky and heavy weight to integrate into a lightweight client. Not to mention that Axis/WS- is overly complicated for basic client to server messaging needs.

Hessian is good choice if you need RMI type capaiblity for a webclient to webserver environment. If you have an all java client and server environment Hessian does the job very well and much much easier to use than Axis.

I'd be interested in using something like this for our applet2server communication, but I'd first like to find out more about how it handles HTTP connections. Does anyone know where to find such information? Specifically, will a client be holding HTTP connections open for long periods of time? On the one hand that is good in order to avoid connection time for chatty protocols, yet on the other hand it is bad as it limits the number of concurrent clients. So, I'd really like to know how this is handled, and if it is possible to customize.

I'd be interested in using something like this for our applet2server communication, but I'd first like to find out more about how it handles HTTP connections. Does anyone know where to find such information? Specifically, will a client be holding HTTP connections open for long periods of time? On the one hand that is good in order to avoid connection time for chatty protocols, yet on the other hand it is bad as it limits the number of concurrent clients. So, I'd really like to know how this is handled, and if it is possible to customize.

Something to keep in mind: I tried Hessian (hessian-3.0.8 jar) in Applet and client JVM threw security exception as Hessian tried reaching a private field.

Something to keep in mind: I tried Hessian (hessian-3.0.8 jar) in Applet and client JVM threw security exception as Hessian tried reaching a private field.

Thanks for the warning, but that's ok. We sign it anyway (along with all external libraries).

Rikard:

Hessian is Open Source and distributed under the Apache License. You can get in and customise the connection handling to your heart's content.

We've been using Hessian with great results on the upcoming version of our software. We've previously used SOAP-based transport but at 144k, the Hessian library is ultra-lightweight for our clients that need to download (most web service stacks are easily in the order of 1mb+ once you have XML parsing and the rest).

The Hessian API is similar to Glue in that it is not intrusive into your code, we have a group of Servlets that are simply wrappers around our underlying logic. If we have a need to introduce another protocol, we can do that very easily.

Performance seems pretty good, we have been transferring files of up to about 10k without a problem, although I have been working on getting larger file sizes to transfer which seems to require a bit more effort.

All in all, very happy campers at the moment.

Toby Hede
------------------------
http://www.webalive.biz/

Rikard:Hessian is Open Source and distributed under the Apache License. You can get in and customise the connection handling to your heart's content.

That's great, but if the current Hessian code has connection management that doesn't work well for lots of applet clients I don't want to bother. That's why I asked, and am still asking because you didn't answer.

We've been using Hessian with great results on the upcoming version of our software. We've previously used SOAP-based transport but at 144k, the Hessian library is ultra-lightweight for our clients that need to download (most web service stacks are easily in the order of 1mb+ once you have XML parsing and the rest). The Hessian API is similar to Glue in that it is not intrusive into your code, we have a group of Servlets that are simply wrappers around our underlying logic. If we have a need to introduce another protocol, we can do that very easily.Performance seems pretty good, we have been transferring files of up to about 10k without a problem, although I have been working on getting larger file sizes to transfer which seems to require a bit more effort.

That's great, but right now I'm more worried about scalability than performance. If it has persistent connections, will it eat up all HTTP connections so that the webserver isn't accessible? (for example) Or does it take care not to violate the max-2-connections restriction in browsers? (for example). Etc.

I tried to find design docs on how connection management is done, but couldn't find any, and in my particular case it's vital to know.

I just did a quick trawl through the source and from the looks of it there is no specific connection management going on.

The connection appears to ultimately be a java.net.HttpUrlConnection that appears to be opened and closed for each invocation.

The objects of interest are the HessianProxyFactory and HessianProxy.

The connection is opened in the HessianProxyFactory.openConnection(URL url) method. Creating some sort of connection pool would probably be quite relatively straight forward.

I just did a quick trawl through the source and from the looks of it there is no specific connection management going on.

Thanks, then I have everything I need.

Today we are using WebWork as our RMI impl., and it works reasonably well.

If Hessian had some intelligent connection pooling it would have been interesting to try it out, but as it is there's not enough "new" to make it useful for me.

You might use Jakarta Commons HttpClient to handle http connections (and HTTP POSTS). Just write a class that replace HessianProxy and extend the HessianProxyFactory and override 'create' so that it will use the new proxy. It is not too much work really.

You might use Jakarta Commons HttpClient to handle http connections (and HTTP POSTS). Just write a class that replace HessianProxy and extend the HessianProxyFactory and override 'create' so that it will use the new proxy. It is not too much work really.

Actually, it is unfortunately not that simple. If you want to use HTTP and persistent connections to implement an RMI layer you will have to have 2 connections from each client. One for the downstream and one for the upstream, since a) you can't mix up and down in one logical connection and b) you can't use HTTP persistent connections for POST's.

But if you use that there are some problems that must be handled, such as buffering proxies and the 2-connection-limit in browsers. And you also have to ensure that the client connections don't max out the webservers connections, hence making the website unreachable.

So it is non-trivial.

Did you compare the performance with a WS toolkit that uses DIME/MIME to transport binary content?

How is the documentation?
The tools?, ease of use?

Thanks,
Yuval.

Is there a Hessian implementation for dotnet ?
How can dotnet client connect to java server using Hessian protocol ?

:-)

There is Hessian for C++ if you went to the hessian site.

.V

We used Hessian in a project and shifted to HttpInvoker after a couple of minor annoyance with Hessian. For example, Hessian does not passes BigDecimals, we had to convert our numbers to byte [] and rebuild them into BigDecimal on the receiving end.

On the other end, HttpInvoker forces you to implement the Serializable interface on each object you want to transfer since it uses java's Serialization mechanism.

I would say the choice of one over another is a matter of personnal preference.

We used Hessian in a project and shifted to HttpInvoker after a couple of minor annoyance with Hessian. For example, Hessian does not passes BigDecimals, we had to convert our numbers to byte [] and rebuild them into BigDecimal on the receiving end. On the other end, HttpInvoker forces you to implement the Serializable interface on each object you want to transfer since it uses java's Serialization mechanism.I would say the choice of one over another is a matter of personnal preference.

From:
http://www.springframework.org/docs/api/org/springframework/remoting/httpinvoker/package-summary.html
<quote>
Package org.springframework.remoting.httpinvoker Description

Remoting classes for transparent Java-to-Java remoting via HTTP invokers. Uses Java serialization just like RMI, but provides the same ease of setup as Caucho's HTTP-based Hessian and Burlap protocols.
</quote>
Sound like wheel reinvention and sign of not-invented-here syndrome.
Hessian and Burlap are not limited to Java and simply to implement, why reinvent?

Sound like wheel reinvention and sign of not-invented-here syndrome.
Hessian and Burlap are not limited to Java and simply to implement, why reinvent?

Simply because there Hessian has limitations and so does RMI. First of all I don't want to bother with setting up RMI over HTTP. Second of all (don't take me wrong, I like Hessian a lot), some complex types (for example Hibernate lazily mapped collections and stuff, like I mentioned before) will simply cause you trouble when serializing them to a fat client.

Read this:
http://www.springframework.org/docs/reference/remoting.html#d0e9002

regards,
Alef

Sound like wheel reinvention and sign of not-invented-here syndrome. Hessian and Burlap are not limited to Java and simply to implement, why reinvent?

Note that Spring comes with first-class support for Hessian and Burlap since its early stages. The reason why we added the HTTP invoker strategy in Spring 1.1 is simply that there is value in that combination of features:

* HTTP-based like Hessian
* as simple to set up as Hessian (on both the client and the server side)
* giving the full power of Java serialization (at the drawback of enforcing the same strict serialization requirements as RMI, like implementing java.io.Serializable etc).

Of course, this HTTP invoker strategy is only a candidate for Java-to-Java remoting, due to its use of Java serialization. I believe that there are appropriate scenarios for both Hessian and HTTP invoker; choose according to your requirements.

One of the benefits of Spring is that it makes the remoting protocol choice a configuration issue: switching between Hessian, HTTP invoker and co is seamless. Exposing the same service instance through different protocols (at different URLs) is straightforward too.

Juergen

It seems to me it is basically just a little bit better than using plain xml over http. I fail to see how

S x00 x05 model

is so much better better than

<val>model</val>

When using Maps for object serialization, most of the power of using XML to constrain and validate transfered data goes away. On top of that, you would most certainly need a way to describe your document schema/call signature in a standard way and I can't really see that Hessian does that for me.