三、 前端页面的主要编码

1. 树的实现

在WEB上实现树结构，同样我们是通过Ajax来实现的。树上可以显示自定义的图标，可以插入、删除、结点。并且结点可任意移动。这里我们不重点讲树的实现技术，我们已经封装好了，你只要按要求去改动就是了。

1) 键接树型文件

在＜head＞与＜/head＞之间键接我们的与树有关的文件, 代码如下：

 组织管理的实现

组织可以增加、删除、编辑。同时当选择树结点时应该把组织显示出来供编辑，查看。为了实现这些功能，你只要按要求去改动就是了。

1) 全局变量的定义

许多地方我们要用到一些公共变量，我们在＜script＞与＜/script＞之间定义全局变量, 代码如下：

2) 初始化

当页面打开时我们要控件好那部分该显示，那部分要隐藏。且对全局变量的赋值等,组织类型装载。在页面的文档打开时装载自定义方法init（）, init方法实现初始化。

init方法实现如下：

3) 编写树拖动及选择结点的方法

4) 建立组织

组织建立主要是通过调用XMLHTTP对象来实现。我们主要学会如何调用XMLHTTP。组织建立应该在后台实现，把组织信息插入数据库中。这里我们通过JSP来实现。我们的Org.jsp 文件中有个createOrg方法，该方法传递一个父ID。

5) 删除组织

组织删除同样是调用Org.jsp 文件中的deleteOrg方法来实现，该方法传递所删除的结点ID。

function deleteOrg(){ 　var OrgId = OrgTree.getSelectedItemId(); 　var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); 　xmlhttp.open("POST","Org.jsp?mode=deleteOrg&OrgId=" + OrgId, false); 　xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); 　xmlhttp.send(); }

6) 编辑组织

组织修改是调用Org.jsp 文件中的modifyOrg方法来实现，该方法传递所修改的结点ID。同时修改的数据通过自定义的XML格式的字符串传送,这时通过send字符串来实现。修改前数据一律要验证其合法性，并提示错误信息。

function modifyOrg(){ 　if(OrgTree.getSelectedItemId() == ""){ return "N"; 　} 　if(txtCode.value == ""){ alert("请输入编码！"); return "N"; 　} 　if(txtName.value == ""){ alert("请输入名称！"); return"N"; 　} 　var OrgId = OrgTree.getSelectedItemId(); 　var OrgKind; 　//alert(txtType.options[txtType.selectedIndex].value) 　var strModify = "＜?xml version='1.0' encoding='gb2312'?＞" + 　"＜data＞" + 　"＜OrgCode＞＜![CDATA[" + txtCode.value + "]]＞＜/OrgCode＞" + 　"＜OrgName＞＜![CDATA[" + txtName.value + "]]＞＜/OrgName＞" + 　"＜OrgKind＞＜![CDATA[" + txtType.options[txtType.selectedIndex].value+ "]]＞＜/OrgKind＞" + 　"＜/data＞"; 　var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); 　xmlhttp.open("POST","Org.jsp?mode=modifyOrg&OrgId=" + OrgId, false); 　xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); 　xmlhttp.send(strModify); 　OrgTree.setItemText(OrgTree.getSelectedItemId(),txtName.value); }

3. 人员管理的实现

人员可以增加、删除、编辑。同时当选择树结点时应该把人员显示出来供编辑、查看......

1) 增加人员

人员增加实现的原理是在personDom中加入结点peorsone，该结点相当于表的一行，设置属性。同时在peorsone中不继地加入其它结点，代表数据库的字段，且必须与XLT文件的标号同名。这些结点相当该行的列。最后在表中插入一行，行上插入一列，并显示之。

function addPerson(){ 　var seqNo = nextSeq; 　nextSeq++; 　var peorsonNode = personDom.createNode("1", "peorsone",""); 　peorsonNode.setAttribute("isNew", "Y"); 　peorsonNode.setAttribute("isDelete", "N"); 　peorsonNode.setAttribute("seqNo", seqNo); 　personDom.documentElement.appendChild(peorsonNode); 　var PersonId= personDom.createNode("1", "personId", ""); 　peorsonNode.appendChild(PersonId); 　var personCode= personDom.createNode("1", "personCode", ""); 　peorsonNode.appendChild(personCode); 　var PersonName= personDom.createNode("1", "personName", ""); 　peorsonNode.appendChild(PersonName); 　var Sex= personDom.createNode("1", "sex", ""); 　peorsonNode.appendChild(Sex); 　var tr = tbList.insertRow(tbList.rows.length); 　tr.setAttribute("seqNo", seqNo); 　var td = tr.insertCell(0); 　td.innerHTML = peorsonNode.transformNode(stylesheet); }

2) 删除人员

人员删除同样是调用Org.jsp 文件中的deletePerson方法来实现，该方法传递所删除的人员ID。如何确定人员ID是通过读取隐藏的ID，并扫描整个表，看那些被选中。这里我们要注意是提供多项选择的。

function deletePerson(){ 　for(var i=0; i＜tbList.rows.length; i++){ var row=tbList.rows[i].cells[0].children[0].rows[0]; if(row.cells[0].children[0].checked) { 　var personId=row.cells[1].children[0].value; 　if(personId＞0) 　{ var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); xmlhttp.open("POST","Org.jsp?mode=deletePerson&personId=" + personId, false); xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); xmlhttp.send(); 　} 　tbList.deleteRow(i); 　i--; } 　} }

3) 编辑人员

人员修改我们要判定哪些行被修改了。刚增加但没保存的行应该是新增而不是修改的。

function save(){ 　if( modifyOrg()=="N") 　{ return; 　} 　for(var i=0; i＜tbList.rows.length; i++) 　{ var row=tbList.rows[i].cells[0].children[0].rows[0]; var personId=row.cells[1].children[0].value; var seqNo = tbList.rows[i].getAttribute("seqNo"); var staffNode = personDom.selectSingleNode("//peorsone[@seqNo='" + seqNo + "']"); var personCode=row.cells[2].children[0].value; var personName=row.cells[3].children[0].value; var sex=row.cells[4].children[0].value; //alert(staffN;ode ); if(staffNode.getAttribute("isNew") == "Y") { 　createPerson(CurrNodeId,personCode,personName,sex); } else { 　var strXML = "＜?xml version='1.0' encoding='gb2312'?＞" + "＜data＞" + "＜personCode＞＜![CDATA[" + personCode+ "]]＞＜/personCode＞" + "＜personName＞＜![CDATA[" + personName + "]]＞＜/personName＞" + "＜sex＞＜![CDATA[" + sex+ "]]＞＜/sex＞" + "＜personId＞＜![CDATA[" + personId+ "]]＞＜/personId＞" + "＜/data＞"; 　//alert(strXML ); 　var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); 　xmlhttp.open("POST","Org.jsp?mode=modifyPerson", false); 　xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); 　xmlhttp.send(strXML ); } 　} }

四、 XML与XSL文件设计

XML是种可扩展的标记语言，它具有开放的、可扩展的、可自描述的语言结构，它已经成为网上数据和文档传输的标准。XSLT的目的是将信息内容与 Web 显示分离，HTML 通过按抽象概念（如段落、重点和编号列表）定义显示来实现设备独立性。XSLT用来具体显示控件，设置控件风格。

Ajax主要使用XML和XSLT进行数据交换与处理。

1. 树信息的XML文件(见root.xml文件)

XML是标记语言，元素必须成对出现。树结构中以tree为根结点，以item为结点体，属性text指出结点所显示的文本，id指出唯一的所标识号。

五、 数据接口的实现（见Org.jpg文件）

Org.JSP文件用来在服务器上运行Java的类与前台web页之间架起一座桥。取到中间件的接口作用。

这里分析部分代码：

六、 后台数据的实现

1. 数据结构的定义

这里，我们主要有三个表。一个是组织结构表，一个是人员表person，一个组织人员关联表orgPerson。组织结构表有OrgCode（组织代码）、OrgName（组织名称）、orgId（组织Id）, parentOrgId（父Id）。人员表有personCode（人员代码）、personName（人员名称）, sex（性别）、personId（人员Id）。orgPerson表有orgId, personId。

2. 数据库的连接

WEB应用程序常用MySQL作后台数据库，这是因为MySQL简单、高效。这里我们也用MySQL作为数据库。Java中用jdbc连接数据库。下面是连接数据库的CODE：

. 业务逻辑层的实现

后台开发我们用Java类来实现。这里我们开发了一个orgNew包，类名为orgManager。此类封装了与数据库操作有关的方法。通过main可调试程序的正确性。

这里给出了新增加一个组织的全部代码和通过XML取得树结构信息的代码，树结构通过递归实现。

其它代码见orgManager.java文件。

七、 总结

本文件通过一个实例全面介绍了Ajax开发的各个细节。通过与J2ee的结合来实现三层分布式开发的层次划分，后台与前端的调用。数据的读取、访问及展现。

通过这个实例，我们可见，Ajax使WEB中的界面与应用分离。数据与呈现分离的分离，有利于分工合作、减少非技术人员对页面的修改造成的WEB应用程序错误、提高效率、也更加适用于现在的发布系统。也可以把以前的一些服务器负担的工作转嫁到客户端，利于客户端闲置的处理能力来处理。

Ajax是传统WEB应用程序的一个转变。以前是服务器每次生成HTML页面并返回给客户端（浏览器）。Ajax理念的出现，揭开了无刷新更新页面时代的序幕，并有代替传统web开发中采用form(表单)递交方式更新web页面的趋势，可以算是一个里程碑。

总之，Ajax适用于交互较多，频繁读数据，数据分类良好的WEB应用。

从Web或者企业级应用的角度看，能以这种方式访问数据真是一种福音，因为它体现了高度的可移动性，使我们与元数据的实际资源本身隔离。这些资源可能来自一个关系数据库系统、某种活动媒体服务器或者Web服务器上的一个静态XML文档，等等。
如果想把这些数据加载到Java应用中，我们可以从当前众多的Java语言XML解析器中选用一个，通过它将XML数据装入一个DOM文档，最后遍历文档，将所有这些数据转换到我们应用系统的对象模型中。

下面是个简单的基于DOM的解析程序，可对上述的媒体DTD进行解析。解析器用的是Apache Xerces：

第14讲与第14讲相关的所有内容讲座的幻灯片
MS PowerPoint
application/vnd.ms-powerpoint
http://javatraining.org/jaf/E123/lecture-14/slides.ppt
讲座的视频片断
RealPlayer streaming videovideo/vnd.rn-realvideo
http://javatraining.org/jaf/E123/lecture-14/lecture.rv
http://javatraining.org/jaf/E123/lecture-14/index.jsp

package jaf.xml;

import java.util.*;
import java.io.IOException;
import org.w3c.dom.*;
import org.xml.sax.*;
// XML文档解析程序，使用上述媒体
DTD.public class MediaParserimplements ErrorHandler
{
/** 使用Apache Xerces解析器 */
org.apache.xerces.parsers.DOMParser mParser
  = new org.apache.xerces.parsers.DOMParser();
/** 构造函数 */
public MediaParser() {
// 告诉解析器验证并解析文档
try {
mParser.setFeature
 ( 
 "http://xml.org/sax/features/validation", true
);
 } catch (SAXException e)
 {System.out.println
  ("Error setting validation on parser:");
e.printStackTrace();
}//
 设置解析器的错误处理句柄mParser.setErrorHandler(this);
}
/** 解析指定的URL，返回找到的XML文档*/
public Document parse(String url)
  throws SAXException, IOException {mParser.parse(url);
Document mediaDoc = mParser.getDocument();
return mediaDoc;
}
/** 解析指定URL的XML文档，将内容转换成 MediaAsset 对象*/
public Collection loadAssets(String url)
  throws SAXException, IOException {Document doc = parse(url);
Collection assets = new LinkedList();
NodeList assetNodes = doc.getElementsByTagName("media-asset");
for (int i = 0;
 i < assetNodes.getLength();
 i++){Node assetNode = assetNodes.item(i);
MediaAsset asset = new MediaAsset(assetNode);
assets.add(asset);
}return assets;
}
/*** 错误处理代码（为简洁起见省略了）*/
}
MediaParser类的构造函数初始化了一个Xerces DOM解析器。
parse()方法告诉解析器到哪个URL去找XML源，然后得到结果文档并返回。
loadAssets()方法调用parse()方法从某个XML源加载文档，
然后为文档中找到的每个“media-asset”节点创建一个MediaAsset对象。
以下是一个使用MediaAsset类的例子：
package jaf.xml;
import java.util.*;
public class MediaAsset {// 资源元数据private String mName = "";
private String mDesc = "";
private Collection mChildren = new LinkedList();
private Vector mTypes = new Vector();
private String mUrn = "";
protected MediaAsset(org.w3c.dom.Node assetNode) 
{// 为简洁起见省略后面代码...}}

因为篇幅的关系省略了MediaAsset类的详细代码，但应用模式依然是清晰的。MediaAsset类遍历文档的节点，
当它碰到不同的子节点时，它用子节点的内容填充自己的成员数据。
如果它发现了一个嵌套的子资源节点，它只需要创建一个新的MediaAsset对象，
然后将子资源节点的数据填充到新对象的成员数据中。
实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构，
如Java API for XML Parsing (JAXP)。
除了使用DOM模型外，事件驱动的SAX模型也可用于解析XML。
类似的程序也可用来产生XML数据——前提是允许产生新的数据对象（在本例中是MediaAsset），它可将其相应的XML实体插入到DOM中，
然后将DOM输出到一个流中（诸如一个文件，一个Socket，或者一个HTTP连接...）。
还有其他更高层次的标准，可将XML映射到Java对象的过程进一步自动化（或简化）。
例如，使用XML概要（Schema）和XML绑定处理引擎，您可以半自动地将满足某个XML概要的XML数据转变成Java数据对象。
代表性的引擎是Castor，是由ExoLab小组管理的一个开放源代码项目的产物。
上述使用Xerces DOM的简单例子仅仅是演示了这一处理过程的底层模型。
上述示例表明，在Java环境中解析或产生XML是非常方便的，这与J2EE没有必然关联。
格式化为XML的数据可以从应用程序的任何层次流入或输出，这使得与外部系统的集成性无可限量。
但我们能否以一种更为直接的方式将XML数据源集成到J2EE架构中去呢？

驾驭消息

J2EE架构包含了对JMS（Java消息服务）API的访问，以实现面向消息的通信（J2EE 1.2.1版只需JMS
API即可，在J2EE 1.3版中JMS基本定型，此时必须由某个兼容J2EE平台的服务器提供一个JMS API Provider）。
这一类的异步交互（与之相对的是：本地或远程方法调用所代表的同步交互）被证明在某些应用环境中是非常有用的。
某些时候，交互只需要通过间接的请求或回答来实现，即：在某些情况下，发出消息后不可能立即收到答复，
但我们仍希望当消息发出者重新在线时，确保他能收到答复信息。
面向消息系统的实际应用之一就是企业之间的松散集成。类似于EDI（电子文档交换）时代的文档交换，
两个企业由于业务的需要而交换消息，此时通常不能为了使用RPC或者RMI、CORBA、DCOM之类的远程方法交互而在两者之间进行紧密集成。
象JMS API这样的消息系统允许双方交换基于JMS API的消息载荷，
前提是双方在会话的时候均能提供兼容的JMS API服务。
当前仍然存在的困难是：双方是否能尊从相同的格式或协议。
这正是XML大显身手的时候。XML明确地被设计来解决此类数据交换问题
——灵丹妙药就是“面向消息的概要表”（Message-Oriented Communication Scheme），
实质就是基于一个双方认同的DTD或schema，用XML格式来交换消息载荷。
JMS API支持好几种消息，其中的TextMessage代表文本消息载荷。
一个简单而有效的XML消息交换方案是，在一端将我们的XML文档插入TextMessage，然后在另一端用自制的XML解析程序（如前面的MediaParser）解开数据并（可选地）将其转换成Java对象。
这使得我们既可以用JMS API支持的公开预订的消息模型，也可以用JMS API支持的点对点的消息模型来发送XML消息。
上述方法有一些局限，因为对于JMS运行时处理而言，XML的内容基本上是不透明的。
例如，JMS API允许使用基于特定消息头的路由。这很容易理解，尤其当我们希望XML消息根据其内容采取不同走向时。
例如在我们的MediaAsset例子中，我们希望公开讲座内容，但只想把特定的内容传送给那些预订了课程的人，或传送给那些表明可以接受某些媒体格式（如视频流）的人。
为了发挥JMS API的价值，以便实现上述基于内容的消息路由，我们有必要从XML数据中解析出关键信息，
然后在构造标准JMS API消息头时插入这些信息。这是可行的，但要实现XML信息我们就得额外地写很多代码（交换消息的双方均如此）。
为了在XML和JMS API之间架起桥梁，一些厂商提供了自定义的JMS扩展，以便直接支持XML消息机制。
例如，BEA系统公司基于J2EE的WebLogic应用服务器特别为TextMessage提供了XMLMessage子类，允许用XPath表达式来过滤XML消息。
不过这是一种专有的扩展，这要求交换消息的双方必须都能处理这类消息。
为此，Sun公司目前正在开发用于XML消息的Java API（JAXM）。其目标是提供一个高级别的标准服务，以实现基于ebXML的消息的合成与传送。
一个JAXM服务提供程序可以将这类消息映射到适当的物理消息系统（诸如JMS API）中去。
让XML看得见
将XML同Web系统的用户界面进行集成显然是一种有益的尝试。绝大多数的界面程序，无论是基于还是不基于Web，都是将数据进行转换，然后用易读的格式展现给用户。
用诸如XML这种“易消化”的格式存放数据将简化上述工作，同时它还大大提高了内容的可管理性，接下来我们就可看到这一点。
不过首先要大书一笔的是，XML在Web界面层的应用得益于JSP技术的发展。
一直以来大家都希望能清晰地区分Web应用程序的表示层与底层对象模型，JSP框架诞生于这些努力之中（包括早期JHTML尝试）。
JSP框架允许将Java代码嵌入到HTML内容中，这样既可以实现动态内容，又不必经常修改Java Servlets的代码。
在页面中包含Java技术的途径是通过JSP标记（JSP Tags），这些标记以XML风格出现。在JSP中，
Java程序以代码片段、服务器端JavaBeans组件、在服务器端触发特定操作的不透明标记（标准的或自定义的）等形式存在。
当某个用户通过浏览器请求JSP页面时，一个Java应用服务器解析该JSP页面，将其编译成一个Java Servlet，然后执行该Servlet以产生答复页面。
一种直接将XML数据源集成到JSP的界面中去的方法是，将XML加载到JavaBeans组件中（如同我们在MediaAsset例子中所做的），然后在JSP中直接引用这些JavaBeans组件。
下面是一个嵌入Java代码片断的例子：

]]> Media Assets for Lecture 14: Collection assets =parser.loadAssets("http://javaschool.org/jaf/E162/lecture14-assets.xml"); Iterator iter = assets.iterator(); %>]]>%>]]>]]> Name Type URN

上述程序还有一种更简洁的写法，那就是使用自定义JSP页面标记。这样我们就可以从JSP页面中剔出代码段，只使用JavaBeans组件和自定义的JSP标记即可。比如说，为了去掉创建解析器、加载资源数据到集合中的那段代码，我们可创建一个自己的标记，由它在幕后完成这些工作。

另外，我们必须强调，使用 EJB 和 Web 服务进行分布式的、基于组件的开发使得测试单个的组件变得非常必要。如果没有"GUI"需要测试，您就必须进行低级（lower-level）测试。最好以这种方式开始测试，省得当您将分布式的组件或 Web 服务作为您的应用程序的一部分时，您不得不花费心思重新进行测试。

总之，通过使用自动的单元测试，能够很快地发现系统的缺陷，并且也易于发现这些缺陷，使得测试工作变得更加系统化，因此整体的质量也得以提高。

3. 按照规范来进行开发，而不是按照应用服务器来进行开发。

要将规范熟记于心，如果要背离规范，要经过慎密的考虑后才可以这样做。这是因为当您背离规则的时候，您所做的事情往往并不是您应该做的事情。

当您要背离 J2EE 可以允许您做的事情的时候，这很容易让使您遭受不幸。我们发现有一些开发人员钻研一些 J2EE 允许之外的东西，他们认为这样做可以"稍微"改善J2EE的性能，而他们最终只会发现这样做会引起严重的性能问题，或者在以后的移植（从一个厂商到另一个厂商，或者是更常见的从一个版本到另一个版本）中会出现问题。实际上，这种移植问题是如此严重，以致 [Beaton] 将此原则称为移植工作的基本最佳实践。 

现在有好几个地方如果不直接使用 J2EE 提供的方法肯定会产生问题。一个常见的例子就是开发人员通过使用 JAAS 模块来替代 J2EE 安全性，而不是使用内置的遵循规范的应用程序服务器机制来进行验证和授权。要注意不要脱离 J2EE 规范提供的验证机制，如果脱离了此规范，这将是系统存在安全漏洞以及厂商兼容性问题的主要原因。类似地，要使用 servlet 和 EJB 规范提供的授权机制，并且如果您要偏离这些规范的话，要确保使用规范定义的 API（例如 getCallerPrincipal()）作为实现的基础。通过这种方式，您将能够利用厂商提供的强安全性基础设施，其中，业务要求需要支持复杂的授权规则。

其他常见的问题包括使用不遵循 J2EE 规范的持久性机制（这使得事务管理变得困难）、在J2EE程序中使用不适当的J2SE 方法（例如线程或 singleton），以及使用您自己的方法解决程序到程序（program-to-program）的通信，而不是使用 J2EE 内在支持的机制（例如 JCA、JMS 或 Web 服务）。当您将一个遵循 J2EE 的服务器移植到其他的服务器上，或者移植到相同服务器的新版本上，上述的设计选择将会造成无数的问题。唯一要背离规范的情况是，当一个问题在规范的范围内无法解决的时候。例如，安排执行定时的业务逻辑在 EJB2.1 出现之前是一个问题，在类似这样的情况下，我们建议当有厂商提供的解决方案时就使用厂商提供的解决方案（例如 WebSphere Application Server Enterprise 中的 Scheduler 工具），而在没有厂商提供的解决方案时就使用第三方提供的工具。如果使用厂商提供的解决方案，应用程序的维护以及将其移植到新的规范版本将是厂商的问题，而不是您的问题。 

最后，要注意不要太早地采用新技术。太过于热衷采用还没有集成到 J2EE 规范的其他部分或者还没有集成到厂商的产品中的技术常会带来灾难性的后果。支持是关键的??如果您的厂商不直接支持一种特定的在 JSR 中提出的技术，但此技术还没有被 J2EE 所接受，那么您就不应该采用此技术。毕竟，我们中的大多数人从事解决业务问题，而不是推进技术的发展。

4. 从一开始就计划使用 J2EE 安全性。

启用 WebSphere 安全性。这使您的 EJB 和 URL 至少可以让所有授权用户访问。不要问为什么??照着做就是了。 

在与我们合作的客户中，一开始就打算启用 WebSphere J2EE 安全性的顾客是非常少的，这一点一直让我们感到吃惊。据我们估计大约只有 50% 的顾客一开始就打算使用此特性。例如，我们曾与一些大型的金融机构（银行、代理等等）合作过，他们也没有打算启用安全性。幸运的是，这种问题在部署之前的检查时就得以解决.

不使用 J2EE 安全性是危险的事情。假设您的应用程序需要安全性（几乎所有的应用程序都需要），您敢打赌您的开发人员能够构建出自己的安全性系统，而这个系统比您从 J2EE 厂商那里买来的更好。这可不是个好的赌注，为分布式的应用程序提供安全性是异常困难的。例如，您需要使用网络安全加密令牌控制对 EJB 的访问。以我们的经验看来，大多数自己构建的安全性系统是不安全的，并且有重大的缺陷，这使产品系统极其脆弱。

一些不使用 J2EE 安全性的理由包括：担心性能的下降，相信其他的安全性（例如 Netegrity SiteMinder）可以取代 J2EE 安全性，或者是不知道 WebSphere Application Server 安全特性及功能。不要陷入这些陷阱之中，尤其是，尽管像 Netegrity SiteMinder 这样的产品能够提供优秀的安全特性，但是仅仅其自身不可能保护整个 J2EE 应用程序。这些产品必须与 J2EE 应用程序服务器联合起来才可能全面地保护您的系统。

其他的一种常见的不使用 J2EE 安全性的原因是：基于角色的模型没有提供足够的粒度访问控制以满足复杂的业务规则。尽管事实是这样的，但这也不应该成为不使用 J2EE 安全性的理由。相反地，应该将 J2EE 验证及 J2EE 角色与特定的扩展规则结合起来。如果复杂的业务规则需要做出安全性决策，那就编写相应的代码，其安全性决策要基于可以直接使用的以及可靠的 J2EE 验证信息（用户 ID 和角色）。
5、创建你所知道的

反复的开发工作将使您能够逐渐地掌握所有的 J2EE 模块。要从创建小而简单的模块开始而不是从一开始就马上涉及到所有的模块。

我们必须承认 J2EE 是庞大的体系。如果一个开发小组只是开始使用 J2EE，这将很难一下子就能掌握它。在 J2EE 中有太多的概念和 API 需要掌握。在这种情况下，成功掌握 J2EE 的关键是从简单的步骤开始做起。 

这种方法可以通过在您的应用程序中创建小而简单的模块来得到最好的实现。如果一个开发小组通过创建一个简单的域模型以及后端的持久性机制（也许使用的是 JDBC）,并且对其进行了完整的测试，这会增强他们的自信心，于是他们会使用该域模型去掌握使用 servlet 和 JSP 的前端开发。如果一个开发组发现有必要使用 EJB，他们也会类似地开始在容器管理的持久性 EJB 组件之上使用简单的会话 Facades，或者使用基于 JDBC 的数据访问对象（JDBC-based Data Access Objects，DAO），而不是跳过这些去使用更加复杂的构造（例如消息驱动bean和JMS）。

这种方法并不是什么新方法，但是很少有开发组以这种方式来培养他们的技能。相反地，多数开发组由于尝试马上就构建所有的模块，同时涉及 MVC 中的视图层、模型层和控制器层，这样做的结果是他们往往会陷入进度的压力之中。他们应该考虑一些敏捷（Agile）开发方法，例如极限编程（XP），这种开发方法采用一种增量学习及开发方法。在 XP 中有一种称为 ModelFirst 的过程，这个过程涉及到首先构建域模型作为一种机制来组织和实现用户场景。基本说来，您要构建域模型作为您要实现的用户场景的首要部分，然后在域模型之上构建一个用户界面（UI）作为用户场景实现的结果。这种方法非常适合让一个开发组一次只学到一种技术，而不是让他们同时面对很多种情况（或者让他们读很多书），这会令他们崩溃的。

还有，对每个应用程序层重复的开发可能会包含一些适当的模式及最佳实践。如果您从应用程序的底层开始应用一些模式如数据访问对象和会话 Facades，您就不应该在您的JSP和其他视图对象中使用域逻辑。

最后，当您开发一些简单的模块时，在开始的初期就可以对您的应用程序进行性能测试。如果直到应用程序开发的后期才进行性能测试的话，这往往会出现灾难性的后果。

6. 当使用 EJB 组件时，始终使用会话 Facades。



决不要将实体 bean 直接暴露给任何用户类型。对实体 bean 只可以使用本地 EJB 接口（Local EJB interfaces）。

当使用 EJB 组件时，使用一个会话 Facades 是一个确认无疑的最佳实践。实际上，这个通用的实践被广泛地应用到任何分布式的技术中，包括 CORBA、EJB 和 DCOM。从根本上讲，您的应用程序的分布"交叉区域"越是底层化，对小块的数据由于多次重复的网络中继造成的时间消耗就越少。要达到这个目的的方法就是：创建大粒度的 Facades 对象，这个对象包含逻辑子系统，因而可以通过一个方法调用就可以完成一些有用的业务功能。这种方法不但能够降低网络开销，而且在 EJB 内部通过为整个业务功能创建一个事务环境也可以大大地减少对数据库的访问次数。

EJB 本地接口（从 EJB 2.0 规范开始使用）为共存的 EJB 提供了性能优化方法。本地接口必须被您的应用程序显式地进行访问，这需要代码的改变和防止以后配置 EJB 时需要应用程序的改变。由于会话 Facades 和它包含的整个 EJB 对于彼此来说都应该是本地的，我们建议对会话 Facades 后面的实体 bean 使用本地接口。然而，会话 Facades 本身的实现（典型例子如无状态会话 bean）应该设计为远程接口。

为了性能的优化，可以将一个本地接口添加到会话 Facades。这样做利用了这样一个事实：在大多数情况下（至少在 Web 应用程序中），您的 EJB 客户端和 EJB 会共同存在于同一个 Java 虚拟机（JVM）中。另外一种情况，如果会话 Facades 在本地被调用，可以使用 J2EE 应用服务器配置优化（configuration optimizations），例如 WebSphere 中的"No Local Copies"。然而，您必须注意到这些可供选择的方案会将交互方法从按值传递（pass-by-value）改变为按引用传递（pass-by-reference）。这可能会在您的代码中产生很微妙的错误。当您要利用这些方案时，您应该在一开始就考虑其可行性。 

如果在您的会话 Facades 中使用远程接口（而不是本地接口），您也可以将同样的会话 Facades 在 J2EE 1.4 中以兼容的方式作为 Web 服务来配置。这是因为 JSR 109（J2EE 1.4 中的 Web 服务部署部分）要求使用无状态会话 bean 的远程接口作为 EJB Web 服务和 EJB 实现的接口。这样做是值得的，因为这样做可以为您的业务逻辑增加客户端类型的数量。

7. 使用无状态会话 bean，而不是有状态会话 bean

这样做可以使您的系统经得起错误的终止。使用 HttpSession 存储和用户相关的状态。

以我们的观点看来，有状态会话 bean 的概念已经过时了。如果您仔细对其考虑一下，一个有状态会话 bean 实际上与一个 CORBA 对象在体系结构上是完全相同的，无非就是一个对象实例，绑定到一个服务器，并且依赖于服务器来管理其生命周期。如果服务器关闭了，这种对象也就不存在，那么这个 bean 的客户端的信息也就不存在。

J2EE 应用服务器为有状态会话 bean 提供的故障转移（failover）能够解决一些问题，但是有状态的解决方案没有无状态的解决方案易于扩展。例如，在 WebSphere Application Server 中，对无状态会话 bean 的请求，是通过对部署无状态会话的成员集群进行平衡加载来实现。相反地，J2EE 应用服务器不能对有状态 bean 的请求进行平衡加载。这意味着您的集群中的服务器的加载过程会是不均衡的。此外，使用有状态会话 bean 将会再添加一些状态到您的应用服务器上，这也是不好的做法。这样就增加了系统的复杂性，并且在出现故障的情况下使问题变得复杂化。创建健壮的分布式系统的一个关键原则是尽量使用无状态行为。

因此，我们建议对大多数应用程序使用无状态会话 bean 方法。任何在处理时需要使用的与用户相关的状态应该以参数的形式传送到 EJB 的方法中（并且通过使用一种机制如 HttpSession 来存储它）或者从持久性的后端存储（例如通过使用实体 bean)作为 EJB 事务的一部分来进行检索。在合适的情况下，这个信息可以缓存到内存中，但是要注意在分布式的环境中保存这种缓存所潜在的挑战性。缓存非常适合于只读数据。

总之，您要确保从一开始就要考虑到可伸展性。检查设计中的所有设想，并且考虑到当您的应用程序要在多个服务器上运行时，是否也可以正常运行。这个规则不但适合上述情况的应用程序代码，也适用于如 MBean 和其他管理界面的情况下。

避免使用有状态性不只是对 IBM/WebSphere 的建议，这是一个基本的 J2EE 设计原则。

8. 使用容器管理的事务

学习一下 J2EE 中的两阶段提交事务，并且使用这种方式，而不是开放您自己的事务管理。容器在事务优化方面几乎总是比较好的。

使用容器管理的事务（CMT）提供了两个关键的优势（如果没有容器支持这几乎是不可能的）：可组合的工作单元和健壮的事务行为。

如果您的应用程序代码显式地使用了开始和结束事务（也许使用 javax.jts.UserTransaction 或者甚至是本地资源事务），而将来的要求需要组合模块（也许会是代码重构的一部分），这种情况下往往需要改变事务代码。例如，如果模块 A 开始了一个数据库事务，更新数据库，随后提交事务，并且有模块 B 做出同样的处理，请考虑一下当您在模块 C 中尝试使用上述两个模块，会出现什么情况呢？现在，模块 C 正在执行一个逻辑动作，而这个动作实际上将调用两个独立的事务。如果模块 B 在执行中失败了，而模块 A 的事务仍然能被提交。这是我们所不希望出现的行为。如果，相反地，模块 A 和模块 B 都使用 CMT 的话，模块 C 也可以开始一个 CMT（通常通过配置描述符），并且在模块 A 和模块 B 中的事务将是同一个事务的隐含部分，这样就不再需要复杂的重写代码的工作了。

如果您的应用程序在同一个操作中需要访问多种资源，您就要使用两阶段提交事务。例如，如果从 JMS 队列中删除一个消息，并且随后更新基于这条消息的纪录，这时，要保证这两个操作都会执行或都不会执行就变得尤为重要。如果一条消息已经从队列中被删除，而系统没有更新与此消息相关的数据库中的纪录，那么这种系统是不稳定的。一些严重的客户及商业纠纷源自不一致的状态。

我们时常看到一些客户应用程序试图实现他们自己的解决方案。也许会通过应用程序的代码在数据库更新失败的时候 "撤销"对队列的操作。我们不提倡这样做。这种实现要比您最初的想象要复杂得多，并且还有许多其他的情况（想象一下如果应用程序在执行此操作的过程中突然崩溃的情况）。作为替代的方式，应该使用两阶段提交事务。如果您使用 CMT，并且在一个单一的 CMT 中访问两阶段提交的资源（例如 JMS 和大多数数据库），WebSphere 将会处理所有的复杂工作。它将确保整个事务被执行或者都不被执行，包括系统崩溃、数据库崩溃或其他的情况。其实现在事务日志中保存着事务状态。当应用程序访问多种资源的时候，我们怎么强调使用 CMT 事务的必要性都不为过。
9、将jsp作为表示层的首选
只有在需要多种表示输出类型，并且输出类型被一个单一的控制器及后端支持时才使用 XML/XSLT。

我们常听到一些争论说，为什么您选择 XML/XSLT 而不是 JSP 作为表示层技术。选择 XML/XSLT 的人的观点是，JSP" 允许您将模型和视图混合在一起"，而 XML/XSLT 不会有这种问题。遗憾的是，这种观点并不完全正确，或者至少不像白与黑那样分的清楚。实际上，XSL 和 XPath 是编程语言。XSL 是图灵完成的（Turing-complete），尽管它不符合大多数人定义的编程语言，因为它是基于规则的，并且不具备程序员习惯的控制工具。

现在的问题是既然给予了这种灵活性，开发人员就会利用这种灵活性。尽管每个人都认同 JSP 使开发人员容易在视图中加入"类似模型"的行为，而实际上，在 XSL 中也有可能做出一些同样的事情。尽管从 XSL 中进行访问数据库这样的事情会非常困难，但是我们曾经见到过一些异常复杂的 XSLT 样式表执行复杂的转换，这实际上是模型代码。

然而，应该选择 JSP 作为首选的表示技术的最基本的原因是，JSP 是现在支持最广泛的、也是最被广泛理解的 J2EE 视图技术。而随着自定义标记库、JSTL 和 JSP2.0 的新特性的引入，创建 JSP 变得更加容易，并且不需要任何 Java 代码，以及可以将模型和视图清晰的分离开。在一些开发环境中（如 WebSphere Studio）加入了对 JSP（包括对调试的支持）的强大支持，并且许多开发人员发现使用 JSP 进行开发要比使用 XLS 简单，一些支持 JSP 的图形设计工具及其他特征（尤其在 JSF 这样的框架下）使得开发人员可以以所见即所得的方式进行 JSP 的开发，而对于 XSL 有时不容易做到。

最后一个要谨慎考虑使用 JSP 的原因是速度问题。在 IBM 所作的对比 XSL 和 JSP 相对速度的性能测试显示：在大多数情况下，JSP 在生成同样的 HTML 的时候，要比 XSL 快好几倍，甚至使用编译过的 XSL 也是如此。尽管多数情况下这不是问题，但在性能要求很高的情况下，这就会成为问题。

然而，这也不能说，您永远也不要使用 XSL。在一些情况下，XSL 能够表示一组固定的数据，并且可以基于不同的样式表来以不同的方式显示这些数据的能力是显示视图的最佳解决方案。然而，这只是一种例外的情况，而不是通用的规则。如果您只是生成 HTML 来表达每一个页面，那么在大多数情况下，XSL 是一种不必要的技术，并且，它给您的开发人员所带来的问题远比它所能解决的问题多。

10. 当使用 HttpSession 时，尽量只将当前事务所需要的状态保存其中，其他内容不要保存在 HttpSession 中。 



启用会话持久性。

HttpSessions 对于存储应用程序状态信息是非常有用的。其 API 易于使用和理解。遗憾的是，开发人员常常遗忘了 HttpSession 的目的----用来保持暂时的用户状态。它不是任意的数据缓存。我们已经见到过太多的系统为每个用户的会话放入了大量的数据（达到兆字节）。那好了，如果同时有 1000 个登录系统的用户，每个用户拥有 1MB 的会话数据，那么就需要 1G 或者更多的内存用于这些会话。要使这些 HTTP 会话数据较小一些，不然的话，您的应用程序的性能将会下降。一个大约比较合适的数据量应该是每个用户的会话数据在 2K-4K 之间，这不是一个硬性的规则，8K 仍然没有问题，但是显然会比 2K 时的速度要慢。一定要注意，不要使 HttpSession 变成数据堆积的场所。 

一个常见的问题是使用 HttpSession 缓存一些很容易再创建的信息，如果有必要的话。由于会话是持久性的，进行不必要的序列化以及写入数据是一种很奢侈的决定。相反地，应该使用内存中的哈希表来缓存数据，并且在会话中保存一个对此数据进行引用的关键字。这样，如果不能成功登录到另外的应用服务器的话，就可以重新创建数据。

当谈及会话持久性时，不要忘记要启用这项功能。如果您没有启用会话持久性，或者服务器因为某种原因停止了（服务器故障或正常的维护），则所有此应用服务的当前用户的会话将会丢失。这是件令人非常不高兴的事情。用户不得不重新登录，并且重新做一些他们曾经已经做过的事情。相反地，如果启用了会话持久性，WebSphere 会自动将用户（以及他们的会话）移到另外一个应用服务器上去。用户甚至不知道会有这种事情的发生。我们曾经见到过一些产品系统因为存在于本地代码中令人难以忍受的 bug（不是 IBM 的代码！）而突然崩溃的情况，这这种情况下，上述功能仍然可以运行良好。 

11. 在 WebSphere 中，使用动态缓存，并使用 WebSphere servlet 缓存机制。 

通过使用这些功能，系统性能可以得到很大的提高，而开销是很小的。并且不影响编程模型。

通过缓存来提高性能的好处是众所周知的事情。遗憾的是，当前的 J2EE 规范没有包括一种用于 servlet/JSP 缓存的机制。然而，WebSphere 提供了对页面以及片断缓存的支持，这种支持是通过其动态缓存功能来实现的，并且不需要对应用程序作出任何改变。其缓存的策略是声明性的，而且其配置是通过 XML 配置描述符来实现的。因此，您的应用程序不会受到影响，并保持与 J2EE 规范的兼容性和移植性，同时还从 WebSphere 的 servlet 及 JSP 的缓存机制中得到性能的优化。

从 servet 及 JSP 的动态缓存机制得到的性能的提高是显而易见的，这取决于应用程序的特性。Cox 和 Martin [Cox] 指出对一个现有的 RDF（资源描述格式）站点摘要 (RSS)servlet，当使用动态缓存时，其性能可以提高 10%。请注意这个实验只涉及到一个简单的 servlet，这个性能的增长量可能并不能反映一个复杂的应用程序。

为了更多地提高性能，将 WebSphere servlet/JSP 结果缓存与 WebSphere 插件 ESI Fragment 处理器、IBM HTTP Server Fast Response Cache Accelerator (FRCA) 和 Edge Server 缓存功能集成在一起。对于繁重的基于读取的工作负荷，通过使用这些功能可以得到许多额外的好处。

12. 为了提高程序员的工作效率，将 CMP 实体 bean 作为 O/R 映射的首选解决方案.

通过 WebSphere 框架（readahead、缓存、隔离级别等）优化性能。如果可能，有选择的应用一些模式来达到提高性能的目的，例如 Fast-Lane 阅读器 [Marinescu]。

对象/关系（O/R）映射是使用 Java 创建企业级的应用程序的基础。几乎每个 J2EE 应用程序都需要一些类型的 O/R 映射。J2EE 厂商提供一种 O/R 映射机制，这种机制在不同的厂商间是可移植的，高效的，并且能够被一些标准及工具很好地支持。这就是 EJB 规范中的 CMP（容器管理的持久性）部分。

早期的 CMP 实现以表现不佳及不支持许多 SQL 结构而著称。然而，随着 EJB 2.0 及 2.1 规范的出现，以及被一些厂商所采纳，并且随着像 IBM WebSphere Studio Application Developer 的出现，这些问题已经不再是问题了。

CMP EJB 组件现在已经被广泛地应用于许多高性能的应用程序中。WebSphere 包括一些优化功能以提高 EJB 组件的性能，优化功能包括：对生命周期的缓存和 read-ahead 能力。这两者优化功能都是配置时的选项，并且不需要对应用程序进行修改或者影响可移植性。

处于缓存状态的生命周期缓存 CMP 状态数据并提供基于时间的无效性。从处于缓存状态的生命周期得到的性能提高可以达到选项 A 的缓存性能，并且仍然可以为您的应用程序提供可伸展性。Read-ahead 能力和容器管理的关系结合使用。这个特性通过在相同的查询中随意地检索相关的数据作为父数据而减少与数据库的交互。如果相关的数据要通过使用并发的查询来访问的话，这种方法可以得到性能的改进。[Gunther]提供了详细的描述以及通过这些特性得到的性能提高的细节。

此外，为了完全优化您的 EJB 组件，当指定隔离级别时要特别注意。尽可能使用最低的隔离级别，并且仍然保持您的数据的完整性。较低的隔离级别可以提供最佳的性能，并且可以降低出现数据库死锁的危险。

这是目前最有争议的最佳实践。已经有大量的文章赞扬 CMP EJB，同样的贬斥声也不绝于耳。然而，这里最基本的问题是数据库开发是困难的。当您开始使用任何持久性解决方案之前，您需要掌握查询以及数据库锁定如何工作这些基础知识。如果您选择使用 CMP EJB，您要确保您已经通过一些书籍（例如 [Brown] 和 [Barcia]）知道如何使用它们。在锁定及争用方面有一些微妙的交互难以理解，但是，在您耗费一定的时间及努力后会将其掌握的。