The invention is related generally to data processing apparatus and corresponding methods for the retrieval of data stored in a database, and more particularly to the remote retrieval of data stored in multiple databases through a persistent data object.
In recent years, traditional two-tier client/server systems have been displaced slowly by more sophisticated multi-tier client/server systems. In general, a multi-tier system places at least one intermediate component between the client and the server. These components are referred to commonly as “middleware.” Generalized “n-tier” systems include n layers of software that provide a different layer of services at varying levels of detail to the layers above and beneath them, where n is any number. See Mark Johnson, A beginner's guide to Enterprise JavaBeans, JavaWorld, at http://www.javaworld.com (October 1998), incorporated herein by reference. Programmers often use multiple client/server tiers in enterprise software applications to separate and delegate the programming tasks. In particular, one tier usually includes objects that implement the business operations while one or more other tiers provide objects that implement the underlying data processing (such as creating a data structure to represent the cart or saving the consumer's order to a database).
“Object-oriented” languages and techniques also have become increasingly popular in recent years. In general, an “object” is a named memory unit that contains data and instructions for manipulating that data. In an object-oriented context, the terms “attribute” and “property” are often synonymous and generally refer to the data within the memory unit, and the term “method” or “procedure” refers to the related instructions for manipulating the data. In practice, objects often include methods that direct the process of storing the object's attributes within a file or database. Of course, an object that includes such a method also generally includes one or more methods that direct other types of operations, such as retrieving, updating, or removing attributes from the file or database.
Today, computer programmers frequently implement enterprise applications with a mix of n-tiered architectures and object-oriented technology. Sun Microsystems, Inc. (SUN) has developed a comprehensive collection of objects and other supporting programs that programmers can use to build sophisticated enterprise applications. SUN currently markets this collection as the JAVA 2 ENTERPRISE EDITION (J2EE) platform. SUN also has developed an application program interface (API) for J2EE that defines an n-tiered architecture, which SUN currently markets as the ENTERPRISE JAVABEANS (EJB) architecture.
An “entity bean” is one type of EJB component used to model data in enterprise applications, the attributes of which are typically persisted within a database. The term “persist” generally refers to the process of storing, updating, and deleting such attributes to or from a database. An entity bean may manage the persistence of its attributes (commonly known as “bean managed persistence” or “BMP”), or it may delegate the responsibility to the EJB container in which it executes (commonly known as “container managed persistence” or “CMP”). CMP often is favored by programmers since many routine persistence tasks are handled by the EJB container and relieves the programmer from writing persistence code. BMP provides greater flexibility, but at the expense of increased burden on the programmer.
Currently, EJB CMP beans can connect to one data source only. Many enterprise applications, though, need to access data stored in multiple databases or partitions within a database. For example, many enterprises have multiple office locations, and each office location has a separate database. Alternatively, some enterprise applications need to access multiple databases for reporting and statistical analyses.
Consequently, a conventional J2EE application requires a separate CMP bean to be deployed for each database accessed by the application. Clearly, this requirement necessitates additional installation time, storage, maintenance, and memory. One known solution to connecting a single CMP bean to multiple data sources is described in U.S. Pat. No. 6,901,409. The '409 patent discloses using a “proxy” database which connects to other data sources. The proxy database must be able to integrate the data from every database, so that it appears as a single virtual database. This solution requires sophisticated software that is compatible with each database to be accessed. Essentially, the method of the '409 patent still only connects the CMP bean to a single data source, the proxy database. Additional software performs queries to the other data sources.
A need exists for a method for connecting an application directly to multiple data sources using from single EJB CMP bean.
The EJB multiple data source connector meets the need identified above. The EJB multiple data source connector is a computer implemented process for connecting an EJB CMP bean to multiple data sources, the computer implemented process comprising the following steps. The EJB multiple data source connector receives a data query and connects to a data source. The EJB multiple data source connector issues the query to the connected data source. After receiving a response as and EJB object from the connected data source, the EJB multiple data source connector binds the EJB object to the data source. The EJB multiple data source connector repeats the steps of connecting to a data source, issuing a query, receiving a response as an EJB object and binding the EJB object to the data source. The EJB multiple data source connector then returns the results to the query initiator.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will be understood best by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The principles of the present invention are applicable to a variety of computer hardware and software configurations. The term “computer hardware” or “hardware,” as used herein, refers to any machine or apparatus that is capable of accepting, performing logic operations on, storing, or displaying data, and includes without limitation processors and memory; the term “computer software” or “software,” refers to any set of instructions operable to cause computer hardware to perform an operation. A “computer,” as that term is used herein, includes without limitation any useful combination of hardware and software, and a “computer program” or “program” includes without limitation any software operable to cause computer hardware to accept, perform logic operations on, store, or display data. A computer program may, and often is, comprised of a plurality of smaller programming units, including without limitation subroutines, modules, functions, methods, and procedures. Thus, the functions of the present invention may be distributed among a plurality of computers and computer programs. The invention is described best, though, as a single computer program that configures and enables one or more general-purpose computers to implement the novel aspects of the invention. For illustrative purposes, the inventive computer program will be referred to as the “EJB Multiple Data Source Connector”.
Additionally, the “EJB Multiple Data Source Connector” is described below with reference to an exemplary network of hardware devices, as depicted in
EJB Multiple Data Source Connector 300 typically is stored in a memory, represented schematically as memory 320 in
J2EE application 330 is an application running in Memory 320 that requires information stored in multiple data sources. Default Data Source List 340 contains the JNDI identifier for each available data source. Data Source List 340 can be used by either J2EE Application 330 or EJB Multiple Data Source Connector 300 to locate information. Intent Definition 350 contains a query for information from J2EE Application 330 and the target data sources containing the desired information. Objects (EJBS) 360 are ENTERPRISE JAVABEANS which are named memory units that contain data and instructions for manipulating that data using a J2EE platform.
EJB Multiple Data Source Connector 300 operates in three different scenarios, each scenario are described here as components: Find Component 400, Create Component 500 and Update Component 500. Find Component 400 intercepts queries from J2EE application 330, and sends the query to each target data source in succession via the same EJB CMP bean, then returns all the responses from each data source at once to J2EE Application 330. Create Component 500 associates (binds) Objects (EJBS) 360 to various data sources. Update Component 600 updates or removes bindings between Objects (EJBS) 360 and various data sources.
By using the JNDI name to bind the EJB object to the data source, the association becomes independent of database schema or vendor. Thus, EJB Multiple Data Source Connector 300 allows J2EE Application 330 to perform in a single query what would have required multiple queries under the prior art Further, a single EJB object can be associated to multiple data sources by Find Component 400, with one data source being the default binding. This overcomes the limitation from the prior art that an EJB object can only have bindings to a single data source.
A preferred form of the invention has been shown in the drawings and described above, but variations in the preferred form will be apparent to those skilled in the art. The preceding description is for illustration purposes only, and the invention should not be construed as limited to the specific form shown and described. The scope of the invention should be limited only by the language of the following claims.