网络编程的基本模型就是客户机到服务器模型.简单的说就是两个进程之间相互通讯,然后其中一个必须提供一个固定的位置,而另一个则只需要知道这个固定的位置.并去建立两者之间的联系..然后完成数据的通讯就可以了.这里提供固定位置的通常称为服务器,而建立联系的通常叫做客户端.基于这个简单的模型,就可以进入网络编程啦.

Java对这个模型的支持有很多种Api.而这里我只想介绍有关Socket的编程接口.对于Java而言已经简化了Socket的编程接口.首先我们来讨论有关提供固定位置的服务方是如何建立的.Java提供了ServerSocket来对其进行支持.事实上当你创建该类的一个实力对象并提供一个端口资源你就建立了一个固定位置可以让其他计算机来访问你.ServerSocket server=new ServerSocket(6789);这里稍微要注意的是端口的分配必须是唯一的.因为端口是为了唯一标识每台计算机唯一服务的.另外端口号是从0~65535之间的,前1024个端口已经被Tcp/Ip 作为保留端口,因此你所分配的端口只能是1024个之后的.好了.我们有了固定位置.现在所需要的就是一根连接线了.该连接线由客户方首先提出要求.因此Java同样提供了一个Socket对象来对其进行支持.只要客户方创建一个Socket的实例对象进行支持就可以了.Socket client

=new Socket(InetAddress.getLocalHost(),5678);客户机必须知道有关服务器的IP地址.对于着一点Java也提供了一个相关的类InetAddress 该对象的实例必须通过它的静态方法来提供.它的静态方法主要提供了得到本机IP 和通过名字或IP直接得到InetAddress的方法.

好了.上面的方法基本可以建立一条连线让两台计算机相互交流了.可是数据是如何传输的呢?事实上I/O操作总是和网络编程息息相关的.因为底层的网络是继续数据的.除非远程调用,处理问题的核心在执行上.否则数据的交互还是依赖于IO操作的.所以你也必须导入java.io这个包.java的IO操作也不复杂.它提供了针对于字节流和Unicode的读者和写者,然后也提供了一个缓冲用于数据的读写.

BufferedReader in=new BufferedReader(new InputStreamReader(server.getInputStream()));

PrintWriter out=new PrintWriter(server.getOutputStream());

上面两句就是建立缓冲并把原始的字节流转变为Unicode可以操作.而原始的字节流来源于Socket的两个方法.getInputStream()和getOutputStream()方.分别用来得到输入和输出.那么现在有了基本的模型和基本的操作工具.我们可以做一个简单的Socket例程了.

服务方:

import java.io.*;

import java.net.*;

public class MyServer {

public static void main(String[] args) throws IOException{

ServerSocket server=new ServerSocket(5678);

Socket client=server.accept();

BufferedReader in=new BufferedReader(new InputStreamReader(client.getInputStream()));

PrintWriter out=new PrintWriter(client.getOutputStream());

while(true){

String str=in.readLine();

System.out.println(str);

out.println(“has receive….”);

out.flush();

if(str.equals(“end”))

break;

}

client.close();

}

}

这个程序的主要目的在于服务器不断接收客户机所写入的信息只到.客户机发送”End”字符串就退出程序.并且服务器也会做出”Receive”为回应.告知客户机已接收到消息.

客户机代码:

import java.net.*;

import java.io.*;

public class Client{

static Socket server;

public static void main(String[] args)throws Exception{

server=new Socket(InetAddress.getLocalHost(),5678);

BufferedReader in=new BufferedReader(new InputStreamReader(server.getInputStream()));

PrintWriter out=new PrintWriter(server.getOutputStream());

BufferedReader wt=new BufferedReader(new InputStreamReader(System.in));

while(true){

String str=wt.readLine();

out.println(str);

out.flush();

if(str.equals(“end”)){

break;

}

System.out.println(in.readLine());

}

server.close();

}

　　对于基本类型，在方法体内对方法参数进行重新赋值，并不会改变原有变量的值。

　　对于引用类型，在方法体内对方法参数进行重新赋予引用，并不会改变原有变量所持有的引用。

　　方法体内对参数进行运算，不影响原有变量的值。

　　方法体内对参数所指向对象的属性进行运算，将改变原有变量所指向对象的属性值。

　　在JAVA中变量有以下两种：

　　基本类型变量，包括char、byte、short、int、long、float、double、boolean。

　　引用类型变量，包括类、接口、数组（基本类型数组和对象数组）。

　　最后我们得出如下的结论：

　　基本类型和基本类型变量被当作参数传递给方法时，是值传递。在方法实体中，无法给原变量重新赋值，也无法改变它的值。

　　对象和引用型变量被当作参数传递给方法时，在方法实体中，无法给原变量重新赋值，但是可以改变它所指向对象的属性。

　　 public class Person
　　{
　　 private String name = null;
　　private int age = 0;
　　public Person(String name, int age) {
　　 this.name = name;
　　this.age = age;
　　}
　　 public void changeName(String newName) {
　　 this.name = newName;
　　 }
　　 public void changeAge(int newAge) {
　　 this.age = newAge;
　　 }
　　public String toString() {
　　 return “Person – Name: ” + name + “, Age: ” + age;
　　 }
　　 }
　　 public class PassByValue
　　 {
　　public static void main(String[] args) {

　　 // one example
　　 String value1 = “value1: aaa”;
　　 String value2 = “value2: bbb”;
　　swapValue(value1, value2);
　　System.out.println(value1);
　　 System.out.println(value2);

　　// another example
　　 Person person = new Person(“张三”, 20);
　　 System.out.println(person.toString());
　　 changePerson(person);
　　 System.out.println(person.toString());
　　 public static void swapValue(String tmpValue1, String tmpValue2) {
　　 String tempStr = tmpValue1;
　　 tmpValue1 = tmpValue2;
　　 tmpValue2 = tempStr;
　　 }
　　public static void changePerson(Person tmpPerson) {
　　 tmpPerson.changeName(“李四”);
　　 tmpPerson.changeAge(30);
　　 }
　　 }
　　考虑一下上面这段代码的输出结果是什么？

　　我相信绝大多数人都能快速的给出正确答案：
　　value1: aaa
　　value2: bbb
　　Person – Name: 张三, Age: 20
　　Person – Name: 李四, Age: 30
　　答案为什么是这样的呢？那么 Java 到底是按值传递还是按引用传递参数的呢？
　　例 子1中的 swapValue() 方法不起作用，看起来是按值传递参数的，例子2中的 changeName() 和 changeAge() 方法起作用，从表面上看起来好像又是按引用传递参数的。呵呵，别急，先让我们来弄清楚一个重要的概念，就是 Java 操纵对象都是通过引用来实现的，所有的对象变量都是所指向的对象的引用，那也就是说所有对象变量的值并不是它所指向的对象本身，而是该对象的引用，这句话听起来可能有点让人犯晕，举个例子来说，String str = new String(“aaa”); 这条语句的意思是 new 了一个值为 “aaa” 的字符串对象，然后用一个名字叫 str 的对象变量来指向它，保存它的引用，假设在内存中 new 出来的这个字符串对象的实际地址为 0xA242, 那么 str 的值实际上是 0xA242。
　　现在来看看例子1，假设
　　String value1 = “value1: aaa” 的地址为 0xA242，
　　String value2 = “value2: bbb” 的地址为 0xA24B,
　　然 我们来看看 swapValue(value1, value2); 语句 Java 是怎么执行的。当程序执行到这句语句的时候，JVM 在栈中创建两个临时变量 tmpValue1,tmpValue2，用来接收传进来的 value1 和 value2 的值，而 value1 和 value2 的值分别为 0xA242 和 0xA24B，所以那两个临时变量 tmpValue1和tmpValue2 的值也被赋值为 0xA242 和 0xA24B，此时接下来的三条语句分别是
　　tempStr = 0xA242,
　　tmpValue1 = 0xA24B,
　　tmpValue2 = 0xA242;
　　此时 tmpValue1 的值是指向 “value2: bbb” 这个对象的，
　　tmpValue2 的值是指向 “value1: aaa” 这个对象，你可以在 swapValue() 方法内部打印 tmpValue1 和 tmpValue2 的值验证一下。
　　不 过这里的 tmpValue1和tmpValue2 是在栈中的临时变量，而并不是 main 方法中 value1和value2，main 方法中 value1和value2 的值并没有改变，那这里所谓的值传递是指什么呢？因为 value1 的值是 0xA242（”value1: aaa” 这个对象的引用），而并不是 “value1: aaa” 这个对象，传递参数时传递的是 “value1: aaa” 这个对象的引用也就是 value1 的值，所以是值传递。
　　例子2也是一样的，假设
　　Person person = new Person(“张三”, 20) 的地址为 0xA242，
　　那 么 person 的值是 0xA242, 那么通过调用 changePerson(person); 将 0xA242 传递给 tmpPerson, 也就是 tmpPerson 此时的值为 0xA242 也就是 new Person(“张三”, 20) 这个对象的引用，也就是说 tmpPerson 指向 new Person(“张三”, 20) 对象，对 tmpPerson 引用对象的修改实际上就是对 person 引用对象的修改，这看起来很想引用传递的概念，但实际上是值传递，为什么呢？因为在参数传递过程中传递的是 person 的值，也就是 0xA242。

　　除了spring.jar文件，Spring还包括有其它13个独立的jar包，各自包含着对应的Spring组件，用户可以根据自己的需要来选择组合自己的jar包，而不必引入整个spring.jar的所有类文件。

　　(1) spring-core.jar

　　这个jar文件包含Spring框架基本的核心工具类，Spring其它组件要都要使用到这个包里的类，是其它组件的基本核心，当然你也可以在自己的应用系统中使用这些工具类。

　　(2) spring-beans.jar

　　这个jar文件是所有应用都要用到的，它包含访问配置文件、创建和管理bean以及进行Inversion of Control / Dependency Injection（IoC/DI）操作相关的所有类。如果应用只需基本的IoC/DI支持，引入spring-core.jar及spring- beans.jar文件就可以了。

　　(3) spring-aop.jar

　　这个jar文件包含在应用中使用Spring的AOP特性时所需的类。使用基于AOP的Spring特性，如声明型事务管理（Declarative Transaction Management），也要在应用里包含这个jar包。

　　(4) spring-context.jar

　　这个jar文件为Spring核心提供了大量扩展。可以找到使用Spring ApplicationContext特性时所需的全部类，JDNI所需的全部类，UI方面的用来与模板（Templating）引擎如 Velocity、FreeMarker、JasperReports集成的类，以及校验Validation方面的相关类。

　　(5) spring-dao.jar

　　这个jar文件包含Spring DAO、Spring Transaction进行数据访问的所有类。为了使用声明型事务支持，还需在自己的应用里包含spring-aop.jar。

　　(6) spring-hibernate.jar

　　这个jar文件包含Spring对Hibernate 2及Hibernate 3进行封装的所有类。

　　(7) spring-jdbc.jar

　　这个jar文件包含对Spring对JDBC数据访问进行封装的所有类。

　　(8) spring-orm.jar

　　这个jar文件包含Spring对DAO特性集进行了扩展，使其支持 iBATIS、JDO、OJB、TopLink，因为Hibernate已经独立成包了，现在不包含在这个包里了。这个jar文件里大部分的类都要依赖 spring-dao.jar里的类，用这个包时你需要同时包含spring-dao.jar包。 
　　(9) spring-remoting.jar

　　这个jar文件包含支持EJB、JMS、远程调用Remoting（RMI、Hessian、Burlap、Http Invoker、JAX-RPC）方面的类。

　　(10) spring-support.jar

　　(11) spring-web.jar

　　这个jar文件包含Web应用开发时，用到Spring框架时所需的核心类，包括自动载入WebApplicationContext特性的类、Struts与JSF集成类、文件上传的支持类、Filter类和大量工具辅助类。

　　(12) spring-webmvc.jar

　　这个jar文件包含Spring MVC框架相关的所有类。包含国际化、标签、Theme、视图展现的FreeMarker、JasperReports、Tiles、Velocity、 XSLT相关类。当然，如果你的应用使用了独立的MVC框架，则无需这个JAR文件里的任何类。

　　(13) spring-mock.jar

　　这个jar文件包含Spring一整套mock类来辅助应用的测试。Spring测试套件使用了其中大量mock类，这样测试就更加简单。模拟HttpServletRequest和HttpServletResponse类在Web应用单元测试是很方便的。

　　如何选择这些发布包，决定选用哪些发布包其实相当简单。如果你正在构建Web应用并将全程使用Spring，那么最好就使用单个全部的 spring.jar文件；如果你的应用仅仅用到简单的Inversion of Control / Dependency Injection（IoC/DI）容器，那么只需spring-core.jar与spring-beans.jar即可；如果你对发布的大小要求很高，那么就得精挑细选了，只取包含自己所需特性的jar文件了。采用独立的发布包你可以避免包含自己的应用不需要的全部类。当然你可以采用其它的一些工具来设法令整个应用包变小，节省空间的重点在于准确地找出自己所需的Spring依赖类，然后合并所需的类与包就可以了。Eclispe有个插件叫 ClassPath Helper可以帮你找找所依赖的类。

Spring包依赖说明:

　　1) spring-core.jar需commons-collections.jar，spring-core.jar是以下其它各个的基本。

　　2) spring-beans.jar需spring-core.jar，cglib-nodep-2.1_3.jar

　　3) spring-aop.jar需spring-core.jar，spring-beans.jar，cglib-nodep-2.1_3.jar，aopalliance.jar

　　4) spring-context.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，commons-collections.jar，aopalliance.jar

　　5) spring-dao.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，spring-context.jar

　　6) spring-jdbc.jar需spring-core.jar，spring-beans.jar，spring-dao.jar

　　7) spring-web.jar需spring-core.jar，spring-beans.jar，spring-context.jar

　　8) spring-webmvc.jar需spring-core.jar/spring-beans.jar/spring-context.jar/spring-web.jar

　　9) spring -hibernate.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，spring- dao.jar，spring-jdbc.jar，spring-orm.jar，spring-web.jar，spring-webmvc.jar

　　10) spring-orm.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，spring- dao.jar，spring-jdbc.jar，spring-web.jar，spring-webmvc.jar

　　11) spring -remoting.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，spring- dao.jar，spring-context.jar，spring-web.jar，spring-webmvc.jar

　　12) spring-support.jar需spring-core.jar，spring-beans.jar，spring-aop.jar，spring-dao.jar，spring-context.jar，spring-jdbc.jar

　　13) spring-mock.jar需spring-core.jar，spring-beans.jar，spring-dao.jar，spring-context.jar，spring-jdbc.jar

　　Kodo EJB是一个支持对象/关系映射的框架，根据EJB3规范的要求，Kodo EJB除了支持在普通Java应用中提供轻量级的持久层框架之外，也支持在JAVA EE容器中使用满足重量级企业应用的需求，充分利用JAVA EE容器中提供的优越特性如容器管理事务、远程(Remote)访问。

　　基于Kodo EJB开发的应用支持使用EJB或者JCA标准接入到JAVA EE环境中：

1. JCA

   Kodo EJB支持JCA1.0标准，因此基于Kodo EJB开发的应用可以和其他JCA资源一样轻松的发布到JAVA EE应用服务器上。

2. JNDI

   另外一种方式是将kodo.persistence.EntityManagerFactoryImpl的一个实例绑定到JNDI，然后通过查找JNDI的方式使用Kodo EJB应用。虽然这种方式需要开发者根据不同的JAVA EE容器编写代码才能完成，但是这种方式能够保持最大限度的JAVA EE容器可移植性，而且为在那些不支持JCA标准的JAVA EE容器中使用Kodo EJB创造可能。

　　本文中我们将以通过一个简单的例子，简单的讲解和演示如何在Weblogic9上通过JNDI方式来访问Kodo EJB应用。

    有些人对它感到陌生，有些人并不看好它，有些人则对它抱以期望的目光，有些狂热者甚至预言：它是未来的Java Web主导者。2006年，Sun把JSF从幕后推到了前台，那么，JSF的命运如何呢？真的会像人们所说的那样，成为各种Web开源框架的终结者吗？

    Web开源框架风烟四起，让我们看到了Java Web世界竞争惨烈。无论框架时代是否已经来临，但开发者们已经感到麻木和疲惫，人们在框架的海洋里穿行着，不免有些劳累，不知哪种框架才是应用开发中的唯一选择……经历过Java开发的人员都会客观地对.NET的组件、良好的集成工具、快速的开发效率报以羡幕的目光。于是，有很多开发人员都提出：为什么Java不能开发出和.net具备同样的功能产品，来改变Java Web世界的混乱格局呢？

   那么，作为JCP组织中国成员和国内领先的Java中间件厂商，金蝶中间件对JSF又是如何思考的呢？就此，IT168记者独家专访了在Java界有着广泛声誉的金蝶中间件首席科学家袁红岗先生，请他畅谈JSF未来的发展。

   袁红岗简介

   袁红岗很早就开始了Java技术的研究，并预见到了Java技术对互联网时代的深远影响，率领当时的金蝶中央研究院开始了J2EE架构的核心——J2EE应用服务器的研究和开发，成功开发出国内首家拥有完全自主知识产权、并第一个通过国际J2EE认证的金蝶Apusic应用服务器，并成为国际JCP组织中国代表。

    袁红岗具有敏锐的技术触觉，有多年的软件开发经验，对应用软件的技术发展趋势有着准确的判断力，是国内第一个J2EE应用服务器的缔造者，也是国内业界深入理解J2EE技术体系的程序员和标志性人物。2004年，被公推为“影响中国软件开发的20人”之一。

    记者：最近我们IT168也做了很多关于JSF的报道，有人称JSF是一种过时的技术，也有些人称JSF是“早晨八九点钟的太阳”，我想请问一下袁总，你怎么看待JSF这种技术和它的未来前景？ 

    袁红岗：JSF这项技术不仅没有过时，相反，Sun最近刚刚把JSF纳入新一代Java EE5.0规范。只不过JSF一直没有真正用起来，业界也相对缺少基于JSF的成功案例，因此，有些开发者有这些看法也是正常的。

    如果从框架的角度说，JSF是一个优秀的开发框架，主要缺少的是一个成熟且丰富的组件库，并且需要得到良好的开发工具的支持。如果这两点能够有效解决，JSF的前景的确是阳光灿烂。

    记者：刚才你谈到了开发工具，JSF是一个对开发工具依赖很强的技术，不知道金蝶Apusic是否也推出自已的开发工具？ 
    
    袁红岗：的确，只有开发工具对JSF进行广泛且深入的支持，才能说明JSF的成功。在JSF规范中有这样一句话“JSF is designed to be tooled”。换言之，JSF规范从设计初就强调对开发工具的依赖。

     目前，业界JSF开发工具正在迅速丰富起来，包括Orcale JDeveloper，Sun Java Studio Creator等等。金蝶中间件也同样提供了基于Eclipse的集成开发环境：Apusic Stutio，通过该工具，能够给JSF的开发带来良好的支持，包括：语法加亮、代码辅助、断点调式、可视化的设计等等。
    记者：那么作为一个后来者，Apusic Stutio与其它JSF开发工具又有哪些不同呢？ 
    
    袁红岗：一个好的开发工具应该从组件和布局这些方面入手，从易用、简化上下功夫，比如大家公认微软的开发工具就很成功。Apusic的开发工具也是看到微软的成功，准备借鉴微软的开发工具模式，这样JSF才有成功可能。

    实际上，JSF在概念上和.NET有很多相似之处，Apusic Studio就是专门为JSF设计的。我们已经推出了具备许多创新特性的JSF引擎，正在努力打造业界最优秀的JSF开方工具，这就是我们的Apusic Studio。

    记者：现在开源框架可以说是百家争鸣，JSF与众多开源框架相比，又有哪些优势呢?

    袁红岗：如今的开源框架都是建立在J2EE本身的基础上的，建立在HTTP、HTML底层协议的基础上。而JSF实际上跟底层协议无关，它是一种更高层次的页面表达方式，它实际上生成不一定是HTML，也可以生成WML，或者其它描述型语言。

    举个最简单的例子，假如有一天，HTML这种标记型语言被一种新描述语言代替的话，其它众多开源框架可能都会在一夜之间被抛弃，而JSF技术却不会。这就是因为它是一种更高层面的框架支持技术，它支持HTML、却不依赖HTML。

    记者：现在业界说Ajax和JSF融合是一个完美的框架组合，不知你怎么看待这种说法？

    袁红岗：目前JSF+Ajax这种思路，很多公司都有，包括我们金蝶在内。诚然，Ajax是一种客户端技术，JSF是服务器端技术；很多人抱有一种观点，认为这两者之间风马牛不相及。事实上，抱有这种观点的人，是对JSF技术不够了解，这两者之间可以非常完美的结合。

    目前，很多JSF在实现对Ajax的支持上，是通过组件级别的形式予以支持，但Apusic JSF引擎则创新性的提出了容器级别对Ajax进行支持。任何常规的JSF应用，在Apusic应用服务器上，只需要增加一个配置参数，就能够将这些应用变成Ajax Enabled的应用，这是非常激动人心的特性。我们刚才谈到，JSF最大的问题是相对缺乏成功案例，为了推动JSF在业界的推广与发展，我们已经把这些核心技术提交给JCP组织。

    甚至于，我们还主动开源出来，出资成立了operamasks.org开源组织，把我们的核心技术以开源形式提供给业界，反馈给社会。在核心技术的把握上，Apusic越来越成熟，也越来越自信。当JSF遭遇Ajax，将会产生强大的化学反应，我对JSF的未来充满信心。 

    揭开JSF神秘面纱 —— JSF掀起你的盖头来

    JSF为什么会受到如此大的亲赖，IBM，orcale，包括国内领先的中间件厂商金蝶也投以关注目光。那么它又具有哪些与众不同的优势吸引众商家投怀送抱呢？下面我们就来揭开JSF的神秘面纱。

    JSF英文全称 JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的新标准 Java 框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化开发，也是Sun精心打造的一项技术。

    JSF优势之一：UI组件（UI-component）

    UI组件（UI-component）一直是桌面程序的专利，web程序中，虽然HTML定义了基本的UI标签，但要使这些UI标签像UI组件那样工作，还需要很多代码片断来处理数据及其表现形式，而且有效地组织这些代码片断使其协调一致也是一件繁琐的工作。JSF的UI组件是真正意义上的UI组件，能极大地简化程序员的工作，例如，在页面上放置一个文本输入框，这个输入框立即具备了数据填充、界面更新、事件侦听、动作触发、有效性检查和类型转换的功能。更为重要的是，程序员只需根据业务逻辑编写核心业务代码，JSF会保证代码在合适的时候被执行，完全不用考虑代码与代码之间该如何来配合。

    JSF优势之二：事件驱动模式

    事件是面向对象方法的重要组成部分，对象之间通过事件进行沟通和交流，使得一个或多个对象能够对另一个对象的行为作出响应，共同合作去完成一项业务逻辑。通常，编写Web程序时，程序员要为对象之间的沟通设计机制，编写代码。虽然沟通的内容属于业务逻辑，但沟通的机制显然与业务没有太大关系，程序员因此为业务逻辑之外的功能浪费了时间。

    JSF改变了这种状况。JSF的事件和侦听模式与大家熟悉的Javabean的事件模式类似，有Java基础的程序员并不需要学习任何新的东西。JSF的UI组件可以产生事件，例如，当页面上一个文本输入框的内容被修改时，会发出一个“值改变事件”。另一个对象如果对“值改变事件”感兴趣，只需注册为该对象的侦听者，并编写处理例程，即可命令JSF在事件发生时自动调用处理例程。JSF做了所有该做的事，留给程序员的只有业务逻辑代码的编写。

    JSF优势之三：用户界面到业务逻辑的直接映射

    举个例子，表单提交是Web编程最常见的任务，也是最复杂的任务之一。当用户在网页上点击“确定”按钮时，浏览器将生成一个HTTP请求，发往服务器端的某个Servlet，执行该Servlet的service方法。在service方法中，HTTP请求需要经历解码、类型转换、有效性验证、状态保存、数据更新等环节，处理这些环节的所有细节，对程序员来说是沉重的负担。

    在JSF下，这些工作的很大一部分都由框架承担了，在程序员看来，这个过程是透明的，用户界面端的HTTP请求可以直接映射到后端的一个事件处理例程，JSF起到了承前启后的作用。

    JSF优势之四：程序员和网页设计人员的分工

    在JSP中，程序员和网页设计人员的工作有时候是互相交织、无法区分的。这是因为JSP页面中掺入了网页设计人员所不熟悉的一些JSP标签，甚至是晦涩的Java代码。要求网页设计人员理解这些标签和代码是不现实的，不符合分工合作的原则。在JSF中，框架为网页设计人员提供了一套标准的UI组件，在工具的支持下，可以通过拖放简单地添加到网页上，然后设置某些显示属性来满足视觉要求。

    网页设计人员不需要知道UI组件背后的复杂代码，那是程序员的事，而程序员也不需要再处理任何与视觉相关的细节，程序员所做的只是给UI组件绑定类的属性或方法。虽然程序员和网页设计人员需要修改同一份文件，但他们各司其职，各得其所，互不干扰。程序员和网页设计人员工作的明确划分，是JSF在易用性方面迈出的一大步。
   
    JSF优势之五：请求处理生命周期的多阶段划分 

     虽然都是建立在Servlet基础之上，但JSF的生命周期要比JSP复杂得多。JSP的生命周期非常简单，页面被执行时，HTML标记立即被生成了，生命周期随即结束。而一个完整的JSF请求-处理生命周期被精心规划为6个阶段，典型的JSF请求需要经历所有阶段，某些特殊的请求也可以跳过一些阶段。阶段的细分，显然引入了更多的处理，但JSF框架会管理这一切，所以，程序员在获得更多控制能力的同时，工作量并没有增加。

    JSF优势之六：伴随工具而生存 

     JSF带来了Web编程的巨大变革，变革的强烈程度超出了很多工具厂商的预料，以至于现在可供JSF使用的工具非常缺乏。缺乏工具支持的JSF只会令人敬而远之，因此，JSF在设计之初就为工具厂商预留了用武之地。在为数不多的JSF工具中，sun的Java Studio Creator是一个优秀的开发环境；Borland的Jbuilder在JSF1.1时曾经是非常好用的开发工具。

    可惜现在对JSF1.2的支持没有跟上；Eclipse下JSF的插件很多，但真正支持所见即所得的JSF插件都是收费的，例如Bea的Workshop for JSF、Exadel的JSF Studio等等；此外，Oracle和IBM也有JSF的开发工具。随着工具的不断涌现，用JSF开发Web程序将会越来越方便和快速。

    JSF优势之七：全面的用户自定义支持

    前面提到，JSF将极大地简化Web程序的开发，作为一个相对复杂的框架，JSF是如何做到这点的呢？原来JSF为程序员提供了很多默认的组件和类，通常情况下，JSF的这些默认组件和类足以满足Web开发的需要了。但是，考虑到在某些应用场合，框架的默认行为也许不符合业务的要求，JSF特别允许程序员编写自己的组件和类，来满足客户的特殊需求。例如，程序员可以编写自己的UI组件，甚至可以创建自己的EL解释器，来支持非标准的EL表达语言。

    JSF优势之八：Web开发的官方标准之一

    JSF的1.0版本发布于2004年2月份，当时是作为一项独立的Web技术推出的。经过1.1版到现在最新的1.2版，短短的两年多时间，JSF终于在2006年年中成为Java EE 5的组成部分，上升为Web开发的官方标准之一。Java EE 5最重要的使命就是简化Java的开发，而JSF无疑为这一使命立下了汗马功劳。在Web框架层出不穷甚至有些泛滥成灾的今天，Sun以JSF来树立标准，对Java的发展是有益的。Sun在Java领域的领袖地位不容动摇，对于Java程序员来说，始终追随业界领袖的步伐，也许是避免技术落伍的最好方法。

    JSF能否统一Web开发模式 

    在J2EE下一代规范Java EE5.0中，JSF技术被放到了一个非常重要的地位，J2EE社区试图通过JSF来统一Web应用的开模式与方法， 但是JSF能否担起Sun所赋予的重任？实现Web开发的统一？
很多开发人士都对JSF不抱乐观的态度，用过JSF的人都称JSF是Web开发世界的创举， JSF可谓墙里开花，墙外不红，是什么原因的造成如此大的反差呢？

    1.获取方式
    书是我们获取知识第一来源，一种技术的火爆程度，我们不用在网上去做任何调查，只要去一下图书城结果就一目了然，关于JSF的书籍简直是凤毛麟角，难觅终影，这样在人们在获取JSF相关资料，JSF会大打折扣，比较经典《JSF in Action》国内还没哪家出版社有翻译动向，证明图书厂商还没有对JSF投入太多关注度。

    2．中文讨论区成熟度不够
    除了图书方面，讨论区的热度也很重要，打开JSF官方讨论区，对JSF大唱赞歌人大有人在，为什么国内这种讨论却少之又少呢？一些国内比较知名的讨论区中没有看到JSF的相关技术讨论，这样从影响度上从知识的渴求度上，都限制了JSF前进脚步。

    3．Sun商业策略
    Sun的商业运作模式一直存在问题，我们在之前曾经预言过如果JSF不叫JSF，而叫JSP3.0那么现在结果会如何呢？Sun可以不费一兵一卒从而实现JSP到JSF的合理过渡，同时也会有大批的JSP狂热者迅速的转向JSF，也可能有些人会认为两者是不同的两种技术，但是谁又能说Asp和Asp.net是两种相同的技术吗？同样的策略微软用的很成功，难道Sun没有想到吗？

    4．开发工具的支持程度
    这次采访袁总的时候，也提到了JSF依赖开发工具的支持，Sun，IBM，Orcale都提出了对JSF开发工具的支持，但是这些开发工具在简化开发方面是否做足了功课，宠大、全面、无所不能一直是众厂商炫耀技术的舞台，这次Apusic Studio提出了简化，易用两方面特性，这点从程序员角度出发的开发工具，我们还是值得期待的。

    5．扩大影响力
    每一种技术都要有忠实狂热者，同时要让更多人的来应用和学习，Struts成功就是很好例证，一位著名IT人士曾经说过，“即使公司发生惨绝人寰的人事大变动，产品经理也不必过于惊惶失措，茫茫人海中，有大批的Struts们可供选择，只需好好考虑好新员工的业务培训如何开展即可，而对于技术延续性,则不必太过于担心,这就是Struts 带来的战略性优势。

    也是Struts在今天技术落后的情况还能一直保持领先地位，这点还是值得反思的，JSF如何在影响上扩大学习者的基层人群，打消企业的后顾之忧，影响高层对JSF企业框架的应用选择，不知JSF是否做好了准备。

    综上所述只是个人观点，如果JSF能在影响力和扩大人层基数上突破瓶颈，那么统一Web开发的格局将指日可待。     记者：最近我们IT168也做了很多关于JSF的报道，有人称JSF是一种过时的技术，也有些人称JSF是“早晨八九点钟的太阳”，我想请问一下袁总，你怎么看待JSF这种技术和它的未来前景？ 

    袁红岗：JSF这项技术不仅没有过时，相反，Sun最近刚刚把JSF纳入新一代Java EE5.0规范。只不过JSF一直没有真正用起来，业界也相对缺少基于JSF的成功案例，因此，有些开发者有这些看法也是正常的。

    如果从框架的角度说，JSF是一个优秀的开发框架，主要缺少的是一个成熟且丰富的组件库，并且需要得到良好的开发工具的支持。如果这两点能够有效解决，JSF的前景的确是阳光灿烂。

    记者：刚才你谈到了开发工具，JSF是一个对开发工具依赖很强的技术，不知道金蝶Apusic是否也推出自已的开发工具？ 
    
    袁红岗：的确，只有开发工具对JSF进行广泛且深入的支持，才能说明JSF的成功。在JSF规范中有这样一句话“JSF is designed to be tooled”。换言之，JSF规范从设计初就强调对开发工具的依赖。

     目前，业界JSF开发工具正在迅速丰富起来，包括Orcale JDeveloper，Sun Java Studio Creator等等。金蝶中间件也同样提供了基于Eclipse的集成开发环境：Apusic Stutio，通过该工具，能够给JSF的开发带来良好的支持，包括：语法加亮、代码辅助、断点调式、可视化的设计等等。
    记者：那么作为一个后来者，Apusic Stutio与其它JSF开发工具又有哪些不同呢？ 
    
    袁红岗：一个好的开发工具应该从组件和布局这些方面入手，从易用、简化上下功夫，比如大家公认微软的开发工具就很成功。Apusic的开发工具也是看到微软的成功，准备借鉴微软的开发工具模式，这样JSF才有成功可能。

    实际上，JSF在概念上和.NET有很多相似之处，Apusic Studio就是专门为JSF设计的。我们已经推出了具备许多创新特性的JSF引擎，正在努力打造业界最优秀的JSF开方工具，这就是我们的Apusic Studio。

    记者：现在开源框架可以说是百家争鸣，JSF与众多开源框架相比，又有哪些优势呢?

    袁红岗：如今的开源框架都是建立在J2EE本身的基础上的，建立在HTTP、HTML底层协议的基础上。而JSF实际上跟底层协议无关，它是一种更高层次的页面表达方式，它实际上生成不一定是HTML，也可以生成WML，或者其它描述型语言。

    举个最简单的例子，假如有一天，HTML这种标记型语言被一种新描述语言代替的话，其它众多开源框架可能都会在一夜之间被抛弃，而JSF技术却不会。这就是因为它是一种更高层面的框架支持技术，它支持HTML、却不依赖HTML。

    记者：现在业界说Ajax和JSF融合是一个完美的框架组合，不知你怎么看待这种说法？

    袁红岗：目前JSF+Ajax这种思路，很多公司都有，包括我们金蝶在内。诚然，Ajax是一种客户端技术，JSF是服务器端技术；很多人抱有一种观点，认为这两者之间风马牛不相及。事实上，抱有这种观点的人，是对JSF技术不够了解，这两者之间可以非常完美的结合。

    目前，很多JSF在实现对Ajax的支持上，是通过组件级别的形式予以支持，但Apusic JSF引擎则创新性的提出了容器级别对Ajax进行支持。任何常规的JSF应用，在Apusic应用服务器上，只需要增加一个配置参数，就能够将这些应用变成Ajax Enabled的应用，这是非常激动人心的特性。我们刚才谈到，JSF最大的问题是相对缺乏成功案例，为了推动JSF在业界的推广与发展，我们已经把这些核心技术提交给JCP组织。

    甚至于，我们还主动开源出来，出资成立了operamasks.org开源组织，把我们的核心技术以开源形式提供给业界，反馈给社会。在核心技术的把握上，Apusic越来越成熟，也越来越自信。当JSF遭遇Ajax，将会产生强大的化学反应，我对JSF的未来充满信心。 

    揭开JSF神秘面纱 —— JSF掀起你的盖头来

    JSF为什么会受到如此大的亲赖，IBM，orcale，包括国内领先的中间件厂商金蝶也投以关注目光。那么它又具有哪些与众不同的优势吸引众商家投怀送抱呢？下面我们就来揭开JSF的神秘面纱。

    JSF英文全称 JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的新标准 Java 框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化开发，也是Sun精心打造的一项技术。

    JSF优势之一：UI组件（UI-component）

    UI组件（UI-component）一直是桌面程序的专利，web程序中，虽然HTML定义了基本的UI标签，但要使这些UI标签像UI组件那样工作，还需要很多代码片断来处理数据及其表现形式，而且有效地组织这些代码片断使其协调一致也是一件繁琐的工作。JSF的UI组件是真正意义上的UI组件，能极大地简化程序员的工作，例如，在页面上放置一个文本输入框，这个输入框立即具备了数据填充、界面更新、事件侦听、动作触发、有效性检查和类型转换的功能。更为重要的是，程序员只需根据业务逻辑编写核心业务代码，JSF会保证代码在合适的时候被执行，完全不用考虑代码与代码之间该如何来配合。

    JSF优势之二：事件驱动模式

    事件是面向对象方法的重要组成部分，对象之间通过事件进行沟通和交流，使得一个或多个对象能够对另一个对象的行为作出响应，共同合作去完成一项业务逻辑。通常，编写Web程序时，程序员要为对象之间的沟通设计机制，编写代码。虽然沟通的内容属于业务逻辑，但沟通的机制显然与业务没有太大关系，程序员因此为业务逻辑之外的功能浪费了时间。

    JSF改变了这种状况。JSF的事件和侦听模式与大家熟悉的Javabean的事件模式类似，有Java基础的程序员并不需要学习任何新的东西。JSF的UI组件可以产生事件，例如，当页面上一个文本输入框的内容被修改时，会发出一个“值改变事件”。另一个对象如果对“值改变事件”感兴趣，只需注册为该对象的侦听者，并编写处理例程，即可命令JSF在事件发生时自动调用处理例程。JSF做了所有该做的事，留给程序员的只有业务逻辑代码的编写。

    JSF优势之三：用户界面到业务逻辑的直接映射

    举个例子，表单提交是Web编程最常见的任务，也是最复杂的任务之一。当用户在网页上点击“确定”按钮时，浏览器将生成一个HTTP请求，发往服务器端的某个Servlet，执行该Servlet的service方法。在service方法中，HTTP请求需要经历解码、类型转换、有效性验证、状态保存、数据更新等环节，处理这些环节的所有细节，对程序员来说是沉重的负担。

    在JSF下，这些工作的很大一部分都由框架承担了，在程序员看来，这个过程是透明的，用户界面端的HTTP请求可以直接映射到后端的一个事件处理例程，JSF起到了承前启后的作用。

    JSF优势之四：程序员和网页设计人员的分工

    在JSP中，程序员和网页设计人员的工作有时候是互相交织、无法区分的。这是因为JSP页面中掺入了网页设计人员所不熟悉的一些JSP标签，甚至是晦涩的Java代码。要求网页设计人员理解这些标签和代码是不现实的，不符合分工合作的原则。在JSF中，框架为网页设计人员提供了一套标准的UI组件，在工具的支持下，可以通过拖放简单地添加到网页上，然后设置某些显示属性来满足视觉要求。

    网页设计人员不需要知道UI组件背后的复杂代码，那是程序员的事，而程序员也不需要再处理任何与视觉相关的细节，程序员所做的只是给UI组件绑定类的属性或方法。虽然程序员和网页设计人员需要修改同一份文件，但他们各司其职，各得其所，互不干扰。程序员和网页设计人员工作的明确划分，是JSF在易用性方面迈出的一大步。
   
    JSF优势之五：请求处理生命周期的多阶段划分 

     虽然都是建立在Servlet基础之上，但JSF的生命周期要比JSP复杂得多。JSP的生命周期非常简单，页面被执行时，HTML标记立即被生成了，生命周期随即结束。而一个完整的JSF请求-处理生命周期被精心规划为6个阶段，典型的JSF请求需要经历所有阶段，某些特殊的请求也可以跳过一些阶段。阶段的细分，显然引入了更多的处理，但JSF框架会管理这一切，所以，程序员在获得更多控制能力的同时，工作量并没有增加。

    JSF优势之六：伴随工具而生存 

     JSF带来了Web编程的巨大变革，变革的强烈程度超出了很多工具厂商的预料，以至于现在可供JSF使用的工具非常缺乏。缺乏工具支持的JSF只会令人敬而远之，因此，JSF在设计之初就为工具厂商预留了用武之地。在为数不多的JSF工具中，sun的Java Studio Creator是一个优秀的开发环境；Borland的Jbuilder在JSF1.1时曾经是非常好用的开发工具。

    可惜现在对JSF1.2的支持没有跟上；Eclipse下JSF的插件很多，但真正支持所见即所得的JSF插件都是收费的，例如Bea的Workshop for JSF、Exadel的JSF Studio等等；此外，Oracle和IBM也有JSF的开发工具。随着工具的不断涌现，用JSF开发Web程序将会越来越方便和快速。

    JSF优势之七：全面的用户自定义支持

    前面提到，JSF将极大地简化Web程序的开发，作为一个相对复杂的框架，JSF是如何做到这点的呢？原来JSF为程序员提供了很多默认的组件和类，通常情况下，JSF的这些默认组件和类足以满足Web开发的需要了。但是，考虑到在某些应用场合，框架的默认行为也许不符合业务的要求，JSF特别允许程序员编写自己的组件和类，来满足客户的特殊需求。例如，程序员可以编写自己的UI组件，甚至可以创建自己的EL解释器，来支持非标准的EL表达语言。

    JSF优势之八：Web开发的官方标准之一

    JSF的1.0版本发布于2004年2月份，当时是作为一项独立的Web技术推出的。经过1.1版到现在最新的1.2版，短短的两年多时间，JSF终于在2006年年中成为Java EE 5的组成部分，上升为Web开发的官方标准之一。Java EE 5最重要的使命就是简化Java的开发，而JSF无疑为这一使命立下了汗马功劳。在Web框架层出不穷甚至有些泛滥成灾的今天，Sun以JSF来树立标准，对Java的发展是有益的。Sun在Java领域的领袖地位不容动摇，对于Java程序员来说，始终追随业界领袖的步伐，也许是避免技术落伍的最好方法。

    JSF能否统一Web开发模式 

    在J2EE下一代规范Java EE5.0中，JSF技术被放到了一个非常重要的地位，J2EE社区试图通过JSF来统一Web应用的开模式与方法， 但是JSF能否担起Sun所赋予的重任？实现Web开发的统一？
很多开发人士都对JSF不抱乐观的态度，用过JSF的人都称JSF是Web开发世界的创举， JSF可谓墙里开花，墙外不红，是什么原因的造成如此大的反差呢？

    1.获取方式
    书是我们获取知识第一来源，一种技术的火爆程度，我们不用在网上去做任何调查，只要去一下图书城结果就一目了然，关于JSF的书籍简直是凤毛麟角，难觅终影，这样在人们在获取JSF相关资料，JSF会大打折扣，比较经典《JSF in Action》国内还没哪家出版社有翻译动向，证明图书厂商还没有对JSF投入太多关注度。

    2．中文讨论区成熟度不够
    除了图书方面，讨论区的热度也很重要，打开JSF官方讨论区，对JSF大唱赞歌人大有人在，为什么国内这种讨论却少之又少呢？一些国内比较知名的讨论区中没有看到JSF的相关技术讨论，这样从影响度上从知识的渴求度上，都限制了JSF前进脚步。

    3．Sun商业策略
    Sun的商业运作模式一直存在问题，我们在之前曾经预言过如果JSF不叫JSF，而叫JSP3.0那么现在结果会如何呢？Sun可以不费一兵一卒从而实现JSP到JSF的合理过渡，同时也会有大批的JSP狂热者迅速的转向JSF，也可能有些人会认为两者是不同的两种技术，但是谁又能说Asp和Asp.net是两种相同的技术吗？同样的策略微软用的很成功，难道Sun没有想到吗？

    4．开发工具的支持程度
    这次采访袁总的时候，也提到了JSF依赖开发工具的支持，Sun，IBM，Orcale都提出了对JSF开发工具的支持，但是这些开发工具在简化开发方面是否做足了功课，宠大、全面、无所不能一直是众厂商炫耀技术的舞台，这次Apusic Studio提出了简化，易用两方面特性，这点从程序员角度出发的开发工具，我们还是值得期待的。

    5．扩大影响力
    每一种技术都要有忠实狂热者，同时要让更多人的来应用和学习，Struts成功就是很好例证，一位著名IT人士曾经说过，“即使公司发生惨绝人寰的人事大变动，产品经理也不必过于惊惶失措，茫茫人海中，有大批的Struts们可供选择，只需好好考虑好新员工的业务培训如何开展即可，而对于技术延续性,则不必太过于担心,这就是Struts 带来的战略性优势。

    也是Struts在今天技术落后的情况还能一直保持领先地位，这点还是值得反思的，JSF如何在影响上扩大学习者的基层人群，打消企业的后顾之忧，影响高层对JSF企业框架的应用选择，不知JSF是否做好了准备。

    综上所述只是个人观点，如果JSF能在影响力和扩大人层基数上突破瓶颈，那么统一Web开发的格局将指日可待。