?? jdbc-into.htm
字號:
3. 1. JDBC API <br>
JDBC API 被描述成為彝族抽象的Java接口,似的應用程序遠可以對某個數據庫打開連接,執行SQL語句并且處理結果。 </p>
<p>最重要的接口是: <br>
* java.sql.DriverManager 處理驅動的調入并且對產生新的數據庫連接提供支持。 <br>
* java.sql.Connection 代表對特定數據庫的連接。 <br>
* java.sql.Statement 代表一個特定的容器,來對一個特定的數據庫執行SQL語句。 <br>
* java.sql.ResultSet 控制對一個特定語句的行數據的存取。 <br>
其中java.sql.Statement又有兩個子類型: <br>
1. java.sql.PreparedStatement 用于執行預編譯的SQL語句。 <br>
2. java.sql.CallableStatement 用于執行對一個數據庫內嵌過程的調用。 <br>
下面的章節對JDBC是如何運行的提供了更多描述,整個定義見第13章。另外第15章描述了系統如果獲取數據庫的元數據信息。 <br>
3. 2. JDBC Driver API <br>
java.sql.Driver在第9章有完整的定義了.大部分JDBC驅動只需要完成這些JDBC API所定義的抽象類就可以了。特別地,所有的driver必須提供對java.sql.Connection,
java.sql. State-ment, java.sql.Prepared-Statement, and java.sql.ResultSet的實現。如果目標DBMS提供有OUT參數的內嵌過程,那么還必須提供java.sql.CallableStatement
接口。每個database driver必須提供一個類:java.sql.Driver以使得系統可以由 java.sql.DriverManager來管理。
<br>
一個顯然的driver是在ODBC之上提供對JDBC的實現,從而提供與ODBC接口的JDBC-ODBC 橋,就象前面的圖所顯示的.由于JDBC放在ODBC之后,所以實現起來簡單而且高效。
<br>
另外一個有用的驅動直接接觸數據庫無關的網絡協議。發布一個協議允許多個服務器實現的方法,例如在ODBC或者特定的DBMS上(盡管已經有了一些使用固定協議的產品,但是我們不打算對它們實現標準化。),是可取的。
</p>
<p><br>
4. JDBC使用場合 Before looking at specifics of the JDBC API, an understanding
of typical use scenarios is help-ful. There are two common scenarios
that must be treated differently for our purposes: applets and applications.
<br>
在看JDBC API之前了解一下典型的使用場合是有幫助的。通常有兩種情形必須分別對待:applet和application.
<br>
4. 1. Applet <br>
目前Java使用的最多的從網絡中下載的applet,它們作為web文件的一個部分。當中有數據庫存取applet和能夠使用JDBC來接觸數據庫的applet。
<br>
例如,一個用戶可能下載一個顯示股票歷史價格圖的applet。這個applet通過internet來從關系數據庫中獲得股票歷史價格。
<br>
最一般的情況里面,對applet的使用是通過不可靠的邊界的。例如從另外一個公司或者Internet上獲得這些applet。于是稱這個情況為"Internet"場合。然而applet也可能通過局域網下載。在這個情況里面,客戶機的安全都還是一個問題。
<br>
典型的applet在幾個方面與傳統的數據庫應用程序有所不同: <br>
1). 不可靠的applet被嚴格地限制在他們被允許執行的的操作上。特別地,不允許他們存取本地的文件,切不允許他們對任意的數據庫建立網絡連接。
<br>
2). 就標識和連接網上數據庫來說,Internet環境里面的applet面臨新的問題。 <br>
3). 當數據庫可能與你相隔萬里的時候,效率的考慮也有所不同了。與局域網相比,Internet上數據庫applet可能會碰到十分不同的反應時間。
<br>
4. 2. Application <br>
Java也可以用來建立普通的應用,從而想一般的應用一樣在客戶機上使用。我們相信隨著開發工具越來越多,人們開始認識到提高程序生產效率的必要性,以及Java的其他優點,Java的這種用法將越來越流行。在這種方式里面,Java的代碼是可以信賴的,且被允許讀寫文件打開網絡連接等等,就想其他的應用程序代碼一樣。
</p>
<p> 也許這些Java應用使用的最多的是在一個公司內部或者在Intranet上,所以不妨成為Intranet場合。例如一個公司希望利用Java及其GUI構件工具來建立他的基于合作數據模式的合作軟件。這些應用程序將存取局域網或者廣域網的數據。Java應用可以作到這些。
<br>
Java應用程序場合和Intranet場合與applet場合有諸多不同。例如標定一個數據庫最自然的方式是用一個數據庫的名字,就象"Customers"
和"Personnel"這樣。然后用戶希望系統能夠定位具體的機器,DBMS,JDBC driver,和Java應用程序。
<br>
4. 3. 其他場合 <br>
還有其他一些有趣的場合: <br>
1). 已驗證的applet(Trusted applets)是指那些已經被Java虛擬機器認定是可以信賴的applet。他們之所以被認為是可信的是因為他們已經對上了特定的密匙,或者用戶認為從特定來源來的applet是可信的。在安全的方面上他們與應用(appliction)相同,但是其他方面(例如定位一個數據庫)與則與applet相似。
<br>
2). 與直接從Java GUI出發用客戶/服務器模式來度曲DBMS服務器不同,三層存取方式可能被使用。在這個場合里面,Java應用程序對中間層的服務發出調用,中間層的服務在網上,它又再去調用數據庫。這些調用可能通過RPC
(remote procedure call)或者ORB (object request broker )。在這兩種場合里面,中間層最好使用一個對象變化。我們希望三層結構會變得越來越普遍,因為對于MIS管理者來說,這可以使得他們有機會在公共數據庫上顯式地定義合法操作等。同時三層結構可以提供許多效率上的好處。
</p>
<p>目前中間層一般用C或者C++這樣的語言來完成。通過優化編譯器把把Java 字節代碼翻譯成為高效的機器代碼,中間層也可以用Java來實現。Java有許多優良特性(健壯性,安全性,多線程)可以達到中間層需要達到的目的。
</p>
<p><br>
5. 安全性考慮 作為網絡上的語言JAVA必須十分注安全性的考慮。基于上面的討論,JDBC的兩種主要使用場合里面,我們必須考慮安全性問題:
<br>
* 在Java applications的場合里面Java代碼是本地的,所以也是"trusted" <br>
* 沒有驗證的Java applet代碼不可以存取本地的以及其他網絡的數據。 <br>
5. 1. JDBC 和未驗證的applet <br>
JDBC首先必須符合JAVA的一般安全規則。另外: <br>
* JDBC 必須認為沒有驗證的applets是不可靠的。 <br>
* JDBC 不可以讓不可靠的applets存取本地數據庫。 <br>
* 一個已經向JDBC DriverManager注冊的是JDBC Driver只能存取它所來的數據源。 <br>
* 一個applet也只能向它所Download來的服務器來存取數據。 <br>
如果JDBC驅動層如果完全確信對一個數據庫服務器打開連接不會引起認證或者權限問題(可能由網上隨機主機上運行的程序引起),那么它就允許applet打開這樣的連接。數據庫服務器不通過IP地址來限制存取是相當少的,主要是為了舉例。(當心,這一段話我可能翻譯反了!!!大家看看原文。)
<br>
這些限制是相當煩瑣的。不過他們與對一般applet的限制是一致的我們沒有必要放開這些限制。 <br>
5. 2. JDBC 和Java應用程序 <br>
對于一個普通的Java應用程序(例如全部用Java代碼而不是不可靠的applet )JDBC將從本地的類路徑里面獲得驅動,并且允許應用程序自由存取文件,遠程服務器等等。
<br>
但是和applet一樣,如果由于某些原因一個沒有驗證的sun.sql.Driver類從遠程的來源里面獲得,那么這個驅動只能和相同地方來的代碼配合。
<br>
5. 3. Driver的安全責任 <br>
JDBC driver可能在各種情況下使用,所以驅動的編制者遵循一定的簡單的安全規則,從而避免applet做非法的數據庫連接。
<br>
如果所有的驅動都象applet一樣從網上下載,那么這些原則將是不必要的,因為普通的安全規則已經對它做了限制。但是驅動的編寫者必須記住一旦他們的驅動獲得成功,用戶將在本地磁盤安裝這些驅動,那么驅動將成為Java環境中一個被信任的部分,所以必須確信它不會被來訪的applet所濫用。所以我們鼓勵所有的驅動編寫者必須遵循一定安全原則。
<br>
所有這些原則都是在連接打開的時候使用。這正式驅動和虛擬機器檢查當前調用者是否真的可以與指定的數據庫連接的時刻。一旦連接建立就不必做更多的檢查了。
<br>
5. 3. 1. 分享TCP/IP連接的時候必須謹慎 如果一個JDBC驅動試圖打開一個 TCP 連接,那么這個打開會被Java
安全管理機制自動檢查。這個機構會檢查當前調用棧里面有沒有applet,如果有那么就限定它可以訪問的機器集合。所以一般地JDBC驅動可以把TCP建立檢查留給Java虛擬機。
<br>
但是如果一個JDBC驅動試圖在多個數據庫連接之間共享一個TCP連接,那么驅動就必須自己負責檢查每個調用者是否真的被允許與目標數據庫聯系。例如如果我們為applet
A打開了一個通往機器foobah 的TCP連接,這并不意味著applet B被自動允許來共享這個連接。applet B可能沒有任何訪問機器foobah的權力。所以在允許某個程序重用一個現成的TCP連接之前,JDBC
驅動必須通過安全機構來檢查當前的的調用者是否可以訪問這個連接。通過下面的代碼可是實現這個功能。 </p>
<p><br>
SecurityManager security = System.getSecurityManager(); <br>
if (security != null) <br>
{ <br>
security.checkConnect(hostName, portNumber); <br>
} </p>
<p><br>
如果連接是不允許的,那么Security.checkConnect方法將產生一個java.lang.SecurityException。
5. 3. 2. 檢查所有的本地文件訪問 <br>
如果一個JDBC取得需要訪問本地機器上的數據,那么他必須確信調用者是被允許打開這個文件的。例如: </p>
<p><br>
SecurityManager security = System.getSecurityManager(); <br>
if (security != null) <br>
{ <br>
security.checkRead(fileName); <br>
} </p>
<p><br>
如果對特定文件的訪問是不允許的,那么Security.checkRead方法將產生一個java.lang.SecurityException。
<br>
5. 3. 3. 作好最壞的準備 <br>
一些驅動可能使用本地的方法來橋接底層數據庫程序。則這些情況里面判斷那些本地文件將被底層函數所訪問是困難的。 <br>
在這些環境里面用戶必須作好最壞的打算,并且否決所有下載applet所發出的數據庫存取,除非驅動可能完全確信將要做存取是沒有問題的。
<br>
例如一個JDBC-ODBC橋接器必須檢查ODBC數據源的的名稱,確保applet只可以訪問它的“生源地”。如果對有的名字中不能判斷出數據源的主機名,那么只能否決這個訪問。
<br>
為了決定一個當前的調用者是可以信賴的應用還是一個applet,JDBC驅動必須能夠檢查這個調用者是否可以寫一個隨機的文件:
</p>
<p><br>
SecurityManager security = System.getSecurityManager(); <br>
if (security != null) <br>
{ <br>
security.checkWrite("foobaz"); <br>
I. } <br>
</p>
<!-- #EndEditable --></td>
<td width="20"> </td>
</tr>
<tr>
<td width="20" height="11"> </td>
<td width="541" height="11"><!-- #BeginEditable "7" --><!-- #EndEditable --></td>
<td width="101" height="11">
</td>
<td width="20" height="11"> </td>
</tr>
</table><div align="center"> <br>
</div>
</td>
</tr>
</table>
<div align="center">
<br>
</div>
</body>
<!-- #EndTemplate --></html>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -