The IProcess is the interface that all processes that we wish to delegate their execution to ISS must implement.
Has you can see in the JavaDoc documentation it is a very simple interface. It simply declares a single method, execute.
public ProcessResults execute();
This method will be invoked by the ISS when it decides to launch the processes into execution. It takes no parameters, since they're not necessary.
The execute method must return an object of the class ProcessResults with a compiled result of the executed process.
All process execute some task. Nearly all of them have some feedback to give their caller. This can be a simple success of failure info (like a boolean flag), but more often than not a more detailed feedback is needed.
ISS provides a generic and flexible class to this need. The ProcessResults.
Let's for instance say that we needed to create a bunch of files on disk. These files would be created by a complex algorithm that would operate on external inputs that would determine what would be written to the files and even what would be the file names that would be created.
In this situation we would probably wish to receive the following return feedback:
Lets see a quick code sample of how we could do this with the ProcessResults class:
(...) // The file handler File outputFile; // The bytes written counter Long bytesWritten = 0L; (...) // After the execution, let's assume that outputFile has been // instanciated and contains the just created file! ProcessResults results = new ProcessResults(); results.setOnError(false); results.setResult("FileName", outputFile.getName()); results.setResult("TotalBytes", bytesWritten); results.setResult("FileObject", outputFile); (...)
We can see that it's very simple to use the ProcessResults for any kind of return data we want to return. The ProcessResults is basically an object that contains an error flag, and a MapString, Object that can contain any list of objects identified by a key string.
If these objects are simple or complex, if they contain for instance other Collections as the value, well, that's up to you.
In this example we return:
How could we get these values from the ProcessResults object? For instance...
File theWrittenFile = (File)results.getResult("FileObject");
When we delegate execution of a process, by means of the delegate method (more on this later on) we expect some response in return. We could say we should receive the results of the execution of our process. A ProcessResults object like the one we have seen just now.
But we don't! Why? Because since ISS manages the execution of our process, it can decide that it cannot execute it immediately and so schedule it for later execution.
What then would be returned to the caller? A null result?
ISS addresses this by always returning a ServiceRequest object.
The ServiceRequest class encapsulates a set of information about the request we just issued to the ISS:
As you can see ServiceRequest contains much more information than just the results. It has relevant information even if there are still no results to be obtained.
We will see later on this section how we can monitor ISS constantly by asking for an updated ServiceRequest object for our process.
The ISSManager is were all starts.
The ISS instances must be instanciated, managed and given to the callers when asked. They have common needs, like logging. All this is the task of the ISSManager.
ISSManager is a static class that is used to get/create ISSs. We can have one ISS instance for managing all of our processes, or we can have several ISSs instances each dedicated to specific kind of processes, tunned is a specific way. This is up to the client application. ISSManager just provides what it is asked for.
Simply call the getISS method.
synchronized static public ISS getISS(String id); synchronized static public ISS getISS(String id, Properties configuration);
You can get more info on the parameters and return types from the JavaDoc, but for what matters here you ask for an ISS by giving an identifier string.
Each ISS is identified by an ID string. When ISSManager is asked for an ISS with an ID it does not know, it creates a new one. It is as simple as that.
You can see that we have two sets of parameters overloaded in the getISS method. One simply needs the ID, the other receives an additional Properties file object. This object will be searched for entries that will be used to configure the ISS regarding how it will manage the processes it will be delegated. Basically this is how we can tune ISS.
At the end of this section you'll find a more detailed explanation on how to do this. So please read on. For now we just acknowledge where we can pass tunning information to our ISS.
A little detail that can be relevant. ISS is prepared to use a given logger instance. If one is not provided, the ISSManager will create one itself and pass it to all ISSs it will manage. ISS logs some info, for instance the performance stats periodic log (at INFO log level), so a Logger is mandatory.
Note: The logger stated above is an instance that implements ILogWrapper interface of the Logger library. See the Logger site for more information.