> Brett McLaughlin [[EMAIL PROTECTED]] wrote:
> > 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...
> >
> Okay, based on this, would it require something like this?
>
> public class XmlRpcService extends TurbineBaseService {
> public ??? execute(String serverURI, String methodName, Vector
params);
> }
No.... you would either do....
TurbineServiceManager.getInstance()..... // do whatever else you want
OR
TurbineServiceManager.getInstance("somehost.com").... // do whatever else
you want.
The getInstance() to a String would return an instance or
XMLRpcServiceManager (or something like that) which of course you wouldn't
know about as a client (casting, polymorhphism, whatever).
The main point here is that "do whatever else you want" would be identical
in both cases. It is just that XMLRpcServiceManager or whatever would
"behind the scenes" be massaging your input into RPC calls.
Now as an option (and more along what you were saying) it is possible you
could define services that extend from XMLRpcService which extends from
BaseService (there would actually be several interfaces here, but we are at
a higher level than that for now), and they _always_ result in XML-RPC
calls. Again, no difference to the client, in that case it would be in the
getService("servicename", "somehost") where you would request/specify that.
But that's not as clean, because now the services contract gets a little
screwy, and non-XMLRpc services have to add this method that is never used.
I like the idea of the TurbineServiceManager handling it all myself, so you
can write your services (the method declarations, etc) fairly ignorant of
what method of calling is used.
And yes, I don't have all this on paper, so I am "walking" through it with
you and inventing as I go. I am happy to help work on it with you... I also
am working on Cocoon integration, though, so my time is stretched (ain't
that always the case ;-) )
>
> If so, then I don't know what the method will return. The raw XML
response?
> This is where that "handler mapping" arose. A hashtable of
methodName/className
> pairs so that execute() would know to instantiate MyClass if methodName is
> "MyClass.doSomething". I don't know if this is the proper way to do this.
I'm
> only starting with this idea, because that's how the library (that I
> mentioned in my previous message) does it. Suggestions?
To the client, XML-RPC requests or responses should never happen - the
service manager and/or service should always do the conversions to keep
things loosely coupled.
-Brett
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
