Here's a wrap-up of the discussions in the past concerning
services. Please take a look at it, make comments, and VOTE so we
can move forward in this area.
I've added in some comments from past postings to help understand
the rational for each area.
//Here's the interface that all services must implement:
public interface Service {
/**
* This will allow the name of a Service <b>instance<b> to be set.
* These names should distinguish an instance across the
* complete namespace of services in any given JVM. In other
* words, it is the programmer's, or the service loader's,
* responsibility to assign these unique names across instances
*
* @param name - String name of service
*/
public void setName(String name);
/**
* @return the name set above
*/
public String getName();
/**
* This method allows a single object parameter to be handed
* to a Service. Because different services will handle
* different objects, this is kept intentionally vague.
* Within this method, the <code>instanceof</code> Java
* construct should be used to ensure the correct type
* of object is passed in for a specific service. If so
* the object should be saved to an appropriate member
* variable and the protected member variable/flag
* isReady should be set to true. This will later be
* used by the <code>output()</code> and
* <code>execute()</code> methods to see if it is OK to
* output/execute the Service. No exception should
* ever result here; if the object is not the right
* type, just don't set the flag to true. This could
* be called multiple times, so don't kill the process
* on incorrect parameters.
*
* @param ob - Object parameter for Service to use
*/
public void init(Object ob);
Why the object passed in the init as opposed to passing it in the
execute() ?
> You can achieve this same thing with init(Object ob) and then
> execute(). I don't want to have to know which is the appropriate
> execute() method to call depending on the service type. That means
I
> can't dynamically load/run services, because I have to figure out
the
> type to see which execute() needs to be run; the one with the
parameter
> or the one without. As long as you always all init(), and always
call
> execute(), you're all set.
> 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.
/**
* This is the executable portion of a service. For a scheduler,
* this would start the event timer; for a parser, it would begin
* parsing of, say, a ClassMap ;-) You get the idea...
* The first thing this method must always do is check the isReady
* flag (@see init()); if it is not true, the
* <code>ServiceException</code> should be thrown signifying things
* aren't ready to go. If this particular service implementation
* does not need any object paramters, <i>still check the flag!</i>
* The <code>init()</code> method in that instance will simply set
* the flag to true. This makes these portable and the
* implementation
* very straightforward. This should return true if everything
* executed, else false. Note that a false return signifies that
* the
* <b>execution</b> failed, not that the intended result was not
* reached. For example, a LoginService that finds out a user's
* credentials are incorrect would return true because it completed
* its task, even though the outcome wasn't what the user wanted.
*
* @return boolean - true if all OK, else false
* @throws ServiceException - if not ready to execute, or errors
occur.
*/
public boolean execute() throws ServiceException;
/**
* Used to retrieve an object from the service.
* For example in the case of the Scheduler I can return a previously
scheduled job.
public Object get();
/**
* Set/Add/Update an Object in the Service.
* For example in the case of the Scheduler this would be a new or
* updated scheduled job.
public void set(Object ob);
*** WOULD set(ob) BE BETTER AS add(Object ob)? ***
/**
* Release a resource. Maybe a Connection, Context, Pool, etc...
*/
public void release(Object ob);
/**
* This method completes the lifecycle. When a service is shut down,
* trashed, etc., this handles closing any open resources,
* doing basic due diligence.
*/
public void destroy();
}
Here's a simple example of how a client might use a Service:
Service service =
TurbineServiceManager.getInstance().getService("scheduler");
// Set up a new event and start the process of execution (timer)
boolean success;
//Run the job NOW
service.init(myNewEvent);
try
{
success = service.execute();
}
catch(ServiceException ouch)
{
//Somethings is NOT right!
}
if ( success )
{
//I did my job!
}
else
{
//I'm a failure!
}
If you still need more information. Hit the mailing list archive and
look
for Brett McLaughlin's postings dated 25 Jan 2000.
dave
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
