wftk: Interfaces

[ wftk documentation home ]

Playing well with others: interfaces to and from the wftk

The whole point of a workflow toolkit is that it provides know-how that can be tossed into any arbitrary system and help you do things right without worrying about building the entire system from the ground up with workflow in mind. We all have systems which deal with workflow -- an ideal wftk would therefore take any such system as is, and work with it to improve the workflow functionality. For that to work, of course, the wftk would have to be able to work with all software in existence, meaning I have an excuse to play with anything I want to, and still tell my wife I'm working. That's pretty neat.

There are two basic ways that the wftk impinges upon other systems:

Any wftk system will ultimately involve both; nothing ever happens in the wftk unless an adaptor does it, and the wftk never does anything unless called by a wrapper or front-end. See?

The "interfacing" section contains one document for each system or protocol or whatever that wftk can deal with, whether this is an adaptor or a wrapper. Thus if you're interested in SOAP and web services, you can check the SOAP page for information about, and links to, wftk smarts in the SOAP arena, and this page will include:

With that in mind, let's list the general types of system we intend to interact with, and the target systems in each of those categories. As I write this, most of the list is going to be on the to-do list instead of existing as a mature codebase. I should have a "complete" workflow system by, oh, 2015. (Note to self: revisit this page in 2017 to revise estimate.)
By subject
Alphabetical listing
  • Databases and not-so-database storage mechanisms
    The question of data storage, of course, was the original motivation for the repository manager. As a result of that work, data can be stored in a lot of different places and still be handled as workflow-enabled "stuff".
    • Filesystem
    • MySQL
    • Oracle
    • PostgreSQL
    • ODBC-accessible databases
  • Scripting (and not-so-scripting) languages
    Most of the work in this section falls into two parts: wrappers allow the wftk to be called from a language, while action adaptors allow the wftk to call code written in a particular language. Sometimes the question isn't the language as a code-level protocol such as COM or CORBA -- but the key idea is calling
    • Python
    • Perl
    • Java
    • C++
    • .NET/C#
  • Protocols, and, um, not-so-protocols
    There are a lot of ways in which systems already talk to one another. The wftk should fit into this kind of network with no problem.
  • Process definition
    This section will deal with alternative ways of defining processes. Ideally, you should be able to define a process in any defined language, and the wftk should go its merry way and do things right. As you can tell from my creative use of tenses and modes, this part doesn't have any actual solutions in it yet.
Web services

Copyright (c) 2003 Vivtek. Please see the licensing terms for more information.