Brett,
Turbine gains more and more services seemingly every day (e.g., Scheduler,
OPaL ClassMap loader). If time permits, maybe you could give us more details
on your thoughts regarding the services model before we have too many
implementations dependent on a possibly-to-be-deprecated API. We discussed it
briefly in the context of XML-RPC but held off any coding at the time. Maybe
it's time to start making some of those changes you mentioned, if indeed they
still need to be made.
--
Christopher Elkins
--
Portions of the relevant thread (somewhat out of context) for those who
forgot, didn't care, or just weren't here at the time:
> 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 ;-) )
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
