Default

Note

This document is under development and will undoubtedly contain lots of badly explained information. I have revised it again recently, and so it may seem to have changed completely since the last time you looked.

Introduction

The graphs used in this documents express relationships or dependencies between nodes.
Nodes represent concepts, processes, objects.
Nodes are connected using relationships.
These relationships may themselves be nodes in another "dimension" of a graph.

Architecture

A possible architecture for managing data, operations on that data, and the ordering of those operations, carried out by users through different "interaction media", could be given as follows:

See a rather large animation of how the architecture works.

Agents

Agents must be able to describe operations to users, perform operations on behalf of users, and be related to other operations through other agents.

It would be envisaged that agents take the form of "medium-specific" functionality which presents agents to users and handles user interactions through a particular medium. The diagram pictured here includes a template and would be suited more to Web applications. However, agents should be able to describe and handle interactions for different media:

HTTP/WAP/SOAP: Web applications and other kinds of interactions can be supported using text markup languages, templates and Internet protocols.
E-mail: E-mail is different from "interactive" communication, such as that supported by Web "sessions", but messages could be defined using templates and mail servers could be accessed by agents in order to send and receive information from users.
Telephony: Both "human operator" and voice menu services could be supported - automatic voice responses could be built using templates, whilst operators could be supported using more advanced interfaces than those offered by Web applications. (Alternatively, Web applications could be used by operators with additional telephony hardware control.)
Paper: Processing of postal mail might be possible, with scanning or OCR employed for input purposes, and the emission of letters or faxes for output purposes. Again, textual templates might be sufficient for the generation of operation descriptions.

Agents do not represent users themselves, but they do support user sessions within the medium in which they are deployed.

Templates

Templates need to express enough about the operation in order to describe it. This means that they must describe the data involved and provide a means for users to express that data correctly in a response. Since many operations may be chosen in a given interaction, a means of indicating the operation should be "framed" in the template so that the user can return their choice in the response.

Description Generators

Description generators use resources such as templates to describe a collection of operations.

Interface

Get Description

Explicit inputs: Data to be associated with the operation, hints about certain parts of the template, session of the user wanting information about the operation.
Implicit inputs: Operation collection.
Explicit outputs: None.
Side effects: In the case of HTML/XML documents, an instantiated description of a form to be sent to the user (in the agent's medium) is passed to the user's session.
Expected error conditions: None.

Action Handlers

Action handlers need to be able to pass on responses from users to the operations, deal with error conditions, and then invoke decisions. Therefore, handlers need to be consistent with the operation names and interfaces.

Interface

Invoke Operation

Explicit inputs: Operation name, session of the user requesting the operation.
Implicit inputs: Operation collection, data to be transformed by the operation (taken from the user's session), decision object to be involved.
Explicit outputs: None.
Side effects: A decision object may be invoked if the operation is a success.
Expected error conditions: Hints about where the operation failed.

Consistency

Consistency checking tools should be employed to ensure that templates produce output which correctly reflects the operation names and interfaces, and that the information associated with operations can be correctly interpreted by action handlers. Hints describing the failure of an operation should be easily fed into the description generator to change the nature of the description.

Sessions

When an incoming request is received...

The agent framework (the framework supporting the different agents for a particular medium) creates a session object containing the details of the request. It registers this session with the session register.
The agent itself accesses the request details and gives them either to the action handler or to the description generator.
The session object receives description details from either the description generator invoked directly, or from a description generator invoked through a decision object.
The agent framework communicates the received description details to the user, and possibly deregisters the session from the session register.

Applying Data

The agent must first determine whether a description is required or whether an action is being performed.

If an explicit description request is received, a description is given by invoking the description generator.
Otherwise, the action handler is invoked and if the data given by the user does not meet the expectations set down by the operation then a description is given describing why this is the case.

Some descriptions require a certain amount of data to be supplied and would not normally be requested by a user not able to provide such data. In such situations, the agent framework might produce an "error page", but a more preferable outcome would be to discover a suitable agent from which the user can start a sequence of meaningful interactions.

Operations

Operation collections expose a interfaces to named operations. Each operation's interface must be described in some way, and this could be done by reporting the relationships the operations have with different kinds of data.

Operation Activities

Operations should be free to transform information in any way they choose, but they will all be related to data types and their definitions, and many will want to retrieve details of well-defined objects for which an identifier is supplied.

Operations and Data

Where data types are associated with operations, these associations can take the following forms:

A set of "constant" data objects are always associated with the operation.
Data objects are presented to the operation and verified against the data type description.
A token (or key) representing (or referring to) a data object is presented to the operation which then obtains a data object from a repository.

Interface

Describe Operation

Explicit inputs: Operation name.
Implicit inputs: Data type definitions associated with this operation.
Explicit outputs: Data types associated with the operation given, along with the type of associations involved.
Side effects: None.
Expected error conditions: None.

Invoke Operation

Explicit inputs: Operation name, data to be transformed by the operation.
Implicit inputs: Data from "repository" services (where identifiers have been given, but where actual data is required in the transformation).
Explicit outputs: Transformed data of the form given.
Side effects: Some data which was retrieved from "repository" services may have been transformed. This will need to be put back into its "repository".
Expected error conditions: Hints about where the operation failed.

Decisions

Decisions "join" operations together, passing information between them where necessary. As a result of a decision being taken, an operation is described to a user by invoking the description generator of a particular agent.

In order to choose an agent for an operation collection, a decision must consider the following things:

Whether the user involved in the next operation is the same as the one which caused this decision to be taken.
- Whether the session of that user is available to be used in the next operation.
- Whether another session needs to be found using the session register.
- Whether a session needs creating, if only to communicate with that user on one occasion only.
Whether the user to be involved is different.
- Whether a session can be found for that user in the session register.
- Whether a session needs creating, if only to communicate with that user on one occasion only.

When a new session is created, the appropriate agent must be found to handle that session, since it may be the policy that new sessions cannot be created for certain agent frameworks by the decision, any newly introduced frameworks must somehow be activated for the users to receive descriptions of the next operation.

Interface

Invoke Decision

Explicit inputs: Operation outputs, session/agent involved.
Implicit inputs: Agents available for subsequent operations, session register.
Explicit outputs: None.
Side effects: Agent invoked.
Expected error conditions: None.

Session Register

The session register records the "channels" (known as sessions) through which users may be contacted, and these sessions are associated with different agent frameworks (or media).

Agent frameworks contact the session register to associate active sessions with themselves. Such information is later used by decisions to determine users can be contacted - sessions are acquired by decisions and passed to appropriate agents within the agent frameworks they are designed for.

Interface

Explicit inputs: Session to register, user associated with session, agent framework which created the session.
Implicit inputs: None.
Explicit outputs: None.
Side effects: Session registered for user and associated with the given framework.
Expected error conditions: None.

Deregister Session

Explicit inputs: Session to deregister.
Implicit inputs: None.
Explicit outputs: None.
Side effects: Session deregistered.
Expected error conditions: Session may not be registered.

Find Session for User (and Agent Framework)

Explicit inputs: User for whom a session is to be found. Possibly an agent framework within which the session must exist.
Implicit inputs: None.
Explicit outputs: A session representing the user within an agent framework (possibly the stated framework).
Side effects: None.
Expected error conditions: No session exists for the stated user (or at least not within the given agent framework).

Find User and Agent Framework for Session

Explicit inputs: Session.
Implicit inputs: None.
Explicit outputs: The agent framework within which the session operates, and the user that the session represents.
Side effects: None.
Expected error conditions: The stated session is not registered.

Preparation

For any given process, the following tasks must be performed:

Define Operations

Define the operations to be performed in the process, along with their interfaces.

Dependencies

Apparently none. Operations are free to have their own interfaces.

Define Decisions

Define the decisions which are to determine the order in which the operations will be invoked. It should be possible to define a skeleton decision graph which ignores the details of agents and operations.

Dependencies

The outputs of one operation must, combined with other data sources, be sufficient to meet the requirements of the description generator for any operation following it.

Define Agents

Define the agents through which access to operations will be given. Define their relationships with decisions. Define their resources.

Dependencies

Agent resources must only reference properties of the operation interfaces that they seek to describe, along with valid properties of the data types involved.

The behaviour of agents, through action handlers, must be compatible with the operations and decisions they are attached to.

Status

(October 11th, 2000): Added a description of the session register and how it is used. Added an animated GIF image of how the architecture might be used.
(October 10th, 2000): Added agents to the description of the development process. Changed GIF images to PNG images.
(October 4th, 2000): Added more detailed description of the development process.
(September 19th, 2000): Added more notes about the preparation of workflows.
(September 9th, 2000): Described decisions.
(September 8th, 2000): Added descriptions of the associations between operations and data types, and of sessions.
(August 27th, 2000): Added session and interface descriptions.
(August 25th, 2000): Added more description of agents.
(August 23rd, 2000): Added some description of agents.
(August 22nd, 2000): Revised the document completely.