WO2003088015A2

WO2003088015A2 - System for protecting access to a database

Info

Publication number: WO2003088015A2
Application number: PCT/GB2003/001551
Authority: WO
Inventors: Donald Van De Merwe
Original assignee: Inte Vexis Ltd; Donald Van De Merwe
Priority date: 2002-04-12
Filing date: 2003-04-14
Publication date: 2003-10-23
Also published as: AU2003224263A8; GB0208408D0; WO2003088015A3; AU2003224263A1

Abstract

An application engine framework is provided for controlling access by a user of one or more applications to at least one database. The engine comprises a profiles module having the following: access permissions for managing data access privileges; menus for viewing by a user; and functional permissions for restricting selected functionality to selected user profiles; wherein the access and functional permissions and the menus are configurable to provide a specific profile for each of a plurality of users.

Description

Application Engine Framework

The present invention relates to an application engine framework

Developing a software application can take a development team many years of effort to produce a reliable application with a reasonable amount of functionality or capability. The steps required to define, build, release, and support a product are complex, programmer intensive, and time consuming. By building a framework that incorporates most of the standard components and requirements of any software application, the nature or method of the steps required to produce a software application are greatly enhanced.

The present invention seeks to provide an improved application engine framework and method for producing such applications.

Accordingly, the present invention provides an application engine framework for controlling access by a user of one or more applications to at least one database, the engine comprising .a profiles module having the following: access permissions for managing data access privileges; menus for viewing by a user; and functional permissions for restricting selected functionality to selected user profiles; wherein said access and functional permissions and said menus are configurable to provide a specific profile for each of a plurality of users.

In a preferred form of the invention a plurality of menu elements are provided wherein each said menu is configurable by selection of individual ones of said elements for combining in said menu. Each said access permission is dependent on a security classification of data in said -database. Functional permissions are provided for verifying and managing instructions given by the user and controlling the execution of said instructions in dependence on the functional permissions associated with the user profile. Visibility permissions are also provided for controlling the visibility of menus in dependence on the visibility permissions associated with the user profile or an area of the application. The present invention also provides a method of constructing a platform for enabling access ^'by a user of to a database, the method comprising providing a profiles module having the following: access permissions for managing data access privileges; menus for viewing by a user; and functional permissions for restricting selected functionality to • selected user profiles; wherein said access and functional permissions and said menus are configurable to provide a specific profile for each of a plurality of users.

In a preferred form of the invention a plurality of menu elements is provided wherein each said menu is configurable by selection of individual ones of said elements for combining in said menu.

Each said access permission is dependent on a security classification of data in said database. Functional permissions are provided for verifying and managing instructions given by the user and controlling the execution of said instructions in dependence on the functional permissions associated with the user profile.^' Visibility permissioris are also provided for controlling the visibility of menus in dependence on the visibility permissions associated with the user profile or an area of the application.

The present invention is further described, hereinafter, by way of definition and example, with reference to the accompanying drawings in which:

Figure 1 is a flow chart showing the steps in a conventional development of a database driven information system platform;

Figure 2 is a flow chart showing the steps in the development of a database driven ^■ information system platform using an application engine framework according to a preferred embodiment of the present invention;

Figure 3 is_. a representation of the _ scope of the application engine framework in comparison to the standard components within an application;

Figure 4 is a representation of the architecture of the application engine framework according to the preferred embodiment of the present invention; Figure 5 is an. illustration of the relationship between elements of a user interface for the application engine framework of Figure 4;

Figure 6 is a representation of the relationship between the database of a user and the application engine framework;

Figure 7 is a representation of the relationship between the application engine framework and two user modules; and ^{' ■}

Figure 8 is a representation of an overview of a module.

The application engine framework defined

The term 'application engine' or 'software engine' has been around for some time. Usually these terms refer to administration toolkits, server components of n-tier architecture, or the core components of an application. The application engine framework incorporates all the aspects of an application and its environment, but modelled in a different way, and also provides a new method for designing, building, integrating, upgrading, maintaining, and supporting an application.

The scope of the application engine, framework

The key objectives of the design of the application engine framework have been to reduce ^' the overall effort and skill required to build applications; to reduce the amount of development- work required; create a new method of configuration instead of development for building applications. The application engine framework covers every major aspect of an application as set out in figure 3 where the presentation level, functionality level, transaction level, and , database level components provide an architectural representation of an application that can be compared next to the application engine framework. The application engine framework also sets out to introduce some additional aspects for an application. Data storage - The storage of information within a database

Business logic - The functionality, events, and business rules within an application

Presentation of system - The customisation of the user interfaces Security - The authorisation of access and secure methods of transactions within a system

System Events- Predefined events for adding additional functionality within the application .

Extensions / Plug-ins - The abihty to add additional modules, services, or components of functionality

System Protocols _, - The methods in which the internal components interact with each other

Customisation - The ability to customise almost every aspect of the application and its usability Usability - The ability to define the profiles, visibility, and navigation within the system

Performance - The performance, efficiency, and speed of the system.

Extensibility • - The abihty for the system to be extended and updated in the future

Flexibility - The ability to change and modify the system, its configuration, or use Redundancy - The ability to set-up secondary or redundant components in the event of a failure

Scalability - The ability to scale to thousands of users across global enterprises

The items above incorporate the main areas of the application engine framework although there are more specific aspects that are required within the system.

The application engine sits between- a module (which is normally created by the developer and can be an application running on a client machine) and a database and controls the profiles that can be set up. It controls the way in which the user of the module can see the information in the database and the access rights to various parts of the database information. It allows a developer to define different user interfaces or screens^' for the presentation of information to the user as well as control the visibility rights to those user interfaces or screens. It can also control such things as the language and currency presented to the user so that different users of the client machine can have widely differing profiles.

The environment of the application engine framework

The application engine framework is designed to operate consistently in different environments. The environment consists of operating system platforms, database platforms, network or Internet platforms, and different devices or device types. The application engine framework has a layered architecture divided by 'upper level' and 'lower level' components, that allows the application engine framework to provide consistency and ease of use for all platforms.

The application engine framework architecture is also a distributed architecture so that a number of computers can be used to support the application engine framework. The benefits of this architecture are that an application built within the application engine framework can exist across the most common environments as well as be robust and fully scaleable. The distribution of such components also delivers another component of the framework that is redundancy. Components can be installed at multiple points within the environment and configured and set-up so that any one point of failure within the environment can automatically be avoided by the application engine framework.

An example of this could be that the 'broker component' of the application engine framework is installed on two different server computers. If the primary server is. not available, the component requestmg a function from the broker will automatically divert to the broker on the secondary server.

Using the application engine framework

The following section defines the new method in which someone can produce an application by using the application engine framework in relation to a. requirement to build a contact management database. Someone who understands the requirements for the application and can use the configuration tools normally creates the application within the application engine framework. Referring to the drawings, Figure 1 shows the typical conventional development process for an application. This consists of each of the components shown in Figure 1 that would be used to develop the product.

Figure 2 shows in full lines the steps that an analyst programmer has to go through using the application engine framework according to the present invention to build an application, and in dotted lines the steps that are now configuration steps not required by the analyst programmer. This means a significant saving in the effort and time and removes the requirement for any programming resource to develop the parts of the application that are now configuration tasks instead of development tasks.

In Figure 2 steps 1 and 9 are identical to the conventional steps. Steps 2, 3, 7, 8 and 13 are not required and steps 4 to 6, 10 to 12 and 14 are configuration steps rather than full design steps.

In this example the requirements need to be documented. From the requirements it will be possible to establish the data model requirements and configure the data model with all the required entities, fields, and relationships within the system. If required, selected locales can be set-up for additional languages within the system thereby having the application available for multiple languages without changes in the code. The security requirements identify three major user groups. .These are configured within the system admin^' tool as profiles. Each profile will be used when configuring the menus, user interfaces, functional permissions, visibility permissions, and access permissions.

The user interface and menus are then configured based on the required menu structure. Assuming there are different user-interfaces for each part of the system they can be configured separately based on the different parts of the system. If the user interface requirements are different depending on particular types of the same information, then these configurations can also be applied. Incorporatin business processes into the system can be done by configuration of the system during the development phase or during the implementation phase of the product without any code changes. The development of the functionality would be done by a developer and plugged into the system through events within the system, or command line options for menu functions. API's are already built and in most instances called by the specific functionality of the application to select, update, or manipulate the information.-- Testing, debugging, and support of the new application is only required for the functionality that have been built specifically for the application being developed. All functionality and capabilities within the application engine have already been tested and are supported.

Incorporating business processes into the system^' can be done by configuration of the system during the development phase or during the implementation phase of the product without any programming requirements or core-code changes. The high-level functionality and development of the functionality would be done by a developer and plugged into the system through events within the system, or command line options for menu functions. Application Programming Interfaces (API's) are already built within the application engine framework and in most instances used by the specific functionality of the application to select, update, or manipulate the information.

Testing, debugging, and support of the new application is only required for the functionality that have been built specifically for the application being developed. Ail functionality and capabilities within the application engine framework have already been tested and are supported.

As can be seen from Figure 2, technical specifications, system architecture, data dictionary development, API development, and managing upgrades and code changes are all steps . that are not required because they are all part of the application engine framework and built to support the flexibility and extensibility required by developing new applications.

The new method of producing an application is clearly contrasted by the reduction in work required, the skills required, the time required, and the approach required as can be see from Figure 2.

The application engine framework user interface

The user interface for the application engine framework is the presentation of information to a user and is structured in a dynamic way to allow it to adapt to different requirements or configurations and different platforms or devices. Conventional interfaces are designed and built to .work in a particular "hard-coded' way because of a specific set of requirements.

The application engine framework breaks down the components of the user interface into elements, behaviours, and privileges. This allows the user interface to be configured in every aspect. As a result of the ability to configure the individual elements, behaviours, and privileges the application engine framework provides customisation and flexibility to the user interface and its presentation to the user.

The underlying technology and architecture of the application engine framework also enables the same consistent configurations of different user interfaces to be extended to any of the devices, over any of the platforms. Because of this capability, the method for designing, building, integrating, upgrading, maintaining, and supporting an application is greatly improved.

The flexibility of the application engine framework makes it possible to build almost any application within the application engine framework, because of the ability to customise every aspect of an application.

The layout of the user interface

The user interface is made up of one or more elements that are positioned to make up the user interface. Each element has its own particular characteristics that deal with requested data or event in its own specific regard to presentation and user interaction. Each of the elements that exist on the same user interface has a unique relationship that is described between each element. This defined relationship structure can be configured and modified establishing the characteristics of the element. For example, is the element visible, can the data be updated, if data is present what is the nature of the presentation of the data? If a tree view element is the parent element of a data list element, then the specified data for the data list element will load the required data according to the requirements of the tree view element. One example of the relationship between elements is shown in Figure 5.

The system of how the user interface works is to enable the configuration of existing and new user interfaces dependant on the user, profile, or part of the system that needs to work in a particular way for enhanced usability. The effect of this is that a user interface required to input large amounts of data can be constructed in such a way as to simplify the data input process. For example, a number of forms can be easily laid out in the correct order of fields that need to be input. A user whose primary task is to search and analyse data will require a user interface where the query and viewing capabilities of the user interface have been configured allowing the easy search and analysis of data.

The behaviour of the user interface

On loading a user interface the primary element or elements will display its default attributes. The relationships between the elements are hierarchical where the root is the user interface. Each parent / child relationship that exists defines the behaviours from one element to the next, and in turn the data that may be loaded. It is possible that most elements will have a relationship with one or more other elements and so one action or event can change the nature of the user interface or modify the one or more elements that are currently visible.

The application engine framework allows the configuration of the relationship behaviours between elements where each child element in the user interface is- based on the 'type' of data being viewed. Selecting a particular record in the data view element will complete the second major part of the relationship between elements and the configuration ('action/reaction') settings for the element. An example of an element could be a 'tree view element'. As the parent element of a second element, a 'data list element', it could define the data displayed in the second element. Within the first element could be a number of 'nodes'. Each node configured for a subset of data. By clicking on ^'each different node in the first element, different data would load in the second.

In one example, another element is a form element and has a number of fields to display information. The form element in this example is a child element to the data view element that is its parent. Because of the type of information being viewed in the data view element we know what type of information will need to be displayed in the form element, and so the form element has already constructed itself in preparation to show the details of a company record. ^'

For example, if a user clicks on a node in a tree view this would send a filter to the server requesting data for the elements that have been set as its child elements and then load the data into the-child elements. In a simple user interface we may have an element that is a data view and lists a set of data. This data view element has a parent element that is say for example a query element. The system of elements is based on a hierarchy of parent child relationships. The query element is the parent, and the data view element is the child. Using the query element to search for companies, for example, will enable the data view element to display all companies matching the criteria of the parent. To extend the scenario, lets introduce another element that is a form element and has a number of fields to display information. The form element in this scenario is a child element to the data view element that is its parent. Because of the type of information being viewed in the data view element (in this company) we know what type of information will need to be displayed in the form element, and so the form element has already constructed itself in preparation to show the details of a company record.

This is one aspect of the relationship between elements that is managed, each child element in the user interface being based on the type of data being viewed. Selecting a particular record in the data view element will complete the second major part of the relationship between elements and based on the behaviour or 'action/reaction' settings for this element relationship display the details of the record selected in the data element view.

Events within the system can be related to elements so that an element is able to call a function from the application engine and pass it parameters. This enables complete control for developers and integrators who need total control over the application engine. The developer can set up a relationship that defines for the application engine how it is to react.to, for example, a mouse double click on a part Of the screen.

The application engine framework privileges

The user interface

User privileges regarding the user interface ate an important aspect of the system. By building up a specific 'experience' or 'view' of the system for users it is possible for the system to present different user interfaces, behaviours, and functionality to different sets of users. The application engine framework is therefore able to attend to the specific needs of all the different types or sets of users within the system.

The way in which the system manages these privileges is through user profiles and user groups.

User Profiles

Figure 4 is a representation of the architecture of the apphcation engine in relation to a client application that can be a web browser, a palmtop or a .net client (meant to ^'define a broad range of devices). Login access to the system is managed through the System Configuration (admin tool), which is based on the database security for managing access to the database. All security related components are assigned to profiles, that are used to describe the system attributes applicable to a particular user type. All aspects of the application relevant to a userDs interaction are associated with the profile. Users are typically assigned to one profile, but may belong to more than one. User membership to a profile can be direct or by being a member of a group that is associated with a profile. A group is a collection of users and used to easily manage security options.

Profiles are set-up to manage user privileges. This is achieved by assigning security related components to profiles, which are used to describe the system attributes applicable to a particular user type. All aspects of the application relevant to a user's interaction are. associated with the profile. It is usual for a user to belong only to one profile, although a user can belong to more than one. The way in which the system applies a profile is for a user to inherit the settings of the profile. If a user does belong to more than one profile, then the user will inherit the cumulative settings for all profiles. User membership to a profile can be direct or by being a member of a group that is associated with a profile.

Profiles are used to streamline complex systems so that unnecessary elements of an application not applicable to certain types of users are not available in that profile. Additional device types are also managed through profile. For example, a regular profile may have all elements available to a user because of the capabilities of their computer, where a PDA device has limited capabilities, and so requires a more streamlined profile and interface.

The Profile section of Figure 4 includes Functional Permissions, Visibility Permissions, Menus, User Interfaces Localisation (this relates to the language to be used) and Multi Currency / Trading which relates to the currency used.

Functional permissions, visibility permissions, and access permissions are all specific components of the overall profile.

User Groups

A group is a collection of users and used to easily manage access permissions options. Access permissions in particular manage the access to data that a user will have. These access permissions are maintained no matter what apphcation the user users to access the information. For example using a report writer, the user will not bypass any of the restrictions there may be.

Access Permissions

Access permissions are used to manage data access privileges. There are five main ^' categories used to provide complete flexibility in how data needs to be managed. The access permissions can be applied in any combination and cover the four main options applicable to data: Read, Edit, Add, and Delete. Privileges are granted to a profile and the effect of multiple privileges being applied is they are cumulative. For example, if 'all' has been granted read permissions only, and 'owner' has been granted edit permissions, then the owner of a record can read and edit that record.

In a typical scenario it is generally the case that most permission's will be dealt with by the all category. There may be certain types of data where most people can read, edit, and add data but cannot delete data. There are also situations where the creator of data has certain privileges, but assigned the information a new owner. Groups of users also need to work together, but sometimes quite separately from other groups. Data access privileges may also be different depending on the classification of the data at a particular point in time.

The categories of access permissions are listed below:

All: Privileges apply to all users in the system.

Owner:Privileges apply to the owner of the record. Creator: Privileges apply to the creator of the record.

Group: - Privileges apply to the primary group of the owner of the record. Class:- . Privileges apply to the particular class of data. Class permissions are applied to each value in class.

Each entity of information within the system has a class field that is used to describe the type or category of data. For example, a company entity may have three main types of company: gold, silver and bronze. In this instance the Company Type has been chosen as the class field. The values gold, silver and bronze will each have access permissions assigned to them. For example, gold companies are read only, silver companies are read and edit, and bronze companies are read, edit, delete. It is therefore only possible to delete bronze companies etc.

Visibility Permissions

Visibility of components within the application engine framework need to be managed depending on the application, part of the system, type of information, or user profile within the system. Visibility permissions are managed in the admin tool and applied to user profiles. Components of the application engine framework that can be managed with visibility permissions include menus, user interfaces, elements, entities, fields, relationships, and lookup values. A component is visible when it has been selected as visible. An example of managing visibility for fields could be applied to an employee salary field that should only be visible to the HR team, and not to anyone else in the system.

Functional Permissions

Functional permissions make it possible to manage who has the privilege to perform any function or command or define what the system can do on behalf of a user. Functionality can be restricted to a profile, or restricted at certain stages within a process within the application. Functional permissions are verified on every command or function that is called by the system or user. Functional permissions are not restricted to the menus or commands or functions within the application engine framework but can be extended to manage plug-ins as well. For example, a functional permission can be set on whether a user can print information from the system as chosen from the menu, or whether an automated event initiates a print function, hi each case the print command will not initiate unless there is a functional permission.

The application engine framework usability Menus

Menus in the application engine framework are fully managed and configurable. Information on menus such as the top-level menus and sub-level menus are maintained in a hierarchical structure. The standard properties for each menu are the caption, command, and parent level menu. Configuration of the menu ranges from defining the top-level menus, the sequence of those menu's as well as the sub menus and the sequence in which they appear. Menu items are also managed by visibility permissions and functional peπnissions.

Visibility permissions make it possible to control the visibility of menus based on user profile, or a particular application, or area of a particular apphcation. For example, when navigating around the application and performing regular tasks the most common menu items are available. If a particular record is open, then additional menu items may become available based on the type of information being accessed. This maintains the critical theme of usability within an apphcation, making it possible to simplify complex applications specifically for different users.

Functional permissions make it possible to manage who has the privilege to perform any function or command, even if the menu is available to a user, it is still possible to restrict the use of a menu item.

User Interface customisation

The system of how the user interface works is to enable the configuration of existing and new user interfaces dependant on the user, profile, or part of the system that needs to work in a particular way for enhanced usability. The effect of this is that a user interface required to input large amounts of data can be constructed in such a way as to simplify the data input process. For example, a number of forms can be easily laid out in the correct order of fields that need to be input. A user whose primary task is to search and analyse data will require a user interface where the query and viewing capabilities of the user interface have been configured allowing enabling the easy search and analysis of data.

Events within the system are related to elements so that the behaviour or functionality required from a standard element can be extended to beyond the application engine framework to call other internal or external objects or functions. This enables complete control for developers and integrators who need total control over the application engine framework. The standard events within the system can be configured to hold any parameters required when triggered.

Creating new records in a flexible application system

Because of the flexibility of the application engine framework, it is possible to configure unique relationships between different entities within the system. When creating a new record or navigating through the system it is necessary at times to relate different information together. For example, if you create a company, contact, action, and sales- lead and you want to relate the information together it may be a cumbersome process. A usability feature of the application engine framework is that a user can effectively create all items and have them automatically create the links between each type of information. Another issue is that in a completely different scenario the same sequence of information that is created must not be linked.

The only feasible way to manage this situation is to have a feature available for the user to specify when the items need to be linked. This result is that when creating a new record that must be linked, the user can choose which of the previous records need to be linked together. This system uses the history and auditing function within the application engine framework that maintains an entry for every action the user has made. For example, when creating the sale-lead the option to select any of the previous records will be listed. Simply choose the company and continue creating the sales-lead. The system will then create all the necessary links for the user.

The application engine framework data dictionary Advancing the abilities of the database

Since the inception of software applications there has been the _. requirement to store information. The two most common methods have been to either store information in database or file format. For most applications the storage and retrieval of information has evolved from simplified 'flat-file' structure to the 'relational' data model. In all cases there is a dependency between the programming and functionality of an application and the structure or schema of the tables and fields in the database. This hard coded approach creates limitations on the application and its ability to be flexible and evolve with the changes required.

A key component of the application engine framework is the data-dictionary that describes all the information about the configuration of the system by defining the schema, layout, and characteristics of the database and its tables, fields, and relationships and other behaviour including the nature and characteristics of a particular system or application configuration. In this way the design, creation, and managenient of the database is performed not directly within the database, but through an administration tool that contains the functionality for a user to configure the database for their apphcation.

The benefits of the data-dictionary component in relation to the application engine framework are that it is fully integrated to the other components within the framework so that the building of an application is a configuration task and not a development task. This is made possible because the data-dictionary information stores additional attributes and properties regarding the nature and behaviour of the different types of information that will be stored in the database. With pre-defined and generic components of functionality available, it is the ability to turn on or off or select these attributes and properties that provide the additional benefit.

The data dictionary includes information on profiles, groups, users, group membership, profile membership, countries, locales, currencies, configuration settings, functional permissions, access permissions, licensing, address formats, data objects, plug-ins, components and modules, redundancy/availability information, user interface information, elements, menus, data types, captions, locale information, tool tips & help information, entities, fields, relationships, lookups, lookup values, lookup groups, and relationship joins and relationship groups.

Applying a different approach when adding functionality means that the application engine framework automatically deals with changes or modifications to the database. The scalability and flexibility of the system removes the need to update of modify all of the common components and programming within the application engine framework. This, enhances further the time, costs, and quality of application development and maintenance.

System Cache

The cache is an extract of the data dictionary that is used to optimise performance of the application for the user. Cache information is built for each user by extracting the 'cumulative' profile based information specific to that user. The use of the cache system is to enhance the performance of the system, and avoid unnecessary network traffic between a client and host or server side system. The only data that is transferred on a regular basis is the actual data or information required by the user.

The caching of information is done where most appropriate. In usual circumstances a cache will exist on the client, although dependant on configuration settings, and security aspects of the client being used. In other circumstances the cache is stored and accessed on a host system. Because it is possible to access external systems or use different device types, the cache is utilised at the optimal point of internal processing so that certain distributed environments can benefit. In all cases however, the cache is updated when required, because of changes are made to the configuration of the system or apphcation engine framework. This is also required because of the evolving changes and support updates that can be made to the system.

Relationship Types

Relationships within the apphcation engine framework can be defined between entities. Entities that exist will have any number of relationships defined between them, depending on the application within the system, and its requirements. These are the relationships within the engine:

1: 1 One to One relationship linking between two fields that can exist on any two entities 1 :N One to Many relationship linking many items to one item. One example is linking many children to a parent

N:N Many to Many relationship that, links two entities together where each item can be . linked to many other items; for example company to contact. Many contacts can belong to a company or many companies and vice versa. Each side of this relationship has a context. For example a contact is an employee, and the company, an employer. N: Group Grouping or Sister relationship that links many items together to for a group. For example: sister companies. If one looks at any sister company one will see all the others in the group.

The application engine framework broker system

The broker system (Figure 6) of the application engine framework has been built to manage the basic functions required in a database system, but in a distributed network environment. In most technologies functions can make a direct call to receive data from the database. In some cases however, it is not possible, practical, or able to be implemented because of the different environments that exist. In these scenarios the broker system solves the problem in its ability to manage information, requests, and functions between client, server, any middle tier component, as well as between different implementations of the application.

The Broker of Figure 6 retrieves information from the Database for the Client after checking the login. The latter needs to be checked only once for a user. The broker system decides how all requests from the client are processed. If a data request is being handled for requests, updates, deletions, and validations, the broker will handle the request and return a dataset or result to the client. If a user interface or cache request is made, then the broker would check the cache and return the required cache information. If a function or stored procedure needs to be executed then the broker would handle the execution of the function or stored procedure and return a result or validation to the client.

The cache in the Broker system -of Figure 6 is effectively a set of rules that determine what the Broker applies from the Database to the Client. It can store, for example, specific profiles, one of which could be a marketing profile whilst another could be an accounts profile that would present different interfaces information in different ways to the profile specific users. The Broker sits in block 10 of the architecture of Figure 4.

The application engine framework plug-ins

Without any functionality, the application engine framework is a sophisticated database tool and not an application. Every application requires business logic or functionality built into the system to add value and create a unique set of capabilities. Being able to easily build functionality required by the user within the application engine framework is fundamental to viability of the application engine framework as a platform to develop applications. Functionality is built and added to the system as a plug-in.

Functions are plug-ins to the application engine framework and allow developers to include new functionahty and integration to the application engine framework. There is no restriction to what programnm g language is used to develop the functionality, although certain capabilities would be required. Each function is registered in the database and called via the application engine framework. The application engine framework handles the deployment of plug-ins to client machine if required. The benefit of this system is that if new or updated code heeds to be rolled out to a large site, it is simply done by updating the plug-in in the adimn tool.

The application engine framework modules

Overview

Each module is a specific software application that is based on the application engine framework. The application engine framework delivers a host of capabilities and functions already within the engine. Most of these capabilities become part and parcel of the module application itself. The application engine framework functions deliver a foundation of capabilities, but not necessarily the specific business logic or functionality required for a specific task. These are the functions or tasks that are provided by the module using the lower-level functions and capabilities of the application engine framework.

An example module or application that has been mentioned above is a sales system used by sales people to manager their sales activity. In this example, specific business logic around the sales process such as qualification of an opportunity, or forecasting of an opportunity is delivered by the sales system. The process of creating the module is to configure the application engine framework creating the data model, user interfaces, and menus. The business logic is created by the developer and hooked into the configured part of the application engine framework. Only the specific calculations required for a qualification or forecasting process need to be written by the developer.

Figure 8 is a representation of a module.

A module is made up of the following objects:

Definition Functions Events Data Dictionary

Module Definition

This is module definition information for the purposes of identification, ownership, copyright, support, version control etc. It is created and maintained by the authors of the module, and used to specify who built the module, what is the module version, and too support maintenance and update information to the module as it is extended, modified, or upgraded. The module definition is added when a module is installed in the application engine framework and removed if the module is uninstalled. The module definition also maintains licensing information such as the licensing method, quantity or allocation and used to monitor permitted use of the module.

Module Functions

Module functions are created within the application engine framework to manage particular business logic required. In the sales example, a function would be the ^* qualification function or the forecasting function. Programmers are also able to publish their functions to be used by other modules for integration purposes.

Module Events

The application -engine framework manages basic events such as save record, exit field and so on. These are generic and more than likely won't be adequate in a specific scenario. For this purpose developers that are creating modules within the application engine framework are able to create events specific to their module. An example would be in a sales system where you have an event based on creating an order. This event could be used to trigger another process to perform another function. The Functions & Events block in Figure 8 is equivalent to the Function block in Figure 6 and uses some or all of the functionality of the engine API.

Module Data Dictionary

The application engine framework data dictionary includes items that relate to a specific module. These data dictionary items include entities, fields, relationships, lookups etc.

Module Integration

Because it is possible, and likely, to have more than one module based on the application engine framework, it is necessary to define the module and its characteristics. When two or more modules do exist within a single application engine framework it is also necessary to have a consistent set of interfaces to manage any possible integration between the two modules. This gives any number of modules the ability to coexist with other modules.

To ensure consistency within the application engine framework a reference list is maintained that provides basic information on the additional events published by modules as well as version control. When a particular bit of integration is done between two modules it is necessary to maintain the details that exist between each set of functions. In particular version control, client functions, server functions, or even functions external to the application engine framework.

A second example module could be a Project System to manage implementation projects on behalf of customers. Figure 7 is a graphic representation of the sales and project modules interfacing with the application engine framework. When the project module is combined with the sales system it is possible to see how a sales order created within the sales system could be used as the event to initiate a process within the project system that can automatically create a project. Using the published list of functions additional items required could easily be established within the framework of the application engine framework without requiring additional documentation. Such information as functions, triggers, input and output parameters can all be made easily available. Consistency with version control can also be managed if an upgraded component of the project system was added to the system. Instead of replacing the original, both can be kept and maintained.

The application engine framework functionality

The application engine framework is a set of technical and functional features to deliver a unique platform for building software applications. The application engine framework is an all-purpose database driven information system platform for developing software products easily and effectively, and providing a very quick lead-time to market. The application engine framework provides an extremely customisable environment for developing information systems that are platform independent, device independent, easily deployable, flexible, scaleable, and extendable. The application engine framework can be used for developing web portals, web content management solutions, collaboration solutions, e-commerce systems, and software applications & solutions. Typical functionality that is required by most information systems has been built into the engine, thereby reducing the amount of effort required to build an application or module within the application engine framework. The application engine framework technically refines and enhances the capabilities of applications that are built on this environment.

The preferred form of application engine framework is platform and device independent. It allows a user to tailor the user interface on his machine and this enables two or more people to use the same product through different user interfaces and to assign an interface to particular types of information that is drawn from the database.

More specific levels of functionality required within the system are:

An administration tool to configure the application engine framework.

Complete set of API's for programming extensions, plug-ins, and integration.

A repository for plug-ins and extensions such as executable or library files.

Network deployment and support capabilities. Support for multiple applications integrated within the same application engine framework. Support for multiple locations through server to server replication.

Support for multiple locales and multiple language versions. Support international ^■■ address format types.

Support for multiple currencies trading capabilities. Support multiple security types such as SQL Server, Windows NT, or Active Directory

Logins.

Ability to manage and configure data model elements such as entities, fields, relationships.

Ability to configure multiple relationship types such as 1 :1, 1 :N, :N, and N: Group. Ability to manage user logins, groups and group membership, profiles and profile membership.

Ability to manage access permissions with complete control for the data they have access to.

Ability to manage visibility permissions defining which data dictionary elements are visible to a user.

Ability to configure system references such as lookup's and additional locales. Ability to customise and create user interfaces based on profile, area of system, or type of data.

Ability to customise and create menu structures based on profile or area of system. Ability to manage functional permissions defining which functions can be executed by^' a user. Ability to audit information updates per user.

Each item in a menu has one or more profiles associated with it. Each profile has an associated form and when the menu item is selected by a user the system will bring up the form associated with the relevant profile to retrieve data from the database. The information retrieved by the form and the information available in the form and indeed the layout of the form will depend on the access permissions in the profile or profiles associated with the user selecting the item on the menu. A user of the application created by the application engine framework can belong to a number of different profiles so that the information he is allowed to retrieve or amend can depend on which part of the database information he is accessing. The profiles can also be accumulative so that if a second profile is given to a user with different permissions to that of a first profile, the permissions will apply effectively to both profiles allowing the user to carry out permissions of one profile when using the other profile.

When a menu item is selected this will result in the associated form allowing access to all of the information to which permission is given by both profiles.

Claims

1 An application engine framework for creating one or more software applications for controlling access by a user to .at least one database, the engine framew'ork comprising a profiles module having the following:

access permissions for managing data access privileges;

menus for viewing by a user;

and functional permissions for restricting selected functionality to selected user profiles;

wherein said access and functional permissions and said menus are configurable to provide a specific profile for each of a plurality of users.

2 An apphcation engine framework as claimed in claim 1 further comprising a plurality of menu elements and wherein each said menu is configurable by selection of individual ones of said elements for combining in said menu.

3 An application engine framework as claimed in claim 1 or 2 wherein each said access permission is dependent on a security classification of data in said database.

4 An application engine framework as claimed in any of the preceding claims further comprising functional permissions for verifying and managing instructions given by the user and controlling the execution of said instructions in dependence on the functional permissions associated with the user profile.

5 An application engine framework as claimed in any of the preceding claims furthe comprising visibility permissions for controlling the visibility of menus in dependence on the visibility permissions associated with the user profile or an area of the application. 6 An apphcation engine framework as claimed in any of claims 1 to 5 wherein privileges for a user are cumulative.

7 An application engine framework as claimed in any of claims 1 to 6 further comprising a data dictionary for storing information on the configuration of the database and the framework thereby enabling a higher level management of the database and the framework through the data dictionary without requiring direct access to the database.

8 An application engine framework as claimed in claim 7 comprising a cache that is associated with a user and contains information extracted from the database dictionary to provide a profile for the user.

9 An application engine framework as claimed in any of claims 1 to 8 wherein the database is a component of the framework

10 An application engine framework as claimed in' any of claims 1 to 9 wherein said software application is a sales application.

11 A method for creating one or more software applications for enabling access by a user to a database, the method comprising providing a profiles module having the following:

access permissions for managing data access privileges;

menus for viewing by a user;

and configuring said access and functional permissions and said menus to provide a specific profile for each of a plurality of users.

12 A method as claimed in claim 11 further comprising providing a plurality of menu elements and configuring each said menu by selection of individual ones of said elements for combiiiin.s in said menu.

13 A method as claimed in claim 12 wherein the relationship between said elements is hierarchical and the root of said hierarchical elements is a user interface.

14 A method as claimed in claim 11, .12 or 13 comprising configuring each said access permission to be dependent on a security classification of data in said database.

15 A method as claimed in any of claims 11 to 14 further comprising providing functional permissions for verifying and managing instructions given by the user and controlHng the execution of said instructions in dependence on the functional permissions associated with the user profile.

16 A method as claimed in claim 15 wherein each said functional permission is verifiable on each instruction called by a user.

17 A method as claimed in any of claims 11 to 16 further comprising providing visibiHty permissions for controlling the visibility of menus in dependence on the

^■visibility permissions associated with the user profile or an area of the apphcation.

18 A method as claimed in any of claims 11 to 17 further comprising providing a data dictionary storing information about the configuration of the database and the framework thereby enabling a higher level management of the database and the framework through the data dictionary without requiring direct access to the database.

19 A method as claimed in claim IS comprising caching information specific to a user to optimise performance of the application for the user.