J2EE是Java技術不斷適應和促進企業級應用過程中的產物。下面本站小編就為大家分享最新的J2EE架構師認證指南，希望能幫助到大家!
架構師之路：
一、書籍
1、基礎書籍
《Java程式設計思想》
《J2EE應用與BEA WebLogic Server》
《精通EJB》
2、設計書籍
《UML和模式應用》
《設計模式：可複用物件導向軟體的基礎》
《Java與模式》
《J2EE核心模式》
《EJB設計模式》
《敏捷軟體開發：原則、模式與實踐》
《企業應用架構模式》
《軟體架構：組織原則與模式》
《重構：改善既有程式碼的設計》
3、流程書籍
《統一軟體開發過程》
二、專注做好一件事
1、分享
分享自己的工作或者學習心得，同時會有理解、應用、總結、表達甚至推廣方面的提高，對於自己的進步很有利。
2、共進
找志同道合的高手，和他們多交流，向他們多學習，少走彎路，同時擴大自己的社交圈子。
3、協同
學習重要，實踐也很重要。有機會參與開源專案，與世界各地的高手交流，學習。
4、修煉
能力不是天生的，是可以後天培養的;能力不是一成不變的，是可以學習提高的;一個人的成功，不是他做事的成功，而是他自我修煉的成功。認真規劃自己的目標和時間。第一，要找到一件事，把它當目標，然後發誓把這件事做到超乎想象的程度。第二，要學會利用時間。用長遠的眼光來規劃這件事，用短期角度來思考和執行這件事。
三、架構師的職業技能
1、卓越的程式設計師
做產品之前，架構師必須要幫助產品團隊把可行性、技術需求以及權衡取捨等因素一一剖析清楚。技術需求出來之後，架構師需要設計整體的技術實現步驟(大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作)。與開發團隊一起，完成設計與實施的細節。與開發團隊和運維團隊一起，完成部署的過程。與運維團隊一起，進行部署之後的維護和故障排除。在這個過程中，一個架構師至少有一半以上的工作是需要與開發團隊一起進行的，一個架構師不能將實施細節拋之腦後。一個架構師必須通過自己的個人影響力來對開發團隊進行指導工作，通過自己寫程式碼以及和其他成員一起寫程式碼，來指導團隊成員實現每個架構細節的思路。一個架構師不僅要會寫程式碼，還必須要能夠寫出自己設計的系統中最難實現的那段程式碼。這樣他才能夠放心的把“落地”的這個重擔交給開發團隊來做。一個架構師的價值在於，他不僅能看到系統的美，而且能夠在建造系統的時候能夠把這些美創造出來。
素質：經驗和技術基礎。創造性和知識彙總能力。基於2、3語言的溝通學習能力。市場嗅覺。藝術氣質和冒險精神。邏輯思維和抽象能力。
技能：架構理論和方法學。物件理論。JEE/動態，技術領域技術能力。模式。遺留系統互聯。中介軟體。訊息機制和協議。本地化和國際化。安全性和效能。
做為一個架構師，需要實現(這個過程是結對程式設計，會有一個搭檔)一個系統最難實現的一部分。可以將其稱之為“先鋒”，因為這是檢驗腦中的主意是否真的是一個好主意的過程。需要在第一次實施中會細化這個主意。然後才能放心的讓程式設計團隊的其他成員按照這個模式來走。這就是“架構”。
2、抽象思維
抽象思維能力。邏輯思維能力。
3、技術前瞻性
好的架構師，應該提前想到如何為程式設計師儘可能減輕負擔，比如資料庫軟體新的特性可以提高效能，簡化查詢步驟，那架構師是不是第一時間要載入程式員去適應新的特性，提高開發效率。技術前瞻性還體現在對新技術的選擇上，哪些東西適合自己團隊，哪些不適合肯定要自己心中有本帳。架構師在自己所處的領域肯定了解頗深，未來本領域技術該如何發展，應該有自己的理解。也會對未來技術的發展有所期盼，有自己的見解。
4、問題解決大師
抽象思維是往高層次的昇華，透過問題看本質則是往深層次的挖掘。從問題看本質，實質上是一個從表層逐步深入的過程。在架構師面對一個使用者需求時，這個“使用者需求”是非常表層的——比如說，一個自動遠端備份資料庫的功能。而架構師的主要工作，就是把這樣的“業務需求”翻譯成“技術需求”。這個過程一方面需要通過抽象思維將使用者需求提煉為啟動、讀取、儲存、中斷處理等模組，而另一方面則需要看到更深層次的網路、作業系統、硬體等方面，以及其可靠性、穩定性、適用性、安全性等問題。如果你在編寫Java程式碼時考慮到了JVM的效能，在編寫PHP程式碼時想到了潛在的.安全問題，甚至於在編寫HTML+CSS頁面時考慮到了不同瀏覽器的相容性，這些都體現了“透過問題看本質”的素質。
5、多領域大師
多學習跨領域、跨學科的東西。談到跨領域學習，知識面廣似乎是最好實現的目標，只要博覽群書，加上高中之前各學科紮實的基礎，相信大多數程式設計師本身就具備一定的跨領域學習的能力。還有一種跨領域學習的目標，就是多語種的學習。學習除英文之外的語言，既能開拓國際視野，也能在平時的工作中有所建樹。IT行業的發展，依靠的業務，從而給人們帶來的方便快捷，改變人們的生活、工作方式，其核心就是服務。科學技術本身並不能創造價值，只有當其轉換了生產力之後才會具有價值，這一切的核心，就是業務。
6、溝通能力
首先自然是溝通要清晰明瞭，平和待人。架構師不能將自己鎖在自己的象牙塔上，頤指氣使的對程式設計師發號施令。做到人性化的溝通，需要我們在平時就進行培養。寫出大部頭的架構書，有的時候並沒有用VISIO畫出的簡單架構圖好理解。人對圖形理解遠遠大於對文字的理解，直觀簡單的UML圖可以極大的方便程式設計師理解架構師的意圖。其次，可以召開小範圍的技術人員會議，大家一起來討論，一起理解架構師真正的意圖。甚至就是一塊小白板，幾支筆就能把問題擺清楚，講明白，統一意見後的團隊必然幹勁十足，再不會出現互相推諉的情況。
鍛鍊溝通能力，首先我們需要更多的感性思考，說話時也要注重別人的感受，尊重對方才能更好的交流。微軟MVP陳廣琛在與51CTO編輯談到程式設計師溝通能力時，曾說道：“很多程式設計師總能列出一堆的理由來，說明為什麼自己不適合學習或者不需要掌握某項與程式無關的技能，例如說演講、英語、設計等等。但其實問題並沒有那麼複雜，你需要考慮的只是多學一項技能是否對你的職業發展更有利，只要你願意，沒什麼是不能改變的。”
7、內力
內力更多的是一種思考能力，結合技術的思考能力。架構更多的內力體現在對技術的綜合運用上，光會程式設計的程式設計師，最多就能做到高階程式設計師，也就是技術實現上的高手。就比如兩個高手比武，比的不光是招式，更多的是對招式的運用，畢竟招式是死的，人是活的。
內功的修煉第一層，自然是開發技術的培養。從寫第一行程式碼開始，就多想為什麼，有沒有什麼其他的路徑能實現同樣的功能。當我們寫了很長時間程式碼了，是不是就該考慮更多的問題，比如優化、預期未來。其次是對架構的熟悉。要做一名優秀的架構師，就得對各種架構做到了熟於心。
更高層次的修煉，就在於不同技術的學習。要懂得資料庫知識，懂得安全監控方面的知識，還要懂得網路構建方面的知識。這是比較高層次的內功修煉，很有可能與程式設計師目前所處的開發環境關係不大，對程式設計師來說並不是什麼有用的東西。但一個優秀的架構師必須懂得這些，才能更好地抽象軟體的使用環境，選擇符合需要的架構以及開發模式。
8、權衡取捨
沒有一個人可以建造一個沒有缺陷的架構。這個專案可能缺乏時間，缺乏金錢，缺乏人手，或者缺乏合適的技術。在專案從開始到進行中的每時每刻，架構師都需要對這些架構的“缺陷”有明確的瞭解。所以架構師必須要對權衡取捨方面有著出色的把控能力，即架構師有沒有看到各方面訴求的差異，以及有沒有意願為了這些差異而做出妥協。一個大型雲端計算服務，需要在安全、伸縮性、可用性、效能以及價效比方面獲得高分，同時必須維持全球上百位客戶不間斷的使用需求。對於系統而言，在某一個地方或某一個層面發生的改變，勢必將影響到系統的其他地方和層面，乃至整個系統。出於對可用性權衡的研究，加州大學的Eric Brewer教授提出了CAP理論，認為對於一個共享資料的系統而言，資料持續性、系統可用性、對網路劃分的耐受性這三個屬性是不可調和的，任何時候只能同時達成兩個。所以在知道了魚和熊掌不可兼得的情況下，要深刻理解各個方面不同角度的訴求，並找出各方都可以接受妥協的制衡點，自然是必不可少的。
9、管控能力
作為一名優秀的架構師，比較迫切的管理任務可能就是開發成本與收益平衡的問題。舉例說，採用MySQL做資料庫與採用Oracle做資料庫，價格肯定有很大差距。但是究竟該採用何種技術，架構師需要仔細權衡使用者的報價與本公司收益率的問題。又比如說採取甲技術開發出的軟體，介面大方效能一般，但是需要耗費程式設計師更多的勞動時間，那在有些場景下就不如採用乙技術快速開發後節約的大量人力成本，儘管介面有些難看。通管理，能增強技術團隊內部的團結。安全監控也是架構師的重要職責，負責監督整個開發過程中可能出現的問題，在出現問題後還要牽頭及時解決問題。這裡我們講到的管控能力，就是這種內部團結的實現，是一種對於程式設計師人格尊重的實現。
10、藝術氣質
架構師最大的價值在於藝術。
商業軟體專案的首要目標是實現來自客戶或公司的商業需求。然而，在架構過程中僅僅考慮到實現商業需求而建立的系統往往缺乏伸縮性、安全性、可維護性、可靠性、可移植性等等，導致其在短短數年內便因無法與時俱進而被拋棄。這一點幾乎每一位維護過專案的程式設計師應該都能夠體會到：面對著缺乏文件、不知所云的程式碼，想要修改或新增一個功能卻無從下手。而一個優美的系統則是可以像有機的生命一樣成長的，這是因為從系統開始架構的那一刻起，架構師就考慮到這個系統以後將會面臨的挑戰，為系統的成長預留好空間。專案經理經常會對這位架構師提出的看似理想化的要求不置可否——專案經理只想著能夠儘快以比較低的成本實現客戶的需求，然而這些充滿藝術美感的想法其實是打造健康——因而優美——的系統的根本因素。
在軟體開發產業發展的過程中逐漸建立起了一些行業準則和參考標準，這些將有助於架構師在面對複雜需求時仍然能夠保持清晰地頭腦來思考問題。學習前人總結的軟體與架構方面的知識，遵循既定的指導標準——比如，按照模版編寫軟體架構文件——看似死板，卻是必要的修煉。這些架構師的基本功是全面的、抽象的、深層次的。沒有這些基礎，那麼架構師連實現商業需求都會感到吃力，更不要說去顧及需求之外的東西。另外我們提到過架構師需要有前瞻性：超前的眼光是架構師實現其藝術追求的必不可少的一部分。
閱讀公開的軟體架構文件(Software Architecture Document)是一個很好的學習途徑(在Google上能夠找到很多)。軟體架構文件是架構師在專案早期階段對於系統的一個描述性概覽，這份文件提供了這個系統預計實現功能的概述，這個系統將會使用什麼技術以及可能存在的技術侷限，以及最重要的部分：檢視模型。
用例檢視(Use-Case View)：這是業務需求的角度。
邏輯檢視(Logical View)：這是功能實現的角度，用例執行的流程圖。
上面兩個檢視是必需的，也往往是專案經理最關注的部分。如果只考慮這兩個角度，系統可以被建立，但正如之前所描述的那樣，是不可能優美的。架構師還需要視情況考慮下面這些檢視：
程序檢視(Process View)：如果系統是多執行緒的，高併發的，則需要考慮執行緒的角度。
部署檢視(Deployment View)：如果系統分佈在多節點，則需要考慮伺服器端和客戶端節點等硬體對映的角度。
資料檢視(Data View)：如果持久層在系統中很重要，則需要考慮資料的角度。
有些檢視框架有一定通用性，比如業內廣為流傳的4+1模型、RM-ODP模型等等;但是對於每一個系統需要考慮哪些檢視，則需要架構師去摸索、去感覺、去研究;況且現在新技術層出不窮，一個比較前沿的專案需要從前人沒有考慮過的角度看問題也不是沒有可能。如果架構師沒有一定的藝術氣質來指引方向，那麼一味的照搬現有的模式可能會水土不服而使系統變得臃腫複雜，而完全不考慮商業需求之外的因素則會讓系統先天不足而夭折。
如果沒有紮實的技術基礎，如果架構師缺乏全域性觀、抽象思維能力以及透過問題看本質的能力，那麼他僅僅為了實現客戶需求都會感到力不從心，更不用說發揮自己的藝術氣質云云了。從另一個角度來講，做藝術的架構師們也都是行業裡大師級別的人物了，這也是架構師們的終極目標吧!
四、架構師的進取之路
在管理體系裡面，一人的個人特性決定了你在哪個位置，而技術技能只是做事實施的必需。架構師這個職務，同時要求較高的個人素質和技術能力，因此它的進取之路總結起來就是：做人、做事，做架構師。
1、個人特性
有效溝通：
包括學會談判，心裡分析，局面分析，寫作訓練。
學會談判：
包括對結果的預期，過程的控制，適時停止討論。
風險與防備：
包括冷靜觀察，最大的風險是成本的枯竭，準確理解決策者的意圖和方向。
抽象思維：
包括理性決策，把事情搞清楚。
2、技術能力
模型化：
包括建立抽象模型，基於模型分析與評估，準確的圖形表達。
實現能力：
包括架構推行，體系/系統的把握，設計能力。
決策背景：
包括需求決定設計，豐富的領域知識。
五、架構師
架構師是具有技術發言權，方向決策權，和團隊人員開發資源調配權的開發團隊的TeamLear，也是這個程式的設計者，當然他是這個程式團隊的靈魂。進行沒有設計的架構設計不叫架構師。面向未來的，才叫設計，設計因未來而存在，沒有創新，就沒有設計，沒有改變，就沒有設計。用進化論去思考你的設計，讓你的設計超越一切理論，設計只是記憶的載體而不是記憶的全部，其實程式設計師是藝術家，而不是建築工人。