Projects tagged ‘scheduler’ and ‘scheduling’

Quartz is an enterprise-class job scheduler for integration with stand-alone Java applications and full-scale J2EE applications. Advanced features include clustering and participation in container ... [More] managed transactions. It is highly scalable, very lightweight, and supports very complex scheduling. [Less]

Completely customizable, CakePHP based project management system for firms, their teams and their clients. A project management system that will suit your needs because it is module based, so it ... [More] can grow and shrink with your requirements. Version 0.4 beta was released March 23, 2009. [Less]

phpJobScheduler will automate the running of scripts at scheduled times. Logs last runs, recording output so you can check it correctly ran or to check for errors. You can run local or remote ... [More] scripts; PHP, CGI, or any other scripts. When running remote scripts PHP CURL is used for the connection if available, otherwise PHP fsockopen is used. This is easy to use and setup, and makes a big improvement on using simple cron jobs. [Less]

KPlato is a project management application. Features include: * Gantt chart with task list and resource allocations per task. * Resource view with task allocations per resource. * Accounts view ... [More] showing planned cost with configurable cut-off date and periodicity. * Tasks are organized in a work breakdown structure (WBS). * Resources are organized in a resource breakdown structure (RBS). * Accounts are organized in a cost breakdown structure (CBS). * Summarytasks, Tasks, and milestones are supported. * Dialogs to create and edit the project, the different types of tasks, calendars, resources, accounts and progress. * Task links can be of types: Finish to Start, Finish toFinish or Start to Start. All types can have a time lag defined. * Different scheduling constraints are supported. [Less]

Schedule::Chronic::Distributed is a distributed scheduling system using a shared database backend. This allows you to schedule jobs based on a combination of criteria including time of day ... [More] , available resources per node, and status of other jobs. Also included is a Maypole Web application providing monitoring, management and reporting of the Schedule::Chronic::Distributed scheduler. [Less]

Schedulator is a software project management system designed to let developers make their own individual task estimates. Those estimates feed into a central database where they can be summarized and ... [More] analyzed by a project manager, who uses the combined information to make intelligent decisions about how to manage the software project. Schedulator supports various bug-tracking plugins, including existing plugins for Mantis, Fogbugz, and Google Code Issue Tracker. It's easy to add new plugins for other systems if you want. DocumentationSchedulator Philosophy (PDF), a mostly non-technical discussion of how Schedulator is different from other software scheduling systems and how it can benefit you. Schedulator for Managers (PDF), a step-by-step guide to getting your team up and running using Schedulator. Schedulator for Developers (PDF), a step-by-step guide to using the Schedulator as a lowly developer, once your team is actively using it. Sample schedulator input Notes for users of the old Schedulator 3 Credits & LicensingSchedulator is a fancy implementation of Painless Software Schedules, an essay and method by Joel Spolsky. The original Schedulator system (which we retroactively numbered versions 1.0 to 3.0) was developed at NITI, largely by Avery Pennarun, Peter McCurdy, and Reid Levesque. The new Schedulator contains absolutely no NITI intellectual property and was rewritten in C# entirely by Avery Pennarun while working for Versabanq. The only exception is that the new Schedulator version uses the MESH web widget library, which was created by mich at NITI and released under the LGPL. The Schedulator documents above are equally applicable to both the new and old Schedulator versions and were written entirely by Avery Pennarun for Versabanq. DiscussionVisit the Schedulator Mailing List. Yes, you can subscribe even if you don't have a google account. [Less]

This project is to create a service like architecture written in Ruby that can be used for scheduling and running tasks, including other Ruby scripts as well as scripts and programs written in other languages

SOAFacesThe goal of the SOAFaces project is to provide developers with an API for building SOA and RIA powered components (called SOAFaces Bundles or just Bundles) that can be composed easily into web ... [More] applications or workflows and jobs with convenient access to local and remote messaging services. SOAFaces = RIA + SOA With SOAFaces you get the full power of an AJAX API combined with a SOA API. What can I build with SOAFaces? Secure Web Applications Mashup applications to full-blown AJAX clients Batch job scheduling Workflow processing You decide........ SOAFaces download page. Specifically, the goals of the SOAFaces project include the following: No need to write GWT RPC code anymore. Use the UniversalClient API to talk with POJO services that are packaged in your application server and/or talk with Mule accessible services/endpoints all across your enterprise and internet. Your GWT application will have convenient access to messaging services (SOAP, JMS, ESB ...etc) that can return JavaBeans or JSON objects back to the GWT client. All marshaling is handled by the framework. A framework for building SOA GUI applications using modular/pluggable components. Build anything from a simple AJAX type weblet all the way to a full blown web application. Package your code as a component and deploy your code as a modular/pluggable and self contained component. SOAFaces components are packaged into a simple JAR formatted archive and easily shared, deployed, and run. Create back-end workflow powered jobs and services that can be scheduled and run on the back-end with easy access to web services. Workflow properties and configuration rules can be configured using a web GUI. There are three main constructs: UniversalClient API - An API to use from any GWT client to make SOA service calls with no RPC. This API can be used with our without weblets/tasklets (you can use it in any plain old GWT client). Cool way to build GWT apps without all that RPC code and with easy access to web services. Weblet - A modular/pluggable way to build/package/deploy front-end web applications using GWT and SOA. Tasklet - A modular/pluggable way of build/package/deploy back-end tasks that can be run in scheduled batch jobs with convenient SOA integration. Sounds like a lot doesn't it? Well the SOAFaces framework is up to the task and keeps it as simple as possible. Keep reading if you would like to hear more........ Building Web ApplicationsWith SOAFaces you can build and deploy web applications that are powered with SOA and GWT. You can build your web GUI using the GWT (Google Web Tookit) framework and deploy your GWT applications on any standard j2ee servlet engine (like Tomcat). With SOAFaces, web developers can focus on building applications that can easily tap into web services hosted across the network. SOAFaces provides a MuleClient like API called UniversalClient. For those not familiar, the MuleClient interface is a universal messaging client available from the Mule Project that can invoke services endpoints such as JMS, Web Services, SMTP, SFTP, ...etc and send and receive data. UniversalClient is an extension of the MuleClient API for AJAX/GWT applications with even more extended capabilities. UniversalClient gives a GWT client the ability to access ESB services exposed by Mule. You can also expose our own POJO services using UniversalClient and make them available from your servlet engine (WAR webapp) directly. So you can message with remote Mule services or develop your own services and access them all from the UniversalClient API. To develop your own services, you create "local" services that you deploy in our servlet engine, and access these services using the same UniversalClient API. In fact the UniversalClient API functions as a universal messaging interface for GWT clients. It automatically marshals data in JSON and/or POJOs for you with no GWT RPC programming. The UniversalClient API builds on and extends the Mule endpoint notation, allowing you to access local POJO services within your web application (servlet engine). With this UniversalClient API you can mix and match resources and services all across the network to build GUI applications with a clear separation between the services/implementation and the GUI presentation. Building Modular and Pluggable Client ApplicationsA Weblet is the essentially building block for building modular component based applications. It is simply a GWT client that adheres to the SOAFaces API for building a GUI component (called a Bundle) and provides for an easy way to deploy big or small GWT GUI applications into a container. A Weblet is a modular GWT client that you can pick up and deploy in any SOAFaces container. Using the power of GWT and SOA, you can build mashups that pull and combine data from different sources across your intranet or internet, allowing developers the freedom to focus on what they do best - building applications and not dealing with implementing server-side code and marshaling data between client and server. Building Modular and Pluggable Workflows and JobsWorkflow? Yes, you can use SOAFaces to build jobs and tasks that can be run and scheduled in a workflow within a job processing container. The essential building block is called the Tasklet. Jobs (composed of one or more Tasklets) can be scheduled and run on a timer or executed on demand (this is up to the container to provide these services). A SOAFaces workflow can execute any arbitrary server-side java code and/or access messaging services via a MuleClient interface. The input properties of a workflow/job can optionally be edited, graphically, using the same GWT GUI framework used to build applications. So you are free to give your job/workflow components full-blown GUI interfaces to customize them anyway you chose. Or if you like just write server-side code (with no GUI) and package it up in a Bundle for use in a job. A Job can be composed of multiple Bundles. Where/How to use the SOAFaces Framework?With SOAFaces you have several ways you can use the framework. You can use the framework for building modular Bundle jobs/tasks, modular Bundle GWT weblets, or as a SOA messaging API in your existing GWT clients code to extend your GWT client to the SOA universe. Here is a break down of the scenarios you have for using the SOAFaces API: Usage Scenarios Deploy Where? Do What? Tasklet API Weblet API IOViewer API UniversalClient / Services API Standalone GWT Client Any standard J2EE container (e.g. tomcat, jetty...etc As a messaging API for use in any GWT client to access SOA services Required GUI Component (Bundle) SOAFaces Container (e.g. JobServer, SoaFacesRunner) For deploying and running modular weblets/applications Required Optional Workflow Component (Bundle) SOAFaces Container (e.g. JobServer, SoaFacesRunner) For batch job scheduling & workflow processing Required Optional Optional Optional (with Weblet/IOViewer) Standalone GWT ClientThe SOAFaces framework can be used as part of your existing GWT web application and provide you the ability to connect your GWT application with POJO services in your backend webapp and to access Mule/SOA services all across your network. You can use the SOAFaces framework with any standard GWT application to access remote SOA services with no RPC coding. The UniversalClient is only one small part of the SOAFaces framework but it is a very powerful and useful API to use directly in your GWT web applications. The UniversalClient API provides any GWT client the ability to access Mule services/endpoints and to send/return JSON and POJO objects with minimal effort - no RPC! The API also allows creating "local" services that can be deployed within the Bundle server-side and accessed as POJOs services from the UniversalClient API. So you get simple POJOs exposed as local services with remote access provided using the UniversalClient API. Simply include the SOAFaces framework JARs in with your servlet code and in your GWT code and you instantly have extended your GWT application with convenient messaging capabilities. No extra deployment or anything is needed. Simply use the SOAFaces framework with your existing GWT application and go. To get more information on how to get started using the UniversalClient API with you GWT application go here. Bundles as Application ComponentsIf you want to build modular component application (weblet), then you can package your code as a Bundle and deploy it in a SOAFaces container that will run and manage your Bundle Application. A Bundle Weblet uses the the Weblet API to allow you to build GWT applications that are managed and run with a SOAFaces container. You of course have full access to the UniversalClient API as well, to access SOA services. Bundles as Workflow ComponentsA Bundle Tasklet uses the Tasklet API to build modular server-side Java code that can be run as part of a larger job. The job can be scheduled for example and run any number of ways. The tasklet is packed in a Bundle and can also include a GUI customizer using the Weblet API. A Bundle Tasklet is deployed, run and managed, all within a SOAFaces container. Underneath the HoodThe essential building blocks of SOAFaces are tasklets and weblets. A packaged SOAFaces component is called a SOAFaces Bundle (or Bundle). A Bundle can be made up of a weblet and/or tasklet. The tasklet provides the API for implementing and executing back-end java code and services when the Bundle is used to build a workflow job. The weblet provides the abstraction for building AJAX Web GUIs of any kind. A weblet can be a standalone web application, that interfaces with remote web services, or it can be the GUI used to customize the input properties of a tasklet. As discussed, SOAFaces also provides easy access to Mule services and can easily interface and communicate with remote and local Mule services of all shapes and forms. SOAFaces leverages the GWT framework which serves the basis for its Web GUI API. Weblet - Building ApplicationsThe Weblet is the main abstraction for building end user GUIs with SOAFaces. A weblet enabled application can be deployed and run from a web application server. A weblet based application can be deployed and loaded dynamically within a hosting container without requiring server restarts. The code that makes up a SOAFaces Bundle is bundled and packaged in a JAR called a Bundle (SoaFaces Bundle). Here are details on creating a SOAFaces Bundle (Bundle). With a weblet, you have the full power of the GWT API at your disposal. The weblet interface itself is nothing more than a GWT Composite widget that can contain any GWT widget you drop into it. It functions as the top level UI panel for your application, mashup, or any other UI thing you want to build. What is especially nice about a weblet, is that you can just compile your GWT java classes into java binary classes and include them in a JAR file and the container will handle compiling your GWT java code into actual ajax/javascript. You can use virtually any standard GWT or third party GWT widget libraries and include them in your Bundle JAR and it will all get linked and compiled for you into ajax/javascript; this sort of similar to how a j2ee server complies JSP pages on the fly. Cool don't you think! So develop your components in GWT, package them up in a Bundle, and drop them into a SOAFaces container and go. No need to mess with GWT javascript to java compiling! Weblets - Accessing Remote Server-Side ServicesWeblets and generic GWT applications can access services using the GWT UniversalClient interface. This API is similar to standard MuleClient API available in native server-side java. The GWT UniversalClient API can pass and return POJOs (basic java primitives and objects that support the GWT IsSerializable interface) and/or JSON types. So using the GWT UniversalClient interface a GWT weblet can access web services and other ESB endpoints throughout your enterprise and over the internet, and do this directly from a GWT GUI. If we stopped there that would be interesting enough. However, you can also define your own "local" services and access such services directly from the GWT UniversalClient interface as well. A local services is a POJO method that is exposed as a local service and bundled directly within the Bundle JAR. So a Bundle can contain all the client and server/services code ,if that is what you prefer, or you can mix and match local services with remote service across your network or internet. For example access a remote web services might go something like this: //pass POJO and returns POJO UniversalClient.send("axis:http://my-web-services.com/?method=hellworld", "Bob", asyncPOJOHandler);All endpoints supported by Mule are supported the GWT UniversalClient interface. Accessing a local services would look like this: //pass POJO and returns POJO UniversalClient.send("soafaces://com.acme.local.MyServices/getHelloWorldEndpoint", "Bob", asyncPOJOHandler); //pass POJO and returns JSON UniversalClient.send("soafaces://com.acme.local.MyServices/getHelloWorldEndpoint", "Bob", asyncJSONHandler);The prefix soafaces:// tells the UniversalClient to route the call to a POJO service in the current Bundle JAR and return the results of the method. In this example the method com.acme.local.MyServices.getHelloWrold("Bob") is called and a POJO or JSON result can be returned via the asyncHandler. Tasklets - Building JobsA tasklet is a simple way to create any arbitrary server-side java code and run it a container that supports the SOAFaces Bundle API and run it as part of a job. The input and output of a tasklet is a JavaBean. One JavaBean for input and another for output. A tasklet consumes a JavaBean as input and returns a JavaBean as output. These input and output JavaBeans can have UI customizers/viewers that can edit and render the contents of the input/output JavaBeans for user manipluation. The Weblet API is used to render the GUI for the customizers/viewers. So you can pair a tasklet with a weblet if you want to give your tasklet a graphical representation (this is optional of course). Multiple tasklets can be composed and packaged together into back-end workflows and executed on timers and schedules for example as part of a job. The specification defines a life cycle for the execution of one or more tasklets that are chained together to execute a single job. Tasklets - Property MappingTasklets even get more interesting and powerful when you understand how the property mapping features works between multiple tasklets that can makeup a job. Tasklets can share and communicate with each other when they run as part of a job/workflow. Individual tasklets can pass JavaBeans to each other during the execution of the workflow (a chain of tasklets). The output JavaBean of one tasklet can serve as the input to the next tasklet in the chain (or even other tasklet further down the chain). This is done through a mapping specification to allow the end user (business analyst type person or developer) the ability to configure which properties of one particular output JavaBean get mapped to which corresponding properties of another input JavaBean. This is a very powerful features, it allows end users to customize behavior using a simple point and click GUI where the output of one tasklet can function as input to another tasklet. It allows tasklet's with no knowledge of each other to work together to perform a larger and more complex job or workflow operation. The SOAFaces API makes all this possible and straight forwards. Weblets and Tasklets - Use Them Together or SeparatelyAs mentioned, if you are only interested with building a RIA GUI, then you do not have to use the Tasklets API - you just focus on an use the Weblet API (org.soafaces.bundle.client package). Now, if you want to build back-end jobs and workflows then you should use the Tasklets API (org.soafaces.bundle.workflow package), and only use weblets, along with the tasklets, if you want to build GUIs to customize your tasklet's properties. Using weblets with tasklets is optional but is very powerful as it provides you with a way to allow end users to customize the inputs of tasklet. Once you have constructed your code, you then take it and package it up into a SOAFaces Bundle (Bundle JAR file) and deploy - that's it. It is very similar to deploying a WAR file but even simpler :) OSGiSOAFaces Bundles sort of sound like OSGi bundles don't they? Well, the two have similar goals with regard to building modular components that can be deployed in a runtime container and discover each other....etc. SOAFaces takes it a little deeper, but the underlying requirements of packaging code into components and hot deployment, for example, are very much similar. The SOAFaces project will make every attempt to align itself with the OSGi effort where it makes sense. Getting StartedReview SOAFaces Javadocs Download and test drive UniversalClient sample webapp to see API in action Download and review sample Bundle component source code from the BeanSoup sub project and write your first Bundle Download SOAFaces binary and source News and EventsProducts Using and Supporting SOAFacesJobServer - A commercial implementation of a SOAFaces container for managing, deploying and running Bundles. Free for non-commercial use. SoaFacesRunner is the SOAFaces container Reference Implementation - you can deploy and run SOAFaces Bundles (Bundles) with SOAFacesRunner in any servlet engine. This includes deploying and running weblets and tasklets. Available SOAFaces ComponentsBeanSoup is a small project and code with many sample SOAFaces Bundles (Bundles) implemented. A Bundle is a SOAFaces component that can be deployed to any compliant SOAFaces container. RoadmapQ1 2010 - SOAFacesRunner 1.0 (RI implementation of SOAFaces container) Q2 2010 - Support for other major ESBs Q3 2010 - JSON Proxy Annotation/Compiler HistorySOAFaces is an evolution of the original TaskBean component API specification. The TaskBean API was a framework before its time :) You can read more about TaskBeans here. [Less]

A scheduling simulator for common algorithms like round-robin, rate monotonic, EDF, and others.

Windows Service Process Scheduler - This is a very simple to use, lightweight windows service framework for scheduling any process that needs to be run at a particular time of day, or every n minutes. ... [More] Includes full setup installer. The solution makes use of the following tools: - CastleProject's Windsor IoC container - NUnit testing framework (98% unit test coverage on key logic) - Driven.Library [Less]