Dave wrote:
>
> Brett McLaughlin wrote:
> >
> >
> > Service service =
> > TurbineServiceManager.getInstance().getService("scheduler");
> > // Set up a new event and start the process of execution (timer)
> > service.init(myNewEvent);
> > service.execute();
> >
> > 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_!!
>
> I just want to be clear. Are you saying then that *all* calls to a
> Service
> will be through:
> service.init(myNewEvent);
> service.execute();
>
> So for example, updating, adding, and removing JobEntries should be
> completely hidden
> to the client (i.e. all they see/care about is init and execute)? If
> this is so, then
> shouldn't the objects you pass in init() need to be a type of Command
> (then a Service is really a
> kind of Command Manager).
It shouldn't be a command, but an Object parameter. Typically a service
handles only execution of some task... The Scheduler is a bit different,
so we may have to stretch our "imagination" a little bit. Usually, a
service does *something*, and the Object parameter doesn't specify
*what* that thing is, but gives the *what* information about *how* to do
it. For example, a scheduler executes events. So the init() parameter
would let it know things like what event to execute, or perhaps how long
to wait between events, whatever - information needed to execute events.
Now in your case, you want to add/update/remove entires in the
Scheduler. Now for remove, I am amicable to adding something like this
to the Service contract:
public void release(Object ob);
which would be a counterpart to get(). I don't like remove() because it
implies that the service is trashing a resource; this is the situation
for you, but I can see release() being used for letting go of
connections, returning a JNDI context to a pool, etc. So that's one
down, right?
I am a bit torn on:
public void set(Object ob);
-or-
public void add(Object ob);
If you can come up with 3 cases of services where that would be used, I
am OK with adding it in. That is my benchmark; if there are 3 times it
can be used, it makes sense to add it; less than that it is too specific
to be in a generic contract. add() could also be your update, as you
check for a name/id of an event and either add/update.
Getting closer?
>
> I also find - service.init(Object) - a little confusing. To me
> init(Object), "sounds" like ( I know it's not your intention) you're
> initiating the service with some possible parameters. To me it seems the
> execute() should actually be passed the "thing" to operate on.
See my comments - execute() may not need anything to operate upon, so
why force those who don't (like connection service or ldap manager) to
pass in a dummy object? i like execute() with no parameters.
-Brett
>
> That's just my .02. Otherwise this is great stuff. As soon as we've
> all decided on it, I'll jump in and
> switch the scheduler over.
>
> dave
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
