J2EE平臺由一整套服務(Services)、應用程序接口(APIs)和協議構成。下面是小編整理的關於J2EE Web架構與CS架構命名上的差異，歡迎大家參考!
與傳統的CS(客戶端與服務器端)架構相比，J2EE Web程序服務器提供了很多額外的技術支持。而且這些技術是一般Web應用程序都需要用到的，但是Web程序開發人員不需要再另行開發，只需要直接拿過來使用即可。具體的來說，在Web應用中主要通過調用現成的API來完成這個功能。而且使用這些技術時，基本上沒有什麼技術含量。因爲在具體工作中使用這些技術都是採用基本固定的格式。命名技術就是其中一個典型的代表。在這篇文章中，筆者根據自己的經驗，談談這方面使用過程中的注意點。
一、 與傳統架構之間的區別。
在使用這個技術之前，筆者認爲開發人員至少需要知道，在Web架構與CS架構之間的區別。只有如此，才能夠更加全面的瞭解採用新技術所能夠帶來的優勢。故筆者一開始就着重強調兩者之間的差異。
在應用程序開發中，如果一個類A需要調用另外一個類B，則類A需要知道類B的源程序，然後在其中新建一個類B的實例，才能夠實現調用。而且當一個程序改變時，還需要重新編譯。從這可以看出，類與類之間的連接需要通過實例來完成，他們之間的連接就比較混亂。
而採用J2EE命名服務則不需要這麼麻煩。簡單的說，JE22命名服務器提供了應用構件程序的命名環境。如果採用了這種技術的話，那麼實現類調用時，就可以不通過實例來完成。做一個形象的比喻，命名服務就好像是一個地址簿。當開發人員在程序開發時採用了新的構件或者新建了某個類，那麼相關的信息就會都在這個地址簿中登記。作爲開發人員的話，就不需要再去查找原始的類，只需要在這個地址簿中查找即可。顯然這方面了我們日常的開發工作，可以縮短開發的週期，同時簡化類之間的引用。最重要的是，如果以後被引用的類有變化時，不需要編譯整個應用程序，而只需要重編譯有變化的類即可。
二、 命名服務的核心環節解析。
J2EE命名服務提供各種應用構件程序的統一命名環境。其英文簡稱是JNDI。從這個英文名字中可以看到，這個命名服務包括兩層含義：命名和目錄接口。我們在瞭解這個技術的時候，如果從這兩個角度去理解，可能會更加簡單一點。JNDI簡化了高級Web程序類之間的查找調用。
從技術上來說，JNDI主要是通過API來實現的。JNDI API提供了Web構件進行標準目錄操作的方法。舉一個簡單的例子，可以將對象屬性和Java對象聯繫在一起，或者通過對象屬性來查找Java對象。當我們在電話簿中查找某個電話的時候，會現在索引中找到某個人的名字。然後再從這個索引中打開對應的記錄，查找這個人的'電話、住址等聯繫信息。JNDI核心的工作思路就是如此。在上面筆者談到過，這些技術都是採用基本固定的調用格式。也就是說，JNDI已經被標準化。爲此應用程序可以通過使用JNDI來訪問其他通用的命名服務。如支持常用的We命名協議、DNS等命名架構。筆者認爲這點非常的重要。因爲其支持多種命名結構，則可以與其他平臺的應用系統，如C++等進行很好的系統的整合。
三、 使用命名服務的注意事項。
JNDI命名服務支持多種命名結構，如Web命名協議、DNS命名架構等等。那麼到底該採用什麼樣的命名結構呢?這裏面還是有比較大的學問。因爲在以後系統維護中，可能要與其它應用程序進行整合。此時如果整合的系統採用相同或者類似的命名架購，那麼以後整合的工作就會相對簡單許多。一般來說，一家公司開發的產品，其採用的都是統一的命名架購。不管開發人員喜歡使用什麼樣的命名結構，公司都會要求其在後續的開發時採用公司規定命名架購，這也主要是爲了方便後續與自己公司產品的集成。現在主要的問題是，如果公司接受的是客戶委託授權的開發，同時又有與其他軟件集成的內容在裏面。那麼對於這個命名架購可能需要特別的考慮。如要分析一下，企業現有軟件所採用的命名架構。然後根據其採用的形式，來確定自己最終需要採用的命名結構。一般來說，在一個應用軟件或者一個項目中，最好採用同一種命名架購，如採用的都是Web命名協議等等。這就好像在不同版本的電話簿中，採用的是同一個目錄格式。這就會在很大程度上方便用戶的查詢。
其次需要注意的是，雖然JNDI命名服務採用都是基本固定的格式，即已經採用了標準化的手段。但是從實際工作來看，開發人員往往需要結合實際情況，做出適當的調整。如需要考慮，命名的合理性。包括可讀性、命名的長度等問題。雖然在具體的命名規則上，沒有很嚴格的限制。但是如果設計合理、細節考慮周到，那麼在很大程度上可以減少後續維護的壓力。如在一個項目團隊開發中，命名的規則需要經過項目成員的討論通過，然後再進行強化培訓。這對於後續項目成員按規則辦事會有很大的幫助。再如，現在不少應用軟件都是按模塊來開發的。此時在命名規則設計時，也需要考慮到模塊的分類。簡單的說，一個模塊一個目錄。不要將不同模塊的類存放在一起。這有利於後續應用軟件的升級、二次開發等等作業。總之，雖然命名服務的使用比較簡單，但是具體在設計時，還是有一定的難度。需要項目管理人員具有比較豐富的經驗。一個合理的命名規則，對於應用程序的開發很有幫助。
最後筆者需要強調的是，應用服務器定義的對象與用戶自己定義的對象的區別。爲了保障應用程序的正常運行，應用服務器往往會自動定義一些對象，如控制對象等等。而程序開發人員也會根據需要自定義相關的對象。這兩種不同的對象對於JNDI命名服務來說，有什麼區別呢?這裏需要注意的是，JNDI在後臺其採用的是多目錄的形式，如其最上一層的目錄是Java：Comp/env。後續的各種對象(包括應用服務器創建的和開發人員自己創建的)，都放在這個目錄下面。不過這裏需要注意的是，兩種不同形式創建的對象其所存放的目錄是不同的。應用服務器創建的對象一般是存放在頂級目錄中，一般目錄的位置不能夠改變。相反，用戶自定義的對象，則可以分別根據所建立對象的特點來分門別類的建立目錄。最常見的還是根據構件的類別和源代碼所處的模塊來建立目錄。這方便了用戶的查找。例如Ejb對象可以放在env/ejb目錄中。然後在這個目錄下面，再根據應用系統的模塊創建幾個子目錄，來進行分門別類的管理。
總之，JNDI命名服務採用了標準化與固定格式的手段，降低了技術門檻。與傳統的開發架購相比，簡化了類之間連接的管理，不需要通過很多的源代碼就可以實現類之間的調用。不過如果要使用好這個技術，也有不少的難度。筆者這裏講的難度，不是指技術上的。而是指經驗上的。如如果選擇合適的命名架構、設計合理的命名規則等等，這些都需要開發人員具有一定的項目背景。否則的話，很難做出正確的判斷。
