Brett McLaughlin [[EMAIL PROTECTED]] wrote:
> > How about something more like this:
> > Vector params = new Vector();
> > params.addElement("someParam");
> > XmlRpcServiceManager xrsm =
> TurbineServiceManager.getInstance("somehost.com");
> > Object result = xrsm.execute("doSomething", params);
>
> Almost... I see more...
>
> TurbineServiceManager sm =
> TurbineServiceManager.getInstance("somehost.com");
> Object result = sm.getService("complex_service").execute(params);
>
> The two notable changes:
> (1) The client doesn't know he is getting an XML-RPC service manager (it
> would have to extend TurbineServiceManager of course...), so it is not
> specific to XML-RPC or a local service manager.
> (2) The execute() is called on a service returned from the service manager,
> not the service manager itself. In this case, service manager would tell
> decide if the service requested was a remote or local service; if remote, it
> would pass on any neccessary information when instantiating the service, and
> return it to the client. Then the client does execute on the service, which
> may (or may not) do XML-RPC. The result is returned to the client. The
> idea here is that you could easily define both local and remote
> implementations of a given service, and plug them in and out with simple
> properties file changes.
>
> Make sense?
>
Yup, sure does. (I wondered about that additional layer of abstraction.) I'll
try to flesh out some code this weekend so we have more to go on.
Some implementation questions:
- Is a Vector fine for the params or should it be a dedicated class?
- Should TurbineServiceManager be a replacement for the current
TurbineServices? If so, I'll need to add execute() to Service and
potentially break NamingService.
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
