再提 Ubuntu/Debian 下 JAVA 中文顯示

posted @ 2008-05-31 22:17 狼愛上貍 閱讀(625) | 評論 (0) | 編輯 收藏

GT4中的globus-start-container和globus-stop-container所遇到的問題

By default globus-stop-container must be executed with the same credentials as the container it is running with. If the ShutdownService or the container is configured with separate private key and certificate files (usually /etc/grid-security/containercert.pem and /etc/grid-security/containerkey.pem) do the following to stop the container:

 $ grid-proxy-init -cert /etc/grid-security/containercert.pem \
-key /etc/grid-security/containerkey.pem \
-out containerproxy.pem
$ setenv X509_USER_PROXY containerproxy.pem
$ globus-stop-container
$ unsetenv X509_USER_PROXY
$ rm containerproxy.pem




上面這段話的含義是globus-stop-container使用和container一樣的證書來執(zhí)行該命令，這里使用

containercert.pem和containerkey.pem來生成一個containerproxy.pem，最后使用這個代理證書來關(guān)閉

container。如果你遇到說找不到/tmp/x509up-uuid（uid是你用來執(zhí)行g(shù)lobus-stop-container的用戶的uid）

文件的情況，可以試圖采用上面的方式來解決這個問題。

posted @ 2008-05-28 12:05 狼愛上貍 閱讀(888) | 評論 (6) | 編輯 收藏

網(wǎng)格開發(fā)人員：值得關(guān)注的組織和項目

級別： 初級

Edna Nerona (edna@legacystudios.biz), 顧問, Legacy Studios, Inc.

2007 年 8 月 09 日

之前，我們向您提供了一份 “網(wǎng)格開發(fā)人員推薦閱讀清單” 和 “面向網(wǎng)格開發(fā)人員的入門級開源工具”。現(xiàn)在我們又編著了一份代表網(wǎng)格計算未來發(fā)展的產(chǎn)品項目和組織清單。本文提供了在目前在不同領(lǐng)域（例如癌癥研究、天文學和物理學）中開展的項目的詳細清單。本文還介紹了工具包、安全性和數(shù)據(jù)管理。它們都是從各種在線資源獲得，向程序員、管理員和新用戶介紹了與使用、部署和開發(fā)網(wǎng)格基礎(chǔ)設(shè)施有關(guān)的具體信息和項目。

開發(fā)網(wǎng)格的組織

本節(jié)將介紹開發(fā)網(wǎng)格產(chǎn)品的組織，它們所解決的問題，以及它們是如何影響網(wǎng)格技術(shù)的。網(wǎng)格部署產(chǎn)品可以劃分為幾類：通用網(wǎng)格、科學和社區(qū)網(wǎng)格、國家網(wǎng)格、地區(qū)網(wǎng)格和大學網(wǎng)格。

國家和國際通用網(wǎng)格

Distributed European Infrastructure for Supercomputing Applications

作為一個領(lǐng)導國家超級計算中心的協(xié)會，DEISA（Distributed European Infrastructure for Supercomputing Applications）部署并操作了一個具有安全產(chǎn)品質(zhì)量的分布式超級計算環(huán)境。通過增強歐洲在高性能計算方面的能力，該研究組織促進了各種科學和技術(shù)領(lǐng)域中的科學發(fā)現(xiàn)。DEISA 對現(xiàn)有國家高端平臺進行了高度集成，使用了專用的網(wǎng)絡(luò)，并獲得了新型系統(tǒng)和網(wǎng)格軟件的支持。

DutchGrid

成立于 2000 年，DutchGrid 擁有很多成功的研究成果和計劃，跨越多個科學協(xié)作領(lǐng)域。作為一個學術(shù)和研究網(wǎng)格計算的開放平臺，DutchGrid 為荷蘭的網(wǎng)格用戶提供了可全球識別的身份證書。DutchGrid CA 是一個完全中立的項目。任何非盈利的研究人員和學術(shù)界用戶都可以獲得個人和服務(wù)器或主機證書來使用網(wǎng)格應(yīng)用程序。

Enabling Grids for E-science

Enabling Grids for E-science （EGEE）項目將來自 32 個國家的 90 多個機構(gòu)的科學家和工程師組織在一起，為科學家使用的電子科學（e-scinece）提供了一個無縫的網(wǎng)格基礎(chǔ)設(shè)施。EGEE 網(wǎng)格包含了超過 30,000 個 CPU，它們可以一周 7 天、每天 24 小時地使用，另外還提供了大約 5 PB（5 百萬個 GB）的存儲空間，平均要維護 30,000 個并發(fā)作業(yè)。擁有如此眾多的資源改變了科學研究所采用的方法。EGEE 是由歐盟建立的一個為期 4 年的項目。

Grid5000

Grid5000 項目的目標是建立一個高度可配置的具有可控性并可監(jiān)視的實驗網(wǎng)格平臺，網(wǎng)格研究人員可以使用它來試驗從網(wǎng)絡(luò)協(xié)議層到應(yīng)用程序?qū)又g的所有軟件。Grid5000 將法國地理上分布的 9 個城市連接在一起，提供了 5,000 個 CPU。這 9 個城市包括：Bordeaux、 Grenoble、 Lille、 Lyon、 Nancy、 Orsay、 Rennes、 Sophia-Antipolis 和 Toulouse。

LA Grid

LA Grid 的發(fā)音是 “lah grid”，它是第一個全面的計算網(wǎng)格，將來自美國、拉美和西班牙各個機構(gòu)的職員、學生和研究人員聯(lián)系在一起，協(xié)作開發(fā)可滿足醫(yī)療服務(wù)行業(yè)內(nèi)商業(yè)和社會需求的復雜行業(yè)應(yīng)用程序。除了大學之外，LA Grid 還吸引了全球工業(yè)界的參與，從而增強了在很多領(lǐng)域內(nèi)的創(chuàng)新，包括衛(wèi)生保健、生命科學和颶風災(zāi)難以及災(zāi)難防御。

Open Science Grid

Open Science Grid （OSG）是科學研究使用的一個分布式計算基礎(chǔ)設(shè)施。OSG 聯(lián)盟是惟一一個由各大學、國家實驗室、科學協(xié)作組織和軟件開發(fā)人員將海量計算和存儲資源組成一個共享的統(tǒng)一網(wǎng)絡(luò)基礎(chǔ)設(shè)施的聯(lián)盟。

TeraGrid

TeraGrid 是由 National Science Foundation 創(chuàng)建的一個開放科學研究基礎(chǔ)組織。將 9 個合作站點的業(yè)界領(lǐng)先的資源組合起來，TeraGrid 創(chuàng)建了一個集成的持久計算資源。通過采用國家專用網(wǎng)絡(luò)的一條高速千兆網(wǎng)絡(luò)彼此連接，TeraGrid 提供了超過 150 teraflops 的計算能力、以及接近 2 PB 的循環(huán)存儲空間、無數(shù)的科學數(shù)據(jù)集、專用的數(shù)據(jù)分析工具、科學網(wǎng)關(guān)、以及用來簡化對有價值資源和可視化資源訪問的用戶門戶。

科學和社區(qū)網(wǎng)格

AstroGrid

AstroGrid 是一個開源項目，它的建立是為英國和國際天文學家創(chuàng)建一個工作用的虛擬天文臺（Virtual Observatory，VO）。AstroGrid 是由英國政府建立，它通過 International Virtual Observatory Alliance （IVOA）與國際上其他 VO 項目緊密協(xié)作。作為這個社區(qū)的領(lǐng)導成員之一，AstroGrid 提供了國際通用的接口標準，用來促進天文數(shù)據(jù)的科學集成，并在全球范圍內(nèi)處理資源。

cancer Biomedical Informatics Grid

cancer Biomedical Informatics Grid （caBIG）是一個自發(fā)組織的網(wǎng)絡(luò)或網(wǎng)格，它將個人和機構(gòu)聯(lián)系在一起，可以共享很多數(shù)據(jù)和工具，它創(chuàng)建了一個全球范圍的癌癥研究資源。caBIG 的目標是為了加速癌癥預防和治療方面的創(chuàng)新方法的迅速問世。caBIG 所創(chuàng)建的基礎(chǔ)設(shè)施和工具在癌癥社區(qū)之外也有很廣泛的應(yīng)用。caBIG 目前正在 National Cancer Institute 的 Center for Bioinformatics 的領(lǐng)導下進行開發(fā)。

International Virtual Data Grid Laboratory

International Virtual Data Grid Laboratory （iVDGL）是一個全球的數(shù)據(jù)網(wǎng)格，用于物理和天文領(lǐng)域的前沿實驗。它的計算、存儲和網(wǎng)絡(luò)資源分布于美國、歐洲、亞洲和南美，提供了一個獨特的實驗環(huán)境，可用來測試和驗證國際的和全球范圍的網(wǎng)格技術(shù)。位于歐洲和美國的站點通過一個由 European DataTAG 項目創(chuàng)建的數(shù)千兆每秒的跨越大西洋的鏈接鏈接在一起。

World Community Grid

World Community Grid 的使命是創(chuàng)建全世界最大的公共計算網(wǎng)格，研究對人類有益的項目。World Community Grid 的成功在于：集合了個體為實現(xiàn)更美好的世界而貢獻出的未用的計算時間。World Community Grid 正在研究一些公共和非盈利組織才能使用的技術(shù)，從而開展一些人道主義研究；如果沒有公共網(wǎng)格，高昂的計算基礎(chǔ)設(shè)施將使研究無法完成。

Worldwide Large Hadron Collider Computing Grid

Worldwide Large Hadron Collider（LHC）Computing Grid 的目的是處理 2007 年前 CERN 的 LHC 所開展的實驗所產(chǎn)生的空前數(shù)據(jù)量。LHC 開展的實驗的計算需求極為龐大。每年大概會生成 12 到 14 PB 的數(shù)據(jù)，這大約相當于 2 千萬張 CD。對這些數(shù)據(jù)進行分析大約需要 70,000 臺目前最快的 PC。通過部署一個全球范圍的計算網(wǎng)格，將分布在歐洲、美國和亞洲的科學計算中心的資源集成到一個全球虛擬化計算服務(wù)中，LHC Computing Grid 可以滿足這些需求。

回頁首

美國地區(qū)的網(wǎng)格

Northwest Indiana Computational Grid

Northwest Indiana Computational Grid（NWICG）是來自 Purdue University-West Lafayette、 Purdue University-Calumet 和 University of Notre Dame 的合作研究和教育組織。NWICG 重點關(guān)注的是國家科學和研究活動，其創(chuàng)建的網(wǎng)絡(luò)基礎(chǔ)設(shè)施可以支持重大問題的解決方案，以及在高性能計算底層技術(shù)領(lǐng)域啟用保持世界領(lǐng)先的技術(shù)。它們正在 Department of Energy's Argonne National Laboratories 的協(xié)助下，在這 3 個大學之間為 Northwest Indiana 開發(fā)一個可擴充的高速、高帶寬的科學驅(qū)動計算網(wǎng)格。

SURAGrid

Southeastern Universities Research Association（SURA）是一個組織協(xié)作聯(lián)盟，它合并各種資源以將網(wǎng)格技術(shù)上升到無縫的共享基礎(chǔ)設(shè)施。SURAgrid 著重關(guān)注的是對大量分布式能力的直接訪問，從而用于研究和教育社區(qū)。SURAgrid 促進了以下領(lǐng)域的開發(fā)：所貢獻的資源、項目特有的工具和環(huán)境、高度專門化訪問、通往國家和國際的網(wǎng)絡(luò)基礎(chǔ)設(shè)施網(wǎng)關(guān)。

Texas Internet Grid for Research and Education

Texas Internet Grid for Research and Education （TIGRE）項目的使命是將整個得克薩斯州的計算系統(tǒng)、存儲系統(tǒng)、數(shù)據(jù)庫、可視化實驗和顯示以及儀器和傳感設(shè)備整合在一起，創(chuàng)建一個計算網(wǎng)格。通過集成強大的計算能力，為得克薩斯州在學術(shù)、政府以及工業(yè)界的研究人員提供增強的計算能力，TIGRE 希望能夠?qū)ι镝t(yī)學、能源和環(huán)境、航空宇宙、材料科學、農(nóng)業(yè)和信息技術(shù)的進步提供幫助。

回頁首

開源網(wǎng)格項目

這些網(wǎng)格項目覆蓋了很多領(lǐng)域，包括網(wǎng)格基礎(chǔ)設(shè)施工具包、中間件工具包、數(shù)據(jù)工具、安全等。下面給出了一些迅速發(fā)展的網(wǎng)格項目和工具。經(jīng)常訪問這些站點可以了解有關(guān)它們領(lǐng)導網(wǎng)格技術(shù)不斷發(fā)展的最新消息。

網(wǎng)格基礎(chǔ)設(shè)施項目

幫助建立自己網(wǎng)格的開源網(wǎng)格基礎(chǔ)設(shè)施項目。

Berkeley Open Infrastructure for Network Computing

Berkeley Open Infrastructure for Network Computing （BOINC）是項目使用的一個軟件平臺，例如 distributed.net 和 SETI@home，它使用了數(shù)百萬臺志愿者計算機組成一個并行的超級計算機。可以獲得該平臺的源代碼，并且鼓勵感興趣的 C++ 開發(fā)人員幫助開發(fā)平臺代碼。BOINC 目前可以支持 Windows®、Linux®、UNIX® 和 Mac OS X。 CPU 平臺的需求可能在使用 BOINC 的項目客戶機之間會有所不同。

Uniform Interface to Computing Resources

Uniform Interface to Computing Resources（UNICORE）提供了一個可隨時運行的網(wǎng)格系統(tǒng)，包括客戶機和服務(wù)器軟件。UNICORE 讓分布的計算和數(shù)據(jù)資源在內(nèi)部網(wǎng)和互聯(lián)網(wǎng)上以一種無縫的安全方式使用。UNICORE 設(shè)計的重點是幾個核心原則：無縫訪問異構(gòu)環(huán)境、安全性、站點自治、易于使用的強大的 GUI 客戶機，以及可以進行簡單安裝的快速啟動包。

網(wǎng)格中間件項目

以下項目已經(jīng)為美國和國際項目提供了一些高級工具，可以簡化訪問大量網(wǎng)格功能，例如計算、可視化和存儲資源。您可以與不同的網(wǎng)格進行交互，或者為自己的網(wǎng)格進行定制。

gLite

gLite 是網(wǎng)格計算使用的下一代中間件，它誕生于 12 個學術(shù)機構(gòu)和行業(yè)研究中心的 80 多個工作人員的聯(lián)合努力，是 EGEE 項目的一部分。gLite 充分利用分布在 Internet 上的計算和存儲資源，為構(gòu)建網(wǎng)格應(yīng)用程序提供了一個最佳框架。

National Research Grid Initiative

National Research Grid Initiative（NAREGI）位于日本，它著重于網(wǎng)格中間件的研究和開發(fā)，為廣泛分布的、高級研究和教育目的實現(xiàn)大規(guī)模的計算環(huán)境。

Ninf-G

Ninf 也是日本的一個項目，正在開發(fā)編程中間件，使用戶能夠通過一個簡單易用的接口來訪問各種資源，例如網(wǎng)格中的硬件、軟件和科學數(shù)據(jù)。Ninf-G 是一個開源軟件，支持開發(fā)和執(zhí)行分布式計算資源中使用 Grid Remote Procedure Call（GridRPC）的啟用網(wǎng)格的應(yīng)用程序。

NorduGrid

NorduGrid 中間件，也稱為 Advanced Resource Connector（ARC），是一個按照 GPL 許可發(fā)布的開源軟件解決方案，可以實現(xiàn)保證產(chǎn)品質(zhì)量的計算和數(shù)據(jù)網(wǎng)格。ARC 為基本網(wǎng)格服務(wù)提供了一個可靠實現(xiàn)，例如信息服務(wù)、資源查找和監(jiān)視、作業(yè)提交和管理、代理和數(shù)據(jù)管理，以及資源管理。大部分服務(wù)都是通過 GSI 的安全層提供的。中間件是在諸如 OpenLDAP、OpenSSL、SASL 和 Globus Toolkit（GT）之類的開源解決方案基礎(chǔ)上構(gòu)建的。

OGSA-DAI

OGSA-DAI 項目著重關(guān)注的是中間件的開發(fā)，從而有助于對網(wǎng)格中不同來源的數(shù)據(jù)進行訪問和集成。這個項目與 Globus、OMII-Europe、NextGRID、SIMDAT 和 BEinGRID 緊密協(xié)作，確保 OGSA-DAI 軟件可以在各種網(wǎng)格環(huán)境中很好地工作。

ProActive

ProActive 是 Java™ 網(wǎng)格中間件庫（其開源代碼具有 LGPL 許可），可用于進行并行、分布式和多線程計算。通過采用一個簡單元語的精簡集，ProActive 提供了一個詳盡的 API 來簡化網(wǎng)格計算應(yīng)用程序的編程，這些程序均分布在 LAN、工作站集群和 Internet 網(wǎng)格中。

安全項目

為了保護重要的基礎(chǔ)設(shè)施和信息，安全性需求一直以來都隨網(wǎng)格計算的發(fā)展而演變。這些項目代表了一些網(wǎng)格安全解決方案的一些最先進的安全標準和實現(xiàn)。

GridShib

GridShib 是在 NCSA 和 University of Chicago 之間開展的由 NFS 創(chuàng)建的項目，用來將聯(lián)合授權(quán)基礎(chǔ)設(shè)施（Shibboleth）與網(wǎng)格技術(shù)（Globus Toolkit）進行集成，從而為分布的科學社區(qū)提供基于屬性的授權(quán)。

Grid User Management System

Grid User Management System（GUMS）是一個網(wǎng)格身份映射服務(wù)（Grid Identity Mapping Service）。當站點資源不使用本地網(wǎng)格憑證，而是使用一種不同的機制來標識用戶時（例如 UNIX 帳號或 Kerberos 準則），就需要使用身份映射。

PRIvilege Management and Authorization

PRIvilege Management and Authorization（PRIMA）是一個提供增強的網(wǎng)格安全的系統(tǒng)。PRIMA 是一個全面的網(wǎng)格安全模型和系統(tǒng)。在 PRIMA 中，特權(quán)是一種與平臺無關(guān)的、細粒度權(quán)限的自包含表示。PRIMA 通過從資源內(nèi)部表示來具體化對資源對象的細粒度訪問權(quán)限實現(xiàn)了特權(quán)的平臺無關(guān)性。

資源管理和調(diào)度

網(wǎng)格的一個基本部分就是在資源之間管理和調(diào)度作業(yè)。下面這些項目展示了有關(guān)的一些策略。

Community Scheduler Framework

Community Scheduler Framework（CSF）是一個基于 OGSA 的元調(diào)度器的開源實現(xiàn)。它可以支持最新的 WS-Agreement 規(guī)范和 Globus Toolkit 的 GRAM 服務(wù)。CSF 填補了現(xiàn)有資源管理現(xiàn)狀的不足，并集成了 Platform LSF 和 Platform Multicluster。CSF 開源項目已經(jīng)包括到了 Globus Toolkit V4.0 發(fā)行版中。

Special Priority and Urgent Computing Environment

高性能建模和仿真在決策制定和預測方面起到了推動作用。對于時間關(guān)鍵型的應(yīng)急應(yīng)用程序，例如災(zāi)害天氣預報、洪水建模、流感建模，任何延時會使結(jié)果變得毫無用處。這需要使用專用的基礎(chǔ)設(shè)施快速、自動而且可靠地提供計算資源。Special Priority and Urgent Computing Environment（SPRUCE）是一個用來在傳統(tǒng)超級計算機和分布式網(wǎng)格上支持緊急或事件驅(qū)動計算的系統(tǒng)。

網(wǎng)格資源監(jiān)視

對資源和應(yīng)用程序的監(jiān)視是網(wǎng)格成功的關(guān)鍵。通過一個簡單易用的接口，這些復雜工具可以幫助用戶搜集、分類和監(jiān)視各種類型的資源。另外，系統(tǒng)管理員還可以監(jiān)視網(wǎng)格的健康狀況。這些不斷發(fā)展的網(wǎng)格項目列出了幾個開源選擇。

GridCat

GridCat 是一個在地理圖上使用狀態(tài)點以及編目的高級網(wǎng)格編目系統(tǒng)。這個圖可以幫助調(diào)試站點問題。編目中包含了有關(guān)站點的準備信息，以及每個站點的很多其他有價值的信息，幫助應(yīng)用程序用戶和網(wǎng)格調(diào)度器開發(fā)人員進行作業(yè)提交和作業(yè)調(diào)度。GridCat 嘗試在其最簡單的狀態(tài)表示中表示網(wǎng)格站點。

Gridscape II

Gridscape II 是一個定制的門戶組件，可以在其自身的網(wǎng)格門戶中使用，也可以插入到現(xiàn)有網(wǎng)格門戶中。Gridscape II 負責從各種異構(gòu)和分布式資源中搜集信息，并在單個界面中無縫地將它們呈現(xiàn)出來。它充分利用了 Google Maps API 來提供一個高交互性的用戶界面。Gridscape II 非常簡單易用，為那些不希望大量投資以從頭開始開發(fā)自己的監(jiān)視門戶的用戶提供了一個解決方案，也為那些希望簡化定制內(nèi)容的用戶提供了一種解決方案。

存儲和數(shù)據(jù)管理

從開源高性能文件系統(tǒng)到無縫地訪問異構(gòu)環(huán)境中的數(shù)據(jù)，以下項目集合了各種存儲和數(shù)據(jù)管理解決方案并進行了優(yōu)化。這種趨勢強調(diào)的是資源之間的數(shù)據(jù)存儲、管理和移動，以及通過網(wǎng)絡(luò)對數(shù)據(jù)資源的連接。

Lustre

Lustre File System，這是一個來自 Cluster File Systems Inc. 的高性能開源文件系統(tǒng)，它是一個分布式文件系統(tǒng)，消除了很多傳統(tǒng)分布式文件系統(tǒng)中存在的性能、可用性和可伸縮性問題。Lustre 是一個高度模塊化的下一代存儲架構(gòu)，它將現(xiàn)有的開放標準、Linux 操作系統(tǒng)和創(chuàng)新協(xié)議組合成一種可靠的、網(wǎng)絡(luò)中立的數(shù)據(jù)存儲和檢索解決方案。通過在集群和數(shù)據(jù)共享環(huán)境中提供高 I/O 吞吐量，Lustre 還提供了與物理存儲上的數(shù)據(jù)位置無關(guān)的獨立性，防止單點失效，并且可以從集群的重新配置和服務(wù)器或網(wǎng)絡(luò)故障中快速恢復。

NeST

NeST 是一個軟件網(wǎng)絡(luò)存儲設(shè)備，為特定時間段提供了安全的存儲分配。分配單元或份額（lot）的大小和持續(xù)時間可以在 NeST 和用戶或應(yīng)用程序之間進行協(xié)商。這些份額的大小也可以擴充，時間可以擴展，或者劃分成不同的層次。另外，NeST 還為份額和文件訪問提供了訪問控制列表。NeST 提供了多種協(xié)議接口，包括內(nèi)部使用的 Chirp、HTTP 和 GSI-FTP。

SAMGrid

SAMGrid 是一個通用數(shù)據(jù)處理系統(tǒng)，它被設(shè)計為用來測試大量數(shù)據(jù)（PB 級）集和廣泛分布的產(chǎn)品和分析工具的一個關(guān)鍵設(shè)備。當前產(chǎn)品的組件提供了大量的服務(wù)，可用于分布式系統(tǒng)中的數(shù)據(jù)傳輸、數(shù)據(jù)存儲和進程記錄。

UberFTP

UberFTP 是在 GridFTP 基礎(chǔ)上構(gòu)建的，它是第一個啟用 GridFTP 的交互式 FTP 客戶機。基本的 GridFTP 客戶機不是可交互式的，它一次只允許傳輸一個文件。UberFTP 提供了交互式工具，工作方式與流行的 NCFTP 工具類似。它支持 GSI 認證、并行數(shù)據(jù)通道以及第三方傳輸功能。

回頁首

結(jié)束語

網(wǎng)格計算是最令人興奮的技術(shù)之一，它在很大程度上影響了我們解決復雜問題和共享各種資源的方式。除了癌癥和物理學之外，它對于安全和認證、查找、監(jiān)視、信息服務(wù)、數(shù)據(jù)管理、資源管理和調(diào)度也有重大影響。

參考資料

學習

• 您可以參閱本文在 developerWorks 全球網(wǎng)站上的 英文原文。
  
  
• 查看 developerWorks 中的 “網(wǎng)格計算文檔庫”。
  
  
• 要收聽面向軟件開發(fā)人員的有趣訪談和討論，請查看 developerWorks podcasts。
  
  
• 隨時關(guān)注 developerWorks 的 developerWorks 技術(shù)活動和網(wǎng)絡(luò)廣播。
  
  
• 了解世界范圍內(nèi)面向 IBM 開源開發(fā)人員的即將召開的會議、商業(yè)展示、webcasts 和其他 事件。
  
  
• 請訪問 developerWorks 中國網(wǎng)站開源軟件技術(shù)專區(qū)，這里有豐富的 how-to 信息、工具和項目更新信息，可以幫助您使用開源技術(shù)進行開發(fā)，并與 IBM 產(chǎn)品一起使用。
  
  

獲得產(chǎn)品和技術(shù)

• 請下載 IBM 產(chǎn)品評測版，嘗試使用來自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的應(yīng)用程序開發(fā)工具和中間件產(chǎn)品。
  
  
• 使用 IBM 試用軟件 改進您的下一個開源開發(fā)項目，這些軟件可以從 developerWorks 下載或從 DVD 獲得。

討論

• 請訪問 developerWorks 上的 網(wǎng)格計算論壇。
  
  
• 通過參與 developerWorks blogs，加入 developerWorks 社區(qū)。
  
  

關(guān)于作者

		Edna Nerona 是 Legacy Studios，Inc. 的所有人，這是一家位于 San Diego 的創(chuàng)新服務(wù)公司。她擁有 San Diego State University 的新聞學學士學位，曾經(jīng)在 San Diego Supercomputer Center 和 Entropia，Inc. 工作過。她還是 Toastmasters International 的一名多才多藝的發(fā)言人。

來自: http://www.ibm.com/developerworks/cn/grid/gr-gridorgs/

posted @ 2008-05-23 10:55 狼愛上貍 閱讀(548) | 評論 (0) | 編輯 收藏

羽球服裝及附件

羽球服裝及附件：

羽毛球服裝選擇相對容易了很多。但不是任何運動衫都有資格可以成為羽毛球衣。選擇的時候還是要有一些原則的。不要選擇純棉的衣服，因為純棉的衣服雖然吸汗，但是能力有限，并且不容易蒸發(fā)，隨著汗水的吸收，自重會加大，到最后會貼在身上，非常的不舒服。夏季不要選擇滌棉的衣服，滌棉的衣服雖然比純棉舒服了很多，但天氣炎熱的時候還是會出現(xiàn)與純棉服裝一樣的結(jié)果。冬季如果不是在非常溫暖的地區(qū)，選擇滌棉服裝會提高保暖性能。不要選擇過于貼身的衣服。過于貼身的衣服有可能會限制球員的運動范圍，打球的時候會不太舒服。要選擇輕量化服裝。并不是每一件衣服都會像知名品牌羽球服裝那樣的輕盈。進行羽毛球運動時，最好還是穿著專門的羽毛球品牌服裝，或是針對羽毛球運動的特點而開發(fā)出來的服裝。YONEX的衣服具有加熱降溫功能。夏天和冬天分別能提供低3度和高3度的感覺，是羽球服裝的精品。選擇運動短褲時要選彈性大的，因為羽毛球運動經(jīng)常需要球員以蹬跨步移動，一件有彈性的運動短褲可以使動作更舒展而不必擔心對服裝構(gòu)成任何傷害。

羽球服裝特點簡述：

YONEX：

YONEX品牌的服裝上鏡率最高。其特點也比較明顯。材料大致分兩大類，特殊功能性纖維和普通功能性纖維。

普通功能型纖維就是常見的YONEX 100％滌綸（polyster）的產(chǎn)品。這里要特別說明的是，有很多走私水貨的YONEX服裝，或假冒的YONEX服裝，都是滌＋棉的。這種衣服的排水性和蒸發(fā)汗水能力都遠差于正品行貨。在天氣較熱出汗量較大時穿著，衣服會因含有棉的成分而粘貼在身上。令人非常難受。但因其售價低廉，還是可以迎合一小部分人的消費需要。SHBC不推薦穿著這樣的服裝上場打球，如果真的不愿意花很多錢來購買YONEX品牌的服裝，還有KASON服裝可供選擇。KASON的服裝也有100％滌綸（polyster）的，在提供了較低價格的同時，保證了羽球服裝應(yīng)有的性能。

特殊功能性纖維指的是YY的HEAT CAPSULE(熱囊)和VERY COOL(冷卻)纖維。這兩種材料成分標識其實也是100％滌，但所用的材料與普通的YONEX服裝不同，VERY COOL服裝一般在領(lǐng)子后面的吊牌下方都會帶有VERY COOL的標記，比較好辨認。 需要注意的是，SP版的衣服使用了一種叫做TRUE COOL的標記，TRUE COOL的標記與VERY COOL類似，但所謂的TRUE COOL是100％棉生產(chǎn)的，這種衣服很明顯是根本不值得購買的。且棉產(chǎn)品容易起皺，放在球包內(nèi)擠壓后穿著會比較難看。

VERY COOL和HEAT CAPSULE可以提供升高三攝氏度或降低三攝氏度的體表感受，在適當?shù)募竟?jié)穿著相應(yīng)特性的產(chǎn)品打球，是非常舒適的。因其功能特殊，價格較一般產(chǎn)品貴了不少。約為普通功能型纖維衣物的1.5-2倍，但因其舒適性出色，還是很受歡迎的。

VICTOR(勝利）的服裝以及KASON（凱勝）的服裝雖然品牌不如YONEX那么出名，但衣服的質(zhì)量是不錯的。尤其是VICTOR的服裝，06年的設(shè)計非常新穎，色彩也很討好。一樣是排汗速干面料，不是非常追求品牌的話，穿起來一樣很舒服。

其他還有如BONNY(波力）的銀纖維，竹炭纖維也是很不錯的衣服，只是設(shè)計實力略欠缺，如果能買到心儀的款式，也是很好的選擇。

羽毛球襪：

很多人覺得自己的襪子已經(jīng)夠厚了，沒必要花幾十塊去買一雙名牌羽球襪，就算是KASON,FLEX等品牌，一雙襪子也要二十元以上，其實這種想法是不對的。再厚的襪子，也很難比的上專業(yè)羽球襪的厚度。很多對此想法持懷疑態(tài)度的人，在親手摸過羽毛球襪以后，往往會立刻購買。足見普通加厚運動襪與專業(yè)羽球襪的區(qū)別。

勿庸置疑，YONEX的VERY COOL羽毛球襪是穿著最舒適的羽毛球襪了。關(guān)于VERY COOL，這里就不再多說了。價格要比一般的襪子略貴一些，有條件的話這是第一選擇。

其他品牌如VICTOR,KASON,FLEX的襪子質(zhì)量基本相同，價格低但是品質(zhì)不低，也都可以起到良好的保護作用。只是沒有VERY COOL那么舒服。

需要注意的是，一雙正品羽毛球襪的厚度大致相當于半碼鞋，考慮到運動中雙腳會繼續(xù)充血膨脹，買鞋最好大1碼。

來自：http://www.shbc.cn/dispbbs.asp?boardID=307&ID=40224&page=1

posted @ 2008-05-19 16:08 狼愛上貍 閱讀(212) | 評論 (0) | 編輯 收藏

羽毛球拍選購

羽毛球拍：

拍子的選擇是目前球友們最關(guān)心的一個問題了。在上羽網(wǎng)論壇上每天要有很多次發(fā)言是與球拍的選擇有關(guān)的。雖然球拍是一個很重要的部分，但在實際運動中，球拍的重要性被夸大了不少。需要強調(diào)的是，一把好的球拍可以給使用者以信心，但是根本不可能提高使用者自身的水平。

目前幾乎所有的球拍都是碳素，石墨復合材料制成的。有些生產(chǎn)商喜歡加一些特殊的材料如TI金屬網(wǎng)，KEVLAR（凱芙拉），納米復合材料。需要著重說明的是，這些附加材料只占了總材料的一少部分，一支球拍的99％以上始終還是這種碳素石墨復合材料。附加材料帶給球拍性能的改變并不會是非常明顯的,但確實有效。

羽毛球拍是球員和球之間的“中介”，由以下幾種特性來分類：形狀，硬度，重量，平衡點。

目前的球拍主要有兩種形狀：圓頭拍和方頭拍。圓頭拍就是傳統(tǒng)的拍形，拍頭上部略尖，球拍整體呈卵形。這種卵形球拍甜區(qū)較小，但甜區(qū)部位力量爆發(fā)非常的集中。圓頭拍對初學者來說較難上手。目前此類拍頭的球拍型號已經(jīng)不是很多了。方頭拍(ISO拍面)是后起之秀，因其甜區(qū)巨大在90年代初期后迅速風靡全球。

球拍的硬度類似于拍線的拉力大小。越硬的球拍需要越大的力量驅(qū)動，反之亦然。

球拍的重量是多樣化的。常見的球拍重量范圍一般在80－95克。同拍柄尺寸單位一樣，不同的廠商有各自的重量單位定義，但是最流行的就是YONEX公司所使用的U系統(tǒng)。U＝95－100克，2U＝90－94克，3U=85-89克，4U＝80－84克，5U＝79－75，一般常用的球拍基本上都是2U-4U，79克以下的一般都叫做超輕拍，主要是設(shè)計給女性，或有特殊需要的球友。而95克以上的一般都是金屬拍，主要是給以打羽毛球為健身手段而不愿在器材上花費過多的人。

球拍的重量決定了揮拍速度。使用同樣的揮拍力量，越輕的球拍可以產(chǎn)生越高的揮拍速度。簡單來說，越輕的球拍使用起來越靈活。但是球拍并不是越輕越好的，因為越輕的球拍就越不穩(wěn)定，需要越多的力量保持其運動軌跡。重一些的拍子在揮動時可以帶有更多的動能，擊球瞬間可以產(chǎn)生更大的勢能。這就是為什么很多進攻型的拍子頭都會比較重的原因。

球拍的平衡點決定了一支球拍的重量分部情況。目前市場上的很多球拍都已經(jīng)是頭重型的了，頭重型的球拍在揮動時可以更加的穩(wěn)定，而平衡型球拍更靈活一些。

球拍的選擇是非常個性化的，沒有任何人可以說某種球拍的某種特性就一定強過另一種。選擇球拍可以參考一些專業(yè)意見，但最終如何選擇還是要由自己來決定。

YONEX球拍特點：

NS系列 NS系列目前成員有NS6000，NS7000，NS8000。

NS6000的拍桿較軟，帶有LSC減震系統(tǒng)，是YONEX于2006年推出的專為女性設(shè)計的球拍。該拍拍身較柔軟，ISO（小平頭）拍面，適合女性使用。

NS7000，此拍是為中高級業(yè)余選手設(shè)計的。采用8mm粗桿，桿身彈性很好，拍頭采用破風設(shè)計，ISO中型拍面，用于防守時非常輕松。平抽擋能力低于NS8000，MP-100等。由于平衡點適中，驅(qū)動輕松，所以拉后場球比較容易。殺球威力與TI-10,MP-100相比略有不足。適合控球型選手。此拍曾被國家隊混雙世界冠軍高凌所選用。

NS8000，此拍是目前納米系列中銷量很大的型號。目前銷量甚至要超過最新款的NS-9000。拍框10點2點位以及拍桿頂端采用了C60(弗拉倫)填充的納米材料。7mm細桿，爆發(fā)力極好。摒棄了傳統(tǒng)的吹氣管工藝而采用了發(fā)泡材料成型的制作方法，使拍框穩(wěn)定性更好，擊球時落點非常準確。采用了單向線孔設(shè)計，使球拍受力更加均勻，更耐用。因其彈性出色，拉球比較省力。均衡的設(shè)計使此拍處理網(wǎng)前球輕松自如，用于雙打時，NS8000平抽擋出球的速度比NS7000要快。雖然是輕量化設(shè)計，但在YONEX球拍坐標中，NS8000進攻能力以極微小差別僅低于MP-100。因其拍頭較輕，連續(xù)進攻能力很強，在業(yè)余選手中此拍比MP-100更受歡迎，銷量很大。

NS9000，最新款重型武器。拍頭明顯重于NS8000。9000的出現(xiàn)將MP-100趕下了進攻王者的寶座。分為S/X兩款分別對應(yīng)硬和超硬兩種中桿硬度。8mm粗桿拍柄加長，想要用好NS9000確實需要一些力量的支持。同樣采用發(fā)泡成型的制作方法。新的線孔位置，將球拍擊球甜區(qū)略微上移。ELASTIC TI的使用是拍框的穩(wěn)定性和彈性都有不小的進步。關(guān)于此拍更詳細的內(nèi)容，可參考本論壇steven_gu所作的“NS-9000使用體會”一文。

AT系列

AT系列是TI系列高端拍升級后的產(chǎn)品。拍框底部采用了傳統(tǒng)的盒式結(jié)構(gòu)，而上部則采用了創(chuàng)新的ARMORTEC技術(shù)。ARMORTEC技術(shù)最大的特點就是強度高，并帶有鈦金屬條配重。在加強了拍框12點位強度的同時也將球拍的中心向12點位移動，使進攻更加凌厲。AT系列拍身都采用了輕量化設(shè)計，在保持了拍頭足夠重的前提下使整拍重量只有3U，4U。專業(yè)選手使用此拍實測時殺球速度可以有5％的提高。

AT700，2003年誕生，在2004年遍地開花，2005年幾乎是言必談700了。此拍因為有大量的優(yōu)秀選手選用，所以幾乎成了業(yè)余中高級選手購拍的首選。就連國家隊內(nèi)多年使用CAB20的夏煊澤也已經(jīng)換成了AT700了。AT700的桿身很硬，頭很重，進攻能力極強，拍框采用盒式結(jié)構(gòu)加ARMORTEC鈦裝甲配重，穩(wěn)定性很好，強度極高，可以承受很高的拍線拉力，深受專業(yè)選手的喜愛。驅(qū)動這樣的球拍需要較強的腕力。如果力量不足，可以考慮用NS8000代替。

AT800，世界著名雙打選手拉斯姆森用的就是AT800中的進攻型（OFFENSIVE）。而另一位著名雙打選手西吉特使用的是防守型（DEFENSIVE）。進攻型的AT800包括了AT700所有的特點，而且800比700還要硬一些。由于球拍的KICKPOINT(彎折點)不同，AT800的平抽擋速度更快，更精準。800進攻型殺球的威力也要比700略微大一點點。AT800/OF和DE是非常適合雙打的一對球拍。也是目前高端拍中唯一的一對專為雙打而設(shè)計的球拍。性能非常的優(yōu)異。是喜愛雙打的業(yè)余愛好者首選。

MP系列

MP系列是YONEX產(chǎn)品線最全面的一個系列。從進攻性最強的MP100到柔軟舒適的MP23一應(yīng)俱全。該系列產(chǎn)品最大的特點就是拍框上帶有muscle power弧形設(shè)計。Muscle power最主要的作用就是降低拍線張力對線孔邊緣的壓力，減少較高磅數(shù)對球拍的傷害，并在拉線厚較長的一段時間內(nèi)保持相對較穩(wěn)定的線床張力。

MP100，2000年YONEX推出的產(chǎn)品。紅＋黑的涂裝非常惹眼。該產(chǎn)品設(shè)計定位就是進攻。是一把除了進攻還是進攻的球拍。拍框采用加鈦設(shè)計，強度高，穩(wěn)定性好，MUSCLE POWER技術(shù)的使用更保持了線床張力的持久，平衡的設(shè)計使球員可以在連續(xù)進攻中節(jié)省不少的體力。添加U Ti的 8mm中桿非常硬，彈性極好，但是因為此拍只適合于爆發(fā)力很好的進攻型球員，所以在業(yè)余選手中選用不多。

MP99,世界一號男單選手林丹在換用AT700之前使用的就是這個型號。MP99的亮黃色外觀非常討人喜歡，尤其是討女生的喜歡。所以有很長的一段時間，國家隊女隊中幾乎是一片香蕉黃。與MP100類似，MP99也是3、9點加鈦的設(shè)計。7mm的細桿同樣帶有了U Ti，因拍桿細了1毫米，所以比MP100要略軟一些。雖然當年此拍風靡一時，但是因為近一段時間與MP99球拍特點類似的新款球拍大量涌現(xiàn)，現(xiàn)時的99已經(jīng)不再吃香了。想要購買MP99的人不妨試試NS7000。

MP88，peter gade曾經(jīng)使用這把球拍很長時間。現(xiàn)在已經(jīng)更換為AT700了。MP88的拍桿中也使用了U Ti，保持了MP高端拍一貫的高彈性。MP88拍桿比MP99 100要軟一些，發(fā)力相對容易一些。拍頭較重，拍面比較穩(wěn)定。是一把性能出色非常適合業(yè)余愛好者使用的球拍。

MP66，這把球拍的風格與NS6000有些類似。色彩也比較相似，都很時尚。只是沒有NS6000那么多的高科技。頭輕型的MP66在使用中非常的靈活，深受女性球友的歡迎。此拍彈性適中，用于雙打時是一把很好的防守拍。

 來自：http://www.shbc.cn/dispbbs.asp?boardID=307&ID=40224&page=1

posted @ 2008-05-19 16:06 狼愛上貍 閱讀(529) | 評論 (0) | 編輯 收藏

羽毛球拍手膠選購

手膠（柄皮）:

手膠是纏在球拍握把上用以提高摩擦力的物品的統(tǒng)稱。目前主要分兩類，PU手膠和毛巾手膠。早起曾經(jīng)使用過的真皮手膠現(xiàn)在已經(jīng)基本退出市場。只有個別款式的球拍原配的柄皮還在使用真皮制品。與拍線和球之間的關(guān)系類似，手膠是和球員雙手關(guān)系最密切的。羽毛球運動需要很多手指，手腕的細膩動作，一根合適的手膠可以及時準確的將擊球后的感覺反饋給球員的手部。

一根好的手膠不但可以提供適當?shù)淖枘崾骨蚺奈盏母危€可以帶給球員柔軟舒適的手感，吸收打球時球員手部的汗水使球員保持手部干燥不易打滑。PU手膠因其較長的使用壽命，不易滋生細菌，吸汗后手感的保持和低廉的價格而深受廣大業(yè)余愛好者的歡迎。毛巾膠雖然價格相對較貴并且使用壽命斷，但因其手感柔軟，吸汗能力強還是有很多人堅持使用。

一條好的PU手膠應(yīng)該相對耐用，阻尼適當，吸汗抗水能力強，抗菌，不產(chǎn)生異味。一條好的毛巾膠應(yīng)該不掉色，不掉毛，圈絨較粗壯，薄厚適中，吸汗后不僵硬，不起球。

使用手膠時應(yīng)在保證稱手，適當柔軟的前提下盡可能的薄。過厚（過粗）的手膠會使手部僵硬，影響技術(shù)的發(fā)揮。

選擇手膠的三要素：類型（毛巾還是PU），尺寸（薄或厚），阻尼（該特點主要針對PU手膠的黏性）

使用手膠的幾種方法：

1、在原配柄皮上加PU手膠。目前國內(nèi)市場的各品牌球拍最常見的尺寸是周長86mm的握把。該尺寸等同于YY G4的粗細。在纏新的PU手膠上去的時候，盡量不要撕掉拍柄的原配熱縮膜（目前只有YY用熱縮膜包裝）。如果是普通的拍柄包裝，則需在取下包裝物后加纏一層UNDERLAP。UNDERLAP彈性很大，強度也不錯，吸水性強，是非常好的襯墊物。如果沒有UNDERLAP，也可以用一層保鮮膜代替。只是手感會稍差一些。

2、拆掉原配柄皮后加纏毛巾膠。這樣做是為了保持球拍合理的尺寸。因為毛巾膠比較厚，不拆除原配柄皮直接加纏毛巾膠會導致拍柄過粗，影響水平發(fā)揮。在纏毛巾膠之前，一定要使用UNDERLAP保護拍柄。

3、拆除原配柄皮后用PU手膠調(diào)整握把粗細。有很多球友在不同季節(jié)喜歡換用不同類型的手膠。夏天用毛巾膠，冬天用PU手膠。這種做法比較符合上海的季節(jié)特點，但是手膠的尺寸比較難控制。所以一般都需要去除原配柄皮，然后重新以PU柄皮來調(diào)整整個握把的粗細。在需要用毛巾膠的時候，只要去除所有的PU手膠即可，等到冬季來臨，再按原來習慣纏回PU手膠。

市場上的手膠品種非常多，比較優(yōu)秀的品牌低價位的有ALPHA，中極星，中高價位的KIMONI, YONEX。其中YONEX的毛巾膠手感較好。為世界各國專業(yè)運動員所喜愛。美國品牌FORTEN（華騰）雖然進入中國市場很晚，但是其手膠色彩鮮艷，價格低廉，頗受時尚球友的喜愛。KIMONI(金萬利）手膠是制作手膠起家的專業(yè)公司，與YONEX不同的是，KIMONI手膠是全日本制造。品質(zhì)極佳，是目前為止唯一一個手感，耐用性都要超越Y(jié)ONEX的產(chǎn)品。不過用好東西總要有點代價，其薄手膠KGT100價格要高于目前YONEX 102C的售價。其實KIMONI的手膠在原產(chǎn)國的價格與YONEX相比并不高，只是YONEX的手膠在國內(nèi)賣的太廉價了。

手膠簡介：

YONEX

AC-102，銷量最大的YONEX手膠。PU材料制造。標準長度1100毫米。實際長度大約為1150毫米左右。PU材料的表層有一層YONEX專門開發(fā)的柔軟覆膜，表層材料黏性好，吸汗能力強，手感舒適。因其表層材料是覆蓋在帶基上的，一旦表層材料磨穿，手感會下降較快。該手膠耐用性一般，在高強度使用條件下，表面覆膜經(jīng)常會大片脫落，這種情況屬于產(chǎn)品特征，并不代表質(zhì)量有問題。

AC-104EX，聚氨酯＋橡膠制造。標準長度1100毫米。在手膠的中間帶有一條5毫米寬2毫米高的發(fā)泡材料制造的長條。纏好以后會顯出一條一條的龍骨，使球拍更易于掌握。因為這種手膠加入了橡膠材料，故該手膠價格昂貴，但是此款手膠耐用性較好，也有一部分用戶堅持使用。

KIMONI

世界第一手膠品牌，其性能有口皆碑。

KGT－100 無孔薄手膠。PU材料，標長1050mm。顏色豐富（19色），手感極佳。各方面性能均超越Y(jié)ONEX產(chǎn)品。

最大特點：耐用，手感保持時間長。

KGT－170 我所用過的性能最出色的厚手膠，難怪其包裝外面印著“世界最強”，我覺得是當之無愧的。如果非要說有缺點，那就只能說他的價格不夠“實惠”了。不過好東西從來就沒實惠過，可以理解的。如果有條件，購買一支高端球拍時，可以當場將原配柄皮撕掉，換裝此產(chǎn)品。其優(yōu)異的性能絕不會令你失望。

最大特點：彈性保持時間長，隔離性好，對拍柄保護能力強。相同情況下，此產(chǎn)品彈性保持能力比最接近它的產(chǎn)品要長3－5倍。

該品牌其他型號雖然很多，但所用原料相同，帶有龍骨的產(chǎn)品價格要低于YONEX AC104EX。還有打孔的產(chǎn)品以增加透氣性，需要注意的是，打孔的產(chǎn)品最好先做隔水處理后再使用，不推薦手汗多的人使用打孔手膠。

值得一提的是，現(xiàn)在只有此品牌還有傳統(tǒng)的真皮手膠。如果你心愛的老款名拍手膠破損，可以用此來替換了。

KARAKAL

該品牌的厚手膠手感良好，雖然比不過世界第一的KIMONI KGT-170，但價格實惠的多，也是值得推薦的。

posted @ 2008-05-19 16:04 狼愛上貍 閱讀(2343) | 評論 (0) | 編輯 收藏

羽毛球拍線選購

羽毛球拍線：

羽毛球拍線是羽毛球運動中非常重要的一種耗材。球員每一次正確擊球動作唯一會接觸到羽毛球的就是拍線了。每一次擊球質(zhì)量的感覺將直接由拍線傳遞給球拍然后到達球員的手上。根據(jù)球員當前的打球風格以及打球的水平，選擇適合的拍線及拍線拉力是非常重要的。拍線的基本特點有耐用性，彈性，擊球聲音，控球能力和吸震性。生產(chǎn)廠家會將不同拍線的性能特點以5邊形的方式表現(xiàn)在該拍線的包裝上。選擇自己所需要的指數(shù)最高的拍線就可以了。舉例，如果追求耐用性，那么就選擇耐用指數(shù)最高的拍線。如果追求高彈性，則需選擇彈性直屬最高的線。一般來說，冬天應(yīng)該用略粗一點的拍線，因為冬天氣溫低，拍線變的相對較脆，很容易斷裂。夏天拍線的選擇可以隨意一些。 相同材質(zhì)情況下，越粗的線就越結(jié)實（耐用），越細的線彈性就越大，越不耐用。目前高檔球線中最耐用的拍線是YONEX BG 65，以及ASHAWAY（傲獅威）的A65(RALLY系列)。注意，ASHAWAY的中文名是傲獅威，而不是雅沙維。品牌名稱問題最后再講。

拍線拉力將直接影響到球拍的使用性能，一般來說，擊球點越準，力量越大，可以使用的拍線拉力就越高。隨著拍線拉力的提高，羽毛球拍上甜區(qū)的尺寸也快速的縮小，如果只是單純的力量大而擊球點準確度不夠，高拉力拍線將會把每一次偏離甜區(qū)的擊打所產(chǎn)生的所有震動通過球拍直接傳遞到球員的手腕、前臂，使球員受到慢性的隱性傷害。這種傷害是在相對較長的一段時間內(nèi)所積累下來的。起初癥狀并不明顯，但到達一定程度后，將會立刻凸顯出來。具體癥狀為手腕內(nèi)有撕裂感劇痛，手無法大力緊握等。一旦發(fā)現(xiàn)自己的前臂具有這種特征，就應(yīng)該減少打球時間，運動后采取一定的養(yǎng)護措施，降低拍線拉力，或更換較軟球拍。

判斷是否已受到這種傷害可用以下方法。持拍手自然端平，大臂和小臂呈90度夾角。此時，小臂應(yīng)指向身體的一側(cè)。手掌外翻對準自己面對的方向，另一只抓住自己的持拍手，慢慢加力向內(nèi)扭轉(zhuǎn)（逆時針方向）。如果達到一定角度以后還只是單純的自然疼痛（因肌肉、韌帶、關(guān)節(jié)等達到極限位置產(chǎn)生的不強烈的隱性疼痛），則是手腕還處于健康狀態(tài)。如果扭轉(zhuǎn)到一定程度后感覺到手腕內(nèi)的撕裂性的疼痛或針刺性的疼痛，則是已經(jīng)受傷了。如果輕輕一扭就已經(jīng)產(chǎn)生了強烈的疼痛，則是傷的較重了。

隨著拍線拉力的提高，拍線的彈性將快速降低，壽命也急速縮短。一些使用高拉力拍線的業(yè)余高手們即使用了BG65這樣極高耐用性的線，1－2周內(nèi)也會斷線。而國家羽毛球隊運動員甚至每1－2天就會斷線一次。當拍線拉力到達一定程度時，所有彈性特征都會消失的無影無蹤。這也是為什么國家隊員一般都只選擇高耐用性的線（如BG65,65TI）而不考慮高彈線的原因了。過高的拍線拉力會嚴重影響球拍的使用壽命，也會使球拍喪失保修資格。一般業(yè)余愛好者應(yīng)該根據(jù)自己的能力或參考比較專業(yè)的建議來選擇適合自己的拍線拉力。

SHBC(上海羽毛球網(wǎng))推薦拍線拉力：

初學者 男性20/21 女性19/20，中級水平 男性23/24 女性22/23，高級水平 男性25＋ 女性 24＋

知名羽毛球拍線品牌有：ASHAWAY（雅沙維），GOSEN(高神), MIZUNO（美津濃）, YONEX（尤尼克斯）

品牌簡介：

YONEX

BG65，高檔拍線中最耐用的一根，同類產(chǎn)品至今無人能出其右。進攻性能良好。控球型球員也可采用。吸震能力始終。0.70毫米的線徑

BG65TI，在BG65的基礎(chǔ)上加TI增加了彈性,犧牲了一部分的耐用性。擊球音略好。提高了線的強度，更適合暴力攻擊型選手。吸震能力與65相同。0.70毫米的線徑

BG70PRO，與65TI彈性相仿，擊球聲音與65類似。也很耐用。因為外皮采用了卵形纖維，所以耐拉能力極強，保持拍線拉力的性能非常好，但因吸震性能一般而使手感略微偏硬。0.70毫米的線徑。

BG80，采用卵形纖維外皮，內(nèi)包VECTRAN纖維，具有很高的反彈性和良好的爆發(fā)力，適合大力抽球，深受雙打選手喜愛。耐用度一般，但是聲音很好。0.68毫米線徑。為了保證VECTRAN纖維的效果，最好降低拉力1－2磅使用。

BG85，控球線，表皮非常粗糙，只有0.67毫米線徑。耐用性一般，吸震性能很好，手感柔軟。擊球音很好聽。彈性超過BG80。因此線同樣采用了VECTRAN纖維而線徑更細，所以要降低拉力2－3磅使用。

BG68TI，綜合性能非常優(yōu)異的一根球線。各方面的能力都比較出色。是目前市場上可見的彈性最高的YONEX拍線。擊球音清脆響亮，吸震性控制力都很出色。0.68毫米線徑。深受業(yè)余球友的歡迎。耐用性一般，冬天低溫很容易變脆斷線，盡量避免低溫使用。此線彈性很大，但是保持張力性能很一般，掉磅較快。為了保持一定的張力，需頻繁更換。印尼雙打名將西吉特的選擇。

ASHAWAY 傲獅威

ASHAWAY曾經(jīng)叫做雅沙維，這是中國總代所用的名字且已經(jīng)注冊了中文商標。但隨著ASHAWAY公司親自進入中國市場，原雅沙維品牌持有人拒絕放棄ASHAWAY產(chǎn)品及商標帶給其的經(jīng)濟效益，將產(chǎn)品轉(zhuǎn)為由其他廠家OEM。美國ASHAWAY公司只好責令其禁止使用ASHAWAY商標但對其中文名稱無能為力。所以，“雅沙維”這個品牌已經(jīng)不再是美國原產(chǎn)產(chǎn)品了。而真正的ASHAWAY中文名稱已經(jīng)改為傲獅威，習慣使用ASHAWAY產(chǎn)品的人購買時要注意一下品名和商標。

posted @ 2008-05-19 16:03 狼愛上貍 閱讀(709) | 評論 (0) | 編輯 收藏

羽毛球鞋選購

所有的羽球愛好者都要面對一個相同的問題：我到底該買什么樣的器材？為什么要買這個器材？這個器材對這項運動有多重要？下面我按照我個人認為的商品重要性進行了排列并做了簡單的說明。希望這篇羽球用品選購指南能對所有正在猶豫不決的羽球愛好者有所幫助。

因水平有限，未能列出全部羽球用品。日后會逐漸添加。

羽毛球鞋：

很多人都沒有認識到，一雙好的羽毛球鞋對這項運動到底有多重要。隨著球員在場上不停的快速移動，雙腳要承受平時幾倍的壓力，伴隨著每一次的啟動，球員的雙腳要作出扭，轉(zhuǎn)，跳躍，急停，換向等等極高機動性的動作。這所有的一切都是靠羽毛球鞋的支撐才得以完成。

有別于普通運動鞋，羽毛球鞋是專為羽毛球運動特點而設(shè)計的。較薄的鞋底，很強的側(cè)面支撐能力使雙腳盡可能的靠近地面。這種設(shè)計在保證了允許踝關(guān)節(jié)快速的彎曲，雙腳運動方向頻繁轉(zhuǎn)變的前提下盡可能低的降低了雙腳受傷的可能性。輕量化的設(shè)計可以使雙腳移動速度更快，專門的鞋底材料可以保證雙腳在球場上的抓地力。

在羽毛球運動中，我們對下半身所施加的壓力可以由一雙羽毛球鞋清晰的顯現(xiàn)出來。一雙高質(zhì)量的羽毛球鞋，在高手的使用下只有3－6個月的有效壽命。此時的羽毛球鞋鞋底已經(jīng)快要磨穿了，鞋墊也會磨透，高強度人造材料的鞋面，也會因為運動中所承受巨大壓力而開裂，破損。

選擇羽毛球鞋一定要仔細，確保選擇了一雙適合雙腳形狀及尺寸的，穿著舒適的球鞋。

選擇羽毛球鞋一定要比平常的鞋略大一點，不然跑動起來腳會包的很難受。

羽毛球鞋選擇時應(yīng)注意前松側(cè)緊。

側(cè)緊，為了避免側(cè)滑，防止扭傷；前松，上網(wǎng)時可起到緩沖作用。

一般來說，羽毛球鞋要比平常的鞋大半碼到一碼，不過記得要穿專業(yè)的羽毛球襪，一雙襪子半碼，留半碼給腳，剛剛好。

激烈的羽毛球運動中雙腳的血液循環(huán)要比平時快的多，雙腳充血也較平常嚴重，別說小了，就是試穿的時候正好合適下場以后都有可能覺得緊。

很多羽毛球愛好者總是覺得鞋買大了一碼以后會非常別扭，每次買鞋都要考慮買正好甚至略小的，這是非常錯誤的。

1、我們平常不會穿專門的羽毛球襪去試鞋，試出來的感覺本身就不夠準確。

2、鞋頭不寬松的話，上網(wǎng)時極有可能會頂?shù)阶铋L的腳趾，嚴重的還會使腳趾甲受損。

球鞋尺寸大了，有可能走路會覺得別扭，甚至會出現(xiàn)上樓梯踢臺階的現(xiàn)象，這是因為我們的大腦已經(jīng)習慣了鞋+腳的尺寸，在做上樓梯這個動作時，大腦發(fā)令總是以我們常用鞋碼的尺寸來作為抬腿出腳距離的標準，這是為了最大限度節(jié)省體力，是本能。

但羽毛球步法和上樓梯完全不是一回事，與平時走路也完全不是一回事。這也是為什么盡量到場館以后才換鞋的另一個原因。

注意不要穿厚底鞋(如籃球鞋)上場打羽毛球。厚底鞋會把腳抬離地面過高，導致嚴重的意外扭傷，甚至會帶來后遺癥，如習慣性扭傷等。這種運動傷害會在今后的很長一段時間影響你的羽毛球水平。

常見的不錯的羽毛球鞋品牌有MIZUNO,YONEX。國產(chǎn)品牌如VICTOR，KASON等因技術(shù)原因暫時無法與國外品牌抗衡，但因其價格低廉，也是不錯的選擇。

YONEX羽毛球鞋產(chǎn)品特點簡介：

YONEX的高級球鞋都帶有專利POWER CUSHION動力墊。Power cushion的減震能力和彈性極好，一個生雞蛋從兩米高度下落掉在動力墊上不會損壞，還可以跳起一米。

99LOW 鞋面由柔韌的高級PU合成皮革加雙層透氣網(wǎng)制成。超輕量EVA中底（GLITE）帶有專利POWER CUSHION材料制成的動力墊，鞋墊下部帶有TPU穩(wěn)定片防止足弓變形。高強度石墨連接橋，外裝爪型TPU支撐片（lateral claw） 鞋底是防滑耐磨的橡膠大底。

99M 同上

89MG 高級PU合成皮革，聚酯透氣網(wǎng)，護踝柔韌合成皮。EVA中底。耐磨，防滑大底。立體石墨支撐片。防扭系統(tǒng)。

56C 柔韌PU（合成皮），腳跟動力墊(POWER CUSHIO)，EVA中底。耐磨橡膠外底。

06年新款的90M 90L采用了圓鞋底，這種設(shè)計可使腳底受力更均勻，減輕腳底局部區(qū)域的壓力，使得穿著，使用更舒適。新品價格略高，但還是值得一試。

來自：http://www.shbc.cn/dispbbs.asp?boardID=307&ID=40224&page=1

posted @ 2008-05-19 16:01 狼愛上貍 閱讀(274) | 評論 (0) | 編輯 收藏

acegi,IBM的Acegi Security System（4）

2008 年 3 月 20 日

Bilal Siddiqui 將繼續(xù)在他的 系列文章 中展示如何使用 Acegi 保護 Java™Server Faces (JSF) 應(yīng)用程序。配置 JSF 和 Acegi，讓它們在 servlet 容器中協(xié)作，探索 JSF 和 Acegi 組件如何彼此協(xié)作。

本 系列 的前 3 部分討論了如何使用 Acegi Security System 保護 Java 企業(yè)應(yīng)用程序：

• 第 1 部分 解釋了如何使用 Acegi 的內(nèi)置過濾器實現(xiàn)一個簡單的基于 URL 的安全系統(tǒng)。
• 第 2 部分 展示了如何編寫訪問控制策略、將其存儲在 LDAP 目錄服務(wù)器中，以及配置 Acegi 與 LDAP 服務(wù)器交互，從而實現(xiàn)訪問控制策略。
• 第 3 部分 展示了如何在企業(yè)應(yīng)用程序中使用 Acegi 保護對 Java 類實例的訪問。

第 4 部分將討論如何使用 Acegi 保護在 servlet 容器中運行的 JavaServer Faces (JSF) 應(yīng)用程序。本文首先解釋 Acegi 針對此目標提供的特性，并澄清一些關(guān)于使用 Acegi 和 JSF 的常見誤解。然后提供一個簡單的 web.xml 文件，可以用來部署 Acegi，從而保護 JSF 應(yīng)用程序。然后深入探討 Acegi 和 JSF 組件，了解在部署 web.xml 文件和用戶訪問 JSF 應(yīng)用程序時所發(fā)生的事件。本文最后提供了一個由 Acegi 保護的示例 JSF 應(yīng)用程序。

無需編寫 Java 代碼即可添加安全性

回顧一下本系列的第一個示例 Acegi 應(yīng)用程序（請參閱 第 1 部分 中的 “一個簡單 Acegi 應(yīng)用程序” 一節(jié)）。該應(yīng)用程序使用 Acegi 提供了以下安全特性：

• 當一個未經(jīng)驗證的用戶試圖訪問受保護的資源時，提供一個登錄頁面。
• 將授權(quán)用戶直接重定向到所需的受保護資源。
• 如果用戶未被授權(quán)訪問受保護資源，提供一個訪問拒絕頁面。

回想一下，您無需編寫任何 Java 代碼就能獲得這些特性。只需要對 Acegi 進行配置。同樣，在 JSF 應(yīng)用程序中，無需編寫任何 Java 代碼，也應(yīng)該能夠從 Acegi 實現(xiàn)相同的特性。

澄清誤解

其他一些作者似乎認為將 Acegi 與 JSF 集成需要 JSF 應(yīng)用程序提供登錄頁面（參見 參考資料）。這種觀點并不正確。在需要時提供登錄頁面，這是 Acegi 的職責。確保登錄頁面在安全會話期間只出現(xiàn)一次，這也是 Acegi 的職責。然后，經(jīng)過身份驗證和授權(quán)的用戶可以訪問一個受保護資源，無需重復執(zhí)行登錄過程。

如果使用 JSF 提供登錄頁面，將會發(fā)生兩個主要的問題：

• 當需要時，沒有利用 Acegi 的功能提供登錄頁面。必須編寫 Java 代碼實現(xiàn)所有邏輯來提供登錄頁面。
  
  
• 至少需要編寫一些 Java 代碼將用戶憑證（用戶名和密碼）從 JSF 的登錄頁面移交到 Acegi。

Acegi 的目的是避免編寫 Java 安全代碼。如果使用 JSF 提供登錄頁面，則沒有實現(xiàn)這一用途，并且會引發(fā)一系列其他 JSF-Acegi 集成問題，所有這些問題都源于 “Acegi 是用來提供可配置安全性” 這一事實。如果試圖使用 JSF 來完成 Acegi 的工作，將會遇到麻煩。

本文余下部分將解釋并演示獨立于 Acegi 的 JSF 應(yīng)用程序開發(fā)，并在稍后配置 Acegi 以保護 JSF 應(yīng)用程序 — 無需編寫任何 Java 代碼。首先看一下 web.xml 文件，可以部署該文件保護 JSF 應(yīng)用程序。

回頁首

部署 Acegi 保護 JSF 應(yīng)用程序

清單 1 展示了一個 web.xml 文件（通常稱為部署描述符），可以使用這個文件部署 Acegi，從而保護運行在 servlet 容器（比如 Apache Tomcat）中的 JSF 應(yīng)用程序：

                        <?xml version="1.0"?>
            <!DOCTYPE web-app PUBLIC
            "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
            "http://java.sun.com/dtd/web-app_2_3.dtd">
            <web-app>
            <context-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>/WEB-INF/acegi-config.xml</param-value>
            </context-param>
            <context-param>
            <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
            <param-value>server</param-value>
            </context-param>
            <context-param>
            <param-name>javax.faces.CONFIG_FILES</param-name>
            <param-value>/WEB-INF/faces-config.xml</param-value>
            </context-param>
            <listener>
            <listener-class>
            org.springframework.web.context.ContextLoaderListener
            </listener-class>
            </listener>
            <listener>
            <listener-class>
            com.sun.faces.config.ConfigureListener
            </listener-class>
            </listener>
            <!-- Faces Servlet -->
            <servlet>
            <servlet-name>Faces Servlet</servlet-name>
            <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
            <load-on-startup> 1 </load-on-startup>
            </servlet>
            <!-- Faces Servlet Mapping -->
            <servlet-mapping>
            <servlet-name>Faces Servlet</servlet-name>
            <url-pattern>*.faces</url-pattern>
            </servlet-mapping>
            <!-- Acegi filter configuration -->
            <filter>
            <filter-name>Acegi Filter Chain Proxy</filter-name>
            <filter-class>
            org.acegisecurity.util.FilterToBeanProxy
            </filter-class>
            <init-param>
            <param-name>targetClass</param-name>
            <param-value>
            org.acegisecurity.util.FilterChainProxy
            </param-value>
            </init-param>
            </filter>
            <!-- Acegi Filter Mapping -->
            <filter-mapping>
            <filter-name>Acegi Filter Chain Proxy</filter-name>
            <url-pattern>/*</url-pattern>
            </filter-mapping>
            </web-app>
            

注意，清單 1 包含以下標記：

• 3 個 <context-param> 標記
• 2 個 <listener> 標記
• 1 個 <filter> 標記
• 1 個 <servlet> 標記
• 1 個 <servlet-mapping> 標記
• 1 個 <filter-mapping> 標記

閱讀該文件，了解每個標記在 JSF-Acegi 應(yīng)用程序中的用途。

向 Acegi 和 JSF 提供上下文參數(shù)

清單 1 中的每個 <context-param> 標記定義一個參數(shù)，供 Acegi 或 JSF 在啟動或執(zhí)行期間使用。第一個參數(shù) — contextConfigLocation — 定義 Acegi 的 XML 配置文件的位置。

JSF 需要 javax.faces.STATE_SAVING_METHOD 和 javax.faces.CONFIG_FILES 參數(shù)。javax.faces.STATE_SAVING_METHOD 參數(shù)指定希望在客戶機還是服務(wù)器上存儲 JSF 頁面-視圖狀態(tài)。Sun 的參考實現(xiàn)的默認行為是將 JSF 視圖存儲在服務(wù)器上。

javax.faces.CONFIG_FILES 參數(shù)指定 JSF 需要的配置文件的位置。JSF 配置文件的詳細信息不屬于本文討論的范圍（參見 參考資料，獲取涉及該主題的資源鏈接）。

為 Acegi 和 JSF 配置偵聽器

現(xiàn)在看一下 清單 1 中的 2 個 <listener> 標記。<listener> 標記定義偵聽器類，偵聽器類偵聽并處理 JSP 或 servlet 應(yīng)用程序啟動和執(zhí)行期間發(fā)生的事件。例如：

• 啟動 JSP 或 servlet 應(yīng)用程序時，servlet 容器創(chuàng)建一個新的 servlet 上下文。每當 JSP 或 servlet 應(yīng)用程序啟動時，就會觸發(fā)此事件。
  
  
• servlet 容器創(chuàng)建一個新的 servlet 請求對象。每當容器從客戶機收到一個 HTTP 請求時，此事件就會發(fā)生。
  
  
• 建立一個新的 HTTP 會話。當請求客戶機建立一個與 servlet 容器的會話時，此事件就會發(fā)生。
  
  
• 一個新屬性被添加到 servlet 上下文、servlet 請求和 HTTP 會話對象。
  
  
• servlet 上下文、servlet 請求或 HTTP 會話對象的一個現(xiàn)有屬性被修改或刪除。

<listener> 標記就像一種可擴展性機制，允許在 servlet 容器內(nèi)部運行的應(yīng)用程序協(xié)同某些事件進行處理。servlet 規(guī)范定義了偵聽器類為處理事件而實現(xiàn)的一些接口。

例如，Spring Framework 實現(xiàn)一個 javax.servlet.ServletContextListener servlet 接口。實現(xiàn)此接口的 spring 類是 org.springframework.web.context.ContextLoaderListener。注意，這是 清單 1 的第一個 <listener> 標記中的偵聽器類。

類似地，JSF 實現(xiàn)一個 com.sun.faces.config.ConfigureListener 類，該類實現(xiàn)一些事件-偵聽接口。可以在 清單 1 的第二個 <listener> 標記中找到 ConfigureListener 類。

本文稍后將解釋不同的事件-偵聽器接口，以及 Acegi 和 JSF 事件-偵聽器類內(nèi)部執(zhí)行的處理（請參閱 “啟動 JSF-Acegi 應(yīng)用程序” 和 “處理對受 Acegi 保護的 JSF 頁面的請求”）。

配置和映射 servlet 過濾器

現(xiàn)在看一下 清單 1 中的 <filter> 標記。在請求的 servlet 處理傳入的請求之前，servlet 應(yīng)用程序使用過濾器對其進行預處理。在請求執(zhí)行之前，Acegi 使用 servlet 過濾器對用戶進行身份驗證。

請注意 清單 1 中的 <filter> 標記，它的 <filter-class> 子標記指定一個 org.acegisecurity.util.FilterToBeanProxy 類。FilterToBeanProxy 類是 Acegi 的一部分。此類實現(xiàn)一個 javax.servlet.Filter 接口，該接口是 servlet 應(yīng)用程序的一部分。javax.servlet.Filter 接口有一個 doFilter() 方法，servlet 容器在收到請求時調(diào)用該方法。

還需注意，清單 1 的 <filter> 標記有另一個子標記 <init-param>。<init-param> 標記指定實例化 FilterToBeanProxy 類所需的參數(shù)。可以從 清單 1 中看出，FilterToBeanProxy 類只需要一個參數(shù)，該參數(shù)是 FilterChainProxy 類的一個對象。FilterChainProxy 類表示 第 1 部分 1 中討論的整個 Acegi 過濾器鏈（請參閱 “安全過濾器” 小節(jié)）。FilterToBeanProxy 類的 doFilter() 方法使用 FilterChainProxy 類執(zhí)行 Acegi 的安全過濾器鏈。

清單 1 中的 <filter-mapping> 標記指定調(diào)用 Acegi 的 FilterToBeanProxy 的請求 URL。我已經(jīng)將所有的 JSF 頁面映射到 Acegi 的 FilterToBeanProxy。這意味著只要用戶試圖訪問 JSF 頁面，FilterChainProxy doFilter() 方法就會自動獲得控制權(quán)。

配置 JSF servlet

web.xml 文件中的 <servlet> 標記指定希望從特定 URl 調(diào)用的 servlet（在本例中是一個 JSF servlet）。<servlet-mapping> 標記定義該 URL。幾乎所有的 JSP 或 servlet 應(yīng)用程序都包含這兩個標記，所以無需再作討論（參見 參考資料，獲取討論 servlet 編程的資源鏈接）。

現(xiàn)在，您已經(jīng)看到，web.xml 文件要部署 Acegi 以保護 JSF 應(yīng)用程序所需的所有標記。您已經(jīng)了解了偵聽器、過濾器和 servlet 如何相互協(xié)作。從這里的討論中可以看出，如果在 servlet 容器中部署 清單 1 中的 web.xml 文件，Acegi 和 JSF 都試圖在兩種情形下進行一些處理：

• 當啟動應(yīng)用程序時
• 當應(yīng)用程序收到對 JSF 頁面的請求時

接下來的兩節(jié)解釋每種情況中發(fā)生的一系列事件。

回頁首

啟動 JSF-Acegi 應(yīng)用程序

圖 1 展示了在 JSF-Acegi 應(yīng)用程序啟動時發(fā)生的事件順序：

詳細來講，圖 1 顯示的事件順序如下所示：

1. servlet 容器實例化在 web.xml 文件中配置的所有偵聽器。
   
   
2. servlet 容器將 Acegi 的 ContextLoaderListener 注冊為一個偵聽器類，該類實現(xiàn) javax.servlet.ServletContextListener接口。ServletContextListener 接口包含兩個重要方法：contextInitialized() 和 contextDestroyed()：
   • contextInitialized() 方法在初始化 servlet 上下文時獲得控制權(quán)。
   • 類似地，當應(yīng)用程序退出時，contextDestroyed() 方法會被調(diào)用，并消除 servlet 上下文。
   
   
3. servlet 容器將 JSF 的 ConfigureListener 注冊為另一個偵聽器。JSF 的 ConfigureListener 實現(xiàn)許多偵聽器接口，比如 ServletContextListener、 ServletContextAttributeListener、 ServletRequestListener，以及 ServletRequestAttributeListener。您已經(jīng)看到了 ServletContextListener 接口的方法。余下的接口是：
   • ServletContextAttributeListener，它包含 3 種方法：attributeAdded() attributeRemoved() 和 attributeReplaced()。這 3 種方法分別在某個屬性被添加到 servlet 上下文、被從 servlet 上下文刪除、被新屬性取代時獲得控制權(quán)。attributeReplaced() 方法在 處理對受 Acegi 保護的 JSF 頁面的請求 小節(jié)的第 8 步中獲得控制權(quán)。
     
     
   • ServletRequestListener 中包含的方法在創(chuàng)建或刪除新的 servlet 請求對象時獲得控制權(quán)。servlet 請求方法表示并包裝來自用戶的請求。
     
     
   • ServletRequestAttributeListener 中包含的方法在添加、刪除或替換某個請求對象的屬性時獲得控制權(quán)。本文稍后將討論在 處理對受 Acegi 保護的 JSF 頁面的請求 小節(jié)的第 3 步中創(chuàng)建一個新的請求對象時，JSF 的 ConfigureListener 執(zhí)行的處理。
   
   
4. servlet 容器創(chuàng)建一個 servlet 上下文對象，該對象封裝應(yīng)用程序資源（比如 JSP 頁面、Java 類和應(yīng)用程序初始化參數(shù)），并允許整個應(yīng)用程序訪問這些資源。JSF-Acegi 應(yīng)用程序的所有其他組件（偵聽器、過濾器，以及 servlet）在 servlet 上下文對象中以屬性的形式存儲與應(yīng)用程序資源相關(guān)的信息。
   
   
5. servlet 容器通知 Acegi 的 ContextLoaderListener，servlet 上下文是通過調(diào)用 ContextLoaderListener 的 contextInitializated() 方法初始化的。
   
   
6. contextInitialized() 方法解析 Acegi 的配置文件，為 JSF-Acegi 應(yīng)用程序創(chuàng)建 Web 應(yīng)用程序上下文，以及實例化所有的安全過濾器和在 Acegi 配置文件中配置的 Jave bean。在以后 JSF 應(yīng)用程序收到來自客戶機的請求時，這些過濾器對象將會用于身份驗證和授權(quán)（參閱 第 3 部分 中關(guān)于 Web 應(yīng)用程序上下文創(chuàng)建的討論和圖 1）。
   
   
7. servlet 容器通知 JSF 的 ConfigureListener，servlet 上下文是通過調(diào)用 contextInitialized() 方法初始化的。
   
   
8. contextInitialized() 方法檢查在 JSF 配置文件中配置的所有 JSF 托管 bean，確保 Java 類與每個 bean 并存。
   
   
9. servlet 容器檢查 web.xml 文件中任何配置的過濾器。例如，清單 1 中的 web.xml 文件包含一個 Acegi 過濾器 FilterToBeanProxy，servlet 容器將其實例化、初始化并注冊為一個過濾器。Acegi 現(xiàn)在可以對傳入的請求執(zhí)行身份驗證和授權(quán)了。
   
   
10. servlet 容器實例化 faces servlet，后者開始偵聽從用戶傳入的請求。

下一節(jié)解釋 JSF-Acegi 應(yīng)用程序收到來自用戶的請求時發(fā)生的一系列事件。

回頁首

處理對受 Acegi 保護的 JSF 頁面的請求

您已經(jīng)了解了如何配置 Acegi 保護 JSF 應(yīng)用程序。也看到了當啟動 JSF-Acegi 應(yīng)用程序時發(fā)生的一系列事件。本節(jié)描述當用戶發(fā)送一個對受 Acegi 保護的 JSF 頁面的請求時，JSF 和 Acegi 組件如何在 servlet 容器的框架中運行。

圖 2 展示了當客戶機發(fā)送一個對受 Acegi 保護的 JSF 頁面的請求時，發(fā)生的事件順序：

詳細來講，圖 2 展示的事件順序如下所示：

1. servlet 容器創(chuàng)建一個表示用戶請求的 servlet 請求對象。
   
   
2. 回想一下 啟動 JSF-Acegi 應(yīng)用程序 小節(jié)中的第 3 步，JSF 的 ConfigureListener 實現(xiàn) ServletRequestListener 接口。這意味著 ConfigureListener 偵聽與創(chuàng)建和刪除 servlet 請求對象相關(guān)的事件。因此，servlet 容器調(diào)用 ConfigureListener 類的 requestInitialized() 方法。
   
   
3. requestInitialized() 方法準備執(zhí)行請求的 JSF 生命周期。準備過程包括檢查請求的 faces 上下文是否存在。faces 上下文封裝與應(yīng)用程序資源相關(guān)的信息。faces servlet 執(zhí)行 JSF 生命周期時需要這些信息。如果此請求是新會話的第一個請求，就會缺少 faces 上下文。在這種情況下，requestInitialized() 方法創(chuàng)建一個新的 faces 上下文。
   
   
4. servlet 容器檢查用戶的請求是否帶有任何狀態(tài)信息。如果 servlet 容器未找到狀態(tài)信息，它會假設(shè)該請求是新會話的第一個請求，并為用戶創(chuàng)建一個 HTTP 會話對象。如果 servlet 容器發(fā)現(xiàn)該請求包含某種狀態(tài)信息（比如一個 cookie 或 URL 中的某種狀態(tài)信息），它就會根據(jù)保存的會話信息恢復用戶以前的會話。
   
   
5. servlet 容器把請求 URL 與一個 URL 模式進行匹配，這個 URL 模式包含在配置描述符中的 <filter-mapping> 標記的 <url-pattern> 子標記中。如果請求 URL 與這個 URL 模式匹配，servlet 容器調(diào)用 Acegi 的 FilterToBeanProxy，FilterToBeanProxy 已在 圖 1 的第 9 步中被注冊為一個 servlet 過濾器。
   
   
6. Acegi 的 FilterToBeanProxy 使用 FilterChainProxy 類執(zhí)行 Acegi 的完整的安全過濾器鏈。Acegi 的過濾器自動檢查第 4 步中創(chuàng)建的 HTTP 會話對象，以查看請求客戶機是否已被驗證。如果 Acegi 發(fā)現(xiàn)用戶未被驗證，它提供一個登錄頁面。否則，它就直接執(zhí)行 第 2 部分 的 “配置攔截器” 一節(jié)中描述的授權(quán)過程。
   
   
7. Acegi 使用經(jīng)過驗證的用戶的會話信息更新 servlet 上下文。
   
   
8. servlet 容器通知 JSF 的 ConfigureListener 的 attributeReplaced() 方法，servlet 上下文已被更新。ConfigureListener 檢查是否有任何 JSF bean 被更改。如果發(fā)現(xiàn)任何更改，它相應(yīng)地更新 faces 上下文。但是，在本例中，在身份驗證過程中 Acegi 沒有更改任何 JSF 托管 bean，因此在此調(diào)用期間 ConfigureListener 不進行任何處理。
   
   
9. 如果授權(quán)過程成功，控制權(quán)被轉(zhuǎn)移到 faces servlet，它執(zhí)行 JSF 生命周期并向用戶發(fā)回一個響應(yīng)。

現(xiàn)在，您了解了 JSF 和 Acegi 如何協(xié)作提供 JSF 請求，接下來看一下完成后的 JSF 和 Acegi。

回頁首

示例 JSF-Acegi 應(yīng)用程序

本文的下載部分（參見 下載）包含一個示例 JSF-Acegi 應(yīng)用程序 JSFAcegiSample，演示了 Acegi 與 JSF 的簡單集成。示例應(yīng)用程序使用 清單 1 中的 web.xml。

要部署示例應(yīng)用程序，執(zhí)行 第 1 部分 的 “部署并運行應(yīng)用程序” 一節(jié)中的兩個步驟。還需要從 Sun 的 JSF 站點（參見 參考資料）下載并解壓 jsf-1_1_01.zip。將 jsf-1.1.X.zip 中的所有文件復制到 JSFAcegiSample 應(yīng)用程序的 WEB-INF/lib 文件夾中。

從瀏覽器訪問 http://localhost:8080/JSFAcegiSample，可以調(diào)用示例應(yīng)用程序。JSFAcegiSample 應(yīng)用程序顯示一個索引頁面和一個登錄頁面，索引頁面中包含受保護資源的鏈接。所有受保護頁面都是使用 JSF 組件開發(fā)的，而 Acegi 提供登錄頁面并執(zhí)行身份驗證和授權(quán)。

結(jié)束語

在本文中，了解了如何配置 Acegi 以保護 JSF 應(yīng)用程序。還詳細了解了 JSF 和 Acegi 組件如何在一個 servlet 容器的框架中協(xié)作。最后，嘗試運行了一個示例 JSF-Acegi 應(yīng)用程序。

關(guān)于實現(xiàn) JSF 應(yīng)用程序的 Acegi 安全性，還涉及到更多內(nèi)容。本系列的下一篇文章將演示如何使用 Acegi 保護對 JSF 的托管 bean 的訪問。


來自: http://www.cnblogs.com/amboyna/archive/2008/03/25/1122089.html

posted @ 2008-05-08 18:50 狼愛上貍 閱讀(299) | 評論 (0) | 編輯 收藏

acegi,IBM的Acegi Security System（3）

2007 年 10 月 18 日

本文是 Acegi Security Systerm 介紹的最后一部分（共三部分），Bilal Siddiqui 將向您介紹如何保護對 Java 類實例的訪問，從而結(jié)束本系列文章。通過本文了解為何需要對 Java™ 類的訪問進行保護，Spring 如何創(chuàng)建和保護對 Java 類實例的訪問以及如何對 Acegi 進行配置以實現(xiàn) Java 應(yīng)用程序的類安全性。

這期共分三部分的系列文章介紹了如何使用 Acegi 安全系統(tǒng)保護 Java 企業(yè)應(yīng)用程序。系列文章的 第 1 部分 簡單介紹了 Acegi 并解釋如何使用其內(nèi)置的安全過濾器實現(xiàn)一個簡單的、基于 URL 的安全系統(tǒng)。第 2 部分 介紹了如何編寫訪問控制策略并將其保存到一個 LDAP 目錄服務(wù)器，以及如何配置 Acegi 來與目錄服務(wù)器進行交互，從而實現(xiàn)訪問控制策略。第 3 部分（也是本系列的最后一篇文章）將演示如何在企業(yè)應(yīng)用程序中使用 Acegi 保護對 Java 類實例的訪問。

首先我將介紹何時需要對 Java 類訪問進行保護，包括文中引用的兩個典型企業(yè)應(yīng)用程序場景。之后，我將解釋 Spring 的反轉(zhuǎn)控制（IOC）框架如何創(chuàng)建可從 JSP 或 servlet 訪問的 Java 類實例。我還將介紹有關(guān) bean 代理 的重要概念，Spring 正是使用它過濾對 Java 類的訪問。最后，我將介紹如何對 Acegi 的方法安全性攔截器進行配置以控制對 Java 類的訪問。我將對 第 2 部分 中的示例程序進行增強，為實現(xiàn)安全的 Java 對象提供支持，從而結(jié)束本系列的最后一篇文章。

由于本文的討論構(gòu)建在本系列前兩部分的內(nèi)容之上，因此會經(jīng)常引用到 第 1 部分 和 第 2 部分 中的討論和示例。因此，在繼續(xù)閱讀本文之前，在其他瀏覽器窗口中打開前兩期文章將有助于理解本文內(nèi)容。

保護 Java 類的用例

您可能還記得，我曾在本系列的開頭部分簡單介紹了 企業(yè)應(yīng)用程序安全性。在那次討論中我曾提到過一種場景，其中 URL 安全性并不能完全滿足這種場景的安全需求：

假設(shè)有這樣一個 PDF 文檔，其中包含了某制造業(yè)公司生產(chǎn)的特定產(chǎn)品的數(shù)據(jù)。文檔的一部分包含了設(shè)計數(shù)據(jù)，將由公司設(shè)計部分進行編輯和更新。文檔另一部分包含生產(chǎn)經(jīng)理將使用到的生產(chǎn)數(shù)據(jù)。對于此類場景，需要實現(xiàn)更加細粒度的安全性，對文檔的不同部分應(yīng)用不同的訪問權(quán)限。

在繼續(xù)閱讀之前，請考慮更多的應(yīng)用程序場景，除了實現(xiàn) URL 安全性以外，這些場景還要求您對單獨的類訪問進行保護。

業(yè)務(wù)自動化

業(yè)務(wù)自動化應(yīng)用程序中的工作流由多個流程組成。例如，病理學實驗室中執(zhí)行血液測試的工作流由若干個步驟組成，其中每個步驟可看作一個業(yè)務(wù)流程：

1. 工作人員從病人處采集血液樣本并為其分配一個 ID。
2. 實驗室技術(shù)人員對樣本進行必要的測試并準備測試結(jié)果。
3. 由具備相應(yīng)資格的病理學專家根據(jù)測試結(jié)果編寫測試報告。

很明顯，每個流程分別由單獨的授權(quán)用戶執(zhí)行。未授權(quán)的用戶則無權(quán)執(zhí)行流程。例如，實驗室研究人員只負責準備試驗結(jié)果，而無權(quán)編寫測試報告。

幾乎所有的業(yè)務(wù)自動化應(yīng)用程序都普遍使用授權(quán)的業(yè)務(wù)流程。通常，每個業(yè)務(wù)流程被實現(xiàn)為一個 Java 類，并且需要使用合適的訪問控制策略對所有類實施保護。

企業(yè)對企業(yè)（Business-to-business）集成

Business-to-business (B2B) 集成指一種常見的場景，其中的兩個企業(yè)實體需要彼此公開各自的特定功能。例如，賓館可能向旅游公司公開其房間預訂功能，而后者使用該功能為游客預訂空閑的房間。作為合作伙伴的旅游公司可能具有一個特定的訂房率。在這個場景中，賓館的訂房系統(tǒng)必須先對旅游公司進行身份驗證，然后才能允許他們訪問所選擇的類，以便按照特定的訂房率進行房間預訂。

回頁首

使用 Spring 創(chuàng)建 Java 對象

現(xiàn)在您已經(jīng)了解了對 Java 類示例的訪問進行保護的重要性。在介紹能夠?qū)崿F(xiàn)更高級安全性的 Acegi 新功能之前，我將引導您回顧 Spring 框架的幾個關(guān)鍵特性，您需要了解這些內(nèi)容才能繼續(xù)后文的示例。

首先對一些 Java 類進行配置并執(zhí)行實例化。第 1 部分 曾介紹過，Java 類在 Spring 的 XML 配置文件中進行配置。在 Spring 配置文件中配置 Java 類的過程與 Acegi 過濾器的配置過程完全相同，因此這里不多做介紹。相反，我們將查看清單 1，它展示了名為 publicCatalog 的 bean 的配置：

            <beans>
            <bean id="publicCatalog"
            class="com.catalog.PublicCatalog" />
            <!--Other bean tags -->
            <beans>
            

了解 Spring 的 IOC 框架如何從 XML 配置文件讀取 Java 類信息以及如何進行實例化，這一點非常重要。您可能還記得，我在系列文章的 第 1 部分 中使用一個 web.xml 文件配置 <listener> 標記，它指向名為 ContextLoaderListener 的類。ContextLoaderListener 裝載 Spring 的 IOC 框架并創(chuàng)建 Java 對象。您可以參考 第 1 部分的清單 8 查看全部內(nèi)容。圖 1 也對此進行了描述：

現(xiàn)在我們將詳細討論這些步驟：

1. 當初始化 Acegi 應(yīng)用程序時，servlet 容器（本例中為 Apache Tomcat）創(chuàng)建了一個 servlet 上下文，其中保存了有關(guān)應(yīng)用程序資源的信息，例如 JSP 頁面和類。
   
   
2. servlet 容器通知 ContextLoaderListener 類應(yīng)用程序正在啟動。
   
   
3. ContextLoaderListener 類創(chuàng)建一個 Web 應(yīng)用程序上下文以保存應(yīng)用程序中特定于 Spring 的資源信息。借助 Spring 的 IOC 框架，您可以裝載自己的自定義應(yīng)用程序上下文。要創(chuàng)建應(yīng)用程序上下文，將使用名為 ContextLoader 的上下文裝載器類裝載應(yīng)用程序上下文。
   
   
4. 如果應(yīng)用程序不需要定義自己的應(yīng)用程序上下文，則可以使用名為 XMLWebApplicationContext 的類，它是 Spring 框架的一部分并提供可處理 Spring XML 配置文件的功能。Acegi 應(yīng)用程序使用的是 Spring 的 XML 配置文件，因此本文僅討論由 XMLWebApplicationContext 類表示的應(yīng)用程序上下文。在本例中，上下文裝載器對 XMLWebApplicationContext 類進行實例化，后者表示您的 Acegi 應(yīng)用程序的應(yīng)用程序上下文。上下文裝載器還在 Web 應(yīng)用程序上下文中設(shè)置 servlet 上下文（于步驟 1 中創(chuàng)建）的引用。
   
   
5. XMLWebApplicationContext 類對 XML 配置文件進行解析，獲得關(guān)于 Java 類的信息并將信息裝載到其他內(nèi)部對象中。
   
   
6. XMLWebApplicationContext 類對 XML 配置文件中指定的所有 Java 類進行實例化。XMLWebApplicationContext 類檢查 XML 配置文件中經(jīng)過配置的 Java bean 是否依賴其他的 Java 對象。如果是的話，XMLWebApplicationContext 類將首先對其他 bean 所依賴的 bean 進行實例化。通過這種方式，XMLWebApplicationContext 類創(chuàng)建了 XML 配置文件中定義的所有 bean 的實例。（注意，步驟 6 假定 XML 配置文件中所有 bean 都不要進行保護，稍后一節(jié)將介紹步驟 5 和步驟 6 之間執(zhí)行的額外步驟，從而保護對此處創(chuàng)建的 Java bean 的訪問）。
   
   
7. XMLWebApplicationContext 類將所有 bean 保存在一個數(shù)組中。

您現(xiàn)在已了解到如何從 XML 配置文件中裝載 bean 定義并創(chuàng)建 Java 類的實例。接下來，我將向您介紹 Spring bean 代理并解釋它對于保護 Java 類實例的重要性。

回頁首

使用 bean 代理

上一節(jié)討論了 Spring 的 IOC 框架對 Java 對象進行實例化。要保護對 Java 對象的訪問，Spring 的 IOC 框架使用了 bean 代理 的概念。本節(jié)首先介紹如何配置 bean 代理，然后演示 Spring 的 IOC 框架如何創(chuàng)建代理對象。

為 Java 對象配置代理

如果希望創(chuàng)建 bean 代理，Spring IOC 框架要求您對代理創(chuàng)建器 bean 的實例進行配置。Spring 的 IOC 框架使用代理創(chuàng)建器創(chuàng)建代理對象。清單 2 為代理創(chuàng)建器 bean 的配置文件，用于保護名為 privateCatalog 的 Java 對象：

            <bean id="proxyCreator"
            class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
            <property name="beanNames">
            <list>
            <value>privateCatalog</value>
            <!--Names of other beans to be proxied -->
            </list>
            </property>
            <property name="interceptorNames">
            <list>
            <value>privateCatalogSecurityInterceptor</value>
            </list>
            </property>
            </bean>
            

如清單 2 所示，<bean> 標記具有一個 class 屬性，其值為 org.springframework.aop.framework.autoproxy. BeanNameAutoProxyCreator。BeanNameAutoProxyCreator 類是 Spring IOC 框架的一部分，可以自動創(chuàng)建 bean 代理。Spring 框架提供了 BeanPostProcessor 接口，它提供了一種可擴展機制，允許應(yīng)用程序編寫自己的邏輯來創(chuàng)建 bean 代理。Spring 的 BeanNameAutoProxyCreator 類實現(xiàn)了 BeanPostProcessor 接口并提供所有必需的代理創(chuàng)建邏輯來保護 Java 類。因此，本文中您無需實現(xiàn) BeanPostProcessor 接口。

在創(chuàng)建 bean 代理時，BeanNameAutoProxyCreator 類為所有由 beanNames 屬性定義的 bean 創(chuàng)建代理（參見 清單 2 中 <bean> 標記的第一個 <property> 子元素）。beanNames 屬性在 <list> 標記中包含一個 bean 名稱列表。在 清單 2 中，我只對希望為之創(chuàng)建代理的 privateCatalog bean進行了配置。

現(xiàn)在查看 清單 2 中 <bean> 標記的第二個 <property> 子元素。它指定了名為 interceptorNames 的代理，它將一個或多個攔截器的名稱封裝起來。我將在后文詳細討論攔截器概念。現(xiàn)在，只需了解攔截器可以攔截用戶并在用戶訪問 bean 之前實現(xiàn)訪問控制策略。

現(xiàn)在，您已了解了如何對希望進行保護的 bean 配置代理。接下來，您將了解 Spring 的 IOC 框架如何在內(nèi)部為應(yīng)用程序的 bean 創(chuàng)建代理對象。

Spring IOC 發(fā)揮效用

在 “使用 Spring 創(chuàng)建 Java 對象” 的步驟 5 和步驟 6 中，您了解了 XMLWebApplicationContext 類如何從 XML 配置文件中讀取 bean 定義并隨后創(chuàng)建 bean 實例。在創(chuàng)建 bean 實例之前，XMLWebApplicationContext 類將檢查 XML 配置文件是否包含任何代理創(chuàng)建器 bean（即實現(xiàn) BeanPostProcessor 接口的 bean）配置。如果存在該 bean，它將要求代理創(chuàng)建器為您希望進行保護的 bean 創(chuàng)建 bean 代理。

1. 代理創(chuàng)建器（即 BeanNameAutoProxyCreator 類）裝載 清單 2 中配置的 beanNames 屬性文件中指定的所有 bean 名稱。
   
   
2. 代理創(chuàng)建器使用 bean 名稱裝載各自的 Java 類，這些類使用了每個 bean 定義的 class 屬性。
   
   
3. 代理創(chuàng)建器創(chuàng)建 清單 2 所示的 interceptorNames 屬性中指定的攔截器的實例。
   
   
4. 最后，代理創(chuàng)建器創(chuàng)建一個 Cglib2AopProxy 類的實例，將所有 bean 名稱（步驟 2）和攔截器（步驟 3）傳遞到 Cglib2AopProxy 類。Cglib2AopProxy 類是 Spring 框架的一部分并用于生成動態(tài)代理對象。在本例中，Cglib2AopProxy 類將創(chuàng)建安全 bean 訪問控制所需的代理對象。

Cglib2AopProxy 類實現(xiàn)了兩個名為 AOPProxy 和 MethodInterceptor 的接口。AOPProxy 接口由 Spring 框架提供，表示您希望進行代理的實際 bean，因此它與您的 bean 公開相同的方法。MethodInterceptor 接口也源于 AOP 框架，它包含的方法可以在用戶試圖訪問您已執(zhí)行代理的 bean 時接受控制權(quán)。這意味著 MethodInterceptor 接口處理來自用戶的請求以訪問執(zhí)行過代理的 bean。由于 Cglib2AopProxy 類同時實現(xiàn)了 AOPProxy 和 MethodInterceptor 接口，因此它提供了完整的功能，既可以提供經(jīng)過代理的 bean，也可以處理用戶請求以訪問代理 bean（參見 參考資料小節(jié) 中有關(guān) AOP 的討論文章的鏈接）。

執(zhí)行完前面的步驟后，您現(xiàn)在具有了所需的代理對象。因此 XMLWebApplicationContext 類將安全 bean 的代理（而不是實際的 bean）保存在 “使用 Spring 創(chuàng)建 Java 對象” 的步驟 7 中的同一個數(shù)組中。

回頁首

訪問執(zhí)行過代理的 Java 對象

在前面的幾節(jié)中，您了解了 Spring 如何創(chuàng)建公有 bean 和私有 bean。出于本文的目的，您可將公有 bean 視為使用代理保護的不安全的私有 bean。現(xiàn)在我們來看一下客戶機應(yīng)用程序為訪問公有 bean 和私有 bean 而必須遵循的一系列步驟。

清單 3 展示了 publicCatalog 和 privateCatalog 兩個 bean 的 XML 配置。publicCatalog bean 意味著公共訪問，因此不需要使用 bean 代理。privateCatalog bean 意味著只能由指定用戶訪問，因此必須加以保護。我在清單 3 中包含了 privateCatalog bean 的 bean 代理配置：

            <beans>
            <bean id="publicCatalog" class="sample.PublicCatalog"/>
            <bean id="privateCatalog" class="sample.PrivateCatalog"/>
            <!-- proxy configuration for privateCatalog bean -->
            <bean id="proxyCreator"
            class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
            <property name="beanNames">
            <list>
            <value>privateCatalog</value>
            <!--Names of other beans to be proxied -->
            </list>
            </property>
            <property name="interceptorNames">
            <list>
            <value>privateCatalogSecurityInterceptor</value>
            </list>
            </property>
            </bean>
            <beans>
            

應(yīng)用程序可以使用清單 4 中的代碼訪問清單 3 中配置的 publicCatalog 和 privateCatalog Java bean。注意，清單 4 中顯示的 Java 代碼可位于 JSP 頁面或位于服務(wù)器端 Java 應(yīng)用程序的 bean 中。

            //Step 1: Fetching an instance of the application context
            XMLWebApplicationContext applicationCtx =
            WebApplicationContextUtils.getWebApplicationContext(
            this.getServletConfig().getServletContext());
            //Step 2: Fetching an insecure bean from the application context
            PublicCatalog publicCatalog =
            (PublicCatalog) applicationCtx.getBean("publicCatalog");
            //Step 3: Calling a method of the insecure bean
            String publicData = publicCatalog.getData();
            //Step 4: Fetching a secure bean from the application context
            PrivateCatalog privateCatalog =
            (PrivateCatalog) applicationCtx.getBean("privateCatalog");
            //Step 5: Calling a method of the secure bean
            String privateData = privateCatalog.getData();
            

下面將進一步討論清單 4 中的步驟：

• 步驟 1：取回一個應(yīng)用程序上下文實例
  當應(yīng)用程序希望訪問 XML 配置文件中配置的 Java bean 時，它必須取回您在 “使用 Spring 創(chuàng)建 Java 對象” 的步驟 4 中見到的 XMLWebApplicationContext 對象。XMLWebApplicationContext 對象包含對 XML 配置文件配置的所有 Java beans 的引用。
  
  
• 步驟 2：從應(yīng)用程序上下文中取回不安全的 bean
  您現(xiàn)在具有一個對 XMLWebApplicationContext 對象的引用。XMLWebApplicationContext 類公開了一個 getBean() 方法，它包含 bean 的名稱并在數(shù)組中查找 “使用 Spring 創(chuàng)建 Java 對象” 步驟 7 中準備的 bean。在本例中，該 bean 為 publicCatalog（未執(zhí)行過代理），因此 XMLWebApplicationContext 將返回實際的 bean。
  
  
• 步驟 3：調(diào)用不安全 bean 的方法
  現(xiàn)在您可以調(diào)用步驟 2 中獲得的 publicCatalog bean 的任何方法。例如，清單 4 顯示的 getData() 方法調(diào)用的執(zhí)行沒有應(yīng)用任何訪問控制并向應(yīng)用程序返回類別數(shù)據(jù)。
  
  
• 步驟 4：從應(yīng)用程序上下文取回安全 bean
  安全 bean 與不安全 bean 的取回方式類似，惟一區(qū)別是：當您通過調(diào)用 getBean() 方法嘗試取回安全 bean 時，您將獲得安全對象的代理而不是實際的對象。該代理就是我在 “Spring IOC 發(fā)揮效用” 步驟 4 中解釋的由 Spring 框架創(chuàng)建的同一個對象。
  
  
• 步驟 5：調(diào)用安全 bean 的方法
  當調(diào)用安全 bean 的方法時，您在 步驟 4 中獲得的代理對象將一個方法調(diào)用請求分配給攔截器。攔截器將檢查試圖訪問方法的用戶是否具有相應(yīng)的訪問權(quán)，從而處理方法調(diào)用請求。

您現(xiàn)在應(yīng)該對 Spring 框架如何創(chuàng)建 Java 對象以及客戶機應(yīng)用程序如何與之交互有了清晰的了解。了解了這些內(nèi)容后，就更加容易理解并利用 Acegi 的方法安全性攔截器，下一節(jié)將具體介紹該主題。

回頁首

配置 Acegi 的方法安全性攔截器

只要應(yīng)用程序試圖訪問由 Acegi 安全系統(tǒng)保護的 bean 方法，請求將被自動傳遞到 Acegi 的方法安全性攔截器。方法安全性攔截器的作用就是控制對安全 Java bean 的方法的訪問。攔截器使用 Acegi 的身份驗證和授權(quán)框架確認用戶是否具有權(quán)利調(diào)用安全 Java bean 的方法，然后相應(yīng)地作出響應(yīng)。

清單 5 展示 Acegi 的方法安全性攔截器的示例配置：

            <bean id="privateCatalogSecurityInterceptor"
            class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
            <property name="authenticationManager">
            <ref bean="authenticationManager"/>
            </property>
            <property name="accessDecisionManager">
            <ref bean="accessDecisionManager"/>
            </property>
            <property name="objectDefinitionSource">
            <value>
            sample.PrivateCatalog.getData=ROLE_HEAD_OF_ENGINEERING
            <!-- Roles required by other beans -->
            </value>
            </property>
            </bean>
            

清單 5 所示的攔截器配置包含三個需要進行配置的屬性，可以保護對 Java bean 的訪問：authenticationManager、accessDecisionManager 和 objectDefinitionSource。

回憶一下，您在本系列第 1 部分的 配置身份驗證處理過濾器 中曾對 authenticationManager 屬性進行了配置。authenticationManager 屬性的作用是對用戶進行身份驗證。

您在本系列的第二篇文章中了解了 accessDecisionManager 屬性。這個訪問決策管理器負責制定授權(quán)決策。在允許對一個安全 bean 進行訪問之前，方法安全攔截器使用 authenticationManager 和 accessDecisionManager 屬性對用戶進行身份驗證和授權(quán)。

現(xiàn)在查看 清單 5 中配置的 objectDefinitionSource 屬性。它類似于第 1 部分中出現(xiàn)的 objectDefinitionSource 屬性。以前的 objectDefinitionSource 包含類似于 /protected/* 和 /** 這樣的 URL，清單 5 中的 objectDefinitionSource 屬性指定類和方法名；例如，sample.PrivateCatalog 是之前執(zhí)行過代理的類的名稱，而 getData 是您希望對其控制用戶訪問的方法的名字。

當用戶訪問 PrivateCatalog bean 的 getData() 方法時，控制權(quán)將自動傳遞給攔截器。攔截器使用 Acegi 框架檢查用戶的業(yè)務(wù)角色是否為 ROLE_HEAD_OF_ENGINEERING（特定于本文的示例）。如果是的話，攔截器將允許對 getData() 方法進行訪問。如果攔截器發(fā)現(xiàn)用戶角色不是 ROLE_HEAD_OF_ENGINEERING，則拒絕訪問。

下一節(jié)將查看一個示例 Acegi 應(yīng)用程序，它將實現(xiàn)您目前所了解的所有概念。

回頁首

示例 Acegi 應(yīng)用程序

本文的 下載源代碼 包含了一個名為 AcegiMethodSecurity 的示例應(yīng)用程序，可按照以下方法進行配置和部署：

1. 使用用戶信息填充 LDAP 服務(wù)器。下載的示例應(yīng)用程序 包含一個 LDIF 文件，其中含有預備裝載到 LDAP 服務(wù)器的用戶信息。關(guān)于如何將 LDIF 文件導入到 LDAP 服務(wù)器，請參考第 2 部分的 “填充服務(wù)器” 一節(jié)。注意，該應(yīng)用程序涉及與第 2 部分相同的用戶（alice、bob 和 specialUser）。
   
   
2. 將本文下載源代碼中的 acegiMethodSecurity.war 文件復制到 Tomcat 安裝目錄中的 webapps 目錄。
   
   
3. 將 Acegi 的 jar 文件復制到示例應(yīng)用程序的 WEB-INF/lib 文件夾。（有關(guān)內(nèi)容請參考第 1 部分的 “部署和運行應(yīng)用程序” 一節(jié)。 ）
   
   
4. 下載 cglib-full-2.0.2.jar 文件并將其復制到示例應(yīng)用程序的 WEB-INF/lib 文件夾。

啟動 Tomcat 并嘗試運行示例應(yīng)用程序。

運行示例應(yīng)用程序

通過從瀏覽器訪問 http://localhost:8080/acegiMethodSecurity URL 可調(diào)用示例應(yīng)用程序。AcegiMethodSecurity 顯示的索引頁面包含兩個鏈接（Catalog 和 Login），如圖 2 所示：

當單擊應(yīng)用程序的 Catalog 鏈接時，它將要求您進行登錄。如果以 alice 或 specialUser 的身份進行登錄，示例應(yīng)用程序?qū)⑻峁?em>完整的 類別，包括公有數(shù)據(jù)和私有數(shù)據(jù)。這是因為在 清單 5 中，您對方法安全性攔截器進行了配置，允許用戶使用 ROLE_HEAD_OF_ENGINEERING 訪問私有類別，而 alice 和 specialUser 都具有該訪問權(quán)。另一方面，如果您以 bob 的身份登錄，示例應(yīng)用程序?qū)H顯示公有數(shù)據(jù)。

回頁首

為通過身份驗證的用戶分配額外角色

本節(jié)將演示經(jīng)過增強的示例應(yīng)用程序。增強后的示例應(yīng)用程序?qū)⒄故?Acegi 如何使您能夠在運行時向通過身份驗證的用戶臨時分配額外角色。

當安全 bean（例如 清單 3 的 privateCatalog bean）要訪問一個原創(chuàng)資源時，您可能需要使用額外的角色。例如，您可能考慮到您的安全 bean 需要通過 Java 的 Remote Method Invocation (RMI) 框架或一個 Web 服務(wù)訪問某個遠程應(yīng)用程序。訪問安全 bean 的用戶不會占用遠程應(yīng)用程序要求訪問用戶所具備的業(yè)務(wù)角色。

在本例中，Acegi 首先檢查用戶是否經(jīng)過授權(quán)來訪問安全 bean。之后，Acegi 允許用戶訪問安全 bean。當安全 bean 試圖訪問遠程服務(wù)時，它需要使用額外的業(yè)務(wù)角色。如果訪問安全 bean 的用戶不具備額外角色，安全 bean 就不能成功訪問遠程服務(wù)。

run-as-replacement 機制

Acegi 框架提供了一種名為 run-as-replacement 的簡單機制，允許您僅在方法調(diào)用期間為通過身份驗證的用戶配置一個或多個額外角色。您可以使用 run-as-replacement 機制為訪問遠程應(yīng)用程序的安全 bean 配置額外角色。這意味著只要安全 bean 需要訪問遠程應(yīng)用程序，Acegi 將為用戶裝載額外角色，從而允許安全 bean 訪問遠程應(yīng)用程序。

清單 6 對 清單 5 中的方法安全性攔截器的配置進行了增強。增強后的配置使用了 run-as-replacement 機制。

            <bean id="privateCatalogSecurityInterceptor"
            class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
            <property name="authenticationManager">
            <ref bean="authenticationManager"/>
            </property>
            <property name="accessDecisionManager">
            <ref bean="accessDecisionManager"/>
            </property>
            <property name="runAsManager">
            

                <bean id="runAsManager"
            class="org.acegisecurity.runas.RunAsManagerImpl">
            

                     <property name="key">
                        <value>myKeyPass</value>
                     </property>
                </bean>
              </property>
            <property name="objectDefinitionSource">
            <value>
            sample.PrivateCatalog.getData=ROLE_HEAD_OF_ENGINEERING,RUN_AS_MANAGER
            </value>
            </property>
            </bean>
            

清單 6 使用粗體顯示了兩處增強（與 清單 5 相比）。第一處增強為 runAsManager 屬性。runAsManager 屬性的作用是向通過身份驗證的用戶動態(tài)添加角色。出于這個目的，runAsManager 屬性包含了 RunAsManagerImpl bean 的定義。RunAsManagerImpl bean 只有在滿足下面的條件時才可變?yōu)榛钴S狀態(tài)：在 objectDefinitionSource 方法的角色定義中找到以 RUN_AS_ 為前綴的角色。例如，PrivateCatalog.getData() 方法的角色定義（清單 6 中以粗體顯示的第二處增強）具有一個 RUN_AS_MANAGER 角色。

RunAsManagerImpl bean 包含一個名為 key 的屬性，它封裝的加密鍵用于確保只將額外的角色作為 run-as-replacement 程序的一部分生成。

當用戶調(diào)用 getData() 方法時，RunAsManagerImpl bean 變?yōu)榛钴S狀態(tài)并創(chuàng)建名為 RUN_AS_MANAGER 的額外角色，從而啟用 getData() 方法訪問遠程應(yīng)用程序。

增強的方法安全性

本文的 下載源代碼 包含一個名為 EnhancedAcegiMethodSecurity 的示例應(yīng)用程序，它可以演示 run-as-replacement 機制和程序。該應(yīng)用程序?qū)@示一個具有 Catalog 鏈接的索引頁面。如果單擊 Catalog 鏈接，將要求進行登錄。

登錄后，EnhancedAcegiMethodSecurity 應(yīng)用程序?qū)槟峁┑卿浻脩艏捌浣巧耐暾畔ⅰ＠纾绻?alice 或 specialUser 身份登錄，將向您顯示用戶的所有業(yè)務(wù)角色，包括額外創(chuàng)建的臨時的 RUN_AS_MANAGER 角色。

結(jié)束語

在這份共分三部分的系列文章中，我介紹了如何使用 Acegi 安全系統(tǒng)增強基于 URL 的安全性和基于方法的安全性。您了解了如何設(shè)計訪問控制策略并將它們托管在目錄服務(wù)器中，如何對 Acegi 進行配置以與目錄服務(wù)器進行通信，以及如何根據(jù)托管在服務(wù)器的訪問控制策略制定身份驗證和授權(quán)決策。

本系列的最后一篇文章主要介紹使用基于方法的安全性保護 Java 類實例。文章還解釋了 Acegi 和 Spring 如何在內(nèi)部創(chuàng)建和代理 Java 對象以及 bean 代理如何實現(xiàn)訪問控制。文章包含了兩個示例應(yīng)用程序，您可以使用它們進一步研究本系列中學到的概念，更多有關(guān)使用 Acegi 保護 Java 應(yīng)用程序的內(nèi)容，請參見 參考資料 小節(jié)。

posted @ 2008-05-08 18:47 狼愛上貍 閱讀(419) | 評論 (0) | 編輯 收藏