wftk: Features

wftk: Interfaces

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:

through adaptors, which enable wftk to invoke other systems
through wrappers and front-ends, which present wftk functionality to 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:

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.)

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.

SOAP application servers, WDSL, and so on
cURL and libcurl support the HTTP protocol for SOAP and page retrieval.
Web in general (CGI, page retrieval, etc.)
Email
WebDAV

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.
cURL
HTTP
libcurl
SOAP
Web services

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. SOAP application servers, WDSL, and so on cURL and libcurl support the HTTP protocol for SOAP and page retrieval. Web in general (CGI, page retrieval, etc.) Email WebDAV 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.		cURL HTTP libcurl SOAP Web services