Re: Hessian PHP implementation

Christian Campo wrote:
> Hi Radu-Adrian,
> it certainly starts a discussion :-)
>
>
> Here we probably do not agree fully. One I believe there should be at
> least an option to use a logging package because in the development
> stages it makes things so much easier. So you should be able to see
> exceptions and stacktraces on the server if you wish and without the
> requirement to put webservice specific exception handling into your
> business logic. They might not even know that are called as a
> webservice.
>

I do remember the original hiccups and the trouble we took to find out what's
actually happening when things go wrong, and a lot of things went wrong during
implementing both c++ and flash clients. But we got by by dumping raw and hex
messages to files, merrily scribbling on pieces of paper and counting bytes with
the pencil on the screen.

> Second I believe that the client should get an idea what went wrong
> and specifically should be able to distinguish HTTP-error 404
> (service not found) from HTTP-error 500 (server error) and HTTP-error
> 403 (forbidden). He may
> want to react to that in different ways.
>

Like I said, this is entirely possible the way the c++ version is implemented. I
don't know about the Caucho Java client implementation, I've actually never used
it (started with the python example, tcpdump, the specs and the C++ IDE).

> Third also errors on the client side that happens deep inside are not
> shown in the stacktrace of the HessianRuntimeException. That is
> because the HessianRuntimeException has no method getCause(), as I
> pointed out earlier in the thread.
>

I'm not sure I read this right: you mean on the client side as in you're in the
client, call on server and an error pops up and you can't tell where it
originates from / the actual cause ? If that's so then I guess it does need
improvement.

>
> Cool however I had a Java webservice where we had the same method name
> twice. One version had 5 parms and one had only 1. When calling 5
> parameter version on the client side, the server (for some reason)
> decided to pick the 1 parameter version and was "surprised" to see
> that there more parameters coming (unexpected code ?). The spec says
> hessian allows overload by parameter code. Does not seem to work in
> all cases however (if at all).
>

If you're right then I guess the "overload by number of parameters" is broken
and needs to be fixed. Have you investigated further ?

>
> For some reason I strongly believe in standards. the Accept-enconding
> header is such a standard. Magic is nice but I found several times

Not that User-Agent is not standard...

> that it will soon turn against you and start to do stuff "magically"
> that you do not want. Simple example would be that you do not want

Nothing magic there, except the GZIP stream header or how Scott puts it,
examine-first-byte. The C++ code is designed to handle both raw and gzipped
hessian streams. I do agree that automagick may do more harm than good at times
and it pays to be a bit orthodox.

> GZIP encoding all the time because it eats CPU time. So say your
> client program wants the tell the server to use GZIP when it has
> mobile (GPRS) connection and not use GZIP when its on the LAN. An
> Accept-encoding header is the way to go and even though it requires

Like I said, the Accept-Encoding header seems to be best suited for this, at
least from a formal point of view.
If this be the way it's going to be done, I strongly suggest defining some
domain specific encodings, for instance:
hessian_raw, hessian_gzip, hessian_bzip, hessian_flash, hessian_whatnot.
I'm not terribly sure about this, but it may avoid problems in set-ups such as
using an Apache front-end with mod_proxy/mod_proxy_http/ProxyPassReverse and
mod_[gzip|deflate]. It may also allow for less-than-capable clients such as
Flash to use Accept-Encoding: gzip, deflate to send/receive using compression
implemented by the standard HTTP stack in any web server.

As a side note Accept-Encoding decisions and encoding decisions are allowed to
be tweaked/made by analysing the User-Agent too.
To soften your impression of the magic involved, or the non-standardness
thereof, quoth the RFC on User-Agent:
"This is for statistical purposes, the tracing of protocol violations, and
automated recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include this field
with requests."
It may not _the_ best place to do this, but it's not wrong either, and it works
in our implementation and it's quite clean.

Here's a thought: how about adding two bytes after the call that serves as a
sort of an accept-encoding or "features" tag ?
c 0x01 0x00 features
features ::= b16 b8
Then define FEATURE_NONE = 0, FEATURE_GZIP = 2, FEATURE_SIGN_MD5 = 4 and so on.
This would be simpler than using hessian's header feature, as an user of the
stream does not need to understand the whole serialisation in order to detect
the features of the stream.

It just hit me, using HTTP headers is an really bad idea if you want to use
Hessian over plain sockets and skip the whole HTTP stuff. Right ?

> more effort its most universal and flexibel. (BTW I would hate it if
> the HessianServlet (the java implementation) has ANY code that says if
> client is "hessiancpp". I believe that is a contradication to the
> concept of webservices where you don't know what implementation the
> other side is as long as it has the right protocol)
>

I do not think that using User-Agent to tweak performance is bad, as it does not
affect standard behaviour compliance - i.e. ability to talk to a reference
implementation client that does not support any of the optional features
(response signing, compression & whatnot).

Also on the binary xml / fast web services, I've seen them getting a hell of a
beating for that ASN.1 choice. I may be out of my depth here a bit, but why not
use CDR (of CORBA) or XDR (of Sun's RPC) ? These are well established
serialisation formats and may allow for better integration in the enterprise.

At any rate, hessian's serialisation is pretty straight-forward and unambiguous,
and it feels neat (as opposed to bloated).

-- 
Radu-Adrian Popescu
CSA, DBA, Developer
Aldrapay MD
Aldratech Ltd.
+40213212243