Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2001-01-31
2004-05-04
Corrielus, Jean M. (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000
Reexamination Certificate
active
06732109
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to software architecture and more particularly to a software architecture for web-based systems.
BACKGROUND OF THE INVENTION
To develop a web site, web pages are created in a hyper-text markup language (HTML) and stored on a server connected to the Internet and some mass data storage device such as a database. Web hosting companies develop the software and maintain the hardware that provide web-based services for a client, or tenant. Web-site specific applications are also created and customized for each tenant's specific needs. In addition to applications, tenants are likely to need distinct versions of each web page for each type of browser the page is likely to encounter because web browsers are incompatible. For example, one version of a page may be necessary for Microsoft Explorer and another for Netscape Navigator. Moreover, different versions of pages will be necessary for wireless telephone browsers as opposed to browsers designed for conventional computer display screens.
Typical web-hosting services have multiple tenants, each with different needs. It is often the case that some tenants actually have conflicting needs so that the system has to be flexible enough to handle the different needs between tenants and agile enough so that each tenant only uses the logic necessary to do its own processing. This balance is extremely difficult to achieve and so it is not uncommon that web-based systems go through large amounts of logic, performing useless verification processes.
With mobile devices that can access the web, more problems are encountered with publishing web site content. Support for devices with screens of varying size must be provided in addition to changing pre-existing server pages designed for a web browser, which calls for reconstructing the logic behind web pages.
Within every system, there are business rules, or logic, that represent constraints and policies to govern how system information can be modified or accessed while safeguarding the integrity of the application's data. As a system grows, more rules are added and pre-existing rules changed, increasing complexity and making it harder to decipher processing logic when modifying the logic at a later time.
As software is developed and built for multi-tenant services, the system is exposed to the combined changes of all tenants. The information model, which is the sum of all information needed to support all the system users, must be adapted to each specific user's needs in viewing the information who work for different departments, each with a different view of the business world. Information models are typically modeled to suit the initial needs of a system when it is first built. As each new feature or departmental view needs to be supported there is usually a need to change the information model.
However, developers tend to resist making changes to the information model. This often results in using part of the information model for purposes it was not designed. Although this may be the most expedient solution, it almost inevitably causes unexpected complications. For example, assume that a user needs to track the lifecycle of a high priced item, such as a car. If there is no such object in the information model of the system, an object that does have lifecycle support, such as a project object, may be modified to view as a car by copying the project user interface and modifying it accordingly. Alternatively, the developer might use the project object without modification, for example, by introducing a special project-type code, which is not part of the information model but is introduced into the code using the information model. In the event the project object is overhauled, the entire support for the car object would have to be reconstructed. Such changes are particularly troublesome if the database is used by multiple tenants (using the same instance), or if the information model is part of the software delivered to the customer (requiring a time consuming software update). But this was the problem the developer was trying to avoid in the first place by using the information model for purposes it was not designed for rather than modifying the information model.
In the prior art systems, there is no, or poor separation of concern between the structure of information and the structure of its use. In the project example discussed above, although the information structures (Car and Project) were almost identical, the implementation included project semantics in the information model. In other words, each implementation included structures that were specific to each particular application. The best solution would have been an abstract information model. Unfortunately, when using an “abstract model,” the developer writing the business logic must use the structures of the model which, because they are “abstract”, necessarily have abstract and difficult names. Therefore, the developer cannot express the logic in well-known terms. Moreover, because the abstract structures are generic to multiple uses, the developer may need to use several layers of “mental indirection” to obtain the desired result. Therefore, while an abstract information model is very flexible, its abstract nature makes the resulting logic difficult for users and subsequent developers to understand. Separation is needed between the need for an information model capable of holding all of the information in a flexible (adaptable and changeable) way, and the need for the users of the information to understand and work with the information.
The Ovum Model (Engineering for Change: The Ovum six-layer reference model, Neil Ward-Dutton, February 1997), incorporated herein by reference, attempts to address the problems of the prior art by providing a six layer architecture. The Ovum Model, however, merely recites a collection of requirements, without any description or indication of how its architecture should be implemented.
SUMMARY OF THE INVENTION
In accordance with an embodiment of the present invention, a system for transferring information between a user interface and a database over a global information network such as the Internet is provided. A plurality of user interfaces are located on a plurality of user computers. In this regard, the user interfaces are implemented on a browser using a mark up language such as HTML. The database is a relational database residing on a second computer, and is accessed by the user interface via a global information network such as the Internet. In accordance with the present invention, the relational database is accessed through four intermediate processing layers: an interaction layer, an application layer, a business object layer, and an information model layer, each located on a second computer, with the information model layer logically adjacent to the database, and the interaction layer logically adjacent to the user interface operating on the browser. It should be noted that the “second computer” could be a single computer which implements the interaction layer, an application layer, business object layer, information model layer, and relational database, or could comprise multiple computers located in a single or multiple locations, connected, for example, via a LAN or WAN. Preferably, the information at each layer of the system above the database layer is in a form which is immediately renderable on a user interface. Most preferably, the information in each of these layers is in the form of an XML document.
As explained in more detail below, the use of these four intermediate layers provides a separation of concern for developers of applications of the information in the database and is particularly useful in supporting multiple tenancies on the relational database. For example, the accounting department, human services department, production department, and research and development department of a first company will have the need to access overlapping data in the relational database, but each will need this information for a substant
Hallgren Thomas
Lindberg Henrik
Corrielus Jean M.
Davidson Davidson & Kappel LLC
The EON Company
LandOfFree
Method and system for transferring information between a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for transferring information between a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for transferring information between a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3252253