[ 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
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
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?
- through adaptors, which enable wftk to invoke other systems
- through wrappers and front-ends, which present wftk functionality to other systems.
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:
- An overview of SOAP and web services
- A timeline of wftk development to do with SOAP, and some random thoughts I might have had during that
- A description of the SOAP adaptor and a link to its definition
- A description of any SOAP-providing services built on wftk and a link to that code.
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.)
- 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".
- 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
- 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.
Copyright (c) 2003 Vivtek. Please see the licensing
terms for more information.