Turbine <[EMAIL PROTECTED]> wrote:
First off, I'm grappling with this design as much as everyone else,
I'm trying to push this issue forward so we can keep moving. It
seems to me that we've stagnated in some areas(and a lot of
folks are busy).
This Services design was put forth by Brett McLaughlin, so I'll try to answer the best
I can.
> Okay, no help so far, so let me try another question. What is the purpose of
>init(Object)?
To pass any (if any) information needed on to the Service and
also check that the Service is ready to do what ever it is expected
to do by checking the isReady flag. In the example of lets say
a Webmacro Service you would pass the RunData object to init(runData)
and it would check to make sure the Template engine is ready, etc...
Since it seems you are supposed to call it prior to execute(), does it do something
everytime it is called?
Yes. The above.
Does the service init after it is first instantiated and any further calls to
init(Object)
are ignored?
No. A Client should always call init() - execute(). However
the service developer could have a service the does some one
time initialization on the first call but should always at a minimum, check the
isReady flag. Let's say I create an Object pool. In the init the client passes the
object to pool. My init would first check to see if the pool is started (isReady)
then maybe check to see if
this is the proper type of object for the pool (instanceof) and then
forward the object to the actual execute.
Or is it expected that any object calling init(Object) will
reinitialize the service?
I think this is up to the developer of the service. The main thing
is that the client fulfills the contract by always calling:
init()
execute()
And the service always check the isReady flag, etc...
Does a service that allows many calls to init() need to track the calling object, so
that it can be in the right state when
execute() is called?
Again, I think this depends on your Service. Does your Service return
a Service object (like Connection for a DBPool) OR is the Service
return a manager. As another example, think of the scheduler service. On the first
call to init(o) check the scheduler
thread is running. Then, forward the object onto the execute an
do what's needed (e.g. queue the job, run it, etc.).
The idea is the client only needs to :
1. Get the TurbineServiceProvider
2. Get the Serice by name
3. call init(myObject)
4. call execute()
The Service developer needs to grapple with the other issues
that are unique to his Service.
Why don't objects call a method execute(Object), if the service is not
initialized it does so before performing the execute?
PLEASE look at Brett McLauglin's retionale for this in his e-mail
on 25 Jan and in the "huge" post I put out a couple of days ago.
I hope this ( is coherent and ) answers some of your questions. I think the overall
main
goal of this design is to standardize how a client interfaces with
a Service. This then allows us to do XML-RPC, Remote Scheduling, etc...
dave
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
