精彩的人生

??? ESB這個新名詞讓人感到既時髦又有點兒迷糊，它似乎正在被賦予許多自己不應承載的內容。那么，ESB究竟是什么呢？

??? 中間件到底是什么東西？ 它現在就好比是不斷將新思想一股腦兒澆在老方法上的一碗意大利面條。業界不斷將更多的調料澆在這碗面條上: 例如企業應用集成、企業信息集成、業務流程管理和面向消息的中間件等模糊概念。

??? 中間件食譜中的最新成份是時髦名詞——ESB（企業服務總線）。ESB現在已經成為一種市場誘惑，因為它承諾提供簡單、快速、基于標準的多點集成。如果現在翻開大多數中間件廠商的資料，就會發現有關ESB的文章真是長篇大論，但這些卻似乎讓新方法與老范例之間的界線更加模糊了。

??? 其實，ESB就是一種可以提供可靠的、有保證的消息技術的最新方法。ESB中間件產品利用的是Web服務標準和與公認的可靠消息MOM協議接口（例如IBM的WebSphere MQ、Tibco的Rendezvous和Sonic Software的SonicMQ）。ESB產品的共有特性包括：連接異構的MOM、利用Web服務描述語言接口封裝MOM協議，以及在MOM傳輸層上傳送簡單對象應用協議（SOAP）傳輸流的能力。大多數ESB產品支持在分布式應用之間通過中間層如集成代理實現直接對等溝通。

??? 廠商支持ESB的方式雖然各不相同，但是顯然這一種類產品的覆蓋面非常廣泛，包括了傳統MOM廠商以及中間件公司，例如Cape Clear、Fiorano、IONA、Polar Lake、SeeBeyond、SpiritSoft、Systinet和Vitria。任何廠商只要支持Java消息服務MOM或JMS API都可以將自己定位于ESB廠商。任何實現新興Web 服務可靠消息傳遞（WS-RM）規范的廠商也可以聲稱自己提供了ESB工具。

??? 當然，沒有一家ESB廠商滿足于只提供一條可靠的通道。因此，它們將各種東西投入到他們的ESB大鍋里，并且拼命地攪拌和翻炒。MOM、企業應用集成、業務流程管理、集成代理、指揮協調、數據轉換、發布與訂閱、事件通知、基于內容的路由、事務處理……它們都是ESB，至少廠商們會這么說。

??? 而企業的IT人員需要的是易于安裝、配置、執行和管理的集成產品。他們需要強大的、支持標準的、能實現任意對象之間集成的中間件。他們需要廉價而迅速地集成，而不是費時多年、高風險、耗費大量資金的大型集成。

??? 今天的ESB產品能夠提供這一切嗎？恐怕很難。問題的關鍵并不在于產品本身，而是那些已經在許多企業中扎根的多如牛毛的中間件產品、協議和方法。各公司為中間件和集成應用投入了太多的資金，以致于不可能在一夜之間將它們全部淘汰，再從頭開始。實際的集成環境基本上是采用多家廠商的中間件產品，其中許多中間件產品是在特殊戰略項目的環境下部署的，或用來集成特定的應用、平臺和協議集合。

??? 因此，大多數的公司并沒有單一企業范圍的“總線”，而這種總線也不可能很快問世。由于實際應用中的集成需求多得令人眼花繚亂，沒有一種ESB產品可以提供單一的解決方案。大多數企業所能做的就是在老環境難以應付的異構性上再覆蓋上一層基于標準的集成環境。

??? 總而言之，ESB術語只是一個有關MOM和基于SOAP的Web服務融合的籠統短語罷了。我們不應該賦予這個術語它所不能承載的更多含意。它只是連接我們整體盤子上中間件肉丸子的一種方法而已。?

??? ·相關鏈接·

??? 什么是ESB ?

??? 全稱為Enterprise Service Bus，即企業服務總線。它是傳統中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的連接中樞，是構筑企業神經系統的必要元素。

??? ESB的出現改變了傳統的軟件架構，可以提供比傳統中間件產品更為廉價的解決方案，同時它還可以消除不同應用之間的技術差異，讓不同的應用服務器協調運作，實現了不同服務之間的通信與整合。從功能上看，ESB提供了事件驅動和文檔導向的處理模式，以及分布式的運行管理機制，它支持基于內容的路由和過濾，具備了復雜數據的傳輸能力，并可以提供一系列的標準接口。

原文地址：http://www.soft6.com/news/detail.asp?id=12195

作者： 務實
Thursday, October 9 2003 2:57 PM

1、  概述
2、  JXTA的設計目標及有關概念
3、  JXTA協議
4、  JXTA應用與發展

一、概述

美國Sun公司自從1995年向世界推出了Java語言以來，每年都會在Java領域里推出新的技術，從JavaCard、J2ME到J2EE、JINI、JavaTV，推動了Java技術的發展和應用。在最近幾次的舊金山的JavaOne會議中，JXTA是該公司向業界推出的較新技術。該技術的目的是為P2P的網絡應用開發提供一個統一的平臺，而且為了鼓勵和支持該技術的發展，JXTA項目采用了開放源碼的方式，因此吸引了大量業界人士參與到JXTA技術的研究與應用當中，JXTA Community(www.jxta.org)就是人氣很旺的一個Java技術研究開發的網站。

JXTA最早起源于2000年的夏天，現在大家把JXTA看成是P2P的平臺，JXTA的目標是要解決幾個技術與商業上的難題。第一是解決眾多P2P系統互不相通的問題。2000年，是P2P突飛猛進的高潮年，但高潮背后卻是許多小公司用自己的封閉系統試圖在Internet上圈一塊地。Sun認為，只有互通才能真正發揮出P2P的優勢，就好像IM(Instant Messaging)，能互連的人越多，越有價值。所以Sun決定出面發布一個平臺，使所有P2P系統都能連接起來，只有Sun這樣位置中立、但在技術上有雄存實力被大家認可的公司才有希望做成這一平臺。

JXTA的另外一個目的就是找尋一套數量最少、概念最簡單的系統構成的“積木”。如果成功，這幾塊積木就會是今后大家構架信息系統的基本模塊，從而幫助人們擺脫像Windows或TCP/IP這樣的傳統軟件帶來的包袱。Java、Jini和JXTA像是J的三部曲，Java取自著名咖啡產地名，Jini是genie(精靈) 的諧音，而JXTA則是Juxtapose的縮寫。當時BillJoy用grep把所有J打頭的英文詞找出來，juxtapose躍然紙上，很是巧妙。既表現了P2P或肩并肩的意義，又說明JXTA不局限于P2P。但JXTA與眾不同，它是由一系列網絡協議構成的，用任何語言都可以實現，并不只限于Java，只有徹底獨立于操作系統、網絡傳輸技術以及程序設計語言，才真正達到了跨平臺，而這樣的技術，最容易受到業界的認同。

JXTA是項目創始人、Sun首席科學家BillJoy二十多年醞釀的結晶，“JXTA技術是網絡編程和計算的平臺，用以解決現代分布計算尤其是點對點(P2P)計算中出現的問題?！盝XTA研究項目，將提供使用戶更便捷地訪問連接在互聯網上的個人電腦資源的新框架，從而進一步拓展互聯網的空間。同時JXTA也是Sun的ONE互聯網戰略的延續，并且將更積極的姿態與Microsoft的.Net戰略和Hailstorm計劃一爭高低。Joy指出，JXTA可能是Sun One平臺最簡單的一部分，而不是打算將它變成象微軟的.Net那樣復雜的東西，而且JXTA也將是開放源代碼的團體；有別于而微軟的Passport和Hailstorm技術都是申請專利的專有技術，Sun希望通過公開JXTA源代碼的方式，成為微軟最有力的競爭對手，在公開源代碼的領域中，Linux和Apache是卓越的成功典范，Sun也希望JXTA能鑄造新的成功。

JXTA技術提供了基礎性的機制解決當前分布計算應用中面臨的問題，實現新一代統一、安全、互操作以及異構的應用。目前它支持基于Java技術的平臺和系統。而將來JATX技術將不受到內存的限制而支持更多小型移動設備。JXTA通過Java技術和XML數據表達的結合，提供了強大的功能使得垂直應用得以交互，并且可以克服目前P2P軟件中的限制。同時，通過小型、簡單、便于開發的構造模塊，JXTA將使開發者從建立各自框架的復雜工作得以解放，可以潛心關注于建設各類新穎、創造性的、分布式計算應用。

二、JXTA 的設計目標及有關概念

一）P2P技術

P2P即Peer to Peer,稱為對等連接或對等網絡，P2P技術主要指由硬件形成連接后的信息控制技術，其代表形式是軟件；P2P并不是一個新的概念，因特網上的許多核心協議本身就是P2P的應用程序，因特網的發展過程也說明了這一點，我們可以通過下述特性來描述P2P：

• Peer知道其他Peer的存在。
• Peer在一個虛擬的網絡中運行。
• Peer同時具有Client和Server的特點。
• 多個Peer可以組成為一個Peer組。

• Peer的獨立控制能力----用戶將變得非常強大，可以創建自己的組和虛擬網絡，而且可以非常容易地發布自己的資源。
• 可靠性----P2P系統是任何人都可以獲得的可靠系統。
• 擴展性----P2P系統的用戶數量可以急劇膨脹，可以與最大的集中式系統媲美。
• 性能----各種資源之間可以協同工作來有效地解決問題。

• JINI技術；
• 軟件代理(Agent)技術；
• JXTA的競爭者(Gnutella和Freenet等)；
• Web Services技術。

二）JXTA設計目標及層次結構

1、JXTA設計目標

首先，JXTA是為了構建P2P網絡而制訂的一組協議，是處理構建P2P網絡所碰到的問題的解決方法，JXTA標準協議規范介紹如下：

    “JXTA由六個協議組成，這些協議是專為特定的、分布式的、對等的網絡計算而設計的。使用這些協議，Peer可以互相合作來建立自我組織、自我管理的對等組，而不必關心它們在網絡中所處的位置(在網絡邊緣或者防火墻的后面)，并且也不需要集中的管理機構?！?/P>

   因此JXTA的核心是六個協議，其次，JXTA是P2P應用程序開發的運行平臺；目前JXTA首先推出了基于Java的參考實現，提供了支持六個協議的Java API，JXTA還將推出包括C語言在內的其他編程語言的API，JXTA在設計時有如下幾個目標：

• 操作系統無關
• 語言無關
• 為P2P應用提供服務和基礎

• 使用組來組織Peer并且在組內提供服務和應用的環境。
• 組可以使用認證和驗證方式來控制組內的訪問權限。
• 通過網絡來發布關于Peer和網絡資源的信息。
• 通過系統來發布各種請求。   
• 提供一個基礎平臺，供Peer之間做路由和通信。在防火墻或者其他障礙后面的Peer之間的通信也是這個目標中很關鍵的一部分。
• 提供一種機制允許Peer之間可以彼此監視狀態和資源。

• 系統應該允許任何設備直接加入到JXTA網絡中去。
• 系統應該允許ISP對網絡上的Peer進行集中管理。
• 系統應該支持數字產品版權的管理，例如購買的軟件、音樂CD、電影等。
• 封裝和抽象一些特定的核心功能，以便產生出商業方面的應用。

2、JXTA的層次結構

JXTA由三層組成，如圖1所示。第一層是JXTA核心層，它包含了服務所需要的核心功能；第二層是服務層，它提供了訪問JXTA協議的接口；第三層是應用層，它使用服務來訪問JXTA網絡和JXTA提供的功能。這樣的設計和一個標準的操作系統比較相似，標準的操作系統包括核心操作系統、服務和應用程序。

                                   圖1 JXTA的層次結構

各層的說明如下所示：

• 核心層(JXTA Core)：這一層封裝了最根本的東西，包括Peer、對等組、Peer發現、Peer通信、Peer監視和相關的安全原語。
• 服務層(JXTA Services)：這一層包括對于P2P網絡不是必需的、但很通用的功能，如查找、共享、索引、代碼緩存和內容緩存的機制。
• 應用層(JXTA Application)：這一層包括了應用JXTA服務開發出來的完整的P2P應用程序，例如myJXTA，JXTA-CAD等應用程序。

三）JXTA有關概念

  在JXTA網絡中，有一些概念是需要熟悉和理解的，它們是從JXTA協議中提出的一系列的專有名詞。

  1、Peer(對等機)

  Peer是一個虛擬的通信點。在一臺計算機或者設備上可以有很多個Peer，一個Peer并不是一個用戶，因為一個用戶可以有多個Peer，同一個設備上也可以有多個Peer(在測試的時候經常用到)。因為Peer不等同于用戶，所以需要將用戶和Peer抽象出來并分離開。

  Peer與特定的網絡服務聯系得很緊，在JXTA的參考實現中，Peer可以使用網絡提供的基本服務，例如rendezvous(集合點服務)，router(路由服務)，gateway(網關服務)等，這些基本服務又可以提供搜索和通信服務，一般來說，并不是所有的Peer都使用這些服務，它們只使用這些服務的一部分。

  2、PeerGroup(對等組)

  對等組是一種組織Peer并且發布組內的特定服務的方式。對等組可以被創建、加入和退出，在一個組里還可以更新一個組成員的關系，由于一些原因，對等組需要對成員關系進行一些限制，例如為了通信的安全、隱私的考慮等。這里使用一種協議來認證，它專門收集信息并判斷其是否符合成員關系的要求。

 對等組為應用程序提供了一種環境，例如對某個話題感興趣的Peer可以組成一個組，并且在組內使用一個聊天服務來討論。這樣，聊天的信息就會限制在那些加入到這個組內的成員之間。并且，對于想加入到這個組的Peer，可以使用成員ID來進行認證；沒有這個ID的Peer不能夠加人到組內，也就不能夠使用組內的聊天服務，也可以把對等組看成一個虛擬的私人網絡VPN，一個VPN只允許幾個計算機之間互相交流，而不允許因特網上其他的成員加入，由于VPN使用了加密的方式，對于偷聽者他們不能夠理解組內的談話，對等組也可以限制Peer的加入，同樣也可以對談話消息加密。

  3、Endpoint(端點)

 在JXTA應用中，端點是最基本的通信方法。一個端點就是實現了特定通信協議的Peer的地址。一個Peer可以有多個端點，這樣可以通過不同的協議來與其他Peer通信。

 端點不一定要是物理地址，端點可以允許物理地址發生變化。端點的一個簡單例子 就是一個IP地址加上一個端口。通過使用這些值，可以打開一個流并且與目標Peer通信。然而，JXTA在流的基礎之上又放置了一層，稱之為Pipe(管道)。這樣，不是將一個流連接到一個地址，而是把一個管道連接到端點上。端點和管道的好處在于，不用去關心Peer所使用的真正的地址和協議是什么。使用抽象出來的端點和管道，可以為創建P2P應用提供強大的功能并降低復雜性。由于管道使用通信協議來連接，端點描述了協議和連接的所需要的信息。因此端點可以描述HTTP、TCP、BEEP以及其他可以支持的通信協議。

 一個Peer可以支持一個或者多個端點。通過使用多種協議，Peer可以提供更有效率的方法。也就是說，如果兩個Peer都在防火墻的后面，可以直接通過它們的TCP端點來通信；如果兩個Peer要穿過防火墻去通信，則需要使用HTTP的端點。

 4、Pipe(管道)

 管道是Peer之間的虛擬通道，通常，我們認為對等通信是單個的通信連接，但是也并不是總是這樣的，因為防火墻和其他障礙的存在，許多Peer并不能直接連接，這時，管道更像一個在多種通信協議之上的虛擬層，可以通過起網關作用的Peer對通信提供中繼支持。

 管道是JXTA最基本、最重要的特性，它提供了一種很好的方案，使得Peer在大多數網絡情況下都可以通信，而不用去管防火墻或者其他的障礙，即使你不知道另外一個Peer的位置以及它所使用的協議等信息，通過管道仍然可以與之通信；管道作為一種抽象的方法，隱藏了一些細節，比如在多個連接的時候可能會有多個Peer參與進去，管道也可以重新定位，找到原來的Peer。在JXTA的參考實現中，有幾種常用到的管道，它們是：

• 單向異步----這種管道只用來做單向通信。管道是異步的，消息到達時可能不是順序的。這是JXTA平臺上最基本的一種類型的管道。
• 同步的請求/應答----所有發出的信息都會收到一個應答消息，消息到達的順序是按照它們發送時候的順序。
• 成批發送----用來發送大量的數據。
• 流傳送----通過流可以更有效地傳送諸如聲音、視頻等大量的數據。
• 雙向----它是兩個單向異步管道的組合。   
• 單向同步----所有發出的信息都會收到一個應答消息，消息到達的順序是按照它們發送時候的順序。
• 單向可靠安全的管道----所有發出的信息都會收到一個應答消息，并且這些消息都是加密的。

• 點到點類型----點到點的管道連接兩個不同的Peer?？梢允褂枚鄠€起網關作用的Peer來創建連接。
• 傳播類型----將一個Peer連接到多個目標Peer。

5、AdvertiSement(廣告)

     一個廣告就是一個XML文檔，它用來描述JXTA的消息、Peer、對等組或者服務等。廣告都遵守編碼、標簽和內容的標準，廣告用來交換JXTA網絡上可以獲得的任何信息。例如，一個Peer創建了名稱為“MyChat”的對等組后，就可以使用IP多播方式把廣告發布到本地的JXTA網絡；也就說，子網中的每一個Peer都會收到一份廣告的副本，此外廣告還會被發送到集合點去。

    Peer使用一種叫做集合點(Rendezvous)的特殊Peer來發現網絡上其他地方的廣告。集合點Peer可以存儲廣告并且支持搜索。Peer可以使用對等組的名字或者其他屬性來搜尋該對等組廣告。有了對等組的廣告，其他的Peer就可以使用廣告中的XML來實例化并加入到“MyChat”這個對等組中。一旦成為對等組的成員之后，Pear可以使用對等組的環境所提供的服務。

    廣告實際上是P2P網絡中的“名片”，P2P網絡中的任何資源，包括Peer、對等組、管道等都可以用廣告來描述，目前是在P2P網絡中標志資源，并且可以相互找到； 大多數JXTA廣告的編碼是使用UTF-8，它是對Unicode的一種ASCII編碼方式，UTF-8使用的是8位編碼，Unicode使用的是16位編碼，因此可以節省一半的空間，只有在消息體中間可能會使用到完全的Unicode編碼，在消息體里可以指定使用Unicode或者其他的字符集作為編碼方式。

6、Message(消息)

    在JXTA中，有兩種方式來處理消息。一種是使用XML格式，數據都遵循XML標準被包裝到消息里；另外一種是使用二進制格式。盡管希望對所有的JXTA消息都使用XML格式，可是由于大量的消息需要傳送，使用XML格式的消息會導致效率較低，而且由于消息通常是在程序之間傳送的，所以可以規范的消息內容使用二進制的格式；對于其他的仍然采用XML格式。

    在一個XML協議中使用二進制消息看起來似乎不太合理，但事實上使用二進制消息，除了可以得到緊湊的格式之外還有很多其他優點。首先數據可以使用一些標準技術進行壓縮，對文本等數據的壓縮可以節省大量的傳輸時間；另外，許多消息本身就是二進制的格式，例如文件共享程序中共享的文檔可能就是二進制的，因此可以直接使用二進制的格式；還有一個問題就是加密，為了加密可以把數據轉化成為二進制，然后直接使用二進制的消息來傳輸。

7、Rendezvous Peer(集合點)   

    一個集合點首先是一個Peer，而且是一個能夠處理來自其他Peer請求的Peer。集合點也可以將請求委托給其他Peer，當然那些Peer也必須是集合點。使用集合點的一個主要目的就是為了方便在本地網絡之外搜索廣告。集合點通常擁有更多資源，并且可以存儲大量的有關它周圍Peer的信息。

    集合點也可以作為搜索的傳遞者。集合點可以轉發發現請求到其他的集合點(原集合點通過與其他Peer的廣告交互而得到了被轉發集合點的信息)。每一個集合點如果本身沒有被請求的信息它都會轉發該請求。

                          圖2 通過集合點進行Peer搜索的過程

   圖2說明了一個典型搜索過程。遠程搜索從Peer1開始，它首先通過IP多播(IP Multicast)詢問本地的Peer2和Peer3，Peer2和Peer3很可能和Peerl處于同一個局域網內，所以很快收到了搜索請求。接下來，如果Peer2和Peer3沒有所搜索的特定資源，搜索將通過集合點進行，Peer1會向它的集合點Peer發出搜索請求，如果該集合點Peer也沒有所需的廣告信息，該集合點Peer會向它所知道的集合點Peer發出搜索請求。需要注意的是，除了和提出查詢請求的Peer處于同一局域網內的Peer收到查詢請求外，在局域網外只有集合點才會收到查詢請求。

    IP多播(IP Muhicast)是一個一到多的消息傳輸協議。IP多播用來發送數據的副本到一組地址。在P2P應用程序中，IP多播有兩個好處。首先，因為多播使用一個組地址而不是使用IP地址，一個Peer可以在不知道接收者地址的情況下發送消息。這樣做的結果是在多播網絡中的所有Peer都可以響應發出請求的Peer，將有關查詢的結果信息、甚至是自己的IP地址(用于與請求Peer直接通信)發送回去。

    IP多播的第二個好處是減少使用帶寬。因為所有的Peer都可以看到一個單一的消息，沒有必要向每一個Peer發送消息的一個副本。當發送大量的數據到一組Peer時，這一點是非常重要的。使用多播的一個缺點是一些防火墻和路由器會阻塞多播的消息。在因特網提供商之間通過因特網主干網可以支持多播消息，不過這種服務是需要額外付錢的。還存在其他IP多播的障礙，比如個人防火墻、子網路由器。這就是為什么JXTA不是僅僅支持IP多播的原因。一般情況下，只要在防火墻后能夠支持多播對于大多數的P2P網絡就足夠了。你可以這樣來利用本地的多播，先將消息發送到每一個網絡的某一個特定的Peer上，然后該Peer又通過本地的多播將消息發送給本地的Peer。

    只有集合點允許進行超出局域網的搜索。一個Peer可以選擇成為一個集合點，但這不是必須的，作為集合點好的一面是集合點可以緩存的形式保留從其他集合點得到的查詢結果的副本；不好的一面是，該Peer將占用很多的內存和帶寬。由于請求數量可能很多并且大量的廣告數據會消耗很多的計算機資源，在這種情況下我們可以選擇將計算機作為專用的集合點。集合點同時可以作為企業內部網的網關和路由器，其效果和使用傳統的路由器是一致的。在每一個子網內也需要使用一個集合點，是否選擇使用專用的集合點Peer取決于安全性的要求和使用的P2P應用的范圍。P2P網絡的拓撲結構需要通過多個的例子來進行測試并且需要定期監控。特別要注意的是：當P2P網絡的服務在大量Peer上存有副本時，P2P網絡的效率更高。有些時候并不是額外的集合點就可以提高網絡的效率。

    當一個Peer在搜索廣告時或者是其他服務使用集合點機制來路由消息時，集合點才被使用，因此一個Peer對集合點的需要不是持續的；為了能夠更好地發揮作用，一個連接到因特網的集合點最好盡可能地暴露給網絡上的多個Peer，在防火墻內把所有的Peer都配置為集合點不一定能夠發揮很大的作用。

8、RouterPeer(路由Peer)

    JXTA中的一個路由Peer是一個支持Peer端點協議的Peer，不是所有的Peer都需要實現該協議，因為和傳統的網絡路由器一樣，我們只需要少數幾個路由器去支持一個大網絡，JXTA路由器和傳統的路由器非常相像，最主要的區別是P2P不是非常固定并且包括了很多非靜態地址。

    9、GatewayPeer(網關Peer)

    JXTA中的一個網關Peer是一個作為通信中繼的Peer。網關Peer和集合點的不同之處在于，網關是用來在Peer間傳遞消息，而集合點是用來傳遞請求的，網關Peer就像是無線電轉發器或者說是Peer間的一個中介，它傳遞消息，因為有防火墻、NAT設備和代理服務器的存在，網關對網絡的連通具有決定性的作用，網關可以存儲消息，并且等待希望得到這些消息的接收者來收集它們。

    網關的存在是因為因特網非?；靵y。混亂的原因是有各種各樣的用于防止Peer間通過公用訪問方法通信的安全保障和障礙物，另一個原因是各個Peer所支持的協議是不同的，一些Peer可能使用TCP，另一些可能使用HTTP。在無線情況下，我們需要使用無線應用協議(WAP)，網關盡可能多地支持這些協議，因此它可以作為不同類型協議間的中介，JXTA目前支持TCP和HTTP，不過對其他協議的支持正在開發中。

    在因特網上網關是與大多數安全機制交互的關鍵，防火墻、代理服務器和NAT設備是主要的安全屏障。

圖3 通過網關對等機進行Peer間的通信

 

圖3說明網關Peer2是怎樣作為Peer1和Peer3之間的交互接口的。網關將從Peer1來的TCP消息轉換成HTTP消息傳遞給Peer3。當消息從Peer1發出時，是通過TCP發往網關Peer2，網關Peer2存儲了這個消息，直到Peer3向它發出獲得消息的HTTP請求。

三、JXTA協議

有六個協議構成了JXTA的核心，JXTA通過這六個協議來完成Peer之間的通信，彼此之間的資源的發布和發現，信息的傳遞和路由，協議本身并不是應用程序，需要添加更多的代碼來開發有用的應用，協議隱藏了很多細節，這樣使得編寫JXTA應用程序比從空白開發P2P應用要容易得多。

    JXTA在JXTA協議規范中定義了它的協議。此規范描述了Peer間如何通信和交互，它并未描述實現的細節或如何編寫P2P應用程序，下面是JXTA協議的列表，其中包含了協議名稱的首字母縮略詞，這六個協議如圖4所示。

圖4 JXTA的核心協議

 

    1、對等機發現協議Peer Discovery Protocol(PDP)：主要用來發布自己的廣告信息，并且從其他Peer處獲得廣告。PDP允許一個Peer發現其他Peer的廣告(包括Peer廣告、對等組廣告、服務廣告，或者是管道廣告)。該協議通過指定一種廣告類型(如Peer、對等組)、一個XML標簽名、一個匹配這個XML標簽所表示數據的字符串來定義查詢。它使用Peer Resolver Protocol來發送和傳播搜索廣告的請求。

    2、管道綁定協議Pipe Binding Protocol(PBP)：允許Peer之間建立虛擬的通信通道。

該協議首要關注的是通過Peer端點路由協議提供的路由連接Peer。它使用Peer Resolver  Protocol來發送和傳播搜索廣告的請求。

    3、對等機信息協議Peer Information Protocol(PIP)：用來獲得其他Peer的狀態信息，包括更新時間、狀態等等。該協議有時被用做ping命令，有時被用來獲得一個Peer的基本狀態信息，PIP消息的正文是自由格式的，它允許詢問特定的Peer信息。此外，這種能力可以被擴展以提供控制能力，它使用Peer Resolver Protocol來發送和傳播搜索廣告的請求。

    4、對等機解析協議Peer Resolver Protocol(PRP)：允許Peer發送更一般的請求，并可以接收到該請求的回應；同時可以將請求分發到組內的一個或者多個匹配的處理器，Peer解析協議是一個基礎通信協議，它按照一種請求/響應格式來進行，要使用這個協議，需要提供一個查詢的Peer和一個包含能被目標Peer理解的XML請求消息，該協議被用來支持JXTA中的其他協議(PDP、PBP和PIP)，而且允許傳播查詢，例如，如果一個Peer收到一個查詢并且不知道答案，解析協議就會將該查詢發送給別的Peer。

    5、端點路由協議Peer Endpoint Protocol(PEP)：通過該協議Peer以發送消息的形式獲得一條路由路徑。它使用Peer間的網關來建立一條包含一個或多個適合建立管道的管道協議組成的通路。管道綁定協議借助此Peer列表來建立Peer間的路由。一般情況下傳統的路由器和DNS服務器會因為防火墻、代理服務器和NAT設備等原因而無法建立連接，而端點路由協議通過尋找網關來穿越諸如防火墻等障礙來建立連接。端點路由協議還可以同時幫助相互不支持對方使用協議的Peer進行通信。例如，如果你連接支持TCP的Peer-A和只支持HTTP的Peer-B，端點路由協議既可以選擇一個可以支持此傳輸的網關，又可以選擇多個并且相互協議兼容的一組網關。

    6、集合點協議Rendezvous Protocol(RVP)：通過該協議Peer可以對一個服務訂閱或者被訂閱。集合點協議負責在JXTA對等組內傳播消息，它為Peer在組內接收和發送消息并且控制消息如何傳播定義了一個基本的協議。

    從編寫P2P應用程序的角度而言，可以簡單地劃分上述協議的主要用途：

• Peer Discovery----搜索資源
• Peer Resolver----一般查詢服務
• Peer Information----監控
• Pipe Binding----可尋址的消息傳遞
• Rendezvous----消息傳播
• PeerEndpoint----路由

四、JXTA的應用與發展

一）JXTA的應用

1、即時通信和文件共享(myJXTA)

myJXTA是在J2SE平臺上的一個JXTA演示程序，主要為展示JXTA項目和P2P的一些概念，它提供了一些功能，諸如安全的一對一的交談、組內的交談、組內文檔的共享、搜索和下載等。myJXTA使用JXTA平臺的核心服務，完成發現組、加入組和創建組的功能；還有在兩個Peer 間創建連接，完成一對一的交談；或者在組內建立連接，完成組內的交談以及組內文件的搜索和下載。該程序的主要目的是未了展示基于JXTA協議的P2P的工作方式。

2、網絡游戲(Chess)

    JXTA技術已在許多游戲應用方面得到了展示，一個互動式的國際象棋比賽的應用程序使用JXTA來傳遞兩個棋手間的對奕過程，并將它展現給觀眾，國際象棋游戲和“tic-tac-toe"游戲都可以用來展示JXTA在小型設備上的應用，一個游戲者可以創建一個新的JXTAPeer組并邀請全世界其他游戲者加入他的游戲，當然也可以限制他人進入他的游戲組。

3、協同工作

JXTA技術已經展示它在協同工作應用程序中的能力。用JXTA開發出來的集成開發環境可以允許一個以上的開發者同時開發一個軟件程序；另外一個協作式的JXTA應用程序允許幾個人同時編輯同一個電子數據表。其他JXTA項目中開發的合作開發工具包則利用了JXTA進行會話、共享瀏覽和文件共享。

    由于具有通話功能，JXTA技術在合作開發中擁有這樣一個優點：一個應用程序的開發不需依賴于服務器或其他中央管理系統。JXTA處理新發現的節點，并保證路線通暢，在用戶和交互式應用程序間交換消息。

4、聊天程序

JXTA非常適合編寫聊天程序，而且可以有多種實現方法，包括完全的集中式、代理方式到完全非集中式。而且一個非常有意思的情況是，用JXTA來實現一個集中式的聊天程序非常困難，而實現完全非集中式的聊天程序反而簡單，因為JXTA平臺本身已經完全解決了底層Peer之間的發現和通信問題。在現有的JXTA項目中已經有許多聊天程序的例子，包括myJXTA應用程序(原先稱為InstantP2P)、JXTA shell中的Talk命令、HotWire應用程序和其他幾個編程指南。

5、JXTA 社區

JXTA是一個開放源代碼的項目，它是由JXTA社區http://www.jxta.org在推動發展。在這個站點上可以獲取最新的JXTA文檔和程序代碼，而且你可以注冊并加入到正在進行中的JXTA項目，參與并推動項目的進展；這些項目分類存放，為用戶展示了JXTA各方面的功能；此外，站點上還有郵件列表，都是JXTA開發人員和P2P參與者就感興趣的問題的討論。

二）JXTA的發展

1、各種語言的實現

目前JXTA只有Java的實現版本，以至于大家談到JXTA都認為它是用Java開發的一套P2P框架，而忽略了JXTA的實質只是一套獨立于各種平臺和語言的協議。因此在各種語言上實現JXTA成為一項非常重要的工作。只有這樣，因特網上的用各種各樣語言實現的應用軟件就可以只需改寫網絡部分的代碼而轉換到JXTA平臺上來。這不但大大地節省了工作量，而且將會吸引大量因為各種原因無法采用Java語言的軟件加入到JXTA中來，從而大大促進JXTA協議的發展。現在正在進行的其他語言的實現有C，Perl，Python，Smalltalk等等，顯然這還遠遠不夠，也許我們將來需要看到用Pascal，VB，C#實現的版本。

2、各種平臺的實現

跨平臺，這是Java已經實現了的目標，但是并不表示JXTA就無事可做，一個真正的P2P網絡不僅僅是包括PC這個大家目前已經熟悉的設備，它還應該包含各種現在以及將來能夠連到因特網上的設備。頭一個目標顯然是PDA和手機這種移動設備，JXTA for J2ME以及PocketJxta都已經在進行中，而且已經可以使用；但是，我們還要考慮到將來的各種設備，這其中主要是各種各樣的嵌人式設備。如果這些設備都運行JXTA平臺，那么我們將看到一個真正的P2P世界。

3、各種應用

有好的應用，一個平臺是不可能流行起來的。目前在jxta.org上登記的應用開發項目有多個，相比現實世界中的各種網絡軟件的數目，這個數字實在是很小。目前的JXTA應用主要集中在即時通信和文件共享上面，這似乎成了P2P的代名詞。但是如果只局限于這些應用，JXTA的應用范圍將會很有限。

4、Service

Service在JXTA中扮演著極其重要的角色，所有JXTA協議的實現都是以Service的形式存在著的。除了幾個核心服務外，目前JXTA上有多個關于Service的項目正在開展著，從某種程度上來說，Service比Application更重要；如果沒有好的Service，也就產生不了多少好的應用，在這些進行中的Service中，Search是其中關鍵的環節，在沒有中心服務器的P2P網絡中，如何有效地進行查找成為一個關鍵問題，與此同時，還需做到盡可能地減少占用的帶寬。

作者：務實，多年從事J2EE網站及應用系統項目的開發和應用。

原文地址：http://www.zdnet.com.cn/developer/tech/story/0,3800067013,39174505-9,00.htm

Web service到底是什么；在什么情況下你應該使用Web service。

分布式應用程序和瀏覽器

研究一下當前的應用程序開發，你會發現一個絕對的傾向：人們開始偏愛基于瀏覽器的瘦客戶應用程序。這當然不是因為瘦客戶能夠提供更好的用戶界面，而是因為它能夠避免花在桌面應用程序發布上的高成本。發布桌面應用程序成本很高，一半是因為應用程序安裝和配置的問題，另一半是因為客戶和服務器之間通信的問題。

傳統的Windows富客戶應用程序使用DCOM來與服務器進行通信和調用遠程對象。配置好DCOM使其在一個大型的網絡中正常工作將是一個極富挑戰性的工作，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧愿忍受瀏覽器所帶來的功能限制，也不愿在局域網上去運行一個DCOM。在我看來，結果就是一個發布容易，但開發難度大而且用戶界面極其受限的應用程序。極端的說，就是你花了更多的資金和時間，卻開發出從用戶看來功能更弱的應用程序。不信？問問你的會計師對新的基于瀏覽器的會計軟件有什么想法：絕大多數商用程序用戶希望使用更加友好的Windows用戶界面。

關于客戶端與服務器的通信問題，一個完美的解決方法是使用HTTP協議來通信。這是因為任何運行Web瀏覽器的機器都在使用HTTP協議。同時，當前許多防火墻也配置為只允許HTTP連接。

許多商用程序還面臨另一個問題，那就是與其他程序的互操作性。如果所有的應用程序都是使用COM或.NET語言寫的，并且都運行在Windows平臺上，那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關系文件(VSAM)的形式存放，并由COBOL語言編寫的大型機程序訪問。而且，目前還有很多商用程序繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫?，F在，除了最簡單的程序之外，所有的應用程序都需要與運行在其他異構平臺上的應用程序集成并進行數據交換。這樣的任務通常都是由特殊的方法，如文件傳輸和分析，消息隊列，還有僅適用于某些情況的的API，如IBM的"高級程序到程序交流(APPC)"等來完成的。在以前，沒有一個應用程序通信標準，是獨立于平臺、組建模型和編程語言的。只有通過Web Service，客戶端和服務器才能夠自由的用HTTP進行通信，不論兩個程序的平臺和編程語言是什么。

什么是Web Service

對這個問題，我們至少有兩種答案。從表面上看，Web service 就是一個應用程序，它向外界暴露出一個能夠通過Web進行調用的API。這就是說，你能夠用編程的方法通過Web來調用這個應用程序。我們把調用這個Web service 的應用程序叫做客戶。例如，你想創建一個Web service ，它的作用是返回當前的天氣情況。那么你可已建立一個ASP頁面，它接受郵政編碼作為查詢字符串，然后返回一個由逗號隔開的字符串，包含了當前的氣溫和天氣。要調用這個ASP頁面，客戶端需要發送下面的這個HTTP GET請求：

http://host.company.com/weather.asp?zipcode=20171

返回的數據就應該是這樣：

21,晴

這個ASP頁面就應該可以算作是Web service 了。因為它基于HTTP GET請求，暴露出了一個可以通過Web調用的API。當然，Web service 還有更多的東西。

下面是對Web service 更精確的解釋： Web services是建立可互操作的分布式應用程序的新平臺。作為一個Windows程序員，你可能已經用COM或DCOM建立過基于組件的分布式應用程序。COM是一個非常好的組件技術，但是我們也很容易舉出COM并不能滿足要求的情況。

Web service平臺是一套標準，它定義了應用程序如何在Web上實現互操作性。你可以用任何你喜歡的語言，在任何你喜歡的平臺上寫Web service ，只要我們可以通過Web service標準對這些服務進行查詢和訪問。

新平臺

Web service平臺需要一套協議來實現分布式應用程序的創建。任何平臺都有它的數據表示方法和類型系統。要實現互操作性，Web service平臺必須提供一套標準的類型系統，用于溝通不同平臺、編程語言和組件模型中的不同類型系統。在傳統的分布式系統中，基于界面(interface)的平臺提供了一些方法來描述界面、方法和參數（譯注：如COM和COBAR中的IDL語言）。同樣的，Web service平臺也必須提供一種標準來描述Web service，讓客戶可以得到足夠的信息來調用這個Web service。最后，我們還必須有一種方法來對這個Web service進行遠程調用。這種方法實際是一種遠程過程調用協議(RPC)。為了達到互操作性，這種RPC協議還必須與平臺和編程語言無關。下面幾個小節就簡要介紹了組成Web service平臺的這三個技術。

XML和XSD

可擴展的標記語言(XML)是Web service平臺中表示數據的基本格式。除了易于建立和易于分析外，XML主要的優點在于它既是平臺無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。

XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎么去擴展這套數據類型。例如，整形數到底代表什么？16位，32位，還是64位？這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，并給出了一種語言來擴展這套數據類型。Web service平臺就是用XSD來作為其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，為了符合Web service標準，所有你使用的數據類型都必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換過程。在第二章中，我們將深入XSD，學習怎樣轉換自定義的數據類型(例如類)到XSD的類型。

SOAP

Web service建好以后，你或者其他人就會去調用它。簡單對象訪問協議(SOAP)提供了標準的RPC方法來調用Web service。實際上，SOAP在這里有點用詞不當：它意味著下面的Web service是以對象的方式表示的，但事實并不一定如此：你完全可以把你的Web service寫成一系列的C函數，并仍然使用SOAP進行調用。SOAP規范定義了SOAP消息的格式，以及怎樣通過HTTP協議來使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的數據編碼方式。第三章我們會討論SOAP，并結識SOAP消息的各種元素。

WSDL

你會怎樣向別人介紹你的Web service有什么功能，以及每個函數調用時的參數呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web

service。解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基于XML的語言，用于描述Web service及其函數、參數和返回值。因為是基于XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。

原文地址：http://lsz.c1c5.com/lsz/article.asp?id=55

2000上怎么做DNS

原文地址：http://ez.sm.fj.cninfo.net/ntclub/server/dns/dns-1.htm

安裝 DNS 服務器

打開 Windows 組件向導。
在“組件”中，單擊“網絡服務”，然后單擊“詳細信息”。
在“網絡服務的子組件”中，選擇“域名系統 (DNS)”復選框，單擊“確定”，然后并單擊“下一步”。
在“文件復制來源”中，鍵入 Windows 2000 分配文件的完整路徑，然后單擊“確定”。
所需的文件被復制到硬盤上，重新啟動系統后就可以使用服務器軟件了。

注意

要從桌面上打開 Windows 組件向導，請單擊“開始”，指向“設置”，并單擊“控制面板”。
控制面板打開時，雙擊“添加/刪除程序”，然后單擊“添加/刪除 Windows 組件”。

某些 Windows 組件要求在使用之前進行配置。如果安裝了一個或多個這樣的組件但沒有配置它們，當您單擊“添加/刪除 Windows 組件”時會顯示一個需要配置的組件列表。要啟動“Windows 組件向導”，請單擊“組件”。
強烈推薦您手動配置計算機以使用靜態 IP 地址。
安裝 DNS 服務器之后，您可以確定如何管理此服務器及其區域。盡管可以使用文本編輯器對服務器引導和區域文件進行更改，但并不推薦使用這種方法。DNS 控制臺簡化了這些文件的維護工作，而且應在可能的時候使用。一旦使用基于控制臺的文件管理，則不推薦手動編輯這些文件。
在使用 Active Directory 集成的區域的地方，不能使用基于文件的區域管理。
將 DNS 服務器引導和區域數據寫入文本文件時，Windows 2000 DNS 服務器使用被傳統 BIND 4 服務器識別的 Berkeley Internet Name Domain (BIND) 文件格式，而不是最新的 BIND 8 格式。

如何設置DNS服務器

原文地址：　?。?）假設本機還擁有如"192.168.0.90"和"192.168.0.91"的IP地址，也想要讓它們分別和"www.enanshan.com"及"nanshan.363.net"兩個域名對應起來。
    
    目標（1）的實現
　　（1）首先確保本機已安裝了DNS服務，則便可以選"開始→程序→管理工具→DNS"打開DNS控制臺管理器。
　　（2）在DNS管理器中，在"SERVER"（服務器名）上單擊右鍵，選"新建區域"以進入新建區域向導中。


　　（3）當向導提示到要讓選擇"區域類型"時，此處應選"標準主要區域"；而在"正向或反向搜索區域中"應選"正向搜索區域"。各步選擇之后都是單擊"下一步"繼續。
　?。?）隨后系統會詢問"區域名"，則在"名稱"后的文字框中輸入"ylwl.cn"；接著向導進入到"區域文件"提示窗口中，默認的，系統會自動選中"創建新文件，文件名為"一項，并在其后的文字框中自動填有"ylwl.cn.dns"（"ylwl.cn"部分即為上步所輸入的"區域名"）的名字。

　?。?）再根據系統提示選擇其默認各項之后即可完成此區域的建立。此時在DNS管理器左邊的"樹"欄中的"SERVER→正向搜索區域"里即可以看到"ylwl.cn"區域。
　?。?）接著在"ylwl.cn"區域上單擊右鍵，選"新建主機"，在其后的對話框中的"名稱"處輸入主機名"www"，"IP地址"處輸入IP地址"192.168.0.51"，再單擊"添加主機"按鈕，即成功地創建了主機地址記錄"www.ylwl.cn"，在"新建主機"窗口再選"完成"便可回到DNS管理器中。

　?。?）再在"ylwl.cn"區域上單擊右鍵，選"新建別名"，在其后的對話框中的"別名"處輸入"ftp"，"目標主機的完全合格的名稱"中輸入"www.ylwl.cn"（或用"瀏覽"逐步選擇），最后"確定"即可為"www.ylwl.cn"建立一個名為"ftp. ylwl.cn"的別名記錄。
　?。?）再用和上步相同的方法相同的方法來為"www.ylwl.cn"建立一個名為"ylwl.cn"的別名記錄，所不同的是，它建立時"名稱"一欄不用填，保持為空即可！
　　（9）以上全部記錄建立好之后，就可以在DNS管理器中看到相關的DNS映射記錄表。如果在"查看"菜單中勾選中"高級"一項，則表中"類型"一項就會由中文名（比如"主機"）改顯示為其英文名稱（比如"A"）。

　?。?0）剩下的工作就是檢驗工作的成效了！在Windows 2000的命令行提示符下（在"開始→運行"中輸入"cmd"進入）用"ping 域名"的命令行去測試，如果所建立的域名"www.ylwl.cn"、"ylwl.cn"和"ylwl.cn"均能顯示出連接的四行如"Reply from 192.168.0.51: bytes=32 time<10ms TTL=128"的響應，則恭喜你成功了！
    
     目標（2）的實現
　?。?）先把"enanshan.com"看作"區域"建立好之后，再在其下建立"www"的"主機"，將其IP地址對應到"192.168.0.90"即可。
　　（2）再把"363.net"看作"區域"建立好之后，再在其下建立"nanshan"的"主機"，將其IP地址對應到"192.168.0.91"即可。
　?。?）具體的*作和驗證方法請參照此前的相關內容施行。

原文：http://ldapman.org/articles/intro_to_ldap.html

原文作者：Michael Donnelly

翻譯：Brimmer

如果你在計算機行業工作，那么對LDAP可能早有耳聞了。想深入地了解LDAP嗎？那么可以好好地讀一下這篇文章。這篇介紹性的文章是一系列介紹如何在企業中設計、實現和集成LDAP環境的文章的頭一篇。主要是先讓你熟悉一下LDAP的基本概念，那些比較困難的細節問題將放到以后討論。在這篇文章中我們將要介紹：

什么是LDAP?

什么時候該用LDAP存儲數據？

LDAP目錄樹的結構

單獨的LDAP記錄

作為例子的一個單獨的數據項

LDAP復制

安全和訪問控制

現在LDAP技術不僅發展得很快而且也是激動人心的。在企業范圍內實現LDAP可以讓運行在幾乎所有計算機平臺上的所有的應用程序從LDAP目錄中獲取信息。LDAP目錄中可以存儲各種類型的數據：電子郵件地址、郵件路由信息、人力資源數據、公用密匙、聯系人列表，等等。通過把LDAP目錄作為系統集成中的一個重要環節，可以簡化員工在企業內部查詢信息的步驟，甚至連主要的數據源都可以放在任何地方。如果Oracle、Sybase、Informix或Microsoft SQL數據庫中已經存儲了類似的數據，那么LDAP和這些數據庫到底有什么不同呢？是什么讓它更具優勢？請繼續讀下去吧！

什么是LDAP?

LDAP的英文全稱是Lightweight Directory Access Protocol，一般都簡稱為LDAP。它是基于X.500標準的，但是簡單多了并且可以根據需要定制。與X.500不同，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP的核心規范在RFC中都有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網頁中找到。

怎么使用LDAP這個術語呢？

在日常交談中，你可能會聽到有些人這么說：“我們要把那些東西存在LDAP中嗎？”，或者“從LDAP數據庫中取出那些數據！”，又或者“我們怎么把LDAP和關系型數據庫集成在一起？”。嚴格地說，LDAP根本不是數據庫而是用來訪問存儲在信息目錄（也就是LDAP目錄）中的信息的協議。更為確切和正式的說法應該是象這樣的：“通過使用LDAP，可以在信息目錄的正確位置讀?。ɑ虼鎯Γ祿?。但是，也沒有必要吹毛求疵，盡管表達得不夠準確，我們也都知道對方在說什么。

LDAP目錄是數據庫嗎？

就象Sybase、Oracle、Informix或Microsoft的數據庫管理系統（DBMS）是用于處理查詢和更新關系型數據庫那樣，LDAP服務器也是用來處理查詢和更新LDAP目錄的。換句話來說LDAP目錄也是一種類型的數據庫，但是不是關系型數據庫。不象被設計成每分鐘需要處理成百上千條數據變化的數據庫，例如：在電子商務中經常用到的在線交易處理（OLTP）系統，LDAP主要是優化數據讀取的性能。

LDAP目錄的優勢

現在該說說LDAP目錄到底有些什么優勢了?，F在LDAP的流行是很多因數共同作用的結果。我在這里說的不過是一些基本的原因，請你注意一下這不過是一小部分原因。

可能LDAP最大的優勢是：可以在任何計算機平臺上，用很容易獲得的而且數目不斷增加的LDAP的客戶端程序訪問LDAP目錄。而且也很容易定制應用程序為它加上LDAP的支持。

LDAP協議是跨平臺的和標準的協議，因此應用程序就不用為LDAP目錄放在什么樣的服務器上操心了。實際上，LDAP得到了業界的廣泛認可，因為它是Internet的標準。產商都很愿意在產品中加入對LDAP的支持，因為他們根本不用考慮另一端（客戶端或服務端）是怎么樣的。LDAP服務器可以是任何一個開發源代碼或商用的LDAP目錄服務器（或者還可能是具有LDAP界面的關系型數據庫），因為可以用同樣的協議、客戶端連接軟件包和查詢命令與LDAP服務器進行交互。與LDAP不同的是，如果軟件產商想在軟件產品中集成對DBMS的支持，那么通常都要對每一個數據庫服務器單獨定制。

不象很多商用的關系型數據庫，你不必為LDAP的每一個客戶端連接或許可協議付費。

大多數的LDAP服務器安裝起來很簡單，也容易維護和優化。

LDAP服務器可以用“推”或“拉”的方法復制部分或全部數據，例如：可以把數據“推”到遠程的辦公室，以增加數據的安全性。復制技術是內置在LDAP服務器中的而且很容易配置。如果要在DBMS中使用相同的復制功能，數據庫產商就會要你支付額外的費用，而且也很難管理。

LDAP允許你根據需要使用ACI（一般都稱為ACL或者訪問控制列表）控制對數據讀和寫的權限。例如，設備管理員可以有權改變員工的工作地點和辦公室號碼，但是不允許改變記錄中其它的域。ACI可以根據誰訪問數據、訪問什么數據、數據存在什么地方以及其它對數據進行訪問控制。因為這些都是由LDAP目錄服務器完成的，所以不用擔心在客戶端的應用程序上是否要進行安全檢查。

LDAP對于這樣存儲這樣的信息最為有用，也就是數據需要從不同的地點讀取，但是不需要經常更新。例如，這些信息存儲在LDAP目錄中是十分有效的：

l        公司員工的電話號碼簿和組織結構圖

l        客戶的聯系信息

l        計算機管理需要的信息，包括NIS映射、email假名，等等

l        軟件包的配置信息

l        公用證書和安全密匙

什么時候該用LDAP存儲數據？

大多數的LDAP服務器都為讀密集型的操作進行專門的優化。因此，當從LDAP服務器中讀取數據的時候會比從專門為OLTP優化的關系型數據庫中讀取數據快一個數量級。也是因為專門為讀的性能進行優化，大多數的LDAP目錄服務器并不適合存儲需要需要經常改變的數據。例如，用LDAP服務器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的數據庫服務器。

如果下面每一個問題的答案都是“是”，那么把數據存在LDAP中就是一個好主意。

l        需要在任何平臺上都能讀取數據嗎？

l        每一個單獨的記錄項是不是每一天都只有很少的改變？

l        可以把數據存在平面數據庫（flat database）而不是關系型數據庫中嗎？換句話來說，也就是不管什么范式不范式的，把所有東西都存在一個記錄中（差不多只要滿足第一范式）。

最后一個問題可能會唬住一些人，其實用平面數據庫去存儲一些關系型的數據也是很一般的。例如，一條公司員工的記錄就可以包含經理的登錄名。用LDAP來存儲這類信息是很方便的。一個簡單的判斷方法：如果可以把保數據存在一張張的卡片里，就可以很容易地把它存在LDAP目錄里。

LDAP目錄樹的結構

LDAP目錄以樹狀的層次結構來存儲數據。如果你對自頂向下的DNS樹或UNIX文件的目錄樹比較熟悉，也就很容易掌握LDAP目錄樹這個概念了。就象DNS的主機名那樣，LDAP目錄記錄的標識名（Distinguished Name，簡稱DN）是用來讀取單個記錄，以及回溯到樹的頂部。后面會做詳細地介紹。

為什么要用層次結構來組織數據呢？原因是多方面的。下面是可能遇到的一些情況：

l        如果你想把所有的美國客戶的聯系信息都“推”到位于到西雅圖辦公室（負責營銷）的LDAP服務器上，但是你不想把公司的資產管理信息“推”到那里。

l        你可能想根據目錄樹的結構給予不同的員工組不同的權限。在下面的例子里，資產管理組對“asset-mgmt”部分有完全的訪問權限，但是不能訪問其它地方。

l        把LDAP存儲和復制功能結合起來，可以定制目錄樹的結構以降低對WAN帶寬的要求。位于西雅圖的營銷辦公室需要每分鐘更新的美國銷售狀況的信息，但是歐洲的銷售情況就只要每小時更新一次就行了。

刨根問底：基準DN

LDAP目錄樹的最頂部就是根，也就是所謂的“基準DN”?；鶞?/SPAN>DN通常使用下面列出的三種格式之一。假定我在名為FooBar的電子商務公司工作，這家公司在Internet上的名字是foobar.com。

o="FooBar, Inc.", c=US

（以X.500格式表示的基準DN）

在這個例子中，o=FooBar, Inc. 表示組織名，在這里就是公司名的同義詞。c=US 表示公司的總部在美國。以前，一般都用這種方式來表示基準DN。但是事物總是在不斷變化的，現在所有的公司都已經（或計劃）上Internet上。隨著Internet的全球化，在基準DN中使用國家代碼很容易讓人產生混淆?，F在，X.500格式發展成下面列出的兩種格式。

o=foobar.com

（用公司的Internet地址表示的基準DN）

這種格式很直觀，用公司的域名作為基準DN。這也是現在最常用的格式。

dc=foobar, dc=com

（用DNS域名的不同部分組成的基準DN）

就象上面那一種格式，這種格式也是以DNS域名為基礎的，但是上面那種格式不改變域名（也就更易讀），而這種格式把域名：foobar.com分成兩部分 dc=foobar, dc=com。在理論上，這種格式可能會更靈活一點，但是對于最終用戶來說也更難記憶一點?？紤]一下foobar.com這個例子。當foobar.com和gizmo.com合并之后，可以簡單的把“dc=com”當作基準DN。把新的記錄放到已經存在的dc=gizmo, dc=com目錄下，這樣就簡化了很多工作（當然，如果foobar.com和wocket.edu合并，這個方法就不能用了）。如果LDAP服務器是新安裝的，我建議你使用這種格式。再請注意一下，如果你打算使用活動目錄（Actrive Directory），Microsoft已經限制你必須使用這種格式。

更上一層樓：在目錄樹中怎么組織數據

在UNIX文件系統中，最頂層是根目錄（root）。在根目錄的下面有很多的文件和目錄。象上面介紹的那樣，LDAP目錄也是用同樣的方法組織起來的。

在根目錄下，要把數據從邏輯上區分開。因為歷史上（X.500）的原因，大多數LDAP目錄用OU從邏輯上把數據分開來。OU表示“Organization Unit”，在X.500協議中是用來表示公司內部的機構：銷售部、財務部，等等?，F在LDAP還保留ou=這樣的命名規則，但是擴展了分類的范圍，可以分類為：ou=people, ou=groups, ou=devices，等等。更低一級的OU有時用來做更細的歸類。例如：LDAP目錄樹（不包括單獨的記錄）可能會是這樣的：

    dc=foobar, dc=com

        ou=customers

            ou=asia

            ou=europe

            ou=usa

        ou=employees

        ou=rooms

        ou=groups

        ou=assets-mgmt

        ou=nisgroups

        ou=recipes

單獨的LDAP記錄

DN是LDAP記錄項的名字

在LDAP目錄中的所有記錄項都有一個唯一的“Distinguished Name”，也就是DN。每一個LDAP記錄項的DN是由兩個部分組成的：相對DN（RDN）和記錄在LDAP目錄中的位置。

RDN是DN中與目錄樹的結構無關的部分。在LDAP目錄中存儲的記錄項都要有一個名字，這個名字通常存在cn（Common Name）這個屬性里。因為幾乎所有的東西都有一個名字，在LDAP中存儲的對象都用它們的cn值作為RDN的基礎。如果我把最喜歡的吃燕麥粥食譜存為一個記錄，我就會用cn=Oatmeal Deluxe作為記錄項的RDN。

l         我的LDAP目錄的基準DN是dc=foobar,dc=com

l         我把自己的食譜作為LDAP的記錄項存在ou=recipes

l        我的LDAP記錄項的RDN設為cn=Oatmeal Deluxe

上面這些構成了燕麥粥食譜的LDAP記錄的完整DN。記住，DN的讀法和DNS主機名類似。下面就是完整的DN：

cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

舉一個實際的例子來說明DN

現在為公司的員工設置一個DN。可以用基于cn或uid（User ID），作為典型的用戶帳號。例如，FooBar的員工Fran Smith（登錄名：fsmith）的DN可以為下面兩種格式：

uid=fsmith,ou=employees,dc=foobar,dc=com

（基于登錄名）

LDAP（以及X.500）用uid表示“User ID”，不要把它和UNIX的uid號混淆了。大多數公司都會給每一個員工唯一的登錄名，因此用這個辦法可以很好地保存員工的信息。你不用擔心以后還會有一個叫Fran Smith的加入公司，如果Fran改變了她的名字（結婚？離婚？或宗教原因？），也用不著改變LDAP記錄項的DN。

cn=Fran Smith,ou=employees,dc=foobar,dc=com

（基于姓名）

可以看到這種格式使用了Common Name（CN）。可以把Common Name當成一個人的全名。這種格式有一個很明顯的缺點就是：如果名字改變了，LDAP的記錄就要從一個DN轉移到另一個DN。但是，我們應該盡可能地避免改變一個記錄項的DN。

定制目錄的對象類型

你可以用LDAP存儲各種類型的數據對象，只要這些對象可以用屬性來表示，下面這些是可以在LDAP中存儲的一些信息：

l        員工信息：員工的姓名、登錄名、口令、員工號、他的經理的登錄名，郵件服務器，等等。

l        物品跟蹤信息：計算機名、IP地址、標簽、型號、所在位置，等等。

l        客戶聯系列表：客戶的公司名、主要聯系人的電話、傳真和電子郵件，等等。

l        會議廳信息：會議廳的名字、位置、可以坐多少人、電話號碼、是否有投影機。

l        食譜信息：菜的名字、配料、烹調方法以及準備方法。

因為LDAP目錄可以定制成存儲任何文本或二進制數據，到底存什么要由你自己決定。LDAP目錄用對象類型（object classes）的概念來定義運行哪一類的對象使用什么屬性。在幾乎所有的LDAP服務器中，你都要根據自己的需要擴展基本的LDAP目錄的功能，創建新的對象類型或者擴展現存的對象類型。

LDAP目錄以一系列“屬性對”的形式來存儲記錄項，每一個記錄項包括屬性類型和屬性值（這與關系型數據庫用行和列來存取數據有根本的不同）。下面是我存在LDAP目錄中的一部分食譜記錄：

  dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com

  cn: Instant Oatmeal Deluxe

  recipeCuisine: breakfast

  recipeIngredient: 1 packet instant oatmeal

  recipeIngredient: 1 cup water

  recipeIngredient: 1 pinch salt

  recipeIngredient: 1 tsp brown sugar

  recipeIngredient: 1/4 apple, any type

請注意上面每一種配料都作為屬性recipeIngredient值。LDAP目錄被設計成象上面那樣為一個屬性保存多個值的，而不是在每一個屬性的后面用逗號把一系列值分開。

因為用這樣的方式存儲數據，所以數據庫就有很大的靈活性，不必為加入一些新的數據就重新創建表和索引。更重要的是，LDAP目錄不必花費內存或硬盤空間處理“空”域，也就是說，實際上不使用可選擇的域也不會花費你任何資源。

作為例子的一個單獨的數據項

讓我們看看下面這個例子。我們用Foobar, Inc.的員工Fran Smith的LDAP記錄。這個記錄項的格式是LDIF，用來導入和導出LDAP目錄的記錄項。

  dn: uid=fsmith, ou=employees, dc=foobar, dc=com

  objectclass: person

  objectclass: organizationalPerson

  objectclass: inetOrgPerson

  objectclass: foobarPerson

  uid: fsmith

  givenname: Fran

  sn: Smith

  cn: Fran Smith

  cn: Frances Smith

  telephonenumber: 510-555-1234

  roomnumber: 122G

  o: Foobar, Inc.

  mailRoutingAddress: fsmith@foobar.com

  mailhost: mail.foobar.com

  userpassword: {crypt}3x1231v76T89N

  uidnumber: 1234

  gidnumber: 1200

  homedirectory: /home/fsmith

  loginshell: /usr/local/bin/bash

屬性的值在保存的時候是保留大小寫的，但是在默認情況下搜索的時候是不區分大小寫的。某些特殊的屬性（例如，password）在搜索的時候需要區分大小寫。

讓我們一點一點地分析上面的記錄項。

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

這是Fran的LDAP記錄項的完整DN，包括在目錄樹中的完整路徑。LDAP（和X.500）使用uid（User ID），不要把它和UNIX的uid號混淆了。

  objectclass: person

  objectclass: organizationalPerson

  objectclass: inetOrgPerson

  objectclass: foobarPerson

可以為任何一個對象根據需要分配多個對象類型。person對象類型要求cn（common name）和sn（surname）這兩個域不能為空。persion對象類型允許有其它的可選域，包括givenname、telephonenumber，等等。organizational Person給person加入更多的可選域，inetOrgPerson又加入更多的可選域（包括電子郵件信息）。最后，foobarPerson是為Foobar定制的對象類型，加入了很多定制的屬性。

  uid: fsmith

  givenname: Fran

  sn: Smith

  cn: Fran Smith

  cn: Frances Smith

  telephonenumber: 510-555-1234

  roomnumber: 122G

  o: Foobar, Inc.

以前說過了，uid表示User ID。當看到uid的時候，就在腦袋里想一想“login”。

請注意CN有多個值。就象上面介紹的，LDAP允許某些屬性有多個值。為什么允許有多個值呢？假定你在用公司的LDAP服務器查找Fran的電話號碼。你可能只知道她的名字叫Fran，但是對人力資源處的人來說她的正式名字叫做Frances。因為保存了她的兩個名字，所以用任何一個名字檢索都可以找到Fran的電話號碼、電子郵件和辦公房間號，等等。

  mailRoutingAddress: fsmith@foobar.com

  mailhost: mail.foobar.com

就象現在大多數的公司都上網了，Foobar用Sendmail發送郵件和處理外部郵件路由信息。Foobar把所有用戶的郵件信息都存在LDAP中。最新版本的Sendmail支持這項功能。

  Userpassword: {crypt}3x1231v76T89N

  uidnumber: 1234

  gidnumber: 1200

  gecos: Frances Smith

  homedirectory: /home/fsmith

  loginshell: /usr/local/bin/bash

注意，Foobar的系統管理員把所有用戶的口令映射信息也都存在LDAP中。FoobarPerson類型的對象具有這種能力。再注意一下，用戶口令是用UNIX的口令加密格式存儲的。UNIX的uid在這里為uidnumber。提醒你一下，關于如何在LDAP中保存NIS信息，有完整的一份RFC。在以后的文章中我會談一談NIS的集成。

LDAP復制

LDAP服務器可以使用基于“推”或者“拉”的技術，用簡單或基于安全證書的安全驗證，復制一部分或者所有的數據。

例如，Foobar有一個“公用的”LDAP服務器，地址為ldap.foobar.com，端口為389。Netscape Communicator的電子郵件查詢功能、UNIX的“ph”命令要用到這個服務器，用戶也可以在任何地方查詢這個服務器上的員工和客戶聯系信息。公司的主LDAP服務器運行在相同的計算機上，不過端口號是1389。

你可能即不想讓員工查詢資產管理或食譜的信息，又不想讓信息技術人員看到整個公司的LDAP目錄。為了解決這個問題，Foobar有選擇地把子目錄樹從主LDAP服務器復制到“公用”LDAP服務器上，不復制需要隱藏的信息。為了保持數據始終是最新的，主目錄服務器被設置成即時“推”同步。這些種方法主要是為了方便，而不是安全，因為如果有權限的用戶想查詢所有的數據，可以用另一個LDAP端口。

假定Foobar通過從奧克蘭到歐洲的低帶寬數據的連接用LDAP管理客戶聯系信息?？梢越?/SPAN>ldap.foobar.com:1389到munich-ldap.foobar.com:389的數據復制，象下面這樣：

  periodic pull: ou=asia,ou=customers,o=sendmail.com

  periodic pull: ou=us,ou=customers,o=sendmail.com

  immediate push: ou=europe,ou=customers,o=sendmail.com

“拉”連接每15分鐘同步一次，在上面假定的情況下足夠了?！巴啤边B接保證任何歐洲的聯系信息發生了變化就立即被“推”到Munich。

用上面的復制模式，用戶為了訪問數據需要連接到哪一臺服務器呢？在Munich的用戶可以簡單地連接到本地服務器。如果他們改變了數據，本地的LDAP服務器就會把這些變化傳到主LDAP服務器。然后，主LDAP服務器把這些變化“推”回本地的“公用”LDAP服務器保持數據的同步。這對本地的用戶有很大的好處，因為所有的查詢（大多數是讀）都在本地的服務器上進行，速度非?？?。當需要改變信息的時候，最終用戶不需要重新配置客戶端的軟件，因為LDAP目錄服務器為他們完成了所有的數據交換工作。

安全和訪問控制

LDAP提供很復雜的不同層次的訪問控制或者ACI。因這些訪問可以在服務器端控制，這比用客戶端的軟件保證數據的安全可安全多了。

用LDAP的ACI，可以完成：

l        給予用戶改變他們自己的電話號碼和家庭地址的權限，但是限制他們對其它數據（如，職務名稱，經理的登錄名，等等）只有“只讀”權限。

l        給予“HR-admins”組中的所有人權限以改變下面這些用戶的信息：經理、工作名稱、員工號、部門名稱和部門號。但是對其它域沒有寫權限。

l        禁止任何人查詢LDAP服務器上的用戶口令，但是可以允許用戶改變他或她自己的口令。

l        給予經理訪問他們上級的家庭電話的只讀權限，但是禁止其他人有這個權限。

l        給予“host-admins”組中的任何人創建、刪除和編輯所有保存在LDAP服務器中的與計算機主機有關的信息

l        通過Web，允許“foobar-sales”組中的成員有選擇地給予或禁止他們自己讀取一部分客戶聯系數據的讀權限。這將允許他們把客戶聯系信息下載到本地的筆記本電腦或個人數字助理（PDA）上。（如果銷售人員的軟件都支持LDAP，這將非常有用）

l        通過Web，允許組的所有者刪除或添加他們擁有的組的成員。例如：可以允許銷售經理給予或禁止銷售人員改變Web頁的權限。也可以允許郵件假名（mail aliase）的所有者不經過IT技術人員就直接從郵件假名中刪除或添加用戶?！肮谩钡泥]件列表應該允許用戶從郵件假名中添加或刪除自己（但是只能是自己）。也可以對IP地址或主機名加以限制。例如，某些域只允許用戶IP地址以192.168.200.*開頭的有讀的權限，或者用戶反向查找DNS得到的主機名必須為*.foobar.com。

這不過是讓你了解一下可以對LDAP目錄進行怎樣的訪問控制，實際上真正實現起來需要做的工作比這多得多。在以后的文章中我會詳細地討論訪問控制。


原文地址：http://www.linuxaid.com.cn/engineer/brimmer/html/LDAP.htm