1 Introduction
Many developers and users are looking for a convenient way to access the database in the Java program. Since Java is a robust, safe, easy-to-use, easy to understand and can automatically Download Download from the network, so it becomes a good language base for developing database applications. It provides many advantages of C, C, SmallTalk, Basic, Cobol, and 4GLS. Many companies have begun to work in Java and DBMS.
Many Java application developers want to write procedures independent of a specific DBMS, and we also believe that an interface independent of DBMS will make it the most convenient to connect with a variety of DBMS connectivity. So we think that a universal SQL data inventory is taken, providing a unified interface on a wide variety of database connection modules, is very meaningful. This allows the programmer to face a single database interface, making the database unrelated Java tools and products that make the developers of database connections can provide a wide variety of connection scenarios. We see the pressing tasks of the Java Database Connectivity (JDBC) API that supports the basic SQL feature.
Fortunately, we don't have to design a SQL API from your head. We can build our work over the X / Open SQL CLI (which is also the basis of Microsoft's ODBC).
Our main task is to define a natural Java interface to connect to the basic abstraction and concepts defined in the X / Open CLI.
JDBC API is very important to get database development vendors, connection development vendors, ISV, and application developers' support. We believe that our work is based on the ODBC abstraction layer, and it is easier to get JDBC more easily accepted. And from the technical point of view, ODBC is a good foundation for our design work.
Because the ODBC is a C language interface, ODBC is inadvertently used in Java. Calling C code from Java has many inconveniences in terms of security, robustness, implementation, and portability. It makes the Java's many advantages in these areas.
We have implemented a API built on ODBC in the short term. In the long run, we can provide implementation in other ways.
1.1. Note / r
We are very grateful to many early workers in the database, database connection and database tools. They provide good comments and suggestions for the early drafts of JDBC. Their jobs have an inconspicuous role in this standard.
2. Target and philosophy
This section describes the goals and philosophy of guiding this API development.
2.1. SQL level API
Our main goal is to define a "call-level" SQL interface for Java. It means that our main attention is concentrated in the original SQL statement and retrieve the results. We expect high-level APIs to be defined, which may be built on the base layer interface. These high-level interfaces include the image directly, transparently, into the table in the Java class, with a syntax tree indicating a more common query, and the SQL syntax embedded in Java.
We hope that a lot of application development tools will use our API. However, we also hope that the programmer can use our API, especially in the case where there is no other means in Java (it should be a database access means).
2.2. Follow SQL
The database system supports a wide variety of SQL syntax and semantics, which are inconsistent with each other, such as external connections such as external connections, embedded processes, etc., although we can look forward to the SQL of these parts of these parts can be standardized . At the same time, we take this attitude and position:
In fact, an application query need not even be SQL, or it may be a specialized derivative of SQL, eg for document or image queries, designed for specific DBMSs.In order to pass JDBC compliance tests and to be called "JDBC COMPLIANT?" we require that a driver support at least ANSI SQL-2 Entry Level. This gives applications that want wide portability a guaranteed least common denominator. We believe ANSI SQL-2 Entry Level is reasonably powerful and is reasonably widely supported today.JDBC allow the query expression Directly passed to the underlying data driver, such a program can get as much SQL function, but may be rejected by DBMS. In fact, the query of a program can even not be SQL, or a special evolution of SQL, for example: text or graphic query designed for a dedicated database.
In order to be tested through JDBC, and we can be called JDBC compatibility, we require a standard that drives at least ANSI SQL-2. This makes those programs that need to be widely granted to get a minimum denominator (this sentence is:
This Gives Applications That Want Wide Portability A Guaranteed Least Common Denominator.).
We believe that ANSI SQL-2 is so powerful and is supported.
2.3. JDBC must be built on existing database interfaces
We must ensure that the JDBC SQL API can be built on a normal SQL API, especially ODBC. These requirements have had an impact on some parts of this specification, especially for the processing of out parameters and large data blocks.
2.4. Must ensure that this interface is consistent with the other parts of the Java system
At present, the positive response to Java is very warm. To a large extent, this language standard and standard runtime library are considered consistent, simple and powerful. We will do our best, provide this Java database interface, which will be built in the Java kernel existing style and will further strengthen it.
2.5. Maintain simple
WE Would PREFER TO Keep This Base API As Simple As Possible, AT Least
initially. In general we would prefer to provide a single mechanism for performing a particular task, and avoid provid-ing duplicate mechanisms. We will extend the API later if any important functionality is miss-ing.
We will strive to make the basic API as simple as possible, at least it is like this. In general, we want to provide only a solution to each particular task, avoiding a variety of programs. If some important features are missing, then we will expand this API later.
2.6. Try to maintain strong, static types
We hope that this JDBC API keeps the tonable type check, so that as many types of information as possible can be static. Make as many errors as possible can be discovered when compiling.
Since SQL itself is dynamic type, we may encounter a problem that the type cannot match when the program is running. For example: When a programmer returns an integer in wishing SELECT, it is a string "foo". But we still hope that the programmer can express it when it is compiled, so we can do Static check as much as possible. We also hope to support dynamic type interfaces when necessary (see Chapter 4)
2.7. Simplification of ordinary tasks
We hope that ordinary tasks can be simple, and no general work is feasible.
A common task refers to a programmer to perform a simple SQL statement (for example: select, insert, update, delete), and then (for example, select) processing returned with a simple type of tuple. A SQL statement with incoming parameters is also ordinary. Not so ordinary but it is also very important, is the SQL statement that is used by the programmer with the inout, OUT parameters. we
It also needs to be supported by the SQL statement to read a few megabytes objects, more special cases include a statement that returns a plurality of result sets.
We hope that the use of metadata is very small, just those skilled programmers and development tools need to be handled. The metadata access function and the dynamic type data access function are at the end of this document, and the general programmers can do not have to care about these sections.
2.8. Different functions make different methods (functions) to achieve
("Method" is: Method, this translation is to use VB) An interface design style is a very few process, providing many control signs as parameters transfer, so they can be used to affect a large range Various behaviors. To express different features. This tends to use a lot of methods, but each method agrees to understand.
In general, Java kernels use different methods (Method). The main advantage of this step is that the programmer that starts learning the basic interface can not have to be troublesome with the parameters associated with complex functions. We try to use the same strategy on the JDBC interface. Generally, different methods rather than adopting different markers and multi-purpose methods.
3. Interface profile
The interface is divided into two levels, one is a JDBC API for programmed developers. The other is the underlying JDBC Driver API.
3.1. JDBC API
The JDBC API is described as an abstract Java interface that is an export of the Yi nationality. It can open a connection to a database, execute the SQL statement and process the results. Error! Embedded object is invalid.
The most important interface is:
Java.sql.driverManager Processes the driven transfer and supports the generated database connection.
Java.sql.Connection represents the connection to a specific database.
Java.sql.Statement represents a specific container to perform SQL statements for a specific database.
Java.sql.ResultSet controls access to row data for a particular statement. There are two subtypes in java.sql.statement:
1. Java.sql.preparedStatement is used to perform a pre-compiled SQL statement.
2. Java.sql.callableStatement is used to perform calls to the embedded process in a database.
The following sections provide more descriptions for how JDBC runs, see Chapter 13 of the entire definition. In addition, Chapter 15 describes the system information about the system to obtain the database.
3.2. JDBC Driver API
Java.sql.driver has a complete definition in Chapter 9. Most JDBC drivers can only complete the abstract classes defined by these JDBC APIs. In particular, all Driver must provide the implementation of java.sql.connection, java.sql.state-physical, java.sql.prepared-statement, and java.sql.resultset. If the target DBMS provides an inline process with an OUT parameter, you must also provide a java.sql.callablestate interface. Each Database Driver must provide a class: java.sql.driver so that the system can be managed by java.sql.driverManager.
An obvious DRiver is an implementation of JDBC over ODBC, providing a JDBC-ODBC bridge with an ODBC interface, as shown in the previous figure. Since the JDBC is placed after the ODBC, it is simple and efficient. Another useful drive direct contact with the database-independent network protocol. Publish a protocol to allow multiple server implementations, such as on ODBC or specific DBMS (although some products that have been used, we don't intend to standardize them).) Is desirable.
4. JDBC use occasion
BEFORE LOOKING AT SPECIFICS OF THE JDBC API, An Undering of Typical Use Scenarios Is Help-Ful. There Are Two Common Scenarios That Must Be Treated Differently for Our Purposes: Applets and Applications.
It is helpful to find out what typical use occasions before watching the JDBC API. There are usually two situations that must be treated separately: applet and application.
4.1. Applet
At present, Java uses the most APPLET downloaded from the network, they are part of the web file. There is a data inventory to take the applet and the applet that can be used to contact the database using JDBC.
For example, a user might download a applet that displays the stock history prices. This applet obtains stock history prices from the relational database through the Internet. In the most general case, the use of Applet is through unreliable boundaries. For example, these Applets are obtained from another company or the Internet. Therefore, this situation is called "Internet". However, Applets may also be downloaded through the LAN. In this case, the security of the client is still a problem.
Typical applets differ from traditional database applications in several ways:
1. Unreliable applets are strictly limited to the operations they are allowed. In particular, they do not allow them to access local files, and they do not allow them to establish network connections to any database.
2. In terms of identifying and connecting the online database, Applets in the Internet environment face new problems.
3. When the database may be separated by you, the efficiency consideration is also different. Compared with the local area network, the database applet on the Internet may encounter very different reaction times.
4.2. Application
Java can also be used to establish ordinary applications, so as to use in the client. We believe that with more and more development tools, people have begun to realize the necessity of improving program productivity, as well as other advantages of Java, this use of Java will become more and more popular. In this way, Java's code is reliable, and is allowed to read and write to open network connections, etc., just like other application code.
Perhaps the most of these Java applications is in the interior of a company or on intranet, so it may be a intranet. For example, a company wants to use Java and its GUI component tool to establish his cooperative software based on cooperative data modes. These applications will access data from a local area network or a wide area network. Java applications can be made. The Java application occasions and intranet situations are many different from the applet. For example, the most natural way to calibrate a database is the name of a database, like // "Customers" and "Personnel". The user is then hoped that the system can locate the specific machine, DBMS, JDBC Driver, and Java applications.
4.3. Other occasions
There are other interesting situations:
1. Verified Applets refers to Applets that have been trusted by Java virtual machines. The reason why they are considered to be credible is because they have been on a specific key, or the user believes that the applet from a particular source is credible. In terms of security, they are the same as the app, but other aspects (such as positioning a database) are similar to the applet.
2. Different from the Java GUI to the client / server mode, the DBMS server is different, and the three-layer access method may be used. In this occasion, the Java application sent a call to the intermediate layer, the service of the intermediate layer is on the Internet, and it will call the database again. These calls may vary via RPC (Remote Procedure Call) or OB (Object RequestBroker). In these two occasions, the intermediate layer preferably uses an object change. We hope that the three-story structure will become more common, because for MIS managers, this can make them an opportunity to explicitly define legal operations on public databases. At the same time, the three-layer structure can provide a number of efficient benefits.
At present, the intermediate layer is generally accomplished using a language such as C or C. The intermediate layer can also be implemented with Java by optimizing the compiler to translate the Java byte code into an efficient machine code. Java has many excellent features (robust, safety, multi-thread) to achieve the purpose of the intermediate layer needs to be achieved.
5. Safety consideration
As a language Java on the network, it must be considered for security. Based on the above discussion, the two main use occasions of JDBC we must consider safety issues:
In the case of Java Applications, Java code is local, so it is also "trusted", and the Java Applet code that is not verified cannot access the data of local and other networks.
5.1. JDBC and unfounded applet
JDBC must first comply with Java's general security rules. In addition:
JDBC must think that there is no verification applets unreliable. l JDBC does not allow unreliable Applets to access local databases.
One has been registered with JDBC DriverManager is that JDBC Driver can only access the data source it comes.
An applet can only access data to servers it Download it.
If the JDBC drive layer is fully confident that the connection to a database server does not cause authentication or permission issues (possibly caused by programs running on the online random host), then it allows the applet to open this connection. The database server does not limit the access to the IP address, which is quite small, mainly for example. (Beware, this paragraph I may translate again!!! Let's take a look at the original text.) These restrictions are quite cumbersome. However, they are consistent with the limitations of general applets, we don't have to let go of these restrictions.
