> Hi, all. I'm in the process of evaluating XML-RPC for a new project. I'm
> wondering if anybody else has looked at XML-RPC to see how it might
integrate
> with Turbine, and more importantly whether it should.
Yeah, I've looked at it, and we will be using it (at least as an option) for
distributing services within Turbine (oh, if only I had time to do all this
...)
>
> An example scenario in Turbine:
> Components:
> - XmlRpcServer: singleton that manages handler mappings and execution
> - XmlRpcScreen: a Screen that uses XmlRpcServer to execute the XML
> method-call it receives via the HTTP request
"Handler mappings"? what exactly do you mean?
And this shouldn't happen on a screen, it should happen within an action.
Screens should be output oriented, while actions should be logic-oriented.
We will have a TurbineServices.getInstance() that will eventually take a
parameter for another server. The services class will then turn any
requests to that instance into XML-RPC and pass them to a remote machine for
processing, such as comlpex equations, etc. It will all be behind the
scenes, though, so the action will never explictly create an XML request.
It shouldn't have to use a local or remote service differently than the
other. Uncoupling here...
>
> Process (after authentication):
> 1. Turbine receives a request for XmlRpcScreen.
This is not good. Turbine should not care if XML-RPC, RMI, whatever it
being used, other than an initial getInstance call where a remote server can
be specified (or handled in the properties file, even better). After that
it does things the same as if it were local calls. That's the whole idea of
remote objects and services - encapsulation.
> 2. XmlRpcScreen gets a reference to XmlRpcServer.
This would be an action... why generate output remotely?
> 3. Upon instantiation, XmlRpcServer retrieves the handler mappings from
> TurbineResources and adds them to its internal hashtable.
what handler mappings? what is it handling?
> 4. XmlRpcScreen calls XmlRpcServer.execute(data.req.getInputStream()).
All
> logic for parsing the XML method-call and executing the handler are
> encapsulated within XmlRpcServer. (For more details, see the class of
> the same name in the "Library for Java". See "References" below.)
No, no, this is high overhead. Here's what would happen in that case:
1) Generate output (HTML, whatever)
2) convert to XML to return via XML-RPC call
3) receive XML return
4) convert to HTML from XML
5) output
Lots of overhead, and you end up with the same format. XML-RPC is great for
getting results of complex tasks, not for doing output.
> 5. XmlRpcServer.execute() returns a string (i.e., the response XML doc),
> which XmlRpcScreen passes back to the client after setting a few
> headers.
See above - it would have to be XML return, or escaped markup (you can't
pass normal HTML in XML without some tricks) that you still have to convert.
>
> Basically, the screen class would work like jon's new ImageServer screen,
and
> the server class would be an amalgamation of the existing java library.
From
> an implementation stand-point it shouldn't be too difficult. However, I'm
> interested in opinions on the appropriateness of such an endeavor. Does it
> make sense to put this in Turbine? Are there potential problems I'm not
seeing?
The potential problems are above. The concept (using XML-RPC) is sound, but
the uses you are suggesting are not. Also, I think you need to look more at
actions, which handle logic rather than screens.
>
> Thanks in advance for any and all opinions.
-Brett
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
