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命名服務採用了標準化與固定格式的手段，降低了技術門檻。與傳統的開發架購相比，簡化了類之間連線的管理，不需要通過很多的原始碼就可以實現類之間的呼叫。不過如果要使用好這個技術，也有不少的難度。筆者這裡講的難度，不是指技術上的。而是指經驗上的。如如果選擇合適的命名架構、設計合理的命名規則等等，這些都需要開發人員具有一定的專案背景。否則的話，很難做出正確的判斷。
