下面以一个具体的实例来学习如何使用FineReport调用Oracle存储过程的。

　　第一步，Oracel定义存储过程

　　StScroe是Oracele数据库中的张表，其中记录了学生的成绩信息，表结构如下：

　　定义返回列表的存储过程——由于oracle存储过程没有返回值，它的所有返回值都是通过out参数来替代的，列表同样也不例外，但由于是集合，所以不能用一般的参数，必须要用pagkage了，所以定义存储过程要分两部分：

　1.建立一个程序包，如下：

CREATE or REPLACE PACKAGE TESTPACKAGE AS
TYPE Test_CURSOR IS REF CURSOR;
END TESTPACKAGE;

　　2.建立存储过程，存储过程为：

CREATE or REPLACE PROCEDURE p_STSCORE(Class in varchar2,p_CURSOR out TESTPACKAGE.Test_CURSOR) IS
BEGIN
OPEN p_CURSOR FOR select * FROM FR.STSCORE where STSCORE.ClassNo=Class;
END p_STSCORE;

　　第二步，调用存储过程

　　1.启动FineReport设计器，右击数据源面板，选择私有数据源，弹出私有数据源对话框。

　　2.点击增加按钮，新建一个私有数据源，名为ds1，数据库选择为Oracle数据源，查询类型为存储过程，在sql文本框中写如下语句调用存储过程：

{call fr.p_stscore('[?Class|Class1?]',?)}

　　3.点击预览按钮，可以预览查询到的数据，如下所示：

　　至此，FineReport设计器成功调用Oracle存储过程，您可以根据报表需求随心所欲地设计报表样式了。

背景

Web Service 现如今已经成为 SOA 实现标准之一。很多公司已经或者正在参与到 Web Service 项目的实现和部署中。Web Service 的优点在于松散的处理异构系统之间的通信和数据交换，可以随机应变的处理企业各个系统之间的整合问题。但是同时，Web Service 采用 XML 标准进行系统间的数据传输，加大了传输的数据量，尤其是在传输一些具有比较严格结构的数据时，会使得传输效率有所下降。所以，如何提高 Web Service 传输效率成为很多公司进行项目部署时非常关心的问题。

目的

本文介绍了在 Web Service 实施和开发过程中，提高系统效率的一些方法，实践证明，这些方法都是非常有效且易于实现的。不同的方法都有其应用领域和优缺点，我们会分别进行讨论。文章的主要目的在于，提供给读者多种方式的基本解决方案，使得读者在 Web Service 项目部署时，拥有更多的思路。

原因分析

Web Service 是采用 XML 标准进行数据传输的。XML 在传输过程中，会附带很多数据的相关信息，并以标签的形式表现出来。在传输过程中，一些情况下，这些标签会占用一半以上甚至更多的数据传输量，例如，要传输一个表格信息，如下（表格中的人名为虚构的）:

表 1 中的数据在传输过程中，有可能会生成下面的 XML 文件:
清单 1. 对应于表 1 数据所传输的 XML 文件示例

<Heading> <column> Name</column> <column>City</column> <column>Apartment</column> </Heading> <Data Grid> <row> <column>Air Wang</column> <column>Beijing</column> <column>IBM CDL</column> </row> </Data Grid>

如果上面的表格中还带有格式的信息（比如字体，背景颜色等等）的话，那么相应的 XML 就会更加复杂了。从上述 XML 中我们可以看出，除了数据之外，XML 会附加很多标签信息，这就使得传输的数据量增大，当所需要传输的数据比较多的时候，XML的标签就会带来比较大的效率问题。

解决方案一: 压缩与解压缩

Web Service 在网络中传输的是以 XML 为基础的消息的请求和响应。大量的数据传输会使网络成为瓶颈。一个最直接的解决方案就是对传输的消息进行压缩。对于不同规模的数据量，压缩应该有不同的解决方案，下面分别介绍如下:

1. 对于整个 XML 传输文件进行压缩
数据压缩已经发展了很多年，有很多成熟的技术，算法以及工具包。经常用于对数据压缩的 API 有 gzip 等方式。对文件进行压缩的做法非常简单，就是在发送 XML 之前对 XML 进行压缩，经过压缩以后，再在 XML 接收端对已经压缩的文件进行解压缩。
优点:
该方法的优点在于，使用了成熟的压缩和解压缩技术，当数据量比较大的时候，可以大大提高传输效率。对于纯文本的 XML，压缩可以减少其80%以上的体积。
缺点：
压缩和解压缩虽然可以使得 XML 的体积大大减少，但是其过程却是十分耗费系统资源的。压缩和解压缩往往会具有很大的 CPU 占有率以及内存占有率。对于配置不高的客户端甚至是服务器端，都会造成不小的压力。
应用场景:
该技术应用于网络瓶颈非常严重的情况或是主机配置比较高的情况。
举例:
正如本小节最开始已经介绍的，现在已经有很多成熟的压缩与解压缩的 API 提供给开发人员进行使用，我们选取其中最常用的 gzip 方式举例说明。一般来讲，系统请求 XML 的体积相对较小，没有必要使用压缩和解压缩的方法处理请求 XML。而对于系统响应 XML 来讲，一般都包含大量的数据，导致其体积庞大，需要进行压缩处理。对响应 XML 进行压缩的流程如下:
服务器端数据模型-->序列化操作-->利用 gzip 方式对序列化后的 XML 进行压缩-->返回到客户端-->以 gzip 方式进行解压缩-->对解压缩后的 XML 进行反序列化操作-->客户端数据模型
这里需要说明的一点是，客户端以及服务器端的数据模型需要实现 Serializable 接口。
清单 2. gzip 方式压缩部分实现代码示例（java 实现）

import java.io.*; import java.util.zip.*; public class Compress { public String gzip(OutputStream pStream) { … try { GZIPOutputStream stream = new GZIPOutputStream(pStream); return stream.toString(); }catch(IOException e){…} … return null; } … }

在程序将对象模型序列化成 XML 之前，可以使用上面的压缩方法，对数据流进行压缩。部分代码如下:
清单 3. 对象模型序列化后再进行压缩的实现代码示例

public class XMLSerializerHelper { … public static String saveOBJtoString(Object inputOBJ) throws ConverException { …… ByteArrayOutputStream outputStream = null; try{ outputStream = new java.io.ByteArrayOutputStream(); m_serializer.save((IXMLSerializable) inputObject, outputStream); return Compress.gzip(outputStream); }catch(Exception e){…} …… } … }

解压缩的过程也类似于上述代码。测试表明，采用 gzip 压缩可以减少60%以上的网络所带来的消耗。

2. 对于特定的数据进行特殊的处理
在企业日常的数据传输中，往往大量的数据具有很多共同的特点。数据和数据之间往往具有很多相同的地方，或者说，具有很多重复的地方。例如，在一个以 Web Service 为构架的报表处理系统中，报表往往会含有很多的空数据，或者相同属性和值域的数据，对于这样的情况，可以在代码中对特殊情况进行特殊的处理。我们同样以传输一个表格作为例子，如下:

可以看到，上述表格具有很多的空值，那么在 XML 中完全可以把空值的部分统一处理，这样就能大大减少网络传输的数量，其对应的部分 XML 如下：
清单 4. 对空值进行处理后的简化 XML 示例

…… <NULL Value>(1,2),(1,3),(1,4),(2,1),(2,2),(2,4)(3,1),(3,3),(3,4)</NULL Value> ……

优点:
对于重复性的数据来说，该方法可以几十倍甚至上百倍的减少传输的数据量（这取决于数据重复的数量大小），相对于第一种压缩方式，由于只是对固定形式的数据进行处理，所以不会占用很大的 CPU 以及内存。
缺点:
数据的特点不容易把握，能够处理的情况比较简单和单一。对于空值或者某些值重复较多的情况，可以采用本方法。

解决方案二: 减少多次调用，尽量使用一次性的调用方式。

传统的 RPC 调用，在多次使用的时候会产生很大的效率问题。用户在进行每次远程调用的时候都要等待网络传输所耗费的时间。而对于 Web Service 来讲，很多用户仍然将其作为传统的 RPC 来进行调用。每次都调用 Web Service Provider 所提供的函数，造成了效率的极大浪费。Web Service 的一大特点在于，可以在本地进行一次性的设置，再把生成的 XML 统一的发送给服务的另外一端。对于用户来讲，所有的设置工作都是在本地进行的，用户完全感觉不到网络所带来的瓶颈，而在最后的数据传输过程中，多消耗一些时间也是值得的。
应用场景:
对于同用户交互的情况，尽可能使用这样的处理，即减少多次的远程调用，尽量使得程序仅需完成一次调用。举一个简单的例子来说明问题：在一个用户界面上（User Interface），需要进行很多的设置，而这些设置的每一步都是需要进行远程调用的，这样对于用户来说，就会在每一次的设置过程中都等待网络传输所耗费的时间。而对于 Web Service 而言，客户端所有的工作就是生成请求 XML，所有的设置工作都可以统一生成一份 XML 文件，然后将其传送给服务器端，这样一来，用户只用等待一次的数据传输时间（可能相对时间较长，但是用户只用等待一次，还是值得的），而其他的工作都在服务器端进行处理。
优点:
所有数据操作在本地进行，用户在处理数据时不会感到网络所带来的停顿。最终所有操作请求统一发送给服务器端，使得原本多次等待的远程操作只需要一次数据传输就能完成。
举例:
下面的两幅图（图 1 和图 2）是某数据导入向导中的两个步骤，用户通过界面设置数据库以及数据表的信息，从而得到目的数据。

很多初学者容易进入的一个误区是在数据库选择以后，在程序中直接连接数据库，通过用户提供的用户密码建立数据库连接，然后在后续的每一个步骤中（如图中的设定数据表条件）都进行远程函数调用，以至于用户每一次点击向导中的“下一步”按钮时都会感觉到网络带来的瓶颈，例如停顿感，或者更严重的程序一段时间的没有响应等等。事实上，对于 Web Service 来讲，每一步都可以对请求 XML 进行设置（这种设置是在本地进行的），当所有步骤都完成以后，再将 XML 统一发送给服务器端进行处理。这样一来，用户在每一步之间的操作都是在本地进行的，不会带来多余的网络响应等待时间，使得整个向导的设置工作能够很快的进行。而最后一步完成以后，用户对于网络的一次性等待是相对值得的。在这个例子中，请求XML的部分结构如下:
清单 5. 客户端进行数据导入设置的 XML 示例

…… <Data Retrieving> <Database> <Type>Toolbox</Type> <Pattern>TCP/IP</Pattern> <UserName>Wang Yun</UserName> </Password> </Database> <Table> <Condition method=’more than’ value=’table’ >2500</Condition> <Condition method=’equal to’ value=’table’>Wang Yun</Condition> <Condition method=’less than’ value=’table’>10 days</Condition> </Table> <Data Retrieving> ……

系统客户端对 XML 进行设置的部分示例代码如下（将对象模型序列化的过程，仅列出 Database 节点）:
清单 6. 对象模型序列化成 XML 示例

public class DataBaseLoginOBJ { … public Element persistToXML(DataObject pOBJ) { … Element dbElement = pOBJ.createElement(“Database”); Element typeElement = pOBJ.createElement(“Type”); Element patternElement = pOBJ.createElement(“Pattern”); Element userElement = pOBJ.createElement(“UserName”); Element pwdElement = pOBJ.createElement(“Password”); dbElement.appendChild(typeElement); dbElement.appendChild(patternElement); dbElement.appendChild(userElement); dbElement.appendChild(pwdElement); … } … }

DataObject实现了org.w3c.dom.Document的接口, Element实现了org.w3c.dom.Element接口。在完成了整个请求XML的设置之后，就将其统一传输至服务器端进行处理。

解决方案三: XML 解析器的选择和优化

现在软件领域有很多种类的 XML 解析器，最基本的方式有两种：DOM 和 SAX。对于不同级别的XML文件，应该使用不同的解析器。有关 XML 解析器的介绍，请参考其他相关文档。下面列出他们使用的场景以及优缺点:

正确的选择XML解析器的种类，对于Web Service系统的效率会有很大的帮助。现在有很多厂家提供了基于这两种类型的很多XML解析器，在选择的时候，应该仔细阅读说明文档，慎重进行选择。另外，往往在一个系统中可以同时使用这两种方式，以达到解析的最高效率。一般来讲，对于请求XML可以采用DOM的解析方式进行解析，而对于响应XML可以使用SAX的方式进行解析。

解决方案四: 简化标签

我们知道，Web Service 解决方案在网络中传输 XML 具有比较复杂的结构。在传输过程中，不仅仅必要的数据被发送和接收，同时也会由于 XML 的结构过于冗杂而附加了更多的信息进行传输。举例如下:
系统客户端从服务器端得到的返回数据的响应 XML 结构如下:
清单 7. 在网络中传输的表格数据对应的 XML

<Cells> <Heading Cells> <Column> <Row> Data </Row> </Column> <Column> <Row/> </Column> … </Heading Cells> <DataGrid Cells> … </DataGrid Cells> </Cells>

由上面的 XML 我们可以看出，每一个返回数值，都至少有 <Column>, </Column>, <Row>, </Row> 来标识它，也就是说，如果我们要传输一个表格，那么表格中每一个数据都要伴随传输相应的这四个标签。假设表格中的每一个数据的字节数为8，那么标签所带来的附加字节就将近为数据的4倍。如果要传输的数据量十分巨大的话，效率自然会降低许多。所以我们可以采用一种十分简单的方式，有效的减少XML所带来的附加字节数，即简化XML标签。可以将上面所说的XML改写成下面的格式:
清单 8. 对应于清单 7 的简化后的 XML

<Cells> <Heading Cells> <C> <R> Data </R> </C> <C> <R/> </C> … </Heading Cells> <DataGrid Cells> … </DataGrid Cells> </Cells>

优点:
测试证明，采用这样的改进方式，可以使得整个系统的效率提高近一倍甚至更多。而且这样的处理方式简单易行，只是修改标签就可以了。
缺点:
使XML自身代表的意义变得不那么容易读懂，弥补的方式是一般会有一个对照表，来说明具体简化后的 XML 文件的含义。
举例:
该方法比较简单直观，这里列出对照表的一个例子如下:

类似上面这样的声明表格应该作为文档提供给用户。

应用场景:
这里需要说明一点，XML 能够清晰的表示出整个数据结构，而很多软件开发人员往往希望利用 XML 来观察数据的情况，而标签就是协助他们更好的完成这样的工作。所以，一般来讲，标签需要尽可能的有意义，由于 C 和 R 可以比较明确的表示 Column 和 Row，并且他们在数据传输过程中是重复的最多的（占传输标签总数的80%），所以我们进行了上述的改动。但是对于像 Cells 这样的标签，由于其重复率不是很高，而且我们需要这个标签具有字面上的意义，所以，类似于这样的情况，我们给予保留。

解决方案五: 缓存机制

前面介绍的四种提高效率的方法都是基于 XML 传输的，也就是说，都是在如何提高 XML 传输效率上进行介绍的。而第五种机制对于任何的软件解决方案都适用，而对于 Web Service 解决方案来讲，更是具有锦上添花的作用。缓存机制最通用的一个思想是，将使用次数比较多的数据缓存起来，如果再有相同请求时，就将缓存中的数据返回。这样会减少数据逻辑处理所带来的时间。我们以用户的一次刷新数据的操作为例，介绍一种比较通用的缓存方式，如图:

由图中可知，当用户进行刷新操作时，服务器端先检查请求 XML，取出要刷新数据源的 CUID。根据该 CUID，系统检查在缓存中是否存在该 CUID 对应的数据对象，如果有，则取出其刷新状态，并与对应该 CUID 的数据源的刷新状态进行比较。如果比较一致，则直接返回数据给客户端，如果比较不一致，则需要打开数据源进行重新刷新，并将刷新以后的结果集的对象保存在缓存中。如果缓存已经满了，则利用最近最少使用原则，清除缓存中的一部分数据对象。另外，缓存的大小设置是可以通过属性文件进行设置的，在程序中，对缓存进行初始化时，首先读取了属性文件来进行缓存大小的设定。缓存数据的好处在于，在对数据进行多次重复刷新时，系统不需要重新打开数据源（有时候连接并打开数据源是非常消耗时间的），从而提高了系统的效率。
优点:
对于多次的相同方式的数据操作，数据直接从缓存返回，可以很大程度的提高系统效率。
缺点:
编程的工作量比较大，需要测试的部分比较多。
应用场景:
一般的 Web Service 部署程序都可以采用缓存机制的处理。

其他解决方案

对于 Web Service 服务器，各个厂商都提供了很多服务器设置，以提高 Web Service 的性能和效率。具体请参考相关服务器的文档。

小结

对于提高 Web Service 的效率，本文给出了一些解决方案，从各个不同方面对 Web Service 效率的提高进行了讨论。对于不同的应用系统，应该酌情分析系统建立的环境以及系统的使用人群和范围，以最终决定采用何种解决方案。

    4. Hibernate：
    Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。
    在平台中，我们采用Hibernate进行数据库操作，只有在一些对数据库性能有特别要求的模块，才直接使用jdbc进行连接。

    5. Ehcache：
    Ehcache出自Hibernate，在Hibernate中使用它作为数据缓存的解决方案。这是Hibernate必须的包。

    6. JCrontab：
        它是由Java语言编写的日程处理程序，它目的是提供强大的定时处理功能，让我们的应用程序可以按照提供的时间表来执行不同的应用。
    我们主要用Jcrontab管理以下一些定时任务：
     1) 年排行榜后台更新进程：自动计算年排行榜。
     2) 月排行榜后台更新进程：自动计算月排行榜。
     3) 周排行榜后台更新进程：自动计算周排行榜。
     4) 日排行榜后台更新进程：自动计算日排行榜。
     5) 更新对象缓存：实现对象缓存的更新，处理那些长期没被再一次访问的对象缓存。
     6) 清页面缓存：当管理员使用的手工刷新页面缓存的功能时，系统会将这些需要刷新的缓存加到一个队列中，由本进程负责刷新。
     7) 相关产品自动实现间隔：相关产品的计算对系统消耗比较大，所以系统不会对所有几十万个商品进行计算，只有在用户查看单个商品时算出这个商品的相关产品并进行缓存。那么当用户下一次访问这个商品的相关产品时就直接从缓存中读取出来。而这个进程就是为了定时更新这个缓存。
     8) 自动推荐后台更新进程：进程根据商品推荐规则进行自动推荐。
     9) 新闻推荐后台更新进程：进程根据新闻推荐规则进行自动推荐。
    10) 关键字后台进程：当用户在前台搜索栏中输入一个查询值时，系统并不马上将其统计到关键字，而是放到内存中，由此进程定时统计。
    11) 保存访问量信息进程：用户每访问一次系统，系统并不马上统计，而是放到内存中，由此进程定时保存到数据库，供统计进程进行统计。
    12) 年访问量排行计算：计算年访问量排行榜。
    13) 月访问量排行计算：计算月访问量排行榜。
    14) 周访问量排行计算：计算周访问量排行榜。
    15) 日访问量排行计算：计算日访问量排行榜。
    16) 年降价排行计算：计算年降价排行榜。
    17) 月降价排行计算：计算月降价排行榜。
    18) 周降价排行计算：计算周降价排行榜。
    19) 日降价排行计算：计算日降价排行榜。
    20) 统计计算：每天对访问量进行统计。
    21) 生成订阅邮件列表进程：根据用户的订阅设置，生成需要发送的邮件队列。
    22) 发送订阅邮件进程：根据要发送的邮件队列发送邮件。
    23) 拍卖自动出价进程：实现拍卖模块中的自动出价功能。
 
    7. JCS：
    JCS是Jakarta的项目Turbine的子项目。它是一个复合式的缓冲工具。可以将对象缓冲到内存、硬盘。具有缓冲对象时间过期设定。还可以通过JCS构建具有缓冲的分布式构架，以实现高性能的应用。
    对于一些需要频繁访问而每访问一次都非常消耗资源的对象，可以临时存放在缓冲区中，这样可以提高服务的性能。而JCS正是一个很好的缓冲工具。缓冲工具对于读操作远远多于写操作的应用性能提高非常显著。
    网客通平台中使用jCS提供缓存功能，主要是页面缓存和对象缓存，通过JCS，系统将用户访问过的页面和对象缓存到内存中，对于访问量巨大，内存缓存已经不能负荷的情况下，我们还可以将缓存设置到硬盘中保存。
    使用缓存的话，能将系统可负载和性能大幅度的提升。当没有使用集群环境的情况下，缓存是一种必不可少的技术。

    8. JSF / MyFaces:
    JavaServer Faces (JSF) 是一种用于构建 Web 应用程序的新标准 Java 框架。它提供了一种以组件为中心来开发 Java Web 用户界面的方法，从而简化了开发。
    JSF 的主要优势之一就是它既是 Java Web 用户界面标准又是严格遵循模型－视图－控制器 (MVC) 设计模式的框架。用户界面代码（视图）与应用程序数据和逻辑（模型）的清晰分离使 JSF 应用程序更易于管理。为了准备提供页面对应用程序数据访问的 JSF 上下文和防止对页面未授权或不正确的访问，所有与应用程序的用户交互均由一个前端“Faces”servlet（控制器）来处理。
    MyFaces是JavaServer Faces（JSF） Web框架 （JSR 127）的一个实现。提供了很多常用控件。
    我们平台中采用一些基于JSF框架的MyFaces控件。这样使程序结构十分清晰。

    9. Log4j：
    Log4j是Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。最令人感兴趣的就是，这些可以通过一个配置文件来灵活地进行配置，而不需要修改应用的代码。
    这是一个可选包，如果不使用Log4j的话，commons-logging会自动使用SUN J2SDK的日志包，不过我们还是推荐使用Log4j，它的功能非常强大。

    10. Lucene：
        Lucene是一个开放源程序的搜寻器引擎，利用它可以轻易地为Java软件加入全文搜寻功能。Lucene的最主要工作是替文件的每一个字作索引，索引让搜寻的效率比传统的逐字比较大大提高，Lucen提供一组解读，过滤，分析文件，编排和使用索引的API，它的强大之处除了高效和简单外，是最重要的是使使用者可以随时应自已需要自订其功能。
    我们使用Lucene建立索引，并在这基础上实现了全文搜索功能。

    11. Ant：
    Ant是一个基于Java的自动化脚本引擎，脚本格式为XML。
    我们除了用Ant做Java编译相关任务外，还通过插件实现很多应用的调用。包括程序编译、打包、Hibernate配置文件自动生成、部署、以及单元测试等操作。
    当一个代码项目大了以后，每次重新编译，打包，测试等都会变得非常复杂而且重复，因此c语言中有make脚本来帮助这些工作的批量完成。在Java中应用是平台无关性的，当然不会用平台相关的make脚本来完成这些批处理任务了，Ant本身就是这样一个流程脚本引擎，用于自动化调用程序完成项目的编译，打包，测试等。除了基于JAVA是平台无关的外，脚本的格式是基于XML的，比make脚本来说还要好维护一些。

    12. Axis：
    Axis是一个SOAP引擎，提供创建服务器端、客户端和网关SOAP操作的基本框架。SOAP是被广泛作为新一代跨平台、跨语言分布计算Web Services的重要部分。
    网客通平台使用Axis提供WebService支持，广泛应用于通用数据接口，对外系统提供服务等功能。
    如：
     1) 商品查询服务：提供接口让外接系统可以查到平台中的商品信息。
     2) 新闻发布服务：提供接口让外接系统可以取到各类新闻。
     3) 订单服务：提供接口让外接系统可以在平台中生成订单，并获取各种订单信息。
    注：上述服务都有严格的权限控制。

    13. JavaMail：
    JavaMail是Sun发布的用来处理email的API。它可以方便地执行一些常用的邮件传输。
    我们使用JavaMail实现了平台中邮件发送、群发等相关功能，供业务系统使用。

    14. XDoclet：
    XDoclet是一个开源项目，可以通过在java源代码中的一些特殊的注释信息，自动生成配置文件、源代码等等。例如web、ejb的部署描述文件等。
    我们用XDoclet来生成Hibernate的hbm配置文件。

    15. JSTL：
    JSP 标准标记库（JSP Standard Tag Library，JSTL）是一个实现 Web 应用程序中常见的通用功能的定制标记库集，这些功能包括迭代和条件判断、数据管理格式化、XML 操作以及数据库访问。
    我们使用JSTL封装各种业务逻辑。

    16. Jakarta ORO：
    Jakarta ORO Java 类是一套文本处理Java类，提供了与Perl5 兼容的规则表达式，类AWK规则表达式，glob 表达式，以及用于执行替换、分割、过滤文件名等的工具。这个包是OROMatcher, AwkTools, PerlTools, and TextTools libraries originally from ORO, Inc的后续产品。
    网客通平台使用ORO处理正则表达式，广泛应用于各种文本处理中。

    17. SwarmCache / JGroups：
    SwarmCache是一个简单且有效的分布式缓存，它使用IP multicast与同一个局域网的其他主机进行通讯，是特别为集群和数据驱动web应用程序而设计的。SwarmCache能够让典型的读操作大大超过写操作的这类应用提供更好的性能支持。SwarmCache使用JavaGroups来管理从属关系和分布式缓存的通讯。
    JGroups是一个开源的纯java编写的可靠的群组通讯工具。其工作模式基于IP多播，但可以在可靠性和群组成员管理上进行扩展。其结构上设计灵活，提供了一种灵活兼容多种协议的协议栈，对于每个产品都有不同的可靠性需求。这种协议栈可以让用户定义的自己可靠性指标和性能指标。
    当使用集群环境时，系统存在着缓存同步的问题，需要对集群中每一台服务器的缓存进行同步，这样就必须要有一个缓存同步的机制，SwarmCache和JGroups就是为了解决这个问题而被加到网客通中。

    18. JUnit：
    JUnit是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（regression testing framework）。Junit测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。
    我们主要用JUnit来进行单元测试。