以下內容含腳本,或可能導致頁面不正常的代碼 |
---|
說明:上面顯示的是代碼內容。您可以先檢查過代碼沒問題,或修改之后再運行. |
以下內容含腳本,或可能導致頁面不正常的代碼 |
---|
說明:上面顯示的是代碼內容。您可以先檢查過代碼沒問題,或修改之后再運行. |
(2)主要Java開源軟件的種類
JavaWeb容器: Tomcat、Resin
EJB容器: JBoss
框架: Java Web框架(Struts)、業(yè)務邏輯層框架(Spring)
持久化層: DAO、ORM映射工具(如Hibernate、OJB)
工程管理工具:ANT、Eclipse
日志輸出工具: Log4J
JavaWeb服務工具:Apache Axis
促成Java世界如此絢麗多姿的基本動力在于以下核心思想:
接口與實現(xiàn)
不同的軟件系統(tǒng)之間通過接口來交互。軟件系統(tǒng)只對外公開接口,封裝實現(xiàn)細節(jié)。接口描述了軟件系統(tǒng)具備的功能,也就是指定軟件系統(tǒng)能夠做什么,但是沒有指明怎么去做。接口具有三大作用:
(1)對于接口制訂者:SUN公司通過定義接口,來制定新的軟件系統(tǒng)的規(guī)范,例如Servlet規(guī)范、EJB規(guī)范和JDO規(guī)范,這些規(guī)范主要以接口的形式描述了軟件系統(tǒng)必須具備的功能。通過制定規(guī)范,SUN公司指引著Java技術的發(fā)展方向,同時給接口的實現(xiàn)者提供了自由發(fā)揮的廣闊空間。
(2)對于接口實現(xiàn)者:接口實現(xiàn)者以特定的方式實現(xiàn)標準的規(guī)范。例如一些開放源代碼軟件,如Tomcat和Resin分別以不同的實現(xiàn)方式,實現(xiàn)了標準的Servlet規(guī)范。同一個接口允許有多種實現(xiàn),使得Java領域保持著百花齊放、百家爭鳴的良好勢頭,
(3)對于接口調用者:接口調用者的程序具有良好的可移植性。以JavaWeb應用為例,由于Tomcat和Resin遵守同樣的規(guī)范,因此用戶開發(fā)的JavaWeb應用能夠順利的從Tomcat容器移植到Resin容器中。
封裝與抽象
封裝指的是在一個大系統(tǒng)中包含一個小系統(tǒng),大系統(tǒng)是建立在已有小系統(tǒng)的基礎上的更為復雜、功能更強大的系統(tǒng)。例如,Hibernate對JDBC API進行了封裝,在Hibernate內部依賴JDBC API來操縱數(shù)據庫,但是Hibernate API比JDBC API具有更強大的功能,例如JDBC API只具有連接和操縱數(shù)據庫的功能,而Hibernate不僅具備這一功能,還具有對象-關系映射的功能。
抽象是指從已經存在的具有相似功能、但不同接口的系統(tǒng)中抽取共性,提煉出統(tǒng)一的接口。例如,Hibernate Transaction API是對JDBC
Transaction API和Java Transaction API(JTA)的抽象。
繼承與擴展
繼承與擴展是一對孿生兄弟,當兩個類之間存在繼承關系,那么必定也存在擴展關系。繼承的優(yōu)點在于提高代碼的可重用性,子類會繼承父類的所有public和protected類型的屬性和方法,在子類的程序代碼中,無需重復定義這些屬性和方法。擴展的優(yōu)點在于使軟件應用具有可伸縮性,能夠在已有功能的基礎上擴展新的功能。
Struts框架充分運用了擴展思想。Struts框架中的許多類都是供應用程序擴展的,其中最主要的一個是Action類,在Action類中已經定義了一些通用的方法,采用Struts框架的JavaWeb應用將擴展Action類,創(chuàng)建負責特定流程或業(yè)務的客戶化的Action類。
對象的生命周期
當一個對象通過new語句創(chuàng)建后,它就會擁有一塊固定的內存空間,如果沒有任何變量引用它,它就會結束生命周期,它占用的內存空間隨時可能被JVM的垃圾回收器回收。
應用程序如何管理對象的生命周期呢?目前比較流行的做法是把對象存放在一個“范圍”內。例如在JavaWeb應用中,JavaBean可以存放在request、session或application范圍內。每個范圍對應一個對象,例如request范圍對應HttpServletRequest對象,session范圍對應HttpSession對象,application范圍對應ServletContext對象。把一個JavaBean存放在request范圍內,實質上是在HttpServletRequest對象的一個集合屬性中加入這個JavaBean的引用,這個集合屬性也被稱為HttpServletRequest對象的緩存。
把一個JavaBean存放在request范圍內,等價于以下兩種說法:
把一個JavaBean加入到HttpServletRequest對象的緩存中
把一個JavaBean和HttpServletRequest對象關聯(lián)
當JavaBean位于request范圍內,這個JavaBean的生命周期依賴于HttpServletRequest對象的生命周期,當HttpServletRequest對象結束生命周期,并且這個JavaBean也不被應用程序中的其他變量引用,那么它就會結束生命周期。
那么HttpServletRequest對象本身的生命周期由誰管理呢?這是由JavaWeb容器(也稱Servlet容器)來管理的。對于每個HTTP請求,JavaWeb容器會自動創(chuàng)建一個HttpServletRequest對象,當HTTP請求的響應完畢,JavaWeb容器就會結束這個對象的生命周期。同理,當每個HTTP會話開始,JavaWeb容器會自動創(chuàng)建一個HttpSession對象,當這個會話結束,JavaWeb容器就會結束這個對象的生命周期;當每個JavaWeb應用啟動時,JavaWeb容器會自動創(chuàng)建一個ServletContext對象,當這個應用被關閉,JavaWeb容器就會結束這個對象的生命周期。
在Hibernate中,在net.sf.hibernate.Session范圍內加入一個持久化對象,實質上是在Session對象的集合屬性中加入這個持久化對象的引用。以下幾種說法是等價的:
在Session范圍內加入一個持久化對象
在Session的緩存中加入一個持久化對象
把一個持久化對象與Session關聯(lián)
值得注意的是,Hibernate的Session不僅能管理緩存中持久化對象的生命周期,還會負責按照持久化對象的狀態(tài)的變化,來同步更新數(shù)據庫。
集成開源軟件的基本步驟
在開發(fā)Java應用時,為了提高開發(fā)效率,縮短開發(fā)周期,常常需要集成第三方提供的Java軟件,如ORM映射工具Hibernate、MVC框架Struts、日志工具Log4J和Web服務軟件Apache
AXIS等。在自己的應用中集成這些第三方軟件時,大體步驟都很相似。
(1) 把它們的JAR文件拷貝到classpath中。
(2) 創(chuàng)建它們的配置文件(XML格式的文件或者Java屬性文件),這些配置文件通常也位于classpath中。
(3) 在程序中訪問它們的接口。
接口與配置文件,是軟件系統(tǒng)對外公開的兩個主要窗口。無論是Tomcat、Struts還是Hibernate,都離不開配置文件,與編寫程序代碼相比,配置文件能提高軟件的可維護性,更加靈活的適應用戶變化的需求,但是,配置文件不擅長表達非常復雜的邏輯,在這種情況下,必須求助于程序代碼。作為軟件使用者,如果僅僅想快速掌握一個新的Java軟件的使用方法,而不打算深入了解軟件內在原理和結構,無非就是了解它的接口以及配置文件的使用方法。當然,如果想對軟件的運用達到得心應手的地步,還應該了解軟件本身的實現(xiàn)原理和結構,而這些軟件無非就是通過抽象、封裝和實現(xiàn)等手段,從簡單的小系統(tǒng)出發(fā),構造出更加復雜,但是對外有著簡潔統(tǒng)一的接口的大系統(tǒng)
下面為避免混淆,在文中凡未加特殊說明的Java,統(tǒng)指桌面Java而言。
一、 問題提出
*常用的解釋性Java(Java Applet)的執(zhí)行速度慢,不適于嵌入式的應用。
*Java要求過大的內存。
*嵌入式設備要求操作硬件。因Java廢棄了C語言所使用的指針,且在Web環(huán)境下使用了Java虛擬機(JVM),使Java無力直接甚至間接地用指針操作硬件。
*Java使用一些自動功能會引起執(zhí)行時間的不確定性,成為嵌入式的大忌。如垃圾自動收集器。本是對于C的重大改進,但卻因程序自動地回收垃圾,從而引入了實時的時間不確定性。
二、解決方案
使用AOT編譯器
為解決解釋性Java(Java Applet)執(zhí)行速度過慢的問題,發(fā)展了AOT(ahead-of-time)編譯器。大家喜歡在Internet上使用Java的一個原因是其字節(jié)碼具有跨平臺性,即同一Java代碼可以運行于PC、Mac、Solaris,甚至于主機之上。為此,在英文叫它WORA(寫一次即可通行于任意機)。這是因為每一操作系統(tǒng)平臺上都有符合自己機型的專用Java虛擬機(JVM),由它對字節(jié)碼進行解釋運行。因為解釋程序需先被解釋再被執(zhí)行,多了解釋環(huán)節(jié),延誤數(shù)秒鐘時間。如果是撥打電話,這個時間足以令人生厭。現(xiàn)在使用AOT(ahead-of-time)超前編譯器,提前將解釋碼轉換為本平臺所用的并經優(yōu)化過的二進制碼,速度提高很多。現(xiàn)有Cygnus公司聲稱,它開發(fā)的AOT編譯器執(zhí)行速度是原解釋程序的8倍。NewMonics說它的 QuickPERC編譯器是原解釋程序的20倍。當然,AOT編譯器也有不足,就是他犧牲了Java的WORA。
減少內存的占用
所有的面向對象語言,比C及匯編語言點用內存都多。這個問題對于桌面系統(tǒng)早已不再是考慮的因素了,如服務器平均占用數(shù)GB的內存已司空見慣。但是,對于嵌入式系統(tǒng)卻不能不考慮。用Java開發(fā)的信息家電產品可能需要把內存限制到512KB以下。如果嵌入式系統(tǒng)使用的是規(guī)模為1MB的核心類庫,那就是說,一句代碼尚未寫,內存早就不夠用了。
為此,需要把用不到的類、類方法和代統(tǒng)統(tǒng)從程序中剔除。(AOT超前編譯器可以幫助解決這個問題。)再就是自己開發(fā)本平臺專用的,既短小高效、又符合Java API標準的Java核心類庫。
開發(fā)能混合編程的IDE
一般認為,用C語言寫的程序,指鍺使用不當引起的缺陷占總缺陷的80%左右。Java語言,出于安全的考慮,才廢棄了使用指針。但是,指針卻能夠最直接地訪問到存儲器和真實的硬件。現(xiàn)在,為在嵌入式Java中能夠訪問到硬件,不得不改用本地接口,即從嵌入式Java中利用能夠訪問到硬件的C語言函數(shù)來實行交叉編程。這就意味著增加了復雜性。開發(fā)人員需要具備多語言以及多層次的混合編程和混合調試的能力。發(fā)展多語言多層次混合編程的IDE,無疑十分有助于一般開發(fā)人員完成這一相當復雜的課題。Metrowerks的CodeWorrior和IBM的VisualAge就是新開發(fā)的基于J2ME的這樣的IDE。
克服時間的不確定性
Java 最主要的問題是時間不確定性,主要來源于存儲器殘渣的自動收集再生器。這種垃圾收集再生器工作的時候,自動地決定何時停下其他程序的執(zhí)行,再根據當時殘渣的實際情況或長或短地完成任務。所以,它嚴重地干擾實時應用所要求的時間確定性。為解決這一問題,不同公司采用不同的方法和垃圾收集的算法。 NewMonics的Real Time Executives和Windriver的FastJ都是保證絕對的確定時間,Sun公司用不同的辦法但也保證具有實時的確定性。采用不同的編程技巧,譬如使用類型確定的線程局部存儲,也可以避免因垃圾收集引發(fā)的沖突。
需保持跨平臺的必要
AOT 編譯器生成的Java代碼喪失了Java在其他操作平臺上的執(zhí)行能力。要想把Java的源代碼再向其他平臺移植,需要附加很大的勞動。面向對象的一個基本設計原理就是只要保持接品不變,那么,與接口交談的代碼在移植時就不受影響。所謂高級邏輯接口的隔離手法,事實上,就是將平臺敏感的內容同移值無關的代碼分離開來,并且分別提供同樣功能的平臺敏感程序。現(xiàn)在,針對嵌入式Java,目前還沒有人做這項工作。
三、實際應用
Java是良好的嵌入式編程語言嗎?
還不能這么說,至少現(xiàn)在是這樣。因為在嵌入式系統(tǒng)中,Java如何應用要看具體情況而定。對于需要管理中斷來完成重要任務的應用系統(tǒng),就不宜于選用Java 進行開發(fā),譬如引導登外星的飛行器系統(tǒng)就是這樣。對于要求輕型、高效、任務重要、時間確定性要求極高的系統(tǒng),也是只能局限于使用C語言和匯編。比如,點燃登陸外星的制動火箭系統(tǒng),定時通過串行口獲取關鍵信息一邊做出決定的系統(tǒng),定時報告航天器方位的系統(tǒng)等都不能使用Java。但是,需要不斷與他人通信聯(lián)系,以便對貨運進行有效管理的手持系統(tǒng),又最適合使用Java編程。因為,它既發(fā)揚了Java Applet固有的跨平臺應用地Web環(huán)境的特點,又能充分利用服務器端的現(xiàn)成軟件。
使用Java有時也并不完全取決于技術
立足于經濟上的考慮,比單獨的技術考慮更為重要。譬如,對于服務器,為了支持使用Java,寧愿多花費數(shù)千元擴大存儲器是正確的。因為,從投入/產出的分析也得出同樣的結論。又如手機,若為支持使用Java,哪性僅只需要多花一元錢去擴大存儲器也是不可行的。因為,手機的生產是以行百萬件的產量來考慮的,多花一元線,就意味著多花千百萬元,諾大的數(shù)字遠比技術的先進更為重要,是顯而易見的。
實施嵌入式Java時需注意
Java 用于嵌入式還是瓣生事物,需要探路前進,摸著石頭過河,忌冒進和全面開花。應試探性地從使用現(xiàn)成的嵌入式J2ME開始,在它的通用性的開發(fā)環(huán)境下運行本平臺的字節(jié)碼。盡可能地順著J2MME向前走,盡可能地順著J2ME向前走,盡可能地走得遠一點,只有在遇到特殊問題時才導求新的解決辦法。新方法的采用并不一定能夠解決問題,比如,AOT或半自動的垃圾收集器等可能并沒有解決你的問題,也勿驚慌,要總結經驗做出評價,繼續(xù)前進,使嵌入式Java日罄完善。
要重視IDE的選用,好的IDE絕對是良好的助手。否則,你是單槍匹馬,披荊斬棘,艱苦良多。
]]>軟件是有生命的,這可能是老調重彈了,但是因為它事關分層架構的原由,反復強調都不過分。
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構,其次才是完整的功能。
目前很多人對軟件的思想還是焦點落在后者:完整的功能,覺得一個軟件功能越完整越好,其實關鍵還是架構的靈活性,就是前者,基礎架構好,功能添加只是時間和工作量問題,但是如果架構不好,功能再完整,也不可能包括未來所有功能,軟件是有生命的,在未來成長時,更多功能需要加入,但是因為基礎架構不靈活不能方便加入,死路一條。
正因為普通人對軟件存在短視誤區(qū),對功能追求高于基礎架構,很多吃了虧的老程序員就此離開軟件行業(yè),帶走寶貴的失敗經驗,新的盲目的年輕程序員還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱,貌似非常符合胃口,其實類似國內那些幾百元的盜版軟件,擴展性以及持續(xù)發(fā)展性嚴重不足。
那么選擇現(xiàn)在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢?其實還不盡然,關鍵還是取決于你如何使用這些框架來搭建你的業(yè)務系統(tǒng)。
存儲過程和復雜SQL語句的陷阱
首先談談存儲過程使用的誤區(qū),使用存儲過程架構的人以為可以解決性能問題,其實它正是導致性能問題的罪魁禍首之一,打個比喻:如果一個人頻臨死亡,打一針可以讓其延長半年,但是打了這針,其他所有醫(yī)療方案就全部失效,請問你會使用這種短視方案嗎?
為什么這樣說呢?如果存儲過程都封裝了業(yè)務過程,那么運行負載都集中在數(shù)據庫端,要中間J2EE應用服務器干什么?要中間服務器的分布式計算和集群能力做什么?只能回到過去集中式數(shù)據庫主機時代。現(xiàn)在軟件都是面向互聯(lián)網的,不象過去那樣局限在一個小局域網,多用戶并發(fā)訪問量都是無法確定和衡量,依靠一臺數(shù)據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環(huán)境的。(當然搞數(shù)據庫集群也只是五十步和百步的區(qū)別)。
從分層角度來看,現(xiàn)在三層架構:表現(xiàn)層、業(yè)務層和持久層,三個層次應該分割明顯,職責分明:持久層職責持久化保存業(yè)務模型對象,業(yè)務層對持久層的調用只是幫助我們激活曾經委托其保管的對象,所以,不能因為持久層是保管者,我們就以其為核心圍繞其編程,除了要求其歸還模型對象外,還要求其做其做復雜的業(yè)務組合。打個比喻:你在火車站將水果和盤子兩個對象委托保管處保管,過了兩天來取時,你還要求保管處將水果去皮切成塊,放在盤子里,做成水果盤給你,合理嗎?
上面是談過分依賴持久層的一個現(xiàn)象,還有一個正好相反現(xiàn)象,持久層散發(fā)出來,開始擠占業(yè)務層,腐蝕業(yè)務層,整個業(yè)務層到處看見的是數(shù)據表的影子(包括數(shù)據表的字段),而不是業(yè)務對象。這樣程序員應該多看看OO經典PoEAA。PoEAA 認為除了持久層,不應該在其他地方看到數(shù)據表或表字段名。
當然適量使用存儲過程,使用數(shù)據庫優(yōu)點也是允許的。按照Evans DDD理論,可以將SQL語句和存儲過程作為規(guī)則Specification一部分。
Hibernate等ORM問題
現(xiàn)在使用Hibernate人也不少,但是他們發(fā)現(xiàn)Hibernate性能緩慢,所以尋求解決方案,其實并不是 Hibernate性能緩慢,而是我們使用方式發(fā)生錯誤:
“最近本人正搞一個項目,項目中我們用到了struts1.2+hibernate3, 由于關系復雜表和表之間的關系很多,在很多地方把lazy都設置false,所以導致數(shù)據一加載很慢,而且查詢一條數(shù)據更是非常的慢。”
Hibernate是一個基于對象模型持久化的技術,因此,關鍵是我們需要設計出高質量的對象模型,遵循DDD領域建模原則,減少降低關聯(lián),通過分層等有效辦法處理關聯(lián)。如果采取圍繞數(shù)據表進行設計編程,加上表之間關系復雜(沒有科學方法處理、偵察或減少這些關系),必然導致 系統(tǒng)運行緩慢,其實同樣問題也適用于當初對EJB的實體Bean的CMP抱怨上,實體Bean是Domain Model持久化,如果不首先設計Domain Model,而是設計數(shù)據表,和持久化工具設計目標背道而馳,能不出問題嗎?關于這個問題N多年就在Jdon爭論過。
關于本系列
PHP 是一種非常優(yōu)秀的 Web 開發(fā)語言,而在商業(yè)應用程序開發(fā)方面,Java 編程語言十分流行。因此,為了在 AIX Version 5.3 操作系統(tǒng)上充分利用它們的優(yōu)勢,專門開發(fā)了 PHP Java Bridge。本系列文章向 AIX 5.3 開發(fā)人員介紹了如何在他們的 Web 應用程序開發(fā)中集成 PHP 和 Java 技術。
為了說明這一點,您將按照典型的開發(fā)過程來構建一個簡單的問卷調查應用程序,具體內容包括:
開發(fā)主要的 Java 應用程序
通過 Servlet 將 Java 應用程序公開為基于 Java 的 Web 應用程序
添加在數(shù)據庫中存儲信息的支持
將原始應用程序公開為 Web Services,并為該應用程序提供 PHP 接口
使用專門的 PHP Java Bridge 重新開發(fā) PHP 接口
本系列文章共分為六個部分:
第 1 部分介紹了一個應用程序,并為構建 Java 應用程序以及使用 Tomcat 執(zhí)行基于 Java 的 Web 應用程序搭建了相應的環(huán)境。
第 2 部分介紹了主要的應用程序代碼以及一個簡單的 Java Servlet 的開發(fā),以便為信息提供一個 Web 接口。
第 3 部分將核心應用程序連接到 DB2? 數(shù)據庫,以便對問卷調查的問題和回答進行存儲。
第 4 部分對原始應用程序進行轉換,使其能夠作為 Web Services 進行訪問,并且它為 PHP 接口提供了基礎。
第 5 部分使用 PHP Java Bridge 為 Java 應用程序構建 PHP 接口。
第 6 部分對這個應用程序進行重新開發(fā),以便使用 PHP Java Bridge 來代替 Web Services 接口。
關于本教程
本教程是這個系列文章的最后一個部分,在本教程中,您將了解如何組合使用 PHP 和 Java 技術,以便為支持問卷調查應用程序的原始 Java 類構建 Web 接口。這個最終解決方案使用 PHP Java Bridge 以使得您可以為在本系列文章的前面幾個部分中所開發(fā)的 Java 類構建基于 PHP 的接口。
您首先將了解 PHP Java Bridge、以及它的操作與最初開發(fā)的 Web 服務方法之間的區(qū)別,從而對這幾種不同的技術進行比較。然后,在研究原始 Java 類的 PHP 接口的最終備選方法之前,您將研究幾種不同的集成您的基于 PHP 和 Java 的解決方案。
先決條件
為了學習本教程,您需要安裝下列軟件:
IBM pSerIEs? 服務器(本文中的代碼使用 AIX Version 5.3 進行了測試。)
Apache Tomcat 系統(tǒng)
Eclipse IDE
Java 5 64-bit SDK(要下載這個包,您需要進行注冊,但注冊是免費的。)
Mozilla Web browser for AIX
幾種不同連接技術的比較
問卷調查應用程序所使用的 Web 服務方法為您提供了極大的靈活性,而 PHP Java Bridge 以不同的方式提供了類似的靈活性。在您更深入地研究開發(fā)過程之前,讓我們更仔細地分析一下它們之間的區(qū)別和相似之處。
Web 服務方法
您對原始應用程序進行了轉換,這樣一來,在本系列文章的第四部分中(請參見參考資料),就可以將其作為 Web Services 進行訪問。除了可訪問性之外,Web Services 模型還具有許多其它的優(yōu)點。通過 Web Services 接口來公開類,您可以保證互操作性,因為幾乎所有的語言都支持某些形式的 Web Services ,無論是 XML-RPC 還是簡單對象訪問協(xié)議 (SOAP)。
這也就帶來了極大的靈活性。現(xiàn)在,您的 Java 后端可以由采用 C、Perl、Java 語言、PHP、JavaScript 和許多其他編程語言所編寫的腳本和應用程序來進行訪問;然而,實現(xiàn)互操作性是要付出一定代價的。
正如您在本系列文章的第四部分中所看到的,將您的應用程序公開為 Web Services 是一項復雜的任務。要正確地完成這項工作,需要通過 Web 服務描述語言 (WSDL) 文件開發(fā)和部署您的代碼;然后,您必須單獨地為每個函數(shù)定義不同的接口,同時還需要確保采用與您希望使用的標準可互操作的格式,對所提供的值和返回的值進行編碼和封裝。
在您為核心類開發(fā)和添加新的功能和擴展時,所有的這些工作都需要花費大量的時間進行開發(fā)、以及較長的時間進行控制。要使得原始類能夠通過 Web 服務接口進行訪問,可能會使得您的開發(fā)時間增加 20% 到 50%。
而且,正如稍后將更詳細地進行介紹的,Web 服務方法還隱含了不容忽視的顯著性能開銷(如果您希望在大型操作環(huán)境中部署該應用程序的話)。
PHP Java Bridge
在本系列文章的第五部分中,您詳細地了解了 PHP Java Bridge(請參見參考資料),但是 PHP Java Bridge 的關鍵元素允許您直接從 PHP 內部訪問 Java 類,就好像您正在訪問本地 PHP 類一樣。
盡管 Web 服務和 PHP Java Bridge 接口在本質上存在很大的差別,但事實上,它們都使用 XML 進行通信,以交換有關原始方法和類、以及應該如何對它們進行訪問的信息。與 Web 服務解決方案有所不同,這個過程是自動的。
正如您在第五部分中所看到的(請參見參考資料)、以及本文清單 1 中所介紹的,在您導入 PHP 元素、并且創(chuàng)建到遠程 Java 主機的連接之后,使用和創(chuàng)建 Java 類和對象是非常簡單的。
清單 1. 簡單的 PHP Java Bridge 的示例 <? require_once("http://sulaco.mcslp.pri:8080/JavaBridge/java/Java.inc"); $System = new Java("java.lang.System"); print_r($System->getProperties); ?> |
在本教程后面的內容中,您將研究所需的確切的方法和解決方案。
區(qū)別和相似之處
Web Services 和 PHP Java 解決方案之間存在許多明顯的區(qū)別和相似之處,從而使得采用這兩種方法開發(fā)和部署應用程序時具有相應的優(yōu)點和缺點。
例如,Web 服務和 PHP Java Bridge 解決方案都允許您使用 PHP 作為前端、使用 Java 環(huán)境作為應用程序的后端部分。對于 Web 服務解決方案,您必須開發(fā)原始類、Web 服務類和 PHP 接口。對于 PHP Java Bridge,您只需要開發(fā)原始 Java 類和 PHP 前端,PHP Java Bridge 可以為您處理所有的互操作性問題。
在 Web 服務和 PHP Java Bridge 解決方案之間還存在一個比較顯著的區(qū)別,即完成解決方案所需的步驟有所不同。Web 服務解決方案需要額外的開發(fā)時間,以使用所需的 Web 服務接口來公開服務、并使得它們可供使用。在 PHP 中使用 Web 服務也是相當繁瑣的,因為您必須開發(fā)一個能夠為已開發(fā)的 Web 服務接口提供接口的解決方案。
對于 PHP Java Bridge,您可以直接訪問現(xiàn)有的 Java 類,而不必在 Java 端顯式地開發(fā)接口、或者在 PHP 端顯式地開發(fā)訪問接口。
性能
為了將您的原始請求轉換為完全與平臺無關的形式,使用 Web 服務的關鍵問題之一是必須將請求轉換為 XML。所得到的 XML 數(shù)據包中包括請求、源或目標信息、以及請求中所包含的任何數(shù)據或者信息(例如,方法或函數(shù)的參數(shù)),這使得 XML 組件的負載變得非常大。
采用這種方式生成有效的 XML 是相當花費時間的,但是對該信息進行解碼甚至可能需要花費更多的時間,因為 XML 解析的過程并不像您所預期的那么簡單和直接。和發(fā)送請求到服務器的客戶端的負載相比,這個處理過程會呈現(xiàn)更高的負載,隨后還會有接受請求和最后處理請求的過程。在將響應發(fā)送回客戶端的時候,將按相反的順序執(zhí)行相同的處理過程(采用 XML 對響應進行編碼,發(fā)送到客戶端,客戶端解析 XML 并且提取響應)。
您可以在圖 1 中更詳細地看到這個過程。
圖 1. 實際應用中的 Web 服務接口 ]]>一、ODBC到JDBC的發(fā)展歷程
說到JDBC,很容易讓人聯(lián)想到另一個十分熟悉的字眼ODBC。它們之間有沒有聯(lián)系呢?如果有,那么它們之間又是怎樣的關系呢?
ODBC是OpenDatabaseConnectivity的英文簡寫。它是一種用來在相關或不相關的管理系統(tǒng)(DBMS)中存取數(shù)據的,用C語言實現(xiàn)的,標準應用程序數(shù)據接口。通過ODBCAPI,應用程序可以存取保存在多種不同管理系統(tǒng)(DBMS)中的數(shù)據,而不論每個DBMS使用了何種數(shù)據存儲格式和編程接口。
1.ODBC的結構模型
ODBC的結構包括四個主要部分:應用程序接口、驅動器管理器、驅動器和數(shù)據源。
應用程序接口:屏蔽不同的ODBC驅動器之間函數(shù)調用的差別,為用戶提供統(tǒng)一的SQL編程接口。
驅動器管理器:為應用程序裝載驅動器。
驅動器:實現(xiàn)ODBC的函數(shù)調用,提供對特定數(shù)據源的SQL請求。如果需要,驅動器將修改應用程序的請求,使得請求符合相關的DBMS所支持的文法。
數(shù)據源:由用戶想要存取的數(shù)據以及與它相關的操作系統(tǒng)、DBMS和用于DBMS的網絡平臺組成。
雖然ODBC驅動器管理器的主要目的是加載驅動器,以便ODBC函數(shù)調用,但是驅動器本身也執(zhí)行ODBC函數(shù)調用,并與相互配合。因此當應用系統(tǒng)發(fā)出調用與數(shù)據源進行連接時,驅動器能管理通信協(xié)議。當建立起與數(shù)據源的連接時,驅動器便能處理應用系統(tǒng)向DBMS發(fā)出的請求,對分析或發(fā)自數(shù)據源的設計進行必要的翻譯,并將結果返回給應用系統(tǒng)。
2.JDBC的誕生
自從Java語言于1995年5月正式公布以來,Java風靡全球。出現(xiàn)大量的用java語言編寫的程序,其中也包括應用程序。由于沒有一個Java語言的API,編程人員不得不在Java程序中加入C語言的ODBC函數(shù)調用。這就使很多Java的優(yōu)秀特性無法充分發(fā)揮,比如平臺無關性、面向對象特性等。隨著越來越多的編程人員對Java語言的日益喜愛,越來越多的公司在Java程序開發(fā)上投入的精力日益增加,對java語言接口的的API的要求越來越強烈。也由于ODBC的有其不足之處,比如它并不容易使用,沒有面向對象的特性等等,SUN公司決定開發(fā)一Java語言為接口的應用程序開發(fā)接口。在JDK1.x版本中,JDBC只是一個可選部件,到了JDK1.1公布時,SQL類包(也就是JDBCAPI)就成為Java語言的標準部件。
二、JDBC技術概述
JDBC是一種可用于執(zhí)行SQL語句的JavaAPI(ApplicationProgrammingInterface,應用程序設計接口)。它由一些Java語言寫的類、界面組成。JDBC給應用開發(fā)人員、前臺工具開發(fā)人員提供了一種標準的應用程序設計接口,使開發(fā)人員可以用純Java語言編寫完整的應用程序。
通過使用JDBC,開發(fā)人員可以很方便地將SQL語句傳送給幾乎任何一種。也就是說,開發(fā)人員可以不必寫一個程序Sybase,寫另一個程序Oracle,再寫一個程序Microsoft的SQLServer。用JDBC寫的程序能夠自動地將SQL語句傳送給相應的管理系統(tǒng)(DBMS)。不但如此,使用Java編寫的應用程序可以在任何支持Java的平臺上運行,不必在不同的平臺上編寫不同的應用。Java和JDBC的結合可以讓開發(fā)人員在開發(fā)應用時真正實現(xiàn)WriteOnce,RunEverywhere!
Java具有健壯、安全、易用等特性,而且支持自動網上下載,本質上是一種很好的應用的編程語言。它所需要的是Java應用如何同各種各樣的連接,JDBC正是實現(xiàn)這種連接的關鍵。
JDBC擴展了Java的能力,如使用Java和JDBCAPI就可以公布一個Web頁,頁中帶有能遠端的Ap?plet。或者企業(yè)可以通過JDBC讓全部的職工(他們可以使用不同的操作系統(tǒng),如Windwos,Machintosh和UNIX)在In?tranet上連接到幾個全球上,而這幾個全球可以是不相同的。隨著越來越多的程序開發(fā)人員使用Java語言,對Java易操作性的需求越來越強烈。
MIS管理人員喜歡Java和JDBC,因為這樣可以更容易經濟地公布信息。各種已經安裝在中的事務處理都將繼續(xù)正常運行,甚至這些事務處理是存儲在不同的管理系統(tǒng)中;而對新的應用來說,開發(fā)時間將縮短,安裝和版本升級將大大簡化。程序員可以編寫或改寫一個程序,然后將它放在服務器上,而每個用戶都可以服務器得到最新的版本。對于信息服務行業(yè),Java和JDBC提供了一種很好的向外界用戶更新信息的方法。
1.JDBC的任務
簡單地說,JDBC能完成下列三件事:
1)同一個建立連接;
2)向發(fā)送SQL語句;
3)處理返回的結果。
]]>新技術采用概況
許多分析家擁有技術應用所需的描述模型。其中最為流行的模型是定義在Ruby的Web開發(fā)框架Iowa中,用來描述農產品的應用,稍后在一本由Geoffrey A. Moore寫作的名為《跨越鴻溝》(Crossing the Chasm)的書中,被用來描述技術內容。在書中,Moore分析了技術應用周期中存在著的五個截然不同的群體:
技術專家。這個群體傾向于采用新的技術。任何一種有前途的技術都會引起這個群體的注意。
先行采納者。不管這項技術是否在主流技術中取得成功,這個群體都將會采用新的技術來提升競爭優(yōu)勢。
實用主義者。一旦新的技術進入主流應用,或是有足夠陡峭的增長曲線來保證技術將得到廣泛采用,那么實用主義者就會積極采用新的技術。
保守派。只有新技術成為必須的時候,他們才會考慮采用新的技術。
懷疑論者。這個群體可能很晚才會采用新的技術,或者也可能永遠只使用某一特定技術。
Moore指出,技術應用的關鍵之處在于團隊中是否存在實用主義者。因為實用主義者需要新技術大規(guī)模的應用,這個中間群體希望看到其他務實派在團隊做出承諾之前就使用新的技術。這是一個類似于《第二十二條軍規(guī)》書中所描述的現(xiàn)象,因為務實派們都會相互依賴的存在。出于這樣的原因,在先行采納者排列在技術專家之后和務實派之前,你會經常在市場接受度曲線中看到一種下降的趨勢。Moore將這種下降稱之為鴻溝傾向,并且這種想法應出于圍繞任何新技術的風險討論的中心。
]]>
基于JVM的語言正在開始流行
當Sun Microsystems公司在1995年第一次揭開Java的面紗的時候,就是非常難被定義的。這是因為JAVA是由多個部分構成:首先,它當然是一個面向對象語言。同時JAVA也是一個定義標準的語言(或多個標準,包括移動設備,標準,和企業(yè)三個版本)。最后,Java是一個虛擬機(”JVM”),一個Java程序能夠執(zhí)行的軟件環(huán)境。如果你有一個JVM,雖然這個JVM只能用來運行Java的程序——但是,JVM能在運行在你能想到的每一個平臺之上,這使得Java成為一個具有高移植性的語言。
在Java世界的一個令人著迷的趨勢就是:在最近的幾年里使用JVM來運行非Java的程序在程增長的趨勢。畢竟,如果創(chuàng)造了一門新的語言,你就必須在特定的平臺上實現(xiàn)它。如果你想你的語言能在不同的平臺上移植,那么你就需要為每一個平臺實現(xiàn)一個版本。但是,相比而言,如果你將語言實現(xiàn)在JVM上,那么你就能讓你的語言運行在任何系統(tǒng)的JVM上,這就意味著幾乎所有平臺都可以運行。
于是現(xiàn)在就有了許多的基于JVM的新增語言。其中4個最流行的是發(fā)布在開源許可證之下的。考慮到如今Java也是開發(fā)源碼了,這意味著你可以使用一個全開源體系,并且這個體系是可以移植的。因為這些語言都在JVM之上實現(xiàn)的,所以你就可以同時訪問Java的標準庫。這意味著如果有一個第三方的的 Java庫,而且你精于Python,那么你就可以使用Jython在你的源代碼中訪問這些Java庫。
早期的基于JVM的腳本語言,就我所知,是Jython,之前被稱為JPython。Jython,從名字你就可以猜到,是一個基于JVM的 Python語言實現(xiàn)。Jython完全兼容Python2.2的標準版本(這個標準版本的Python也被稱為CPython),這意味著Jython 將會沒有Python的一些新特性。最近發(fā)布的Jython版本是2007年月發(fā)布的,但是Sun雇傭了兩位早期Jython非常知名的開發(fā)者,并且現(xiàn)在 Jython可以運行Django應用程序框架,因此驗證其兼容Python的能力
Sun公司同時資助了JRuby的開發(fā),一個基于JVM的Ruby版本。Jython是Python唯一的兩個實現(xiàn)的其中之一,對比而言,JRuby則是眾多Ruby語言實現(xiàn)的其中之一。然而,JRuby被廣泛的認為是一個非常重要的版本。特別是因為他的效率,和高度兼容標準C的 Ruby版本實現(xiàn)。JRuby同樣可以運行Ruby on Rails框架(譯者注:構建在Ruby之上的WEB應用框架),此外還能運行其他眾多的功能。
Jython和JRuby都是從其他已存在的語言中移植到JVM中來的。而全新的基于JVM的腳本語言是Groovy和Scala。這兩門語言現(xiàn)在都越來越流行,不同的是,Groovy是動態(tài)腳本語言,而是Scala是靜態(tài)語言。使用Groovy最著名的應用是Groovy on Grails項目,一個用Groovy寫成,運行在JVM之上的WEB應用框架(和Ruby on Rails很相似)。Grails找到通向商業(yè)應用程序的道路,最著名的就是LinkedIn,使用Linkedin,開發(fā)人員發(fā)現(xiàn)他們能比直接使用 Java更快速和容易的開發(fā)程序。相比而言,Scala,而是強類型是語言,Steve Yegge最近的一次訪談中曾經談到、靜態(tài)語言和動態(tài)語言的爭論,因為這個他還受到了很多的批評(譯者注:關于Steve Yegge的這篇關于動態(tài)語言和靜態(tài)語言之爭可以查看這里Steve Yegge是一個動態(tài)語言的支持者)
Java已經被公認為是非常成功而流行的語言。現(xiàn)在,Java也同時也被認為是非常流行的平臺,這四類語言僅僅是在不遠的將來通過JVM來實現(xiàn)的新興語言的開始。
]]>