Patent Application
20060004855
Embodiments of the invention generally relate to the field of data processing and, more particularly, to a system and method for interacting with a persistence layer.
Many businesses are providing access to their products and services through applications that are delivered over computer networks such as the Internet. These applications typically have a multi-tiered architecture. In those cases where the applications are delivered over the Internet they are commonly referred to as Web-based applications.
Web-based application 100 includes client layer 110, application layer 120, and database layer 130. Client layer 110 includes user interface 112 that runs on a client computing device such as a desktop computer, laptop computer, personal digital assistant, telephone, and the like. In a Web-based environment, user interface 112 is typically a Web browser. User interface 112 may collect input from a user and provide that input to application layer 120 for processing.
Application layer 120 includes application server 122 to receive and process input from client layer 110. Application server 122 typically includes a number of subcomponents including, for example, connectivity layer 140, presentation logic 142, business logic 144, and database interface 146. Connectivity layer 140 provides connections to client layer 110 using protocols such as the HyperText Transfer Protocol (HTTP), HTTP secured through the Secure Socket Layer, the Simple Object Access Protocol (SOAP), and the like. Presentation logic 142 generates a Graphical User Interface (GUI) using, for example, a markup language such as the Hyper Text Markup Language (HTML). Business logic 144 represents the core of the application, for example, the rules governing the underlying business process (or other functionality) provided by the application. Database interface layer 146 provides an interface to database layer 130. The Java 2 Enterprise Edition Specification v1.3, published on Jul. 27, 2001 (the J2EE Standard) defines an increasingly popular architecture for application layer 120.
Database layer 130 includes data access logic used by business logic 144 to store and retrieve data in database 132. Database 132 provides non-volatile storage (sometimes referred to as a persistent store) for the data accessed and/or processed by application layer 120. Database 132 may be, for example, a relational database or an object-oriented database.
In some cases, business logic 144 may be implemented with Enterprise Java Beans (EJBs). EJBs are server-side J2EE components that provide business logic and represent persistent data. Although EJBs provide a flexible architecture for business logic 144, they also introduce a certain amount of complexity.
Conventional mapping architecture 230 attempts to map the object-oriented domain of business logic 210 to the relational domain of database 220. Conventional mapping architecture 230 is typically only able to process a limited set of the queries that are generated by business logic 210. In addition, conventional mapping architecture 230 is typically constrained to interoperating with a database provided by a particular vendor. Conventional mapping architecture 230 typically lacks the capacity to perform a variety of validity and compatibility checks on the metadata and schemas defining various aspects of the architecture.
A system and method are provided for interacting with a persistence layer. In an embodiment, a persistence layer may receive a representation of Enterprise Java Bean (EJB) metadata. The persistence layer may determine whether the representation of Enterprise Java Bean (EJB) metadata is compatible with a version of the EJB specification. In an embodiment, a representation of an Object-Relational (OR) mapping schema may be generated based, at least in part, on the representation of EJB metadata.
Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
A system and method are provided for interacting with a persistence layer. In an embodiment, a persistence layer may receive a representation of Enterprise Java Bean (EJB) metadata. The persistence layer may determine whether the representation of Enterprise Java Bean (EJB) metadata is compatible with a version of the EJB specification. In an embodiment, a representation of an Object-Relational (OR) mapping schema may be generated based, at least in part, on the representation of EJB metadata.
Application server 320 receives information from client 310 and may generate a response after processing the information. In an embodiment, application server 320 is based, at least in part, on the J2EE standard (e.g., IBM's Websphere platform). In an alternative embodiment, application server 320 may be based on a different platform such as Microsoft Corporation's .Net platform. The illustrated embodiment of application server 320 includes EJB container 340, mapping architecture 350, and database 360. In an alternative embodiment, application server 320 may include more elements, fewer elements, and/or different elements.
EJB container 340 is the environment in which EJBs reside. EJB container 340 enables multiple EJBs to be deployed to application server 320 and makes them accessible through a naming service such as the Java Naming and Directory Interface (JNDI). EJB container 340 provides deployed beans with services such as persistence, transaction handling, pooling, security, exception handling, and the like. At runtime, EJB container 340 creates instances of the bean class (e.g., bean class instance 342) and manages the lifecycle of the instances of the bean class.
An EJB typically has four basic elements: instance of the bean class 342, object interface 344, home interface 346, and deployment descriptor 348. Bean class 342 implements business methods that may be declared in, for example, object interface 344. Home interface 346 may define one or more methods used by client 310 to find and/or remove bean class 342. Deployment descriptor 348 may be an eXtensible Markup Language (XML) file containing metadata that, for example, describes an EJB's structure and its relationships to other EJBs. An entity EJB is an EJB that represents specific data or collections of data such as a row in a relational database (e.g., database 360).
In an embodiment, mapping architecture 350 receives persistency requests from EJB container 340 and generates Structured Query Language (SQL) statements based, at least in part, on the received persistency requests. EJB container 340 may use the generated SQL statements to, for example, implement Container Managed Persistence (CMP). In one embodiment, mapping architecture 350 is an element of persistency layer 352. In an embodiment, persistency layer 352 provides an interface between an application layer and a database layer. Persistency layer 352 may include, for example, a Java Database Connectivity (JDBC) API, various buffers, communications protocols, and the like that facilitate the interaction between EJB container 340 and database 360.
In an embodiment, the persistency requests received by mapping architecture 350 may be grouped into two categories: user-defined EJB Query Language (EJBQL) persistency requests and EJB container persistency requests. In an embodiment, user-defined EJBQL persistency requests may be based, at least in part, on ejbSelect( ) methods and ejbFinder( ) methods. Similarly, in an embodiment, EJB container persistency requests may be based, at least in part, on ejbLoad( ) methods, ejbStore( ) methods, and/or ejbRemove( ) methods as well as methods for manipulating and maintaining Container Managed Relationships (CMRs). Mapping architecture 350 is further described below with reference to
In an embodiment, mapping architecture 400 is assigned an Object/Relational (OR) mapping schema 410 to determine the mapping between, for example, entity EJBs, database tables (e.g., the tables of database 360, shown in
In an embodiment a catalog reader may validate the data in OR mapping schema 410 against an underlying database (e.g., database 360, shown in
In an embodiment, SQL mapper implementation 430 provides a number of interfaces and classes to implement the core functionality of mapping architecture 400. For example, in an embodiment, SQL mapper implementation 430 provides SQL mapper interface 440 to receive persistence requests from an EJB container (e.g., EJB container 340, shown in
In an embodiment, SQL mapper implementation 430 employs a two-layer set of classes to process persistence requests that it receives from SQL mapper interface 440. For example, the illustrated embodiment of SQL mapper implementation 430 includes EJB interpreting layer 432 and SQL assembly layer 438. In one embodiment, the purpose of EJB interpreting layer 432 is to interpret received EJB persistence requests and to send a sequence of commands (e.g., method calls) to the SQL assembly layer 438. In an embodiment, the purpose of SQL assembly layer 438 is to assemble SQL statements based, at least in part, on the sequence of commands received from EJB interpreting layer 432.
In an embodiment, EJB interpreting layer 432 is divided into two sections: EJBQL persistence request processor 434 (or, for ease of discussion, EJBQL processor 434) and EJB container persistence request processor 436 (or, for ease of discussion, EJB container processor 436). In such an embodiment, the purpose of EJBQL processor 434 is to interpret EJBQL persistence requests and to send a sequence of commands to SQL assembly layer 438 based, at least in part, on the persistence requests. Similarly, the purpose of EJB container processor 436 may be to interpret EJB container persistence requests and send a sequence of commands to SQL assembly layer 438 based, at least in part, on the persistence requests. SQL mapper implementation 430 is further discussed below with reference to
In an embodiment, the output of SQL mapper implementation 430 is described by SQL mapping result implementation 450. In one embodiment, the SQL statement(s) provided by SQL mapping result implementation 450 are organized as a tree structure in which each element of the SQL statement is represented by a node of the tree structure. Organizing the information in a tree structure enhances the processing of persistence requests by providing a more efficient, more complete, and reusable presentation of data related to a persistence request (e.g., data source, type of statement, conditional clauses, etc.). An example of an SQL statement organized as a tree structure is shown below with reference to
In one embodiment, the SQL statement(s) provided by SQL mapping result implementation 450 are database-independent. The term “database-independent” refers to, for example, an SQL statement that is portable across a number of databases provided by a number of different vendors. In such an embodiment, SQL mapper implementation 430 may map a received persistence request to an SQL statement that is known to be database-independent. For example, in an embodiment, a set of SQL statements may be chosen that are a subset of standard SQL-92 statements, for example, a subset of statements that comply with the American National Standards Institute/International Organization or Standardization (ANSI/ISO) 9075: 1992 Information Technology—Database Languages—SQL standard (hereinafter, the SQL-92 Standard). The subset of standard SQL-92 statements may be selected, at least in part, based on whether they are database-independent. In one embodiment, the subset of standard SQL-92 statements is supplemented with additional SQL statements that are known to be database-independent.
In an embodiment, SQL mapping result implementation 450 implements mapping result interface 460 to provide the SQL mapping result to an EJB container (e.g., container 340, shown in
In an embodiment, SQL mapping result implementation 450 may derive database-specific SQL statements for given database vendors from its internal database-independent SQL statement representation. For example, one or more methods may be provided that allow an end-user (or program) to specify a specific database (e.g., via a database product name and/or a database vendor identifier). In an embodiment, the one or more methods may be used by SQL mapping result implementation 450 to derive an SQL statement string representation of the SQL statement that is specific to the identified database.
In an embodiment, EJB interpreting layer 510 includes EJBQL processor 530 to interpret EJBQL persistence requests. In one embodiment, the received EJBQL persistence requests are organized as tree structures in which each element of the persistence request is represented by a node of the tree structure. In such an embodiment, EJBQL processor 530 traverses the tree structure representing the EJBQL persistence request and transforms the information it encounters into appropriate method calls to underlying SQL assembly layer 520. In an embodiment, SQL assembly layer 520 assembles an SQL statement in a step-wise fashion as it receives the method calls from EJBQL processor 530. In such an embodiment, once EJBQL processor 530 has completely traversed the tree structure representing the persistence request, SQL assembly layer 520 has completely assembled, for example, an SQL statement representing the original EJBQL persistence request.
In an embodiment, EJBQL processor 530 employs a number of classes to interpret the received persistence request. For example, the illustrated embodiment includes ConditionProcessor class 532, SimpleConditionProcessor class 534, ArithmeticExpressionProcessor class 536, and StringExpressionProcessor class 538. In an embodiment, ConditionProcessor class 532 interprets combined conditions of a WHERE clause within the received persistence request. Similarly, SimpleConditionProcessor class 534 may interpret elementary conditions (as well as simple arithmetic and Boolean conditions) of the WHERE clause. In an embodiment, ArithmeticExpressionProcessor class 536 may be used to interpret more complex arithmetic expressions. In an embodiment, StringExpressionProcessor class 538 may be used to interpret one or more of the string expressions in a persistence request. SQL mapper implementation is easy-to-extend because, for example, new classes may be added to one or more of its layers to extend the functionality of the layer.
In an embodiment, EJB interpreting layer 510 includes EJB container processor 540 to process persistence requests from an EJB container (e.g., EJB container 340, shown in
SQL assembly layer 520 assembles SQL statements based, at least in part, on the commands (e.g., method calls) that it receives from EJB interpreting layer 510. In an embodiment, SQL assembly layer 520 provides a tree representation of the assembled SQL statement. In an embodiment, SQL assembly layer 520 employs one or more classes to assemble an SQL statement. For example, WhereNodeManager class 522 may generate a subtree of logic predicates representing an SQL statement's WHERE clause. In an embodiment, ExpressionNodeManager class 524 compiles the expressions used within those predicates.
Certain versions of the Java Database Connectivity (JDBC) Application Program Interface (API) may not support Boolean expressions (e.g., versions earlier than JDBC ver. 3.0). BooleanNodeManager class 526 may provide mappings to alternative expressions when mapping to Boolean expressions is not supported by the JDBC API. For example, if a WHERE predicate's right operand expression is to inherit type mapping from its corresponding left operand expression, BooleanNodeManager class 526 may support the type mapping. In an embodiment, Boolean literal values may be appropriately transformed in accordance with a prevailing type mapping. In such an embodiment, LiteralValueMapper class 528 may provide the appropriate transformation. Some constructs of a persistence request may involve the use of subqueries within an SQL statement. In an embodiment, SubqueryBuilder class 529 generates subqueries, as needed, for the SQL statement.
SELECT a.phone FROM AddressBean AS a WHERE a.lastName=?1 AND a.firstName=?2
In an embodiment, an EJBQL parser (not shown) parses, for example, the persistence request shown in Listing 1 and generates a tree structure representation of the persistence request as shown by EJBQL tree structure 630. In an embodiment, each node of EJBQL tree structure 630 represents an element of the persistence request shown in Listing 1. For example, EJBQL node 632 may represent the EJBQL persistence request generally while from node 634 and where node 636 represent the FROM clause and WHERE clause of the EJBQL persistence request. In an embodiment, relationships between EJBs may be also be represented by EJBQL tree structure 630. For example, a.phone node 639 may represent a relationship between address bean 620 and another EJB (not shown).
In an embodiment, SQL mapper implementation 640 receives an EJBQL persistence request such as, for example, EJBQL tree structure 630. SQL mapper implementation 640 may include EJBQL processor 642, EJB container processor 644, and SQL assembler 646. Since EJBQL tree structure 630 represents a user-defined EJBQL statement, in an embodiment, it may be interpreted by EJBQL processor 642. In an embodiment, EJBQL processor 642 traverses EJBQL tree structure 630 (e.g., with the help of classes such as 532-538, shown in
In an embodiment, SQL assembler 646 generates SQL tree structure 610 in a step-wise fashion as it receives the command sequence from EJBQL processor 642. For example, as EJBQL processor 642 traverses select node 638 and where node 636, SQL assembler 646 may generate select node 611 and p.ID node 613 (representing the primary key of the other EJB (not shown) to which the relation phone of EJB AddressBean 620 is pointing) as well as where node 612 and AND node 615 and an equal join condition node 614 to realize the relation phone of EJB AddressBean 620. In an embodiment, SQL assembler 646 generates node elements for SQL tree structure 610 that are database-independent (e.g., elements selected from a subset of SQL-92 that are database-independent). In an alternative embodiment, an embodiment, SQL assembler 646 may generate platform-independent and/or platform dependent SQL statements.
The interaction between an EJB container (e.g., EJB container 340, shown in
In the illustrated embodiment, SQL mapper implementation 710 maps EJBQL persistence requests to appropriate SQL statements. SQL mapper implementation 710 may receive EJBQL tree representation 715 and return SQL mapping result 720 to the EJB container. In an embodiment, SQL mapping result 720 describes the generated SQL statement and may also describe the input variables used and the result set created by the SQL statement. In an embodiment, SQL mapper implementation 710 attempts to generate SQL statements that comply with a specified SQL grammar (e.g., an SQL grammar that defines a database-independent SQL statement). If SQL mapper implementation 710 cannot generate an SQL statement that complies with a specified SQL grammar, then it may inform the EJB container via, for example, SQL mapping result 720 that the generated SQL statement is to be considered native. In one embodiment, both EJB 2.0 and EJB 2.1 are supported indistinctively.
In an embodiment, the EJB container employs catalog reader 805 (shown in
Referring again to
In an embodiment, a compatibility check is performed on EJB descriptors 725 to determine whether they are compatible with a specified version of the EJB specification (e.g., EJB 2.0 or EJB 2.1). In an embodiment, one or more elements of EJB descriptors 725 may indicate which version of the EJB specification was used to create the EJBs. A compatibility check may include referencing these elements to determine whether they are the same as the specified version of the EJB specification (e.g., EJB 2.0). In an embodiment, EJB descriptors provide the basis for OR mapping descriptors 745. OR mapping descriptors 745 may be, for example, an implementation of an OR mapping schema.
In an embodiment, EJBQL parser 705 is created to parse EJBQL persistence requests of the find/select methods that are specified in the abstract schema defined by EJB descriptors 725. In one embodiment, each find/select method is described in a FinderDescriptor element that is part of EJB descriptors 725. EJBQL parser 705 may be “prepared” for parsing an EJBQL persistence request by accessing the FinderDescriptor element of the corresponding find/select method. In an embodiment, invocation of a method such as getParseTree( ) on the prepared EJBQL parser 705 creates tree representation 715 of the EJBQL persistence request. In an embodiment, SQL mapper implementation 710 further maps tree representation 715 to an appropriate SQL statement (also represented in the form of a tree).
In an embodiment, SQL mapper implementation 710 provides SQL mapping result 720 in response to a method invocation such as SQLMapper.mapEjbQl( ). The method SQLMapper.mapEjbQl( ) may take as a parameter tree representation 715. In an embodiment, statement generator 750 maps EJB container persistence requests to SQL statements. Persistent classes 755 may include SQL mapping result(s) 720 and the statements generated by statement generator 750. In an embodiment, persistent classes 755 facilitate interaction between an EJB container and a database.
The application may be started on each of the server nodes and persistent classes 755 (shown in
In an embodiment, OR mapping verifier 815 uses catalog reader 805 to verify whether one or more OR mapping requirements have been fulfilled. The term “OR mapping requirements” may refer to a correspondence between an OR mapping schema and a database schema as well as compliance with one or more OR mapping rules. The process of verifying the “correspondence” between the schemas may include accessing catalog reader 805 to evaluate database tables that have been defined and deployed (e.g., via a data dictionary). The term “OR mapping rules” refers, for example, to restrictions that define allowable mappings and allowable data types. OR mapping rules may (but are not required) to include some or all of the following rules: restricting the mapping of each EJB to a separate database table; mapping particular CMP fields to individual columns; matching particular Java types to certain JDBC types; defining the use of foreign key columns for Container Managed Relations (CMR); and the like. In an embodiment, the application startup may fail if some or all of the OR mapping requirements have not been fulfilled. The startup phase may finish successfully if the OR mapping requirements have been fulfilled.
In an embodiment, OR mapping descriptors 745 are implemented based, at least in part, on the information provided by IDE descriptors 905. OR mapping verifier 815 may perform some or all of the OR mapping verification, discussed above with reference to
In an embodiment, if the EJB specification compatibility check, OR mapping verification, and/or SQL grammar verification are performed during design-time then they may be skipped during deploy-time and startup time. In an alternative embodiment, one or more of the compatibility checks and verification processes may be performed at deploy-time and/or startup time. In one embodiment, the various compatibility checks and verification processes are selectively performed at deploy-time and/or startup time based on the settings of one or more switches (not shown).
In the illustrated embodiment, SQL mapper implementation 1005 maps both EJBQL persistence requests and EJB container persistence requests to appropriate SQL statements. For example, SQL mapper implementation 1005 may return SQL mapping result 1010 in response to an EJB container persistence request and may return SQL mapping result 720 in response to an EJBQL persistence request. In an embodiment, persistent classes 1055 are persistent classes that are generated during deploy-time such as SQL mapping results 1010 and 720.
Some applications (and the EJBs that, in part, implement these applications) are only compatible with a specified SQL grammar (e.g., a native SQL grammar provided by a vendor). In contrast, certain datasources (e.g., databases) are designed to be used with a database-independent SQL grammar. In an embodiment, if an application (or its EJB) is marked as requiring a specific SQL grammar, then SQL grammar checker 1115 may determine whether the associated datasource requires a different SQL grammar (e.g., a database-independent SQL grammar). In an embodiment, application startup may fail if an application and an associated datasource require different SQL grammars.
Turning now to
Referring to process block 1350, the representation of the OR mapping schema (e.g., OR mapping descriptors 745, shown in
Query language mapping logic 1650 may facilitate one or more validity/compatibility checks of one or more elements of a query language mapping architecture. Query language mapping logic 1650 may be executable content, control logic (e.g., ASIC, PLD, FPGA, etc.), firmware, or some combination thereof, in an embodiment of the invention. In embodiments of the invention in which query language mapping logic 1650 is executable content, it may be stored in memory 1620 and executed by processor(s) 1610.
Memory 1620 may encompass a wide variety of memory devices including read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), non-volatile random access memory (NVRAM), cache memory, flash memory, and other memory devices. Memory 1620 may also include one or more hard disks, floppy disks, ZIP disks, compact disks (e.g., CD-ROM), digital versatile/video disks (DVD), magnetic random access memory (MRAM) devices, and other system-readable media that store instructions and/or data. Memory 1620 may store program modules such as routines, programs, objects, images, data structures, program data, and other program modules that perform particular tasks or implement particular abstract data types that facilitate system use.
One or more I/O devices 1630 may include a hard disk drive interface, a magnetic disk drive interface, an optical drive interface, a parallel port, serial controller or super I/O controller, serial port, universal serial bus (USB) port, a display device interface (e.g., video adapter), a network interface card (NIC), a sound card, modem, and the like. System interconnection 1660 permits communication between the various elements of node 1600. System interconnection 1660 may include a wide variety of signal lines including one or more of a memory bus, peripheral bus, local bus, host bus, bridge, optical, electrical, acoustical, and other propagated signal lines.
Elements of embodiments of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of machine-readable media suitable for storing electronic instructions. For example, embodiments of the invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
Similarly, it should be appreciated that in the foregoing description of embodiment of the invention, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed subject matter requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.
