Re: Hessian PHP implementation

Hi Radu-Adrian,
it certainly starts a discussion :-)

On Fri, 14 Jan 2005 14:16:43 +0200, Radu-Adrian Popescu
<radu.popescu@xxx.com> wrote:
> 1. Error handling
> - Client side
> HessianCPP uses a small, SSL-enabled, POST-only HTTP library.
> This throws (*) sslpp::exceptions::http_exception.
> The hessiancpp codebase defines another two exceptions:
> (*) hessian::exceptions::io_exception
> (*) hessian::exceptions::fault_exception
> So we have three exception types, each of those on a different layer in the
> client-server communication:
> - http_exception at the TCP/HTTP level;
> - io_exception at the Hessian protocol level;
> - fault_exception for server-side errors (these _do not_ include 404, 500 and
> friends, i.e. they are exclusively hessian-serialised exceptions from the reply).
> We really don't care about the server-side stack trace, except for the embedded
> exception name (when using exceptions that are thrown by code to signal truly
> exceptional conditions, such as database failure).
> I also think that there's really no point in having the server-side stack trace
> in the client. I mean it's not like the client cares about a list of some thirty
> Java classes on the backtrace; the client made a call and the server went awry,
> nothing it can do about it. And obviously exception logging should be
> implemented on the server side, so no need to serialise Kb of maps to the client
> for a useless backtrace. Maybe some of you will disagree, but I think that
> writing services that catch all exceptions and throw user exceptions in a
> controlled fashion, and make use of proper error logging is the way to go. And
> this I hold for all clients, not just C++.
> I also think the server-side hessian Java implementation should not make use of
> some logging package that would slow it down, and leave the error handling to
> the service implementation.

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.

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.

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.

>
> Regarding error handling when exceptions are missing (PHP), how about an
> exception handler function pointer thing ? Maybe not the best idea...
>
> Regarding the method overloading, I've not run into it as yet and provided not
> support for it in hessiancpp, but I've talked to someone who has (Matt from
> Javalobby, see http://javalobby.org/nl/archive/jlnews_20041207o.html#newsfront)
> and pointed him to
> http://www.caucho.com/resin-3.0/protocols/hessian-1.0-spec.xtp#Methods-and-Overloading
>
> He replied saying thanks, he's already and unknowingly done it that way.
> So the least I can say here is that the assertion that two methods having the
> same name and different signature is forbidden is wrong, and overloading is in
> the spec

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).
>
> Regarding the Gzip compression: "If you use HTTP headers you could keep it out
> of the Hessian internals.". Well, here's how I did it:
> - changed com.caucho.hessian.HessianServlet and
> 1) look-up User-Agent header;
> 2) if the user-agent is Flash, we pre-un-escape the input stream;
> 3) prepare a ByteArrayOutputStream to hold reply;
> 4) invoke with input stream and our output stream;
> 5) if the client is Flash, escape the reply data;
> 6) if the client is hessiancpp, if the reply size exceeds a threshold, gzip it;
> 7) pour the reply to the client;
> 8) in C++ the server call proxy test the 1st four bytes of the reply for the
> gzip magic and de-compresses if found, then passes the de-compressed reply to
> the same channel of processing as usual.
> Now looking at the above I find the process quite straight-forward. We may want
> to add usage of another HTTP header, namely the standard Accept-encoding header
> ("gzip" or "deflate"), to make things a bit more general on the compression side
> and maybe also on the Flash escaping side. This remains to be thought through
> properly though, as we may also be able to use standard web server compression
> for Flash using mod-gzip or mod-deflate (Flash calls server using browser and
> browsers generally are able to grok gzip/deflate). The Flash issue is that it
> does not have a API-accessible, native (meaning C/C++) implementation of any
> compression algorithm. The SWF itself uses Gzip if I'm not mistaken, so the
> ActiveX/Netscape component does have this built in, but it's just that you can't
> get to it from the API, and writing one in AS does not look pretty.

For some reason I strongly believe in standards. the Accept-enconding
header is such a standard. Magic is nice but I found several times
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
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
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)

>
> Regarding binary XML, I don't an opinion on that as yet. I've fiddled with
> S-expressions instead and I find them much more agreeable (than XML). Maybe I'm
> naive, but I wrote a non-recursive S-expression parser:
> [root@xxx sexpp]# wc -l *.java
>
> 81 bytearray.java
> 113 Parser.java
> 48 sexp_input_stream.java
> 242 total
>
> in yes, 242 lines of code, including a very fast resizeable byte array and a
> simplistic, over-a-string input stream. It parses S-expressions into trees,
> using DefaultMutableTreeNode from *ugh* Swing. It also supports binary data by
> using (optionally) length-prefixed strings.
> Prior art suggests in-memory, binary representation of s-expressions is rather
> efficient.
> You may want to take a look here: http://theory.lcs.mit.edu/~rivest/sexp.txt for
> further information.
> And to think XML 2.0 is in the works...
>
> All in all, except for the bugs, I'm pretty happy with the current
> Caucho/Hessian implementation. Not that happy with the c++ implementation though
> :). I've also implemented a code generator for C++, written in Java, that
> outputs C++ classes matching those used by the service's methods, and also all
> the [de]serialisation, exception handling and all that's needed to basically
> provide a C++ project with the service invocation stubs. Pretty much like what
> an IDL compiler does, or a WSDL-to-code (.NET's wsdl.exe is a good example)
> does, except here we don't have an IDL but the service's interface class.
>
> Wow, this was a long email. I hope it will spring up the discussion.
>
> Cheers,
> --
> Radu-Adrian Popescu
> CSA, DBA, Developer
> Aldrapay MD
> Aldratech Ltd.
> +40213212243
>
>
>
I can say I like Hessian but I think the Java implemenation has still
some steps to go to be perfect. :-)
Any effort planned to make it a sourceforge.net project so that people
can start to contribute their fixes and features ? Any new release
planned with the existing fixes ??

regards
christian campo

-- 
christian campo (gmail.com)