Brett McLaughlin [[EMAIL PROTECTED]] wrote:
> > 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
> ...)
>
Thanks for the feedback. Comments below.
> >
> > 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.
>
By "handler mappings" I only meant the object/process/whatever that responds
to the XML-RPC request. I was treating the resulting XML of the XML-RPC call
as "output".
As far as screen vs. action goes: Instead of the Screen sending HTML output, it
would write the XML directly to the output stream. No XML<=>HTML conversion. I
agree that an action would be more appropriate, but I didn't think (and I
didn't look too closely) that you could have an action that wasn't followed
(at some point) by a screen.
> 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...
>
I recognize this as a fundamental flaw in my example - I assumed that Turbine
would be processing the XML-RPC calls (i.e., that it wouldn't be relaying them
to a remote process). I agree: this is a bad idea. Turbine shouldn't know or
care whether the XML-RPC server is local or remote. And it definitely shouldn't
presume that it handles all calls it receives.
> >
> > 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.
>
I agree. Turbine should really only act as a client/relay for remote
processing. In other words, make calls to a (logically, not physically) remote
server and format output based on the response.
> 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.
>
Okay, I admit it, my plea for advice was a bit disingenuous. I knew that my
example scenario had some fatal flaws. I was hoping somebody would shoot
holes through it so I wouldn't get lazy and do things the "easy" (albeit wrong)
way. Thanks, Brett. Also, I wanted to get discussion going on how this
would/will be implemented. I am interested in adding support to Turbine for
making/passing calls to XML-RPC (etc.) servers. I'll take your suggestions and
come up with some more hair-brained ideas.
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
