An objective of the TaskBean API is to provide an easy to learn and implement API for developing reusable server-side components. The API requires little effort to learn and imposes very little restrictions on a developer. Virtually any piece of Java code can be wrapped into a TaskBean. The goal of the TaskBean API is to provide a thin wrapper around any Java code, such that it can then be interconnected with other TaskBean components and then executed within a server or container.
A TaskBean can be as simple or as complex as a developer chooses. It can be as simple as a single println or as complex as thousands of lines of number crunching and database calls. The developer also has the option of defining the input and output properties of a TaskBean (note, that this is optional). This is done using standard JavaBean properties. Again no new api to learn. The JavaBean input/output properties allow TaskBeans to expose and exchange data between each other if and when they are chained together with other TaskBeans.
TaskBeans can be connected together to form more complex entities called Jobs. A Job can be composed of one or more TaskBeans. The Job functions as the outer execution wrapper for the TaskBeans it contains. When the Job is passed to a Container for execution, the TaskBeans it contains are executed based on how they are connected together within the Job. TaskBeans can be configured to execute in serial order (one after the other) and/or can be defined to execute in parallel or a combination. The diagram below gives an example of some possible TaskBean execution graphs [to do].
GUI tools can be used to compose and interconnect TaskBeans to form a Job. So this is not the responsibility of the developer, but that of a less technical author or composer. An XMLSchema (to do: provide link) is used to define how the TaskBeans are aggregated and interconnected. Job execution containers can use their own internal format to define how TaskBeans are composed but the XMLSchema format is the externalized format for portability across containers. The rules for how a Job and its TaskBeans are executed are also defined in this XSD. This includes things such as what a Job/TaskBean should do if it encounters errors while executing.
A TaskBean Container is defined to be any process that can execute a Job according to the TaskBean specification. The Container can be a command-line tool, servlet engine, J2EE server of some form, or any other Java process. There is no restriction.
The Container is responsible for managing the life cyle of a Job as it executes and performs all TaskBean I/O communication. The life cycle of the Job can be configured to define how the Job (and corresponding TaskBeans) deal with errors. A Job can be configured to terminate processing if any one of its TaskBeans throws errors. This would halt all TaskBean processing and terminate the Job. If a Job is configured to ignore TaskBean errors, then even if a TaskBean fails, all proceeding TaskBeans will still continue to execute within the Job.
A user composing a Job out of TaskBeans is not necessarily the developer of the TaskBeans. Keep in mind also that individual TaskBeans can be developed independent from each other. The TaskBeans that make up a Job don't need to know anything about each other. For example, a Job might be composed of one TaskBean that performs some accounting functions, which is followed by a simple email notification TaskBean that sends an email. The TaskBeans in this example need to know nothing about each other and they exchange no information.
Now to demonstrate how TaskBeans can exchange information without prior knowledge of each other, consider this example of a Job that is composed of three TaskBeans. The first TaskBean gathers website statistics and formats them into a tabular form and puts them into a file. This statistics TaskBean will expose a JavaBean output property as to where the file it just generated resides (each TaskBean has a directory sandbox where files can be created and accessed). The next two proceeding TaskBeans, are an email TaskBean and ftp TaskBean. They each will run one after the other. They each can read the given file from the filesystem and transport that file accordingly. They need to know nothing about the statistics gathering TaskBean; they only expect to receive information as two where a file is. They each have an input JavaBean property, that when set, tells them where the file of interest resides that they can email or ftp.
An objective of the TaskBean I/O specification is to keep the mechanism simple, but as effective as possible. The I/O mapping between TaskBeans is all done in Java and in large part based on the Java Reflection Data Conversion rules: Wrapping and Unwrapping Conversions and Widening Conversions. In addition, the TaskBean I/O specification allows for some additional conversion rules.
For example, when a user is configuring two TaskBeans to work together, all that needs to be done is to connect the output property of one TaskBean to the corresponding output property of the other TaskBean. If the properties are compatible, based on the conversion rules defined above, then the hosting container will perform the conversion and assign the new input property as the Job and TaskBeans are run.
If the user wishes to perform special transformation and conversions between two TaskBeans, then customized conversion TaskBeans can be placed between the two TaskBeans to perform the necessary conversion (using XML/XSLT or whatever mechanism desired).
A TaskBean's associated classes are packaged into a JAR format using a structure that will be defined in detail here. The packaging allows all the software associated with a TaskBean (including necessary third party libraries) to be put into a compact JAR, with some supporting meta data, that a TaskBean Container can execute.
The input JavaBean properties of a given TaskBean can, be edited using a GUI, if one is provided. The TaskBean can choose what properties to expose for manual editing by defining a GUI for the given TaskBean. An editing tool will be created as part of the reference implementation to demonstrate this.
Jobs are executed within a secure sandbox environment. The security settings follows the standard Java security model. The security settings are applied at the Job level. In this way a Job administrator can control what rights each Job can have within the container. The security settings are enforced by the hosting container. Note, that security is an optional requirement for a Container to support.
Each Job is given a directory sandbox where it can read and write. There is a directory that will persist across Job runs and another directory that will only be present for each unique Job run.
JobRunner is an open source reference implementation of a TaskBean Container (servlet and command-line versions). Check the JobRunner sub project for details.
JobServer is a commercial implementation of a TaskBean Container. A developer version is available for free download. JobServer provides tools for managing and running TaskBeans and Jobs.
Repository of general purpose TaskBeans developed by open source community. Check the BeanSoup sub project for details.