Brett McLaughlin [[EMAIL PROTECTED]] wrote:
> In light of the increasing amount of services, I make the following
> proposal for service redesign. Hopefully this starts to give people an
> idea of what I have in mind for Turbine 1.0 final, or even 2.0. This is
>
I don't see any reason why we can't implement these changes ASAP after
discussion. Sure, we'll have to fix minor breakages with existing services,
but that's nothing insurmountable.
>
<..snip..>
>
> Redefinition of the Service interface:
>
> public interface Service {
>
> public void setName(String name);
>
> public String getName();
>
> public void init(Object ob);
>
> public Object get();
>
> public boolean execute() throws ServiceException;
>
I understand the distinction between get() and execute(), but is it
implicit that for some services one of these methods might do nothing? For
instance, a JDBC Connection service has no identifiable "execute" behavior.
Therefore, would a call to execute() always return true (after checking that
the service was properly init()-ed, of course)? Would we require that a
connection service user call execute() even if has no substantive result?
>
<..snip..>
>
> No big deal, you still don't see, right? But what if the scheduler is
> distributed, and on another machine? Uh.. oh... but no big deal,
> because the client doesn't request an implementation of a _sepcific_
> service, they request an implementation that conforms to the generic
> _service_contract_!! This means that we can return to them an
> XMLRPCService class, which implements Service, and give it the
> information (in TurbineServiceManager) to know how to send the type of
> XML-RPC that the Scheduler Engine, on another box understands. So when
> you call execute, you aren't _really_ invoking execute() on
> SchedulerService, but rather on XMLRPCService, that constructs an
> XML-RPC call, sends it across the wire, and invokes execute() on
> SchedulerService somewhere ... all unknown to the client because he is
> using a generic Service interface, not casting to a sepcific Service
> implementation.
>
Something, somewhere needs to have the intelligence to format an XML-RPC
request for a specific service. Given the above scenario, it sounds like
XMLRPCService has far too much knowledge about the particulars of the
Scheduler Engine. Can you provide a more detailed description of this
example? Here's my guess:
*) services.properties file contains an entry like:
service.scheduler=org.apache.turbine.services.RemoteSchedulerService
*) RemoteSchedulerService extends the abstract class XMLRPCService, adding
the specific knowledge required to call a Scheduler Engine residing on
a remote host (whose URI is contained in services.properties).
*) XMLRPCService encapsulates the XML-RPC un-/marshalling required to
call the remote procedure by declaring some abstract methods that
provide procedure name and arguments.
Yuck, that seems ugly. What if XMLRPCService just read the procedure
names/args from the properties file? Then you wouldn't have to create a
new class every time you wanted to make a remote call. Okay, now I think
I'm beginning to understand XMLRPCService.
> So this is beatiful for us ;-) We have TurbineServiceManager read in a
> services.properties file (yes, seperate, because it may be on machines
> that TurbineResources.properties is not), and at service request
> (getService(serviceName)), determine whether to return the actual class
> for a given service, or the XMLRPCClass, or a ProxyClass, or an
> SSLRequest class, or any number of intermediary services that add
> advanced pre- and post- processing to service behavior. All using our
> nice simple little properties file ;-)
>
Maybe it's still too early, but could you give some example properties file
entries (esp. for XMLRPCService)?
> Examples:
>
> Using SchedulerService across the wire via XML-RPC...
> Getting a URL that is SSL protected with SSLService... (lame, but an
> example still)
> Changing a data store from a database to LDAP without the client
> knowing... (no casting to JNDIService vs. ConnectionService!)
> <scott-pay-attention-here>
> Getting a DOM layer over a SAXparser service for handling class maps if
> one is needed.
> </scott-pay-attention-here>
>
> So what do you all think?
>
I think you rock!
> -Brett
>
>
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
