[go: up one dir, main page]

WO2005073848A2 - Environnement d'exploitation informatique - Google Patents

Environnement d'exploitation informatique Download PDF

Info

Publication number
WO2005073848A2
WO2005073848A2 PCT/GB2005/000334 GB2005000334W WO2005073848A2 WO 2005073848 A2 WO2005073848 A2 WO 2005073848A2 GB 2005000334 W GB2005000334 W GB 2005000334W WO 2005073848 A2 WO2005073848 A2 WO 2005073848A2
Authority
WO
WIPO (PCT)
Prior art keywords
operating environment
data
objects
computer operating
environment according
Prior art date
Application number
PCT/GB2005/000334
Other languages
English (en)
Other versions
WO2005073848A3 (fr
Inventor
George Svarovsky
Original Assignee
Id Business Solutions Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Id Business Solutions Ltd filed Critical Id Business Solutions Ltd
Priority to GB0515098A priority Critical patent/GB2414838A/en
Publication of WO2005073848A2 publication Critical patent/WO2005073848A2/fr
Publication of WO2005073848A3 publication Critical patent/WO2005073848A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • each object may include data, executable code or both.
  • 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.
  • 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.
  • one or more objects may include metadata. This is data that describes the content of the objects.
  • the metadata may include one or more of:
  • 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.
  • 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.
  • a persistence layer that handles the exchange of data between objects and the database.
  • Hibernate 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • URL uniform resource locator
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • the security modules use PAM (pluggable authentication modules) 96 to perform authentication requests.
  • PAM plugable authentication modules
  • 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.
  • JAAS Java Authentication & Authorisation Service
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the operating environment provides an interface that is fundamentally similar to that provided by a graphical file manager in a conventional operating system.
  • the interface is referred to as the "gateway" and this is illustrated in Figure 10.
  • 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.
  • Objects within the operating environment are made persistent through storage of the data and metadata associated with each object in a relational database.
  • 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.
  • an executable is analogous to a Windows ".EXE".
  • An executable is an application within the context of the embodiment.
  • 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.)
  • the URL of the Gateway is WorkBench/Gateway.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • vendor-specific syntax e.g. sequence generation
  • 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.
  • 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 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.
  • ActivityBase a known database system
  • Studies, Protocols and Tests there are Studies, Protocols and Tests, and the tables STUDY, PROTOCOL and TOCCASON.
  • TOCCASON a known database system
  • 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.
  • Metadata 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.
  • AppObject An object of central importance to this embodiment is the AppObject.
  • AppClass a compaction of Application Class
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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 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 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:
  • Relational data can have complex internal relationships that are hard to visualise in a user-friendly manner.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne un environnement d'exploitation, dans lequel des objets logiques de l'environnement d'exploitation sont stockés dans une base de données relationnelle. Dans un environnement d'exploitation selon l'invention, chaque objet peut comprendre des données et/ou un code exécutable. Dans ce contexte, les 'données' peuvent comprendre pratiquement n'importe quel élément présentant un contenu d'information. Il peut s'agir de données textuelles (par exemple un document codé dans un format texte), de données binaires (par exemple une image ou un son), d'un code source de programme, d'un code exécutable, etc. Dans ce contexte, un 'code exécutable' peut comprendre un code machine compilé, un code script pour une exécution au moyen d'un interpréteur, ou un code source pour une compilation avant l'exécution, par exemple, par un compilateur 'juste à temps'.
PCT/GB2005/000334 2004-01-30 2005-01-31 Environnement d'exploitation informatique WO2005073848A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0515098A GB2414838A (en) 2004-01-30 2005-01-31 Computer operating environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB0401972.5A GB0401972D0 (en) 2004-01-30 2004-01-30 Computer operating environment
GB0401972.5 2004-01-30

Publications (2)

Publication Number Publication Date
WO2005073848A2 true WO2005073848A2 (fr) 2005-08-11
WO2005073848A3 WO2005073848A3 (fr) 2006-01-26

Family

ID=31971683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2005/000334 WO2005073848A2 (fr) 2004-01-30 2005-01-31 Environnement d'exploitation informatique

Country Status (2)

Country Link
GB (1) GB0401972D0 (fr)
WO (1) WO2005073848A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3776195B1 (fr) * 2018-04-12 2024-04-24 Huawei Technologies Co., Ltd. Système et procédé de matérialisation rapide d'objets java à partir de données de base de données

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5613122A (en) * 1994-11-14 1997-03-18 Object Technology Licensing Corp. Object-oriented operating system
US6163776A (en) * 1998-03-23 2000-12-19 Software Tree, Inc. System and method for exchanging data and commands between an object oriented system and relational system
US6587856B1 (en) * 1998-12-07 2003-07-01 Oracle International Corporation Method and system for representing and accessing object-oriented data in a relational database system
AU2002226893A1 (en) * 2000-11-16 2002-05-27 Thought, Inc. Dynamic object-driven database manipulation and mapping system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3776195B1 (fr) * 2018-04-12 2024-04-24 Huawei Technologies Co., Ltd. Système et procédé de matérialisation rapide d'objets java à partir de données de base de données

Also Published As

Publication number Publication date
GB0401972D0 (en) 2004-03-03
WO2005073848A3 (fr) 2006-01-26

Similar Documents

Publication Publication Date Title
US6243709B1 (en) Method and apparatus for loading stored procedures in a database corresponding to object-oriented data dependencies
US6704743B1 (en) Selective inheritance of object parameters in object-oriented computer environment
US6279008B1 (en) Integrated graphical user interface method and apparatus for mapping between objects and databases
US7043481B2 (en) System, method and software for creating, maintaining, navigating or manipulating complex data objects and their data relationships
EP1042720B1 (fr) Procede et appareil de creation d'index dans une base de donnees relationnelle correspondant a des classes d'une application orientee objet
US7240330B2 (en) Use of ontologies for auto-generating and handling applications, their persistent storage, and user interfaces
US8296720B2 (en) Framework to access a remote system from an integrated development environment
US6049673A (en) Organicware applications for computer systems
US7289997B1 (en) System and method for an extensible metadata driven application framework
Keith et al. Pro Jpa 2
Acharya Post Office Management System Project Report
Patel et al. Java database programming with JDBC
EP1040432B1 (fr) Procede et appareil de chargement de procedures stockees dans une base de donnees correspondant a des dependances de donnees orientees objet
WO1999033004A1 (fr) Procede et equipement relatifs a une interface graphique utilisateur integree pour mappages objets/bases de donnees
Habela Metamodel for Object-Oriented Database Management Systems
WO2005073848A2 (fr) Environnement d'exploitation informatique
McFarland et al. Object-oriented database management systems revisited
Alia et al. A middleware framework for the persistence and querying of java objects
CA2293114A1 (fr) Representation d'un mappage de donnees d'une reference d'objet
Sperko et al. Java persistence for relational databases
Akbay et al. Design and implementation of an enterprise information system utilizing a component based three-tier client/server database system
Sawyer A User Interface Framework for Object-Oriented Database Systems
Zhao services retrieval system tool for software reuse.
Guide et al. Persistence Framework
Sun A three-tier database system for Java remote objects

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 0515098

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20050131

WWE Wipo information: entry into national phase

Ref document number: 0515098.2

Country of ref document: GB

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase