大型Java Web系统选型问题探讨
转自Infoq
http://www.infoq.com/cn/news/2007/09/java_web_architecture_turnning
一位ID是jackson1225的网友在JavaEye询问了一个大型Web系统的架构和部署选型问题，希望能提高现有的基于Java的Web应用的服务能力。由于架构模式和部署调优一直是Java社区的热门话题，这个问题引发了很多热心网友的讨论，其中一些意见对其它大型Web项目也有很好的指导意义。在讨论之初jackson1225这样描述了当前的应用的架构和部署方案：
目前系统架构如下:
web层采用struts+tomcat实现，整个系统采用20多台web服务器，其负载均衡采用硬件F5来实现；
中间层采用无状态会话Bean+DAO+helper类来实现，共3台weblogic服务器，部署有多个EJB，其负载均衡也采用F5来实现；
数据库层的操作是自己写的通用类实现的，两台ORACLE数据库服务器，分别存放用户信息和业务数据；一台SQL SERVER数据库，是第三方的业务数据信息；
web层调用EJB远程接口来访问中间件层。web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口；
该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作，即有三个数据库连接，在一个事务中完成。
这样的架构其实很多公司都在使用，因为Struts和Tomcat分别是最流行的Java Web MVC框架和Servlet容器，而F5公司的负载均衡是横向扩展常见的解决方案（例如配置session sticky方案）。由于这个系统中有跨数据源的事务，所以使用Weblogic Server EJB容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。
但是随着Rod Johnson重量级的著作《J2EE Development without EJB》和其中的Spring框架的流行，轻量级框架和轻量级容器的概念已经深入人心。所以对于jackson1225提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。网友们大都认为SLSB（无状态会话Bean）完全没有必要出现在这个场景中，认为SLSB通过远程接口访问本地资源会有很大的性能开销，这种观点也是Rod johnson在without EJB中批判EJB 2.x中的一大反模式。
由于JavaEE是一个以模式见长的解决方案，模式和架构在JavaEE中占有很重要的地位，所以很多业内专家也都警惕“反模式（Anti-patterns）”的出现。对于上面所述的方案是否是反模式，jackson1225马上站出来申辩：
我们项目就是把EJB作为一个Facade，只是提供给WEB层调用的远程接口，
相关文档：
1. W3C把标签内的文本部分也定义成一个Node
2.
Element对象代表的是XML文档中的标签元素
，继承于Node，亦是Node的最主要的子对象
3. Attr实际上是包含在Element中的，它并不能被看作是Element的子对象，因而在DOM中Attr并不是DOM树的一部分，所以Node中的 getparentNode()，getpreviousSiblin ......
采用串口操作进行短信收发,是比较常见的一种方式.比如,很多群发软件,用的就是这种方法.
1.配置comm.jar.
Comm.jar是Sub实现底层串口操作的API,调用了本地的DLL文件,因为Java本身不具备直接访问硬件设置的能力,都是通过调用本地方法来实
现的.可以Java的官方网站下载.下载之后把其中Comm.jar包导入到工程的Classpath中,把 ......
public class Regex {
/**
* 检查email输入是否正确
* 正确的书写格式为 username@domain
* @param value
* @return
*/
public boolean checkEmail(String value, int length) {
return value.matches("\\w+([-+.]\\w+)*@\\w+([-.]\\w+)* ......
一些java类中为什么需要重载 serialVersionUID 属性。
在Java中，软件的兼容性是一个大问题，尤其在使用到对象串行性的时候，那么在某一个对象已经被串行化了，可是这个对象又被修改后重新部署了，那么在这种情况下， 用老软件来读取新文件格式虽然不是什么难事，但是有可能丢失一些信息。
serialVersionUID 来解决这些� ......
