GB2380007A

GB2380007A - Database access system

Info

Publication number: GB2380007A
Application number: GB0122612A
Authority: GB
Inventors: Alex Mattelaer; Robert Scott-Stewart
Original assignee: ALEA TECHNOLOGY Ltd
Current assignee: ALEA TECHNOLOGY Ltd
Priority date: 2001-09-19
Filing date: 2001-09-19
Publication date: 2003-03-26
Anticipated expiration: 2021-09-19
Also published as: GB0122612D0; WO2003025791A3; GB2380007B; WO2003025791A2

Abstract

A system for accessing a database from a client, in which the client is connected by means of a browser to an application server and the application server is connected to the database. Validation of at least some data to be transmitted from the client to the database is carried out at the client by means of validation objects cached at the client which are accessed by the browser.

Description

Database Access System This invention relates to a system for accessing a database. It is particularly concerned with a system for adding or modifying data remotely in a controlled manner.

When accessing a database, it is essential that there be controls over what data can be added or modified. Rules are usually included in the database itself which control what data is permissible in a particular field.

There may be fields requiring data to be in a particular format-such as a date field. There may be fields which require limitations on data, such as a text field which requires the text to be within a preset number of characters. If data sent to a field does not comply with the rules, then an error message is generated. This is usually of a generic type and can be confusing to normal users if passed through to them. In some cases, complicated validation routines are required and it is not always convenient to include these on the data base itself.

As a result, it is common for"front end"or client applications to include validation routines. If a user enters data in a field, then it is checked before an attempt is made to send it to the database. If an invalid date is entered, then there is direct interaction between the client application and the user so that it can be corrected before being sent to the database.

Another area in which a client application can be used to ensure that only correct data is entered, is the use of"lookup"tables. It may be necessary to ensure that,

for example, a contact can only be selected from an authorised list of contacts held on the server. The server will have a table of approved contacts. The client application will only let users select a contact on that table-and that may involve further checks as to whether the contact is available for new business, has an appropriate credit rating and so forth. Typically the client application will present a lookup list of available contacts to users, and a contact may only be selected from the list.

This is a two tier structure, in which a user is connected through a client application to the database.

With browser technology now commonplace, a three tier architecture is becoming common. In this, the client application is run on an application server connected to the database and the third tier runs on the user's own PC or terminal server. A user connects to the application server over a network such as the Internet or a corporate intranet, and a"web"page appears on the users personal computer providing access to the database through an application run on the application server. In some cases, validation is carried out at the application server but this is inefficient as a whole page of information from the user must be submitted for validation and if there is a problem then the user must be advised, the page sent back to the user, and the necessary corrections made. In other cases, the page downloaded to the user already includes validation routines and lookup information, embedded in the page as - for example-Java code. This means that validation of data takes place as users enter data, and before it is sent to the second tier. This is an improvement but it is still inefficient. Each time that a user goes to a page, that page including its validation data must be downloaded and if there is a considerable amount of validation data-such as a long lookup table-there

will be lengthy delays.

Thus, designing applications for a"browser front end" environment has the drawback that once a page has been supplied to the browser by the server, it is "disconnected". In other words the server has no control over what will happen to that page, and the browser cannot refer to the server (for example to look up reference data or perform validation) without resubmitting the entire page. Clearly, this is not ideal when handling a large, complex document such as an insurance contract, particularly when working within a low-bandwidth environment (e. g. over an intranet or the internet, where many users may be using a 56 kbps dialup connection).

A traditional three tier architecture is therefore limited if there is a significant amount of validation to be carried out.

Viewed from one aspect the present invention provides a system for accessing a database from a client, in which the client is connected by means of browser technology to an application server, the application server is connected to the database, and validation of at least some data to be transmitted from the client to the database is carried out at the client, characterised in that validation objects are cached at the client and are accessed by the browser technology to validate data to be transmitted to the database.

Thus, in an implementation of the invention in which there is a simple lookup list of permitted contacts, the list will be transmitted initially from the database, via the application server, to the client where it will be cached. Subsequently, when a user connects to the application server and accesses a page with a form on

which a contact can be entered, the page will present a list from which contacts can be selected. The data to fill this list is obtained from the list previously stored on the client. The browser technology does not present a page which has been downloaded with the list data embedded, nor is the list data downloaded from the application server or the database. The data is already resident on the client and is not embedded in a downloaded page.

Preferably, a check is made for validation data which has changed, and if necessary the new data is transmitted to the client. In a preferred arrangement, the application server, or another designated server, builds tables of validation data regularly and creates a data file. When a lookup is reported to the server, for example when a page is submitted containing data, a check is made to determine whether the data used at the client end is from the current version created by the server. If it is not, then a new data file will be transmitted to the client, and the client will be instructed to go through the routine again.

The invention extends not only to the system as a whole, whose components may be distributed over various jurisdictions, but to client data processing means programmed to operate within the system, to data processing means programmed to operate in the middle tier and to software used in implementing the system.

Thus viewed from another aspect the invention provides data processing means configured to operate as a client in a system as set out above, wherein the data processing means provides browser technology to connect to the application server, and is programmed so that validation of at least some data to be transmitted from the client is carried out at the client, characterised

in that the data processing means caches validation objects which are accessed by the browser technology to validate data to be transmitted.

Viewed from another aspect there is provided computer software which when installed on data processing means will configure the data processing means to operate as a client in the above manner.

Viewed from another aspect there is provided data processing means configured to operate as an application server in a system as described above, the data processing means being configured to generate validation data which is transmitted to the client for caching at the client.

Viewed from another aspect there is provided computer software which when installed on data processing means will configure the data processing means to operate as an application server in the above manner.

Computer software may be provided in the form of signals transmitted form a remote location, for example over the Internet or a corporate intranet, or in the form as data stored on physical media such as a CD-ROM.

Where reference is made to an"application server", this is not restricted to a single piece of equipment but encompasses linked servers which perform different parts of the overall system. For example, a conventional application server could be linked to a separate server whose job is to create validation data for transmittal to the client.

The client may be a personal computer for a single user, or, for example, a terminal server which is accessed by multiple users, hosting several instances of the

necessary software or validation data.

References to"browser technology"encompass conventional browsers such as Microsoft's"Internet Explorer"as well as other applications which provide the same functions necessary to operate a system in accordance with the invention.

Some embodiments of the invention will now be described by way of example and with reference to the accompanying drawings, in which: Figure 1 is a diagram of the principal objects in a system in accordance with the invention; Figure 2 is the database schema for a metadata database used in a system in accordance with the invention; Figure 3 is a screen shot showing how"business"objects can be related to"physical"objects ; Figure 4 is a screen shot showing how data warehouse definitions can be created and maintained using metadata; and Figure 5 is a screen shot showing how business rule definitions can be created and maintained using metadata.

The preferred system is designed around a component based, three tier, true thin client architecture. This architecture is provided in the form of a suite of components and tools making up a"Core framework". This framework consists of: A sophisticated"metadata"database structure to store the business rules and track the interrelation of these

with the front end screens and back end data.

A user-friendly graphical user interface to enable easy maintenance and analysis of the business rules.

A library of generic pre-built components to provide consistent functionality across all of the applications built with the framework. For example, a very powerful yet flexible component can be used to consult reference data for any field.

Advanced code generation utilities that are designed to automatically build, compile and deploy components, using the logic captured in the"metadata", thereby drastically reducing the amount of code that needs to be "hand written" (and"hand maintained").

The fundamental architectural principles that are adhered to are: Transparent and independent storing of business rules, separate from the database and user interface.

Full web-enablement to give global communication for data sharing and direct access to clients.

Incremental delivery of components.

The preferred architecture has been designed to facilitate delivery of the different business components using a range of technologies without the constraints imposed by the use of specific toolsets for all the components. The components can be delivered using a blend of technologies including Visual Basic/COM, Active Server Pages, JavaScript, HTML/DHTML, Lotus Domino, Java, and Microsoft SQL Server. It is possible to choose the most appropriate technology vendor for the

application and subsequently to have progressive migration of the components that make up an application to better toolsets as these emerge. The result is that the architecture can integrate with any number of different environments with minimal effort, e. g. an Oracle back end instead of SQL Server; Java Server Pages instead of Active Server Pages, and so on.

With reference to Figure 1, at the back end there is a back end database where original data is maintained. In a middle tier, there is a metadata database. This is the repository of all information specific to an implementation of the architecture. The database schema for one implementation is depicted in Figure 2. The middle tier metadata database stores information about what lookups are defined, their names, definitions and descriptions. It also contains information about sort orders, field names and aliases, and the back end database from which they should be sourced.

A metadata front end is provided. This is an Active Server Page application used to manage the content of the metadata database. A Component generator and publisher is also provided. This is a Visual Basic/ Active Server Page application that uses the information captured in the metadata database to generate programme code for the various objects required within an application, compiles the resultant code and distributes it to the appropriate server (s). The objects thus generated can be separated into the following categories : ActiveX (front end validator) components. These objects are used by the front end applications to perform all possible client-side validation and other business logic (calculations, default values) before a browser page is submitted to the server.

Java script generation. These are Java script files generated for inclusion into the front end application to allow manipulation of the front end validator objects with an absolute minimum of manual coding.

MTS (back end writer) components. These objects are typically deployed as COM objects on the middle tier server and handle the actual writing of data to the back end database (s) under transaction control.

There are also generic components, i. e. pre-built standard components which provide generic functionality to applications using the architecture. They include: Grid lookup controller. This is a front end object that provides standardised presentation of lookup information, and also provides a standardised method of returning values to the front end.

Lookup data mediator. This is a front end object that provides methods for refreshing data and metadata in a locally cached data store. It provides a mechanism for front end programs and objects to find out about items in the local data cache, and to synchronise them with the original data source. Data is provided to this object through a call to a middle tier lookup factory server.

Lookup factory. This is a middle tier process implemented as ActiveX DLL running on Microsoft Internet Information Server that refers to the middle tier metadata database in order to retrieve lookup information from the back end database. The process supplies the records set information to front end objects or programs over the http protocol.

The preferred architecture is extremely well suited to

the deployment of applications with complex business rules and forms, within an intranet/internet environment, as it reduces bandwidth requirements to a minimum whilst retaining a rich user interface. Any business rules employed by the system are stored in a format that is easily accessible and recognised by a very large cross section of the development community.

The architecture is "technology flexible" as the back end and front end can be completely replaced independently of altering the middle tier metadata database. It is possible to centralise the storage of all corporate data and preserve investment in legacy systems through the simplicity of integration it provides, and ensures the consistency of updates to multiple back end databases through a Transaction Monitor.

In the preferred system in accordance with the invention,"front end validator objects"are automatically downloaded to, and cached on, the user's local machine as needed, and contain all business logic that can be carried out within the context of a frontend page. This obviates the need to resubmit the page to the server whenever the execution of a business rule or calculation is required. Generic lookup components are used which cache and maintain reference data on a user's PC so that lookup lists can be displayed quickly without needing to download the complete list from the server every time a lookup is requested.

Figure 3 is a screen shot showing how"business"objects can be related to"physical"objects. Figure 4 is a screen shot showing how data warehouse definitions can be created and maintained using metadata. Figure 5 is a screen shot showing how business rule definitions can be created and maintained using metadata.

Claims

CLAIMS 1. A system for accessing a database from a client, in which the client is connected by means of browser technology to an application server, the application server is connected to the database, and validation of at least some data to be transmitted from the client to the database is carried out at the client, characterised in that validation objects are cached at the client and are accessed by the browser technology to validate data to be transmitted to the database.
2. A system as claimed in claim 1 wherein the client is configured to have a local lookup cache, a lookup controller and a lookup data mediator.
3. A system as claimed in any claim 1 or 2, wherein validation data is transmitted from the application server to the client, for caching at the client.
4. A system as claimed in claim 3, wherein a check is made for validation data which has changed, and new validation data is transmitted to the client for caching.
5. A system as claimed in claim 4, wherein the application server builds tables of validation data at intervals and creates a data file, and when a lookup is reported to the application server a check is made to determine whether the data used at the client is from the current version of the data file created by the application server.
6. Data processing means configured to operate as a client in a system as claimed in any preceding claim, wherein the data processing means provides browser technology to connect to the application server, and is

<Desc/Clms Page number 12>

programmed so that validation of at least some data to be transmitted from the client is carried out at the client, characterised in that the data processing means caches validation objects which are accessed by the browser technology to validate data to be transmitted.
7. Computer software which when installed on data processing means will configure the data processing means to operate as a client as claimed in claim 6.
8. Data processing means configured to operate as an application server in a system as claimed in any of claims 1 to 5, the data processing means being configured to generate validation data which is transmitted to the client for caching at the client.
9. Computer software which when installed on data processing means will configure the data processing means to operate as an application server as claimed in claim 8.