Workflow Open Service

The Workflow Open Service Interface Definition (OSID) is an O.K.I. specification which provides the means to define a Process composed of Steps. OSIDs are programmatic interfaces which comprise a Service Oriented Architecture for designing and building reusable and interoperable software. Each Step has Input Conditions and Output States. A Process exists to advance Work from an initial to a terminal Step. The advance is affected by events that are performed as part of a Step, the result of which is a new Step Output State. Work events are the result of Agents performing a specific role in the Process.

Part of the service providers responsibility is to define the Process and its Steps. Other parts of the service are intended to capture the events of a user in the Process. Separate applications for designing and using Workflow are likely to be written, each of which will rely on one or more OSIDs.

The Workflow OSID provides an application, or set of applications, with the means for coordinating and managing workflow based on some predetermined logic, among one or more actors (Agents). Abstracting and separating the workflow from the application insulates the application from changes in the workflow logic. Common tools for displaying, monitoring and maintaining workflow could be used in conjunction with the application, saving the application from delivering this functionality.

Ref: Wikipedia

Workflow Application

A workflow application is where various applications, components, and people must be involved in the processing of data to complete an instance of a process. For example, consider a purchase order that moves through various departments for authorization and eventual purchase. The orders may be treated as messages, which are put into various queues for processing. It is critical that the state of the queues are captured.

A workflow process involves constant change and update. You can introduce new components into the operation without changing any code.
There are two ways of developing workflow applications. The first one is to design workflow models in a dedicated language and then to link the tasks in these models to worklist handlers (for human tasks) or software applications (for automated tasks).

Workflow languages usually come with an associated graphical notation, but some are textual or XML-based. Languages that can be used for workflow definition in this way include:
Dedicated workflow specification languages:
1. XPDL
2. YAWL
3. SCUFL
Executable process definition languages based on Web Services:
1. BPEL
2. BPML
3. WSFL
4. XLANG
5. Wf-XML
6. SWSL

Ref: wikipedia