再提 Ubuntu/Debian 下 JAVA 中文显示

posted @ 2008-05-31 22:17 狼爱上狸 阅读(618) | 评论 (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一样的证书来执行该命令，这里使用

containercert.pem和containerkey.pem来生成一个containerproxy.pem，最后使用这个代理证书来关闭

container。如果你遇到说找不到/tmp/x509up-uuid（uid是你用来执行globus-stop-container的用户的uid）

文件的情况，可以试图采用上面的方式来解决这个问题。

posted @ 2008-05-28 12:05 狼爱上狸 阅读(881) | 评论 (6) | 编辑 收藏

网格开发人员：值得关注的组织和项目

级别： 初级

Edna Nerona (edna@legacystudios.biz), 顾问, Legacy Studios, Inc.

2007 年 8 月 09 日

之前，我们向您提供了一份 “网格开发人员推荐阅读清单” 和 “面向网格开发人员的入门级开源工具”。现在我们又编著了一份代表网格计算未来发展的产品项目和组织清单。本文提供了在目前在不同领域（例如癌症研究、天文学和物理学）中开展的项目的详细清单。本文还介绍了工具包、安全性和数据管理。它们都是从各种在线资源获得，向程序员、管理员和新用户介绍了与使用、部署和开发网格基础设施有关的具体信息和项目。

开发网格的组织

本节将介绍开发网格产品的组织，它们所解决的问题，以及它们是如何影响网格技术的。网格部署产品可以划分为几类：通用网格、科学和社区网格、国家网格、地区网格和大学网格。

国家和国际通用网格

Distributed European Infrastructure for Supercomputing Applications

作为一个领导国家超级计算中心的协会，DEISA（Distributed European Infrastructure for Supercomputing Applications）部署并操作了一个具有安全产品质量的分布式超级计算环境。通过增强欧洲在高性能计算方面的能力，该研究组织促进了各种科学和技术领域中的科学发现。DEISA 对现有国家高端平台进行了高度集成，使用了专用的网络，并获得了新型系统和网格软件的支持。

DutchGrid

成立于 2000 年，DutchGrid 拥有很多成功的研究成果和计划，跨越多个科学协作领域。作为一个学术和研究网格计算的开放平台，DutchGrid 为荷兰的网格用户提供了可全球识别的身份证书。DutchGrid CA 是一个完全中立的项目。任何非盈利的研究人员和学术界用户都可以获得个人和服务器或主机证书来使用网格应用程序。

Enabling Grids for E-science

Enabling Grids for E-science （EGEE）项目将来自 32 个国家的 90 多个机构的科学家和工程师组织在一起，为科学家使用的电子科学（e-scinece）提供了一个无缝的网格基础设施。EGEE 网格包含了超过 30,000 个 CPU，它们可以一周 7 天、每天 24 小时地使用，另外还提供了大约 5 PB（5 百万个 GB）的存储空间，平均要维护 30,000 个并发作业。拥有如此众多的资源改变了科学研究所采用的方法。EGEE 是由欧盟建立的一个为期 4 年的项目。

Grid5000

Grid5000 项目的目标是建立一个高度可配置的具有可控性并可监视的实验网格平台，网格研究人员可以使用它来试验从网络协议层到应用程序层之间的所有软件。Grid5000 将法国地理上分布的 9 个城市连接在一起，提供了 5,000 个 CPU。这 9 个城市包括：Bordeaux、 Grenoble、 Lille、 Lyon、 Nancy、 Orsay、 Rennes、 Sophia-Antipolis 和 Toulouse。

LA Grid

LA Grid 的发音是 “lah grid”，它是第一个全面的计算网格，将来自美国、拉美和西班牙各个机构的职员、学生和研究人员联系在一起，协作开发可满足医疗服务行业内商业和社会需求的复杂行业应用程序。除了大学之外，LA Grid 还吸引了全球工业界的参与，从而增强了在很多领域内的创新，包括卫生保健、生命科学和飓风灾难以及灾难防御。

Open Science Grid

Open Science Grid （OSG）是科学研究使用的一个分布式计算基础设施。OSG 联盟是惟一一个由各大学、国家实验室、科学协作组织和软件开发人员将海量计算和存储资源组成一个共享的统一网络基础设施的联盟。

TeraGrid

TeraGrid 是由 National Science Foundation 创建的一个开放科学研究基础组织。将 9 个合作站点的业界领先的资源组合起来，TeraGrid 创建了一个集成的持久计算资源。通过采用国家专用网络的一条高速千兆网络彼此连接，TeraGrid 提供了超过 150 teraflops 的计算能力、以及接近 2 PB 的循环存储空间、无数的科学数据集、专用的数据分析工具、科学网关、以及用来简化对有价值资源和可视化资源访问的用户门户。

科学和社区网格

AstroGrid

AstroGrid 是一个开源项目，它的建立是为英国和国际天文学家创建一个工作用的虚拟天文台（Virtual Observatory，VO）。AstroGrid 是由英国政府建立，它通过 International Virtual Observatory Alliance （IVOA）与国际上其他 VO 项目紧密协作。作为这个社区的领导成员之一，AstroGrid 提供了国际通用的接口标准，用来促进天文数据的科学集成，并在全球范围内处理资源。

cancer Biomedical Informatics Grid

cancer Biomedical Informatics Grid （caBIG）是一个自发组织的网络或网格，它将个人和机构联系在一起，可以共享很多数据和工具，它创建了一个全球范围的癌症研究资源。caBIG 的目标是为了加速癌症预防和治疗方面的创新方法的迅速问世。caBIG 所创建的基础设施和工具在癌症社区之外也有很广泛的应用。caBIG 目前正在 National Cancer Institute 的 Center for Bioinformatics 的领导下进行开发。

International Virtual Data Grid Laboratory

International Virtual Data Grid Laboratory （iVDGL）是一个全球的数据网格，用于物理和天文领域的前沿实验。它的计算、存储和网络资源分布于美国、欧洲、亚洲和南美，提供了一个独特的实验环境，可用来测试和验证国际的和全球范围的网格技术。位于欧洲和美国的站点通过一个由 European DataTAG 项目创建的数千兆每秒的跨越大西洋的链接链接在一起。

World Community Grid

World Community Grid 的使命是创建全世界最大的公共计算网格，研究对人类有益的项目。World Community Grid 的成功在于：集合了个体为实现更美好的世界而贡献出的未用的计算时间。World Community Grid 正在研究一些公共和非盈利组织才能使用的技术，从而开展一些人道主义研究；如果没有公共网格，高昂的计算基础设施将使研究无法完成。

Worldwide Large Hadron Collider Computing Grid

Worldwide Large Hadron Collider（LHC）Computing Grid 的目的是处理 2007 年前 CERN 的 LHC 所开展的实验所产生的空前数据量。LHC 开展的实验的计算需求极为庞大。每年大概会生成 12 到 14 PB 的数据，这大约相当于 2 千万张 CD。对这些数据进行分析大约需要 70,000 台目前最快的 PC。通过部署一个全球范围的计算网格，将分布在欧洲、美国和亚洲的科学计算中心的资源集成到一个全球虚拟化计算服务中，LHC Computing Grid 可以满足这些需求。

回页首

美国地区的网格

Northwest Indiana Computational Grid

Northwest Indiana Computational Grid（NWICG）是来自 Purdue University-West Lafayette、 Purdue University-Calumet 和 University of Notre Dame 的合作研究和教育组织。NWICG 重点关注的是国家科学和研究活动，其创建的网络基础设施可以支持重大问题的解决方案，以及在高性能计算底层技术领域启用保持世界领先的技术。它们正在 Department of Energy's Argonne National Laboratories 的协助下，在这 3 个大学之间为 Northwest Indiana 开发一个可扩充的高速、高带宽的科学驱动计算网格。

SURAGrid

Southeastern Universities Research Association（SURA）是一个组织协作联盟，它合并各种资源以将网格技术上升到无缝的共享基础设施。SURAgrid 着重关注的是对大量分布式能力的直接访问，从而用于研究和教育社区。SURAgrid 促进了以下领域的开发：所贡献的资源、项目特有的工具和环境、高度专门化访问、通往国家和国际的网络基础设施网关。

Texas Internet Grid for Research and Education

Texas Internet Grid for Research and Education （TIGRE）项目的使命是将整个得克萨斯州的计算系统、存储系统、数据库、可视化实验和显示以及仪器和传感设备整合在一起，创建一个计算网格。通过集成强大的计算能力，为得克萨斯州在学术、政府以及工业界的研究人员提供增强的计算能力，TIGRE 希望能够对生物医学、能源和环境、航空宇宙、材料科学、农业和信息技术的进步提供帮助。

回页首

开源网格项目

这些网格项目覆盖了很多领域，包括网格基础设施工具包、中间件工具包、数据工具、安全等。下面给出了一些迅速发展的网格项目和工具。经常访问这些站点可以了解有关它们领导网格技术不断发展的最新消息。

网格基础设施项目

帮助建立自己网格的开源网格基础设施项目。

Berkeley Open Infrastructure for Network Computing

Berkeley Open Infrastructure for Network Computing （BOINC）是项目使用的一个软件平台，例如 distributed.net 和 SETI@home，它使用了数百万台志愿者计算机组成一个并行的超级计算机。可以获得该平台的源代码，并且鼓励感兴趣的 C++ 开发人员帮助开发平台代码。BOINC 目前可以支持 Windows®、Linux®、UNIX® 和 Mac OS X。 CPU 平台的需求可能在使用 BOINC 的项目客户机之间会有所不同。

Uniform Interface to Computing Resources

Uniform Interface to Computing Resources（UNICORE）提供了一个可随时运行的网格系统，包括客户机和服务器软件。UNICORE 让分布的计算和数据资源在内部网和互联网上以一种无缝的安全方式使用。UNICORE 设计的重点是几个核心原则：无缝访问异构环境、安全性、站点自治、易于使用的强大的 GUI 客户机，以及可以进行简单安装的快速启动包。

网格中间件项目

以下项目已经为美国和国际项目提供了一些高级工具，可以简化访问大量网格功能，例如计算、可视化和存储资源。您可以与不同的网格进行交互，或者为自己的网格进行定制。

gLite

gLite 是网格计算使用的下一代中间件，它诞生于 12 个学术机构和行业研究中心的 80 多个工作人员的联合努力，是 EGEE 项目的一部分。gLite 充分利用分布在 Internet 上的计算和存储资源，为构建网格应用程序提供了一个最佳框架。

National Research Grid Initiative

National Research Grid Initiative（NAREGI）位于日本，它着重于网格中间件的研究和开发，为广泛分布的、高级研究和教育目的实现大规模的计算环境。

Ninf-G

Ninf 也是日本的一个项目，正在开发编程中间件，使用户能够通过一个简单易用的接口来访问各种资源，例如网格中的硬件、软件和科学数据。Ninf-G 是一个开源软件，支持开发和执行分布式计算资源中使用 Grid Remote Procedure Call（GridRPC）的启用网格的应用程序。

NorduGrid

NorduGrid 中间件，也称为 Advanced Resource Connector（ARC），是一个按照 GPL 许可发布的开源软件解决方案，可以实现保证产品质量的计算和数据网格。ARC 为基本网格服务提供了一个可靠实现，例如信息服务、资源查找和监视、作业提交和管理、代理和数据管理，以及资源管理。大部分服务都是通过 GSI 的安全层提供的。中间件是在诸如 OpenLDAP、OpenSSL、SASL 和 Globus Toolkit（GT）之类的开源解决方案基础上构建的。

OGSA-DAI

OGSA-DAI 项目着重关注的是中间件的开发，从而有助于对网格中不同来源的数据进行访问和集成。这个项目与 Globus、OMII-Europe、NextGRID、SIMDAT 和 BEinGRID 紧密协作，确保 OGSA-DAI 软件可以在各种网格环境中很好地工作。

ProActive

ProActive 是 Java™ 网格中间件库（其开源代码具有 LGPL 许可），可用于进行并行、分布式和多线程计算。通过采用一个简单元语的精简集，ProActive 提供了一个详尽的 API 来简化网格计算应用程序的编程，这些程序均分布在 LAN、工作站集群和 Internet 网格中。

安全项目

为了保护重要的基础设施和信息，安全性需求一直以来都随网格计算的发展而演变。这些项目代表了一些网格安全解决方案的一些最先进的安全标准和实现。

GridShib

GridShib 是在 NCSA 和 University of Chicago 之间开展的由 NFS 创建的项目，用来将联合授权基础设施（Shibboleth）与网格技术（Globus Toolkit）进行集成，从而为分布的科学社区提供基于属性的授权。

Grid User Management System

Grid User Management System（GUMS）是一个网格身份映射服务（Grid Identity Mapping Service）。当站点资源不使用本地网格凭证，而是使用一种不同的机制来标识用户时（例如 UNIX 帐号或 Kerberos 准则），就需要使用身份映射。

PRIvilege Management and Authorization

PRIvilege Management and Authorization（PRIMA）是一个提供增强的网格安全的系统。PRIMA 是一个全面的网格安全模型和系统。在 PRIMA 中，特权是一种与平台无关的、细粒度权限的自包含表示。PRIMA 通过从资源内部表示来具体化对资源对象的细粒度访问权限实现了特权的平台无关性。

资源管理和调度

网格的一个基本部分就是在资源之间管理和调度作业。下面这些项目展示了有关的一些策略。

Community Scheduler Framework

Community Scheduler Framework（CSF）是一个基于 OGSA 的元调度器的开源实现。它可以支持最新的 WS-Agreement 规范和 Globus Toolkit 的 GRAM 服务。CSF 填补了现有资源管理现状的不足，并集成了 Platform LSF 和 Platform Multicluster。CSF 开源项目已经包括到了 Globus Toolkit V4.0 发行版中。

Special Priority and Urgent Computing Environment

高性能建模和仿真在决策制定和预测方面起到了推动作用。对于时间关键型的应急应用程序，例如灾害天气预报、洪水建模、流感建模，任何延时会使结果变得毫无用处。这需要使用专用的基础设施快速、自动而且可靠地提供计算资源。Special Priority and Urgent Computing Environment（SPRUCE）是一个用来在传统超级计算机和分布式网格上支持紧急或事件驱动计算的系统。

网格资源监视

对资源和应用程序的监视是网格成功的关键。通过一个简单易用的接口，这些复杂工具可以帮助用户搜集、分类和监视各种类型的资源。另外，系统管理员还可以监视网格的健康状况。这些不断发展的网格项目列出了几个开源选择。

GridCat

GridCat 是一个在地理图上使用状态点以及编目的高级网格编目系统。这个图可以帮助调试站点问题。编目中包含了有关站点的准备信息，以及每个站点的很多其他有价值的信息，帮助应用程序用户和网格调度器开发人员进行作业提交和作业调度。GridCat 尝试在其最简单的状态表示中表示网格站点。

Gridscape II

Gridscape II 是一个定制的门户组件，可以在其自身的网格门户中使用，也可以插入到现有网格门户中。Gridscape II 负责从各种异构和分布式资源中搜集信息，并在单个界面中无缝地将它们呈现出来。它充分利用了 Google Maps API 来提供一个高交互性的用户界面。Gridscape II 非常简单易用，为那些不希望大量投资以从头开始开发自己的监视门户的用户提供了一个解决方案，也为那些希望简化定制内容的用户提供了一种解决方案。

存储和数据管理

从开源高性能文件系统到无缝地访问异构环境中的数据，以下项目集合了各种存储和数据管理解决方案并进行了优化。这种趋势强调的是资源之间的数据存储、管理和移动，以及通过网络对数据资源的连接。

Lustre

Lustre File System，这是一个来自 Cluster File Systems Inc. 的高性能开源文件系统，它是一个分布式文件系统，消除了很多传统分布式文件系统中存在的性能、可用性和可伸缩性问题。Lustre 是一个高度模块化的下一代存储架构，它将现有的开放标准、Linux 操作系统和创新协议组合成一种可靠的、网络中立的数据存储和检索解决方案。通过在集群和数据共享环境中提供高 I/O 吞吐量，Lustre 还提供了与物理存储上的数据位置无关的独立性，防止单点失效，并且可以从集群的重新配置和服务器或网络故障中快速恢复。

NeST

NeST 是一个软件网络存储设备，为特定时间段提供了安全的存储分配。分配单元或份额（lot）的大小和持续时间可以在 NeST 和用户或应用程序之间进行协商。这些份额的大小也可以扩充，时间可以扩展，或者划分成不同的层次。另外，NeST 还为份额和文件访问提供了访问控制列表。NeST 提供了多种协议接口，包括内部使用的 Chirp、HTTP 和 GSI-FTP。

SAMGrid

SAMGrid 是一个通用数据处理系统，它被设计为用来测试大量数据（PB 级）集和广泛分布的产品和分析工具的一个关键设备。当前产品的组件提供了大量的服务，可用于分布式系统中的数据传输、数据存储和进程记录。

UberFTP

UberFTP 是在 GridFTP 基础上构建的，它是第一个启用 GridFTP 的交互式 FTP 客户机。基本的 GridFTP 客户机不是可交互式的，它一次只允许传输一个文件。UberFTP 提供了交互式工具，工作方式与流行的 NCFTP 工具类似。它支持 GSI 认证、并行数据通道以及第三方传输功能。

回页首

结束语

网格计算是最令人兴奋的技术之一，它在很大程度上影响了我们解决复杂问题和共享各种资源的方式。除了癌症和物理学之外，它对于安全和认证、查找、监视、信息服务、数据管理、资源管理和调度也有重大影响。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
  
  
• 查看 developerWorks 中的 “网格计算文档库”。
  
  
• 要收听面向软件开发人员的有趣访谈和讨论，请查看 developerWorks podcasts。
  
  
• 随时关注 developerWorks 的 developerWorks 技术活动和网络广播。
  
  
• 了解世界范围内面向 IBM 开源开发人员的即将召开的会议、商业展示、webcasts 和其他 事件。
  
  
• 请访问 developerWorks 中国网站开源软件技术专区，这里有丰富的 how-to 信息、工具和项目更新信息，可以帮助您使用开源技术进行开发，并与 IBM 产品一起使用。
  
  

获得产品和技术

• 请下载 IBM 产品评测版，尝试使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
  
  
• 使用 IBM 试用软件 改进您的下一个开源开发项目，这些软件可以从 developerWorks 下载或从 DVD 获得。

讨论

• 请访问 developerWorks 上的 网格计算论坛。
  
  
• 通过参与 developerWorks blogs，加入 developerWorks 社区。
  
  

关于作者

		Edna Nerona 是 Legacy Studios，Inc. 的所有人，这是一家位于 San Diego 的创新服务公司。她拥有 San Diego State University 的新闻学学士学位，曾经在 San Diego Supercomputer Center 和 Entropia，Inc. 工作过。她还是 Toastmasters International 的一名多才多艺的发言人。

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

posted @ 2008-05-23 10:55 狼爱上狸 阅读(542) | 评论 (0) | 编辑 收藏

羽球服装及附件

羽球服装及附件：

羽毛球服装选择相对容易了很多。但不是任何运动衫都有资格可以成为羽毛球衣。选择的时候还是要有一些原则的。不要选择纯棉的衣服，因为纯棉的衣服虽然吸汗，但是能力有限，并且不容易蒸发，随着汗水的吸收，自重会加大，到最后会贴在身上，非常的不舒服。夏季不要选择涤棉的衣服，涤棉的衣服虽然比纯棉舒服了很多，但天气炎热的时候还是会出现与纯棉服装一样的结果。冬季如果不是在非常温暖的地区，选择涤棉服装会提高保暖性能。不要选择过于贴身的衣服。过于贴身的衣服有可能会限制球员的运动范围，打球的时候会不太舒服。要选择轻量化服装。并不是每一件衣服都会像知名品牌羽球服装那样的轻盈。进行羽毛球运动时，最好还是穿着专门的羽毛球品牌服装，或是针对羽毛球运动的特点而开发出来的服装。YONEX的衣服具有加热降温功能。夏天和冬天分别能提供低3度和高3度的感觉，是羽球服装的精品。选择运动短裤时要选弹性大的，因为羽毛球运动经常需要球员以蹬跨步移动，一件有弹性的运动短裤可以使动作更舒展而不必担心对服装构成任何伤害。

羽球服装特点简述：

YONEX：

YONEX品牌的服装上镜率最高。其特点也比较明显。材料大致分两大类，特殊功能性纤维和普通功能性纤维。

普通功能型纤维就是常见的YONEX 100％涤纶（polyster）的产品。这里要特别说明的是，有很多走私水货的YONEX服装，或假冒的YONEX服装，都是涤＋棉的。这种衣服的排水性和蒸发汗水能力都远差于正品行货。在天气较热出汗量较大时穿着，衣服会因含有棉的成分而粘贴在身上。令人非常难受。但因其售价低廉，还是可以迎合一小部分人的消费需要。SHBC不推荐穿着这样的服装上场打球，如果真的不愿意花很多钱来购买YONEX品牌的服装，还有KASON服装可供选择。KASON的服装也有100％涤纶（polyster）的，在提供了较低价格的同时，保证了羽球服装应有的性能。

特殊功能性纤维指的是YY的HEAT CAPSULE(热囊)和VERY COOL(冷却)纤维。这两种材料成分标识其实也是100％涤，但所用的材料与普通的YONEX服装不同，VERY COOL服装一般在领子后面的吊牌下方都会带有VERY COOL的标记，比较好辨认。 需要注意的是，SP版的衣服使用了一种叫做TRUE COOL的标记，TRUE COOL的标记与VERY COOL类似，但所谓的TRUE COOL是100％棉生产的，这种衣服很明显是根本不值得购买的。且棉产品容易起皱，放在球包内挤压后穿着会比较难看。

VERY COOL和HEAT CAPSULE可以提供升高三摄氏度或降低三摄氏度的体表感受，在适当的季节穿着相应特性的产品打球，是非常舒适的。因其功能特殊，价格较一般产品贵了不少。约为普通功能型纤维衣物的1.5-2倍，但因其舒适性出色，还是很受欢迎的。

VICTOR(胜利）的服装以及KASON（凯胜）的服装虽然品牌不如YONEX那么出名，但衣服的质量是不错的。尤其是VICTOR的服装，06年的设计非常新颖，色彩也很讨好。一样是排汗速干面料，不是非常追求品牌的话，穿起来一样很舒服。

其他还有如BONNY(波力）的银纤维，竹炭纤维也是很不错的衣服，只是设计实力略欠缺，如果能买到心仪的款式，也是很好的选择。

羽毛球袜：

很多人觉得自己的袜子已经够厚了，没必要花几十块去买一双名牌羽球袜，就算是KASON,FLEX等品牌，一双袜子也要二十元以上，其实这种想法是不对的。再厚的袜子，也很难比的上专业羽球袜的厚度。很多对此想法持怀疑态度的人，在亲手摸过羽毛球袜以后，往往会立刻购买。足见普通加厚运动袜与专业羽球袜的区别。

勿庸置疑，YONEX的VERY COOL羽毛球袜是穿着最舒适的羽毛球袜了。关于VERY COOL，这里就不再多说了。价格要比一般的袜子略贵一些，有条件的话这是第一选择。

其他品牌如VICTOR,KASON,FLEX的袜子质量基本相同，价格低但是品质不低，也都可以起到良好的保护作用。只是没有VERY COOL那么舒服。

需要注意的是，一双正品羽毛球袜的厚度大致相当于半码鞋，考虑到运动中双脚会继续充血膨胀，买鞋最好大1码。

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

posted @ 2008-05-19 16:08 狼爱上狸 阅读(208) | 评论 (0) | 编辑 收藏

羽毛球拍选购

羽毛球拍：

拍子的选择是目前球友们最关心的一个问题了。在上羽网论坛上每天要有很多次发言是与球拍的选择有关的。虽然球拍是一个很重要的部分，但在实际运动中，球拍的重要性被夸大了不少。需要强调的是，一把好的球拍可以给使用者以信心，但是根本不可能提高使用者自身的水平。

目前几乎所有的球拍都是碳素，石墨复合材料制成的。有些生产商喜欢加一些特殊的材料如TI金属网，KEVLAR（凯芙拉），纳米复合材料。需要着重说明的是，这些附加材料只占了总材料的一少部分，一支球拍的99％以上始终还是这种碳素石墨复合材料。附加材料带给球拍性能的改变并不会是非常明显的,但确实有效。

羽毛球拍是球员和球之间的“中介”，由以下几种特性来分类：形状，硬度，重量，平衡点。

目前的球拍主要有两种形状：圆头拍和方头拍。圆头拍就是传统的拍形，拍头上部略尖，球拍整体呈卵形。这种卵形球拍甜区较小，但甜区部位力量爆发非常的集中。圆头拍对初学者来说较难上手。目前此类拍头的球拍型号已经不是很多了。方头拍(ISO拍面)是后起之秀，因其甜区巨大在90年代初期后迅速风靡全球。

球拍的硬度类似于拍线的拉力大小。越硬的球拍需要越大的力量驱动，反之亦然。

球拍的重量是多样化的。常见的球拍重量范围一般在80－95克。同拍柄尺寸单位一样，不同的厂商有各自的重量单位定义，但是最流行的就是YONEX公司所使用的U系统。U＝95－100克，2U＝90－94克，3U=85-89克，4U＝80－84克，5U＝79－75，一般常用的球拍基本上都是2U-4U，79克以下的一般都叫做超轻拍，主要是设计给女性，或有特殊需要的球友。而95克以上的一般都是金属拍，主要是给以打羽毛球为健身手段而不愿在器材上花费过多的人。

球拍的重量决定了挥拍速度。使用同样的挥拍力量，越轻的球拍可以产生越高的挥拍速度。简单来说，越轻的球拍使用起来越灵活。但是球拍并不是越轻越好的，因为越轻的球拍就越不稳定，需要越多的力量保持其运动轨迹。重一些的拍子在挥动时可以带有更多的动能，击球瞬间可以产生更大的势能。这就是为什么很多进攻型的拍子头都会比较重的原因。

球拍的平衡点决定了一支球拍的重量分部情况。目前市场上的很多球拍都已经是头重型的了，头重型的球拍在挥动时可以更加的稳定，而平衡型球拍更灵活一些。

球拍的选择是非常个性化的，没有任何人可以说某种球拍的某种特性就一定强过另一种。选择球拍可以参考一些专业意见，但最终如何选择还是要由自己来决定。

YONEX球拍特点：

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

NS6000的拍杆较软，带有LSC减震系统，是YONEX于2006年推出的专为女性设计的球拍。该拍拍身较柔软，ISO（小平头）拍面，适合女性使用。

NS7000，此拍是为中高级业余选手设计的。采用8mm粗杆，杆身弹性很好，拍头采用破风设计，ISO中型拍面，用于防守时非常轻松。平抽挡能力低于NS8000，MP-100等。由于平衡点适中，驱动轻松，所以拉后场球比较容易。杀球威力与TI-10,MP-100相比略有不足。适合控球型选手。此拍曾被国家队混双世界冠军高凌所选用。

NS8000，此拍是目前纳米系列中销量很大的型号。目前销量甚至要超过最新款的NS-9000。拍框10点2点位以及拍杆顶端采用了C60(弗拉伦)填充的纳米材料。7mm细杆，爆发力极好。摒弃了传统的吹气管工艺而采用了发泡材料成型的制作方法，使拍框稳定性更好，击球时落点非常准确。采用了单向线孔设计，使球拍受力更加均匀，更耐用。因其弹性出色，拉球比较省力。均衡的设计使此拍处理网前球轻松自如，用于双打时，NS8000平抽挡出球的速度比NS7000要快。虽然是轻量化设计，但在YONEX球拍坐标中，NS8000进攻能力以极微小差别仅低于MP-100。因其拍头较轻，连续进攻能力很强，在业余选手中此拍比MP-100更受欢迎，销量很大。

NS9000，最新款重型武器。拍头明显重于NS8000。9000的出现将MP-100赶下了进攻王者的宝座。分为S/X两款分别对应硬和超硬两种中杆硬度。8mm粗杆拍柄加长，想要用好NS9000确实需要一些力量的支持。同样采用发泡成型的制作方法。新的线孔位置，将球拍击球甜区略微上移。ELASTIC TI的使用是拍框的稳定性和弹性都有不小的进步。关于此拍更详细的内容，可参考本论坛steven_gu所作的“NS-9000使用体会”一文。

AT系列

AT系列是TI系列高端拍升级后的产品。拍框底部采用了传统的盒式结构，而上部则采用了创新的ARMORTEC技术。ARMORTEC技术最大的特点就是强度高，并带有钛金属条配重。在加强了拍框12点位强度的同时也将球拍的中心向12点位移动，使进攻更加凌厉。AT系列拍身都采用了轻量化设计，在保持了拍头足够重的前提下使整拍重量只有3U，4U。专业选手使用此拍实测时杀球速度可以有5％的提高。

AT700，2003年诞生，在2004年遍地开花，2005年几乎是言必谈700了。此拍因为有大量的优秀选手选用，所以几乎成了业余中高级选手购拍的首选。就连国家队内多年使用CAB20的夏煊泽也已经换成了AT700了。AT700的杆身很硬，头很重，进攻能力极强，拍框采用盒式结构加ARMORTEC钛装甲配重，稳定性很好，强度极高，可以承受很高的拍线拉力，深受专业选手的喜爱。驱动这样的球拍需要较强的腕力。如果力量不足，可以考虑用NS8000代替。

AT800，世界著名双打选手拉斯姆森用的就是AT800中的进攻型（OFFENSIVE）。而另一位著名双打选手西吉特使用的是防守型（DEFENSIVE）。进攻型的AT800包括了AT700所有的特点，而且800比700还要硬一些。由于球拍的KICKPOINT(弯折点)不同，AT800的平抽挡速度更快，更精准。800进攻型杀球的威力也要比700略微大一点点。AT800/OF和DE是非常适合双打的一对球拍。也是目前高端拍中唯一的一对专为双打而设计的球拍。性能非常的优异。是喜爱双打的业余爱好者首选。

MP系列

MP系列是YONEX产品线最全面的一个系列。从进攻性最强的MP100到柔软舒适的MP23一应俱全。该系列产品最大的特点就是拍框上带有muscle power弧形设计。Muscle power最主要的作用就是降低拍线张力对线孔边缘的压力，减少较高磅数对球拍的伤害，并在拉线厚较长的一段时间内保持相对较稳定的线床张力。

MP100，2000年YONEX推出的产品。红＋黑的涂装非常惹眼。该产品设计定位就是进攻。是一把除了进攻还是进攻的球拍。拍框采用加钛设计，强度高，稳定性好，MUSCLE POWER技术的使用更保持了线床张力的持久，平衡的设计使球员可以在连续进攻中节省不少的体力。添加U Ti的 8mm中杆非常硬，弹性极好，但是因为此拍只适合于爆发力很好的进攻型球员，所以在业余选手中选用不多。

MP99,世界一号男单选手林丹在换用AT700之前使用的就是这个型号。MP99的亮黄色外观非常讨人喜欢，尤其是讨女生的喜欢。所以有很长的一段时间，国家队女队中几乎是一片香蕉黄。与MP100类似，MP99也是3、9点加钛的设计。7mm的细杆同样带有了U Ti，因拍杆细了1毫米，所以比MP100要略软一些。虽然当年此拍风靡一时，但是因为近一段时间与MP99球拍特点类似的新款球拍大量涌现，现时的99已经不再吃香了。想要购买MP99的人不妨试试NS7000。

MP88，peter gade曾经使用这把球拍很长时间。现在已经更换为AT700了。MP88的拍杆中也使用了U Ti，保持了MP高端拍一贯的高弹性。MP88拍杆比MP99 100要软一些，发力相对容易一些。拍头较重，拍面比较稳定。是一把性能出色非常适合业余爱好者使用的球拍。

MP66，这把球拍的风格与NS6000有些类似。色彩也比较相似，都很时尚。只是没有NS6000那么多的高科技。头轻型的MP66在使用中非常的灵活，深受女性球友的欢迎。此拍弹性适中，用于双打时是一把很好的防守拍。

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

posted @ 2008-05-19 16:06 狼爱上狸 阅读(527) | 评论 (0) | 编辑 收藏

羽毛球拍手胶选购

手胶（柄皮）:

手胶是缠在球拍握把上用以提高摩擦力的物品的统称。目前主要分两类，PU手胶和毛巾手胶。早起曾经使用过的真皮手胶现在已经基本退出市场。只有个别款式的球拍原配的柄皮还在使用真皮制品。与拍线和球之间的关系类似，手胶是和球员双手关系最密切的。羽毛球运动需要很多手指，手腕的细腻动作，一根合适的手胶可以及时准确的将击球后的感觉反馈给球员的手部。

一根好的手胶不但可以提供适当的阻尼使球拍握的更牢，还可以带给球员柔软舒适的手感，吸收打球时球员手部的汗水使球员保持手部干燥不易打滑。PU手胶因其较长的使用寿命，不易滋生细菌，吸汗后手感的保持和低廉的价格而深受广大业余爱好者的欢迎。毛巾胶虽然价格相对较贵并且使用寿命断，但因其手感柔软，吸汗能力强还是有很多人坚持使用。

一条好的PU手胶应该相对耐用，阻尼适当，吸汗抗水能力强，抗菌，不产生异味。一条好的毛巾胶应该不掉色，不掉毛，圈绒较粗壮，薄厚适中，吸汗后不僵硬，不起球。

使用手胶时应在保证称手，适当柔软的前提下尽可能的薄。过厚（过粗）的手胶会使手部僵硬，影响技术的发挥。

选择手胶的三要素：类型（毛巾还是PU），尺寸（薄或厚），阻尼（该特点主要针对PU手胶的黏性）

使用手胶的几种方法：

1、在原配柄皮上加PU手胶。目前国内市场的各品牌球拍最常见的尺寸是周长86mm的握把。该尺寸等同于YY G4的粗细。在缠新的PU手胶上去的时候，尽量不要撕掉拍柄的原配热缩膜（目前只有YY用热缩膜包装）。如果是普通的拍柄包装，则需在取下包装物后加缠一层UNDERLAP。UNDERLAP弹性很大，强度也不错，吸水性强，是非常好的衬垫物。如果没有UNDERLAP，也可以用一层保鲜膜代替。只是手感会稍差一些。

2、拆掉原配柄皮后加缠毛巾胶。这样做是为了保持球拍合理的尺寸。因为毛巾胶比较厚，不拆除原配柄皮直接加缠毛巾胶会导致拍柄过粗，影响水平发挥。在缠毛巾胶之前，一定要使用UNDERLAP保护拍柄。

3、拆除原配柄皮后用PU手胶调整握把粗细。有很多球友在不同季节喜欢换用不同类型的手胶。夏天用毛巾胶，冬天用PU手胶。这种做法比较符合上海的季节特点，但是手胶的尺寸比较难控制。所以一般都需要去除原配柄皮，然后重新以PU柄皮来调整整个握把的粗细。在需要用毛巾胶的时候，只要去除所有的PU手胶即可，等到冬季来临，再按原来习惯缠回PU手胶。

市场上的手胶品种非常多，比较优秀的品牌低价位的有ALPHA，中极星，中高价位的KIMONI, YONEX。其中YONEX的毛巾胶手感较好。为世界各国专业运动员所喜爱。美国品牌FORTEN（华腾）虽然进入中国市场很晚，但是其手胶色彩鲜艳，价格低廉，颇受时尚球友的喜爱。KIMONI(金万利）手胶是制作手胶起家的专业公司，与YONEX不同的是，KIMONI手胶是全日本制造。品质极佳，是目前为止唯一一个手感，耐用性都要超越YONEX的产品。不过用好东西总要有点代价，其薄手胶KGT100价格要高于目前YONEX 102C的售价。其实KIMONI的手胶在原产国的价格与YONEX相比并不高，只是YONEX的手胶在国内卖的太廉价了。

手胶简介：

YONEX

AC-102，销量最大的YONEX手胶。PU材料制造。标准长度1100毫米。实际长度大约为1150毫米左右。PU材料的表层有一层YONEX专门开发的柔软覆膜，表层材料黏性好，吸汗能力强，手感舒适。因其表层材料是覆盖在带基上的，一旦表层材料磨穿，手感会下降较快。该手胶耐用性一般，在高强度使用条件下，表面覆膜经常会大片脱落，这种情况属于产品特征，并不代表质量有问题。

AC-104EX，聚氨酯＋橡胶制造。标准长度1100毫米。在手胶的中间带有一条5毫米宽2毫米高的发泡材料制造的长条。缠好以后会显出一条一条的龙骨，使球拍更易于掌握。因为这种手胶加入了橡胶材料，故该手胶价格昂贵，但是此款手胶耐用性较好，也有一部分用户坚持使用。

KIMONI

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

KGT－100 无孔薄手胶。PU材料，标长1050mm。颜色丰富（19色），手感极佳。各方面性能均超越YONEX产品。

最大特点：耐用，手感保持时间长。

KGT－170 我所用过的性能最出色的厚手胶，难怪其包装外面印着“世界最强”，我觉得是当之无愧的。如果非要说有缺点，那就只能说他的价格不够“实惠”了。不过好东西从来就没实惠过，可以理解的。如果有条件，购买一支高端球拍时，可以当场将原配柄皮撕掉，换装此产品。其优异的性能绝不会令你失望。

最大特点：弹性保持时间长，隔离性好，对拍柄保护能力强。相同情况下，此产品弹性保持能力比最接近它的产品要长3－5倍。

该品牌其他型号虽然很多，但所用原料相同，带有龙骨的产品价格要低于YONEX AC104EX。还有打孔的产品以增加透气性，需要注意的是，打孔的产品最好先做隔水处理后再使用，不推荐手汗多的人使用打孔手胶。

值得一提的是，现在只有此品牌还有传统的真皮手胶。如果你心爱的老款名拍手胶破损，可以用此来替换了。

KARAKAL

该品牌的厚手胶手感良好，虽然比不过世界第一的KIMONI KGT-170，但价格实惠的多，也是值得推荐的。

posted @ 2008-05-19 16:04 狼爱上狸 阅读(2336) | 评论 (0) | 编辑 收藏

羽毛球拍线选购

羽毛球拍线：

羽毛球拍线是羽毛球运动中非常重要的一种耗材。球员每一次正确击球动作唯一会接触到羽毛球的就是拍线了。每一次击球质量的感觉将直接由拍线传递给球拍然后到达球员的手上。根据球员当前的打球风格以及打球的水平，选择适合的拍线及拍线拉力是非常重要的。拍线的基本特点有耐用性，弹性，击球声音，控球能力和吸震性。生产厂家会将不同拍线的性能特点以5边形的方式表现在该拍线的包装上。选择自己所需要的指数最高的拍线就可以了。举例，如果追求耐用性，那么就选择耐用指数最高的拍线。如果追求高弹性，则需选择弹性直属最高的线。一般来说，冬天应该用略粗一点的拍线，因为冬天气温低，拍线变的相对较脆，很容易断裂。夏天拍线的选择可以随意一些。 相同材质情况下，越粗的线就越结实（耐用），越细的线弹性就越大，越不耐用。目前高档球线中最耐用的拍线是YONEX BG 65，以及ASHAWAY（傲狮威）的A65(RALLY系列)。注意，ASHAWAY的中文名是傲狮威，而不是雅沙维。品牌名称问题最后再讲。

拍线拉力将直接影响到球拍的使用性能，一般来说，击球点越准，力量越大，可以使用的拍线拉力就越高。随着拍线拉力的提高，羽毛球拍上甜区的尺寸也快速的缩小，如果只是单纯的力量大而击球点准确度不够，高拉力拍线将会把每一次偏离甜区的击打所产生的所有震动通过球拍直接传递到球员的手腕、前臂，使球员受到慢性的隐性伤害。这种伤害是在相对较长的一段时间内所积累下来的。起初症状并不明显，但到达一定程度后，将会立刻凸显出来。具体症状为手腕内有撕裂感剧痛，手无法大力紧握等。一旦发现自己的前臂具有这种特征，就应该减少打球时间，运动后采取一定的养护措施，降低拍线拉力，或更换较软球拍。

判断是否已受到这种伤害可用以下方法。持拍手自然端平，大臂和小臂呈90度夹角。此时，小臂应指向身体的一侧。手掌外翻对准自己面对的方向，另一只抓住自己的持拍手，慢慢加力向内扭转（逆时针方向）。如果达到一定角度以后还只是单纯的自然疼痛（因肌肉、韧带、关节等达到极限位置产生的不强烈的隐性疼痛），则是手腕还处于健康状态。如果扭转到一定程度后感觉到手腕内的撕裂性的疼痛或针刺性的疼痛，则是已经受伤了。如果轻轻一扭就已经产生了强烈的疼痛，则是伤的较重了。

随着拍线拉力的提高，拍线的弹性将快速降低，寿命也急速缩短。一些使用高拉力拍线的业余高手们即使用了BG65这样极高耐用性的线，1－2周内也会断线。而国家羽毛球队运动员甚至每1－2天就会断线一次。当拍线拉力到达一定程度时，所有弹性特征都会消失的无影无踪。这也是为什么国家队员一般都只选择高耐用性的线（如BG65,65TI）而不考虑高弹线的原因了。过高的拍线拉力会严重影响球拍的使用寿命，也会使球拍丧失保修资格。一般业余爱好者应该根据自己的能力或参考比较专业的建议来选择适合自己的拍线拉力。

SHBC(上海羽毛球网)推荐拍线拉力：

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

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

品牌简介：

YONEX

BG65，高档拍线中最耐用的一根，同类产品至今无人能出其右。进攻性能良好。控球型球员也可采用。吸震能力始终。0.70毫米的线径

BG65TI，在BG65的基础上加TI增加了弹性,牺牲了一部分的耐用性。击球音略好。提高了线的强度，更适合暴力攻击型选手。吸震能力与65相同。0.70毫米的线径

BG70PRO，与65TI弹性相仿，击球声音与65类似。也很耐用。因为外皮采用了卵形纤维，所以耐拉能力极强，保持拍线拉力的性能非常好，但因吸震性能一般而使手感略微偏硬。0.70毫米的线径。

BG80，采用卵形纤维外皮，内包VECTRAN纤维，具有很高的反弹性和良好的爆发力，适合大力抽球，深受双打选手喜爱。耐用度一般，但是声音很好。0.68毫米线径。为了保证VECTRAN纤维的效果，最好降低拉力1－2磅使用。

BG85，控球线，表皮非常粗糙，只有0.67毫米线径。耐用性一般，吸震性能很好，手感柔软。击球音很好听。弹性超过BG80。因此线同样采用了VECTRAN纤维而线径更细，所以要降低拉力2－3磅使用。

BG68TI，综合性能非常优异的一根球线。各方面的能力都比较出色。是目前市场上可见的弹性最高的YONEX拍线。击球音清脆响亮，吸震性控制力都很出色。0.68毫米线径。深受业余球友的欢迎。耐用性一般，冬天低温很容易变脆断线，尽量避免低温使用。此线弹性很大，但是保持张力性能很一般，掉磅较快。为了保持一定的张力，需频繁更换。印尼双打名将西吉特的选择。

ASHAWAY 傲狮威

ASHAWAY曾经叫做雅沙维，这是中国总代所用的名字且已经注册了中文商标。但随着ASHAWAY公司亲自进入中国市场，原雅沙维品牌持有人拒绝放弃ASHAWAY产品及商标带给其的经济效益，将产品转为由其他厂家OEM。美国ASHAWAY公司只好责令其禁止使用ASHAWAY商标但对其中文名称无能为力。所以，“雅沙维”这个品牌已经不再是美国原产产品了。而真正的ASHAWAY中文名称已经改为傲狮威，习惯使用ASHAWAY产品的人购买时要注意一下品名和商标。

posted @ 2008-05-19 16:03 狼爱上狸 阅读(706) | 评论 (0) | 编辑 收藏

羽毛球鞋选购

所有的羽球爱好者都要面对一个相同的问题：我到底该买什么样的器材？为什么要买这个器材？这个器材对这项运动有多重要？下面我按照我个人认为的商品重要性进行了排列并做了简单的说明。希望这篇羽球用品选购指南能对所有正在犹豫不决的羽球爱好者有所帮助。

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

羽毛球鞋：

很多人都没有认识到，一双好的羽毛球鞋对这项运动到底有多重要。随着球员在场上不停的快速移动，双脚要承受平时几倍的压力，伴随着每一次的启动，球员的双脚要作出扭，转，跳跃，急停，换向等等极高机动性的动作。这所有的一切都是靠羽毛球鞋的支撑才得以完成。

有别于普通运动鞋，羽毛球鞋是专为羽毛球运动特点而设计的。较薄的鞋底，很强的侧面支撑能力使双脚尽可能的靠近地面。这种设计在保证了允许踝关节快速的弯曲，双脚运动方向频繁转变的前提下尽可能低的降低了双脚受伤的可能性。轻量化的设计可以使双脚移动速度更快，专门的鞋底材料可以保证双脚在球场上的抓地力。

在羽毛球运动中，我们对下半身所施加的压力可以由一双羽毛球鞋清晰的显现出来。一双高质量的羽毛球鞋，在高手的使用下只有3－6个月的有效寿命。此时的羽毛球鞋鞋底已经快要磨穿了，鞋垫也会磨透，高强度人造材料的鞋面，也会因为运动中所承受巨大压力而开裂，破损。

选择羽毛球鞋一定要仔细，确保选择了一双适合双脚形状及尺寸的，穿着舒适的球鞋。

选择羽毛球鞋一定要比平常的鞋略大一点，不然跑动起来脚会包的很难受。

羽毛球鞋选择时应注意前松侧紧。

侧紧，为了避免侧滑，防止扭伤；前松，上网时可起到缓冲作用。

一般来说，羽毛球鞋要比平常的鞋大半码到一码，不过记得要穿专业的羽毛球袜，一双袜子半码，留半码给脚，刚刚好。

激烈的羽毛球运动中双脚的血液循环要比平时快的多，双脚充血也较平常严重，别说小了，就是试穿的时候正好合适下场以后都有可能觉得紧。

很多羽毛球爱好者总是觉得鞋买大了一码以后会非常别扭，每次买鞋都要考虑买正好甚至略小的，这是非常错误的。

1、我们平常不会穿专门的羽毛球袜去试鞋，试出来的感觉本身就不够准确。

2、鞋头不宽松的话，上网时极有可能会顶到最长的脚趾，严重的还会使脚趾甲受损。

球鞋尺寸大了，有可能走路会觉得别扭，甚至会出现上楼梯踢台阶的现象，这是因为我们的大脑已经习惯了鞋+脚的尺寸，在做上楼梯这个动作时，大脑发令总是以我们常用鞋码的尺寸来作为抬腿出脚距离的标准，这是为了最大限度节省体力，是本能。

但羽毛球步法和上楼梯完全不是一回事，与平时走路也完全不是一回事。这也是为什么尽量到场馆以后才换鞋的另一个原因。

注意不要穿厚底鞋(如篮球鞋)上场打羽毛球。厚底鞋会把脚抬离地面过高，导致严重的意外扭伤，甚至会带来后遗症，如习惯性扭伤等。这种运动伤害会在今后的很长一段时间影响你的羽毛球水平。

常见的不错的羽毛球鞋品牌有MIZUNO,YONEX。国产品牌如VICTOR，KASON等因技术原因暂时无法与国外品牌抗衡，但因其价格低廉，也是不错的选择。

YONEX羽毛球鞋产品特点简介：

YONEX的高级球鞋都带有专利POWER CUSHION动力垫。Power cushion的减震能力和弹性极好，一个生鸡蛋从两米高度下落掉在动力垫上不会损坏，还可以跳起一米。

99LOW 鞋面由柔韧的高级PU合成皮革加双层透气网制成。超轻量EVA中底（GLITE）带有专利POWER CUSHION材料制成的动力垫，鞋垫下部带有TPU稳定片防止足弓变形。高强度石墨连接桥，外装爪型TPU支撑片（lateral claw） 鞋底是防滑耐磨的橡胶大底。

99M 同上

89MG 高级PU合成皮革，聚酯透气网，护踝柔韧合成皮。EVA中底。耐磨，防滑大底。立体石墨支撑片。防扭系统。

56C 柔韧PU（合成皮），脚跟动力垫(POWER CUSHIO)，EVA中底。耐磨橡胶外底。

06年新款的90M 90L采用了圆鞋底，这种设计可使脚底受力更均匀，减轻脚底局部区域的压力，使得穿着，使用更舒适。新品价格略高，但还是值得一试。

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

posted @ 2008-05-19 16:01 狼爱上狸 阅读(273) | 评论 (0) | 编辑 收藏

acegi,IBM的Acegi Security System（4）

2008 年 3 月 20 日

Bilal Siddiqui 将继续在他的 系列文章 中展示如何使用 Acegi 保护 Java™Server Faces (JSF) 应用程序。配置 JSF 和 Acegi，让它们在 servlet 容器中协作，探索 JSF 和 Acegi 组件如何彼此协作。

本 系列 的前 3 部分讨论了如何使用 Acegi Security System 保护 Java 企业应用程序：

• 第 1 部分 解释了如何使用 Acegi 的内置过滤器实现一个简单的基于 URL 的安全系统。
• 第 2 部分 展示了如何编写访问控制策略、将其存储在 LDAP 目录服务器中，以及配置 Acegi 与 LDAP 服务器交互，从而实现访问控制策略。
• 第 3 部分 展示了如何在企业应用程序中使用 Acegi 保护对 Java 类实例的访问。

第 4 部分将讨论如何使用 Acegi 保护在 servlet 容器中运行的 JavaServer Faces (JSF) 应用程序。本文首先解释 Acegi 针对此目标提供的特性，并澄清一些关于使用 Acegi 和 JSF 的常见误解。然后提供一个简单的 web.xml 文件，可以用来部署 Acegi，从而保护 JSF 应用程序。然后深入探讨 Acegi 和 JSF 组件，了解在部署 web.xml 文件和用户访问 JSF 应用程序时所发生的事件。本文最后提供了一个由 Acegi 保护的示例 JSF 应用程序。

无需编写 Java 代码即可添加安全性

回顾一下本系列的第一个示例 Acegi 应用程序（请参阅 第 1 部分 中的 “一个简单 Acegi 应用程序” 一节）。该应用程序使用 Acegi 提供了以下安全特性：

• 当一个未经验证的用户试图访问受保护的资源时，提供一个登录页面。
• 将授权用户直接重定向到所需的受保护资源。
• 如果用户未被授权访问受保护资源，提供一个访问拒绝页面。

回想一下，您无需编写任何 Java 代码就能获得这些特性。只需要对 Acegi 进行配置。同样，在 JSF 应用程序中，无需编写任何 Java 代码，也应该能够从 Acegi 实现相同的特性。

澄清误解

其他一些作者似乎认为将 Acegi 与 JSF 集成需要 JSF 应用程序提供登录页面（参见 参考资料）。这种观点并不正确。在需要时提供登录页面，这是 Acegi 的职责。确保登录页面在安全会话期间只出现一次，这也是 Acegi 的职责。然后，经过身份验证和授权的用户可以访问一个受保护资源，无需重复执行登录过程。

如果使用 JSF 提供登录页面，将会发生两个主要的问题：

• 当需要时，没有利用 Acegi 的功能提供登录页面。必须编写 Java 代码实现所有逻辑来提供登录页面。
  
  
• 至少需要编写一些 Java 代码将用户凭证（用户名和密码）从 JSF 的登录页面移交到 Acegi。

Acegi 的目的是避免编写 Java 安全代码。如果使用 JSF 提供登录页面，则没有实现这一用途，并且会引发一系列其他 JSF-Acegi 集成问题，所有这些问题都源于 “Acegi 是用来提供可配置安全性” 这一事实。如果试图使用 JSF 来完成 Acegi 的工作，将会遇到麻烦。

本文余下部分将解释并演示独立于 Acegi 的 JSF 应用程序开发，并在稍后配置 Acegi 以保护 JSF 应用程序 — 无需编写任何 Java 代码。首先看一下 web.xml 文件，可以部署该文件保护 JSF 应用程序。

回页首

部署 Acegi 保护 JSF 应用程序

清单 1 展示了一个 web.xml 文件（通常称为部署描述符），可以使用这个文件部署 Acegi，从而保护运行在 servlet 容器（比如 Apache Tomcat）中的 JSF 应用程序：

                        <?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 应用程序中的用途。

向 Acegi 和 JSF 提供上下文参数

清单 1 中的每个 <context-param> 标记定义一个参数，供 Acegi 或 JSF 在启动或执行期间使用。第一个参数 — contextConfigLocation — 定义 Acegi 的 XML 配置文件的位置。

JSF 需要 javax.faces.STATE_SAVING_METHOD 和 javax.faces.CONFIG_FILES 参数。javax.faces.STATE_SAVING_METHOD 参数指定希望在客户机还是服务器上存储 JSF 页面-视图状态。Sun 的参考实现的默认行为是将 JSF 视图存储在服务器上。

javax.faces.CONFIG_FILES 参数指定 JSF 需要的配置文件的位置。JSF 配置文件的详细信息不属于本文讨论的范围（参见 参考资料，获取涉及该主题的资源链接）。

为 Acegi 和 JSF 配置侦听器

现在看一下 清单 1 中的 2 个 <listener> 标记。<listener> 标记定义侦听器类，侦听器类侦听并处理 JSP 或 servlet 应用程序启动和执行期间发生的事件。例如：

• 启动 JSP 或 servlet 应用程序时，servlet 容器创建一个新的 servlet 上下文。每当 JSP 或 servlet 应用程序启动时，就会触发此事件。
  
  
• servlet 容器创建一个新的 servlet 请求对象。每当容器从客户机收到一个 HTTP 请求时，此事件就会发生。
  
  
• 建立一个新的 HTTP 会话。当请求客户机建立一个与 servlet 容器的会话时，此事件就会发生。
  
  
• 一个新属性被添加到 servlet 上下文、servlet 请求和 HTTP 会话对象。
  
  
• servlet 上下文、servlet 请求或 HTTP 会话对象的一个现有属性被修改或删除。

<listener> 标记就像一种可扩展性机制，允许在 servlet 容器内部运行的应用程序协同某些事件进行处理。servlet 规范定义了侦听器类为处理事件而实现的一些接口。

例如，Spring Framework 实现一个 javax.servlet.ServletContextListener servlet 接口。实现此接口的 spring 类是 org.springframework.web.context.ContextLoaderListener。注意，这是 清单 1 的第一个 <listener> 标记中的侦听器类。

类似地，JSF 实现一个 com.sun.faces.config.ConfigureListener 类，该类实现一些事件-侦听接口。可以在 清单 1 的第二个 <listener> 标记中找到 ConfigureListener 类。

本文稍后将解释不同的事件-侦听器接口，以及 Acegi 和 JSF 事件-侦听器类内部执行的处理（请参阅 “启动 JSF-Acegi 应用程序” 和 “处理对受 Acegi 保护的 JSF 页面的请求”）。

配置和映射 servlet 过滤器

现在看一下 清单 1 中的 <filter> 标记。在请求的 servlet 处理传入的请求之前，servlet 应用程序使用过滤器对其进行预处理。在请求执行之前，Acegi 使用 servlet 过滤器对用户进行身份验证。

请注意 清单 1 中的 <filter> 标记，它的 <filter-class> 子标记指定一个 org.acegisecurity.util.FilterToBeanProxy 类。FilterToBeanProxy 类是 Acegi 的一部分。此类实现一个 javax.servlet.Filter 接口，该接口是 servlet 应用程序的一部分。javax.servlet.Filter 接口有一个 doFilter() 方法，servlet 容器在收到请求时调用该方法。

还需注意，清单 1 的 <filter> 标记有另一个子标记 <init-param>。<init-param> 标记指定实例化 FilterToBeanProxy 类所需的参数。可以从 清单 1 中看出，FilterToBeanProxy 类只需要一个参数，该参数是 FilterChainProxy 类的一个对象。FilterChainProxy 类表示 第 1 部分 1 中讨论的整个 Acegi 过滤器链（请参阅 “安全过滤器” 小节）。FilterToBeanProxy 类的 doFilter() 方法使用 FilterChainProxy 类执行 Acegi 的安全过滤器链。

清单 1 中的 <filter-mapping> 标记指定调用 Acegi 的 FilterToBeanProxy 的请求 URL。我已经将所有的 JSF 页面映射到 Acegi 的 FilterToBeanProxy。这意味着只要用户试图访问 JSF 页面，FilterChainProxy doFilter() 方法就会自动获得控制权。

配置 JSF servlet

web.xml 文件中的 <servlet> 标记指定希望从特定 URl 调用的 servlet（在本例中是一个 JSF servlet）。<servlet-mapping> 标记定义该 URL。几乎所有的 JSP 或 servlet 应用程序都包含这两个标记，所以无需再作讨论（参见 参考资料，获取讨论 servlet 编程的资源链接）。

现在，您已经看到，web.xml 文件要部署 Acegi 以保护 JSF 应用程序所需的所有标记。您已经了解了侦听器、过滤器和 servlet 如何相互协作。从这里的讨论中可以看出，如果在 servlet 容器中部署 清单 1 中的 web.xml 文件，Acegi 和 JSF 都试图在两种情形下进行一些处理：

• 当启动应用程序时
• 当应用程序收到对 JSF 页面的请求时

接下来的两节解释每种情况中发生的一系列事件。

回页首

启动 JSF-Acegi 应用程序

图 1 展示了在 JSF-Acegi 应用程序启动时发生的事件顺序：

详细来讲，图 1 显示的事件顺序如下所示：

1. servlet 容器实例化在 web.xml 文件中配置的所有侦听器。
   
   
2. servlet 容器将 Acegi 的 ContextLoaderListener 注册为一个侦听器类，该类实现 javax.servlet.ServletContextListener接口。ServletContextListener 接口包含两个重要方法：contextInitialized() 和 contextDestroyed()：
   • contextInitialized() 方法在初始化 servlet 上下文时获得控制权。
   • 类似地，当应用程序退出时，contextDestroyed() 方法会被调用，并消除 servlet 上下文。
   
   
3. servlet 容器将 JSF 的 ConfigureListener 注册为另一个侦听器。JSF 的 ConfigureListener 实现许多侦听器接口，比如 ServletContextListener、 ServletContextAttributeListener、 ServletRequestListener，以及 ServletRequestAttributeListener。您已经看到了 ServletContextListener 接口的方法。余下的接口是：
   • ServletContextAttributeListener，它包含 3 种方法：attributeAdded() attributeRemoved() 和 attributeReplaced()。这 3 种方法分别在某个属性被添加到 servlet 上下文、被从 servlet 上下文删除、被新属性取代时获得控制权。attributeReplaced() 方法在 处理对受 Acegi 保护的 JSF 页面的请求 小节的第 8 步中获得控制权。
     
     
   • ServletRequestListener 中包含的方法在创建或删除新的 servlet 请求对象时获得控制权。servlet 请求方法表示并包装来自用户的请求。
     
     
   • ServletRequestAttributeListener 中包含的方法在添加、删除或替换某个请求对象的属性时获得控制权。本文稍后将讨论在 处理对受 Acegi 保护的 JSF 页面的请求 小节的第 3 步中创建一个新的请求对象时，JSF 的 ConfigureListener 执行的处理。
   
   
4. servlet 容器创建一个 servlet 上下文对象，该对象封装应用程序资源（比如 JSP 页面、Java 类和应用程序初始化参数），并允许整个应用程序访问这些资源。JSF-Acegi 应用程序的所有其他组件（侦听器、过滤器，以及 servlet）在 servlet 上下文对象中以属性的形式存储与应用程序资源相关的信息。
   
   
5. servlet 容器通知 Acegi 的 ContextLoaderListener，servlet 上下文是通过调用 ContextLoaderListener 的 contextInitializated() 方法初始化的。
   
   
6. contextInitialized() 方法解析 Acegi 的配置文件，为 JSF-Acegi 应用程序创建 Web 应用程序上下文，以及实例化所有的安全过滤器和在 Acegi 配置文件中配置的 Jave bean。在以后 JSF 应用程序收到来自客户机的请求时，这些过滤器对象将会用于身份验证和授权（参阅 第 3 部分 中关于 Web 应用程序上下文创建的讨论和图 1）。
   
   
7. servlet 容器通知 JSF 的 ConfigureListener，servlet 上下文是通过调用 contextInitialized() 方法初始化的。
   
   
8. contextInitialized() 方法检查在 JSF 配置文件中配置的所有 JSF 托管 bean，确保 Java 类与每个 bean 并存。
   
   
9. servlet 容器检查 web.xml 文件中任何配置的过滤器。例如，清单 1 中的 web.xml 文件包含一个 Acegi 过滤器 FilterToBeanProxy，servlet 容器将其实例化、初始化并注册为一个过滤器。Acegi 现在可以对传入的请求执行身份验证和授权了。
   
   
10. servlet 容器实例化 faces servlet，后者开始侦听从用户传入的请求。

下一节解释 JSF-Acegi 应用程序收到来自用户的请求时发生的一系列事件。

回页首

处理对受 Acegi 保护的 JSF 页面的请求

您已经了解了如何配置 Acegi 保护 JSF 应用程序。也看到了当启动 JSF-Acegi 应用程序时发生的一系列事件。本节描述当用户发送一个对受 Acegi 保护的 JSF 页面的请求时，JSF 和 Acegi 组件如何在 servlet 容器的框架中运行。

图 2 展示了当客户机发送一个对受 Acegi 保护的 JSF 页面的请求时，发生的事件顺序：

详细来讲，图 2 展示的事件顺序如下所示：

1. servlet 容器创建一个表示用户请求的 servlet 请求对象。
   
   
2. 回想一下 启动 JSF-Acegi 应用程序 小节中的第 3 步，JSF 的 ConfigureListener 实现 ServletRequestListener 接口。这意味着 ConfigureListener 侦听与创建和删除 servlet 请求对象相关的事件。因此，servlet 容器调用 ConfigureListener 类的 requestInitialized() 方法。
   
   
3. requestInitialized() 方法准备执行请求的 JSF 生命周期。准备过程包括检查请求的 faces 上下文是否存在。faces 上下文封装与应用程序资源相关的信息。faces servlet 执行 JSF 生命周期时需要这些信息。如果此请求是新会话的第一个请求，就会缺少 faces 上下文。在这种情况下，requestInitialized() 方法创建一个新的 faces 上下文。
   
   
4. servlet 容器检查用户的请求是否带有任何状态信息。如果 servlet 容器未找到状态信息，它会假设该请求是新会话的第一个请求，并为用户创建一个 HTTP 会话对象。如果 servlet 容器发现该请求包含某种状态信息（比如一个 cookie 或 URL 中的某种状态信息），它就会根据保存的会话信息恢复用户以前的会话。
   
   
5. servlet 容器把请求 URL 与一个 URL 模式进行匹配，这个 URL 模式包含在配置描述符中的 <filter-mapping> 标记的 <url-pattern> 子标记中。如果请求 URL 与这个 URL 模式匹配，servlet 容器调用 Acegi 的 FilterToBeanProxy，FilterToBeanProxy 已在 图 1 的第 9 步中被注册为一个 servlet 过滤器。
   
   
6. Acegi 的 FilterToBeanProxy 使用 FilterChainProxy 类执行 Acegi 的完整的安全过滤器链。Acegi 的过滤器自动检查第 4 步中创建的 HTTP 会话对象，以查看请求客户机是否已被验证。如果 Acegi 发现用户未被验证，它提供一个登录页面。否则，它就直接执行 第 2 部分 的 “配置拦截器” 一节中描述的授权过程。
   
   
7. Acegi 使用经过验证的用户的会话信息更新 servlet 上下文。
   
   
8. servlet 容器通知 JSF 的 ConfigureListener 的 attributeReplaced() 方法，servlet 上下文已被更新。ConfigureListener 检查是否有任何 JSF bean 被更改。如果发现任何更改，它相应地更新 faces 上下文。但是，在本例中，在身份验证过程中 Acegi 没有更改任何 JSF 托管 bean，因此在此调用期间 ConfigureListener 不进行任何处理。
   
   
9. 如果授权过程成功，控制权被转移到 faces servlet，它执行 JSF 生命周期并向用户发回一个响应。

现在，您了解了 JSF 和 Acegi 如何协作提供 JSF 请求，接下来看一下完成后的 JSF 和 Acegi。

回页首

示例 JSF-Acegi 应用程序

本文的下载部分（参见 下载）包含一个示例 JSF-Acegi 应用程序 JSFAcegiSample，演示了 Acegi 与 JSF 的简单集成。示例应用程序使用 清单 1 中的 web.xml。

要部署示例应用程序，执行 第 1 部分 的 “部署并运行应用程序” 一节中的两个步骤。还需要从 Sun 的 JSF 站点（参见 参考资料）下载并解压 jsf-1_1_01.zip。将 jsf-1.1.X.zip 中的所有文件复制到 JSFAcegiSample 应用程序的 WEB-INF/lib 文件夹中。

从浏览器访问 http://localhost:8080/JSFAcegiSample，可以调用示例应用程序。JSFAcegiSample 应用程序显示一个索引页面和一个登录页面，索引页面中包含受保护资源的链接。所有受保护页面都是使用 JSF 组件开发的，而 Acegi 提供登录页面并执行身份验证和授权。

结束语

在本文中，了解了如何配置 Acegi 以保护 JSF 应用程序。还详细了解了 JSF 和 Acegi 组件如何在一个 servlet 容器的框架中协作。最后，尝试运行了一个示例 JSF-Acegi 应用程序。

关于实现 JSF 应用程序的 Acegi 安全性，还涉及到更多内容。本系列的下一篇文章将演示如何使用 Acegi 保护对 JSF 的托管 bean 的访问。


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

posted @ 2008-05-08 18:50 狼爱上狸 阅读(290) | 评论 (0) | 编辑 收藏

acegi,IBM的Acegi Security System（3）

2007 年 10 月 18 日

本文是 Acegi Security Systerm 介绍的最后一部分（共三部分），Bilal Siddiqui 将向您介绍如何保护对 Java 类实例的访问，从而结束本系列文章。通过本文了解为何需要对 Java™ 类的访问进行保护，Spring 如何创建和保护对 Java 类实例的访问以及如何对 Acegi 进行配置以实现 Java 应用程序的类安全性。

这期共分三部分的系列文章介绍了如何使用 Acegi 安全系统保护 Java 企业应用程序。系列文章的 第 1 部分 简单介绍了 Acegi 并解释如何使用其内置的安全过滤器实现一个简单的、基于 URL 的安全系统。第 2 部分 介绍了如何编写访问控制策略并将其保存到一个 LDAP 目录服务器，以及如何配置 Acegi 来与目录服务器进行交互，从而实现访问控制策略。第 3 部分（也是本系列的最后一篇文章）将演示如何在企业应用程序中使用 Acegi 保护对 Java 类实例的访问。

首先我将介绍何时需要对 Java 类访问进行保护，包括文中引用的两个典型企业应用程序场景。之后，我将解释 Spring 的反转控制（IOC）框架如何创建可从 JSP 或 servlet 访问的 Java 类实例。我还将介绍有关 bean 代理 的重要概念，Spring 正是使用它过滤对 Java 类的访问。最后，我将介绍如何对 Acegi 的方法安全性拦截器进行配置以控制对 Java 类的访问。我将对 第 2 部分 中的示例程序进行增强，为实现安全的 Java 对象提供支持，从而结束本系列的最后一篇文章。

由于本文的讨论构建在本系列前两部分的内容之上，因此会经常引用到 第 1 部分 和 第 2 部分 中的讨论和示例。因此，在继续阅读本文之前，在其他浏览器窗口中打开前两期文章将有助于理解本文内容。

保护 Java 类的用例

您可能还记得，我曾在本系列的开头部分简单介绍了 企业应用程序安全性。在那次讨论中我曾提到过一种场景，其中 URL 安全性并不能完全满足这种场景的安全需求：

假设有这样一个 PDF 文档，其中包含了某制造业公司生产的特定产品的数据。文档的一部分包含了设计数据，将由公司设计部分进行编辑和更新。文档另一部分包含生产经理将使用到的生产数据。对于此类场景，需要实现更加细粒度的安全性，对文档的不同部分应用不同的访问权限。

在继续阅读之前，请考虑更多的应用程序场景，除了实现 URL 安全性以外，这些场景还要求您对单独的类访问进行保护。

业务自动化

业务自动化应用程序中的工作流由多个流程组成。例如，病理学实验室中执行血液测试的工作流由若干个步骤组成，其中每个步骤可看作一个业务流程：

1. 工作人员从病人处采集血液样本并为其分配一个 ID。
2. 实验室技术人员对样本进行必要的测试并准备测试结果。
3. 由具备相应资格的病理学专家根据测试结果编写测试报告。

很明显，每个流程分别由单独的授权用户执行。未授权的用户则无权执行流程。例如，实验室研究人员只负责准备试验结果，而无权编写测试报告。

几乎所有的业务自动化应用程序都普遍使用授权的业务流程。通常，每个业务流程被实现为一个 Java 类，并且需要使用合适的访问控制策略对所有类实施保护。

企业对企业（Business-to-business）集成

Business-to-business (B2B) 集成指一种常见的场景，其中的两个企业实体需要彼此公开各自的特定功能。例如，宾馆可能向旅游公司公开其房间预订功能，而后者使用该功能为游客预订空闲的房间。作为合作伙伴的旅游公司可能具有一个特定的订房率。在这个场景中，宾馆的订房系统必须先对旅游公司进行身份验证，然后才能允许他们访问所选择的类，以便按照特定的订房率进行房间预订。

回页首

使用 Spring 创建 Java 对象

现在您已经了解了对 Java 类示例的访问进行保护的重要性。在介绍能够实现更高级安全性的 Acegi 新功能之前，我将引导您回顾 Spring 框架的几个关键特性，您需要了解这些内容才能继续后文的示例。

首先对一些 Java 类进行配置并执行实例化。第 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 框架并创建 Java 对象。您可以参考 第 1 部分的清单 8 查看全部内容。图 1 也对此进行了描述：

现在我们将详细讨论这些步骤：

1. 当初始化 Acegi 应用程序时，servlet 容器（本例中为 Apache Tomcat）创建了一个 servlet 上下文，其中保存了有关应用程序资源的信息，例如 JSP 页面和类。
   
   
2. servlet 容器通知 ContextLoaderListener 类应用程序正在启动。
   
   
3. ContextLoaderListener 类创建一个 Web 应用程序上下文以保存应用程序中特定于 Spring 的资源信息。借助 Spring 的 IOC 框架，您可以装载自己的自定义应用程序上下文。要创建应用程序上下文，将使用名为 ContextLoader 的上下文装载器类装载应用程序上下文。
   
   
4. 如果应用程序不需要定义自己的应用程序上下文，则可以使用名为 XMLWebApplicationContext 的类，它是 Spring 框架的一部分并提供可处理 Spring XML 配置文件的功能。Acegi 应用程序使用的是 Spring 的 XML 配置文件，因此本文仅讨论由 XMLWebApplicationContext 类表示的应用程序上下文。在本例中，上下文装载器对 XMLWebApplicationContext 类进行实例化，后者表示您的 Acegi 应用程序的应用程序上下文。上下文装载器还在 Web 应用程序上下文中设置 servlet 上下文（于步骤 1 中创建）的引用。
   
   
5. XMLWebApplicationContext 类对 XML 配置文件进行解析，获得关于 Java 类的信息并将信息装载到其他内部对象中。
   
   
6. XMLWebApplicationContext 类对 XML 配置文件中指定的所有 Java 类进行实例化。XMLWebApplicationContext 类检查 XML 配置文件中经过配置的 Java bean 是否依赖其他的 Java 对象。如果是的话，XMLWebApplicationContext 类将首先对其他 bean 所依赖的 bean 进行实例化。通过这种方式，XMLWebApplicationContext 类创建了 XML 配置文件中定义的所有 bean 的实例。（注意，步骤 6 假定 XML 配置文件中所有 bean 都不要进行保护，稍后一节将介绍步骤 5 和步骤 6 之间执行的额外步骤，从而保护对此处创建的 Java bean 的访问）。
   
   
7. XMLWebApplicationContext 类将所有 bean 保存在一个数组中。

您现在已了解到如何从 XML 配置文件中装载 bean 定义并创建 Java 类的实例。接下来，我将向您介绍 Spring bean 代理并解释它对于保护 Java 类实例的重要性。

回页首

使用 bean 代理

上一节讨论了 Spring 的 IOC 框架对 Java 对象进行实例化。要保护对 Java 对象的访问，Spring 的 IOC 框架使用了 bean 代理 的概念。本节首先介绍如何配置 bean 代理，然后演示 Spring 的 IOC 框架如何创建代理对象。

为 Java 对象配置代理

如果希望创建 bean 代理，Spring IOC 框架要求您对代理创建器 bean 的实例进行配置。Spring 的 IOC 框架使用代理创建器创建代理对象。清单 2 为代理创建器 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 框架的一部分，可以自动创建 bean 代理。Spring 框架提供了 BeanPostProcessor 接口，它提供了一种可扩展机制，允许应用程序编写自己的逻辑来创建 bean 代理。Spring 的 BeanNameAutoProxyCreator 类实现了 BeanPostProcessor 接口并提供所有必需的代理创建逻辑来保护 Java 类。因此，本文中您无需实现 BeanPostProcessor 接口。

在创建 bean 代理时，BeanNameAutoProxyCreator 类为所有由 beanNames 属性定义的 bean 创建代理（参见 清单 2 中 <bean> 标记的第一个 <property> 子元素）。beanNames 属性在 <list> 标记中包含一个 bean 名称列表。在 清单 2 中，我只对希望为之创建代理的 privateCatalog bean进行了配置。

现在查看 清单 2 中 <bean> 标记的第二个 <property> 子元素。它指定了名为 interceptorNames 的代理，它将一个或多个拦截器的名称封装起来。我将在后文详细讨论拦截器概念。现在，只需了解拦截器可以拦截用户并在用户访问 bean 之前实现访问控制策略。

现在，您已了解了如何对希望进行保护的 bean 配置代理。接下来，您将了解 Spring 的 IOC 框架如何在内部为应用程序的 bean 创建代理对象。

Spring IOC 发挥效用

在 “使用 Spring 创建 Java 对象” 的步骤 5 和步骤 6 中，您了解了 XMLWebApplicationContext 类如何从 XML 配置文件中读取 bean 定义并随后创建 bean 实例。在创建 bean 实例之前，XMLWebApplicationContext 类将检查 XML 配置文件是否包含任何代理创建器 bean（即实现 BeanPostProcessor 接口的 bean）配置。如果存在该 bean，它将要求代理创建器为您希望进行保护的 bean 创建 bean 代理。

1. 代理创建器（即 BeanNameAutoProxyCreator 类）装载 清单 2 中配置的 beanNames 属性文件中指定的所有 bean 名称。
   
   
2. 代理创建器使用 bean 名称装载各自的 Java 类，这些类使用了每个 bean 定义的 class 属性。
   
   
3. 代理创建器创建 清单 2 所示的 interceptorNames 属性中指定的拦截器的实例。
   
   
4. 最后，代理创建器创建一个 Cglib2AopProxy 类的实例，将所有 bean 名称（步骤 2）和拦截器（步骤 3）传递到 Cglib2AopProxy 类。Cglib2AopProxy 类是 Spring 框架的一部分并用于生成动态代理对象。在本例中，Cglib2AopProxy 类将创建安全 bean 访问控制所需的代理对象。

Cglib2AopProxy 类实现了两个名为 AOPProxy 和 MethodInterceptor 的接口。AOPProxy 接口由 Spring 框架提供，表示您希望进行代理的实际 bean，因此它与您的 bean 公开相同的方法。MethodInterceptor 接口也源于 AOP 框架，它包含的方法可以在用户试图访问您已执行代理的 bean 时接受控制权。这意味着 MethodInterceptor 接口处理来自用户的请求以访问执行过代理的 bean。由于 Cglib2AopProxy 类同时实现了 AOPProxy 和 MethodInterceptor 接口，因此它提供了完整的功能，既可以提供经过代理的 bean，也可以处理用户请求以访问代理 bean（参见 参考资料小节 中有关 AOP 的讨论文章的链接）。

执行完前面的步骤后，您现在具有了所需的代理对象。因此 XMLWebApplicationContext 类将安全 bean 的代理（而不是实际的 bean）保存在 “使用 Spring 创建 Java 对象” 的步骤 7 中的同一个数组中。

回页首

访问执行过代理的 Java 对象

在前面的几节中，您了解了 Spring 如何创建公有 bean 和私有 bean。出于本文的目的，您可将公有 bean 视为使用代理保护的不安全的私有 bean。现在我们来看一下客户机应用程序为访问公有 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>
            

应用程序可以使用清单 4 中的代码访问清单 3 中配置的 publicCatalog 和 privateCatalog Java bean。注意，清单 4 中显示的 Java 代码可位于 JSP 页面或位于服务器端 Java 应用程序的 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：取回一个应用程序上下文实例
  当应用程序希望访问 XML 配置文件中配置的 Java bean 时，它必须取回您在 “使用 Spring 创建 Java 对象” 的步骤 4 中见到的 XMLWebApplicationContext 对象。XMLWebApplicationContext 对象包含对 XML 配置文件配置的所有 Java beans 的引用。
  
  
• 步骤 2：从应用程序上下文中取回不安全的 bean
  您现在具有一个对 XMLWebApplicationContext 对象的引用。XMLWebApplicationContext 类公开了一个 getBean() 方法，它包含 bean 的名称并在数组中查找 “使用 Spring 创建 Java 对象” 步骤 7 中准备的 bean。在本例中，该 bean 为 publicCatalog（未执行过代理），因此 XMLWebApplicationContext 将返回实际的 bean。
  
  
• 步骤 3：调用不安全 bean 的方法
  现在您可以调用步骤 2 中获得的 publicCatalog bean 的任何方法。例如，清单 4 显示的 getData() 方法调用的执行没有应用任何访问控制并向应用程序返回类别数据。
  
  
• 步骤 4：从应用程序上下文取回安全 bean
  安全 bean 与不安全 bean 的取回方式类似，惟一区别是：当您通过调用 getBean() 方法尝试取回安全 bean 时，您将获得安全对象的代理而不是实际的对象。该代理就是我在 “Spring IOC 发挥效用” 步骤 4 中解释的由 Spring 框架创建的同一个对象。
  
  
• 步骤 5：调用安全 bean 的方法
  当调用安全 bean 的方法时，您在 步骤 4 中获得的代理对象将一个方法调用请求分配给拦截器。拦截器将检查试图访问方法的用户是否具有相应的访问权，从而处理方法调用请求。

您现在应该对 Spring 框架如何创建 Java 对象以及客户机应用程序如何与之交互有了清晰的了解。了解了这些内容后，就更加容易理解并利用 Acegi 的方法安全性拦截器，下一节将具体介绍该主题。

回页首

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

只要应用程序试图访问由 Acegi 安全系统保护的 bean 方法，请求将被自动传递到 Acegi 的方法安全性拦截器。方法安全性拦截器的作用就是控制对安全 Java bean 的方法的访问。拦截器使用 Acegi 的身份验证和授权框架确认用户是否具有权利调用安全 Java bean 的方法，然后相应地作出响应。

清单 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 属性。这个访问决策管理器负责制定授权决策。在允许对一个安全 bean 进行访问之前，方法安全拦截器使用 authenticationManager 和 accessDecisionManager 属性对用户进行身份验证和授权。

现在查看 清单 5 中配置的 objectDefinitionSource 属性。它类似于第 1 部分中出现的 objectDefinitionSource 属性。以前的 objectDefinitionSource 包含类似于 /protected/* 和 /** 这样的 URL，清单 5 中的 objectDefinitionSource 属性指定类和方法名；例如，sample.PrivateCatalog 是之前执行过代理的类的名称，而 getData 是您希望对其控制用户访问的方法的名字。

当用户访问 PrivateCatalog bean 的 getData() 方法时，控制权将自动传递给拦截器。拦截器使用 Acegi 框架检查用户的业务角色是否为 ROLE_HEAD_OF_ENGINEERING（特定于本文的示例）。如果是的话，拦截器将允许对 getData() 方法进行访问。如果拦截器发现用户角色不是 ROLE_HEAD_OF_ENGINEERING，则拒绝访问。

下一节将查看一个示例 Acegi 应用程序，它将实现您目前所了解的所有概念。

回页首

示例 Acegi 应用程序

本文的 下载源代码 包含了一个名为 AcegiMethodSecurity 的示例应用程序，可按照以下方法进行配置和部署：

1. 使用用户信息填充 LDAP 服务器。下载的示例应用程序 包含一个 LDIF 文件，其中含有预备装载到 LDAP 服务器的用户信息。关于如何将 LDIF 文件导入到 LDAP 服务器，请参考第 2 部分的 “填充服务器” 一节。注意，该应用程序涉及与第 2 部分相同的用户（alice、bob 和 specialUser）。
   
   
2. 将本文下载源代码中的 acegiMethodSecurity.war 文件复制到 Tomcat 安装目录中的 webapps 目录。
   
   
3. 将 Acegi 的 jar 文件复制到示例应用程序的 WEB-INF/lib 文件夹。（有关内容请参考第 1 部分的 “部署和运行应用程序” 一节。 ）
   
   
4. 下载 cglib-full-2.0.2.jar 文件并将其复制到示例应用程序的 WEB-INF/lib 文件夹。

启动 Tomcat 并尝试运行示例应用程序。

运行示例应用程序

通过从浏览器访问 http://localhost:8080/acegiMethodSecurity URL 可调用示例应用程序。AcegiMethodSecurity 显示的索引页面包含两个链接（Catalog 和 Login），如图 2 所示：

当单击应用程序的 Catalog 链接时，它将要求您进行登录。如果以 alice 或 specialUser 的身份进行登录，示例应用程序将提供完整的 类别，包括公有数据和私有数据。这是因为在 清单 5 中，您对方法安全性拦截器进行了配置，允许用户使用 ROLE_HEAD_OF_ENGINEERING 访问私有类别，而 alice 和 specialUser 都具有该访问权。另一方面，如果您以 bob 的身份登录，示例应用程序将仅显示公有数据。

回页首

为通过身份验证的用户分配额外角色

本节将演示经过增强的示例应用程序。增强后的示例应用程序将展示 Acegi 如何使您能够在运行时向通过身份验证的用户临时分配额外角色。

当安全 bean（例如 清单 3 的 privateCatalog bean）要访问一个原创资源时，您可能需要使用额外的角色。例如，您可能考虑到您的安全 bean 需要通过 Java 的 Remote Method Invocation (RMI) 框架或一个 Web 服务访问某个远程应用程序。访问安全 bean 的用户不会占用远程应用程序要求访问用户所具备的业务角色。

在本例中，Acegi 首先检查用户是否经过授权来访问安全 bean。之后，Acegi 允许用户访问安全 bean。当安全 bean 试图访问远程服务时，它需要使用额外的业务角色。如果访问安全 bean 的用户不具备额外角色，安全 bean 就不能成功访问远程服务。

run-as-replacement 机制

Acegi 框架提供了一种名为 run-as-replacement 的简单机制，允许您仅在方法调用期间为通过身份验证的用户配置一个或多个额外角色。您可以使用 run-as-replacement 机制为访问远程应用程序的安全 bean 配置额外角色。这意味着只要安全 bean 需要访问远程应用程序，Acegi 将为用户装载额外角色，从而允许安全 bean 访问远程应用程序。

清单 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 属性的作用是向通过身份验证的用户动态添加角色。出于这个目的，runAsManager 属性包含了 RunAsManagerImpl bean 的定义。RunAsManagerImpl bean 只有在满足下面的条件时才可变为活跃状态：在 objectDefinitionSource 方法的角色定义中找到以 RUN_AS_ 为前缀的角色。例如，PrivateCatalog.getData() 方法的角色定义（清单 6 中以粗体显示的第二处增强）具有一个 RUN_AS_MANAGER 角色。

RunAsManagerImpl bean 包含一个名为 key 的属性，它封装的加密键用于确保只将额外的角色作为 run-as-replacement 程序的一部分生成。

当用户调用 getData() 方法时，RunAsManagerImpl bean 变为活跃状态并创建名为 RUN_AS_MANAGER 的额外角色，从而启用 getData() 方法访问远程应用程序。

增强的方法安全性

本文的 下载源代码 包含一个名为 EnhancedAcegiMethodSecurity 的示例应用程序，它可以演示 run-as-replacement 机制和程序。该应用程序将显示一个具有 Catalog 链接的索引页面。如果单击 Catalog 链接，将要求进行登录。

登录后，EnhancedAcegiMethodSecurity 应用程序将为您提供登录用户及其角色的完整信息。例如，如果以 alice 或 specialUser 身份登录，将向您显示用户的所有业务角色，包括额外创建的临时的 RUN_AS_MANAGER 角色。

结束语

在这份共分三部分的系列文章中，我介绍了如何使用 Acegi 安全系统增强基于 URL 的安全性和基于方法的安全性。您了解了如何设计访问控制策略并将它们托管在目录服务器中，如何对 Acegi 进行配置以与目录服务器进行通信，以及如何根据托管在服务器的访问控制策略制定身份验证和授权决策。

本系列的最后一篇文章主要介绍使用基于方法的安全性保护 Java 类实例。文章还解释了 Acegi 和 Spring 如何在内部创建和代理 Java 对象以及 bean 代理如何实现访问控制。文章包含了两个示例应用程序，您可以使用它们进一步研究本系列中学到的概念，更多有关使用 Acegi 保护 Java 应用程序的内容，请参见 参考资料 小节。

posted @ 2008-05-08 18:47 狼爱上狸 阅读(411) | 评论 (0) | 编辑 收藏