#

反向控制和面向切面编程在Spring的应用

引言

  在J2EE的整个发展历程中,现在正是一个非常时刻。从很多方面来说,J2EE都是一个伟大的成功:它成功地在从前没有标准的地方建立了标准;大大提升了企业级软件的开放程度,并且得到了整个行业和开发者的广泛认可。然而,J2EE在一些方面已经开始捉襟见肘。J2EE应用开发的成本通常很高。J2EE应用项目至少和从前的非J2EE项目一样容易失败——如果不是更容易失败的话。这样的失败率高得让人难以接受。在这样的失败率之下,软件开发几乎变成了碰运气。而在J2EE遭遇失败的场景中,EJB通常都扮演着重要的角色。因此,J2EE社群不断地向着更简单的解决方案、更少使用EJB的方向发展[1]。然而,每个应用程序都需要一些基础设施,拒绝使用EJB并不意味着拒绝EJB所采用的基础设施解决方案。那么,如何利用现有的框架来提供这些基础设施服务呢,伴随着这个问题的提出,一个轻量级的J2EE解决方案出现了,这就是Spring Framework。

  Spring是为简化企业级系统开发而诞生的,Spring框架为J2EE应用常见的问题提供了简单、有效的解决方案,使用Spring,你可以用简单的POJO(Plain Old Java Object)来实现那些以前只有EJB才能实现的功能。这样不只是能简化服务器端开发,任何Java系统开发都能从Spring的简单、可测试和松耦合特征中受益。可以简单的说,Spring是一个轻量级的反向控制(IoC)和面向切面编程(AOP)容器框架[3]。Spring IoC,借助于依赖注入设计模式,使得开发者不用理会对象自身的生命周期及其关系,而且能够改善开发者对J2EE模式的使用;Spring AOP,借助于Spring实现的拦截器,开发者能够实现以声明的方式使用企业级服务,比如安全性服务、事务服务等。Spring IoC和 Spring ; AOP组合,一起形成了Spring,这样一个有机整体,使得构建轻量级的J2EE架构成为可能,而且事实证明,非常有效。没有Spring IoC的Spring AOP是不完善的,没有Spring AOP的Spring IoC是不健壮的。本文是以Spring架构的成功的实际商务系统项目为背景,阐述了反向控制原理和面向切面的编程技术在Spring框架中的应用,同时抽取适量代码示意具体应用,并和传统开发模式进行对比,展示了Spring framework的简单,高效,可维护等优点。

  1、Spring IoC 1.1 反向控制原理

  反向控制是Spring框架的核心。但是,反向控制是什么意思?到底控制的什么方面被反向了呢?2004年美国专家Martin Fowler发表了一篇论文《Inversion of Control Containers and the Dependency Injection pattern》阐述了这个问题,他总结说是获得依赖对象的方式反向了,根据这个启示,他还为反向控制提出了一个更贴切的名字:Dependency Injection(DI 依赖注入)。

  通常,应用代码需要告知容器或框架,让它们找到自身所需要的类,然后再由应用代码创建待使用的对象实例。因此,应用代码在使用实例之前,需要创建对象实例。然而,IoC模式中,创建对象实例的任务交给IoC容器或框架(实现了IoC设计模式的框架也被称为IoC容器),使得应用代码只需要直接使用实例,这就是IoC。相对IoC 而言,“依赖注入”的确更加准确的描述了这种设计理念。所谓依赖注入,即组件之间的依赖关系由容器在运行期决定,形象的来说,即由容器动态的将某种依赖关系注入到组件之中。

  1.2 IoC在Spring中的实现

  任何重要的系统都需要至少两个相互合作的类来完成业务逻辑。通常,每个对象都要自己负责得到它的合作(依赖)对象。你会发现,这样会导致代码耦合度高而且难于测试。使用IoC,对象的依赖都是在对象创建时由负责协调系统中各个对象的外部实体提供的,这样使软件组件松散连接成为可能。下面示意了Spring IoC 应用,步骤如下:

  (1)定义Action接口,并为其定义一个execute方法,以完成目标逻辑。多年前,GoF在《Design Pattern:Elements of Reusable Object-Oriented Software》一书中提出“Programming to an Interface,not an implementation”的原则,这里首先将业务对象抽象成接口,正是为了实施这个原则。

  (2)类UpperAction实现Action接口,在此类中,定义一个String型的域message,并提供相应的setter和getter方法,实现的execute方法如下:

public String execute (String str) {
 return (getMessage () + str).toUpperCase () ;
}

  (3)编写Spring配置文件(bean.xml)

<beans>
<bean id="TheAction" class="net.chen.spring.qs.UpperAction">
<property name="message">
<value>HeLLo</value>
</property>
</bean>
</beans>

  (4)测试代码

public void testQuickStart () {
 ApplicationContext ctx=new
 FileSystemXmlApplicationContext ("bean.xml");
 Action a= (Action) ctx.getBean ("TheAction");
 System.out.println (a. execute ("Rod Johnson"));
}

  上面的测试代码中,我们根据"bean.xml"创建了一个ApplicationContext实例,并从此实例中获取我们所需的Action实现,运行测试代码,我们看到控制台输出:

……
HELLO ROD JOHNSON

  仔细观察一下上面的代码,可以看到:

  (1)我们的组件并不需要实现框架指定的接口,因此可以轻松的将组件从Spring中脱离,甚至不需要任何修改,这在基于EJB框架实现的应用中是难以想象的。

  (2)组件间的依赖关系减少,极大改善了代码的可重用性。Spring的依赖注入机制,可以在运行期为组件配置所需资源,而无需在编写组件代码时就加以指定,从而在相当程度上降低了组件之间的耦合。

  Spring给我们带来了如此这般的好处,那么,反过来,让我们试想一下,如果不使用Spring框架,回到我们传统的编码模式,情况会是怎样呢?

  首先,我们必须编写一个配置文件读取类,以实现Message属性的可配置化。

  其次,得有一个Factory模式的实现,并结合配置文件的读写完成Action的动态加载。于是,我们实现了一个ActionFactory来实现这个功能:

public class ActionFactory {
 public static Action getAction (String actionName) {Properties pro = new Properties ();
 try {
  pro.load (new FileInputStream ("config.properties"));
  String actionImplName =(String)pro.get(actionName);
  String actionMessage =(String) pro.get (actionName+"_msg");
  Object obj =Class.forName (actionImplName).newInstance ();
  BeanUtils.setProperty(obj,"message",actionMessage);
  return (Action) obj;
 } catch (FileNotFoundException e) {
  ……
 }
}

  配置文件则采用properties文件形式如下所示:

TheAction=net.chen.spring.qs.UpperAction
TheAction_msg=HeLLo

  测试代码也作相应修改。现在不论实现的好坏,总之通过上面新增的多行代码,终于实现了类似的功能。如果现在有了一个新的需求,这样这个ActionFactory每次都新建一个类的实例,显然这对系统性能不利,考虑到我们的两个Action都是线程安全的,修改一下ActionFactory,保持系统中只有一个Action实例供其它线程调用。另外Action对象创建后,需要做一些初始化工作。修改一下ActionFactory,使其在创建Action实例之后,随即就调用Action.init方法执行初始化。Action的处理这样就差不多了。下面我们来看看另外一个Factory

  ……

  往往这些系统开发中最常见的需求,会导致我们的代码迅速膨胀,而Spring IoC的出现,则大大缓解了这样的窘境。通过以上实例,可以看出,Spring IoC为我们提供了如下几方面的优势:

  (1)应用组件不需要在运行时寻找其协作者,因此更易于开发和编写应用;

  (2)由于借助于IoC容器管理组件的依赖关系,使得应用的单元测试和集成测试更利于展开;

  (3)通常,在借助于IoC容器关系业务对象的前提下,很少需要使用具体IoC容器提供的API,这使得集成现有的遗留应用成为可能。

  因此,通过使用IoC能够降低组件之间的耦合度,最终,能够提高类的重用性,利于测试,而且更利于整个产品或系统集成和配置。
2、Spring AOP

  2.1 面向切面编程基础

  通常,系统由很多组件组成,每个组件负责一部分功能,然而,这些组件也经常带有一些除了核心功能之外的附带功能 。系统服务如日志、事务管理和安全经常融入到一些其他功能模块中。这些系统服务通常叫做交叉业务,这是因为它们总是分布在系统的很多组件中。通过将这些业务分布在多个组件中,给我们的代码引入了双重复杂性。

  (1) 实现系统级业务的代码在多个组件中复制。这意味着如果你要改变这些业务逻辑,你就必须到各个模块去修改。就算把这些业务抽象成一个独立模块,其它模块只是调用它的一个方法,但是这个方法调用也还是分布在很多地方。

  (2) 组件会因为那些与自己核心业务无关的代码变得杂乱。一个向地址录中添加条目的方法应该只关心如何添加地址,而不是关心它是不是安全或支持事务的。

  此时,我们该怎么办呢?这正是AOP用得着的地方。AOP帮助我们将这些服务模块化,并把它们声明式地应用在需要它们的地方,使得这些组件更加专注于自身业务,完全不知道其它涉及到的系统服务。

  这里的概念切面,就是我们要实现的交叉功能,是应用系统模块化的一个方面或领域。切面的最常见例子就是日志记录。日志记录在系统中到处需要用到,利用继承来重用日志模块是不合适的,这样,就可以创建一个日志记录切面,并且使用AOP在系统中应用。下图展示了切面应用方式


图表 1 应用切面

  其中,通知Advice是切面的实际实现。连接点Joinpoint是应用程序执行过程中插入切面的地点,这个地点可以是方法调用,异常抛出,甚至可以是要修改的字段,切面代码在这些地方插入到你的应用流程中,添加新的行为。切入点Pointcut定义了Advice应该应用在那些连接点,通常通过指定类名和方法名,或者匹配类名和方法名式样的正则表达式来指定切入点。

  2.2 AOP在Spring中的实现

  基于AOP,业界存在各种各样的AOP实现,比如,JBoss AOP、Spring AOP、AspectJ、Aspect Werkz等。各自实现的功能也不一样。AOP实现的强弱在很大程度上取决于连接点模型。目前,Spring只支持方法级的连接点。这和一些其他AOP框架不一样,如AspectJ和JBoss,它们还提供了属性接入点,这样可以防止你创建特别细致的通知,如对更新对象属性值进行拦截。然而,由于Spring关注于提供一个实现J2EE服务的框架,所以方法拦截可以满足大部分要求,而且Spring的观点是属性拦截破坏了封装,让Advice触发在属性值改变而不是方法调用上无疑是破坏了这个概念。

  Spring的AOP框架的关键点如下:

  (1)Spring实现了AOP联盟接口。在Spring AOP中,存在如下几种通知(Advice)类型

  Before通知:在目标方法被调用前调用,涉及接口org.springframework.aop.MethodBeforeAdvice;

  After通知:在目标方法被调用后调用,涉及接口为org.springframework.aop.AfterReturningAdvice;

  Throws通知:目标方法抛出异常时调用,涉及接口org.springframework.aop.MethodBeforeAdvice;

  Around通知:拦截对目标对象方法调用,涉及接口为org.aopalliance.intercept.MethodInterceptor。

  (2)用java编写Spring通知,并在Spring的配置文件中,定义在什么地方应用通知的切入点。

  (3)Spring的运行时通知对象。代理Bean只有在第一次被应用系统需要的时候才被创建。如果你使用的是ApplicationContext,代理对象在BeanFactory载入所有Bean的时候被创建。Spring有两种代理创建方式。如果目标对象实现了一个或多个接口暴露的方法,Spring将使用JDK的java.lang.reflect.Proxy类创建代理。这个类让Spring动态产生一个新的类,它实现所需的接口,织入了通知,并且代理对目标对象的所有请求。如果目标对象没有实现任何接口,Spring使用CGLIB库生成目标对象的子类。在创建这个子类的时候,Spring将通知织入,并且将对目标对象的调用委托给这个子类。此时,需要将Spring发行包lib/cglib目录下的JAR文件发布到应用系统中。

  2.3 Spring AOP的优势

  借助于Spring AOP,Spring IoC能够很方便的使用到非常健壮、灵活的企业级服务,是因为Spring AOP能够提供如下几方面的优势:

  (1)允许开发者使用声明式企业服务,比如事务服务、安全性服务;EJB开发者都知道,EJB组件能够使用J2EE容器提供的声明式服务,但是这些服务要借助于EJB容器,而Spring AOP却不需要EJB容器,借助于Spring的事务抽象框架就可以这些服务。

  (2)开发者可以开发满足业务需求的自定义切面;

  (3)开发Spring AOP Advice很方便。因为这些AOP Advice仅是POJO类,借助于Spring提供的ProxyFactoryBean,能够快速的搭建Spring AOP Advice。

  3、结语

  本文详细阐述了Spring背后的IoC原理和AOP技术,以实际成功项目为背景,抽取简短片断,展示了Spring架构J2EE应用系统的原理。Spring IoC借助于依赖注入机制,减轻了组件之间的依赖关系,同时也大大提高了组件的可移植性,组件得到了更多的重用机会。借助于Spring AOP,使得开发者能声明式、基于元数据访问企业级服务,AOP合理补充了OOP技术,Spring AOP合理地补充了Spring IoC容器。Spring IoC与Spring AOP组合,使得Spring成为成功的J2EE架构框架,并能与标准的EJB等标准对抗,EJB不再是必需品。Spring已经冲入了J2EE的核心,将引领整个J2EE开发、架构的方向。

posted @ 2008-08-25 18:08 金家寶 阅读(220) | 评论 (0)编辑 收藏

GoF设计模式

著名的EJB领域顶尖的专家Richard Monson-Haefel在其个人网站:www.EJBNow.com中极力推荐的GoF的《设计模式》,原文如下:

Design Patterns
Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have suffered a very serious gap in your programming education that should be remedied immediately.

翻译: 很多程序员在读完这本书,宣布自己相当于经历了一次"主显节"(纪念那稣降生和受洗的双重节日),如果你从来没有读过这本书,你会在你的程序教育生涯里存在一个严重裂沟,所以你应该立即挽救弥补!

可以这么说:GoF设计模式是程序员真正掌握面向对象核心思想的必修课。虽然你可能已经通过了SUN的很多令人炫目的技术认证,但是如果你没有学习掌握GoF设计模式,只能说明你还是一个技工。

在浏览《Thingking in Java》(第一版)时,你是不是觉得好象这还是一本Java基础语言书籍?但又不纯粹是,因为这本书的作者将面向对象的思想巧妙的融合在Java的具体技术上,潜移默化的让你感觉到了一种新的语言和新的思想方式的诞生。

但是读完这本书,你对书中这些蕴含的思想也许需要一种更明晰更系统更透彻的了解和掌握,那么你就需要研读GoF的《设计模式》了。

《Thingking in Java》(第一版中文)是这样描述设计模式的:他在由Gamma, Helm和Johnson Vlissides简称Gang of Four(四人帮),缩写GoF编著的《Design Patterns》一书中被定义成一个“里程碑”。事实上,那本书现在已成为几乎所有OOP(面向对象程序设计)程序员都必备的参考书。(在国外是如此)。

GoF的《设计模式》是所有面向对象语言(C++ Java C#)的基础,只不过不同的语言将之实现得更方便地使用。

GOF的设计模式是一座"桥"
就Java语言体系来说,GOF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。

会Java的人越来越多,但是一直徘徊在语言层次的程序员不在少数,真正掌握Java中接口或抽象类的应用不是很多,大家经常以那些技术只适合大型项目为由,避开或忽略它们,实际中,Java的接口或抽象类是真正体现Java思想的核心所在,这些你都将在GoF的设计模式里领略到它们变幻无穷的魔力。

GoF的设计模式表面上好象也是一种具体的"技术",而且新的设计模式不断在出现,设计模式自有其自己的发展轨道,而这些好象和J2EE .Net等技术也无关!

实际上,GoF的设计模式并不是一种具体"技术",它讲述的是思想,它不仅仅展示了接口或抽象类在实际案例中的灵活应用和智慧,让你能够真正掌握接口或抽象类的应用,从而在原来的Java语言基础上跃进一步,更重要的是,GoF的设计模式反复向你强调一个宗旨:要让你的程序尽可能的可重用。

这其实在向一个极限挑战:软件需求变幻无穷,计划没有变化快,但是我们还是要寻找出不变的东西,并将它和变化的东西分离开来,这需要非常的智慧和经验。

而GoF的设计模式是在这方面开始探索的一块里程碑。

J2EE等属于一种框架软件,什么是框架软件?它不同于我们以前接触的Java API等,那些属于Toolkist(工具箱),它不再被动的被使用,被调用,而是深刻的介入到一个领域中去,J2EE等框架软件设计的目的是将一个领域中不变的东西先定义好,比如整体结构和一些主要职责(如数据库操作 事务跟踪 安全等),剩余的就是变化的东西,针对这个领域中具体应用产生的具体不同的变化需求,而这些变化东西就是J2EE程序员所要做的。

由此可见,设计模式和J2EE在思想和动机上是一脉相承,只不过

1.设计模式更抽象,J2EE是具体的产品代码,我们可以接触到,而设计模式在对每个应用时才会产生具体代码。

2.设计模式是比J2EE等框架软件更小的体系结构,J2EE中许多具体程序都是应用设计模式来完成的,当你深入到J2EE的内部代码研究时,这点尤其明显,因此,如果你不具备设计模式的基础知识(GoF的设计模式),你很难快速的理解J2EE。不能理解J2EE,如何能灵活应用?

3.J2EE只是适合企业计算应用的框架软件,但是GoF的设计模式几乎可以用于任何应用!因此GoF的设计模式应该是J2EE的重要理论基础之一。

所以说,GoF的设计模式是Java基础知识和J2EE框架知识之间一座隐性的"桥"。为什么说隐性的?

GOF的设计模式是一座隐性的"桥"
因为很多人没有注意到这点,学完Java基础语言就直接去学J2EE,有的甚至鸭子赶架,直接使用起Weblogic等具体J2EE软件,一段时间下来,发现不过如此,挺简单好用,但是你真正理解J2EE了吗?你在具体案例中的应用是否也是在延伸J2EE的思想?

如果你不能很好的延伸J2EE的思想,那你岂非是大炮轰蚊子,认识到J2EE不是适合所有场合的人至少是明智的,但我们更需要将J2EE用对地方,那么只有理解J2EE此类框架软件的精髓,那么你才能真正灵活应用Java解决你的问题,甚至构架出你自己企业的框架来。(我们不能总是使用别人设定好的框架,为什么不能有我们自己的框架?)

因此,首先你必须掌握GoF的设计模式。虽然它是隐性,但不是可以越过的。

 

关于本站“设计模式”

Java提供了丰富的API,同时又有强大的数据库系统作底层支持,那么我们的编程似乎变成了类似积木的简单"拼凑"和调用,甚至有人提倡"蓝领程序员",这些都是对现代编程技术的不了解所至.

在真正可复用的面向对象编程中,GoF的《设计模式》为我们提供了一套可复用的面向对象技术,再配合Refactoring(重构方法),所以很少存在简单重复的工作,加上Java代码的精炼性和面向对象纯洁性(设计模式是java的灵魂),编程工作将变成一个让你时刻体验创造快感的激动人心的过程.

为能和大家能共同探讨"设计模式",我将自己在学习中的心得写下来,只是想帮助更多人更容易理解GoF的《设计模式》。由于原著都是以C++为例, 以Java为例的设计模式基本又都以图形应用为例,而我们更关心Java在中间件等服务器方面的应用,因此,本站所有实例都是非图形应用,并且顺带剖析Jive论坛系统.同时为降低理解难度,尽量避免使用UML图.

如果你有一定的面向对象编程经验,你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手,那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式,便于他人理解;让你自己减少重复性的编程工作),这无疑是成为一个优秀程序员的必备条件.

整个设计模式贯穿一个原理:面对接口编程,而不是面对实现.目标原则是:降低耦合,增强灵活性.

posted @ 2008-07-07 11:05 金家寶 阅读(268) | 评论 (0)编辑 收藏

什么是MIS

所谓MIS(管理信息系统--Management Information System)系统,是一个由人、计算机及其他外围设备等组成的能进行信息的收集、传递、存贮、加工、维护和使用的系统。它是一门新兴的科学,其主要任务是最大限度的利用现代计算机及网络通讯技术加强企业的信息管理,通过对企业拥有的人力、物力、财力、设备、技术等资源的调查了解,建立正确的数据,加工处理并编制成各种信息资料及时提供给管理人员,以便进行正确的决策,不断提高企业的管理水平和经济效益。目前,企业的计算机网络已成为企业进行技术改造及提高企业管理水平的重要手段。随着我国与世界信息高速公路的接轨,企业通过计算机网络获得信息必将为企业带来巨大的经济效益和社会效益,企业的办公及管理都将朝着高效、快速、无纸化的方向发展。MIS系统通常用于系统决策,例如,可以利用MIS系统找出目前迫切需要解决的问题,并将信息及时反馈给上层管理人员,使他们了解当前工作发展的进展或不足。换句话说,MIS系统的最终目的是使管理人员及时了解公司现状,把握将来的发展路径。

  一个完整的MIS应包括:辅助决策系统(DSS)、工业控制系统(IPC)、办公自动化系统(OA)以及数据库、模型库、方法库、知识库和与上级机关及外界交换信息的接口。其中,特别是办公自动化系统(OA)、与上级机关及外界交换信息等都离不开Intranet的应用。可以这样说,现代企业MIS不能没有 Intranet,但Intranet的建立又必须依赖于MIS的体系结构和软硬件环境。

  传统的MIS系统的核心是CS (Client/Server——客户端/服务器)架构,而基于Internet的MIS系统的核心是BS(Browser/Server——浏览器/服务器)架构。BS架构比起CS架构有着很大的优越性,传统的MIS系统依赖于专门的操作环境,这意味着操作者的活动空间受到极大限制;而BS架构则不需要专门的操作环境,在任何地方,只要能上网,就能够操作MIS系统,这其中的优劣差别是不言而喻的。

  基于Internet上的 MIS系统是对传统MIS系统概念上的扩展,它不仅可以用于高层决策,而且可以用于进行普通的商务管理。通过用户的具名登录(或匿名登录),以及相应的权限控制,可以实现在远端对系统的浏览、查询、控制和审阅。随着Internet的扩展,现有的公司和学校不再局限于物理的有形的真实的地域,网络本身成为事实上发展的空间。基于Internet上的MIS系统,弥补了传统MIS系统的不足,充分体现了现代网络时代的特点。随着Internet技术的高速发展,因特网必将成为人类新社会的技术基石。基于Internet的MIS系统必将成为网络时代的新一代管理信息系统,前景极为乐观

posted @ 2008-07-05 19:20 金家寶 阅读(209) | 评论 (0)编辑 收藏

开发者版本:你属于哪个版本的程序员?

国外开发者博客中有一篇有趣的文章,将程序员按水平像软件版本号那样划分为不同的版本。相对于在招聘时分为初级,中级,高级程序员,直接表明需要某种语言N版本的程序员或许更方便直接。根据作者的观点,可将WEB开发者大致分为以下几个版本:

Alpha:阅读过一些专业书籍,大多数能用Dreamweaver或者FrontPage帮朋友制作一些Web页面。但在他们熟练掌握HTML代码以前,你大概不会雇佣他们成为职业的WEB制作人员。

Beta:已经比较擅长整合站点页面了,在HTML技巧方面也有一定造诣,但还是用Tables来制作页面,不了解CSS,在面对动态页面或数据库连接时还是底气不足。

Pre Version 1 (0.1):比Beta版的开发者水平要高。熟悉HTML,开始了解CSS是如何运作的,懂一点JavaScript,但还是基于业余水准,逐步开始关心动态站点搭建和数据库连接的知识。这个版本的WEB开发人员还远不能成为雇主眼中的香饽饽。

1.0: 能够基本把控整个站点开发,针对每个问题尽可能的找到最直接的解决办法。但对可测性,可扩展性以及在不同(层)框架下如何选择最合适的WEB设计工具尚无概念。这个版本的WEB开发者有良好的技术基础,需要有进一步的帮助和指导。



2.0:懂面向对象的编程语言,理解分层开发的必要性,关注代码分离,对问题寻找更完美的解决方法,偶然也会考虑设计模式的问题,但对此仍然概念不清。属于优秀的初级开发者,能完成较松散的代码开发(相对大型严谨的站点开发而言),在面对较复杂问题寻找解决办法时需要周边人的帮助。

3.0:开始较为深入的理解面向对象编程和设计模式,了解他们的用途,当看到好的设计模式时能看透其本质,逐步关注分层的架构解决办法和可测试性。理解不同的开发语言并能说出他们的异同(例如各自的优势)。属于优秀的中级别开发者,雇主也确信他们最终能找到问题的解决办法,这个版本的人可以给1.0和2.0的开发者以指导。但他们对架构的理解仍然不够清晰,值得一提的是,只要给予一些指导,他们能很快理解并熟记做出的决定,以及选定方案的优势所在。

4.0:
理解模式,重视用户的反馈。着手研究方法论,架构设计和软件开发的最佳入口。头脑中已经形成了超越开发语言,技术架构的整体方案,可根据需求解构程序。能从理论的角度,不同模式如何融合成最佳形态,将多种X-驱动的模式应用到不同的方案中。是精通多语言的高手,理解不同系统和方法论的细微差别,属于高级程序员。这个级别的人能够轻易的辅导2.0和3.0的程序员,将他们推向更高的级别。

5.0:从系统的角度考虑问题。对各种系统结构有深入研究,能对整个代码架构中的问题进行改进。在团队粘合性以及代码安全性方面有杰出贡献。对1.0到4.0版本的开发人员出现的问题能及时察觉,让整个团队保持积极性且保持兴奋的状态创建软件解决办法。举例来说,他们总是对新的技术和信息保持饥渴状态,试图用最简便的方案解决开发任务。在整个IT团队中获得信任,属于高级程序员和架构师。

那么,您属于哪个版本的程序员呢?

posted @ 2008-06-27 10:47 金家寶 阅读(227) | 评论 (0)编辑 收藏

Eclipse官方网站已经正式宣布 Eclipse 3.4发布

感谢Wendal,匿名人士的投递
Eclipse官方网站已经正式宣布 Eclipse 3.4发布,代号为ganymede (Ganymede (英语发音"GAN uh meed")为最大的木星已知卫星,也是第七颗发现的木星卫星,在伽利略发现的卫星中离木星第三近,在希腊神话中 Ganymede是一个特洛伊美人的男孩(一个美少男),被宙斯带去给众神斟酒)。

 

关注Eclipse项目的开发者朋友们可以下载3.4版本尝试一下,在JavaEye上还专门介绍一个很酷的Eclipse3.4带的实时结对编程插件

目前3.4版本是Eclipse项目发布的10周年庆典版;至今Eclipse项目共有23个子项目。此次发布的Ganymede 版本引入不少亮点,其中包括新的p2平台(provisioning platform),点击查看p2的介绍、新增的Equinox(OSGi实现)安全方面的特性、全新的Ecore建模工具、支持SOA等。

posted @ 2008-06-26 09:01 金家寶 阅读(795) | 评论 (1)编辑 收藏

[转]Java语言的细节

Java作为一门优秀的面向对象的程序设计语言,正在被越来越多的人使用。本文试图列出作者在实际开发中碰到的一些Java语言的容易被人忽视的细节,希望能给正在学习Java语言的人有所帮助。
 
1,拓宽数值类型会造成精度丢失吗?
    Java语言的8种基本数据类型中7种都可以看作是数值类型,我们知道对于数值类型的转换有一个规律:从窄范围转化成宽范围能够自动类型转换,反之则必须强制转换。请看下图:
byte-->short-->int-->long-->float-->double
char-->int
我们把顺箭头方向的转化叫做拓宽类型,逆箭头方向的转化叫做窄化类型。一般我们认为因为顺箭头方向的转化不会有数据和精度的丢失,所以Java语言允许自动转化,而逆箭头方向的转化可能会造成数据和精度的丢失,所以Java语言要求程序员在程序中明确这种转化,也就是强制转换。那么拓宽类型就一定不会造成数据和精度丢失吗?请看下面代码:
int i=2000000000;
int num=0;
for(float f=i;f<i+50;f++){
    num++;
}
System.out.println(num);
请考察以上代码输出多少?
如果你回答50 ,那么请运行一下,结果会让你大吃一惊!没错,输出结果是0,难道这个循环根本就没有执行哪怕一次?确实如此,如果你还不死心,我带你看一个更诧异的现象,运行以下代码,看输出什么?
int i=2000000000;
float f1=i;
float f2=i+50;
System.out.println(f1==f2);
    哈哈,你快要不相信你的眼睛了,结果竟然是true;难道f1和f2是相等的吗?是的,就是这样,这也就能解释为什么上一段代码输出的结果是0,而不是50了。那为什么会这样呢?关键原因在于你将int值自动提升为float时发生了数据精度的丢失,i的初始值是2000000000,这个值非常接近Integer.MAX_VALUE,因此需要用31位来精确表示,而float只能提供24位数据的精度(另外8位是存储位权,见IEEE745浮点数存储规则)。所以在这种自动转化的过程中,系统会将31位数据的前24位保留下来,而舍弃掉最右边的7位,所以不管是2000000000还是2000000050,舍弃掉最右边7位后得到的值是一样的。这就是为什么f1==f2的原因了。
    类似的这种数值拓宽类型的过程中会造成精度丢失的还有两种情况,那就是long转化成float和long转化成double,所以在使用的时候一定要小心。
 
2,i=i+1和i+=1完全等价吗?
    可能有很多程序员认为i+=1只是i=i+1的简写方式,其实不然,它们一个使用简单赋值运算,一个使用复合赋值运算,而简单赋值运算和复合赋值运算的最大差别就在于:复合赋值运算符会自动地将运算结果转型为其左操作数的类型。看看以下的两种写法,你就知道它们的差别在哪儿了:
  (1) byte i=5;
      i+=1;
  (2) byte i=5;
      i=i+1;
    第一种写法编译没问题,而第二种写法却编译通不过。原因就在于,当使用复合赋值运算符进行操作时,即使右边算出的结果是int类型,系统也会将其值转化为左边的byte类型,而使用简单赋值运算时没有这样的优待,系统会认为将i+1的值赋给i是将int类型赋给byte,所以要求强制转换。理解了这一点后,我们再来看一个例子:
  byte b=120;
  b+=20;
  System.out.println("b="+b);
  说到这里你应该明白了,上例中输出b的值不是140,而是-116。因为120+20的值已经超出了一个byte表示的范围,而当我们使用复合赋值运算时系统会自动作类型的转化,将140强转成byte,所以得到是-116。由此可见,在使用复合赋值运算符时还得小心,因为这种类型转换是在不知不觉中进行的,所以得到的结果就有可能和你的预想不一样。
 
3,位移运算越界怎么处理
    考察下面的代码输出结果是多少?
    int a=5;
    System.out.println(a<<33);
    按照常理推测,把a左移33位应该将a的所有有效位都移出去了,那剩下的都是零啊,所以输出结果应该是0才对啊,可是执行后发现输出结果是10,为什么呢?因为Java语言对位移运算作了优化处理,Java语言对a<<b转化为a<<(b%32)来处理,所以当要移位的位数b超过32时,实际上移位的位数是b%32的值,那么上面的代码中a<<33相当于a<<1,所以输出结果是10。
 
4,判断奇数
  以下的方法判断某个整数是否是奇数,考察是否正确:
   public boolean isOdd(int n){
       return (n%2==1);
   }
   很多人认为上面的代码没问题,但实际上这段代码隐藏着一个非常大的BUG,当n的值是正整数时,以上的代码能够得到正确结果,但当n的值是负整数时,以上方法不能做出正确判断。例如,当n=-3时,以上方法返回false。因为根据Java语言规范的定义,Java语言里的求余运算符(%)得到的结果与运算符左边的值符号相同,所以,-3%2的结果是-1,而不是1。那么上面的方法正确的写法应该是:
   public boolean isOdd(int n){
       return (n%2!=0);
   }
 
5,可以让i!=i吗?
在本题中,要求你声明一个i值,使得以下程序输出"No i!=i":
//在此声明i,并赋值。
if(i==i){
      System.out.println("Yes i==i");
  }else{
      System.out.println("No i!=i");
  }
 
    当你看到这个命题的时候一定会以为我疯了,或者Java语言疯了。这看起来是绝对不可能的,一个数怎么可能不等于它自己呢?或许就真的是Java语言疯了,不信请将i做出以下声明,再运行上面的代码。
  double i=0.0/0.0;
    上面的代码输出"No i!=i",为什么会这样呢?关键在0.0/0.0这个值,在IEEE 754浮点算术规则里保留了一个特殊的值用来表示一个不是数字的数量。这个值就是NaN("Not a Number"的缩写),对于所有没有良好定义的浮点计算都将得到这个值,比如:0.0/0.0;其实我们还可以直接使用Double.NaN来得到这个值。在IEEE 754规范里面规定NaN不等于任何值,包括它自己。所以就有了i!=i的代码。
 
6,2.0-1.1==0.9吗?
 考察下面的代码:
 double a=2.0,b=1.1,c=0.9;
 if(a-b==c){
   System.out.println("YES!");
 }else{
   System.out.println("NO!");
 }
以上代码输出的结果是多少呢?你认为是“YES!”吗?那么,很遗憾的告诉你,不对,Java语言再一次欺骗了你,以上代码会输出“NO!”。为什么会这样呢?其实这是由实型数据的存储方式决定的。我们知道实型数据在内存空间中是近似存储的,所以2.0-1.1的结果不是0.9,而是0.88888888889。所以在做实型数据是否相等的判断时要非常的谨慎。一般来说,我们不建议在代码中直接判断两个实型数据是否相等,如果一定要比较是否相等的话我们也采用以下方式来判断:
  if(Math.abs(a-b)<1e-5){
     //相等
  }else{
    //不相等
  }
上面的代码判断a与b之差的绝对值是否小于一个足够小的数字,如果是,则认为a与b相等,否则,不相等。

posted @ 2008-06-13 14:41 金家寶 阅读(479) | 评论 (2)编辑 收藏

WEB交互界面易用性设计和验收的指导性原则

随着企业intranet和国际internet的迅速发展,越来越多的工作流程,商务交易,教育、培训、会议和讲座,以及个人消费娱乐都被转移到所谓的万维网(world wide web,以下简称web)上来了。与此相对应的是交互操作的复杂性越来越高。

随着browser rver模式的日渐流行,很多操作都是在浏览器环境下的网页上完成的,并不是只有失效的链接和意外的出错才会使操作者感到烦恼,即便是一次完整的成功操作过程,也可能因为操作的繁复性过高或者使用上的不方便而给操作者带来不愉快的体验。

本文试图阐述web交互页面设计的一些指导性原则,这些原则有利于避免发生不愉快的操作体验。这些原则是用户友好性的,是在完成同一种操作要求下,使用户最感到轻松、简单、舒适的web交互界面设计原则。我们假定我们讨论的web页面都是功能正常的,符合美学观点的。需要说明我们讨论的原则可能会和设计上的美学观点以及既有的功能设计有所冲突。如果发生这种情况,基于“实用的就是美的”观点,我们会建议您酌情放弃原先的美学观点与功能设计。

一、输入控件的自动聚焦和可用键盘切换输入焦点

    使用javascript实现页面加载完成后立即自动聚焦(focus)到第一个输入控件。可用tab键(ie缺省实现)或方向键切换聚焦到下一个输入控件。

    输入控件指web页面表单(<form> )中显式的,需要用户进行修改、编辑操作的表单元素。对于这些控件,如果没有自动聚焦操作,不可避免的出现一次用户鼠标定位操作(如果用户此前处于键盘输入操作状态或鼠标定位后需要进行键盘输入操作,实际上是键盘鼠标切换操作)。如果鼠标定位后需要进行键盘输入操作,如果不能键盘切换输入焦点,那么不可避免的在切换输入焦点时需要反复的键盘鼠标切换操作,这是很繁琐的。

    如果实现了页面加载完成即自动聚焦到第一个输入控件,并且可以键盘切换输入焦点标定位操作,那么对于用户来说整个页面的输入操作可能都不需要鼠标操作,或次数较少,这是一种便利。毕竟频繁的键盘鼠标切换操作是比较累人的。

    对于有输入栏的对话框或网页,在不干预的情况下就应将当前控制焦点定位在待输入的输入栏上;如果输入栏在一般情况下不需要更改其中的内容,则应直接将焦点定在“确定”按钮上;在几个输入栏之间应支持tab,shift+tab切换操作,“确定”和“取消”应该是切换操作的终点,与具体所在位置无关。

二、可用enter(或ctrl+enter)键提交,确保和点击提交按钮的效果是相同的

不要在提交按钮上加入onclick=”…”这样的javascript代码。

    用enter键提交页面是原则1的自然延伸,而且这也是浏览器所缺省支持的。只所以单独列出来是因为实际上有些设计者设计的页面不能达到这种效果,结果导致使用enter键提交和点击“确定”按钮提交带来的效果不一样。大部分情况下是设计者在“确定”按钮上加入了onclik=”…”这样的代码,通过点击“确定”按钮后,会执行一段javascript代码,比如对某些hidden类型的input元素设值。而使用enter键提交时就不会执行这段代码。

    正确的做法是把这段代码移到表单标签<form>中,以onsubmit=”…”属性引入。

    对于<textarea>表单元素,它会消耗enter键,因此会使得enter键提交失效。可以引入javascript代码捕捉ctrl+enter复合键,一旦捕捉到即执行表单的submit()方法。对于需要频繁提交的场合,比如bbs上,这种代码是很有必要的。

三、鼠标动作提示和回应

    对用户的鼠标定位操作,当移动到可响应的位置上时,应给予视觉或听觉的提示。

    动作回应的最简单形式就是鼠标icon变成手状。浏览器只对具有href属性的html标签会自动进行这种变换icon的行为。对于没有href属性(或没有设置href属性)的标签,可以通过javascript设置style属性的cursor为hand。

    目标区域发生变化是更为主动的响应形式。当鼠标指针移到目标区域,此时指针图形改变或文字颜色发生改变均能较大的减轻用户搜索定位目标区域的注意力负担。在按钮上增添直观的图形,尽可能的增大按钮面积;按钮间保持适当的距离,太近增加了用户区别它们之间界限以防误操作的负担,太远增加了用户搜索定位按钮的负担。

四、尽可能早的在客户端完成输入数据合法性验证

    输入数据的合法性检验应该在客户端使用javascript进行验证。除非验证只能在服务器端完成,否则验证工作应在最早能完成的情况下进行。

    在客户端完成数据合法性验证,可以避免一次服务器请求和回复通讯,这种通讯是需要用户等待的,如果用户等待很长时间后从服务器返回的结果提示出现的错误是在输入时即可发现的,那么这种设计就是不友好的。诸如密码长度限制,用户名允许字符限制等等,显然应该在客户端提交前就应该进行验证。

五、根据应用场景决定在表单页面和提交后返回页面间是否使用中间过渡页面

    根据应用场景,决定是否显示接收表单页面(表单页面和提交后返回页面间的中间过渡页面),以及使用何种方式显示接收表单页面。

表单页面和接收表单页面是大部分web交互操作赖以实现的配合模式。关于表单页面和接收表单页面的相互关系的设计,要做如下几个方面的考虑。

1.对于需要频繁操作的场合,从操作便利和快捷性出发,尽可能的减少服务器和客户端交互次数,应该避免使用中间过渡页面。提交完毕直接返回原来的表单页面或默认页面。在这种情况下要考虑到数据安全和可恢复性。

如果因为用户输入的数据不合格,需要重新输入,那么,去除中间页面,把错误信息直接显示在原表单页面上的设计方式,将是最简洁的处理方式。用户只需要根据错误提示进行更正即可。当然这样做稍微增加了编程负担。在表单接收页面上需要包含原表单页面的内容,而且输入数据项都必须用服务器端代码或客户端javascript设置成用户输入的值。为了开发快捷,可以这样做:表单页面和接收表单页面用同一个服务器端脚本页面实现。这个页面按如下流程完成原来两个页面的工作:

页面脚本初始化

检查“提交”变量是否设置

┠已设置,做数据验证

┃ ┠验证通过->业务逻辑处理->使用包含页面方式或重定向方式返回到特定页面

┃ ┗验证不通过->保存用户输入的数据->退出表单提交处理到表单页面流程中

┗未设置,做表单页面流程,如有来自提交流程中产生的用户输入数据,则显示出来

其中,使用包含页面方式返回到特定页面可以避免一次客户端重定向过程,比客户端重定向过程还要快捷和稳定一些。但是有些情况下因为代码变量冲突或其他原因,使用包含页面方式可能并不方便,这时候可以使用服务器端重定向技术,在asp里是server.transfer方法,在java servlet里是requestdispatcher.forward()方法。不要使用response.redirect或者httpservletresponse.sendredirect()这种客户端http重定向方法。不使用中间过渡页面也就意味着用户不能后退浏览原先已经填好的表单页面,因为使用的是同一个url。所以在验证不通过情况下保存用户输入的数据就是必不可少的。

不使用中间过渡页面带来的另一个问题就是使用包含页面方式或服务器端重定向方式返回会使得url和页面内容不能一一对应。对于用户可能会直接用这个url(会收藏这个url)访问返回页面的情况,他会发现实际上到达的是表单页面,不是他想要的那个返回结果页面。所以,去除中间过渡页面,确实会带来url和内容含混不清的情况,因而不适合需要url和页面内容一一对应的场合。

2.从技术角度考虑,使用中间过渡页面能保证url和页面内容一一对应,简化页面开发工作。

为了保证页面内容总是和固定的url联系起来,必须使用客户端重定向:

提交   业务逻辑处理 (中间过渡页面)

表单页面――――->接收表单页面―――――――――>显示处理结果―――>客户端重定向到特定页面

客户端重定向分几种情况:

1.使用http header重定向,location: http://www.netall.com.cn,这种定向是最快的,在窗口一片空白的情况下就迅速访问(get)另一个页面。这种方式实际上不能显示处理结果,只能说是向第一种快速重定向方式的一种折衷处理;

2.html标签刷新,<meta http-equiv=”refresh” content=”5;url=http://www.netall.com.cn”>,这种定向比较友好,在这个页面加载完毕后访问另一个页面。很多设计者把这个作为一个技巧使用,在载入一个大页面前放置一个缓冲页面以避免用户乏味的等待;

3.javascript重定向。由于是用代码控制重定向,可以做的更灵活。比如根据用户习惯,控制操作完毕后的转向流程。

4.被动式的重定向。在页面上放置按钮或链接,由用户手动决定返回到特定页面。这种情况适合于处理结果的显示页面包含相当多的信息,需要用户仔细浏览,而决定下一步的操作。

   在使用中间过渡页面的情况下,不能再使用页面过期失效了。否则一旦出现错误,需要用户重新输入表单数据,用户就不能用后退按钮恢复此前填写的表单数据了。除非设计者有意禁止这种恢复。

六、防止表单重复提交处理

    对提交按钮点击后做变灰处理避免在网络响应较慢情况下用户重复提交同一个表单。使用页面过期失效避免用户后退浏览重复提交表单。

    有些复杂的应用会导致需要较长时间的等待才会返回处理结果。而在较慢的网络环境中,这种情况更是频繁发生。焦急等待的用户往往会重复点击提交按钮。这种情况是设计者所不希望看到的。

    使用javascript在点击提交按钮后使按钮失效变灰是一个最直接的办法(根据原则2这段代码应该放在<form>标签里onsubmit=”…”做)。此外,在表单页面上,用服务器端脚本设置http header的expires为立即过期可以保证用户没办法使用后退浏览恢复表单页面。注意这样做的代价可能是用户辛辛苦苦填写很长的内容,结果一旦操作失误就没法恢复。所以应该避免在包含<textarea>表单元素的页面上使用页面过期失效。

    应该说,更严格的方法是,服务器端脚本就应该具备抵抗重复提交的能力。例如,为这个表单分配一个唯一id或一个使用一次即失效的验证码。此外,这个表单处理还应具有事务性质,如果表单不被接受,所做的改变还是能恢复的。在金融应用场合,重复提交同一笔交易是肯定不被允许的。能在重复提交中获利的一方总是会想办法绕过浏览器的限制,所以不能依赖于客户端的技术。

七、页面链接是打开新窗口、使用原窗口还是弹出窗口的原则

    一般而言,首页上链接可以使用target=”_blank”属性打开新窗口,而其他页面上的链接都应使用原窗口或弹出窗口。如果链接页面内容相对原页面来说不重要,是附属性质的,可以使用弹出窗口方式。

    一般情况下应该使用原窗口,把是否保留原窗口内容的权利留给用户。除非设计者相信原页面是如此重要,在用户发出点击指令后还有使用上的价值,以至于不能被随便更新或覆盖。一般来说,只有首页才会处于这样一个地位,用户在首页上打开一个链接后,一般还会在这个首页上去打开另一个链接。比如首页包含极多链接的门户网站,或者搜索引擎的搜索结果页面。google.com以前的搜索结果页面上的链接是使用原窗口的,后来他们意识到用户会反复使用这个页面,而改成打开新窗口了。一般的网站如果首页链接不多,就不必使用新窗口,这是用户友好的设计原则。

    上述情形的一个极端情况就是新页面内容比起原页面内容的重要性差很多,以至于都未必需要打开一个新页面。这时候使用弹出窗口比较合适。用javascript弹出窗口有好几种:一个是window.open()函数。这里有个技巧。应该使用window.open()先打开一个空白窗口,再使用location.replace()用目标页面替换。这样做可以避免在打开新页面的过程中导致原页面失去响应。window.open()将打开一个新的浏览器窗口进程,因此资源消耗比较大。另一个是由微软dynamichtml规范中扩充的方法createpopup()。createpopup()可以创建无边框的弹出窗口,消耗系统资源较小。还有一个就是用页面中隐藏的层<div>来模拟一个弹出页面。后两种可以使用javascript代码填充弹出窗口内容。如果需要下载网页作为其内容的话,需要微软dynamichtml规范中的<download>标签。

八、尽可能少的排列可选项,尽可能少的安排操作步骤

    根据用户操作习惯安排尽可能少的操作菜单选项,同时要保证尽可能少的操作步骤。 在不降低功能多样性的前提下减少菜单项和操作步骤是用户友好的设计。要做到这一点很不容易。要从用户出发考虑他们最频繁的操作是什么。正常情况下一个用户需要的操作总可以归类为5个以下的种类,如果出现更多的种类,那一定是没有针对用户兴趣去区分主次。一个用户同时有5个以上的强烈兴趣中心是难以想像的,走马观花似的随意点击浏览的用户,是不大可能在某个种类上进行深入的交互操作的。在这5个种类中,每个种类都可能有若干个可操作的二级种类。如果这些二级操作项是不可见的,那么意味着要做两次选择才能进入可操作页面。这就违背了“尽可能少的安排操作步骤”这一原则。如果使用javascript制作二级菜单,避免请求服务器,会好一些。如果二级菜单项总共不超过20个左右,不妨将二级菜单直接显示出来,比如放在左列一字向下排开,这样只需要一次选择到可操作项,更加明了方便。

九、操作逻辑无漏洞,保证数据是操作安全的

    多个页面间的操作和同个页面上的多个操作间的逻辑关系在设计上是安全和严谨的。保证不会出现不被允许的用户操作组合,至少不会因为用户的不适当的操作导致出错。

    这最典型的表现则是在页面上广泛采用的所谓联动下拉框设计。一个下拉框中允许的选项受另一个下拉框中的选择而变。另外一个例子是根据选择使表单元素有效或者失效。如果在多个页面间也要维持某种合法性逻辑,那么就需要服务器端脚本的参与。这样会使表单设计跟操作有关,应该说这不是一个好的设计。可以通过变更操作步骤顺序、组合方式来尽可能避免这种情况出现。

    操作逻辑的设计既要保证用户任意的输入不会导致错误,也要保证是用户输入的数据能购被安全处理。在session控制下的表单中输入大幅文字可能会导致超时出错,这时候往往还伴随重定向过程,导致用户的长篇输入荡然无存。用javascript提醒用户已超时,请保存输入后重新提交,是一个好办法。某些表单元素如<input type=”text”>接受esc键清除数据,并且无法撤销,这也是很危险的。在中文输入法中常常使用esc键清楚输入的码位,一旦不小心多按一下esc就会使得输入数据消失。因此有必要用javascript禁用<input>和<textarea>的esc键处理过程。(Edit From:Internet,By Aaron)

posted @ 2008-05-29 22:35 金家寶 阅读(567) | 评论 (0)编辑 收藏

JSP安全几个小问题

记得还是去年,刚到据说是高手云集的威威公司上班的时候,一个新到的同事给我讲他花了半天的时间写,并做了很长时间的实践,写了个关于攻击.jsp页面的程序。下面我把具体的实现过程和大家分享一下。测试平台是Tomcat,当然,版本有点低,他的目的只是想证实一下他的某些想法。首先,他在Tomcat的WEB目录下建立了一个Hello.jsp文件,内容是:

<%out.print(hello);%>

通过IE的正常请求地址为:http://localhost:8080/examples/jsp/hello.jsp,显示结果为:hello。然后开始具体的攻击测试。测试时,发出的请求地址为:http://localhost:8080/examples/jsp/////////hello.jsp ,浏览器上显示编译错误,错误的原因是500 java.lang.NullPointerException。这个应该是比较常见的错误了。现在,恢复正常的请求http://localhost:8080/examples/jsp/hello.jsp,问题就出现了,即出错,而且所报的错误和刚才造成它错误的请求是一样的:“500 java.lang.NullPointerException”。难道是缓存在浏览器里了吗?换台机器访问http://192.168.10.188/examples/jsp/hello.jsp。问题依然如故,哎!可怜的Hello.jsp呀!

  虽然这个问题有些弱智,不过,他的目的也达到了,即找出“.jsp”流程中存在的一些问题。所以,JSP程序同ASP一样,还是存在着很多安全上的问题的。因此,对于一心研究论坛或者其他安全信息的朋友来说,要想发现JSP的BUG,了解一些JSP的工作原理是十分重要的。

  需要指出的是,虽然是一门网络编程语言,JSP和PHP、ASP的工作机制还存在很大的区别,首次调用JSP文件时,JSP页面在执行时是编译式,而不是解释式的。首次调用JSP文件其实是执行一个编译为Servlet的过程。当浏览器向服务器请求这一个JSP文件的时候,服务器将检查自上次编译后JSP文件是否有改变,如果没有改变,就直接执行Servlet,而不用再重新编译,这样,工作效率得到了明显提高。这也是目前JSP论坛开始逐渐风靡的一个重要原因。

  小提示:Servlet是用Java编写的Server端程序,它与协议和平台无关;Servlet运行于Java-enabled WEB Server中;Java Servlet可以动态地扩展Server的能力,并采用请求-响应模式提供WEB服务;最早支持Servlet技术的是JavaSoft的Java WEB Server;Servlet的主要功能在于交互式地浏览和修改数据,生成动态WEB内容。

  说到这里,我们自然就会关心一些JSP的安全问题。一般来说,常见的JSP安全问题有源代码暴露(包括程序源代码以明文的方式返回给访问者,如添加特殊后缀引起jsp源代码暴露;插入特殊字符串引起Jsp源代码暴露;路径权限引起的文件Jsp源代码暴露;文件不存在引起的绝对路径暴露问题等)、远程程序执行类、数据库如SQL Server、Oracle 、DB2等的漏洞,操作系统漏洞等。不过,为了突出Jsp的安全问题,本文将结合目前的一些比较流行的Jsp论坛分类阐述和提出解决的建议。为了讲解方便,本文还采用一些公开了原代码的论坛实例代码,至于安装软件版本、操作系统等,可以查看安装提示。

  论坛用户管理缺陷

  为了加强实战效果,我们可以到http://down.chinaz.com/S/5819.asp这个地址下载一个典型的论坛代码,根据提示,数据源名称为yyForum,用户名为xyworker,密码:999。到baidu、Google等网站搜索一下,我们可以看到,安装这个代码的论坛不少。仔细分析后,可以发现,用户管理的页面是user_manager.jsp文件。首先,我们看看这个系统是如何加强它的代码安全性的。其中,在代码的开始部分有一个if限制条件,代码的第三行到第十行具体如下:

<%
if ((session.getValue(UserName)==null)||(session.getValue(UserClass)==null)||(!session.getValue(UserClass).equals(系统管理员)))

%>

  其中,Session.getValue表示检索出Session的值;sendRedirect()执行后,地址栏链接会改变,相当于客户端又重新发了一个get请求,要服务器传输另一个文件过来。

  下面,我们再来看看修改用户信息的文件modifyuser_manager.jsp。典型代码如下:

<%@page contentType=text/html; charset=gb2312 language=java import=java.sql.*,java.util.*  %>
<jsp:useBean id=yy scope=page class=yy.jdbc/>
<%!String User_Name,User_Password,sql, User_Sign;%>
<%
User_Name=request.getParameter(name);

//out.println(User_Name);
User_Password=request.getParameter(password);
User_Password=yy.ex_chinese(User_Password);
……
User_Sign=request.getParameter(sign);
User_Sign=yy.ex_chinese(User_Sign);

Connection con=yy.getConn();
Statement  stmt=con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
sql=update 用户表 set 用户密码='+User_Password+',用户性别='+User_Sex+',用户邮箱='+User_Email+',居住地址='+User_Address+',手机号码='+User_Mobile+',Oicq='+User_Oicq+',出生日期='+User_Birthay+',用户等级='+User_Class+',签名='+User_Sign+' where 用户名='+User_Name+';
//out.println(sql);
stmt.executeUpdate(sql);
out.println(<font size=2 color=blue>正在处理你的用户信息,请稍后...</font><meta http-equiv='refresh' content='2;url=user_manager.jsp'>);
%>
<jsp:include page=inc/online.jsp flush=true/>

  看看这个文件,我们就好像看到了一个简单的教学文件。现在,假设管理员提交如下地址,即http://www.51dz.net/bbs/modifyuser_manager.jsp?modifyid=51,需要查看、修改ID为51的用户的资料(管理员默认的用户ID为51)。问题就出来了。同样的,我们可以通过搜索引擎得到如下地址

很明显,这个用户管理文件缺乏认证,即使是普通的用户,甚至包括我们这些搭不上边的“游客”,也可以直接提交上述请求,从而将其资料一览无余,更让人动心的是,密码也是明文存储的。
  
  http://www.51dz.net/bbs/modifyuser_manager.jsp同样是大开山门,直到恶意用户把数据更新的操作执行完毕,重定向到user_manager.jsp的时候,管理员才会看见那个显示错误的页面,但这个时候为时已晚,更谈不上“亡羊补牢”了。类似的错误存在于很多JSP的站点上,面对这样的论坛,我们能够放心的说“安全”吗?解决之道有很多,不过,最基本的要求是为每个需要加身份认证的地方加上身份认证,如果借用别人的代码,一定要对涉及到用户管理、密码认证等重要文件修改一下,照搬虽然省事,但代码毫无安全性可言。

  再就是SQL注入的问题。比如,这个典型的问题:“昨天公司的数据库被人SQL注入,9万条记录都被update了,同事写了个JSP程序来把他改回来,可是这JSP没有一点信息返回,看不到进度,在运行些什么都不知道。”不过,这和JSP程序没有什么必然的联系,根据国情,国内的网站用ASP+Access或SQLServer的占70%以上,PHP+MySQL占20%,其它的不足10%。因此,ASP的SQL注入比较常见也不足为怪。不过,SQL注入漏洞可谓是“千里之堤,溃于蚁穴”,这种漏洞在网上极为普遍,即使是JSP程序也不能幸免。归根结底,通常是由于程序员对注入不了解,或者程序过滤不严格,或者某个参数忘记检查导致。看看这个教材式的JSP程序就可以窥见一般:

Statement stmt = conn.createStatement(); 
String checkUser = select * from login where username = ' + userName + ' and userpassword = ' + userPassword + '; 
ResultSet rs = stmt.executeQuery(checkUser); 
if(rs.next()) 
 response.sendRedirect(SuccessLogin.jsp); 
else 
 response.sendRedirect(FailureLogin.jsp);

  针对这种情况,如果数据库里存在一个名叫“Tom”的用户,那么在不知道密码的情况下至少有下面几种方法可以登录: 
用户名:Tom            密码:' or 'a'='a
用户名:Tom            密码:' or 1=1/*
用户名:Tom' or 1=1/*     密码:(任意)

posted @ 2008-05-23 18:20 金家寶 阅读(1231) | 评论 (0)编辑 收藏

Servlet使用

1.1重定向(如果对方不支持cookie,回写sessionID进行session跟踪)
 response.sendRedirect(response.encodeRedirectURL(request.getContextPath()+"/next"));
******************************************************************
1.2转发
 RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(url);
 dispatcher.forward(request,response);
******************************************************************
1.3字符
  request.setCharacterEncoding("utf-8");
  response.setContentType("text/html;charset=utf-8");
******************************************************************
String servletPath = request.getServletPath();
  servletPath = servletPath.substring(servletPath.lastIndexOf("/") + 1);
  String operation = servletPath.substring(0, servletPath.indexOf(".do"));
1.设置连接超时时间(分钟)
 <session-config>
  <session-timeout>50</session-timeout>
 </session-config>
******************************************************************
4.相对路径匹配
 1>绝对匹配 /xx/yy
 2>后缀匹配 *.xx
 3>后面匹配 /xx/*
******************************************************************
5.监听器
5.1ServletRequestListener
   getServletContext()
   getServletRequest()
 requestDestroyed(ServletRequestEvent)
 requestInitialized(ServletRequestEvent)
5.2HttpSessionListener
   getSession()
 sessionCreated(HttpSessionEvent)
 sessionDestroyed(HttpSessionEvent)
5.3ServletContextListener
   getServletContext()
 contextInitialized(ServletContextEvent)
 contextDestroyed(ServletContextEvent)
 
5.4ServletRequestAttributeListener
   getName()
   getValue()
 attributeAdded(ServletRequestAttributeEvent)
 attributeRemoved(ServletRequestAttributeEvent)
 attributeReplaced(ServletRequestAttributeEvent)
5.5HttpSessionAttributeListener
   getName()
   getValue()
   getSession()
 attributeAdded(HttpSessionBindingEvent)
 attributeRemoved(HttpSessionBindingEvent)
 attributeReplaced(HttpSessionBindingEvent)
5.6ServletContextAttributeListener
   getName()
   getValue()
 attributeAdded(ServletContextAttributeEvent)
 attributeRemoved(ServletContextAttributeEvent)
 attributeReplaced(ServletContextAttributeEvent)

posted @ 2008-04-19 20:31 金家寶 阅读(384) | 评论 (0)编辑 收藏

linux关机和重启命令

 
 
Linux中常用的关机和重新启动命令有shutdown、halt、reboot以及init,它们都可以达到关机和重新启动的目的,但是每个命令的内部工作过程是不同的,下面将逐一进行介绍。

1. shutdown

shutdown命令用于安全关闭Linux系统。有些用户会使用直接断掉电源的方式来关闭Linux,这是十分危险的。因为Linux与Windows不同,其后台运行着许多进程,所以强制关机可能会导致进程的数据丢失,使系统处于不稳定的状态,甚至会损坏硬件设备。

执 行shutdown命令时,系统会通知所有登录的用户系统将要关闭,并且login指令会被冻结,即新的用户不能再登录系统。使用shutdown命令可 以直接关闭系统,也可以延迟指定的时间再关闭系统,还可以重新启动。延迟指定的时间再关闭系统,可以让用户有时间储存当前正在处理的文件和关闭已经打开的 程序。

shutdown命令的部分参数如下:

[-t] 指定在多长时间之后关闭系统

[-r] 重启系统

[-k] 并不真正关机,只是给每个登录用户发送警告信号

[-h] 关闭系统(halt)

shutdown命令的工作实质是给init程序发送信号(signal),要求其切换系统的运行级别(Runlevel)。系统的运行级别包括:

0:关闭系统

1:单用户模式,如果没有为shutdown命令指定-h或-r参数而直接执行,则默认将切换到此运行级别

2:多用户模式(不支持NFS)

3:多用户模式(支持NFS),一般常用此种运行级别

5:多用户模式(GUI模式)

6:重新启动系统

2. halt

halt是最简单的关机命令,其实际上是调用shutdown -h命令。halt执行时,杀死应用进程,文件系统写操作完成后就会停止内核。

halt命令的部分参数如下:

[-f] 没有调用shutdown而强制关机或重启

[-i] 关机或重新启动之前,关掉所有的网络接口

[-p] 关机时调用poweroff,此选项为缺省选项

3.reboot

reboot的工作过程与halt类似,其作用是重新启动,而halt是关机。其参数也与halt类似。

4.init

init是所有进程的祖先,其进程号始终为1。init用于切换系统的运行级别,切换的工作是立即完成的。init 0命令用于立即将系统运行级别切换为0,即关机;init 6命令用于将系统运行级别切换为6,即重新启动。

posted @ 2008-04-19 16:33 金家寶 阅读(277) | 评论 (0)编辑 收藏

仅列出标题
共7页: 上一页 1 2 3 4 5 6 7 下一页