Method and apparatus to make and transmit objects from a database on a server computer to a client computer6591272Abstract Contents of databases are translated into objects by reading the database schema metadata to determine data interrelationships and create objects with nominal human to computer interaction. Metadata for any number of databases is normalized in a standardized view. Skeleton code templates representative of final classes to be produced are accessed and merged with the standardized view. Source code for the class of the objects is then generated. At runtime, data objects are then produced by encapsulating the metadata and data values. Communication between database instances and a client computer consists of metadata and database row values., Rows from database tables and the corresponding metadata are transmitted from the server to the client computer in one logical network operation. The final distributed objects are then assembled into the optimal format required by the client computer. To update, delete or create new persistent objects, the reverse process occurs. Claims What is claimed is: Description TECHNICAL FIELD
FILE NAMES SIZE DATE
OSFApplicationTables.java 4,962 02/14/00 12:26p
OSFAttribute.java 1,964 02/14/00 12:26p
OSFBaseObject.java 18,709 02/14/00 12:26p
OSFBaseTable.java 7,991 02/14/00 12:26p
OSFBaseTableIO.java 3,506 02/14/00 12:26p
OSFColumnList.java 5,688 02/14/00 12:26p
OSFComponentObject.java 23,477 02/14/00 12:26p
OSFControlServlet.java 14,741 02/14/00 12:26p
OSFDatabase.java 18,139 02/14/00 12:26p
OSFDataElement.java 1,945 02/14/00 12:26p
OSFDateTime.java 22,519 02/14/00 12:26p
OSFDBIOException.java 2,667 02/14/00 12:26p
OSFDBIOObject.java 18,861 02/14/00 12:26p
OSFDBUpdateValueCompareException.java 6,155 02/14/00 12:26p
OSFGeneralExceptionFormat.java 1,585 02/14/00 12:26p
OSFGenerate.java 281,158 02/14/00 12:26p
OSFGenerateMT.java 248,832 02/14/00 12:26p
OSFIDL.java 10,813 02/14/00 12:26p
OSFKeyField.java 2,248 02/14/00 12:26p
OSFKeyFields.java 3,411 02/14/00 12:26p
OSFMain.java 234,303 02/14/00 12:26p
OSFMember.java 9,143 02/14/00 12:26p
OSFMessageWindow.java 5,064 02/14/00 12:26p
OSFObject.java 5,478 02/14/00 12:26p
OSFObjectCache.java 5,213 02/14/00 12:26p
OSFObjects.java 31,569 02/14/00 12:26p
OSFORBStream.java 59,173 02/14/00 12:26p
OSFORBStreamException.java 1,607 02/14/00 12:26p
OSFORBStreamObject.java 613 02/14/00 12:26p
OSFOwnerList.java 3,731 02/14/00 12:26p
OSFPersistenceObject.java 22,468 02/14/00 12:26p
OSFPickListBuildThread.java 8,746 02/14/00 12:26p
OSFRegistry.java 4,310 02/14/00 12:26p
OSFRelationList.java 6,487 02/14/00 12:26p
OSFRemoteException.java 2,739 02/14/00 12:26p
OSFRulesObject.java 16,548 02/14/00 12:26p
OSFSecurity.java 26,245 02/14/00 12:26p
OSFSecurityException.java 1,595 02/14/00 12:26p
OSFSecurityObject.java 1,974 02/14/00 12:26p
OSFServerObject.java 3,851 02/14/00 12:26p
OSFServletObject.java 107,762 02/14/00 12:26p
OSFServletRunner.java 1,542 02/14/00 12:26p
OSFSystemManagement.java 16,839 02/14/00 12:26p
OSFTableOwner.java 821 02/14/00 12:26p
templates 02/14/00 12:26p
OSFattributecommonrules.java 2,253 02/14/00 12:26p
OSFbuildejserver 1,087 02/14/00 12:26p
OSFcommonrules.java 9,209 02/14/00 12:26p
OSFcontents.html 2,416 02/14/00 12:26p
OSFcontentsDEMO.html 2,675 02/14/00 12:26p
OSFcontentsPROD.html 2,431 02/14/00 12:26p
OSFdbio.java 51,642 02/14/00 12:26p
OSFdeploymentdescriptor.txt 1,628 02/14/00 12:26p
OSFdeploymentdescriptor.xml 1,108 02/14/00 12:26p
OSFedit.html 5,541 02/14/00 12:26p
OSFejhome.java 2,592 02/14/00 12:26p
OSFejmanifest 111 02/14/00 12:26p
OSFejobject.java 8,936 02/14/00 12:26p
OSFejserver.java 21,310 02/14/00 12:26p
OSFhelp.html 4,475 02/14/00 12:26p
OSFinquiry.html 5,718 02/14/00 12:26p
OSFlanguagesedscript.sed 1,079 02/14/00 12:26p
OSFobject.java 86,725 02/14/00 12:26p
OSFpersistence.java 44,242 02/14/00 12:26p
OSFprodbuildNT.cmd 7,119 02/14/00 12:26p
OSFregistry.java 26,452 02/14/00 12:26p
OSFresourcebundle.java 2,362 02/14/00 12:26p
OSFrules.java 8,118 02/14/00 12:26p
OSFsearch.html 4,593 02/14/00 12:26p
OSFserver.java 28,246 02/14/00 12:26p
OSFserverdeploymentdescriptor.xml 613 02/14/00 12:26p
OSFserverrules.java 6,960 02/14/00 12:26p
OSFserverstartup.java 5,129 02/14/00 12:26p
OSFservlet.java 81,345 02/14/00 12:26p
OSFtable.html 5,104 02/14/00 12:26p
OSFtestdbio.java 15,552 02/14/00 12:26p
OSFtestejserver.java 5,949 02/14/00 12:26p
OSFtestobject.java 6,679 02/14/00 12:26p
OSFtestpersistence.java 17,665 02/14/00 12:26p
OSFtestserver.java 18,562 02/14/00 12:26p
BACKGROUND OF THE INVENTION SQL-based databases and the tables and structures contained therein are well known in the art. Typically, SQL-based tables and associated relations are "flat" structures involving elements in rows and columns with elements in a column "related" to elements in different columns by a relation. Structured Query Language or "SQL" is used to define database elements, consisting, but not limited to: tables, columns with tables, data types of columns, relationships between tables, constraints of numerous types, and to perform queries upon and to also perform create, update, delete operations upon the aforementioned elements. Although attempts have been made at standardization, in reality the syntax of SQL and operation of relational databases can vary significantly from one database vendor and type to another. It can thus be problematic, within an application, to change from one database type to another. The process of interrogation of relational database schema or catalogs to obtain information pertaining to the database tables and the interrelationships between database tables is well known. The use of Internet, or Intranet, or other network to communicate from a database computer to a server computer to a client computer is also well known. The use of software to manually map database tuples (rows of a table or, more importantly, multiple rows of related tables) into objects for use by object oriented languages such as lava and C++ is also well known. The use of software to map objects from relations and data in relational database management systems or vice versa to object oriented applications is also well known. The use of software to transmit information in object form from a server computer to a client computer or vice versa is also well known. In the prior art, such as that disclosed in U.S. Pat. No.5,857,197, the process of manually mapping database tuples into objects is typically performed through utilization of graphical computer interface. Using a graphical computer interface in a manual manner for this relational to object mapping operation has proven to be time consuming and error prone. An expert-level technician with extensive knowledge of both the internals of relational databases and detailed knowledge and experience with object oriented systems and languages is typically required to use these software products, referred to as "object-relational mapping tools". These expert-level personnel are usually in practice, both scarce and expensive. In the prior art, databases have been maintained on server computers and when queried by a client computer the resultant objects have been transmitted to the client computer. There is an inherent mismatch between data stored in relational databases and the format and structure of this relational data in object based systems. The problem faced by the prior art and how such prior art has failed is detailed in "Relational Data Hits the Highway, Making Persistent Objects from Relational Data", Miller, Julia K. and Kern, Thomas, pgs. 38-42, Distributed Computing, Jul. 1998. Further, network efficiency problems faced by the prior art are enumerated in "Reducing Network Traffic in Distributed Java Apps", Patten, Bon and McCabe, James, pgs. 51-57, Java Report, Sep. 1999. Attempts to solve these problems in the prior art have been addressed by several methods. A common technique is to create an intermediate translation or mapping between the relational database(s) and the object system though interaction with a graphical interface. It is not uncommon to have to manually create or define all of the attributes and methods of the target objects, then manually map the corresponding relational data. This intermediate translation layer of software either significantly and measurably reduced the efficiency of the resultant application and/or introduced an additional point of failure into the application, thus reducing the overall reliability of the application. In the prior art, manual creation or manipulation of SQL is also typically needed to populate the objects from the database though this intermediate object-relational mapping layer. This SQL can be specific to the brand or vendor of the database, making migration from one database type to that of another vendor costly and problematic. In the prior art, the combination of numerous, heterogeneous databases from different database vendors was either time-consuming, error-prone, problematic, inefficient, or not possible. In the prior art, one could typically update the underlying relational database(s) exclusively through the object system, precluding direct database updates though conventional methods, such as offline or batch database load jobs or tasks, and realtime data communication software. The result would be data presented to end users that would not be current or, worse, when updates were made to the underlying database, the offline or batch changes would be lost. In the prior art, to transmit subsets of related database tables as a distributed objects comprising, e.g. 4.times.5 or a total of 20 elements, 4 objects need to be created at the server computer and transmitted to the client computer with up to, in the case of CORBA, 20 subsequent attribute requests from the client computer to the server computer interspersed there between for a total of 40 transmissions, or more, over the network to populate the 4 objects. This is wasteful of the network and server resources and reduces the performance and scalability of object systems so constructed. Thus, what is required and would be particularly useful would be: 1. A computer program product that embodies and contains the human knowledge of an expert in the fields of both relational databases and object systems and object languages, and, 2. A computer program product that reduces or eliminates the manual and error-prone manual mapping operations between the relational database(s) and the object oriented classes required by the object-based system, and, 3. A computer program product that provides the ability to combine multiple types of heterogeneous databases from different vendors into one logical object view, so that the business application software sees one logical set of objects in a vendor-independent manner, and, 4. A computer program product that provides a transparent way to update and access relational databases as persistent objects without the need to ever use or be aware of the specific query language (or SQL) unique to a given database vendor, thus providing the capability to change vendors and types of a given relational database so as to preclude the necessity to alter the high-level source code at the application level, and 5. A computer program product that permits offline database loads and batch database update jobs and real time data communications interface software to execute concurrently with, and update the same databases as, the object based system, whilst concurrently providing consistent and current data to the end-users and eliminating the possibility of lost updates, whilst also performing this in an efficient manner, and, 6. A computer program product that generates software that, at execution time, is as efficient or more efficient, and also less problematic, than software that could be manually designed, constructed, written, and tested by an expert in the fields of relational databases and object systems and object languages. SUMMARY OF THE INVENTION In the present invention, an automated, expert method, system and program product that translates and transmits metadata and data from database tables into familiar and customary objects desired is disclosed. The method comprises the steps of reading the definitional elements of the databases to determine data types and interrelationships between relational data elements. These data interrelationships and data types are assembled in a vendor-neutral standardized view of the database schemas and the plurality of all the possible logical objects contained therein in the databases are created. Template definitions generically represent the classes of the objects desired. An inexperienced user can, if so desired, easily select a subset of all possible objects represented by the databases through use of a simple and intuitive graphical interface. Conversely, tables and interrelationships not required by the application can be easily deselected through use of the said simple and intuitive graphical interface. Source code for the classes is then generated from the standardized view when merged with the prepared template definitions. The source code is then compiled into binary executable form into the classes desired. Pseudo-objects are then produced by dynamic generation and execution of pre-optimized SQL, enveloping values that result from execution of the generated prepared SQL statements. Result sets from said associated prepared statement operations from the appropriate database tables and rows are normalized into a standard format, then combined with metadata from the database schemas. The pseudo-objects are then ready for transmission to the client computer or the requester of the objects desired. The present invention also relates to a method of communicating elements of a database table between a server computer and a client computer. A pseudo-object is generated by the server computer with the pseudo-object comprising rows from singular database tables, or optimized joins between multiple related database tables, that comprise the object desired. The plurality of datatypes present in the relational databases are normalized into a singular standardized form to prepare the data for transmission to the requestor of the object. Metadata of the elements where the metadata is the relationship between the data elements is also generated by the server computer. The metadata and normalized pseudo-object data are transmitted from the server computer to the client computer in a single logical transmission.. At the client computer, the elements are assembled into the final objects from the pseudo-objects and metadata received, into the format required by the software on the client computer without runtime overhead on the database or middle-tier server computers. The present invention also relates to a method of communication of new objects from client computers and their conversion into one or more rows to be inserted in the corresponding databases in transactional mode. The present invention also relates to a method of communication of changes to existing objects from client computers and their conversion into updates to one or more rows so as to modify the rows of the appropriate tables in the corresponding databases in transactional mode. The present invention also relates to a method of communication removal existing objects from client computers so as to delete the rows of the appropriate tables in the corresponding databases in transactional mode. The present invention also relates to a method that permits the databases to be shared with multiple applications, so as to ensure that the most current data is presented to the end-users and that updates from end users do not collide with updates, inserts and deletes to database columns and rows performed outside of the object system. Finally, the present invention also relates to an article of manufacture embodied as a computer usable medium having computer readable program code embodied therein configured to perform the aforementioned methods. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic hardware view of the relationship of a client computer and a server computer in the environment in which the methods of the present invention are utilized. FIG. 2 is a schematic software view of an embodiment of one method of the present invention with regard to the translation of elements of a relational database table into classes desired. FIG. 3 is a schematic block level diagram of a software view of another method of the present invention in communicating elements of a database tables from a one or more database server computers and/or middle-tier computers to a client computer. FIG. 4 is a chart showing Normalization Object Topology. FIG. 5 is a chart showing OSF Object Hierarchy. FIG. 6 is a model of Basic OSF Persistence. FIG. 7 is a screen shot of an example of a Generated HTML Page. FIG. 8 is a screen shot of an example of a Non-Frames Generated HTML Page. FIG. 9 is a screen shot of a Database Connect Panel--DB Login. FIG. 10 is a screen shot of a Database Connect Panel--Advanced Connect. FIG. 11 is a screen shot of a Database Connect Panel--DB Driver and URL. FIG. 12 is a screen shot of a Database and Table Select--No Selections Made. FIG. 13 is a screen shot of a Database and Table Select--CUSTOMER Table Selected. FIG. 14 is a screen shot of an Object and Attribute Naming. FIG. 15 is a screen shot of an Object and Attribute Naming--Attribute Name Correction. FIG. 16 is a screen shot of a Database and Table Select--All Tables Selected. FIG. 17 is a screen shot of a Generation Options--Primary Options. FIG. 18 is a screen shot of a Generation Options--Enterprise Architecture. FIG. 19 is a screen shot of a Generation Options--Secondary Options. FIG. 20 is a graph of an OSF High Level Input Output. FIG. 21 is a screen shot of an IDE Design Mode HTML. Template. FIG. 22 is a screen shot of a Generated HTML Subframe. DETAILED DESCRIPTION OF THE DRAWINGS Referring to FIG. 1 there is shown a network 10 in which the methods of the present invention can be practiced. As is well known, the network 10 comprises a server computer 12 connected to a network 14 to which a number of client computers 16 are also connected. The client computers 16 communicate with the server computer 12 through the network 14. The network 14 can be an Intranet in which the network is private, it can be in the nature of the Internet, which is the public accessible network or it can be a secure private virtual network, a private network which uses the Internet. The server computer 12 can comprise an IBM compatible PC, or a workstation or a mini-computer or a mainframe. Each of the client computer 16(a-b) can comprise IBM compatible PCs or other types of computers having at least a microprocessor, disk storage and some memory for processing. It can even be a NC or network computer in which there is no disk for storage. In the first method of the present invention, shown in FIG. 2, software 21 in the nature of a computer usable medium, such as magnetic disks or CD-ROM, having computer readable program code embodied therein is loaded onto any computer connected to the network 14, such that it can access a plurality of databases 20(a-e). The software 21 generates the necessary class file source code compilation then subsequent execution by the server computer 12 and, if necessary, by the client computer 16. The software 21 presents a graphical computer interface to the user on the client computer 16 requesting the user to establish connections to the various database management systems or databases 20(a-e) to be selected and to be translated into objects desired. Thus, for example, if a user desires to access data from a plurality of databases 20(a-e), which are all different and from different vendors and having different object properties, the method of the present invention first seeks out the definitions or the schemas from these databases 20(a-e). The software 21 then performs an inspection of the schema definitions and an optional inversion of each database table contained within the databases 20(a-e). Thus, each table is optionally read from top to bottom and each value of each column is inspected. From this inspection, a pick list is generated for ultimate presentation to the user at run time, in which the user can minimize data entry errors. Further, by internationalizing the pick list descriptions, it permits the user at the client computer 16(a-b) to select the preferred language. To perform this, the software 21 executes a pick list scan thread for each database table in databases 20(a-e). Column values are selected as pick list candidates based upon field, length and count of unique values. A java.util.LlistRresourceBundle of a derived class is generated for each object and foreign language selected at this time. A translation file contains internationalized strings for each attribute descriptor and descriptor for each pick list in each object. Further details of this process is set forth in the section entitled "Database Table Scan/Table Column Value Inversion" in the Principles of Operation set forth hereinafter. Once the database tables have been selected and each column of values has been examined, a standardized view of the data objects 24 is generated. The "standardized view of the database objects" 24 is structure of vectors and hash tables 24 having the relationship between the elements of the database table, common to all the database tables in the databases 20(a-e) without any specific elements that are unique to the database tables, that are attributable to any particular vendors. Thus, this structure 24 so generated does not contain any code that is specific to the type of the data object that the user has desired nor programming language selected, e.g. C++, JAVA, or object language. The structure 24 so generated only has the definitional elements and values common to the database tables in the databases 20(a-e). This standardized view of the databases 20(a-e) is generated and a pictorial representation of this is set forth in the diagram entitled "Normalization Object Topology" of the preferred embodiment description, hereinafter. Skeleton code templates 22, generalized versions of the final objects to be produced, are also supplied to the software 21. Code 26(a-z) for the class of the particular objects desired by the user, e.g. Java/C++, XML, sed or shell scripts, IDL etc. is then generated. The code 26 is used to implement the standardized view of the table 24. The foregoing method can be analogized to the following in the word processing area. Assume the documents 20(a-e) have been created by various different application programs such as Word, WordPerfect, PageMaker, Claris, etc. The standardized view of each particular document 24, may be the DOS text version of those characters without the specific attribute codes or metadata produced by the respective programs but with the text indicating where the attribute codes should be placed. For example, different word processing programs generate different code for the attribute of "bold" or "underscore". The standardized view of the document 24 simply has the reference to the words that constitute the document as well as to indicate that that particular word or phase is to be "bolded". The code 26 that is so generated would then provide the specific bold code for that object or that version of the document desired. It is the use of templates 22 which are not object-specific combined with standardized view of object specific tables 24 to convert into code 26 (a-z), such that after compiling and execution pseudo-objects 30 of the classes desired and its associated metadata 31, is produced at run time, that is the basis of the first method of the present invention. The software 21 to perform the foregoing method is set forth in the software modules entitled: OSFMain.java and OSFGenerate.java, within the Principles of Operation set forth on the CD-ROM filed herewith. Referring to FIG. 3, once the code 26 (on FIG. 2) is compiled and loaded upon server computer 12, object access or update requests can originate from client computer(s) 16 over network 14. Server computer 12, in response to an object access request, generates the pseudo-object 30 and the associated metadata 31, in a particular object of choice is generated. During execution, subsets of database tables in the databases 20(a-e) (on FIG. 2) are enveloped by code 26 (on FIG. 2) to become a pseudo-object 30 desired, along with its associated metadata 31, and is transported as a single logical network packet unit transmitted synchronously or asynchronously over the network 14 to the client computer 16. The pseudo-object 30 so transmitted over the network 14 with metadata 31 is received as the received pseudo-object 32 and received metadata 33 at the client computer 16. However, as can be seen from the previous description, the received pseudo-object 32 is in essence data a subset of rows from database tables in databases 20(a-e) of the relevant entries comprising a plurality of entries. Thus, the received pseudo-object 32 at the client computer 16 is then assembled into a plurality of true objects 34(a-f) in an object, or block of objects; or hierarchical or "tree" object representation 38 having the specific relationships between the objects 34(a-f). The object(s) 38 then can be presented to the user through conventional display means such as HTML etc. The manner by which the pseudo-object 30 and metadata 31 is transmitted over the network 14 in which the data and their relationship is transmitted in a single packet unit is as follows. The pseudo-object 30, is as previously described, comprises a plurality of the values 34(a-f) of the object 38, in the user interface of the client computer 16. The relationship between these objects 34(a-f), called metadata, was transmitted along with the pseudo-object 30. In the logical network transmission pseudo-object 30 to the client computer 16, the pseudo-object 30 comprised data values of the objects 34(a-f). In addition, the metadata 31 indicating the relationship between the pseudo-objects 34(a-f) was also transmitted. At the client computer 16, the received pseudo-object 32 is assembled to retrieve the data values 34(a-f), and the metadata is then used to place these data values 34(a-f) into the user interface of the client computer 16, or in the case of creation of new objects, from the client computer 16 to the server computers 12 containing the database tables in databases 20(a-e) (of FIG. 2). In this manner, an efficient means of transmitting a number of database elements from a server computer 12 to a client computer 16 and new objects or object updates or object deletions from client computer 16 to server computer 12 is accomplished. Thus, in the present invention, where the client computer 16 makes a single request and a single pseudo-object 30 with metadata is transmitted over the network 14 with the received pseudo-object 32 thereafter assembled and placed into the user interface of the client computer 16, only two uses of the network 14 are made. This greatly reduces traffic on the network 14 and dramatically reduces CPU processing time requirements on server computer 12. Conversely, when new objects are created, a single object 34 is created on client computer 16, is transmitted over network 14 to server computer 12 where the pseudo-object 30 is created by metadata 31 on server computer 12 to create appropriate new table rows in database tables in databases 20(a-e) with only two uses of network 14. Further, the client can assemble the objects into the precise format desired by the user interface object being populated by object data; such as tree or hierarchical format, or block or grid data format. The software to perform the foregoing method is set forth in the software modules entitled: OSFORBStream java, OSFORBStreamObjectjava, and OSFORBStreamExceptionjava which are on the CD-ROM filed herewith. The preferred embodiment of the present invention is also disclosed in the following Principles of Operation. PRINCIPLES OF OPERATION PREFACE This document provides, for reference purposes, a detailed definition of the OBJECTSERVERFACTORY product (OSF) and the PRO-OBJECTS, support classes, XML, and scripts generated by OSF. Built exclusively upon open, generally accepted industry standards, OSF has successfully addressed several problems associated with distributing persistent, relational objects built from relational databases over networks. In particular, a generalized and efficient relational to object translation and algorithm and object distribution methodology has proven elusive. It is these processes and algorithms that are unique to OSF; thus a detailed description of this unique technology is therefore an appropriate focus of this preferred embodiment of the present invention.. The result of the above technologies is a set of object-oriented networked remote database access methods that use generally accepted industry standard Internet-centric protocols and software engineering standards to extend persistent objects securely out from relational databases. OSF-created PRO-OBJECTS permit rich user interfaces to be built that would otherwise would be inefficient, even on the fastest of networks. The net result is an application system with superior aesthetics and performance than would otherwise be possible using current distributed object technology. Outlined herein is the minimum level of insight required to understand and take maximum advantage of OSF to generate a set of persistent relational objects and to efficiently implement these objects into an application. Required Background The reader is assumed to have a working knowledge of relational databases in general and significant development experience with C, C++ or the Java programming language. A basic understanding of object oriented technology and terminology will prove helpful. Document Organization The information presented in this document is grouped into the following sections: The Introduction highlights the major design patterns and the resultant benefits, technical features and structure of OSF. Readers, whom desire an overview can read only this section, then skip to the subsequent detailed sections of further interest. OSF Software Organization describes the major software component classes within OSF, PRO-OBJECTS and support classes. This section provides the necessary background material for adequate comprehension of the following detailed sections. Included here is the class structure of PRO-OBJECTS. OSF Expert System Operation outlines how internal OSF definition objects are assembled and organized through the OSF object-oriented graphical computer interface as databases are opened, schemas are scanned, tables are selected or deselected for assembly into objects, objects/attributes names are verified, and class generation options are chosen. OSF Template-based Software Generation details how OSF template files are organized and the scanning and replacement algorithms are used to generate database-specific persistent-relational objects, support classes and scripts. A complete example demonstrates how the OSFGenerate class builds a PRO-HTML browser component. OSFORBStreams shows how related attributes and multiple objects can be blocked together to reduce network traffic by two orders of magnitude or more. Object update/locking and object assembly/disassembly algorithms are outlined. The OSF object <-> relational persistence translation model is implicitly defined here. OSF Support Classes are then discussed. Examples of these support classes include pick list generation, distributed edit/business rules, and real-time performance measurement and analysis. The Registry class is central to runtime system configuration and it is described in this section. The technical approach to integrate these components is unique and the result is a highly effective expert software system. INTRODUCTION OSF addresses many nagging problems associated with making persistent, distributed object components from relational databases and specifically, relational to object translation. The algorithms and processes used for these endeavors are unique in the software engineering community and are the result of a significant research and development investment. OSF addresses the need to present sets of relational database tables to client applications and applets as proper, true distributed persistent, relational objects (or PRO-OBJECTS for short). PRO-OBJECTS can take the form of RMI server-side objects; CORBA version 2.0-style objects and even objects in dynamically generated HTML streams. This subject area has been a challenging design area since object-oriented programming was first extended over networks via CORBA to object-oriented client applications from centralized object servers using traditional relational databases. There are many aspects to the problem of how to best produce coherent CORBA-style objects from relational databases: distribution and communication mechanisms, performance, object lifecycle, locking, integration to legacy applications, recovery, scalability, fault-tolerance to name a few. Indeed, the problem is multidimensional. A generalized, pre-packaged and intuitive commercial solution has been nearly impossible to imagine. Until the invention of ObjectServerFactory, that is. ObjectServerFactory uses several unique algorithms and design patterns to address these and other problems that have to-date precluded a successful turnkey solution. These designs are unique to the ObjectServerFactory product and the resultant PRO-OBJECTS OSF creates for runtime execution. These algorithms and design patters are a significant leap over the current state-of-the-art. A synopsis of these algorithms is enumerated in this section. Relational to Object Translation with OSFbRBStreams OSF uses a technique known as Deferred Object Assembly to build true objects from flat relational tables. The previous version of OSF given to a client in Q2 1998 worked admirably, but server overhead required to read flat tables and build objects was significant, noticeable in fact. This version used the generally accepted and standard methodology used in all distributed object applications today; first read the database tables and assemble the objects in the server or in middleware near the server, then transmit the object(s_ to the client for use in the graphical computer interface. However, some object requests are simple while others very complex requiring significant amounts of CPU time to join many records from numerous database tables to create blocks of objects needed by client application interfaces such as grids and tree controls. Given potentially powerful PCs on a user's desktop it makes sense to match CPU requirements to the machine that made the request, freeing up the servers for subsequent requests. This is the idea behind distributed computing-distribute the work over all machines in the network. Since only the final object assembly work is done in a web server or web browser (in the case of an applet), the "thin-client" model is preserved. Further, the raw relational data can be processed one time and assembled into the presentation format desired by the graphical interface component currently in use in the browser. Consider that objects displayed in a tree control require different assembly than in a form or a grid/spreadsheet. OSFORBStream Definition OSFORBStream.class is a generalized object used on both the transmitting and receiving object streams, both to the client and to the server. By sending all attributes that make up an object or by sending a block of objects in one stream, object-oriented network traffic is reduced by at least an order of magnitude when compared to standard CORBA or RMI solutions. The easiest way to define an OSFORBStream is to provide a functional summary of the four sub-types of OSFORBStreams. Server side, transmit OSFORBStreams are used to package the raw records read from the flat database tables. Metadata is sent along with the raw table records to identify the base table records, identify the primary and foreign keys and data fields and the relationships between key fields between the table records. The reason metadata is sent is so client-side objects do not need to have server-side definition files imported into the client-end application. This makes OSFORBStreams dynamic so clients or object requesters can be insulated from changes to the backend database tables. A very useful feature but was complex to implement in practice. Client/requestor side, receive OSFORBStreams process the server side, transmit OSFORBStreams. The aforementioned metadata is isolated, verified then used to assemble the objects into the form desired by the requestor. Client/requestor side, transmit OSFORBStreams are used to create, delete and update server-side objects. Server side, receive OSFORBStreams are used to disassemble the objects back into the corresponding flat database tables so the appropriate object delete, object insertion or object attribute update operations can be performed. Object Requestor May Not Be A Client Workstation Note that the client-side is referred to as client/requestor. This is because in many cases the requestor of a persistent, relational object is indeed the client workstation. It is quite common in fact for the requester to not be the end client workstation where the terminal operator or end user resides. Consider: An HTTP servlet requires a PRO-OBJECT for use in server-side business rules or domain logic. The web browser running on the client workstation can not perform final object assembly since the Java VM is not running (or needed to process the dynamic HTTP stream). Thus the server-side HTTP servlet acts as a requestor and processes the OSFORBStream created by the underlying Persistence class. Middleware domain logic may request a PRO-OBJECT via CORBA. The final PRO-OBJECTS are then assembled by this middleware requestor and consumed, created, updated or deleted as needed by the domain logic. Stateless or Stateful Session Enterprise JavaBeans containing pure domain or business logic can and do request PRO-OBJECTS. The Session EJB is the requestor and performs the final object assembly. Symmetry of the OSFORBStream Object One symmetrical Java class handles both server and client/requestor streams of types receive and transmit. Again, this seems intuitive, obvious and simple. Yet anyone familiar with network programming will appreciate the complexity of making a generalized object like OSFORBStreams work in an efficient, robust generalized manner, and still be symmetric for both transmit receive, both client and server. OSFORBStream Media and Transport Independence OSFORBStreams were originally designed to transmit blocks of objects via CORBA-2 using the GIOP mapping to TCP/IP (IIOP). Significant network traffic reductions also result using OSFORBStreams over the Pure Java Remote Method Invocation protocol known as RMI. However, clean design permits use of the OSFORBStream class to transfer objects through raw sockets or even method to method (as in the case of HTTP Servlets). In fact, OSFORBStreams can even be sent over any communications media, such as RS-232/485 serial communications. All features of OSFORBStreams (client independence, automatic compression and encryption etc) operate effectively on whatever protocol or transport media is used. Deferred Object Assembly OSF performs the absolute minimal database I/O to build the object(s)- one read per query request; no more, no less. This is true whether the client end or server middleware requests a single object or a block of objects. Object Block Reads This section briefly summarizes how blocks of objects are requested, created, transmitted, assembled and presented to the requestor (1) Requesting An Object Block, Key Field Issues Object blocks are requested by specifying a value for each primary key of-the high-level parent object and the count of objects desired. The top-level parent table is then read, requesting a number of rows equal to the number of objects desired. If multiple tables comprise the object, a "left outer join" with a subselect is generated by the SQL generator and then generated (2) No SQL Strings No SQL strings are used anywhere in OSF or the PRO-OBJECT server support classes. Avoidance of SQL strings and use of proper logical database objects not only reduces maintenance, but results in pure object software which is easy to maintain, extensible, and results in software which is database-vendor independent. That is, the same code runs against any vendor-specific brand of RDB. (3) OSFORBStreams After a transmit-type OSFORBStream is instantiated, metadata needed for object assembly is appended to the OSFORBStream. Then result objects from the individual table reads are stringified, appended to the OSFORBStream and transmitted to the client or consumer of the object (as in the case of server middleware). Note that the OSFORBStream is compressed and encrypted by default before being transmitted to the client. Also note that OSFORBStreams can be transmitted using any communications protocol or media, such as CORBA, RMI or BSD sockets over IP, serial lines (PPP and RS232/485).or any other media. Thus the name OSFORBStream is a bit of a misnomer because the streams do not have to be sent through an Object Request Broker. (The astute reader will have observed that, even in the CORBA-2 world, CORBA object communications and data transfers typically bypass the ORB for speed and to eliminate a point of failure.) (4) Object and Attribute Identification After the OSFORBStream is received, decompressed and decrypted, objects and base table object components are identified through the use of an IDL enumeration. Object IDs and Attribute IDs are generated at application'build time through the use of any vendor's IDL compiler. These object IDs are transmitted with the stringified base table rows in the OSFORBStream so the rows can be identified. (5) Object Assembly Metadata is sent at the front of the OSFORBStream so rows can be merged and redundant fields eliminated during object assembly (all foreign keys are by definition redundant and must be removed from the child rows during object assembly). This metadata takes the form of OSF KeyMaps in external string form and are part of the OSFORBStream header. Static helper methods in the OSFORBStream class assist with the construction of these OSFORBStream headers. At the client end, final object assembly is performed depending on the visual object that is to contain and display the data. A very high-speed assembly algorithm matches related base table records, completing the object assembly process. A java.util.Enumeration interface implemented by OSFORBStream is used to then access the objects or object segments and ultimately attributes in the correct and proper sequence. Fully Qualified Object Access Reading a block of objects requires a key value for each primary key in the highest-level parent table, as noted in the discussion above. To read a single object, a key value is needed for each primary key for each base table that makes up the object. This is referred to internally in OSF as "fully qualified object access" as opposed to "partially qualified object access" as outlined in the previous section. The Deferred Object Assembly process, including building of the OSFORBStreams, transmission, and object assembly are the same whether fully or partially qualified object access is used. Object Disassembly For object insertions, an OSFORBStream is built in the client that contains the new attributes of the object to be inserted. The OSFORBStream is transmitted to a server where the object is disassembled into its base table components; the underlying RDB table records are then inserted. This is a more traditional approach--the work is done in the server. However, the generalized algorithm which maps the object to the underlying tables is unique to OSF and uses OSFKeyMap objects to disassemble the objects when insertion, object update or object deletion is required. Compression and Encryption Because of the inherent network performance efficiencies associated with blocking of n objects into one transmission or network packet through the use of OSFORBStreams, OSFORBStreams are used for the vast majority of client and server communication between PRO-OBJECTS and their backend server-side support classes. Accordingly OSFORBStreams provide a convenient point to encrypt and compress the object and attribute stream. By default, the OSFORBStream class compresses and encrypts the stream before transmission and decrypts and decompresses the stream upon receipt. A short overview of encryption and compression techniques is described. Encryption Details The PRO-OBJECTS runtime uses a very fast dual-asymmetric-random-key encryption algorithm developed at the same time OSFORBStreams were designed. The objective was to create an encryption scheme that was highly efficient and suitable for use on corporate Intranets only to keep prying eyes away from the data. When a PRO-OBJECTS based applet loads, a stream of 64 random integers is transmitted to the client. The OSFORBStream is thus encrypted. The stream is now ready for transmission over CORBA as an IDL-defined OSFORBStream data type or over another transmission media or protocol (because OSFORBStreams are transport, media and protocol independent). (6) SSL Support Of course, all of the above is compatible with web servers running in secure mode with SSL. In the case of SSL, if a hacker were to decode an SSL-encoded network packet they would then be faced with an encrypted OSFORBStream. Thus we offer an additional level of security that is well suited for the most sensitive of data. Compression Details Standard java.util.zip.Deflater and java.util.zip.Inflater classes are used for decompression and compression. No proprietary or special programming is involved here. Use of CORBA-Standard IIOP Accessors NOTE: OMG IDL generated by OSF defines all attributes in all persistent relational CORBA objects as read-only. Thus the standard getter remote CORBA accessor methods are available but these do not use OSFORBStreams. This raw IIOP network traffic is not encrypted by default and thus the underlying TCP packets are open for viewing for anyone with a network protocol analyzer. The network packets are also more numerous as well. OSF Events, Exceptions and Asynchronous Communications A really brief outline of OSF events and exceptions is contained in this section. Persistent Object Events A custom OSFPersistentObjectEvent class is used to communicate state changes of the object to other components in the applet, server middleware or other component using PRO-OBJECTS. These events are:
final static int OBJECTDELETE = 1 + FIRSTEVENT;
final static int OBJECTUPDATE = 2 + FIRSTEVENT;
final static int OBJECTCREATE = 3 + FIRSTEVENT;
final static int MATRIXUPDATE = 4 + FIRSTEVENT;
final static int OBJECTINFORMATION = 5 + FIRSTEVENT;
final static int COMPONENTEXCEPTION = 6 + FIRSTEVENT;
The standard JavaBean property change events are also supported for bound properties. Each attribute that composes the object is a proper bound property as well. The astute reader will note the absence of a read completion event. An OBJECTOBDATE event is posted to notify the component of a read completion. OSF Exceptions A comprehensive exception handling scheme handles all server-side exceptions, standardizes and normalizes them then transmits the exceptions via CORBA. When received at the client end or requesting server-side middleware, PersistentobjectEvent.COMPONENTEXCEPTION events are fired to all registered listeners in the PRO-OBJECT with all indicative data about the exception in a format presentable to the end-user. A minor CORBA-2 limitation is that exceptions may only be thrown over the network when the synchronous, blocking remote accessors are used. Synchronous remote CORBA methods are available for all PRO-OBJECT server implementations, but no exceptions will be thrown over CORBA by default. This is because PRO-OBJECTS by default utilizes the asynchronous IIOP accessors, as identified by the Async suffix on the remote method call. Asynchronous IIOP remote method invocations are most commonly referred to as Distributed Callbacks and are the preferred way to invoke remote method calls via CORBA. Thus a brief description of how ObjectServerFactory utilizes Distributed Callbacks is in order. A coherent mechanism to transport exceptions was needed which was independent of the type of remote method call used (asynchronous or synchronous). This is described in the next section. Asynchronous Communications OSF CORBA-style PRO-OBJECTS utilize by default asynchronous IIOP Distributed Callbacks. Early prototypes used standard synchronous method calls and this was not optimal. This is because the threads that issue the remote method call obviously block until the replies are received. If the thread that issued the remote IIOP method call was the AWT thread (a common occurrence), then the graphical interface would effectively be locked up until a reply was received from the server implementation. An example will prove enlightening and will simultaneously in detail explain OSF-specific technical architecture. Here is an excerpt from the IDL BaseObject class from which all OSF-generated PRO-OBJECTS derive:
// Enumeration for ORBStreamEvents
//
enum ORBStreamEvent
{
GETOBJECT,
GETOBJECTBLOCK,
GETOBJECTBLOCKKEYSONLY,
NEWOBJECT,
DELETEOBJECT,
UPDATEOBJECT,
USEREVENT
};
<snip>
The above event Ids are used in the one-way xoxxObjectAsync method calls (where xxxx is get, delete, insert or new). That is, the event type identifying the method operation is passed as the last argument of each Async method. Note the forward declaration of ORBStreamReply and locate the actual declaration at the end of the default IDL preamble. Observe the local (or client) reference of ORBStreamReply is a/ways sent as the first argument of an Async IIOP method call. And, as noted above the ORBStreamEventID is the last argument.
// base class definition. Note that distributed callbacks are used for
// this interface as optimal performance is required here.
//
// forward reference to ORB Stream callback:
interface ORBStreamReply;
interface BaseObject
{
// basic *stateless* Object I/O
// Persistent <-> Relational Object operations which pertain
// to the entire PRO-OBJECT
OSFORBStream getObject(in string keylist)
raises (GeneralException);
oneway void getObjectAsync(in ORBStreamReply returnstream,
in string keylist, in long /* (ORBStreamEvent) */ event);
OSFORBStream getObjectBlock(in string keylist, in long count)
raises (GeneralException, MultiDBSynchronisationException);
oneway void getObjectBlockAsync(in ORBStreamReply returnstream,
in string keylist, in long count, in long /* (ORBStreamEvent) */
event);
OSFORBStream getObjectBlockKeysOnly(in string startkeylist, in
long count)
raises (GeneralException, MultiDBSynchronisationException);
oneway void newObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBStreamEvent) */
event);
void newObject(in OSFORBStream orbstream)
raises (GeneralException, MultiDBSynchronisationException);
oneway void deleteObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBstreamEvent) */
event);
void deleteObject(in OSFORBStream orbstream)
raises (GeneralException, MultiDBSynchronisationException);
void updateObject(in OSFORBStream orbstream)
raises (GeneralException, MultiDBSynchronisationException);
oneway void updateObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBStreamEvent) */
event);
void setKeyFields(in string keyfields)
raises (GeneralException);
boolean pingObject ( )
raises (GeneralException);
};
// ORB Stream server-> client generalised callback operation
interface ORBStreamReply
{
// exceptiondetail is null if OSFORBStream and ORBStreamEvent
is valid
oneway void returnORBStream(in OSFORBStream stream,
in long /* ORBStreamEvent */ event, in string exceptiondetail);
};
Observe that one common callback object is used to reply to the requestor notwithstanding the type of remote operation (getobject( ), getobjectblock( ), newobjecto( ) updateobject( ) or deleteObject( )). The type of reply is always an OSFORBStream and the event type sent in the initial request is copied to the reply in the in long/* ORBStreamEvent */event parameter of the ORBStreamReply callback object. This generalized design pattern is highly efficient as only one client-end or server-middleware requestor callback object is required, and thus only one async IIOP event reply processing Thread is needed. (7) CORBA 2 and AWT 1.1 Delegated Event Integration If an exception occurred on the remote operation, details regarding that exception will be placed in the in string exceptiondetail parameter (see IDL example in the previous section). If the remote operation completed normally and the reply OSFORBStream is valid, then exceptiondetail is zero-terminated, that is containing only the 0.times.00 byte. Finally, if exceptiondetail is not a zero-terminated string, an OSF PersistentObjectEvent object of type COMPONENTEXCEPTION is instantiated and the event fired to all listening components. This is how exceptions are thrown over CORBA through asynchronous distributed non-blocking IIOP callbacks and how these events are propagated through the client or middleware requestor to all listeners through the standard lava 1.1 delegated event model. Thus CORBA events are tightly and cleanly integrated to lava events. OSF is unique in implementing this non-traditional yet highly efficient approach. OSF Object Servers Combine intelligent multithreading with the use of OSFORBStreams and Deferred Object Assembly and fully asynchronous operation, and the result are very lightweight and fast object servers. This level of performance and scalability has been heretofore impossible using traditional distributed relational <-> object architectures. ORBStreams and Deferred Object Assembly with a coherent asynchronous event model make CORBA work properly, even over a slow 56K, voice grade, dialup PSTN connection. Herein is a guiding principle of OSF: generate the code and then get out of the way. There is no TP Monitor requirement or Application Server component used or required by OSF object servers when the HTTP/servlet and CORBA architectures are selected. This reduces cost by eliminating unnecessary software product license fees. Lower server overhead permits a single server to concurrently service more client workstations than would otherwise be possible, reducing server hardware costs significantly. Response time is maximized for all concurrently connected end-user client workstations. CORBA Server Implementation Activation Mode All OSF-generated object servers are multithreaded, stateless implementations and are scheduled to run automatically depending on the desired architecture: Ultra-thin client architecture. Here the web server invokes the appropriate stateless server class as specified in the HTML originally transmitted to the client, servlet.properties and other configuration files Thin client architecture. At _ bind( ) time the orbixdj Object Request Broker examines its Implementation Repository to determine the stateless .class server file to launch. See note below on activation mode. Enterprise EJB Architecture. The application server invokes the appropriate class server file as defined by the Deployment Descriptor and other configuration files used by a J2EE-compliant EIB application server. (8) Activation Mode with CORBA Activation mode is not really a consideration with OSF-generated CORBA-style object servers as OSF CORBA object servers are essentially independent of CORBA activation mode. Early on in the design of OSF it was decided to put each individual database I/O operation in a separate thread, so that one database request would not block or otherwise affect another request in any way. As a result the Persistence classes are multithreaded and by-design are guaranteed thread-safe. Since all types of object servers use the same persistence classes, all object servers are implicitly multithreaded. Shared Activation Mode: Shared activation mode can be used when registering a CORBA object server implementation since shared activation mode saves memory and nominalizes ORB overhead. Since all object servers, regardless of architecture, start a thread each time a database has to be accessed, one user will not affect another in the server in shared activation mode. Per-client activation mode can also be used if lots of server resources are available and the absolute best performance is desired for the client workstations/end users. We recommend this option and it is the default used in the script that registers CORBA object servers with the ORB. Stateless Operation Persistent relational object data exists in two and only two places: within the RDB (its disks and cache) and in the client. There are no upstream caches or client specific data in the server implementations. The underlying database(s) is/are queried each time a persistent object method is invoked. This facilitates load balancing and recovery in addition to improving server performance, as there is no client or remote object-specific context data to store and fetch. Also, there are no upstream caches to synchronize when updates, deletes and inserts are made to the underlying database. In fact, the overhead, time delay and latency of database round-trips with recent releases of any database from any database vendor (such as ORACLE version 8 and 9) is quite nominal if the data is contained in the cache of the database server or member of a database server cluster that handles the data request. Latency of queries of one millesecond or less for recently accessed rows that are known to be available in an ORACLE version 8 or 9 cache are frequently observed. Thus the design decision to implement stateless object servers result in a relatively insignificant amount of incremental overhead in the RDBMS server backend. (9) Security Implications Stateless object servers (whether RMI with EJBs or CORBA) improve security significantly. This is because, by definition, there is no client data resident in the server middle tier between client requests. As a result: 1. The probability that client context can be inadvertently assigned to the wrong client is zero. So, for example, one client can not attain the security state and access rights of another. 2. The probability that one client can inadvertently alter that of another in the server is dramatically reduced since client context areas exist only in the servers for only a bit longer than the database round-trips required to satisfy the persistent object request. The memory for server-side client control blocks is freed and reclaimed as soon as the reply is sent to the client or requestor. 3. The possibility that a hacker can spoof a session into an object server and examine the client context blocks is zero since these context blocks are non-existent. 4. The possibility that a hacker can log in as a legitimate client then alter session security attributes to that of another user is again zero since there are no security attributes in the server to alter a session. Given the improved performance associated with stateless object servers and improved security one gets as well, the design decision was made early-on to write stateless object servers. OSF Object Servers of all varieties are stateless, whether the object servers are HTRP servlets, CORBA implementations or Stateless Session EJBs. Because there is no security context in object servers, true, nominal security information has to be transmitted along with each client request. However, security context by default is encrypted, the session security token is buried into an OSFORBStream when possible. Further, validation of a sequence number, client IP address, client hostname and timestamp is performed on each received session security token before the username contained therein is used for an access check. Thus an incremental bit of network overhead is necessary to retransmit the client security context on each request. And an incremental amount of server overhead is necessary to ensure that the client is not being impersonated. In fact, a secure security infrastructure will revalidate a user internally on each request anyway so the net downside is an increment of network overhead, a few dozen bytes tops for each request. (10) Definition of a Remote Object Reference Given the understanding of stateless object servers, we can now define an OSF-based remote object reference from the standpoint of the client or requesting middleware object. On OSF remote object is a combination handle and JavaBean state object to a set of persistent, relational server methods which are an object-oriented window to the underlying RDB. Since the server implementations never contain persistent data, failover and load balancing are facilitated using standard IP and DNS configuration techniques-no additional third party software-is-required, further reducing costs. Since failover is transparent and fast, web server reliability is not as important, thus one can further reduce costs by using generic INTEL hardware. There are several additional advantages to using stateless object servers and these will be enumerated in subsequent sections where appropriate. Locking Traditional "optimistic locking" is used when updating objects with a few additional improvements beyond the prevailing prior state-of-the-art to maximize performance and simultaneously improve data integrity. When a persistent relational object is to update the corresponding database tables, the PRO-OBJECT component first builds an OSFORBStream of type UPDATE with the ObjectID and the key field(s) required for fully qualified object access. Then only the attributes that are to be changed in the persistent relational object are added to the OSFORBStream. In addition to the attribute ID and the new attribute value, the old attribute value is added to the OSFORBStream as well. Given that PRO-OBJECTS can take the form of JavaBean components, it makes sense to handle the persistent relational update in the same manner as the update of a JavaBean bound property (in fact, that'is precisely what occurs: the attribute property is changed and then the remote RDB is synchronized, with the old, previous value of the attribute being sent to the server in the OSFORBStream). The OSFORBStream is then transmitted to the server implementation. A remote server exception will restore any changes made to bound properties and fire a PersistentObjectEvent.COMPONENTEXCEPTION to all registered event listeners. On the server side of the update, the OSFORBStream of type UPDATE is received. Then the key fields are extracted from the OSFORBStream. Using the attribute,. IDs, the new/revised object attributes are mapped to the correct underlying base table and column. A transaction is then started on the current connection object to the database. The underlying base tables of the object are read and the record rows are locked with intent to update via the persistence class. The current values in the database then are compared between the object just read and the previous values in the OSFORBStream supplied by the client or requesting middleware. These steps are taken if the attribute value as believed current by the client is not matched to the column value in the database: A rollback( ) is issued against the current Connection object in the server implementation to roll out any partially completed updates and to free all locks an OSFDBValueUpdateCompareException is thrown over CORBA to the client PRO-OBJECT a COMPONENTEXCEPTION PersistentObjectEvent is thrown in the PRO-OBJECT to all interested and registered event listeners the end user notified that he or she was dealing with stale data If all updates are applied without error a commit( ) is issued on the RDB Connection object in the persistence object and a normal return status is returned via CORBA to the PRO-OBJECT. Thus we see how updating is fast, efficient and secure in OSF-generated object servers and how the server backend integrates nicely to a client/requestor component model. This locking scheme is particularly advantageous when the relational databases are being accessed concurrently by other applications. Database Table Scan/Table Column Value Inversion OSF performs an inversion of each database table at application build/generation time. That is, each table is read from top to bottom and each value of each column is inspected. This is possibly time-consuming scan is performed primarily for two reasons: picklist generation and data type determination. Internationalized Resource Bundles, Picklist Generation Data entry errors are minimized when a Choice or drop-down picklist is presented. If real-word descriptions rather than values are presented in the picklist, the interface is much easier to operate and understand. Internationalize the picklist descriptions and let the end-user select their preferred language and the application system then becomes even more successful. OSF generated UI components and client-end PRO-OBJECTS do just this. Also, ultra-thin clients benefit from OSF-generated HTML <select> pull down menus as OSF builds <option> statements for each pick list candidate element. Refer to the section entitled OSF Template-based Software Generation for an example of an OSF-built picklist. OSF fires a PickListScanThread for each base table during the PRO-OBJECT generation process. Column values are selected as pick list candidates based upon field length and count of unique values. This precludes picklists from being built from inappropriate columns, such as street addresses. A java.util.ListResourceBundle-derived class is generated for each PRO-OBJECT and foreign language selected at PRO-OBJECT generation/build time. The translation file contains internationalized strings for each attribute descriptor and descriptors for each picklist in each object. Please refer to the Appendix for an example resource bundle generated from a couple of the ORACLE DEMO starter tables. (11) Language Translation sed Scripts Since a given field descriptor or pick list descriptor can and probably will be used in many PRO-OBJECTS, a sed(IV) script is also generated which contains all unique foreign language strings to be translated for a given language. This is the file that is sent to a translator for implementation of a given language. When translation is complete, sed is run using the script as input and a mass exchange is performed to all resource bundle-derived class files at One time. This is a real time-saver and avoids manual edit of each resource bundle or to download a singular huge translation file into the browser at runtime. So it is the internationalized descriptors which are loaded into the java. awt.Choice. Thus we see how picklists are tightly coupled to internationalization by design. OSF-generated PRO-OBJECTS are unique in this regard as it uniquely balances ease of translation and client memory utilization, thus minimizing translator expense and at the same time maximizing the efficiency of the applet or application. Base Edit Rules The schema definition of the column is used as the initial internal data type for each attribute in each PRO-OBJECT. However, while the columns are being scanned for picklists, alphanumeric and character datatypes are refined further by inspection of the actual data. If a column in a database contains only alpha characters (A-Z, a-z), then the base edit rules contained in the PRO-OBJECT will not permit any characters other than alpha characters to be written into the column. Other OSF rules that can be enforced are alphanumeric, alphanumeric with punctuation, numeric, and date. Note that all edit rules and business logic are implemented and executed in the browser, so data does not have to be sent back and forth to and from the server software simply to be edited. Nor will database constraint exceptions be generated in the backend DB server, database network round trips can be avoided. Further, the error messages built from the OSFRulesObject base class and presented to the terminal operator are far, far more precise and understandable than constraint violation messages built by relational database management servers. The result is a further reduction in network traffic, far better response time and coherent and precise error messages from the perspective of the end-user. Class Codefile Generation The above functionality and more is implemented by a state-of-the-art expert system we call ObjectServerFactory. OSF has several additional unique features, most significant of which are: 1. Unification of numerous RDBs in a vendor independent manner, creating a unified application view of what was to this point separate "stovepipe" applications 2. Automated object and attribute naming and normalization 3. Language-independent template based class codefile generation (programming language, that is) 4. Serialization of object views of databases to persistent disk files facilitates regeneration and change propagation when code templates change or definitions of databases change Consolidation of Multiple Relational Databases When OSF is started the DBConnect window is opened and presented to the developer. This window identifies the databases and the associated schema tables to be scanned by OSF. When the RDB connect parameters are entered, a tool bar button entitled "Test Connect" attempts to open a database, build a connection pool and acquire a hotJDBC Connection object from the connection pool. The developer can concurrently connect to as many databases as desired-there is no technical limit. (12) Logical Display of Databases Each database for which a connection has been successfully completed shows up on the subsequent DBSelect window as a tree control node under the root node. Table owners are displayed under each database node in the tree control. Tables by owner are displayed when a table owner node is opened and finally, the columns in a table are expanded when a table is clicked or selected in the DB Select tree control. In this manner, OSF provides a consolidated view of numerous relational databases for easy selection. Automated Object and Attribute Naming OSF uses sophisticated algorithms to convert table names to proper object names and column names to attribute names. In essence, all of the garbage (numerics, underscores, and other non-alphanumeric characters) is removed from the column and table names. Then, using the /usr/dict/words file from a Solaris 2.6 system, the words within each table and column name are capitalized. Special suffixes, such as 'id" are also capitalized. Manual Correction of Object and Attribute Names This process, though good, is not perfect. To permit precise adjustment of OSF's "best guess" of normalized object and attribute names, full editing capability is provided. Using the OSF Object and Attribute Naming windows of the OSF expert computer graphical interface, the developer can add and delete words to and from the word list. Also each object name and attribute name can be manually corrected if so desired. Refer to the section entitled "OSF Expert System Operation" for additional details. Language-independent Template-based Class Codefile Generation Though written in Java, the code generator can be used to generate class files and thus PRO-OBJECTS in any language, such as C++ or Basic. This is accomplished because no programming language specific functionality whatsoever is hard-coded in the OSFGenerate code generation object. Instead, template files are used with special tags used to identify points in the code where persistent relational object statements need to be inserted.. Replacement is recursive and nested code repeat blocks are supported. Here is an example from the beginning of the PRO-OBJECT client-end CORBA component template:
/**
* ##ObjectName##Object Java Component
*/
// Generated by ObjectServerFactory (TM)
// Copyright TriCoron Networks, Inc. 1998, Patent(s) Pending
package ##Package##.client;
import java.io.Serializable;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import java.beans.PropertyChangeSupport;
import java.beans.PropertyChangeListener;
import org.omg.CORBA.ORB;
import IE.Iona.OrbixWeb._CORBA;
import org.omg.CORBA.SystemException;
import com.tricoron.OSFv13.OSFBaseObject;
import com.tricoron.OSFv13.OSFObject;
import com.tricoron.OSFv13.OSFORBStream;
import com.tricoron.OSFv13.OSFORBStreamObject;
import com.tricoron.OSFv12.OSFSyetemManagement;
import ##Package##.servercommon.Registry;
import com.tricoron.OSFv12.GeneralExceptionFormat;
import
##Package##.servercommon.##ObjectName##Package.##ObjectName##AttributeIDs;
import ##Package##.servercommon.ORBStreamEvent;
import ##Package##.servercommon._ORBStreamReplyImplBase;
import ##Package##.servercommon.GeneralException;
import ##Package##.servercommon.MultiDBSynchronisationException;
import ##Package##.servercommon.ORBStreamReply;
import ##Package##.servercommon.##ObjectName##;
import ##Package##.servercommon.ObjectID;
import ##Package##.servercommon.##ObjectName##Helper;
public class ##ObjectName##Object extends OSFObject implements Serializable
{
// manifest constants
final int MAXKEYCOUNT = ##MAXKEYCOUNT##;
final int ATTRIBUTECOUNT = ##ATTRIBUTECOUNT##; // includes all key
fields
// primary object instance attributes
##attributeblock##
public String ##attributeName## = "";
##endattributeblock##
// other instance vars
public String beanname_ ="";
public String keylist_ [ ] = new String[MAXKEYCOUNT];
public String keyliststring_ = "";
// handy offsets for vectors and matrices or attributes and descriptors
##attributeblock##
public int ##ATTRIBUTENAME##ATTRIBUTEID =
##ObjectName##AttributeIDs._ ##ATTRIBUTENANE##AID;
##endattributeblock##
// transient attributes
protected static transient int instancecount_ = 0;
protected transient ORBStreamReply returnstream_ = null;
// ##ObjectName##-specific transient attributes
// remote proxy object declaration.
protected transient ##ObjectName## ##objectname##_ = null;
// obligatory zero-arg ctor
public ##ObjectName##Object ( )
throws GeneralException
{
// create unique component instance name
synchronized (this)
{
instancecount_++;
}
beanname_ = this.getClass( ).getName( ) + instancecount_;
String hostname = locateServer( );
try
}
// bind to IIOP proxy object
##objectname##_ = ##ObjectName##Helper.bind(
":" + "ObjectName##Server", hostname);
// establish asynchronous callback object
returnstream_ = new ##ObjectName##LocalImplementation(this);
}
<snip>
OSFGenerate looks for the ##targets## and essentially fills in the targets. The parameters come in off the Generation Options property pages in the OSF graphical interface and from OSF-internal database normalization objects. (13) Basic Target Insertion Example When there is a one-to-many relationship between a singular ## target## and n lines of code, the OSFGenerate class is sufficiently intelligent to tidy up the punctuation. Example:
final static String[] COLUMNNAMES =
{
"##COLUMNNAMES##",
};
Expands to:
final static String[] COLUMNNAMES =
{
"CUSTOMER_ID",
"NAME",
"ADDRESS",
"CITY",
"STATE",
"ZIP_CODE",
"AREA_CODE",
"PHONE_NUMBER",
"SALESPERSON_ID",
"CREDIT_LIMIT",
"COMMENTS"
};
(14) Repeat Blocks A powerful feature of the OSFGenerate class is that nested, repeating code blocks are supported. This permits code to be generated that is a function of the next level of detail down from the current context of the software. For example, in the above OSFobject.skl template it is necessary to declare a JavaBean bound property for each attribute in the persistent relational object. This is defined through the use of three OSF tags: 1. ## attribute block## defines the start a repeat block where the context of the attribute in the current object changes on each iteration. If there are eight attributes in a given object, the attribute block is repeated eight times. 2. ## attributeName## tells OSFGenerate to take the name of the current attribute on this iteration of the repeat block, change the first character of the attribute name to lower case, then insert this attribute name in place of the ##attributeName## target. 3. ## endattributeblock## defines the end of the attribute repeat block Thus, using the DEMO Customer and Sales Order database tables shipped with version 7, 8 and 9 of ORACLE.RTM. and the three line repeat block above as an example:
##attributeblock##
public String ##attributeName## = "";
##endattributeblock##
. . . the CustomerSalesOrder persistent relational object (derived from the CUSTOMER and SALES_ ORDER tables) would expand to the following Java source code:
public String customerID = "";
public String name = "";
public String address = "";
public String city = "";
public String state = "";
public String zipCode = "";
public String areaCode = "";
public String phoneNumber = "";
public String salesPersonID = "";
public String creditLimit = "";
public String comments = "";
public String orderID = "";
public String orderDate = "";
public String shipDate = "";
public String total = "";
See the appendix for an example list of the special tag targets used by OSFGenerate to create persistent relational objects. (15)Template Use Summary Here are a few examples of templates that are read in by OSFGenerate at object-generation time:
Template file name: Purpose:
OSFtestpersistence.skl Command line test template for Persistence
classes
OSFtestserver.skl Command line test template for Server
OSFtestobject.skl Implementation classes
OSFobject.skl Command line test template for PRO-OBJECT
OSFrules.skl JavaBean classes
OSFresourcebundle.skl PRO-OBJECT JavaBean state class template
OSFlanguagesedscript. PRO-OBJECT business and edit rules class
skl template
Foreign language translation file template
OSFdbio.skl Language specific master translation file
(sed scripting
OSFtestdbio.skl language)
OSFpersistence.skl Template for low-level DBIO
Command line test program template for
low-level
OSFserver.skl DBIO classes
OSFregistry.skl Template for server side object <-> relational
translation classes (CORBA)
Template for stateless CORBA server
implementation
OSFservlet.skl classes
Template for the application-specific
registry class
OSFedithtml.skl containing all parameters for a given set of PRO-
OBJECTS and support classes including registry
accessor methods and the object map
Template for the Java servlet PRO-OBJECTS
used by
OSFtablehtml.skl the ultra-thin browser clients
Basic form used for display and editing of
singular
OSFinquiryhtml.skl objects by ultra-thin browser clients. Read
in by the servlet
PRO-OBJECTS. When the form is completed it
is also read in and processed by the servlet PRO-
OSFejb.skl OBJECT classes.
Output template used by the servlet
PRO-OBJECTS
OSFejbobject.skl when more than more object is to the displayed in
tabular format
Template used by servlets to generate
dynamic HTML
to ultrathin browser clients for advanced,
mult-object filter inquiries.
Template used to dynamically entity Enterprise
Java Bean-style PRO-OBJECTS using
SQL-free bean-managed persistence.
Template used to encapsulate the client-end home
and client stubs / state objects of Enterprise Java
Bean-style PRO-OBJECTS
(16) Rapid Software Change Propagation Think of OSF as a super-fast intelligent software editor. If a one-line change is to be made to all CORBA object server classes, for example, the OSFserver.skl template can be changed in one place and OSFGenerate run in standalone mode from a command line. The change will be propagated via OSF to all server implementation classes in a matter of moments. Thus, the error-prone process of manually applying the same change and testing to a related group of similar programs is no longer necessary. OSF performs the requisite change(s) rapidly and accurately. Recompilation is expedited since a build script is generated as well to recompile all modified programs. (17) Faster Relational <-> Object Translation The overhead of using a generalized programming model to handle different database relations is avoided because a native code object is built to operate on a specific relation. This is what makes ObjectServerFactory unique as an Object-Oriented Software Engineering product. (18) Language-Independent Code Generation If C++ servers and Java clients are required, OSF C++ server templates can easily be created from a stable, released, production C++ server source class. Or an example from a vendor or a prototype can be easily converted to a PRO-OBJECT template and prepared for input to ObjectServerFactory. Thus a full set C++ server side persistent, relational objects can be generated in a very short period of time if the Java skeleton templates we supply are deemed to be somehow less than desirable. As an example of this language-independent code generation capability of OSF, observe in the Template Use Summary table above, UNIX sedlanguage translation files are generated to apply a single foreign language translation to multiple resource bundle class files..Also, several sets of HTML files are also created from templates as well for use in ultra-thin clients. For EJBs, XML deployment descriptors and are also generated. Thus we see OSF is not limited just to object-oriented languages such as C++ and Java, but to any language which has to be customized as a function of the contents of a given set of relational databases. Regeneration via State Serialization The graphical interface component of OSFGenerate has File/Save and File/Open pulldown menu items and a Save and Open buttons on the toolbar for the window frame. This functionality permits the state of a given run of OSF to be saved and restored using flat files via Java object serialization. This makes it easy to, say, change one attribute name in a given persistent relational object someplace and be absolutely certain that all of the necessary changes are made in each of the appropriate server or client class modules. The OSF software is far faster, more precise, and thus more efficient than even a team of skilled software engineers. This is why we refer to ObjectServerFactory as an expert system Summary It should now be apparent how ObjectServerFactory and the PRO-OBJECTS it creates to effectively and successfully address today's heretofore unsolved problems associated with building coherent, distributed persistent remote objects from relational database tables. Recall these problems involved distribution and communication mechanisms, performance, object lifecycle, locking, integration to legacy applications, recovery, scalability, and fault tolerance. To summarize, here is how OSF solves these problems. Distribution and Communication Mechanisms OSFORBStreams are the key to distributing objects through CORBA, RMI, raw sockets or other communications media. Object elements or attributes are blocked up and multiple objects are subsequently blocked into a singular network packet. Object oriented interfaces and views are preserved on each end of the OSFORBStream. Use of OSFORBStreams permits data streams to be encrypted and compressed, contributing to further network efficiencies and adding additional security. All OSF-supported server types (servlet, CORBA implementation and EJB) rely on OSFORBStreams to provide a level of performance efficiency which is at least one and perhaps two orders of magnitude greater than competing solutions. Industry standard interfaces are used, while at the same time, portability, vendor independence and transport independence is maintained to protect the software investment of our customers. Performance OSF does not need a TP monitor or an Application Server as it generates native CORBA server implementations or servlets. However, use of an EJB application server is needed for OSF built Enterprise Java Stateless Session bean generated components by definition. Both synchronous and asynchronous IIOP and RMI methods are supported; asynchronous methods are supported via familiar CORBA distributed callback objects. Stateless server operation improves performance at the beginning and end of each HTTP, IIOP or RMI invocation. Stateless server operation permits far more efficient and dynamic fault tolerance and load balancing. Object Lifecycle Object lifecycle issues are irrelevant for OSF-built persistent relational objects by-design. The reasons for this are: 1. OSF object servers do not use any caches upstream from the underlying RDB cache 2. Remote object server implementations are stateless and thus do not need to contain any client data 3. Any data in the client that is modified is first checked for currency on the server side, making sure the terminal operator is working with the most recent data when making changes. 4. An effective publish-and-subscribe model is employed to keep client data current when in changes in the underlying database In the case of Java Beans, the previous value of a bound property has to be supplied to update a bound property. We transmit this old or current value along with the new or revised value in an OSFORBStream of type update when modified object attributes are sent to the server. If the value has changed since it was last fetched from the client, then we know the user is looking at stale data and a DBUpdateValueCompareException is thrown. Thus object lifecycle issues are moot by design. Locking Optimistic locking is employed so as to preclude the possibility of deadlocks by minimizing the time the locks are held. Note OSFORBStreams of type UPDATE contain only the object attributes changed by the end-user, further easing locking requirements. Complete underlying DB table records are almost never completely rewritten. Integration to Legacy Applications PRO-OBJECTS and their support classes were designed to run along side of the existing legacy applications from day one and share the same databases in real time. The idea was to simplify testing and expedite release planning and migration to production of OSF-based solutions, an arduous process in some large, enterprise environments, which can be painfully bureaucratic. Thus there are nominal issues associated with legacy applications; the most significant of which is transferring domain or business logic and rules from the legacy application to the new OSF-created solution. If OSF could automate business rule transfer it would be more than an expert system, it would be telepathic. Recovery Since the OSF-generated object servers are stateless, a PRO-OBJECT application can lose a connection to one WWW or middle tier server and reconnect to the original server or another in mid-stream with no loss of data or functionality to the user. In fact, a server can be rebooted when the end-user is but to lunch and the applet will continue running as though web server had been running uninterrupted. Scalability Scalability by definition is the characteristic of a distributed client-server architecture that permits additional hardware capacity to be added to efficiently service large additional load increments without change to the application software. Solutions built using ObjectServerFactory are highly scalable, though each of the architecture options provides scalability in different ways. Because of stateless object servers, full multithreaded design, no upstream database caches and deferred object assembly, server side overhead is thus nominalized, providing a basis for scalability for each of the OSF application architecture options. (19) Ultrathin Client Architecture Scalability To reiterate, this architecture option uses a Java-aware Web Server to schedule Java Servlets for processing of HTTP streams received from client browsers. Multithreaded Servlets read the database(s), perform the requisite relational to object translation, generate a dynamic HTML reply and then transmit the HTTP stream to the client browser. So let's assume a web server bogs down with combined server and OSF object server overhead. How is capacity added? The solution is simple. Create another WWW server, install the servlet .class files, register the servlets and configure the servlet.properties and other properties needed by the web server and test. Then set up the local DNS server to perform round-robin address translation between the two web servers. That is one www.servername.com addresses is mapped to two IP addresses through DNS. Off-the-shelf functionality shipped with any coherent DNS server can be used to load-balance requests between multiple OSF-generated object server hardware platforms. Thus, using simple round-robin DNS or a TCP/IP load balancer, one can create a pool of Web Servers with one name, such as www.domainname.com. Browser requests to www.domainname.com are then assigned to all web servers in a pool. If the current pool of web servers become busy, additional web servers can be configured and added to the pool without changes to the OSF-built servlet backend software. Since no application software changes are needed to add additional capacity, the application software solution is deemed scalable. (20) Thin Client/CORBA Architecture Scalability Thin Client architecture uses CORBA-2 object servers to distribute persistent, relational PRO-OBJECTS to clients or server middleware implementing domain or business logic. The Object Request Broker is contacted when a remote object is needed and the ORB via the IDL-generated stub code in the requester or client returns an object reference to the application. One can configure a pool of Web servers using DNS in an identical manner like the Ultra-thin client architecture. Alternately, with certain CORBA-2 implementations such as OrbixWeb one can use an IIOP proxy to add a layer of object servers between the web servers and database servers (refer to the WonderWall product at http://www.iona.ie). Thus by moving the CORBA object server implementations off the webservers, a multi-tier distributed architecture can be implemented that has the ability to withstand large, random bursts of arriving traffic and still maintain acceptable response time. So we see how the CORBA-2 architecture can have an incrementally higher level of scalability than the HTTP Servlet architecture. Again the OSF-built application object server software does not have to be changed to take advantage of this additional capability. (21) Enterprise/EJB Architecture Scalability Because an application server is used to house the OSF-built Enterprise Java Beans, there is additional capability provided with these monitors that increase the ability to scale backend servers built using Enterprise Java Bean components. Consider the WEBLOGIC EJB server from BEA. One can setup clusters of WEBLOGIC servers and add additional object servers, as additional capacity is needed. The trade-off with this architecture option is that the application servers user more overhead and consume more system resources by their presence. Yet the capability added with a product such as WEBLOGIC (clustering is an example) can provide a higher overall level of throughput and simultaneously better response times if properly configured. We endorse EJB architecture accordingly as capacity can be easily added without any changes to the business application or OSF-built PRO-OBJECT components. (22) Scalability Synopsis Thus, no matter which hardware configuration is chosen the underlying OSF-built application software is unchanged. Any QSF distributed object solution is thus highly scalable; due primarily because of the object servers are stateless. This also permits individual requests within a session to move around from server to server. Other advantages to stateless object server design will soon become apparent. Fault Tolerance and Load Balancing Many applications built today require a user to terminate and restart the application when a network, hardware or software failure occurs. Also users may have to logoff and login/reauthenticate when a network, hardware or software problem occurs. We consider both of these methods of human, end-user recovery to be not at all acceptable. Each ObjectServerFactory architecture solution offers transparent recovery in the event of network, hardware or server software component failure. In addition, server load can be easily balanced between servers within a given login session. How this capability is enabled through solid design is and intelligent design patterns are outlined in the following sections. (23) Ultrathin Client Architecture Rule #1 in the distributed component business is to "Never let the users fall asleep in front of their workstations". Since the OSF-built servlets are stateless, conversations can move from one web server to another during a session without difficulty. For example, a browser session can be started on Web Server A and Web Server A will send a dynamic HTTP reply. The end-user can fill out a form or perform an inquiry and the next inbound HTTP stream can be directed or transmitted to Web Server C transparently. This is possible because there is no client data or state information on Web Server A needed to process the request sent to Web Server C and process correctly. Round-robin DNS, though simple and inexpensive, has technical problems. Most significant of which is if one of the Web Servers pack it in, lock up or otherwise crash, a timeout has to occur before the next server in the address list is contacted. These delays can be noticeable and thus significantly adversely affect response time. Third party front-end redirector hardware and TCP/IP load balancers can be used to maintain constant contact with a pool of WWW servers. Thus traffic is dynamically redirected in the event of failure without perceptible delay by the end-user. Round-robin DNS also does not take into account the load on a given system when the address is resolved to start a session. Machines are assigned in sequence, almost guaranteeing that certain machines will be running flat-out while others have spare capacity. The better web server routers and redirectors can take into account the load of a given server before making the redirection assignment. Further, since the default language is Java, one WWW server can be a SUN SPARC and others INTEL- OSF object server code is totally portable to numerous hardware vendor platforms without recompilation of the server source code. And since this portable object server code is stateless, elements of a session can move from one hardware or operating architecture in the event of failure. Sessions can move and be load-balanced dynamically from hardware platform to another. Also, numerous third party WWW server allocation products work with PRO-OBJECT backend server support classes without enhancement or modification. (24) Out-of-Process v. In-Process HTTP Stream Processing A word on web server architecture and processing is in order. In-Process vs. Out-of-Process. With the ultra-thin architecture option, the HTTP Servlet server objects must reside on the same physical machine as the web server because the servlets run in-process with the web server, but in their own processing threads. In-process means that the servlets run in the same address space or process as the web server software itself (examples of web servers are the Microsoft Internet Information Server, Apache, the Sun Java Web Server, the Oracle WWW Service, among others). Running in-process is far, far more efficient than running out-of-process. Perl scripts, for example, run out-of-process to process form browser input. What this means is that, for each HTRP transmission from a browser, the web server must start a new operating system process, transfer the end-user input into the environment of this new process and then start an interpreter to process the environment and build the HTTP reply. This scheme is known as the Common Gateway Interface, or CGI. With servlets, the web server has to only start a thread and transfer the input stream via the stack. Further, if the servlet class is already loaded, multiple browser requests can concurrently processed in multiple threads. This scheme is usually two orders of magnitude faster than the CGI. In addition, lava interpreters are far more efficient than their perl equivalents and will get faster given the annual ten figure investments in lava technology by most large software'corporations. Further, Java is a pure object language where perl is flat and procedural, making a library of Java servlet classes significantly cheaper to maintain and far easier to reuse and adapt than a collection of perl scripts. (25) Thin Client and Enterprise Architectures Fault tolerance and load balancing is similar between thin client/enterprise architectures and the ultra-thin client described in the previous section, with one major exception: an additional tier of processing servers can optionally be deployed behind the web servers for faster processing and increased scalability. Ultra-thin, thin and enterprise architectures all use web servers. Thus pools of web servers can be used with either round-robin DNS or with redirection/balancing hardware and software. Thin clients execute Java applets in the web browser or use a web server to maintain Java applications on the client machine (these are referred to as Zero Administration Clients). The Java applications or applets contact an Object Request Broker to obtain an object reference to the server-side object. At this point an architecture decision can be made. One can configure the ORB to start object servers as needed on the web server. Alternately, an IIOP can relay the IIOP object reference request to another machine different from that of the front-end web server. These object servers then connect to the various backend database servers. The effect is to implement a layer of CORBA middleware object servers, thus implementing a three-tier processing architecture (four if one counts the web browser on the client). Enterprise solutions use HTTP pages and forms, lava applet and applications in combination to communicate with the server-side EJBeans as required by the business system application and end-user requirements. In the simplest of architectures, one can deploy session and entity EJBeans on the same machine as the web server(s). It is more customary to see EJBeans on a tier of systems between the web servers and the database servers. Further, clusters of EJBean application servers can be easily configured, as with the WEBLOGIC EJB server from BEA SYSTEMS. WEBLOGIC uses IP multicast so that one client/requester is in contact with all available servers in the cluster, an intelligent and efficient technique. In both multi-tier architectures, Enterprise and Ultra-thin/CORBA, stateless persistent, relational object servers built by ObjectServerFactory take advantage of the inherent fault tolerant capabilities with all multi-tier architectures. The technology that takes maximum advantage of the inherent dynamic load balancing capability of these architectures is the stateless design of all OSF-generated and built object servers. Thus an individual client request can be dynamically directed to the optimal web or middleware server available at a given instant in time. This is extremely advantageous as it permits a higher transaction throughput rate given a fixed quantity of backend server hardware. Summary We have discussed here that, through the use of unique processes and technical innovation, ObjectServerFactory and its resultant PRO-OBJECTS create a pure Object-Oriented execution environment which is significantly beyond the prior technical state-of-the-art. To summarize, these inventions are: Template-based, program language-independent and architecture independent software generation 1. Unique and innovative Relational <-> Object translation algorithms 2. Deferred Object Assembly 3. OSFORBStreams dramatically improve network performance and permit Database Inversion to build dynamic Pick Lists and to narrow edit rules 4. Stateless object server implementations The result of the above technologies is a set of object-oriented networked remote database access methods which uses generally accepted industry standard Internet-centric protocols and software engineering standards to extend persistent objects out from relational databases. OSF-created PRO-OBJECTS permit rich user interfaces to be built that would otherwise would be inefficient, even on the fastest of networks. The net result is an application system with superior aesthetics and performance than would otherwise be possible using commercially available distributed object technologies. SOFTWARE ORGANIZATION This section outlines in detail the software organization of ObjectServerFactory and the resultant PRO-OBJECTS built by OSF. Since OSF is a pure object-oriented application, the internal classes used to build the product will be explained and their relation to other classes defined. In this manner, anyone familiar with object-oriented programming techniques and the lava programming language will easily understand how OSF is built, facilitating its use and effectiveness while expediting future maintenance and enhancements by providing a foundation for further, more detailed understanding of ObjectServerFactory and PRO-OBJECT technology. Nomenclature OSF objects are based upon and extensively use objects provided by the Java programming language. To avoid any confusion, all public OSF objects are all prefixed with "OSF". Example: OSFBaseTable refers to the class which contains all attribute data and methods which massage the data associated with a standardized view of a table in a relational database from which persistent, relational objects are constructed. When Java classes are referenced, the entire Java package name will be used so that the reader at once knows that this is a lava language class. Example: rather than use the term hashtable, we will refer to a java.util.Hashtable to be absolutely clear. Internal Class Overview OSF classes and the resultant PRO-OBJECTS and the classes PRO-OBJECTS use fall into the following categories: 1. Database Normalization Objects OSF supports relational databases from numerous vendors. However, each vendor internally defines the database schema in different internal formats. OSF converts each database into a standard internal format for use by other OSF objects, such as the OSFGenerate code generation class. Each database OSF reads is converted internally into a standard set of Database Normalization Objects unique to OSF. 2. Object-Oriented User Interface: Through the OSF OOUI, the software developer selects the databases from which to build PRO-OBJECTS. Operation of the various windows, tree controls and selection elements of the OSF OOUI by the developer creates and modifies the underlying Data Normalization Objects, thus converting an external database into a standard internal format. 3. OSFGenerate and Template Code Skeletons, OSFGenerate is the class that generates the PRO-OBJECTS and their support classes. OSFGenerate reads in the Data Normalization Objects and the language-independent software template code skeletons to accomplish PRO-OBJECT codefile generation 4. OSFBase Object: PRO-OBJECTS are all derived from a set of base classes, all of which are derived from the OSFBaseObject master base class. Understanding of the organization of the runtime classes that PRO-OBJECTS extend is essential to the complete understanding of the software generated by OSF. 5. OSFORBStream is the helper class used with the underlying communications infrastructure to move persistent relational objects through a network, whether the network is CORBA over TCP/IP, BSD-style sockets or even serial lines. OSFORBStreams are sufficiently complex to deserve a separate discussion section and since they are used to move objects from the client-end PRO-OBJECTS to the backend server support classes, examples of their use are also enumerated. 6. Utility Objects are generic utility classes that are used throughout the aforementioned categories. Two examples of these utility classes are OSFSystemManagement and OSFDateTime. Database Normalization Objects OSF is designed to support relational, SQL-based databases from numerous database vendors. Naturally, each vendor internally defines database schemas in different internal formats (database schemas are the internal and proprietary structures used by the RDB itself to define business-specific and application database tables, relationships, constraints, stored procedures, security/access control and other functionality of the particular vendor's implementation of an SQL database). OSF converts each database into a standard internal format for use by subsequent OSF software components. To do so, OSF scans the tables which make up the database schema and then builds and modifies a set of OSF-specific Database Normalization Objects. Once all databases from multiple vendors are converted to OSF Database Normalization Objects, a unified view that appears as one database is produced. It is these normalization objects that are described in this section.Refer to FIG. 4. in the drawings for a class hierarchy diagram of the Normalization Object Topology. Refer to the source code on the CD-ROM filed herewith for further details regarding the processing logic in these database normalization classes. Object-Oriented User Interface Through ObjectServerFactory's OOUI, the software developer connects to the database schemas from which to build PRO-OBJECTS. Objects and Attributes are named appropriately for use in the generated software components through the use of expert object and attribute naming algorithms. Generation options present various alternatives for both code generation and various runtime options. Through the operation of these various windows, tree controls and selection elements of the OSF OOUI, the developer creates and modifies the underlying Data Normalization Objects enumerated in the previous section, thus converting external databases into a standard internal format. Refer to the section OSF Expert System Operation for a list of configuration options and screen snaps of the OSF OOUI. The entry point to OSF's OOUI is OSFMain.class. (26) Class Details of OSFMain Data Normalization Objects are instantiated by the various classes contained in OSFMain. These classes are as follows:
Major classes making up the OSF OOUI
ClientsTab.class GenRuntimeTab.class
ClientsTabPanel1.class GenRuntimeTabPanel1.class
ColumnNames.class GenServersTab.class
DataAccessPassword.class GenServersTabPanel1.class
DatabasesTab.class JournalsTab.class
DatabaseaTabPanel1.class JournalsTabPanel1.class
DBAdvancedConnectTab.class MessageBox.class
DBAdvancedConnectTabPanel1.class ModalQuestionBox.class
DBConnect.class ObjectsTab.class
DBConnectPanel1.class ObjectsTabPanel1.class
DBDriverTab.class PerformanceTab.class
DBDriverTabPanel1.class PerformanceTabPanel1.class
DBIconAndTextContent.class SecurityTab.class
DBLoginTab.class SecurityTabPanel1.class
DBLoginTabPanel1.class ServersTab.class
DBSelect.class ServersTabPanel1.class
DBSingleSelectedManager.class SystemManagement.class
EmptySecurityManager.class SystemManagementPanel1.class
GenClientsTab.class TableNames.class
GenClientsTabPanel1.class TreeControlEntry.class
GenerationOptions.class WordListLoadThread.class
GenerationOptionsPanel1.class
GenIDLTab.class
GenIDLTabPanel1.class
Please refer to the CD-ROM filed herewith for a detailed source code in the appendices which outlines detailed processing specifics. OSFGenerate and Template Code Skeletons OSFGenerate is the class that reads in the Data Normalization Objects and the language-independent software template code skeletons to generate the PRO-OBJECTS and their support classes. In addition to client-end and server-side persistent, relational object classes, OSF generates: OMG Interface Definition Language which exposes remote server methods to PRO-OBJECT based clients Build scripts for all generated code, including invocation of the IDL compiler and compiling IDL output A server registration script to register the CORBA server implementations with the Object Request Broker Master sedlanguage translation scripts to propagate translations to the various java.util.ListResourceBundle-derived objects HTML template files for data entry, inquiry and tabular display A Registry.java file containing all runtime parameters for a given installation, along with accessor classes and the object map Test programs for standalone testing of PRO-OBJECT component Other assorted utility and convenience scripts including a buildall script which builds everything in the proper sequence, interleaving builds into separate processes when possible (27)Standard IDL Interfaces, Synchronous and Asynchronous All CORBA distributed objects are derived from the BaseObject base IDL class, as outlined below. Note that this base class contains persistent relational distributed object accessors for reading objects, block object reads, object insertion, object update and object delete. Versions of these remote methods are supplied to the client PRO-OBJECT for both synchronous/blocking and asynchronous CORBA-based remote methods using familiar CORBA distributed callbacks. Asynchronous one-way persistent relational object methods use the ORBStreamReply callback object for all asynchronous remote object requests.
// NOTE: OSF object servers are stateless. . .
interface ORBStreamReply;
interface BaseObject
{
Core Persistent Object read operations:
/// basic Object I/O .backslash..backslash..backslash.
// operations which pertain to the entire object
OSFORBStream getObject(in string keylist)
raises (GeneralException);
oneway void getObjectAsync(in ORBStreamReply returnstream,
in string keylist, in long /* (ORBStreamEvent) */ event);
OSFORBStream getObjectBlock(in string keylist, in long count)
raises(GeneralException, MultiDBSynchronisationException);
oneway void getObjectBlockAsync(in ORBStreamReply
returnstream,
in string keylist, in long count, in long /* (ORBStreamEvent) */
event);
Core Persistent Object creation operations:
oneway void newObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBStreamEvent) */
event);
void newObject(in OSFORBStream orbstream)
raises (GeneralException, MultiDBSynchronisationException);
Core Persistent Object removal operations:
oneway void deleteObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBStreamEvent) */
event);
void deleteObject(in OSFORBStream orbstream)
raises (GeneralException, MultiDBSynchronisationException);
Core Persistent Object modification operations:
void updateObject(in OSFORBStream orbstream)
raises(GeneralException, MultiDBSynchronisationException);
oneway void updateObjectAsync(in ORBStreamReply returnstream,
in OSFORBStream orbstream, in long /* (ORBStreamEvent) */
event);
Core Persistent Object support methods:
void setKeyFields(in string keyfields)
raises (GeneralException);
boolean pingObject( )
raises (GeneralException);
};
// ORB Stream server-> client generalised callback operation
interface ORBStreamReply
{
// exceptiondetail is null if OSFORBStream and ORBStreamEvent
is valid
oneway void returnORBStream(in OSFORBStream stream,
in long /* ORBStreamEvent */ event, in string exceptiondetail);
};
OSFORBStream client--server intercommunication is performed in this manner. (28) PRO-OBJECT--Server Initialization Synchronization The pingObject( ) remote server method defined in the IDL exc | ||||||