JobServer FAQ


Product Questions:

  1. Is JobServer a web server or EJB Server and how does it relate to J2EE?
  2. Is JobServer a J2EE application server or can it run in a J2EE application server?
  3. So do I have to learn and develop to a whole new set of Java APIs to create Jobs/Tasklets?
  4. How does a Tasklet relate to Sun's JavaBeans and EJB APIs?
  5. What is the relationship of a job to a Tasklet?
  6. Is JobServer a workflow processing type system?
  7. How many jobs can be scheduled to run at any point in time?
  8. To what degree of scheduling accuracy will a job run?
  9. So JobServer uses a database for persistence, what happens if the database crashes? Will jobs still run properly?
  10. What is a Partition?
  11. Can JobServer scale across a cluster of host machines?
  12. Does the JobServer scheduler have support for failover?
  13. Can I load balance job processing across a cluster of machines?
  14. Is JobServer centrally upgradable?
  15. Can I run jobs (when deployed on Linux/Unix) under unique OS user names?
  16. Can I run web reports that will predict when future jobs will be scheduled to run?
  17. Can I move/import/export jobs between multiple JobServer environments?
  18. Can jobs be killed after they have started running?
  19. If a job does not run (due to system down time or system failure) can I configure a job to have an expiration period after which it will not run for that scheduled time?
  20. How do I know if a job had problems while running?
  21. If I develop jobs and Tasklets will I be locked in to your product (JobServer)?
  22. How difficult is it to develop a Tasklet?
  23. How do I access the various JobServer applications and tools?
  24. How easy is it to monitor overall system usage and performance?
  25. Why don't I just use a commercial J2EE appserver in place of JobServer? Don't App Servers already do load balancing, distributed computing, EJB, ...etc?
  26. Can I only use Java to develop my Jobs/Tasklets?
  27. How are Tasklets chained together to create Jobs?
  28. Why is XML not used to define Tasklets inputs and outputs?
  29. What is JobServer's relationship to Web Services and other messaging standards?
  30. How do Tasklet inputs and outputs work?
  31. How do you make new Tasklets available to JobServer?
  32. How does JobServer and the Tasklet API promote software reuse?
  33. How does JobServer relate to grid computing?
  34. How does JobServer relate to open source sandards and technologies?

See JobServer's Feature Summary page for information on product capabilities.

See Troubleshooting Questions



Product Questions/Answers:

  1. Is JobServer a web server or EJB Server and how does it relate to J2EE?

    JobServer leverages J2EE technologies but is not an EJB container. It uses a web server as a part of its application architecture. jobs developed with JobServer can easily connect and communicate with EJB containers using RMI, COBRA, JMS, or Web Services.


  2. Is JobServer a J2EE application server or can it run in a J2EE application server?

    No it is not a J2EE app server nor will it will it run within a J2EE app server. Today's typical application servers are geared toward a particular form of computing. This typically centers around hosting large volumes of user initiated transaction processing of one form or another and often in a "stateless" type of computing environment.

    JobServer leverages J2EE but provides its own container that is geared toward time management, detailed tracking and management of job processing, and overall engine state management. From how JobServer uses persistence to how it starts up and shuts down has been carefully designed to meet the needs of a highly reliable and scalable job processing engine. Even the JobServer developer API, called the Tasklet API, avoids the complexities of J2EE. Developers, developing new jobs have a very simple yet expressive API from wich to create component based Java software, without the complexities of J2EE, yet they are free to use any part of J2EE that they wish.


  3. So do I have to learn and develop to a whole new set of Java APIs to create Jobs/Tasklets?

    To develop new Tasklets requires using the opensource Tasklet API. The is a relatively simple API to use. In its most basic form, a developer only needs to implement one Java interface, and package the code into a JAR file. The rest of the work is GUI driven and be customized by a non-programmer using the tools available in JobServer.


  4. How does a Tasklet relate to Sun's J2SE JavaBeans and EJB APIs?

    Tasklets leverage J2SE JavaBeans to expose properties. JavaBeans are used to optionally define the inputs and outputs of a Tasklet. EJB API has no direct relation to Tasklets. Tasklets can make calls to an EJB container using RMI or Web Services for example.


  5. What is the relationship of a job to a Tasklet?

    A job can be composed of one or more Tasklets. Tasklets can be chained together in a workflow. They execute one after the other and can pass properties to each other. Passing properties between Tasklets is optional, and they can be configured to do so using GUI tools and without the Tasklets having any prior knowledge of each other.


  6. Is JobServer a workflow processing type system?

    Yes it has some features of what can be classified as workflow. Workflow is a broad concept and can have many meanings. Using JobServer, non-programmers can compose jobs from basic Tasklet components and schedule them for execution. JobServer offers extensive tools to allow users to track and monitor jobs before, during, and after they run, including notification features to alter the user of errors or failures.


  7. How many jobs can be scheduled to run at any point in time?

    JobServer can scale to handle tens of thousands of jobs running concurrently. It is designed to scale with the hardware it runs on. It can take advantage of machines running dozens of CPUs. Advanced scanning and caching algorithms allow JobServer to execute a very large number of jobs with a high degree of precision and concurrency while taking full efficient advantage of system resources (like multiple CPUs).


  8. To what degree of scheduling accuracy will a job run?

    JobServer executes jobs using a highly optimized scheduling design. If you have an environment where hundreds or thousands of jobs may execute simultaneously, JobServer is designed to handle this. It uses an advanced multi-threaded scanning algorithm to launch jobs as soon as they are ready as defined by the system clock, while using a minimal amount of system resources.


  9. So JobServer uses a database for persistence, what happens if the database crashes? Will jobs still run properly?

    JobServer uses a relational database to manage its persistent date. It also uses database transactions to insure a degree of transaction integrity of its many operations. This offers a degree of reliability and scalability. If the database where to crash or be shutdown, JobServer will attempt to reestablish contact until the database is returned to a proper running state or the JobServer environment is itself shutdown. The bottom line is that the JobServer environment is designed to be resilient in the face of database problems. Also if a job fails or throws an error, you will know about it. JobServer offers great tools for tracking how jobs run and offers notification features to quickly alert the proper people.


  10. What is a Partition?

    It is a way of segmenting a JobServer into multiple resource pools and managing those resources. Each Partition can be throttled to control how many jobs can be run simultaneously. It is also way to mange other resource like external databases. Say you have a set of large reporting jobs that all use one particular database. You don't want too many of them simultaneously running, so if you put them all into one Partition you can control how many run at any one time against that particular database.


  11. Can JobServer scale across a cluster of host machines??

    Yes you can run JobServer in a variety of configurations from simple configurations on one single computer to deploying JobServer across a cluster of hundreds of computers while still having centralized control and management over the job scheduling and processing environment. JobServer scales out at every level from the job processing, job scheduling and web applications layers. You can deploy JobServer to run on a large cluster of machines and support running tens of thousands of jobs.


  12. Does the JobServer scheduler have support for failover?

    JobServer's scheduling engine supports a primary and secondary configuration. If the primary scheduling engine fails the secondary can take over control automatically and continue scheduling jobs.


  13. Can I load balance job processing across a cluster of machines?

    Job processing can be spread across hundreds of Agent nodes so you can setup your partitions and environment so that if any Agent node goes down other Agent nodes will pick up the slack for a given job processing Partition. JobServer's Partition concept is a powerful way to organize your jobs and distribute jobs across Agent nodes so that resources are efficiently utilized.


  14. Is JobServer centrally upgradable?

    Yes, you only need to upgrade the central shared filesystem where JobServer is installed in order to update the software for all nodes. So whether you have JobServer deployed on one or a hundred machines, the upgrade process is straight forward and simple.


  15. Can I configure jobs to run under unique OS user names (when deployed on Linux/Unix)?

    Yes, you can configure jobs to run under any Linux/Unix user that exists in our environment. So you can have jobs run under one common user or have each job run under a different user. Note, this feature is not available on MS Windows.


  16. Can I run reports that will predict when future jobs will be scheduled to run?

    Yes, JobServer has a powerful reporting feature that lets you project out at any time in the future to estimate what jobs are expected to run.


  17. Can I import/export jobs between multiple JobServer environments?

    Yep, JobServer has great import and export features so you can move single jobs or groups of jobs between different JobServer environment. So, for example, if you have a job running in a QA installation and you want to move it a different Production environment you have a variety of built-in JobServer web UI, web API and command line tools to do this with.


  18. Can jobs be killed after they have started running?

    Yes, you can kill and terminate running jobs from the web UI, command line and web API.


  19. If a job does not run (due to system down time or system failure) can I configure a job to have an expiration period after which it will not run for that scheduled time?

    Yes. You have the option to configure a job such that if it does not run within a specified time window, it will not run and will instead get marked as “expired”.


  20. How do I know if a job had problems while running?

    JobServer provides monitoring tools for tracking the state of a Job while it is running and after it has finished running. Errors reports for one particular job or for a group of jobs can quickly be accessed and reported on.


  21. If I develop jobs and Tasklets will I be locked in to your product (JobServer)?

    The Tasklet API is an open API and given that it is a relatively lightweight API, there is little in a Tasklet implementation that is proprietary. To put it another way, it takes a minimal amount of work to package existing Java code into a Tasklet.


  22. How difficult is it to develop a Tasklet?

    The learning curve is relatively simple. Implement one interface and package the code into a special JAR format and you have a Tasklet and this can be one line of Java code or one thousand lines of code. There are other more advanced options but they are optional. You can get very sophisticated with Tasklet customization and configuration, but this is optional. Simple things are simple to do with the Tasklet API. Use as much or as little of the J2SE and J2EE APIs as you like.


  23. How do I access the various JobServer applications and tools?

    All you need is a web browser (Chrome, Firefox, Safari or IE 8). All JobServer applications are web based.


  24. How easy is it to monitor overall system usage and performance?

    Web tools are provided that allow users to monitor the total number of Jobs running across the environment. Job processing can be monitored at many levels in order to track activity across virtual Partitions and agent host computers.


  25. Why don't I just use a commercial J2EE appserver in place of JobServer? Don't App Servers already do load balancing, distributed computing, EJB, ...etc?

    Standard Application Servers don't offer the scheduling and monitoring features provided by JobServer. JobServer can be used along side an Application Server infrastructure as needed. JobServer is designed from top to bottom for the sole purpose of scheduling, running, and managing jobs. Standard J2EE servers are not designed for this. Bolting on a scheduling engine or workflow engine directly onto a general purpose J2EE application server will get you a less than optimal solution.


  26. Can I only use Java to develop my Jobs/Tasklets?

    Tasklets are developed using Java. Tasklet implementations can also be built that allow UNIX scripts to be executed. There is a pre-packaged Tasklet that comes with JobServer that lets you execute any arbitrary UNIX shell script (bash, csh, perl, ...etc). With this you can run any c/c++ or fortran application you may have and still monitor, track, and log standard input and standard error.


  27. How are Tasklets chained together to create Jobs?

    Tasklets are run one right after the other. As soon as one Tasklet finishes the next will start. Tasklets can pass data between each other using J2SE JavaBean constructs.


  28. Why is XML not used to define Tasklets inputs and outputs?

    JavaBean properties provides a more intuitive abstraction than XML. Using XML will only impose an unnecessary impedance mismatch. POJO is a design theme that the Tasklet API uses. XML is great, but only where necessary.


  29. What is JobServer's relationship to Web Services and other messaging standards?

    JobServer exposes some of its interfaces as Web Services. Third party tools can integrate with JobServer using standard WSDL based Web Services. For example, a developer can write a Web Service that tells JobServer to manually force a job to run when a file is dropped into a FTP directory. That job might then pick up the FTPed file and do something with it. jobs are also free to talk Web Services as they like (as well as RMI, COBRRA, JMS, ....etc).


  30. How do Tasklet inputs and outputs work?

    Every Tasklet has the option of exposing an input JavaBean and an output JavaBean. The output of one Tasklet can be used as the input to another Tasklet within the Job. Configuring the input/output mapping, between Tasklets, can be done when designing a job using GUI tools.


  31. How do you make new Tasklets available to JobServer?

    Tasklets are packages in a JAR format. The JARs are added to the JobServer environment by dropping them into the proper directory. Once added the new Tasklet can be used to create Jobs.


  32. How does JobServer and the Tasklet API promote software reuse?

    Very much so. The Tasklet API is a powerful way to develop software components that can connected to other components without prior knowledge of each other.


  33. How does JobServer relate to grid computing?

    While grid computing is an evolving concept with many dimensions, JobServer can be viewed as a tool that can enable some aspects of grid computing.


  34. How does JobServer relate to open source standards and technologies?

    Overall JobServer itself is not open source, but aspects of it are. The Tasklet API is open source enabling developers to create new components using an open API. Other open source projects like beansoup and jobrunner also support the Tasklet API by providing supporting tools outside of the JobServer product. This insures users, that they will not be locked into a proprietary technology, and gives them greater access and control over their assets. JobServer also uses other open source APIs and technologies where applicable, such as echo and tomcat. There are also plans to expose the JobServer's scheduling rules as an open source API. This will allow open source development of custom scheduling rules and patterns.







Copyright &169; Grand Logic, Inc. All Rights Reserved.