GB2176636A - A system for providing a workstation environment - Google Patents

Abstract

A system for providing a workstation environment includes a plurality of centres 21, each centre having associated therewith all objects i.e. materials necessary thereto to execute a task assigned to that centre. <IMAGE>

Description

SPECIFICATION A system for providing a workstation environment This invention generally relates to a system for providing a workstation environment and, in particular, relates to such a system having at least one centre having objects exclusively associated with that centre.

Presently, most, if not all, workstations are supported by software architectures commonly known as operating systems. As used herein a workstation is taken to include such devices as personal computers, terminals interconnected to a common computer mechanism, or the like.

Conventional operating systems are designed to provide the users thereof with the maximum concurrent access to the resources of the computer system. One major drawback of current operating systems is that the users thereof are not provided with any comprehensive mechanisms for executing or organizing interdependent tasks. For such tasks, the user is left at the mercy of ad hoc solutions, such as shared data bases, telephone calls, electronic mail, files accessible by multiple users or any other ad hoc means, none of which solve the problem.

Another drawback of current operating systems stems from the requisite languages, i.e.

commands, used. That is, in order to fully utilise the functions and features of any given operating system the user is required to be quite familiar with a substantial amount of material. Further, the knowledge of this volume of material is rendered substantially completely useless if the user is to work with a different operating system. In such an event, the user must learn a-completely different set of commands and capabilities. This is clearly inefficient in installations having more than a single operating system available to the employees.

Further, the volume of material required to function effectively with any current operating system is often a major discouraging factor for workstation novices. This can lead to reluctance to utilise a workstation and/or considerable user inefficiency.

Consequently, there is a considerable need in the industry to provide workstation environments that are not only relatively easy to learn and use but also provide the power and functions required by the growing electronic work environment.

Accordingly, the present invention basically aims to supply a system for providing a workstation environment that substantially eliminates the drawbacks and difficulties of current operating systems.

According to one aspect of the present invention there is provided a system for providing a workstation environment, the system comprising means for accepting an input from a user; and at least one centre, said centre being responsive to said user, said centre having one or more files exclusively associated therewith, said files having one or more objects stored therein, said objects being exclusively associated with said centre.

According to another aspect of the present invention there is provided a workstation environment architecture, said architecture comprising a host operating system for storing at least one centre, said host operating system having a file system, and means for providing a uniform operating environment to a workstation user regardless of the characteristics of said host operating system.

According to a further aspect of the present invention there is provided a method for providing a workstation environment, said method comprising the steps of providing a multiplicity of workstations; defining a plurality of roles, each said role representing an assigned responsibility, defining, for each said role, a centre, each said centre being provided with all objects needed to execute said assigned responsibility; and distributing said roles and said centre associated therewith to said workstations.

According to yet another aspect of the present invention there is provided a method for providing a workstation environment, said method comprising the steps of providing a multiplicity of workstations; defining a plurality of mutually dependent tasks; storing said task definitions according to whichever workstation said task definitions are defined upon; distributing said task definitions throughout said workstations according to the location of said workstation where said tasks are to be performed; and providing, at each workstation, means for executing said tasks distributed thereto according to said task definitions.

Embodiments of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a block diagram of a system for providing a workstation environment embodying the principles of the present invention; Figure 2 is a more detailed block diagram of an architecture for use in the system depicted in Figure 1; Figures 3A to 3C are illustrations of a stateaction-state triple of a role script; Figures 4A to 4C are illustrations of a complex state-action-state triple of a role script; Figure 5 is an illustration of a role script action having computational code; Figure 6 is an illustration of a typical "userops" file; and Figures 7 to 30 are flow charts showing the operation of a system embodying the principles of the present invention.

A system for providing a workstation environment, generally indicated at 10 in Figure 1 and embodying the principles of the present invention, includes at least one means 12 (three being illustrated) for supporting the workstation environment provided by the system 10 at each physical site thereof, a means 14 for interfacing with the workstation environment supporting means 12 and means 16 for establishing communication between and among the workstation environment support means 12. The illustrated embodiment of means 12 for supporting a workstation environment includes a host operating system 18 and an operating environment 20. In addition, the interface means 14 can be a personal computer, a terminal or the like. In one possible system 10, the interface means 14 minimally requires that the user be able to position a cursor and write a character.Although shown in Figure 1 as separate entities, the workstation environment support means 12 may, in fact, be an integral part of the interface means 14. Further, the means 16 for establishing communication between and among the workstation environment support means 12 can be, for example, a local area network (LAN) or any other communication medium. Each workstation environment support means 12 intercommunicates therewith via a communication link 22.

In order to provide a more complete understanding of the present invention a number of the general precepts thereof are discussed hereinafter. These precepts include centres, role scripts, actions, interactions and extraordinary operations. With regard to centres, it is understood that, in one embodiment, each centre corresponds to a directory in the hierarchical file system of the underlying operating system. The directory includes a number of centre artifacts that support the centre, record its state, and allow the centre to execute the appropriate behaviour. The centre artifacts are more fully discussed below. In the present system 10 each centre resides only on a single machine or workstation. The centres may be organised according to a hierarchy thereby permitting centres to be contained fully within other centres.In fact, centres themselves may be treated as objects and moved within the system 10 and between workstations. The state of any centre, at any particular point in time, is determined from the explicit state artifact associated therewith and from the values and states of the objects within and assigned thereto. Objects may move between the centres only when the communication between those centres has been specified by the role script or as part of extraordinary operations. As used herein, the term "object" is taken to encompass those things that a user of the system 10 can manipulate. That is, for example, a form is an object that can be worked on, i.e. filled-in and, if desired or required, transferred to another centre.

Each centre is normally provided with a role script although this is not absolutely mandated. The role script establishes and defines the role state-action/interaction-role state ordinary behaviour of the centre. The role script further defines whether the action involves only a single centre or other centres, as well as includes the conditions under which those actions, or interactions, can occur. The ordinary behaviour of a centre includes, and is fully defined by, the actions executed thereby.

The actions may be solitary or joint with other centres. Further, in one preferred embodiment, actions may be either user dependent or automatic. That is, the role script can require the active participation of the user, or role player, or alternatively the role script can permit particular actions to be automatic (i.e. actions occurring without the necessity of user involvement or presence at any level). Before any action can occur, the centre must be in the predefined prestate as required by the role script thereof. Further, every action causes the centre associated therewith to change from the appropriate prestate to the predefined poststate thereof.

An interaction is, essentially, a special type of action involving more than one centre. Before any interaction can occur all participants thereto must be in the appropriate prestate and, upon completion of that interaction, all participants will be in the appropriate poststates. Further, every interaction must terminate, for all practical purposes, simultaneously for all participants thereto.

In one embodiment, each workstation location and thus, each centre associated therewith, is provided with the capability of performing extraordinary operations, i.e. those operations not defined by the role script of the centre involved. In fact, if no role script is provided to a particular centre, that centre may, nevertheless, function by means of extraordinary operations under user control. Extraordinary operations include such things as modifying the state of a centre, the records thereof, the contents as well as other artifacts associated with the ordinary behaviour of the centre. By means of these extraordinary operations, the user of the system has the ability to create, or delete, entire centres, to redefine the role scripts of centres under his control and perform other general exception handling activities. In addition, multi centre extraordinary operations are provided between centres only if those centres have been specified as being able to communicate with each other. In this instance, the extraordinary operations can include such things as voice communication, electronic mail exchange, passage of objects and redefining the mechanism or steps by which the two centres communicate. In adjusting the interaction procedure by way of extraordinary operations, i.e. in order to change the rules of any interaction, all parties to that interaction must agree that the change will occur. Upon agreement, each participant, by his own extraordinary behaviour, adapts his role script for that interaction accordingly.

The basis for the above precepts are more fully described and discussed in our U.S. Patent Application Serial No. 745347 entitled, "Method for Organising and/or Expressing Concurrent Rule-Governed Human Behaviour" filed on June 14, 1985.

With reference now to Figure 2, the workstation environment support means 12 is shown in a more detailed block diagram. In the preferred embodiment, the host operating system 18 includes a host operating system core 24 and a host file system 26 preferably having at least one centre 21 stored therein.

The operating environment 20 includes a user interface manager 28, a supervisory operations manager 30, a user operations manager 32, an action manager 34, an interaction manager 36, and a session manager 38. In addition, as more fully discussed hereinbelow, the workstation environment support means 12 is provided with a window manager 40. With regard to the architecture shown in Figure 2, each partition line indicates a bidirectional information transfer between those elements abutting that partition line.That is, in the host operating system 18, the host file system 26 and the host operating system core 24 bidirectionally communicate, the host operating system core 24 bidirectionally communicates with the window manager 40, the user interface manager 28, the supervisory operations manager 30, the user operations manager 32, the action manager 34, the interaction manager 36 and the session manager 38. In addition, the session manager 38 further bidirectionally communicates with the interaction manager 36, whereas the interaction manager 36 further bidirectionally communicates with the action manager 34. The action manager 34 additionally bidirectionally communicates with both the user operations manager 32 and the user interface manager 28. The supervisory operations manager 30 bidirectionally communicates with the user operations manager 32 and the user interface manager 38.

The window manager 40 bidirectionally communicates with the host operating system core 24 and the user interface manager 28.

The host operating system 18 preferably provides the following capabilities, these capabilities are ordinarily included within current operating systems. The preferred host operating system 18 must provide a file system, a process management system, interprocess communication, a device input/output controller mechanism, system services and networking services.

The file system, in the preferred embodiment, is a hierarchical file system having operations that include the ability to create and destroy a directory, find the list of files in a directory; create and destroy files; copy and move files within the directory hierarchy; open and close files; read, write and append files; alter access for files and directories; obtain type and access times for file system objects.

The process management means preferably includes some mechanism to dynamically create and manage processes from within other processes. Such operations include: synchronous process creation; asynchronous process creation and destruction; detect process exit status; obtaining the name of a directory within which a process is executing; and change a directory wherein the process is executing.

The interprocess communication mechanism provides the capability to move information between asynchronously executing processes.

The device input/output controller provides low level control of a user's input/output devices and communication lines. Essentially, this provides the ability to read a single input character and write a single output character without mapping, buffering or other interpretation.

Other system services preferably made available by the host operating system 18 include: a clock signal, a text editor, a text printer, a command interpreter, and access to user specific option settings.

The network services are provided in order to implement the system 10 on a plurality of workstations and provides the facilities for transferring files across the network, executing remote log-ins for automatic behaviour as well as normal operations within the system 10.

Nevertheless, if any of the above-recited host operating system facilities are unavailable from the particular host operating system utilised, the missing facilities can be provided by supplementing the operating environment 20 using techniques known in the art.

The window manager 40 is ordinarily provided by the host operating system 18 and allows a user to view a plurality of functions on a single display screen. The user interface manager 28 permits the user to examine the centres 21 under his control and to select the centre 21 desired, either to execute the role script thereof or to perform extraordinary operations therein. The user interface manager 28 is the primary interface with the user by way of invocation of host operating system mechanisms such as text editing, the use of the user interface manager 28 may cause the control thereof to be temporarily transferred to the host operating system 18 in order to deliver services provided thereby.

To invoke extraordinary operations, the user interface manager 28 or the user operations manager 32 invokes the supervisory operations manager 30. This component can be invoked at any time while the user is actively participating in an operation.

The user operations manager 32 is activated only through the explicit command in an action specification defined by the role script of a centre. Upon being activated, the user operations manager 32 displays a list of the ob jects contained in the centre being 21 worked on and allows the operator or user to select from a list of defined operations in a particular file that may be named in the role script. Such operations are preferably specified in terms of commands recognisable by the command interpreter of the host operating system 18 with additional commands recognisable by the action manager 34 itself. This facility, however, is not activated when the role script of the centre 21 being used controls the choice of operation, i.e. when the required operation is to invoke a text editor on a particular file, for example.The user operations manager 32 is also inactive during any automatic activity of the work station. Automatic behaviour can involve only the managers 34, 36, 38 and the host operating system 18 without the use of the managers 28, 30, 32 or 40.

The action manager 34 is the component of the architecture that executes the role script for a given centre 21. From the current state of the associated role, the action manager 34 computes a list of all enabled actions, that is, a a list of actions for which the current state of the centre 21 is the correct prestate and any other necessary conditions are satisfied (e.g.

explicit condition specification, user presence if action is not automatic). The actions of the enabled list are examined in order until one is executed or the list is exhausted. If a solitary action (not an interaction) is encountered, that action is executed immediately. Upon successful execution of an action, the poststate of that action is recorded as the new current state of the centre 21. If, however, the considered action is an interaction, the interaction manager 36 is invoked to lock the resources of the interaction partner for the interaction. If, however, any of the necessary locks cannot be obtained, the inability is indicated by a failure return from the interaction manager locking phase. The next action in the enabled list is then considered for execution. If, however, the locking phase is successful, the interaction manager 36 is invoked to execute that interaction.Upon successful completion of that interaction, the poststate of the interaction for the particular centres involved are recorded as the current states of those centres. Regardless of success or failure, the interaction manager 36 is invoked to execute the unlocking phase with regard to the previously locked resources of the interaction partners. If no enabled interaction can be executed and there is no solitary action, the action manager 34 exits that centre without causing a centre state change therein.

The interaction manager 36 determines whether an interaction can be executed, based on the state of the local centre and all partners. When all partners are in the appropriate prestates, the interaction manager 36 of each centre is invoked to execute the local portion of the interaction.

Given an interaction, this component executes the steps needed to determine the state of readiness of not only the current centre 21 but also the state of readiness of the other centres that are partners in the interaction.

The commitment of a set of parties to each other for interaction is accomplished via a locking protocol. The protocol is a variant on two-phase locking protocols for distributed database transactions. That is, each centre participating in the interaction is viewed as both a transaction (i.e. that must obtain locks for the specific interaction on all resources) and a resource (i.e. that must be locked by all transactions for the specific interaction). During the first phase, locks on all resources are obtained without releasing any locks. The second phase consists of releasing locks, without obtaining any new locks.A lock on a given resource may be obtained only if that lock does not create a conflict with a lock already in place on the resource; a lock does not create a conflict if the resource being locked is either committed to the same interaction (i.e. is itself in the locking phase of the interaction and thus committed) or is uncommitted but the given interaction is enabled. The interaction manager 36 uses facilities provided by the session manager 38 for establishing connections to remote machines, executing remote log-ins, and carrying out the basic lock and unlock operations required.

The locking phase is deemed complete when all necessary locks have been obtained or when any one of the necessary locks cannot be obtained. In the latter case, the unlocking phase is entered immediately. The success or failure of the locking phase is returned, i.e.

conveyed, to the action manager 34.

The action manager 34 re-invokes the interaction manager 36 to execute an interaction if the locking phase was successful.

The session manager 38 provides the actual communication services required by the interaction manager 36. Essentially, the session manager 38 has two operating modes, active and passive. When invoked by the interaction manager 36 to establish and manage a connection to another centre, the session manager 38 operates in the active mode. When invoked in response to a connection initiated by another centre, the session manager 38 operates in the passive mode. In either mode, the session manager 38 is driven by sets of rules that specify the response to the information received on the communication lines. For the active mode, the rules specify how to activate and control; communication means for connection establishment and termination; system log-in and log-out; remote lock creation/release; remote centre identification; and remote workstation activation.

The active mode of the session manager 38 is invoked with a set of rules specific to each operation. These rules define the criteria for success or failure of the operation, the result being returned to the interaction manager 36 upon completion of the operation. For each operation, a time-out may also be specified.

The passive mode session manager is invoked as a consequence of a connection initiated by another active mode session manager 38. The passive mode rule set specifies how to respond to the active mode operations defined above. These operation responses are: make the interrogated centre directory the current directory; create/release locks in local directory; identify the workstation, log-in-id, and local directory; activate the workstation; and quit.

The rule responses include an indication of the success or failure of the operation.

Upon activation, the session manager 38 checks the connection status and establishes a new connection if necessary. The appropriate rule set is then loaded and begins to interpret it. As characters are received on the communication line, the accumulated input characters are matched against the rule patterns. When a match is detected, the rule command is executed. The process continues until a quit command is executed or a timeout on the communication line input occurs.

When not provided in the host operating system 18, additional low-level communication facilities can be implemented in the session manager 38. Such facilities can provide means for locking and opening communication channels with remote workstations, configuring communication channels, transmitting and receiving characters over the channels and closing the channels.

As mentioned above, in the preferred embodiment, each centre 21 corresponds to a directory in the host file system 26 of the host operating system 18. All artifacts associated with a particular centre 21 are contained within this directory. Although the centre 21 has a title, in the preferred embodiment, it is actually the directory name that uniquely identifies the centre within the file system 26. Further, the workstation name and directory name, taken together, uniquely identify one centre 21 with respect to another centre. The directory name is made absolute and unique within the file system 26, whereas the workstation name may be either absolute or relative.

The partitioning of artifacts into individual files is, of course, a design choice that does not affect the logical behaviour of the system 10. Hence, the particular partitioning discussed for the system 10 is more a matter of the intended purposes thereof and performance than a general implementation principle. In general, the artifacts associated with a centre 21 include a role script, which is an optional artifact that defines how the centre behaves when operating by predefined rule. if this definition is absent, the centre is still capable of manually directed, i.e. extraordinary behaviour under user control, but cannot execute automatically. In addition, the artifacts include a neighbour file that describes the neighbouring centres, if any, giving their network addresses. This artifact is required if the role script has interactions.Also included as artifacts are an optional title file that contains the title of the centre, and perhaps help text describing the centre; and a status file that is generated and maintained by the co-ordination system itself, though subject to user modification. The status file contains current state information about the centre. Further, as artifacts, there are preferably several lock files that may be created in connection with the execution of interactions between neighbouring centres. These are used primarily to prevent clashes between concurrent activity and to ensure correct logical behaviour. Still further there is an enabled file artifact that is generated and maintained by the system 10. The enabled file also preferably, contains the names of the actions currently enabled based on the control state and content state of the centre.In addition, there is a contents directory artifact that is a required directory and wherein the objects that constitute the defined contents of the centre, as distinct from the centre artifacts that define the centre, are maintained.

Role scripts, in one embodiment, contain both organisational and computational information. The organisational information concerns the pattern of states, actions, and conditions that control the gross ordinary behaviour of the centre, and the connection of multiple centres in joint actions. The computational information describes what behaviour occurs during the execution of individual actions or interactions.

In one embodiment, these parts of the role script are intermingled and are logically inseparable. They are stored together in textual form in the role script file. Preferably, however, when operated upon by the user, they are normally displayed and edited differently. In the preferred embodiment, the organisational information is displayed graphically and is directly edited using a graphical editor, whereas the computational information is textual in nature, and is modified using a text editor invoked, for example, from the graphical editor.

Fundamentally, a role script is a set of state-action-state triples. Each triple specifies an action, together with the prestate that must hold for the action to be possible, i.e.

enabled, and the poststate that must hold if the action is successfully completed. Figure 3 illustrates a state-action-state triple as it might be stored in text form Figure 3A (in the role script file), and as it might be displayed by graphical editors, Figures 3B and 3C. This tri ple specifies that the action "housekeep" can occur only if the "start" state holds, and that the "endrole" state holds when "housekeep" is completed.

Multiple actions may have the same prestate and/or the same poststate. This usually causes them to be displayed together by the editor.

Individual actions may also have additional conditions imposed, in one embodiment, in either of two ways: by boolean expressions that are associated with the action, such that the action can occur only if both the prestate holds and the boolean expression is true; and by the action being specified as either automatic or user-active. These latter two conditions are both exhaustive andmutually exclusive, but they impose additional conditions that must be satisfied for the action to occur.

Thus, if the action is user-active, it can only be considered for execution if the user is present. Alternately, there may be circumstances wherein automatic actions are executed only in background processes, so that they do not compete for the process through which the user gains access to the machine.

An action may be joint, i.e. an interaction.

In such a circumstance the role script contains additional information about the neighbouring centre and the neighbour's name for the joint action.

Figures 4A to 4C show a sample role script having the following properties. When the centre is in the "start" state, any of three actions may occur, depending on the circumstances: (1) if the "closed" flag is set, the "re-open" action will occur. This may occur automatically, since the action is specified as automatic; (2) A request for services may be received through interaction "get request" with another centre (presumably a customer of this centre). If it does occur, the actions "process" and "reply" will then occur, assuming all goes normally. This entire sequence may occur automatically, since all three actions are defined as automatic. When the sequence has concluded (with the second interaction, "reply"), the centre is again in the "start" state; (3) the "housekeep" action may occur.This action, because it is user-active, occurs only through explicit user selection of the centre.

Associated with each solitary action or interaction, there is also computational information that specifies what occurs if this action is executed. This computational information is preferably expressed in the form of commands understandable by the command interpreter of the underlying host environment. However, some exceptions should be noted: solitary actions or interactions can also contain the interpreted commands "set", "unset", and "title"; solitary actions can contain the interpreted commands "userops", "superops", "exe crole"; interactions may contain the interpreted commands "title", "give", "get", and, in one embodiment, no host commands can occur in the specification of an interaction.

Figure 5 shows an example of a role script having a single action, for which the computational code is specified. The computational code includes both host commands and system commands. A number of special system commands are discussed hereinbelow.

"Userops Command": The userops command allows the definition of a single action in which the user may select from a number of operations, and perhaps apply the operations to a number of objects in the centre. This is appropriate behaviour in centres wherein the user maintains many objects without strong rules covering the sequence of operations that are performed. It is also appropriate behaviour for a centre that is not yet well defined as it allows highly flexible behaviour under user control.

The userops command has the syntax "userops (subdirectory) (operations file)". The entry of this command causes the display of a list of the objects in the indicated subdirectory of the centre and causes a situation-specific set of "user operations" to be made available to the user. These operations are defned in the indicated operations file, preferably the default is to return to userops. Thus, different userops files can exist for different actions in the role script.

Operations are specified in a userops file in terms of the command language of the underlying host operating system. Figure 6 illustrates a sample userops file.

Whenever the string "%f" is encountered in a selected operation definition, it is replaced by the name of the file on which the user has placed the cursor. This allows the selected operation to be applied to a specified object.

Similarly, the string "%d" is replaced by the full path name of the current directory.

Several special commands are preferably included in a userops file to control the behaviour of the userops facility itself: "wait" causes the screen refresh to be delayed until the user presses the return key, so that the results of the operation can be seen; "refresh" causes the lists of objects and operations to be updated; "done" asserts that by selecting this operation, the user has completed the current action of the role script; "quit" causes the current action of the role script to be exited without completion; subsequent invocation of the centre, however, continues the same action.

"Execrole Command": The execrole command provides for the existence of subcentres within a centre. Whenever this command is executed, it causes the execution of the ordinary behaviour of the specified subcentre. The syntax of this command is "execrole (subcentre name) (role script)". If the subcentre already has a role script, that script is executed, starting with the current state of the centre. If the subcentre does not yet have a role script, the indicated role script file is cop ied from the supercentre into the subcentre, and becomes the role script of the subcentre.

This arrangement provides a very convenient mechanism to treat centres as objects, and vice versa. A centre can contain objects, that may be regarded as subcentres. Thus, a subcentre might be passed into a centre as an ordinary object and then be made into a centre by an execrole command, that even has the effect of specifying a locally relevant role script, if the centre did not have a role script associated therewith. When the local role script has been completed, it can be removed and the subcentre passed on to another centre for additional work.

If a centre is permitted to contain subcentres capable of rule-driven behaviour, it is also preferable that a mechanism be provided that allows the user to engage in extraordinary behaviour in those subcentres. One such mechanism is the "superops" command "superops (subcentre name)", that invokes a standard supervisor (extraordinary operations) function, discussed herein, in the specified subcentre.

With regard to the neighbours file, when an interaction occurs in a role script, it names the neighbouring centre by a local label, as well as the neighbour's name for the corresponding action. For example, in Figure 4 the action "get request", which is an interaction with a neighbouring centre called "customer". "Customer's" name for the interaction is "giveit".

The neighbours file contains a mapping that specifies where such centres are, in reality, to be found. Thus, the entry "customer (node 5:/u/Jones/papers)" specifies that the neighbouring centre, locally known as "customer", is on a workstation called node 5 and is in the directory "/u/Jones/papers". The workstation name and directory name together constitute the location of the neighbouring centre. The directory name is an absolute, fully qualified path name within the file system of the specified workstation. The session manager 38 interprets the workstation name through reference to another table, called an address table, that maps such names as "node 5" into a full network address.

The title file serves two purposes, both of which concern the textual description of the centre itself. The first line of the title file contains the title of the centre by which the centre is ordinarily known to its user(s). The remainder of the file contains any desired textual description of the centre, suitably formatted for display in response to a "help" character ('?) inputted by the user.

The status file is not ordinarily created or manipulated by the user, but is formed by the system 10 itself. However, the user may manually change this information in order to adjust the state of the centre. the kinds of information normally found in the status file include: a "title: (as possibly modified by title commands; this is therefore distinct from the permanent title kept in the title file); "state", the name of the current state of the centre, as specified in the role script; and "enabled" a list of the actions currently enabled in the centre.

In the absence of a status file, the centre is assumed to be in the "start" state, but incapable of automatic behaviour. Automatic behaviour is possible only when a status file exists. Thus, the starting of even a fully automatic centre, nevertheless, requires a user action.

In one embodiment the centre artifacts include three files used in executing the interaction protocol. These artifacts record the presence of locks on the centre and the actions and interactions that are currently enabled in the centre. Alternately, these may be replaced with differently named files or may be combined as another centre artifact.

The enabled file lists all actions and interactions in which the centre is currently capable of engaging. It is produced every time the action manager recomputes a list of enabled actions. Since it duplicates information represented internally, its primary use is when the local centre is not actively executing an action and a remote centre attempts to engage the local centre in an interaction. The only interactions in which the local centre may engage are those listed in this file.

The offer lock file is, preferably, created by a remote centre. It represents an "offer" to interact with the local centre. Contained in this file is the local name of the interaction. The successful creation of an offer lock and the check that the interaction offered is enabled are two distinct operations; conceptually however, an offer lock may only be created if the interaction is enabled. An offer lock may be created only if a different offer is not already present.

The committed lock file is created by the local centre. This file contains the name of the interaction (or action, although the lock is not created for solitary actions) that the local centre is attempting to execute It is created during the locking phase of the interaction protocols. If an offer lock is present, the centre may only commit to the interaction identified in the offer. If, however, no offer lock is present, the centre may commit to any enabled interaction.

The lock files are removed during the unlocking phase of the interaction.

As discussed above, extraordinary operations are preferably available to the user, independently of the role script of any centre.

These operations allow the user to exert full control over the structure, contents, and definition of the centre.

Extraordinary operations have already been briefly discussed and this discussion relates to the structure of the machine or the artifacts used by the machine to exhibit centre behaviour.

Conceptually, it is arguable that many attempts at office procedure description languages, and similar ideas, have failed primarily because they have neglected to imagine an underlying system, capable of providing system-level facilities for exception handling, reorganisation, etc. The resultant need to define all exception cases and re-organisation cases as part of the definition of an application leads to combinatorial explosions. Although the features discussed here seem rather simple, these features are not considered exhaustive of the potential of the concept. They do, however, demonstrate the provision of system-level support for re-organisation and exception handling.

One kind of "extraordinary" capability is direct access to the host operating system, or command interpreter, of the host environment.

Since centres are implemented as directories in the underlying host environment, a centre can be created by simply creating a directory having an appropriate internal structure.

The creation of new centres can be accomplished either via the host environment, or by making use of host environment facilities available through a role script or a userops file.

For example, a common centre definition allows the centre to be a sort of container for subcentres. This allows the user to readily create or delete centres, see the status thereof, perform extraordinary operations on them, and start ordinary behaviour in them.

In one embodiment, separate command is provided in the supervisory mode for editing the role script. The role script can also be printed, if appropriate printing capability is available.

A sophisticated editor allows the user to construct and manage entire networks of centres, automatically maintaining both role scripts and neighbours files, so long as the centres remain within the same file system.

A separate command is provided in supervisory mode for editing the neighbours file. A separate command is provided in supervisory mode for editing the title file. The title file is simply edited with the user's preferred text editor.

A separate command is provided in supervisory mode for editing the default userops file, whose name is "userops". Other userops files must be explicitly named, or selected via cursor placement, if they already exist. Userops files are simply edited with the user's preferred text editor.

Ordinarily, the state of the centre is determined through execution of the role script, starting at the "start" state. However, the user may wish to specify a different starting state than "start", or to modify the current state extraordinarily. In such a case, the user edits the status file, changing the state: (current state) line to the desired contents. It is also necessary to remove any lock files that may be present.

Another operation that is commonly desired is to restart the centre from the "start" state.

While that can be done as specified above, a special command is provided, for accomplishing this function.

Miscellaneous additional capabilities are preferably provided to allow the user to perform extraordinary operations involving other centre artifacts. These capabilities include the ability to add new files, or directories, to eliminate extraneous artifacts via a "cleanup" facility defined in the user's profile, to delete files or directories, edit files or directories, page through files, re-name files or directories, and print files.

One particularly important kind of extraordinary capability involves communication between neighbouring centres. Such a communication may involve not only electronic mail, but movement of objects, telephone calls connecting the responsible actors, and even jointly controlled re-definition of centre-tocentre relationships.

Special commands are provided both to send and read extraordinary mail. When the user asks to send extraordinary mail, the user is provided with a list of neighbouring centres to choose from and is then allowed to compose a message.

Since centres can be defined as neighbours even though they have no interactions that are defined via role scripts, it is possible to use this mechanism to allow occasional communication among centres whose only connection is extraordinary. One example might be the connection between task centres, in general, and a monthly report or work-logging centre.

If it is not desired to define formal interactions between such centres, the user can still send extraordinary mail from the task centres to the monthly report centre, simply by defining the monthly report centre as a neighbour of each task centre.

With reference now to Figures 7 to 30, the operation of a typical system 10 is shown by means of the flow charts. More specifically, Figure 7 depicts a flow chart for executing the present system. Initially, the flow chart 42 is entered by, for example, a user logging on to a workstation having the system implemented thereon. As shown, if the system is implemented on a single centre only, the ordinary centre behaviour thereof is executed in accordance with flow chart 44 shown in Figure 8.

If, the system 10 operates on more than one centre the user may select a particular centre or enter a supervisory mode for extraordinary communication.

As shown in Figure 8 the flow chart 44 depicts the execution of ordinary centre behaviour whereupon the centre's role script, status, and title can be obtained from the file system. Subsequently, the enabled list of actions can be computed and execution attempted.

Figure 9 depicts a flow chart 46 (of Figure 8) for computing an enabled list as discussed above. Figure 10 depicts a flow chart 48 (of Figure 8) that generally depicts an attempted interaction whereupon, at the proper prestate according to a role script, the interaction attempt is made. When all necessary locks are secured the action is executed, if executable, and subsequently, all locks previously secured, are unlocked. As shown in Figure 11, the flow chart 50 (of Figure 8) demonstrates the flow of the execution of an actual action that, according to the commands in the action definition, the action manager can execute either the user operations manager 52, shown in Figure 12, or can execute special commands, or else pass commands to the host operating system. Execution of a single user operation is shown in Figure 12 via the flow chart 54.

Each command in the user operation definition is executed in turn. Special commands can invoke the supervisor (superops command) or the action manager (execrole) (54 -Figure 13).

All other commands are passed to the host operating system for execution. Exit functions are performed when all commands have been exhausted. The supervisory manager 56, shown in the Figure 14 flow chart, presents a menu of the centre artifacts to the user who then selects the particular artifact and operation or, at his choice, invokes the host operating system shell. When the user is finished with the extraordinary operations, the user selects "quit" and the supervisory operations manager is exited.

Figures 15 to 27 depict the various stages of the locking and unlocking steps in establishing communication between the two centres for the execution of an interaction.

The flow chart 84 shown in Figure 28 shows the establishing of a connection between two partners to an interaction by means of the session manager. The session manager is shown in Figure 29 via the flow chart 86. The passive mode of the session manager is shown via the flow chart 88 in Figure 30 and is invoked during automatic behaviour of a centre.

The system as described herein has a substantial number of major advantages over conventional operating environments. For example, in the present system every user is provided with a uniform interface and a uniform language for performing all operations required. In addition, by means of the extraordinary operations, tasks can be defined in an distributed fashion across a network and the actual tasks can be further distributed to those users actually assigned to execute those tasks. Further, by the use of task definition and defining of role scripts for various interactions required to accomplish defined tasks, the actual pattern of behaviour, including the concurrency of behaviour, of all users of the present system, can be co-ordinated and established to maximise the efficiency of the individual users. In addition, the provision of extraordinary operations allows the maximum flexibility to be provided to each user while nevertheless retaining the pattern of organisation necessary to carry out the defined tasks. Still further, by allotting to each centre a role script and providing that centre with all objects necessary to execute the task assigned thereto the difficulties involved with present shared files, shared data bases, and the like are eliminated.

Although the present invention has been described with reference to various embodiments, it will be understood that many other arrangements and configurations can be implemented which nevertheless do not depart from the spirit and scope of the present invention.

Claims (45)

1. A system for providing a workstation environment, the system comprising means for accepting an input from a user; and at least one centre, said centre being responsive to said user, said centre having one or more files exclusively associated therewith, said files having one or more objects stored therein, said objects being exclusively associated with said centre.

2. A system as claimed in claim 1 wherein one or more of said centres include a role script, each said role script defining at least one state-action/interaction-state triple.

3. A system as claimed in claim 2 wherein each said role script is stored in one of said files of said centre associated therewith.

4. A system as claimed in claim 2 further comprising a neighbour list, one said neighbour list being associated with each said centre.

5. A system as claimed in claim 4 further comprising means for enabling two or more neighbouring centres to interact, said enabling means being conditional on said interacting neighbours being in respective predefined prestates.

6. A system as claimed in claim 5 wherein said neighbouring centres each include a predefined poststate, said interacting centres entering said respective predefined poststate subsequent to said interaction.

7. A system as claimed in claim 4 wherein said neighbour list is stored in one of said files exclusively associated with said centre having a role script defining a state-interaction-state triple.

8. A system as claimed in claim 4 further comprising at least one lock file associated with each said centre having a role script defining a state-interaction-state triple.

9. A system as claimed in claim 8 wherein said lock file is stored in one of said files exclusively associated with said centre.

10. A system as claimed in claim 2 further comprising an enabled list, said enabled list including a list of the available actions of said centre.

11. A system as claimed in claim 10 wherein said enabled list is stored in one of said files exclusively associated with said centre.

12. A system as claimed in claim 1 wherein each said centre includes a status list, said status list including state information relating to said centre.

13. A system as claimed in claim 12 wherein said status list is stored in one of said files exclusively associated with said centre.

14. A system as claimed in claim 1 further comprising a contents list, said contents list being a directory of said objects exclusively associated with said centre.

15. A system as claimed in claim 14 wherein said contents list is stored in one of said files exclusively associated with said centre.

16. A system as claimed in claim 1 wherein said files exclusively associated with each said centre includes means for storing a role script, each stored role script defining at least one state-action/interaction-state triple; means, associated with each said role script having an interaction, for storing a list of neighbouring centres involved in each said interaction; at least one lock file for controlling mutual communication between interacting centres; means for generating and storing a list of enabled actions; means for maintaining a centre status list; and means for storing a list of said objects exclusively associated with said centre.

17. A system as claimed in claim 1 further comprising means for defining ordinary centre operations on each said centre, said definitions being stored in said files exclusively associated with each said centre; means for executing extraordinary operations on said files exclusively associated with said centre, said extraordinary operations include means for changing the information stored in said files.

18. A system as claimed in claim 1 wherein said input accepting means includes a workstation, and a host operating system, said host operating system being accessible by said user via an operating environment, said host operating system having a hierarchical file system defined thereby.

19. A system as claimed in claim 18 wherein said centres are stored in a directory of said hierarchical file system of said host operating system.

20. A system as claimed in claim 19 further comprising a plurality of said workstations, and means for establishing intercommunication between and among said workstations, said intercommunication establishing means including at least one communication link with each said workstation.

21. A system as claimed in claim 20 wherein each said workstation includes one, or more, said centres exclusively associated therewith.

22. A system as claimed in claim 21 further comprising means for defining at least one state-interaction-state triple for two or more different ones of said centres, and means for executing said interaction without the presence of a user at one or more said workstations having said different ones of said centres associated therewith.

23. A system as claimed in claim 20 further comprising means, associated with a preselected number of said workstations, for transferring centres between said workstations.

24. A system as claimed in claim 23 wherein said preselected number of workstations further include means for selectively including a predefined role script with said transferred centre, said role script being an integral part of said centre and defining at least one state-action/interaction-state triple for said transferred centre.

25. A workstation environment architecture, said architecture comprising a host operating system for storing at least one centre, said host operating system having a file system, and means for providing a uniform operating environment to a workstation user regardless of the characteristics of said host operating system.

26. An architecture as claimed in claim 25 wherein said file system of said host operating system is a hierarchical file system having said centres stored in a directory thereof.

27. An architecture as claimed in claim 25 wherein said uniform operating environment includes means directly accessible by said user, for providing access to any centres stored in said host operating system that are associated with said user, said means being adapted to allow said user to select one of said centres for operating thereon.

28. An architecture as claimed in claim 27 further comprising means for executing an action associated with a role script of said centre, said action execution means interfacing with said centre access providing means.

29. An architecture as claimed in claim 28 further comprising means for displaying a list of objects associated with said centre and selecting an operation on said objects, said object list displaying and operation selecting means interfacing with said centre access providing means and said action execution means.

30. An architecture as claimed in claim 29 further comprising means for executing operations unspecified by said role script.

31. An architecture as claimed in claim 30 wherein said unspecified operation execution means interfaces with said object list display and operation selection means and said centre access providing means.

32. An architecture as claimed in claim 31 further comprising means, associated with each said uniform operating environment providing means, for establishing communication between and among a plurality of said uniform operating environment providing means.

33. An architecture as claimed in claim 32 further comprising means, interfacing with said communication establishing means associated with each said uniform operating environment, for executing an interaction defined by associated role scripts, each said interaction executing means interfacing with said action execution means associated with said role scripts.

34. An architecture as claimed in claim 25 wherein said uniform operating environment means includes a window manager, said window manager interfacing with said host operating system; a user interface manager, said user interface manager interfacing with said host operating system and said window manager; a supervisory operations manager, said supervisory operation manager interfacing with said host operating system, and said user interface manager; a user operations manager, said user operations manager interfacing with said host operating system, said supervisory operations manager and said user interface manager; and an action manager, said action manager interfacing with said host operating system, said user operations manager and said user interface manager.

35. An architecture as claimed in claim 34 further comprising an interaction manager, said interaction manager interfacing with said host operating system and said action manager; and a session manager, said session manager interfacing with said host operating system and said interaction manager.

36. A method for providing a workstation environment, said method comprising the steps of providing a multiplicity of workstations; defining a plurality of roles, each said role representing an assigned responsibility, defining, for each said role, a centre, each said centre being provided with all objects needed to execute said assigned responsibility; and distributing said roles and said centre associated therewith to said workstations.

37. A method as claimed in claim 36 further comprising the step of providing each said workstation with exclusive access to a dirctory of a hierarchical file system.

38. A method as claimed in claim 37 further comprising the step of storing said centres associated with each said workstation in said directory of said hierarchical file system associated with said assigned workstation.

39. A method as claimed in claim 36 further comprising the step of defining, for preselected centres, a role script, said role script including at least one state-action/interactionstate triple, said role script being distributed integrally with said centre.

40. A method for providing a workstation environment, said method comprising the steps of providing a multiplicity of workstations; defining a plurality of mutually dependent tasks; storing said task definitions according to whichever workstation said task definitions are defined upon; distributing said task definitions throughout said workstations according to the location of said workstation where said tasks are to be performed; and providing, at each workstation, means for executing said tasks distributed thereto according to said task definitions.

41. A method as claimed in claim 40 further comprising the steps of changing at least one of said task definitions; and redistributing, in response to said changed task definition, said task definitions and said means for executing said tasks.

42. A method as claimed in claim 41 further comprising the steps of providing at least one state-action/interaction-state triple for selected ones of said defined task definitions; and distributing said state-action/interaction-state triples with said task definitions.

43. A system for providing a workstation environment substantially as herein described with reference to the accompanying drawings.

44. A workstation environment architecture substantially as herein described with reference to the accompanying drawings.

45. A method for providing a workstation environment substantially as herein described with reference to the accompanying drawings.