看了几天java web开发的东东，简单梳理一下。
-
容器
这是java
web开发过程中非常强调的一个概念。顾名思义，在它的内部存放着某些东西，各种java对象，包括所谓的bean等等。java的容器也可以称其为一个
应用服务，或一个框架，用户通过配置指定代码或者说对象、构件存放的路径，以及对象之间的关系、对象和容器直接的关系。这通常有一套标准，例如
javaEE本身的servlet/jsp的规范，或容器本身特定的某些标准，你的配置和代码必须符合这种标准，才能被容器调用使用。标准有很多形
式，xml的配置、java接口的实现、对象的继承、java的标注等等，他们决定了对象如何被容器调用、对象之间的关系、以及对象在容器中的运行状态。
目前作为java web开发最常用的servlet/jsp容器是tomcat，企业应用服务器是jboss。spring框架虽然没有服务器的概念，但是从其包含、组织、调用java组件的特征来看，也可以说是容器了。
回忆.net，虽然没有特别强调容器的概念，但是从程序的流程和组织架构来说，iis就是.net web程序运行的容器了。
-
web生命周期
在任何技术平台的web开发中，web的生命周期都是一个核心概念。由于web应用都是基于http协议和b/s模式，所以不论采用何种技术，其生命周期都是类似的。
-
请求与响应：
客户端请求-服务器端运算服务-响应，request->service->response，这个标准的http访问流程存在于任何
一种web开发平台中。流程对应的对象引用和方法也都相似，HttpServletRequest封装http的请求，可以通过该对象获取请求相关的各种
参数，HttpServletResponse封装对客户端的响应，通过该对象可以设置http流的各种响应数
据，HttpServlet.service(HttpServletRequest req, HttpServletResponse
res)则实现服务的计算内容，获取请求，再根据程序逻辑设置响应。
-
scope：
web程序有其自有的运行环境和上下文，在java web开发中一般称其为scope（page|request|session|application）。
-
page
是最小运行环境，一个jsp page即一个servlet类实例，但是page scope并非指这个servlet实例的变量，它的有效范围是该servlet对象和某次http请求的交集，只能在当前请求当前页面有效。
-
request
是某次请求范围内有效，即使该请求在服务器端通过forward跨越多个servlet。
-
session
（HttpSession） 是指某个用户会话的全过程，这是为了弥补无状态的http会话缺陷，通过cookie识别客户端并在服务器端添加状态的机制。
-
application
（ServletContext） 是指在整个应用（context）范围内有效的程序环境。
在这些scope中，request|session|application都可以通过setAttribute/getAttribute在有效范围内设置获取变量。这是一种常见的代码数据共享方式，不过存在线程安全问题，需要注意考虑并发情况。
-
对象各自的生命周期：
所有的对象都有其各自的生命周期，初始化-运行时-销毁。通常初始化和销毁是由容器控制，运行时会运行程序代码实现逻辑。同时，servlet还提
供监听（listener）和过滤（filter）的机制，使程序能控制对象生命周期更广的范围。当然这些都必须实现指定的接口，并通过xml或标注等容
器认可的方式配置编码，使容器能访问调用。
-
jsp标签
标签是web页面的表现中非常常见的技术，最原始的标签就是html模板内的变量替换，估计做web的人人都写过。java web的标签有jsp的标准标签、el、自定义标签，JSTL应该也属于自定义标签，只是后来作为标准发布了。
-
繁杂的标签：
jsp标准的标签实现，我个的感觉有些繁杂。java平台一向以自由著称，但是作为一种技术的标准，内容和实现应该尽量简洁，提供一种标准的实现方式即可，是否采用其它第三方库完全可以由用户自己选择。
jsp的标准标签提供了jsp页面实现的基本功能，它包括基本的页面定义、servlet类程序定义、表达式、包含、异常等等，其他程序逻辑则通过
代码片段来实现。继此之后，大家觉得在一个xml文档里面，java代码片段到处飞，看上去不太美观，因此jstl出来了。通过自定义标签，他试图把所有
标准标签实现不了必须依靠代码片段实现的东西转换为标签，从而在jsp模板里消灭java代码片段。因此他实现了环境变量的设置和引用，异常，程序流转逻
辑等等，甚至通过sql库实现数据库操作。我考虑了很久，除非那种没有任何性能要求，简单到只有1、2个的页面的应用，否则是不太可能采用这种方式来实现
数据库操作的。而xml形式的程序逻辑标签（if|else|choose|when…）也过于繁琐，远不如代码片段简洁。
I18N库倒是很简单实用，但是它的本地化文件数据格式太简单，只适合某些很简单的单词单句的本地化，如果有比较复杂的内容，估计这么简单的数据格式是无法满足要求的。不知道有没有接口可以对底层进行重写，否则实用价值有限。
-
el库：
el是非常简洁漂亮的，基本上可以把他当作是某种脚本变量的引用，据说javaEE5以后官方也大力提倡使用。但是我觉得也挺逗，这不就和当初试图
消灭jsp模板里面非xml风格元素的目标相冲突吗？el可完全不是xml风格，虽然他比java代码对文档的破坏性小，但他也仅仅是表达式，无法实现其
他逻辑功能。
-
自定义标签：
通过tag api，或者通过简单的标签文件，用户可以创建自定义标签，这和asp.net中的自定义控件和用户控件如出一辙。在我以往的经验中，除了基于学习的目的，从来没有自己开发过控件，用户控件一般也只用于进行简单的包含，方便做缓存或部分逻辑控制。
我感觉自定义标签和asp.net自定义控件的情况类似，多用于某些企业系统的开发，或者是某些商业库的实现。而在一般网站系统中去开发和自定义一
套标签库是非常困难的，代价成本非常高。实现本身比较复杂，增加了开发人员学习成本，库的维护和发展得不到保障，增大了程序复杂度增大了运算资源的消耗。
上面这些问题对于需求变化快、应用访问量非常高的网站应用来说是致命的，而对于一般的企业系统来讲影响比较小。
-
代码和界面分离的传说：
我相信所有做web的人——无论前端后端——都听过这么一个论述，如果web页面模板能够和后端程序完全分离，那么前端和后端能完全相互无干扰的工
作，将大大提高工作效率。从理论上来说，如果能做到这一点确实能大大提高工作效率，然而能做到吗？所谓界面本身就是程序的一部分，他和程序逻辑是息息相关
的。除非某个界面和程序完全没有关系，否则他必然存在某种形式的程序逻辑控制代码，不管这种代码是代码片段、xml还是简单表达式，又或者未来发明个别的
什么东西。这是应用的需求和软件开发工作的实质决定的。
又有某种说法，认为将程序控制实现为html格式类似的标签，可以帮助前端人员更容易识别和修改html模板，这个说法更不可信。我长期和设计师及
前端人员合作，事实上除极个别极端情况，大多数人都很容易理解简单的程序语法，如变量或对象声明、简单的程序逻辑控制等。甚至很多设计师为了页面控制方
便，自己写一些简单控制逻辑。这个学习成本很低，而且基本上所有的流行程序语言语法都类似。而仅jsp的标签库就有多少种？其表达形式何其花样百出？很多
时候还存在需要设计师理解标签库设置界面外观等等情况，对设计师来说复杂度远远高于去了解一门程序语言的简单语法。
对标签这种形式，我的态度是实现方式越简单，表现形式越简洁越好，不必完全拒绝程序代码，不要过于苛求xml文档化，过犹不及。对于jsp标签的现
状，我觉得可以参考asp.net，通过继承或者实现分部类，把jsp的大部分代码逻辑放到后端java程序中去，分离代码和模板。或者强化el，有限制
的实现某种jsp中的脚本语言，甚至嫁接一个别的脚本语言进来。嗯，都不错。
-
bean就是组件
在我未接触java之前，就总是听说javaBean和ejb，我不知道为什么要取名为bean，那应该只是源于java的某种趣味的称呼吧。
bean就是对象，没有什么不同，只是他需要符合某些标准，以方便jsp或其他调用。看了这些标准，bean和.net中的组件是一个概念，没有什么区
别。在jsp中访问bean很简单，就是一些现成的标签，设置一下bean的scope。我仍然觉得这种标签访问方式感觉很恶劣……
关于ejb，我看的这本书
简单讲了
一个例子，如何创建并访问。ejb我感觉和bean的差别在2个方面，一是ejb是分布式组件，除业务逻辑类本身外，还需要按标准创建相关的接口、配置、
部署，最后提供远程调用的能力。二是ejb的服务器应该会提供强大的管理功能，组件之间的关系、结构组合、性能优化、事务等等，这一部分我看的书没有提。
我看的书还是ejb2的例子，ejb3据说已经大大简化了，嗯，待学习了。
-
有趣的java
搞java也一个多星期了，感觉java确实很繁杂，不论语法还是平台框架，很多东西不如.net平台简洁有效。但是java更加自由，整个开源世
界存在很多框架、技术可供你自由选择——当然这种选择是需要成本的，有时候这也是一种痛苦。另外，对于软件构架，java更趋向于从技术和程序的角度，
而.net趋向于从用户的角度，对于技术人员来讲，java的这种视角更加可贵。
