WO2005073848A2

WO2005073848A2 - Computer operating environment

Info

Publication number: WO2005073848A2
Application number: PCT/GB2005/000334
Authority: WO
Inventors: George Svarovsky
Original assignee: Id Business Solutions Ltd
Priority date: 2004-01-30
Filing date: 2005-01-31
Publication date: 2005-08-11
Also published as: WO2005073848A3; GB0401972D0

Abstract

This invention provides an operating environment in which logical objects of the operating environment are stored in a relational database. In an operating environment embodying the invention, each object may include data, executable code or both. In this context, 'data' can include substantially anything that has information content. This might include text data (e.g. a document encoded in text format), binary data (such as an image or a sound), program source code, executable code, and so forth. In this context 'executable code' may include compiled machine code, script code for execution using an interpreter, or source code for compilation prior to execution, for example, by a 'just-in-time' compiler.

Description

Computer Operating Environment

This invention relates to a computer operating environment.

The prime purpose of a computer operating environment is to enable a user to use a computer's hardware to do useful work. Traditionally, operating environments maintain logical objects divided into two broad classes. The first of these classes contains objects upon which operations can be performed, and that are generally referred to as "data". The second of these classes contains objects that can perform an operation on a data object, and can be generally referred to as "programs" or "applications", depending upon context.

This split between applications and data is somewhat artificial because most users are interested in working with data, and are concerned only incidentally with the identity of the applications that will effect the work. Therefore, some modern operating environments have gone some way towards hiding this split. This is typically done by classifying data objects into types, and for each type associating one or more programs with the data object type. A user is then given the option of activating one or more verbs associated with the application (for instance, by way of a graphical user interface), the operating environment then activating the program appropriate to the verb and file type. While this gives the user the impression that the data objects themselves are

active objects, the underlying operating environment maintains a strict distinction between program and data objects.

To achieve this, a typical operating environment provides a filesystem in which objects of all types can be stored as files and a process controller that controls the execution of program objects. A particular problem that this causes is the complexity of the filesystem. As computer systems become more complex, the size of the complexity of the filesystem also increases; this causes real problems, both to users and to the system itself, in that it becomes increasingly difficult to locate any particular object within the filesystem. This difficulty is such as to impose a considerable and ever-increasing limitation upon the performance of a computer system and of the ability for a user to locate specific data objects.

An aim of this invention is to provide an operating environment that mitigates limitations of known operating environments.

This invention provides an operating environment in which logical objects of the operating environment are stored in a relational database.

Embodiments of this invention provide many advantages over an operating environment in which the objects are stored in a filesystem, as will become apparent.

In an operating environment embodying the invention, each object may include data, executable code or both. In this context, "data" can include substantially anything that has information content. This might include text data (e.g. a document encoded in text format), binary data (such as an image or a sound), program source code, executable code, and so forth. In. this context "executable code" may include compiled machine code, script code for execution using an interpreter, or source code for compilation prior to execution, for example, by a "just-in-time" compiler. In addition, one or more objects may include metadata. This is data that describes the content of the objects. For example, the metadata may include one or more of:

• definitions of the type or nature of the data; • definitions of actions that can be performed on the data;

• identification of program code that can be invoked to perform actions on the data;

• definition of rights of access to the data; and

• definition of a programmatic interface to the object.

amongst many other possibilities.

It should be noted that embodiments of the invention allow all objects (or, at least, all objects with which an user can interact) to have associated metadata. This allows a wide range of objects, from an atomic piece of data to an entire database, all to have metadata associated with them. This is in contrast to a traditional operating environment in which the metadata are either presented as an application program interface that a programmer "hard coded" into an application, or in more modern operating environments, stored in a MIME- type or system registry.

As is well-recognised, the data in a relational database is stored in one or more tables. Each data object may comprise information that is stored in more than one table. This allows objects to be re-used easily and cross-table links can be used to implement inheritance among objects.

Object-oriented data is very different in nature to relational data stored in a database. Therefore, a typical embodiment of the invention includes a persistence layer that handles the exchange of data between objects and the database. For example, the open-source persistence layer known as "Hibernate" has been found to be useful in this regard.

An operating environment embodying the invention typically includes an application that a user can use to manipulate objects within the operating environment. For example, such an application will typically present a user with a view of objects, shortcuts to objects represented by icons. The browsing application may also represent folders as icons, each folder object being capable of storing one or more shortcut to an object or folder.

Embodiments of the invention can be implemented on top of an existing operating system, within a virtual machine or, alternatively, as a complete system that can be loaded at boot time. A particularly preferred implementation is implemented in Java to execute within a Java runtime environment. This ensures that the operating environment and objects within it can execute on a wide range of hardware platforms.

It is preferable that, within the operating environment, all objects can be identified by a URL. This is a convenient and consistent way to identify objects. It also makes manifest the interrelation between objects since the structure of a URL is indicative of the position of the object within a hierarchy of objects. Moreover, any object can refer to any other object by reference to its URL. In such embodiments, it is advantageous that all objects irrespective of their type (executable, data, etc.) exist within a common hierarchy.

An embodiment of the invention will now be described in detail, by way of example, and by reference to the accompanying drawings, in which:

Figure 1 presents a list of iconic symbols that will be used in subsequent figures;

Figure 2 is a block diagram that shows the principal components of an operating environment embodying the invention; Figure 3 is a block diagram showing the main interface components of the operating environment of Figure 2;

Figure 4 is a block diagram that shows library components of the operating environment of Figure 2;

Figure 5 is a block diagram of a kernel layer of the operating environment of Figure 2;

Figure 6 is a diagram illustrating metadata components associated with objects in the embodiment of Figure 2;

Figure 7 is a diagram illustrating standard executables that are provided in embodiments of the invention;

Figure 8 is a diagram illustrating components related to security and authentication in an operating environment embodying the invention;

Figure 9 is a diagram illustrating the disposition of commands and executables within the operating environment of Figure 2;

Figure 10 is an annotated screenshot of a user interface of an operating environment embodying the invention;

Figure 11 illustrates persistence layers that are logically disposed between an application and a system database in an embodiment of the invention;

Figure 12 is a screenshot of an AppObject browser application, being a standard component in embodiments of the invention; and

Figure 13 is a screenshot of the explorer, being a component of the embodiment of the invention.

This embodiment is implemented in the Java (r. t. m.) language. As such, it can execute in any runtime environment that is capable of executing compiled Java code. For example, it can execute within a Java virtual machine that is itself executing on any one of a number of operating systems.

Within the operating environment, the basic units of information with which the user interacts are objects disposed within an object hierarchy. Additional objects may be stored outside of the hierarchy. Moreover, there may be more than one hierarchy in separate namespaces. Any object can be identified by a unique uniform resource locator (URL).

Structure of the operating environment

As shown in Figure 2, the operating environment comprises a product layer 10 with which a user can interact. The product layer 10 stores user-created forms, executables and application objects. In addition, the user has access to standard executables 16 provided by default with the system. These include an application object browser, tools and utilities, standard forms for creating objects, and a gateway to act as an interface for the user and to enable connections to be made to remote systems.

A session interface layer 20 provides an interface between the product layer 10 and an underlying session implementation 22, which will be described further with reference to Figure 5. The session interface layer provides various modules that can be accessed by the product layer to provide its functionality. These include interfaces for executables, security, persistence, the scheme and namespaces. In the context of this embodiment, the scheme provides access to data-level, object-level and application-level metadata. Since this is central to operation of the operating environment, in this embodiment it is cached in memory. Note that the scheme is not equivalent to a database schema. A database schema is a logical grouping of tables (with columns, keys, triggers etc.), procedures, views, sequences and so forth — metadata relating to the database. In the context of this invention, the scheme also contains metadata, but it reaches higher into the application space rather then trying to exhaustively describe the data structure. There is overlap between a schema and the scheme, but only so much as is useful.

In addition, the operating environment comprises library components 24 that are available to all layers of the system. The library components 24 provide functionality that is required to support operation of the operating environment. For example, these include an application workbench, procedures for maintaining persistent objects, a forms framework, graphical controls, system components for bootstrapping, exception handling and URL processing, and utilities for controlling and maintaining the operating environment.

With reference to Figure 3, the interface provided by the operating enviromnent will now be described. The interface is provided by a complex collection of interacting modules, the detail of which goes beyond the scope of this description.

The principal library components included in the operating environment are illustrated in Figure 4. Separate libraries provide functions that implement the internal functionality of the operating environment and that implement the graphical user interface with which the user interacts, these including both general components and components specific to the operating environment. A general library 40 provides general utility functions (e.g. for file manipulation), data transfer utilities including data pipes, and a workflow engine to manage processing of multi-process tasks.

General GUI libraries provide a forms framework that implements an XML- driven GUI system. These include standard GUI controls (graphical objects such as text and number boxes), standard validators for checking and validating data entered by the users, and libraries to implement user- configurable look and feel.

Of greater significance are the system-specific modules 42; these provide the special functionality that is required to implement the invention. These include a set of core utilities 44 to implement Exception handling, URL processing, standard business rules, and standard permissions. A set of GUI extension routines 46 provide additional GUI functionality specific to implementations of the invention. These include data-bound controls for viewing database data, namespace-bound controls for viewing data hierarchies; standard dialog boxes, for example for use during user login or selecting data; and data models for use by GUI controls.

Provider implementation modules 48 provide a default scheme implementation, default security implementation, and default namespaces, for example, for modules, AppClasses and AppObjects. AppClasses and AppObjects, will be described fully in due course. Put simply, an AppClass describes a particular business object type in terms of its properties and behaviour (e.g. business rules); it holds metadata about that class of business objects. An AppObject is a particular business object instance in the system holding real data. Utilities 50 are provided also for working on AppObjects. These include AppObject Graph Walking for traversal of complex object relationships and modules for importing and exporting AppObjects to and from XML. Support modules, including folders and shortcuts 52 for the workbench system (to be described) are also provided.

Figure 5 illustrates the components of the database kernel 22. Access to the kernel is achieved through the session interface layer 20, the kernel effectively implementing the services exported through the interface layer.

Figure 6 illustrates metadata components used in the embodiment. Metadata plays a central role in the operation of the operating environment, and exists in many different levels and forms. The principal types of metadata are application-specific metadata 60, bootstrapping metadata 62, scheme (core) metadata 64, and security metadata 66.

Core metadata 64 includes data-level metadata 68, application-level metadata 70, and object-level metadata 72. The data-level metadata 70 resembles the metadata present in most database systems. This includes, for example, a description of data tables (their columns and keys). The application-level metadata 70 describes verbs, applications and namespaces that can be applied by the operating environment. This defines the actions (verbs) applicable to objects and specifies the application that will be invoked to perform the action. Object-level metadata 72 defines AppObjects in tenns of the underlying data and business rules and properties of the data.

Security metadata 66 describes the users who are authorised to use the operating environment in term of their roles and permissions to access data within the operating environment.

The embodiment of the invention will be provided with a set of standard executables 16 (introduced in Figure 2) to enable it to perform its function. These executables rely upon the libraries 40, 42 described above with reference to Figure 4. These executables will be described in greater detail with reference to Figure 7.

Three standard objects include an AppObject browser 80 for browsing and modifying single data records, a gateway 82, which is the standard entry point for an end-user system, and standard forms 84 for metadata browsing and administration. These make use of the GUI functions provided by the libraries 40.

Further objects are provided for administration of the operating environment. These include an application 86 for importing and and exporting objects to and from XML files. This makes use of import and export functions provided in the libraries 42. Also included is a command-line interface 88 through which low-level administration functions can be performed.

Embodiments of the invention are also provided with developer tools, although these will typically be made available for only a limited range of users of the operating environment, as defined in the security metadata 66. These allow a developer to create custom extensions of the operating environment. The tools include a scripter 90 that integrates data and metadata development, a class registration wizard 92 for creating and registering new persistent classes, and an application registration wizard 94 for registering new applications within the operating environment.

Given the complex series of relationships that can exist between users and objects within the system, several security modules are provided for handling of security and access permissions. The arrangement of these modules is illustrated in Figure 8.

At a low level, the security modules use PAM (pluggable authentication modules) 96 to perform authentication requests. The wide range of readily available modules allows a wide range of authentication techniques to be used, as appropriate to a particular application of the operating environment. For example, Windows NT (r. t. m.) domain, LDAP, biometric or Oracle based authentication may be provided, with additional modules being added as new authentication techniques become available.

Granting of permissions is handled by a Java Authentication & Authorisation Service (JAAS) layer 98. Operation of the JAAS layer is controlled by a policy object 100. The policy object 100 itself is configured through the security interface module 102 within the session interface 20.

Within the context of the security interface module 102, each user 104 is defined by one or more principals 106. A principal 106 is a representation of a user in the context of a particular authentication module, thereby allowing a user to be assigned different permissions and different authentication modules in different contexts. Each principal 106 defines a series of roles 108 and permissions 110 in the context of each role 106.

The configuration of commands and executables within the operating environment is illustrated in Figure 9. This will be described with reference to a user executing a command, as illustrated at 120. A user issues a command by activating an object (e.g. via double-clicking on it), rather than by invoking a separate application or other executable.

Execution is handled by a default implementation 122. This refers to the application-level metadata 70 to determine the identity of the executable to be invoked. The application-level metadata 70 describes relationships between verbs, objects and applications. The default implementation identifies the executable appropriate to perform the action on the object.

It is important that the command is decoupled from the executable that is used to perform its action. The user issues a command, but the operating environment decides how it should be performed with reference to metadata. Moreover, execution of commands is context-dependent.

A user may extend this framework by writing custom command implementations. This make be required for complex decision-making processes or if there is a requirement to enhance or extend the contextual information that the operating environment uses by default.

From the point of view of a user, the operating environment provides an interface that is fundamentally similar to that provided by a graphical file manager in a conventional operating system. In the context of this invention, the interface is referred to as the "gateway" and this is illustrated in Figure 10.

As illustrated in the screenshot in Figure 10 in this embodiment, the gateway includes a workbench area 134 within which objects can be stored, the objects being represented as icons visible in the desktop region.

A taskbar 132 is displayed adjacent to the desktop. The taskbar contains links to applications and shortcuts to objects.

A general discussion of the operation of the above components will now be presented. Introduction

Objects within the operating environment are made persistent through storage of the data and metadata associated with each object in a relational database. In this embodiment, object persistence is performed by a persistence layer, which exposes an API that can be used by objects to store, recall and modify their data. This means that neither an application developer nor the object itself need be aware of the format or query language of the underlying database (typically, this will be SQL). This is a concept used heavily in J2EE EJB applications and provided for in Microsoft's .NET Persistence API. The use of object persistence does not mean that the database can no longer be accessed directly. While the persistence layer automates the generation of most SQL statements, the underlying JDBC connection can be exposed to allow "hand- written" SQL when necessary. As illustrated in Figure 11, the embodiment provides a persistence layer with which applications can interact at a high level. This communicates with the database through a persistence layer, both of these layers being implemented in Java.

Executables

In the context of the embodiment, an executable is analogous to a Windows ".EXE". An executable is an application within the context of the embodiment. There are two types of executable: in-framework executables and out-of-framework executables. An in-framework executable is launched by the system using its execute() method. It is always launched from the gateway or another application. An out-of-framework executable is launched externally via its main() method, as with a conventional application. It can be run as a standalone application using the operating environment as a library.

In-framework executables are intended to be launched from within the framework provided by the embodiment. This ensures that they can be launched from any generic in-framework application and integrate well with the operating environment's gateway and other applications. An in- framework application can be launched as the first application to appear after login by passing a suitable URL to the login process.

Out-of-framework executables are used when the application is to be launched independently of the operating environment - i.e. with its own login mechanism and initialisation code. (It is possible for an executable to be both in-framework and out-of-framework by simply implementing both methods.)

An example application is the gateway, which is provided as a standard component of the embodiment. A screenshot is shown in Figure 10. The gateway is an example of an application that is both in-framework and out-of- framework. The gateway typically serves as a default application that is launched from the login dialog box. (The default application can be configured in the operating environment's in-database metadata.) Within the operating environment, the URL of the Gateway is WorkBench/Gateway.

An alternative example is the AppObject browser (of which Figure 12 shows a screenshot). The AppObject browser is a general-purpose record sheet browser as an instance of the class AppObjectBrowser. It uses the operating environment's XML forms framework to dynamically build screens for record sheet input. All the form structure, layout, text, and controls, plus the way they interact are described in metadata. It does not normally make sense to view an isolated record sheet outside an application. Therefore, the AppObjectBrowser is implemented as an in-framework application only (A separate wrapper is available to launch AppObjectBrowser out-of-framework for development purposes). The AppObjectBrowser also sits under the WorkBench module and its URL is: WorkBench/Browser.

Some other executables provided within the embodiment will now be described briefly.

• Ixport is a combination of import and export. It converts objects to a general-purpose XML fonnat and vice-versa. In some embodiments, part of the install process of the operating environment uses Ixport to import its data (an alternative would be to use a set of SQL scripts generated from Ixport data).

• CommandPrompt is a tool that executes URLs as they are typed in. If a user wishes to launch the AppObjectBrowser or another WorkBench, this can be achieved by typing the URLs given above in the CommandPrompt.

• Scripter is a database administration tool for the operating environment that is used for building and maintaining schemas. It manages the running of both SQL and Ixport scripts together in a single tool. It is not a schema design tool but simply a runner of scripts.

Verbs and Applications

In the context of embodiments of this invention, a verb is a description of an action with a unique meaning. A verb describes an action in the operating environment that gives rise to a command. It contains a name, a user-readable description, a unique meaning (which can be expressed as an English- language verb in lower-case), and a command Java class to use. The name of a verb name does not necessarily have to match its meaning. This would be the case in a non-English language installation (the meaning is always given in English, for comparability between databases). It is also often true of the "default" Verb, for which the name "Default" would be unhelpful. This embodiment uses the word "Open" to describe the default action.

Verbs can be associated with Java classes. This process of associating a verb with a particular Java class is at the heart of the command architecture. Effectively, it is metadata that says "these are the things you can do with (or to) this particular object". The way that the operating environment decides what can be done is by checking which verbs are associated with the Java class of the object in question.

A verb can create a single command class. It is a common paradigm in the operating environment that a registered metadata object is used to describe and create instances of a Java class implementing a particular interface. For example:

• AppClasses describe and create objects implementing AppObject;

• Types describe and create values (which do not have a specific interface);

• Verbs describe and create objects implementing Command; and

• Applications describe and create objects implementing Executable.

When a verb is used to create a command, the operating environment can then execute that command. This requires two steps because once a command is created, it can be executed more than once. This is more efficient, but also the identity of the command object may be useful to whatever code finally performs the required action, and can be used to further customise behaviour.

Object Persistence

Of great importance to the operation of the embodiment is the concept of persistence. A particularly onerous part of developing conventional database applications is writing and managing all of the code required to access an underlying database. To simplify this task, embodiments of the invention provide an underlying persistence layer to take care of this task in a transparent and automated manner. The persistence layer must transform a relational paradigm (at the underlying database) into an object-oriented one (the operating environment objects). This is referred to as object-relational mapping. Persistence layers are already known, and the invention may be implemented using a commercially or freely available persistence layer product. This specific embodiment uses the open-source persistence layer known as "Hibernate", which is implemented in Java.

Object-relational mapping supports object-oriented concepts such as inheritance and polymorphism, in a database enviromnent that allows data to be stored in a database using a transactional model, and supports queries using a query language such as SQL.

One of the strengths of the persistence layers is the ability to encode the storage of objects into database tables using a flexible mapping (for example as an XML file). This decouples the application from the database structure and allows the database schema to be changed without changing application code. For example, renaming a column is just a change in a single mapping file. Such portability and ease of change is advantageous when working with products that must satisfy more than one database vendor, or if site-specific customisation is required. Also important is the ability to generate SQL appropriate to a particular database system. The persistence layers generate different SQL depending on which database is configured. This is important to take account of vendor-specific syntax (e.g. sequence generation) and variations from the ANSI SQL standards.

In conventional applications, business rules and logic are often encoded inside database stored procedures. This has the problem that these procedures are usually written in a database-specific language (e.g. PL/SQL) and run inside the constraints of the database machine. In addition, most end-user applications need to express these rules to the user and therefore duplicate the procedures that allow and check data in application code. The use of stored procedures has other problems such as the difficulty in batching up requests with some database access technologies. Maximum performance is usually gained by bulk INSERT or UPDATE rather than repeatedly calling a stored procedure. Limitations on the sizes of procedure arguments preclude most batching approaches.

Persistence layers are designed to make persisting objects to the database easy, so that the natural place to put business logic is inside the business objects layer itself. This reduces duplication and provides greater flexibility. Batching is facilitated because all of the logic processing has been done before the database is contacted. The persistence system ensures data integrity by implementing optimistic locking. In optimistic locking there is no explicit lock on the record, but the persistence system has some way of knowing whether an object has been changed by another process when an attempt is made to save it. If a change has occurred, an error is presented to the user, usually instructing them to reload the object and make their changes again. In the Hibernate provider, a table can contain an explicit version or modified time column, which is used by Hibernate to determine if the object has been updated.

Metadata

The concept of metadata is of particular importance in embodiments of the invention. Metadata allows applications to understand, manipulate and present data without being specific as to its structure. Its philosophy is the direct opposite to hard coding, in which the configuration of the data dictates the program code. When an application is designed, there will be a set of business objects and their associated data tables. For example, in ActivityBase (a known database system) there are Studies, Protocols and Tests, and the tables STUDY, PROTOCOL and TOCCASON. As the design evolves, it usually becomes clear that other secondary objects are needed, which also persist into tables, to describe, for example, application state and configuration information. It is this secondary data that is called metadata.

In embodiments of this invention, the metadata is far more extensive and . pervasive than in a typical existing application. The design aim is to describe as much as possible in metadata; everything from the data structure through object model to application state and GUI layout.

In ActivityBase, there is provided a generic control that displays a little icon beside each field on a form that represents a link from one object to another, for example a "Study" field on a "Protocol" form. This control allows a user to drag and drop a selected item, and also to directly open it in its own form by double-clicking. However, everywhere that this control is used, it is initialised with its displayed type in the code that is specific to that form. Therefore, in the code for the Protocol form, there is code relating to the Study field that tells the the control that it is displaying a Study. In a typical real-world application, there may be tens of places where there is code that says, in one way or another, that the "Study" field of "Protocol" is of type Study. In embodiments of this invention, that information is encoded in one place — in the Metadata - and is made available for any application's code to use. The aim is to store the metadata centrally, and store it once only. Since the metadata describes the data and the applications that use the data, in this embodiment it is stored in the database itself. Predominantly, this is stored in the database, where its integrity can be assured. An exception to the aim of storing metadata centrally in this embodiment is that form data is stored in XML files with the application code, because this is more convenient in implementation of the operating environment and for form designers.

This embodiment of the invention provides four levels of metadata: data, object, applications, individual application.

Data-level metadata includes mapped tables and their contents, and is intended for use by query tools and metadata management tools. Low-level detail of the tables is accessible instead through the JDBC driver.

The object-level metadata includes mapped Java classes - their persistent properties, property types and how the classes map to data within the database. This is the level of metadata at which applications can find out about business objects in the operating environment, the properties that these objects have and how the objects relate to one another.

An example of how this might be used is in displaying a form. For each field that needs to be displayed, the application can determine from the metadata which control to use, based on the type of the relevant property; for reference fields it can provide click-through and drag-and-drop functionality. An object of central importance to this embodiment is the AppObject. Within the embodiment, all persistent Java objects must implement an AppObject tag. Each mapped object is described by an AppClass (a compaction of Application Class) and each persistent field is described by a property. AppClass and Property combine the functions of Java "reflection" (Java's own metadata system) with information relating to how objects are persisted, and add some detail specific to the embodiment such as descriptive names for each property. AppClass is therefore a repository for information about business objects.

Application-level metadata includes applications, mappings of Java classes to available verbs, mappings of verbs to applications, and namespaces. It is intended for any application that can run (or uses components that can run) other applications. The Command and Namespace architectures, which will be described, require metadata to detennine what to run and what to identify (respectively) when they are invoked. These services provide a base level of decoupling similar to a shell execution mechanism and filesystem in other operating environments.

Individual application-level metadata includes an individual application state, application options, and anything else that an application must store other than actual data. It is intended for use by the application that defines it and components of it. It is accessible through the application, not through the scheme. An individual user's workbench contents are an example of application-level metadata.

Within the scheme (as described above) AppClasses and applications are classified into modules. Each module is a logical grouping of related functionality. The structure of the scheme can be viewed in the explorer. Modules are an entirely logical way of categorising the metadata in the scheme. At this level the scheme stops, and it becomes the responsibility of an individual application to maintain its own metadata. That does not mean the application must do this independently. The recommended approach is to store metadata in the database using the persistence mechanism provided by the operating environment. In other words, the application should define AppObjects for its metadata and map the data to tables as though they were real data.

Retrieving information from the database

As is standard in the use of databases, information is retrieved from the database by use of queries. This embodiment provides several different types of query that can be used to retrieve data: loading a single object by its ID, using the query interface, using a provider query, and using the JDBC driver.

Generally speaking loading a single object by its ID is only used by an application to reload an object it already has in memory, whether to recover the latest state from the database or simply to make sure that it has the right object for the current connection. For example, if it has the Study "my Study" already loaded, it might use the following code to reload it:

myStudy = connection. load (Study. class, myStudy.getld ()) ;

This type of query has a simple syntax, but the method must be passed an identifier such as a database key that is meaningless to a human. Its versatility is also limited: it cannot be combined with multiple qualifiers and it only can make use of one operator: equality.

The query interface provides a more versatile and powerful query mechanism. The query interface is created as a Query object within the operating environment. In this embodiment, the query interface supports queries on any property of an AppClass; various operators; aliases; joins; distinct results; grouping and ordering; row count and first row; timeout; bind variables; compilation; and list, iterator and cursor return types. Other embodiments may extend or restrict this list. It is possible to construct a query object independently of a database connection, and then execute the query against one or more particular database comiections. Moreover, many methods of the query object return a query object, thereby allowing query methods to be executed in a chain.

Provider queries allow the provider-specific query language of the underlying database system to pass into the execution environment. These may allow an application to take advantage of database provider-specific features not available through the query object interface. However, their use limits the generality of any application that uses them to an operating environment that uses a specific underlying database.

JDBC driver queries are implemented by use of a connection object that offers an application access to an underlying java.sql.Connection. This is provided for use only on occasions on which no other way of achieving the required result can be achieved because it does not take advantage of the services offered by the operating environment, may result in incompatibilities, and does not guarantee future operability.

Namespaces

Namespaces allow representation of complex object relationships as a hierarchy and are defined in metadata. The URLs previously discussed use namespaces, and every object within the operating environment may have its own namespace. When applied to an object, the namespace defines its children and its canonical parent.

The aim is to apply a namespace to any object, even ones that have not been implemented within the operating environment. For example, a Java File object may have children if it is a directory. It could also have children if it is an XML file (the nodes). The nodes themselves, read in as DOM Node objects, also have children, and so on. Therefore the approach in this embodiment is to query the metadata for a namespace that applies to a particular object. How that namespace is determined is decided by the provider.

Modules, Applications, AppClasses, and AppObjects have namespaces by default. Identifying an AppObject by URL is a common use of namespaces.

The namespace system is a way of decoupling knowledge of object children and parents from the object's implementation. In other words, code that navigates through hierarchy described by the namespace system does not need to know anything about the objects it is navigating. This is advantageous because usually it is only the final target of the navigation that is of interest.

The Command Prompt

The command prompt is an application that is installed by default that can be used to execute arbitrary URLs. What is meant by executing a URL is something quite complex. However, the outcome is the same as if you were to execute a DefaultCommand with the target of the URL passed as its target thus:

new DefaultCommand 0.execute (keystone, new CommandArgument [ ] { newCommandArgument (theUrlTarget) });

It is also possible to specify the verb you want to use when executing the URL, as in the following example:

Product /Product /Gas+Lift+Chair#verb=edit

The Workbench System

To understand the function of the workbench system, it is useful to draw analogies between an operating environment being an embodiment of this invention and a conventional operating system (such as Microsoft Windows (r.t.m.)). These analogies are set forth in the table below.

The bold items in the lower right-hand corner of the table are implemented by the workbench system.

Relational data can have complex internal relationships that are hard to visualise in a user-friendly manner. To apply the philosophy of the invention to this visualisation, it is business objects that should be represented, not the data that lies beneath the objects. Therefore, there is provided within the workbench system an application known as the explorer, shown in Figure 13, as has been discussed. The aim of the explorer is to provide an application that can display all objects in the environment, reference any object in the environment by shortcut or URL, and manage object references into arbitrary folders.

The explorer displays items, shortcuts and folders. An item is anything with a name and an icon; a shortcut is a reference to anything; and a folder can contain items, shortcuts, and folders. In this embodiment, all of these are AppObjects. Within the gateway, a user workbench, at 134 provides a region within which a user store and arrange shortcuts to objects upon which they are working. In this embodiment, the workbench 134 appears in the bottom right pane of the Gateway.

In order to arbitrarily categorise objects in the operating environment, a user must have a way of referencing the objects. This is already provided for in the form of URLs, but the user must be able to save the URL. This is done by having an AppObject, with the URL as one of its fields. There are times when the user may want to present the impression that the reference (described above) is actually the object it references, and, at other times, treat the reference as an object in its own right. The former are items, the latter shortcuts. Only shortcuts can live in folders, which constitute the customisable hierarchy. Both can also have icons associated with them. This closely parallels a filesystem.

The main task tree of the gateway is shown at 132. It typically contains shortcuts and folders. The main task tree is fully customisable by virtue of being a folder that contains subfolders and shortcuts. Shortcuts can be added to, removed and generally changed within the folder. The namespace hierarchy can also be viewed by an explorer tool 136. Like the workbench, the main-task tree also consists of shortcuts. These are also configurable but typically are shortcuts to applications rather than objects. The main-task tree may be controlled by an administrator rather than an end-user.

Claims

1. A computer operating environment in which logical objects of the operating environment are stored in a relational database.

2. A computer operating environment according to claim 1 in which an object may include data, executable code or both.

3. A computer operating enviromnent according to claim 2 in which data can include substantially anything that has information content.

4. A computer operating environment according to claim 3 in which data can include text data, binary data, or program source code.

5. A computer operating environment according to claim 4 in which executable code may include compiled machine code, script code for execution using an interpreter, or source code for compilation prior to execution, for example, by a "just-in-time" compiler.

6. A computer operating environment according to any preceding claim in which objects are described by metadata that describes the structure of the object.

7. A computer operating environment according to claim 6 in which the metadata includes one or more of: definitions of the type or nature of the data; definitions of actions that can be performed on the data; identification of program code that can be invoked to perform actions on the data; definition of rights of access to the data; and a definition of programmatic interface to the object.

8. A computer operating environment according to claim 7 in which a range of objects, from an atomic piece of data to an entire database, may all be described by metadata.

9. A computer operating environment according to any preceding claim in which one or more object is constituted by data stored in more than one table of the database.

10. A computer operating environment according to claim 8 or claim 9 having a persistence layer that performs an exchange of data between objects and the database.

11. A computer operating environment according to any preceding claim that includes a browsing application for browsing and manipulating objects.

12. A computer operating environment according to claim 11 in which the browsing application presents a user with a view of objects and shortcuts to objects represented by icons.

13. A computer operating environment according to claim 11 or claim 12 in which the browsing application can represent folder objects as icons, each folder object being capable of storing one or more shortcuts to an object or folder.

14. A computer operating environment according to any preceding claim implemented on top of an existing operating system.

15. A computer operating environment according to claim 14 that executes within a virtual machine.

16. A computer operating environment according to claim 15 implemented in Java to execute within a Java runtime environment.

17. A computer operating enviromnent according to any one of claims 1 to 14 implemented as a complete system that can be loaded at boot time.