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 的出現顯 得別具意義。