java架構一下知識

Java架構：

軟體架構作為一個概念，展現在技術和業務兩個方面。
      

從技術角度來說：軟體架構随着技術的革新不斷地更新其内容，軟體架建構立于目前技術和一些基本原則的基礎之上。
      

先說一些基本原則：
      

分層原則：分層是為了降低軟體深度複雜性而使用的關鍵思想，就像社會有了階級一樣，軟體有了層次結構。
      

子產品化原則：子產品化是化解軟體廣度複雜的必然手段，子產品化的目的就是讓軟體分工。
      

接口實作分離原則随着軟體子產品化的不斷深入改進，面向接口程式設計而不是面向實作程式設計可以讓複雜度日趨增高的軟體降低子產品之間的耦合度，進而讓各子產品更輕松改進。從這個原則出發，軟體也從微觀進行了細緻的規範化。
      

還有兩個比較小但很重要的原則：
細節隐藏原則很顯然把複雜問題簡化，把難看的細節隐去，能讓軟體結構更清晰。其實這個原則使用很普遍，java/c++語言中的封裝原則以及設計模式中的Facade（外觀）模式就很能展現這個原則的精神。
      

依賴倒置原則随着軟體結構的進一步發展,層與層之間、子產品與子產品之間的依賴逐漸加深，而層、子產品的動态可插拔要求不端增大。依賴倒置原則可看視為接口實作分離原則的深化，根據此原則的精神，軟體進入了工具時代。這個原則有點類似于知名的好萊塢法則：Don't call us, we'll call you。

以上這些原則奠定了我們的軟體架構的價值名額。但軟體架構畢竟是建立在目前技術之上的。而每一代技術都有架構模式。過去的不再說了，讓我們現在就來看一下目前流行的技術，以及目前我們能采用的架構。

因為面向對象是目前最流行開發技術，且設計模式的大量使用使面向對象的走向成熟，而資料庫是目前最有效的存儲結構、web界面是目前最流行的使用者接口，是以目前最典型的三層次架構就架構在以上幾項技術的基礎之上，用資料庫作存儲層、用面向對象來實作業務層、用web來作為使用者接口層。我們從三層次架構談起：
      

因為面向對象技術和資料庫技術不适配，是以在标準三層次架構的基礎上，我們增加了資料持久層，來管理O-R雙向映射，但目前一直沒有最理想的實作技術。cmp和entity bean技術因為其實作複雜，功能前景有限，已接近被淘汰的邊緣。JDO及hibernate作為o-r映射的後期之秀，尤其是hibernate，功能相當完備。推薦作為持久層的首選
在業務層,因為目前業務日趨負載，且變動頻繁，是以我們必須有足夠靈活的技術來保證我們的适應變化的能力，在标準j2ee系統中session bean負責業務處理，且有不錯的性能表現，但采用ejb系統對業務架構模式改變太大，且其複雜而昂貴，業務代碼移植性差。而spring 作為一個bean配置的輕量級架構，漂亮的IOC模式實作，對業務架構影響小，是以推薦作為中間層業務架構。
      

在使用者結構層,雖然servlet/jsp/jstl/javaBean 能夠實作MVC架構,但終究過于粗糙。struts對MVC架構的實作就比較完美，Taperstry也極好地實作MVC架構，且采用基于事件的方式，非常誘人，惜其不夠成熟，我們仍舊推薦struts作為使用者接口層基礎架構。
因為業務層是三層次架構中最有決定意義的，是以讓我們回到業務層細緻地分析一下，在複雜的業務我們常常需要以下基礎服務的一種或幾種：事務一緻性服務acid(tool:jta/jts)、并發加鎖服務concurrent&&lock、池化管理服務cache、通路控制服務(tool:jaas)、流程控制服務workflow、動态實作服務IOC，串行化消息服務(tool:jms)、負載平衡服務blance等。如果我們不采用重量級應用伺服器(如weblogic,websphere,jboss等)及重量級元件(EJB)，我們必須自己實作其中一些服務。雖然我們大多情況下，不需要所有這些服務，但實作起來卻非易事。幸運的是我們有大量的開源實作代碼,但采用開源代碼卻常常是件不輕松的事。

      

随着xml作為結構化資訊傳輸和存儲地位日漸重要,一些xml文檔操作工具(DOM,Digester,SAX等)的使用愈發重要,而随着xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema來設計xml文檔格式,然後采用java binding來生成java bean 會成為主要程式設計模式,而這又進一步使資料中心向xml轉移,使在中小資料量上,愈發傾向于以xquery為查詢語言的xml資料庫。最近還有一個趨勢,microsoft,ibm等紛紛大量開發中間軟體如(microsoft office之infopath)，可以直接從xml schema 生成 錄入頁面等非常實用的功能。還有web service 的廣泛應用，都将對軟體的架構有非常重大的影響。至于面向服務架構(SOA)前景如何，三層次架構什麼時候走入曆史，現在還很難定論。
      

aop的發展也會對軟體架構有很深的影響，但在面向對象架構裡，無論aspectJ還是jboss-aop抑是aspectWerks、nanning都有其自身的嚴重問題:維護性很差,是以說它将很難走遠。也許作為一個很好的思想，它将在web service裡大展身手。

      

rdf,owl作為w3c語義模型的标志性的語言,也很難想象能在目前業務架構發揮太大影響。但如果真如它所聲稱那樣，廣泛地改變着資訊的結構。那麼對軟體架構也會有深遠影響。

      

有關架構設計的一些忠告：
      

盡量建立完整的持久對象層.可獲得高回報
      

盡量将各功能分層,分塊,每一子產品均依賴假定的其它子產品的外觀
      

不能依賴靜态資料來實作IOC模式，應該依賴資料特征接口，靜态資料僅是資料特征接口實作方式之一
      

架構設計時xml是支援而不是依賴.但可以提供單一的xml版本的實作

      

從業務角度說：軟體架構應是深刻展現業務内部規則的業務架構，但因為業務變化頻纴，是以軟體架構很難保持恒定不變，但業務的頻繁變化不應是軟體架構大規模頻繁變化的原因，軟體架構應是基于變化的架構。
一種業務有其在一段時間内穩定存在的理由(暫且不談)，業務内部有許多用例，每一種用例都有固定的規則，每一規則都有一些可供判定的項，每一項從某一次元來觀察都是可測量的，我們的架構首先必須保證完美适應每一項每一種測量方式，很多失敗的架構都是因為很多項的測量方式都發生變更這種微觀變化中。

      

每個用例都有規則，我們在作業務用例分析，常常假定一些規則是先驗的，持久穩定的，然而後來的業務改變常常又證明這種看法是錯誤的，然而常常我們的架構已經為之付出了不可挽回的代價。大量事實證明：規則的變化常常用例變化的根本原因。是以我們的架構要盡可能适應規則的變化，盡可能建立規則模版。

      

每個用例都關系着不同的角色。每一個用例的産生都必然是因為角色的變更（注意：不是替換，而是增強或減弱），是以注意角色的各種可能情況，對架構的設計有舉足輕重的意義。在我們目前的三層架構裡，角色完美地對應接口概念。

      

在一個系統裡很多用例都互相關聯,考慮到每個用例均有可能有不同的特例，是以在架構設計中，盡量采用依賴倒置原則。如架構許可可采用消息通信模式(JMS)。這樣可降低耦合度。

      

現在我們談一下業務穩定存在理由對業務的影響。存在即是合理，在這裡當然是正确的。業務因人而存在，是以問業務存在的理由即是問不同角色的需要這項業務的理由以及喜歡不喜歡目前業務用例的理由，所有這樣的角色都應該在系統裡預留。《待續》
      

在架構設計中有幾個原則可以考慮：
      

用例盡量細分
      

用例盡量抽象
      

角色盡量獨立
      

項測量獨立原則
      

追求簡單性
      

這裡未提供相關的例子，例子會在以後的更新時提供。

      

業務和模式之間的關系
      

業務中的一些用例之間的關系常常和一些正常的模式很相似。但随着時間的演化，慢慢地和先前的模式有了分歧。這是個正常的現象。但這對系統架構卻要求非常高，要求系統架構能适應一些模式的更替。在這裡我們盡可能早地注意到用例之間的互相角色變化，為架構更新做好準備.      

主流架構還是MVC架構技術
      
    
1：jsp+servlet+javaben适用于比較小的項目
      
    
2：strut+spring+hibnate
目前這是主流架構技術組合在一起就是ssh了
适用于要求可維護性強的架構技術
      
    
3：ejb jsf等重量級架構技術比較過時
      
    
WebWork 【Java開源 Web架構】
       
    
WebWork 是由OpenSymphony組織開發的，緻力于元件化和代碼重用的拉出式MVC模式J2EE Web架構。WebWork目前最新版本是2.1，現在的WebWork2.x前身是Rickard Oberg開發的WebWork，但現在WebWork已經被拆分成了Xwork1和WebWork2兩個項目。 Xwork簡潔、靈活功能強大，它是一個标準的Command模式實作，并且完全從web層脫離出來。 Xwork提供了很多核心功能：前端攔截機（interceptor），運作時表單屬性驗證，類型轉換，強大的表達式語言（OGNL – the Object Graph Notation Language），IoC（Inversion of Control倒置控制）容器等。 WebWork2建立在Xwork之上，處理HTTP的響應和請求。WebWork2使用ServletDispatcher将HTTP請求的變成 Action(業務層Action類), session（會話）application（應用程式）範圍的映射，request請求參數映射。WebWork2支援多視圖表示，視圖部分可以使用 JSP, Velocity, FreeMarker, JasperReports，XML等。在WebWork2.2中添加了對AJAX的支援，這支援是建構在DWR與Dojo這兩個架構的基礎之上.【EclipseWork：用于WebWork輔助開發的一個Eclipse插件】
       
    
Struts 【Java開源 Web架構】
      
    
Struts 是一個基于Sun J2EE平台的MVC架構，主要是采用Servlet和JSP技術來實作的。由于Struts能充分滿足應用開發的需求，簡單易用，靈活迅速，在過去的一年中頗受關注。Struts把Servlet、JSP、自定義标簽和資訊資源(message resources)整合到一個統一的架構中，開發人員利用其進行開發時不用再自己編碼實作全套MVC模式，極大的節省了時間，是以說Struts是一個非常不錯的應用架構。【StrutsIDE：用于Struts輔助開發的一個Eclipse插件】
      
    
Hibernate 【Java開源 持久層架構】
      
    
Hibernate 是一個開放源代碼的對象關系映射架構，它對JDBC進行了非常輕量級的對象封裝，使得Java程式員可以随心所欲的使用對象程式設計思維來操縱資料庫。 Hibernate可以應用在任何使用JDBC的場合，既可以在Java的用戶端程式實用，也可以在Servlet/JSP的Web應用中使用，最具革命意義的是，Hibernate可以在應用EJB的J2EE架構中取代CMP，完成資料持久化的重任。Eclipse平台下的Hibernate輔助開發工具:【Hibernate Synchronizer】【MiddlegenIDE】
       
    
Quartz 【Java開源 Job排程】
      
    
Quartz 是OpenSymphony開源組織在Job scheduling領域又一個開源項目,它可以與J2EE與J2SE應用程式相結合也可以單獨使用。Quartz可以用來建立簡單或為運作十個，百個，甚至是好幾萬個Jobs這樣複雜的日程式表。Jobs可以做成标準的Java元件或 EJBs。Quartz的最新版本為Quartz 1.5.0。
       
    
Velocity 【Java開源 模闆引擎】
      
    
Velocity 是一個基于java的模闆引擎（template engine）。它允許任何人僅僅簡單的使用模闆語言（template language）來引用由java代碼定義的對象。當      
    
Velocity應用于web開發時，界面設計人員可以和java程式開發人員同步開發一個遵循MVC架構的web站點，也就是說，頁面設計人員可以隻關注頁面的顯示效果，而由java程式開發人員關注業務邏輯編碼。Velocity将java代碼從web頁面中分離出來，這樣為web站點的長期維護提供了便利，同時也為我們在JSP和PHP之外又提供了一種可選的方案。 Velocity的能力遠不止web站點開發這個領域，例如，它可以從模闆（template）産生SQL和PostScript、XML，它也可以被當作一個獨立工具來産生源代碼和報告，或者作為其他系統的內建元件使用。Velocity也可以為Turbine web開發架構提供模闆服務（template service）。Velocity+Turbine提供一個模闆服務的方式允許一個web應用以一個真正的MVC模型進行開發。 【VeloEclipse ：Velocity在Eclipse平台下的一個輔助開發插件】
       
    
IBATIS 【Java開源 持久層架構】
       
    
使用ibatis 提供的ORM機制，對業務邏輯實作人員而言，面對的是純粹的Java對象， 這一層與通過Hibernate 實作ORM 而言基本一緻，而對于具體的資料操作，Hibernate 會自動生成SQL 語句，而ibatis 則要求開發者編寫具體的SQL 語句。相對Hibernate等 “全自動”ORM機制而言，ibatis 以SQL開發的工作量和資料庫移植性上的讓步，為系統設計提供了更大的自由空間。作為“全自動”ORM 實作的一種有益補充，ibatis 的出現顯 得别具意義。