Re: Hessian PHP implementation

On Jan 14, 2005, at 10:37 AM, Radu-Adrian Popescu wrote:

> 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.

I think Christian is talking about application-level errors.
Currently, the Java implementation is not doing a good job of logging
the application errors. (Partially because of JDK compatibility
worries, partially because of laziness in the initial implementation.)

Logging the hessian stream itself is a somewhat different issue. It
would be a good idea to write a pretty-printer so you could at least
save the stream and look at it.
>
>> 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.

These are mostly issues with the Java implementation.
>> 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.

Actually, the Accept-Encoding would work just fine, and letting Apache
(or Resin's GzipFilter) do the compression should work. I don't think
there's any need for "hessian_*" values.

> 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.

I think those sorts of flags would belong in an envelope, if that was
necessary.

E 0x01 0x00 features headers hessian-content

The call/reply itself shouldn't know or care how it's
encoded/compresses/digested.

>
> 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
> ?

Yes, but a plain socket protocol would probably add some kind of
flow-control or encapsulation protocol over the main Hessian calls.

You could also have the rule that if a client request was gzipped, the
response should be gzipped as well. Logically, that's an
encapsulation, even though it's just determined by looking at the first
byte.

> 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) ?

IIOP is horribly complex from an implementation perspective. The basic
byte/integer/double is fine, but the encoding of strings and objects is
ugly.

XDR would be fine, but I don't know if it can handle arbitrary (i.e.
non-predefined by IDL) objects.

I haven't really looked into it as much as I probably should. They may
just be trying to solve different problems.

> 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).

Yep. An IDL-based protocol could be a bit more compact (I think the
ICE guys have created a straightforward IDL-based protocol), but
Hessian is pretty compact for a self-describing protocol.

-- Scott

>
> --
> Radu-Adrian Popescu
> CSA, DBA, Developer
> Aldrapay MD
> Aldratech Ltd.
> +40213212243
Received on Fri 14 Jan 2005 11:21:50 -0800