« PreviousContinue »
Execute "make CM"
Read, parses "register, src"; insert application and files into server
to allow tester
CM changes effective date to "today"
Distributed to users as users launch
APPLICATION AND DATABASE SECURITY
AND INTEGRITY SYSTEM AND METHOD
This application is related by subject matter to the fol- 5 lowing co-pending, co-owned U.S. Patent Applications: U.S. application Ser. No.08/405,766, filed Mar. 17, 1995, "Method and Apparatus for Transaction Processing in a Distributed Database System"; U.S. application Ser. No. 08/579,371 filed Dec. 27, 1995, "Billing Statement Render- 10 ing System and Method"; each herein incorporated by reference.
TECHNICAL FIELD OF THE INVENTION
This invention relates in general to maintaining the security and integrity of applications and databases.
BACKGROUND OF THE INVENTION
In the past, a user's access to applications has been 20 controlled by the use of passwords. Generally, the password provides a user with access to all applications, with certain files, e.g., personal files, financial files, etc. being protected by a second password. More elaborate access control schemes have used access control lists for applications, 25 databases, and systems. These access control schemes or systems have significant shortcomings, including that they are not very flexible for large user systems, users are provided access to applications and/or databases which are outside the scope of their work, and thus a user may disturb 30 these applications or databases, and with password protection, the security may relatively easily be breached.
With known systems and applications, there exist problems with identifying and controlling which version of a particular application a user has access to and/or is using. In 35 some systems, when a user is interfacing with another user, support personnel, etc., often it is required that the user verbally ask what version the other is using. Also in many cases, a new version is simply installed over the top of an old version, and new users access the new version automatically. 40 This presents problems in that, if the new version has a significant bug, then the old version needs to be reinstalled, which is confusing and time consuming. Also, this does not allow the testing of the new version before it is installed to all users.
With known systems and applications, problems exist in moving a particular application from a developer to the system. Typically developers customize their systems. This presents problems in moving the developed application from the developer to the system, particularly in relation to troubleshooting the application after it has been installed on the system. Also, problems exist with regard to transferring the files that are necessary for the application to run. Frequently, not all of the desired files are transferred, or the files are transferred in an undesired format.
SUMMARY OF THE INVENTION
In view of these and other shortcomings of the prior art, there is a need for a system and method which insures the g0 security and integrity of applications and databases.
It is an object of the current invention to overcome the above described and other shortcomings of the prior art.
It is a further object of the current invention to provide a security system which is secure, flexible, and allows the user 65 to access only those applications or stored procedures which are required for the user to do his work activity.
It is further an object of the present invention to ensure that a user is using the desired, current version of a particular application.
It is another object of the present invention to provide a framework that application developers use to facilitate transfer of the developer's work to the system.
The present invention includes a user management system having a directed acyclic graph structure to provide a user or group permission to access applications, stored procedures, etc. The present invention also includes a version control management system which insures a user is using the desired current version of an application and provides a format for an application developer to facilitate the development and implementation of an application onto a system.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the present invention and the advantages associated therewith may be acquired by referring to the accompanying drawings wherein:
FIG. 1 is a block diagram depicting the architecture of one embodiment of a system for use in the present invention.
FIG. 2 shows a simplified Directed Acyclic Graph (DAG).
FIG. 3 is a flow chart illustrating, in a broad sense, the verification and access method utilized when a user attempts to access an application.
FIG. 4 is a flow chart illustrating, in a broad sense, the version control management from the point of a user starting an application.
FIG. 5 is a flow chart illustrating, in a broad sense, the version control management system from the application development and version release standpoint.
DETAILED DESCRIPTION OF THE
The present inventive system and method is preferably utilized in a system having an architecture as shown in U.S. application Ser. No. 08/405,766, filed Mar. 17,1995, entitled "Method and Apparatus for Transaction Processing in a Distributed Database System"; herein incorporated by reference. FIG. 1 generally illustrates this system and architecture.
While the various aspects and embodiments of the invention are capable of use in various systems and types of distributed database systems, for simplicity, the system will be described in connection with a Subscriber Management System (SMS) 100 having a distributed database. Such system is useful for, among other things, cable system operations. However, the inventive system and method is not limited to this described system. As shown in FIG. 1, the SMS comprises a plurality of transaction generators labeled 1 through N, where N=any integer. Each transaction generator 120 is connected via a two-way communication link 105 to one (or more) data directory servers (DDS) 150. The present invention may include any number of data directory servers 150, but includes at least one. Each data directory server 150 in turn is connected via a two-way communication link 165 to multiple data servers (DSA-Dsm) 160. Each data server 160 is in turn connected to one or more databases either as components of a single subsystem (processor and database) or through a two way communication link 135. Additionally, each DDS 150 is connected via a two-way communication link 130 to one or more cross reference servers (X-refj-X-ref,,, where N=any integer) 170.
FIG. 1 indicates a block of 1 through N, (where N=any integer) DDSs 150 representing DDS functionality within
the SMS. It is to be understood that, although not shown, connections between transaction generators 120 and DDSs 150 as well as those between data servers 160 and DDSs 150 are preferably individual connections rather than to a grouping of DDSs. For example, Transaction Generator 1 is 5 separately connected to each of the DDSs as is Data Server A. Alternatively, however, DDS functionality may be grouped with common connections to transaction generators 120 and/or data servers 160 as indicated in FIG. 1 so long as proper control between DDSs 150 is maintained. 10
Additionally, the SMS system 100 includes at least one control application 175 for communication between the DDS(s) 150 and a human operator and/or another SMS process. The control application 175 provides, among other functionality, a means for updating the internal rules used by :5 the DDS(s) 150.
When a transaction is generated by a transaction generator 120 and sent to a data directory server 150, the data directory server 150 determines the appropriate server 160 for execution of the transaction. Preferably, this is accomplished by 20 the DDS 150 consulting the internal rules and identifying the arguments associated with the transaction.
The SMS 100 of the present invention is designed to manage a very large number of On Line Transaction Pro- ^ cessing (OLTP) transactions occurring within the system. The SMS 100 of the present invention provides users with the ability to query across the entire database from any client in the system. Similarly, each of the users may update data located anywhere within the SMS 100. 3Q
The transaction generators 120 in the system of the present invention may be any devices capable of receiving input from a user and transmitting that input to the Data Directory Servers (DDSs) 150. This type of device is often referred to as a client and these terms are used interchange- 35 ably herein. These devices may be dumb terminals (i.e., incapable of performing local processing) or they may have various processing capabilities of their own. Examples of transaction generators include, without limitation, PCS, RISC-based workstations and local area networks. In typical 40 applications, there will be a large number of transaction generators 120. Thus, the SMS 100 is designed as an open platform environment which is hardware independent. The transaction generators 120 may be homogeneous in terms of interface and operation or they may be heterogeneous. In 45 other words, all transaction generators 120 may be of one type or there may be a variety of devices interacting with the DDSs 150. It is also possible to permit customer interaction with the SMS 100 through an ARU/ANI (Automated Interactive Voice Response Unit/Automatic Number Indicator) 50 (not shown). In this case, much of the processing may be driven by the telephone number retrieved by the ANI when the customer calls into the system.
The DDSs 150 of the present invention function as the middle tier of a three tier client/server architecture. As 55 illustrated in FIG. 1, more than one DDS 150 may exist within the SMS 100. In such case, each of the DDSs 150 has communication access to all of the other DDSs 150 as well as to each of the data servers 160. The DDSs 150 serve three primary functions. After receiving a client request, the go selected DDS 150 first locates the appropriate server 160 for execution of the request, it then submits the client request to the selected server and finally the DDS 150 returns the result to the submitting client 120.
Transaction generators 120 requesting information from 65 the SMS databases must connect to a DDS 150 prior to accessing data. Through the use of internal rules, the DDSs
150 determine where a remote procedure should run in order to complete processing of a transaction. Access to the DDSs 150 may be efficiently implemented through the use of remote procedure calls (RPCs) which are identified in tables internal to the DDS 150. Any of a large number of standards for such RPCs may be used with the current invention.
The DDS(s) 150 are preferably open server applications that provide a mechanism to direct any data request associated with a generated transaction to a data server 160 that can service the transaction generators' requests. Specifically, the DDSs 150 may be open servers comprising the same or similar hardware as the data servers 160 of the present invention. Alternatively, the DDSs 150 may be configured differently from the data servers 160. The DDSs 150 function to analyze the client's data request transaction and, based upon the transaction type and a set of rules, directs the request to the appropriate data server 160. The types of transactions which are received at the DDSs 150 are based upon a set of stored procedures recognizable to the DDSs 150 and available to the transaction generators 120. The DDSs 150 communicate with a plurality of data servers 160 each accessing one or more storage devices. In a preferred embodiment of this invention the data servers 160 are Sybase SQL (Structured Query Language) Servers which execute Sybase remote procedure calls (RPC). This invention is not, however, necessarily limited thereto and the servers may be of any type so long as the stored procedures are designed for processing by the particular server and the associated database which are selected. It is possible to employ any number of servers 160, transaction generators 120 and DDSs 150 in the SMS 100 of this invention so long as the proper number of communication channels can be supplied and supported.
The data servers 160 maintain the customer data and are accessible by each of the transaction generators 120 through a DDS 150. In a typical implementation, the data servers 160 are SQL devices which are capable of executing the RPCs transmitted by a DDS 150. The databases making up the enterprise can be either homogenous or heterogeneous. In a homogeneous environment, particular protocols for accessing each of the databases are consistent throughout the enterprise. Conversely, in a heterogeneous environment, the particulars of database access vary within the enterprise. In a heterogeneous environment, it is often desirable, however, to render any differences in requirements within the enterprise transparent to user working at the client site. That is, a user should not be aware of any database heterogeneity and a user request should be processed in a standard manner across all resources.
The databases which are accessed in a distributed system may all be located together or they may be physically apart. They may be at the client location or they may be at an alternate site. Databases may be relational databases such as SYBASE (a trademark of Sybase, Inc.) or they may be as simple as a series of flat files.
In FIG. 1, it can be seen that the DDSs 150 interface with a control application 175. The control application 175 functions to allow a system operator to store, update and modify stored procedures available to transaction generators 120. This is typically accomplished by downloading the update to the X-Ref Server 170 which loads the new rules base into the DDSs 150 at DDS startup.
The SMS system also includes one or more X-Ref Servers 170. The X-Ref Servers 170 function as a resource available to the DDSs 150 for determining where specific data resides in the system and for storing the rules base which is loaded