> 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.
Yeah, and some of that is in projects I work on at work, and not yet
committed to Turbine. (bad me...)
>
> 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.
Ummm.... I would let the parameter into an execute() type call always be of
type Object. That way we can define a generic service contract that doesn't
have to be service-implementation dependent. Then the individual services
have to check (using instanceof or something similar) if the object passed
is is the approprtiate type, and throw an exception if not (again, the
contract can define this, like IllegalArgumentsException).
I'll try and look into TurbineServiceManager vs. TurbineServices this
weekend.... I am mixing my projects' at work's terminolgy with Turbine...
but really, I tend to think TurbineServiceManager might be a better name, as
it is more descriptive of what it does. What do you think?
-Brett
>
> --
> Christopher Elkins
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
