服务器端组件

[size=medium] 为了大家能够更好的学习Java EE各种技术，在这里写一篇文章帮大家理解服务器端组件这个概念。
开发人员可以使用Java、C++之类的语言编写具有灵活性、可扩展性和可重用性的软件。通常开发人员会把业务逻辑采用面向对象的封装特点进行封装，以面对业务的变化性。而进行封装时，为了提高软件的健壮性以及性能，传统的方式需要利用相应的API获得诸如事务、安全、多线程甚至持久化的功能。这就迫使开发人员学习大量的特定API，例如BEA的Tuxedo API。如此一来就导致开发人员不能专注于业务逻辑的实现。更糟糕的是被开发的软件，不管是定制项目还是产品被锁定在某一商业平台，降低了软件的可移植性。开发机构为了实现不同平台的产品目标，不得不维护不同产品的不同软件版本。这样就大大提高了机构的软件维护成本。于是开发机构渴望标准API的出现。Sun Microsystems为了满足这一需求，利用Java的跨平台特点制定了许多标准API，如JTA用于不同的事务平台。我们最熟悉的要数JDBC了，如果采用JDBC来实现持久化，数据库方面的可移植性将会很高，因为JDBC可用以相同的编码操作几乎所有的数据库产品
有了标准的API，开发机构基本可以解决软件的可移植性问题，开发人员也可以从学习不同的API噩梦中解脱出来，恐怕没有开发人员愿意为了某一软件项目辛辛苦苦学习的API，一段时间之后再也不使用而被遗忘废弃掉。但是这样并不能做到开发人员只关注业务逻辑实现。开发人员仍然需要自己编码控制事务、安全、多线程等复杂易出错的部分。这种方式虽然有很高的灵活性，但是软件的健壮性使得对开发人员的要求非常高。软件维护成本仍然没有降低。如果有一种机制能够使开发人员从标注事务API中解脱出来，问题也就解决了大半。同样为了满足这种需求，Sun Microsystems制定了Java EE标准。基于组件和容器的概念，要求容器透明支持诸多服务。组件如果需要服务，只需以声明的方式，通知容器提供相应服务即可。非常典型的是CMT（容器管理的事务）。这里提高的组件就是服务器端组件。那么组件和容器该如何互相认识，互相交互呢？
为了使容器能够准确的管理组件和对组件提供服务是有要求的（我们可以理解成是一种代价），即是组件必须实现某些接口。这里的接口起到的是一种标准的作用。既然是标准，就是双方的，就是说不仅仅用来约束组件的实现者，也约束了容器的提供者。我们拿大家肯定熟悉的Servlet组件举例子。先从Servlet组件实现者方说起。开发人员不能随意编写一个类就是Servlet，哪怕这个类中存在诸如init()、service()、destroy()方法。容器（这里以大家熟悉的Tomcat作例子）是没有办法管理随意编写的类。开发人员为了编写Servlet组件，必须实现javax.servlet.Servlet接口，并提供此接口中定义的所有生命周期方法以便容器能够对其进行生命周期管理，就是init()、service()、destroy()方法。在对容器的约束方面，Servlet组件标准要求容器提供者实现对Servlet组件的生命周期管理以及诸多基础性工作。例如，Servlet组件如果需要正确响应客户端的请求，那么容器就必须在请求到达容器时，为Servlet组件提供封装了客户端提交过来的数据的ServletRequest对象，这些数据包括了表单参数，客户端元数据（请求头信息）等。除了请求对象，容器还需提供ServletRespose响应对象向客户端做出响应数据的发送。细心的读者会发现，Servlet规范当中定义的ServletRequest，ServletResponse明明是接口，怎么能说成是对象呢？这就更体现了对容器的约束。容器必须实现这些接口以便能实例化相应的请求和相应对象。例如Resin的实现类是com.caucho.server.connection.CauchoRequest类。
随着Java EE的发展，为了满足开发更加简易，将会采用POJO+Annotaction的方式来替代接口是实现，虽然开发方式变了，但是容器和组件的概念没有变，她们之间的关系也基本不变。
[/size]