Taskr - the RESTful OpenWFEru Scheduler
5 views
Skip to first unread message
Matt Zukowski
Jan 4, 2008, 9:50:15 AM1/4/08
to OpenWFEru users
This is a bit off topic, but given all the talk lately on this list
regarding RESTful services, I thought this might come in useful to
someone here.
Although my work on Fluxr (a RESTful front-end for the OpenWFEru
workflow engine) was sidelined, I was able to salvage some of it and
have now released Taskr, a RESTful front-end for the OpenWFEru
scheduler.
From a functionality point of view, Taskr is basically a networked
cron, with a REST API so that jobs can be scheduled and managed via
REST calls over HTTP. It's a stand-alone server, so all you need to do
is install via rubygems (`gem install taskr`), configure a single YAML
file, and run the daemon. The server handles persistence, provides a
simple web-based UI, and exposes the REST API for other RESTful
services.
You can find out more at http://ruby-taskr.googlecode.com
Taskr can handle fairly sophisticated jobs, making it a pretty
versatile tool -- especially as part of a larger REST-based service-
oriented architecture. For example we're using it to execute arbitrary
ruby code on our remote Rails servers. We're slowly replacing all of
our cron jobs this way, since Taskr gives us a centralized place to
manage and keep track of all of the various scheduled actions needed
by our Rails apps.
Another useful feature is Taskr's ability to make scheduled REST
requests to other RESTful services. We use it for example to check the
status of certain things at the start of the business day, and then
send off email notices via a Howlr messaging daemon (http://
howlr.googlecode.com).
Anyway I hope this comes in useful to someone out there. I figure a
scheduler is a pretty important tool and as far as I know Taskr is the
only such implementation in the REST space.
regarding RESTful services, I thought this might come in useful to
someone here.
Although my work on Fluxr (a RESTful front-end for the OpenWFEru
workflow engine) was sidelined, I was able to salvage some of it and
have now released Taskr, a RESTful front-end for the OpenWFEru
scheduler.
From a functionality point of view, Taskr is basically a networked
cron, with a REST API so that jobs can be scheduled and managed via
REST calls over HTTP. It's a stand-alone server, so all you need to do
is install via rubygems (`gem install taskr`), configure a single YAML
file, and run the daemon. The server handles persistence, provides a
simple web-based UI, and exposes the REST API for other RESTful
services.
You can find out more at http://ruby-taskr.googlecode.com
Taskr can handle fairly sophisticated jobs, making it a pretty
versatile tool -- especially as part of a larger REST-based service-
oriented architecture. For example we're using it to execute arbitrary
ruby code on our remote Rails servers. We're slowly replacing all of
our cron jobs this way, since Taskr gives us a centralized place to
manage and keep track of all of the various scheduled actions needed
by our Rails apps.
Another useful feature is Taskr's ability to make scheduled REST
requests to other RESTful services. We use it for example to check the
status of certain things at the start of the business day, and then
send off email notices via a Howlr messaging daemon (http://
howlr.googlecode.com).
Anyway I hope this comes in useful to someone out there. I figure a
scheduler is a pretty important tool and as far as I know Taskr is the
only such implementation in the REST space.
Pat Cappelaere
Jan 4, 2008, 10:07:16 AM1/4/08
to openwfe...@googlegroups.com
Matt,
This is cool. I have been trying to get that interface finalize but receive
some pushback from John.
I took a stab modeling it after WfXML but using the same RESTful approach.
The intent was to use that to interface Matelot (Flex version of BPMN
modeling tool) and OpenWFE.
The other addition is to use OpenID/Oauth to add security to that RESTful
interface for delegation of user authority to the workflows so they can
access other web services on behalf of the users.
May be we could try come up with a standard we can all live with?
WDYT?
Pat.
John Mettraux
Jan 4, 2008, 10:36:45 AM1/4/08
to openwfe...@googlegroups.com
On Jan 4, 2008 11:50 PM, Matt Zukowski <matt.z...@gmail.com> wrote:
>
> Anyway I hope this comes in useful to someone out there. I figure a
> scheduler is a pretty important tool and as far as I know Taskr is the
> only such implementation in the REST space.
>
> Anyway I hope this comes in useful to someone out there. I figure a
> scheduler is a pretty important tool and as far as I know Taskr is the
> only such implementation in the REST space.
Sounds focused, powerful and with lots of reach. I will study it and
blog about it.
Congrats !
--
John Mettraux -///- http://jmettraux.openwfe.org
John Mettraux
Jan 4, 2008, 10:47:11 AM1/4/08
to openwfe...@googlegroups.com
On Jan 5, 2008 12:07 AM, Pat Cappelaere <cappe...@gmail.com> wrote:
>
> Matt,
>
> This is cool. I have been trying to get that interface finalize but receive
> some pushback from John.
>
> Matt,
>
> This is cool. I have been trying to get that interface finalize but receive
> some pushback from John.
Sorry for the "pushback", I am fearing "featuritis", postponed
replying to you to after the xmas - new year break.
Best regards and a happy new year,
Matt Zukowski
Jan 4, 2008, 11:32:33 AM1/4/08
to OpenWFEru users
The API for Taskr is super simple. There's only one resource -- a
"task", and as you can imagine the CRUD operations on it are pretty
self-explanatory. If you're asking about an API for workflows, of
course I'd be happy to help out with that, although at this point I'm
afraid I'd be looking at it from a more abstract than practical point
of view, since I wouldn't have a chance to put it in practice at our
organization, at least not immediately.
In regards to authentication -- this is something I'm struggling with
quite a bit. In the end I just settled on plain old HTTP Basic, and
this is what Taskr uses. The advantage is that this is supported out
of the box by ActiveResource, Zend_Rest_Client (for PHP), Restr, and
most other REST client libraries. The disadvantages though are
obvious.
We actually use CAS for authentication, and I've been trying to think
of a good way to get this working with RESTful web services.
Essentially I think the client (or rather something above the client)
would have to contact the CAS server, obtain an authentication token,
and then send that token as part of its request to the target service
(it's actually a bit more complicated with CAS because you have to do
it via "proxy ticketing"). I suspect that the pattern is similar with
OpenID/Oauth. The main difficulty I guess is that no REST client
supports this sort of thing -- at least not yet -- so it would be up
to whatever code is making use of the client to feed the
authentication token to the client so that the client can send it as a
parameter along with the rest of its request.
On Jan 4, 10:07 am, Pat Cappelaere <cappela...@gmail.com> wrote:
> Matt,
>
> This is cool. I have been trying to get that interface finalize but receive
> some pushback from John.
> I took a stab modeling it after WfXML but using the same RESTful approach.
> The intent was to use that to interface Matelot (Flex version of BPMN
> modeling tool) and OpenWFE.
>
> The other addition is to use OpenID/Oauth to add security to that RESTful
> interface for delegation of user authority to the workflows so they can
> access other web services on behalf of the users.
>
> May be we could try come up with a standard we can all live with?
> WDYT?
>
> Pat.
>
"task", and as you can imagine the CRUD operations on it are pretty
self-explanatory. If you're asking about an API for workflows, of
course I'd be happy to help out with that, although at this point I'm
afraid I'd be looking at it from a more abstract than practical point
of view, since I wouldn't have a chance to put it in practice at our
organization, at least not immediately.
In regards to authentication -- this is something I'm struggling with
quite a bit. In the end I just settled on plain old HTTP Basic, and
this is what Taskr uses. The advantage is that this is supported out
of the box by ActiveResource, Zend_Rest_Client (for PHP), Restr, and
most other REST client libraries. The disadvantages though are
obvious.
We actually use CAS for authentication, and I've been trying to think
of a good way to get this working with RESTful web services.
Essentially I think the client (or rather something above the client)
would have to contact the CAS server, obtain an authentication token,
and then send that token as part of its request to the target service
(it's actually a bit more complicated with CAS because you have to do
it via "proxy ticketing"). I suspect that the pattern is similar with
OpenID/Oauth. The main difficulty I guess is that no REST client
supports this sort of thing -- at least not yet -- so it would be up
to whatever code is making use of the client to feed the
authentication token to the client so that the client can send it as a
parameter along with the rest of its request.
On Jan 4, 10:07 am, Pat Cappelaere <cappela...@gmail.com> wrote:
> Matt,
>
> This is cool. I have been trying to get that interface finalize but receive
> some pushback from John.
> I took a stab modeling it after WfXML but using the same RESTful approach.
> The intent was to use that to interface Matelot (Flex version of BPMN
> modeling tool) and OpenWFE.
>
> The other addition is to use OpenID/Oauth to add security to that RESTful
> interface for delegation of user authority to the workflows so they can
> access other web services on behalf of the users.
>
> May be we could try come up with a standard we can all live with?
> WDYT?
>
> Pat.
>
> > From: Matt Zukowski <matt.zukow...@gmail.com>
> > Reply-To: <openwfe...@googlegroups.com>
> > Date: Fri, 4 Jan 2008 06:50:15 -0800 (PST)
> > To: OpenWFEru users <openwfe...@googlegroups.com>
> > Subject: [openwferu-users] Taskr - the RESTful OpenWFEru Scheduler
>
> > This is a bit off topic, but given all the talk lately on this list
> > regarding RESTful services, I thought this might come in useful to
> > someone here.
>
> > Although my work on Fluxr (a RESTful front-end for the OpenWFEru
> > workflow engine) was sidelined, I was able to salvage some of it and
> > have now released Taskr, a RESTful front-end for the OpenWFEru
> > scheduler.
>
> > From a functionality point of view, Taskr is basically a networked
> > cron, with a REST API so that jobs can be scheduled and managed via
> > REST calls over HTTP. It's a stand-alone server, so all you need to do
> > is install via rubygems (`gem install taskr`), configure a single YAML
> > file, and run the daemon. The server handles persistence, provides a
> > simple web-based UI, and exposes the REST API for other RESTful
> > services.
>
> > You can find out more athttp://ruby-taskr.googlecode.com
> > Reply-To: <openwfe...@googlegroups.com>
> > Date: Fri, 4 Jan 2008 06:50:15 -0800 (PST)
> > To: OpenWFEru users <openwfe...@googlegroups.com>
> > Subject: [openwferu-users] Taskr - the RESTful OpenWFEru Scheduler
>
> > This is a bit off topic, but given all the talk lately on this list
> > regarding RESTful services, I thought this might come in useful to
> > someone here.
>
> > Although my work on Fluxr (a RESTful front-end for the OpenWFEru
> > workflow engine) was sidelined, I was able to salvage some of it and
> > have now released Taskr, a RESTful front-end for the OpenWFEru
> > scheduler.
>
> > From a functionality point of view, Taskr is basically a networked
> > cron, with a REST API so that jobs can be scheduled and managed via
> > REST calls over HTTP. It's a stand-alone server, so all you need to do
> > is install via rubygems (`gem install taskr`), configure a single YAML
> > file, and run the daemon. The server handles persistence, provides a
> > simple web-based UI, and exposes the REST API for other RESTful
> > services.
>
Reply all
Reply to author
Forward
0 new messages