Interfacing the wftk with other systems

[ wftk documentation home ]

Interfacing with wftk

There are two categories of interface to the wftk: there are ways to invoke the wftk functionality, and there are ways to be invoked by the wftk engine. The former category of module I usually call a wrapper, while functionality to allow the wftk engine to talk to other systems is collected in adaptors. Each type of interaction needed by a workflow system is an adaptor class. I've called the adaptor mechanism a "poor man's ActiveX" elsewhere, because I've always liked the idea of ActiveX (even back when it was called OLE): the idea is that you implement an object once, then you have binary compatibility with it which persists over version changes.

At any rate, a full wftk system is going to be a wrapper (and may use one or more established wrapper libraries), and is going to make use of various adaptors. If you have moderately unique needs, you will probably end up writing an adaptor, thus this section of the document will largely be concerned with how adaptors work.

As with most of the wftk documentation, this isn't complete. However, here is what I hope to have in this section:

Overview of the adaptor mechanism

The wftk is intended to do workflow-y kinds of things in whatever system you have. In order to make that work, nearly every system dependency that wftk has is split out into one or more adaptors. An adaptor presents a unified API to wftk and identifies individual functions using string names. It's not the most efficient way of doing things, perhaps, compared to the traditional C approach, but it's simple to manage and simple to write to. It's kind of like letting a bare minimum of scripting languages into the C paradigm.

At any rate, I need to flesh this out with examples, but for the time being, look at some of the implementations in the source directory.




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