WO2004077218A2 - System and method for unifying data and server functionalities and helping intertalk between these different server functionalities - Google Patents

Abstract

The present invention relates generally to the field of creation of server objects independent of features, functionality and syntactical variations supported by server vendors. More particularly the present invention relates to a methodology of unifying server functionalities and permitting functionality interchange across server objects independent of operating systems, vendor implementation, supported object features and communication protocols.

Description

TITLE OF INVENTION

SYSTEM AND METHOD FOR UNIFYING DATA AND SERVER FUNCTIONALITIES AND HELPING INTERTALK BETWEEN THESE DIFFERENT SERVER FUNCTIONALITIES

BACKGROUND OF THE INVENTION Over the period of technology evolution, many servers have evolved, such as database, web, mail, application servers etc. Each server has its set of functionalities and client types, which communicate using specific protocols and their own proprietary patterns of data. Whenever data has to be exchanged across these server's, only popular vendors of these server's have provided programmable interface components. Also like a standard process of data exchange through import-export of all servers do not have a predefined accepted standard of data exchange. This leads to a lot of data and functional disparity. Any solution provider when selling a business automation solution currently needs a database, web and mail interface working in conjunction with each other. However, the process of automation typically needs digitized data irrespective of the mode of communication used to share information whether ifs a printed matter, fax, voice, telex etc. The popularity of the Internet has forced an industry of technology convergence to accept a standard protocol that is TCP/IP so that any device used for communication stands a chance to share data with other clients at least at the protocol level. Analyzing the current trend of automation and globalization of business processes, the popular mechanism adapted as a mode of communication is emails and web for which two separate servers; namely, a Mail server (like 'Exchange') and web server (like 'Apache') are presently used, apart from a database server, which usually does the back office business process automation. To facilitate data exchange between these servers scripts such as ASP / JSP etc. are used to interact between web servers and database servers, but presently there exists not standard means to exchange data between mail / web and database servers. The current mechanisms adapted to exchange data requires a lot many development and debugging tools and an extra process of data conversion since presentation logic of each of these servers vary. Also this leads to extra set of same user connectivity across different sets of protocols with different authentication mechanisms and various other programming issues. Therefore, there exists a need for providing similar server functionalities by creating all objects of any functional server working on patterns of server resources rather than splitting individually functional servers as separate product entities without compromising on any functionality requirement expect by clients. There exists a further need to have all clients hooked to a unified server, and management of users, security privileges, server data, backup / restore etc can be simplified, while permitting seamless data exchange between server components. There exists a need to allow business logic to be embedded as either a trigger, package or PL script, which executes across server objects and provides real time interactivity between these servers without any external scripting, parsing, interpreting process or any other tiered interface like application server.

SUMMARY OF THE INVENTION

To meet the foregoing needs, the present invention provides a software-implemented process, system and method for use in a computing environment, with a multi functional server agent is to provide seamless business logic application integration between server objects, which is currently performed by application servers or middleware.

To achieve this objective the present invention consists of a parser, which syntactically validates all OQL queries irrespective of clients that is ODBC, web or mail. The simple process is to decompose any functional server into component objects and provide a standard SQL compatible mechanism to access object definition and data and provide interfaces so that these server objects are available as programmable entities by standard development tools. For example the database server can be decomposed into objects such as tables, tablespace, index etc. Similarly web server can be decomposed into application, session etc which are server objects. Also this serves and extends current SQL skill sets to web and mail server and without delving into scripting syntaxes and tagging interpretations, allows developers to focus on business logic rather than presentation mechanism jugglery across various development tools and protocols. The Object Parser handles syntactical and semantic issues; server architectural differences across vendors were analyzed to create related objects and their relations because many vendors did not support objects and their hierarchical implementation varied. Hence parser handled the syntactical issues and server agent handled the object and their functional entities. In case of any independent query with just a singular operation, the nature of operation dictates the flow that is operations like alter or drop have a prior assumption of the object existence but their current state is dictated by object usage in a concurrent user environment. In case of these DDL operations where the object is dropped or design altered care for existing object data, relations with other linked objects, current transactions fired on the object define the flow of execution. Further the object is checked for existence. Further these objects can be of two types one containing data such as database tables etc also called container objects and other type of objects which do not contain data but are purely executable example view, stored procedures etc which don't have data stored in them. Like any database object, which is finally persisted in metadata tables, the web and mail server objects functional entities are designed to embedded in database metadata and routed via a user / schema which serves as a window to access objects as per grants, roles and privileges. All database specific functional features and entities can be applied to these server objects and session related information which either the web server or the mail server maintains is managed as database virtual tables which is updated via audit or a triggered process. Also when achieving vendor independent server object architectural compatibility a data dictionary and related metadata was designed to encapsulate all functionality and features implemented by various server vendors. To isolate and manage physical resource utilization across server functionalities separate tablespaces were allocated during the creation of the topmost hierarchical object as per server functionality and features like storage option, quota, automatic resource growth associated generally with database objects were extended to mail boxes, web server data etc. Also the entire indexing logic for the server objects and resource allocation, utilization is governed by the pattern of data i.e. the data type of the data with respect to the server functionality. Whenever the servers such as a mail server or a web server created persistent data the final format is in the format of database objects having its extents, blocks etc. The current server has implemented its own file system where the constraints dictate the file properties obeyed by the OS and file data is archived as LOB data. Similarly the mail-boxes are maintained as tables and scope of usability of data is exposed through views. Quotas of usage of resources are monitored and auditing of these resources can be tracked, logged and billed which currently is available as a third party tool for servers.

The entire design is based on state machines and modules comprising of various events communication via messages that is it is event driven using Finite State Machine (FSM) concept, the functionality is broken down into a series of events scheduled by kernel.

BRIEF DESCRIPTION OF THE DRAWINGS

The various objects and advantages of the present invention will become apparent to those of ordinary skill in the relevant art after reviewing the following detailed description and accompanying drawings, wherein:

Fig 1 is a block diagram depicting the functional blocks of the preferred embodiment of the present invention.

Fig 2 is a flow diagram illustrating the process by which the request is analyzed, processed and final the output of the request is given to the Dispatcher Agent.

DETAILED DESCRIPTION OF THE INVENTION

While the present invention is susceptible to embodiment in various forms, there is shown in the drawings and will hereinafter be described a presently preferred embodiment with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiment illustrated.

In the present disclosure, the words "a" or "an" are to be taken to include both the singular and the plural. Conversely, any reference to plural items shall, where appropriate, include the singular. Referring now to the drawing particularly in Fig 1 is a block diagram depicting the functional blocks of the preferred embodiment of the present invention.

The OQL Query block 100 receives queries from various clients irrespective of their functionality such as ODBC or OLEDB clients or Web clients such as browser, ftp, etc or Mail Client such as MS Outlook Express. Further the Object Parser 105 parses any query irrespective of nature of client or server vendor that is the parser is capable of parsing database SQL / PL queries, web scripts such as Active Server Pages (ASP) or Java Server Pages (JSP) and any mail client such as MS Outlook Express commands. In the event if the request is syntactically correct an Object Interface 110 based on the source query is created. The Dynamic Dictionary 115 is interfaced with the Object Parser 105 and MetaData Object Dictionary 120. This Dynamic Dictionary 115 plays a vital role in parsing any query. Each word contained in the query given to the parser is checked for existence in the dictionary. This Dynamic Dictionary 115 contains all reserved or unreserved words, symbol and functional details irrespective of the server functionality and aids mappings of the query to form the Object Interface 110.

The Command Analyzer 125 interprets this Object Interface 110 and derives the operation to be performed on object with user specified options. The Parser 103 isolates every syntactically varying vendor specific jargons and an object interface is created as per object properties and features across various vendor syntaxes.

The Vendor Independent Object Analyzer 130 isolates the nature of the object, associated similar features but dissimilar addressibility (vendor specific jargons), and functionalities unique to the object as per request and translates the request parameters into object properties. The preferred embodiment of the present invention handles only the DDL requests hence any object created finally is a set of meta- transaction Data Manipulation Language (DMLs). The OQL or SQL command Translator 135 interprets commands other than SQL too and redirects object functionality which may require server agent functionality but without creation of objects. These typically may involve Database Administrator (DBA) commands or console related User Interface or output buffer settings.

The Metadata Translator 140 analyzes options specified with operations to translate user specified DDL commands into meta-transactions. Any object in a database is generally a perceived entity as per functionality but the physical definition of the object is persisted in database as metadata table records. Hence every other object like synonym, sequence, index, procedure, trigger etc are finally derivatives of basic object table.

The functionality interpretation of their metadata values imparts them their behaviors and features, the execution of which is carried by the server agent. Hence as per user specified object definition the physical definition of the translated object may lay scattered in more than one metadata table. For example suppose the user creates a table object ABC with columns a, b, c the simple definition of table lies in more than one metadata table that is while storing this object definition a basic centralized object is created in VMOBJECTS metadata table and other table VMTABLE save the name of table and associated storage attributes. The data about sub object entities like columns a, b, c is saved as records in VMCOLUMNS table and definition of their data types in VMCDEF. Other disk related resource allocated is saved in VMUET and VMFET tables. Hence as seen the object ABC as perceived by the user internally is a fragmented series of DMLs across so many metadata tables. Also the number of records and values of these records are dictated by the user object definition. Ex: Suppose the user specified that one of the columns of a, b, c was indexed or is a primary key the additional information and definition related constraint is saved in additional tables like VMINDEX and VMCONSTRAINTS.

The Metadata Object Dictionary 120 is the heart of database defining, driving, relating and dictating functionality of objects and their related values. Once a user creates an object the definition and parameters specified during creation restricts and imposes data functionality as per object definition (DDL). The metadata interpretation drives the database and at every operation performed on the object these rules dictated during object creation are obeyed. The dictionary definition is unique in many ways as it encapsulates more than one server object functionality validating rules as per object definition independent of functional server but permitting functionality interchange without any constraint violation.

The Virtual File System Translator 145 is a constraint defined stimulated file system in which all files are archived in database records but following OS specified rules. Whatever information a typical OS file system supports is archived as database record rather than saving file data in ROOT / FAT etc as in any OS file system. All web related files can be either linked with their paths or embedded in the database but their stimulation as root / directory, files etc managed based on the database records rather than relying on OS file system. This feature allows a multitude of enhancements like

1. File level security and access features can be granted which works directory wise in any OS.

2. No OS provides callback functionality to monitor file level operations on any specific file, which can be implemented here very easily as triggers. 3. Schema wise file sharing, versioning or scope of directory view support is very easily possible unlike a FS 4. Access of file system through standard ODBC compliant drivers using ANSI SQL opens a whole world of file system functionality for developers who currently have to toggle between database logic and OS supported file operations for application solutions. 5. Backup / restore and other miscellaneous LOG related activities can be supported programmatically using SQL. 6. The current technology of PUSH / PULL from application data to web data can be eliminated as business logic can be extended to web objects seamlessly and need not require an export import process via HTML / XML scripting. 7. Real time changes can instantly publish data and does not need any intermediate process. Web users get live access and deferred results can be avoided. Once the presentation logic for pages in web site is decided through DTD / XSLT the data is reflected instantly. There is no downtime when site data is being FTP in normal cases of publishing.

The Data Wrapper and Manipulator 150 is a formatting module, which as per nature of client and output translation demanded converts the status of result query buffer to target expected format.

In case the format specification is specified in a XSLT or DTD format the corresponding XML Parser 155 such as SAX or DOM parser rendering functions are evoked to generate the target buffer. Many successful DDL statements executed are just a status notification message which varies as per nature of client that is the result of status is different for a browser than an ODBC client. In case of error the translation of the error code to corresponding error string or HTML page, is also managed by this module.

Accordingly the Output buffer 160 is prepared as per OQL query. After the OQL or SQL or XML query is translated it is given to the Metadata Translator 140, which in turn passes the query to the output buffer as per OQL query.

The Dispatcher Agent 165 is useful for managing this output buffer as per OQL query.

Fig 2 is a flow diagram illustrating the process by which the request is analyzed; processed and final the output of the request is given to the Dispatcher Agent.

On receiving a client request 200, the request is checked for type of server operations 201. Since the agent supports every server objects of database, web and mail there may be direct commands, which are not SQL compatible for other server objects. In the event there does not exist any valid server operation, it proceeds to get first object information 214. In the event of valid server operation the DDL operation is checked 202. In the event of invalid DDL operation, it is verified to check if it is a DCL operation 203. In the event it is DDL operation it proceeds to check whether the object exists 204. The Objects can be of two types, one containing data such as table, index, database space and other do not contain data but are purely executable such as view, stored procedures, etc. In the event the object does not exist, an error is reported 205. In the event the object exists, it proceeds to check for user privileges 206. In the event of no user privilege present, it proceeds to report an error. In the event of user having privilege, proceed to get first object information 214. In the event it is not a DCL operation 203 the request is checked for DML operation 207. In the event of a DML operation 207 the request is given to the DML Agent 208. In the event the request is not a DML operation 207 the request is checked for scheduler command 209. In the event the request is a scheduler command 209 it is given to the Server Agent 211. In the event the request is not a scheduler command 209 it is classified as unknown command 210. After the first object information is obtained, it proceeds to obtain the first record 216. On doing this, it proceeds to check for delete operations 218. In the event of a non-Delete operation, it proceeds to make a tuple 220. After the tuple is made the current transaction block of the table is obtained 222. After the current transaction block of table is obtained further checking is done for sufficient space in the block on disk 224. In the event of insufficient space in block, the next block is examined for availability 226. In the event of availability of next block, the next block is obtained 228. In the event of non-availability of next block, the user quota is checked 230. It then proceeds to check if the user quota exceeds 232. In the event the user quota exceeds, an error is reported 234. In the event the quota does not exceed, it proceeds to get free extent information 236. After the Free Extent information is obtained, it checks for availability of tablespace 238. In the event of no tablespace available, it proceeds to get the file information 240. It then proceeds to check the file for expandability 242. In the event the file is non-expandable then an error is reported 244. In the event the file is expandable then it proceeds to physically expand the file 246. After the file is physically expanded, it proceeds to update the file information 248. After the file information is updated, the free extent information is updated 250. After the free extent information is updated, it proceeds to examine the tablespace availability 252. In the event the tablespace is available, it proceeds to make extent used information 254. After the extent used information is made, it proceeds to update free extent information 256. After the free extent information is updated, the segment information is updated 258. After the segment information is updated, it proceeds to update the allocated quota 260. After the allocated quota is updated, the blocks are initialized 262.

On checking if there is sufficient space in the block 224, if there is sufficient space available in the block, it checks whether the operation is 'update' 264. In the event the operation is not an update it makes an entry in the Rollback segment 266. Similarly after the blocks are initialized 262, an entry is made in the Rollback segment 266. Further after an entry is made in the Rollback Segment 266, it proceeds to write tuple in block 268.

In the event of 'update' operation, it moves the old tuple to the Rollback Segment 270. Further, after moving old the tuple to the rollback segment, it proceeds to update tuple 272.

On checking for delete operations 218, in the event of the existence of a 'Delete' operation, it makes an entry in the rollback segment 274. After the entry in the rollback segment, it marks the tuple as deleted 276 and it proceeds to check for more records 278.

In the event of more records, it proceeds to get the next record 280 and then proceeds to check for delete operations 218. In the event, that there does not exist any more records, it is checked for more objects 282 and in the event of no more objects it is returned 284. In the event of more objects the next object is obtained 286. After the next object is obtained, it proceeds to obtain the first record 216.

Claims

What is claimed is:

1. A system for data definition of objects, comprising: an object interface for pre-determined objects based on said data definition such that said object interface has all elements to be compatible with the features of said object; an input means for accepting instructions and data in a plurality of formats; an analyzing and mapping means to map functionality and features of said instructions with the elements of said object interface based on the addressed notations of said instructions; a processing means to create a plurality of objects and allocating resources based on the elements of said object interface for said data definition; and whereby the said system dynamically determines the dependencies and constraints using available resources.

2. A system according to claim 1 , wherein said invention provides for means for analyzing the said instructions. 3. A system according to claim 1 , wherein said invention provides for means for analyzing the interface.

4. A system according to claim 1 , wherein said invention provides for translating said query using the OQL / SQL translator, virtual file system translator and metadata object dictionary.

A system according to claim 1, wherein a plurality of optimization rules for analyzing and mapping, lies outside the binary source.

6. A method for dynamically generating instruction execution, comprising: decomposing a query into objects, operations, options and values; deriving creation plan; and execution of the query; whereby achieving independence from the features and the syntactical variations supported by the various vendors, versions, products and hardware. 7. The method according to claim 6, wherein said invention supports object creation and execution further comprising: using parsed query as object interface; isolating identifiers and deriving objects/sub-objects and values; analyzing objects and validating operations and object; isolating the options for each of the operations; managing co-relations and dependencies; isolating the operation sequence; isolating option values; sequencing of the module / function execution; deducing creation and dependency plan; checking said resource availability and utilization and execute the query.

A method according to claim 6, wherein said invention provides for the data definition and extends it to any functional server.

9. A method according to claim 6, wherein said invention can be extended for web, database, mail etc.

10. A method according to claim 6, wherein said invention provides for extending transactional support to different servers. 11. A method according to claim 6, wherein said invention imparts cross server properties to any of the servers.

12. A method for associating patterns of data resulting from patterns of functionality in a plurality of wide loosely coupled system and for a user defined relationships on any server objects.

13. A method for data definition of objects, comprising: creating an object interface using the pre-determined objects based on said data definition such that said object interface has all elements to be compatible with the features of said object; providing an input means for accepting instructions and data in a plurality of formats; analyzing and mapping functionality and features of said instructions with the elements of said object interface based on the addressed notations of said instructions; creating a plurality of objects and allocating resources based on the elements of said object interface for said data definition; and whereby the said system dynamically determines the dependencies and constraints using available resources.