Menu

Features

2001-05-04
2001-05-07
  • Rainer Bischof

    Rainer Bischof - 2001-05-04

    Hi,

    I just had a quick look at your stuff and I think it's quite useful, especially the XmlRpcProxy and the flexibility gained through the custom serializers.

    I have one question

    Are you thinking of a way to add custom deserializers like it is possible for serializers? This would useful to transfer real java objects.

    Thinking this further would lead to the possibility not only to return any object but also to pass any object as a parameter to a method call.

    What I am looking for is an XML based solution which is really object oriented. I know this goes beyound the spec and is thus proprietary but would be a very useful replacement for RMI.

    Any ideas?

    Thanks
    Rainer

     
    • Greger Ohlson

      Greger Ohlson - 2001-05-05

      Hi,

      This is perhaps not such a bad idea. I will see how it could be implemented. Firstly, there would have to be some convention specifying how this deserializer should be invoked. Arriving at the server is just an "anonymous" struct that does not inherently indicate that this struct actually match a known object type at the server. However, with some work a simple convention could be introduced where the caller could specify that the struct should invoke a custom deserializer at the server side, or in some way mark the struct. I'll look into it.

      Thanks for the input. Keep in touch.

      Regards,
      Greger Ohlson

       
    • Rainer Bischof

      Rainer Bischof - 2001-05-06

      Hi,

      I have implemented it (just a quick and dirty proof of concept to see if it works):
      If a struct arrives with a value named '#ClassName' the struct is interpreted as an object of the class with the given name and beeing built using reflection.
      That way it does not add any proprietary extensions to the XML-RPC spec, and at least in Java '#ClassName' is an invalid variable identifier so it cannot happen to conflict with a variable in the serialized object.

      I have not had a deeper look into your code to make it fit best, just played around until it worked.
      I built a new ReflectiveObjectSerializer that includes the classname and modified the methods handleParsedValue in XmlRpcClient and XmlRpcDispatcher to change the object from Hashtable to the object being transferred.

      The only thing I am really not happy with is the exception handling. Any exception thrown on the server side should be trnasferred to the client and rethrown there. Any communication error should be thrown as a RemoteException as in RMI. Also the dynamic Proxy-Stuff should be modified to provide a clearer Exception handling.

      All that stuff should be pluggable but I have not had a deeper look into your code how this can be done. I will hopefully be able to have a clooser look into it next week but I will be on the road...

      So, seems that your stuff is working great for us, I will check to see if we can use in our next project here.

      Thanks
      Rainer

       
      • Greger Ohlson

        Greger Ohlson - 2001-05-06

        Hi,

        Thanks for the input. This is good stuff.

        Exception handling, and error handling in general will be looked into. Currently, if the XML payload is unparseable, the caller will receive a HTTP 400 Internal error. If the payload is parseable XML, any exception arising from that point on will result in an XML-RPC fault-struct.

        Error in communication results in an IOException. There are a few known issues. I'll look over the exception handling, and see if the proxy-code can be improved.

        At the server side, an XmlRpcInvocationProcessor could be registered with the server that examines the arguments. Every Hashtable with a "#ClassName" field could be converted to its object counterpart and then be reinserted into the argument list. This way the object deserializer may be treated as an extension to the current server code (no alteration to  handleParsedValue() necessary).

        On the client side, there is no way of converting the value contained in the response, but altering the handleParsedValue() method. Perhaps there should be an entry point somewhere where user objects may interfere. Will look into that.

        Again, thanks for the input. I'll have a go at the code in a few days when things settled down over here. I'm currently involved in three projects with three different customers so I'm a bit choked right now. Things are clearing up, however, so there will be some time over soon.

        Regards,
        Greger Ohlson

         
        • Rainer Bischof

          Rainer Bischof - 2001-05-07

          Greger,

          following a few thoughts of mine of what I would like to see in the object communication enhancements:

          Server Integration: Plugging an XmlRpcInvocationProcessor into it is a really simple way.

          Client Integration: A modified XmlRpcProxy should do it. It can recreate the returned object and can throw exceptions (see below). I would guess that the proxies are the preferred way of using this stuff anyway since they make life much easier :)

          For both sides we need a slightly modified ReflectiveSerializer.

          Regarding the exception handling:
          What I don't like about server side exceptions is that the information about the exception type is lost. What do you think about returning a fault string in a format like "ClassName: Message", e.g. "java.sql.SQLException: Session timed out" or so? This is not really a deviation from the spec since it is just a more detailed exception description.

          This would enable the mentioned Proxy to look into the fault struct and re-throw the same exception at the client side, thus fulfilling the interface implemented by the proxy also in error conditions.

          Taking this into account I would propose to introduce an XmlRpcIOException that is thrown if a communication error occurs instead of the IOException. The reason is that in case a communication error occurs in a server side method that can itself throw an IOException we cannot distinguish between both exception sources (XmlRpc communication or exception thrown by the method).

          Since communication exceptions can occur in each remote method call I would also like to see the Proxy to require each method in the implemented interface to throw this XmlRpcIOException.

          On the server side we could support automatic service binding, e.g. server.bind(Object serviceProvider). That method checks for all interfaces implemented by the serviceProvider object and binds it for all interface names. This would probably reqire the introduction of a new tagging interface XmlRpcService to tell which interfaces of the serviceProvider should be made available.

          Regarding the exception handling in general: You have a dedicated writeError-method that writes the response. What about changing this to a model similar to the normal handling, something like Exception Serializers. That way the response would also be pluggable.

          OK, thats it for now :-)
          I think I can do some of the object stuff to let you guys concentrate on the core functionality.
          I will build the following and provide it to you in the next few days so that you can have a look at it:
          A new ReflectiveSerializer that includes the classname, a modified XmlRpcInvocationProcessor that rebuilds the object on the server side, a modified XmlRpcProxy that rebuilds the object on the client side and throws appropriate exceptions. For that to work I will also have to modify the writeError method to include the exception's classname.

          Beside the last modification all of this can be in a separate package, making it a cool extension to your stuff.

          Cheers
          Rainer

           

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.