Re: Hessian PHP implementation

Hi

On Thu, 13 Jan 2005 23:47:20 -0500, Manolo Gómez P. <vegeta.ec@xxx.com> wrote:
> Hello to everyone
>
> Again, thank you very much for the support.
>
> Actually I did send an email about the release of HessianPHP but looks
> like the message didn't get to the list on time.
> (Thanks a lot Radu-Adrian and Scott)
>
> Hessian seems to be gaining interest among the community, but as
> Christian Campo noted, there seems to be several aspects to consider
> for the next Hessian version.
>
> I agree with Christian's ideas and I am trying to match them for HessianPHP,
> concretely:
>
> > - better error handling (HessianRuntimeException or
> > HessianProtocolException is most times not good enough)
>
> As you might know, PHP 4 error handling model is just messed up, you don't
> have exceptions so when an error is detected (or a "fault"), HessianPHP
> throws a "fatal error" that just halts the script and shows some
> information.
>
> PHP5 is a different history, the object model is closer to Java so I
> implemented two different exceptions, HttpException and HessianException
> which respectively correspond to a communication failure and to a protocol
> error (basically parsing and faults), both contain some sort of stack
> trace and info regarding the failure condition.
>
> I wish you could give me some thoughts on this, a way to effectively
> handle errors when you have NO exceptions at all and maybe unify the
> possible exceptions in the implementation.

Actually my problem is not so much that what Exceptions to throw but
rather to detect several comon error situations. Say your webservice
call dies on the server with HTTP error code 500 (for whatever
reason). What I get on the client is a HessianRuntimeException with no
indication what happened. That is indistiguishable from timeouts,
ClassNotFourndExceptions etc. The HessianRuntimeException not even
contains a message most of the times and if it does it says meaningful
thing like "expected code t". This is tough for application
developers. So I started to actually wrapp the HessianRuntimeException
in our code with a reference to "---> check server log". But I know
that the code on the client could give more info, like the HTTP error
codes and sometimes messages that it gets.
Of course then I like to have HessianTimeoutExceptions and
HessianServerExceptions etc. or as an alternative have some private
fields that a programmer could check to show a user friendly message.
Not every webservice call that fails is a reason to exit the whole
program. :-)

>
> > - did you ever try to create a webservice that had two methods with
> > the same name but different signature ??? My users tried that and all
> > you get is "Unexpected code: M" :-) I know its forbidden, but a
> > clearer message would
> > help
>
> This is bad indeed, I never considered this since PHP is dynamically
> typed, and it can handle any number of parameters you send to a method
> even if the signature says different.

If though thats true, I believe that the Webservice definitions (at
least SOAP) rule out overloading of methods. So maybe that means that
you have to forbid that feature in PHP to be compatible with other
languages. After all you may want to have the ability to exchange a
PHP webservice "seemingless" with a Java webservice (with the same
interface). That requires the enforce the smallest common subset of
features.
Maybe I am wrong here ???
 
>
> There should be a code or message that handles this.
>
> > - GZIP requests and responses, hopefully by using HTTP Headers so that
> > the client triggers whether he wants GZIPping or not
> > - optionally logging error message on the server when they occurr
> > - and there is always more :-)
>
> This is interesting and I hope it gets in Hessian Java code. I am curious
> to know how to implement it though, using HTTP headers as Christian
> proposes or by inspecting incoming data as I think HessianCPP does,
> please correct me if I'm wrong Radu-Adrian.

If you use HTTP headers you could keep it out of the Hessian
internals. I mean Hessian already has several pieces of code
duplicated. If you have header you only need to deal with it in the
HessianServlet and in the HessianProxy. For example in the
HessianProxy in the invoke method you write something like:
      GZIPOutputStream gzipOut=null;
      HessianOutput out;
      if (useGZIP) {
         gzipOut =new GZIPOutputStream(os);
         out = _factory.getHessianOutput(gzipOut);
      } else {
               out = _factory.getHessianOutput(os);
      }
and depending on useGZIP it would gzip the stream it sends to the server or not.
(There are a number of places like that but its pretty straight forward)

>
> PHP supports gzip natively so It shouldn't be hard to get this feature in.
>
> Logging errors to file sounds good too, or perhaps having a pluggable
> logging mechanism where you can switch bewteen things like log4j or
> commons-logging or whatever, defining the level of messages.

That sounds good. It would even help to put into the log of the webcontainer
but simple using System.out.
The current implementation is like:
    } catch (RuntimeException e) {
      throw e;
    } catch (ServletException e) {
      throw e;
    } catch (Throwable e) {
      throw new ServletException(e);
So you too often see no message at all on the server log.

>
> Oh, I almost forgot, this is an even more off topic question, but what
> do you think
> about this:
>
> http://weblogs.java.net/blog/pelegri/archive/2005/01/start_using_bin.html
>
> Open source Binary XML standard, look like it's comming full circle,
> back to binary
> where it should have stayed in the first place.
>
> Would love to hear your thoughts.

I can only say a little about this, since we signed a NDA on Fast
Webservices. So I had contact with Eduardo who helped us to get an
evaluation copy of Fast Webservices. Its terrific software (I guess I
am safe to say that :-) ). However at the time we evaluate it, they
had no Dynamic Proxy support (not sure about the current status, but
there were plans to have that) which is what we wanted.

Other than that I agree that Webservices exchanging a binary format
are better suited at least for some applications. I also used Axis and
SOAP and no matter what you think about XML alone, just the number of
XML namespace declarations in the XML requests and response is much to
much for my taste.

I still like to hear from someone else (like Scott) what the future
timeline of Hessian is. Having ideas is good, having new releases is
even better :-)

kind regards
christian campo

>
> Manolo Gómez Placencia, MCP
> Investigación y Desarrollo de Software
> Pontificia Universidad Católica del Ecuador
> Quito, Ecuador
> Telf: (593) 2 2991700 ext. 1336
>

-- 
christian campo (gmail.com)