设计模式在短信触发平台中的实践和应用论文.doc

毕业论文 第 33 页

毕 业 论 文

论文题目
设计模式短信触发平台

中的实践和应用
学生姓名

学生学号

专业班级

学院名称

指导老师

学院院长

5 月 8 日

设计模式在短信触发平台中的实践和应用
摘 要
短信触发业务是利用了用户在收/发短信的过程中触发进短信触发业务平台，进行相关的业务操作。在用户收短信的过程中，可以触发了被叫触发业务属性，从而进行与被叫相关的一些业务操作，比如：短信拦截、短信自动回复、短信转移、短信U盘、短信加密业务等。在用户发送短信的过程，可以触发了主叫触发业务属性，从而进行与主叫相关的一些业务操作，比如：发短信点值累积计算，以鼓励用户多发短信，等业务。
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
通过在短信触发平台运用好的设计模式，实践结果表明，选择适当的设计模式大大提高了开发效率，而且提高了代码的可读性和可维护性。
关键词：短信触发，指令，设计模式。

The practice and application of design patterns
in messaging platform trigger
Abstract
SMS trigger business users triggered into SMS platform and operate related business in the use of the process of send / receive SMS. SMS users in the send process， can trigger an Called trigger business attributes， Thus， with some Called related business operations， such as : SMS interception， automatic SMS reply message transfer， text messaging USB ，SMS encryption， and so on. Send SMS users in the process and could trigger a calling trigger business attributes. Thus， with the calling of some business operations， such as: the value of the accumulated points SMS， to encourage more users send text messages. And so on.
A design pattern was repeated use， and the majority of people know about it， after the catalog， code design experience. It was used to designed to be reusable code， more easily understood by others， ensuring code reliability. Undoubtedly， the design pattern to ourselves to others in the system are a win-win， so that code designed to prepare really works，Design software engineering model is the cornerstone， as a building block in the same brick. Design patterns so that people can be more convenient to the successful reuse of design and architecture. Will be confirmed as the technical presentation is designed to make the new system developers more easily understand their design ideas.
SMS triggered by the use of good design platform model results show， select appropriate design pattern has greatly improved the efficiency of development and improve code readability and maintainability.
Keywords: SMS trigger， directives， design patterns.

目 录

1 绪论 1
1.1 题背景及目的 1
1.1.1 课题背景 1
1.1.2 课题目的 1
1.2 国内研究现状 2
1.2.1 IVR 2
1.2.2 SMPP 3
2 设计模式 4
2.1 设计模式简介 4
2.1.1 基本要素 4
2.1.2 一些基本的设计模式 5
2.1.3 设计模式之Factory 6
2.2 应用框架 12
2.2.1 Spring Framework 13
2.2.2 WebWork 13
2.2.3 Struts 14
2.2.4 Hibernate 14
3 短信触发平台的需求和设计 15
3.1 需求概述 15
3.1.1 短信拦截业务 15
3.1.2 短信自动回复业务 15
3.1.3 短信转移业务 15
3.1.4 短信U盘业务 15
3.1.5 短信加密业务 16
3.2 系统结构 16
3.2.1 短信平台结构 16
3.2.2 短信触发系统结构 17
4 短信触发平台的实现 18
4.1 开发环境 18
4.1.1 流程开发IVR TOOLS 18
4.1.2 开发平台Eclipse 18
4.1.3 数据库Sybase 19
4.2 IVR接口形式 20
4.3 IVR处理流程 20
4.3.1 用户业务登记注册 20
4.3.2 短信中心业务触发 21
4.3.3 短信中心短信处理流程 21
4.3.4 短信中心回执处理流程： 21
4.4 IVR指令方案 21
4.5 设计模式在短信触发平台中的应用 22
4.5.1 新太科技的openeap平台 23
4.5.2 Factory在短信触发平台应用 23
4.5.3 后台调度设计 27
5 结论与展望 30

1 绪论
1.1 课题背景及目的
1.1.1 课题背景
短信触发业务是利用了用户在收/发短信的过程中触发进短信触发业务平台，进行相关的业务操作。在用户收短信的过程中，可以触发了被叫触发业务属性，从而进行与被叫相关的一些业务操作，比如：短信拦截、短信自动回复、短信转移、短信U盘、短信加密业务等。在用户发送短信的过程，可以触发了主叫触发业务属性，从而进行与主叫相关的一些业务操作，比如：发短信点值累积计算，以鼓励用户多发短信，等业务。
短信触发业务系统通过扩展的SMPP短信协议与短信中心之间实现短信触发的激活/关闭/查询功能。对于短信的被叫触发功能由短信中心进行实现，各个厂家都有自己的短信被叫触发机制。一旦短信被叫触发后，通过该联网网关将所触发的短信送给短信触发业务系统，由短信触发业务系统进行后续处理。短信触发业务系统通过计费网关与计费中心连接进行扣费和出话单XDR文件。短信触发业务系统通过短信网关模块与第三方SP以短信协议进行交互，以实现外挂SP的接入。
1.1.2 课题目的
电信市场竞争的日趋激烈和移动通信对固定电话的冲击，多家电话运营商以价格和服务争夺用户的“拉锯战”，再加上网络电话等新技术、新业务的强力冲击，使得中国电信面临着前所未有的压力。正是在此压力之下，中国电信明确提出实施战略转型，推动企业由传统基础网络运营商向现代综合信息服务提供商转变。
然而，这种转变并非一蹴而就，转变的过程也非一帆风顺，商务领航信息化服务在市场运营推广的过程中面临重重困难，抛开产品本身存在的问题，尽管其商业模式得到了应用提供商、设备提供商、服务提供商、中国电信甚至用户的充分肯定，但在降低用户的资金、技术、人才压力门槛的同时，从某种程度来讲，将这种压力传递到电信自身和应用提供商、设备提供商、服务提供商身上，短期内无法大量创收，转型的道路走得非常艰辛，全新的信息化服务专家的形象暂时无法充分体现。但激烈市场竞争不容许电信公司消极等待和踌躇迟疑，需要充分挖掘现有资源潜力，提供有别于传统语音的差异化服务，推出短信触发平台业务，在满足市场需求的同时增强自身竞争力，使其发挥最大效用。
随着江苏电信小灵通短信应用的持续增长，短信业务的巨大潜力已经越来越展现出来，同时，声讯IVR业务作为增值业务的传统业务形式，在江苏已经发展的相当成熟，展现出更多的求新求变的趋势。如果能够将短信业务于IVR业务结合起来，将会极大的提升无论是短信还是IVR业务的吸引力，并提高业务的服务层次。两者的结合不仅将提升很多现有业务的服务能力，同时，两者的结合还将涌现出更多新的服务内容。
1.2 国内研究现状
1.2.1 IVR
IVR，(Interactive Voice Response)即互动式语音应答，您只须用电话即可进入服务中心，根据操作提示收听手机娱乐产品。 可以根据用户输入的内容播放有关的信息。IVR(交互式语音响应)是呼叫中心的重要组成部分，主要用于为用户电话来访提供语音提示，引导用户选择服务内容和输入电话事务所需的数据，并接受用户在电话拨号键盘输入的信息，实现对计算机数据库等信息资料的交互式访问。IVR可以取代或减少话务员的操作，达到提高效率、节约人力、实现24小时服务的目的。同时也可方便用户，减少用户等候时间，降低电话转接次数。
IVR业务：意即无线语音业务增值服务，和目前大家熟知的固定电话声讯服务类似。手机用户拨打指定号码，获得所需信息或者参与互动式的服务。 最常见的业务有：1 语音点歌、2 语音聊天交友、3 手机杂志、4 电子贺卡。目前运营IVR业务的SP包括雷霆无极、腾讯、鸿联九五、新浪。其中，TOM旗下的雷霆无极占有国内市场70%的份额。据中移动预计，2004年国内IVR业务的市场规模将达到25亿人民币左右，当然，这一数据相对乐观。但是不可否认，IVR也必将成为无线增值服务中的重量级业务之一。 现有的IVR业务包括彩铃（移动自己运营）、在线点歌、语音信息服务、语音游戏、多方会议、背景音乐通话以及聊天交友等等。实质上，IVR业务主要是复制以前声讯台的业务模式，同时也提供了虚拟身份的主题聊天和点对点聊天业务。
1.2.2 SMPP
SMPP（short message peer to peer）协议是一个开放的消息转换协议；它定义了一系列操作的协议数据单元（PDUS）和当SMPP运行时ESMS应用系统与smsc之间交换的数据。从而完成SMSC与ESMES（外部短消息实体）的信息交换。SMPP是基于SMSC与ESME之间的请求和响应协议数据单元的交换，每一个smpp操作都由一个请求pdu和相应的一个响应PDU组成并且这种交换是在TCP/IP或x．25网络连接之上的.
1、 与CMPP/SGIP协议的差异
1） 协议定义比CMPP和SGIP严谨和规范，虽然CMPP和SGIP都是从SMPP派生出来的。
2）  CMPP和SGIP中有大量的关于计费的定义，SMPP没有考虑这部分内容。这完全反映了通过短信实现的移动增值业务模式在国内的成熟和流行。
3） SMPP的网络承载层可以是TCP/IP和X.25。
2、SMPP协议解决的是移动网络之外的短消息实体与短消息中心的交互问题。即允许移动网络之外的短消息实体（External Short Message Entities，ESMEs）连接短消息中心（SMSC）来提交和接受短消息。
3、任何SMPP操作都包含请求PDU（Request Protocol Data Unit）和与之对应的回应PDU（Response Protocol Data Unit）。
4、SMPP把ESMEs分类为Transmitter/Receiver/Transceiver三种交互方式，分别对应仅提交短消息/仅接收短消息/提交和接收短消息三种形态。
5、SMPP会话有5种状态：OPEN / BOUND_TX / BOUND_RX / BOUND_TRX / CLOSED

2 设计模式
2.1 设计模式简介
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。GoF的“设计模式”是第一次将设计模式提升到理论高度，并将之规范化，GoF包括23种基本设计模式，自此，在可复用面向对象软件的发展过程中，新的大量的设计模式不断出现。
2.1.1 基本要素：
1. 模式名称（pattern name）
一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。
2. 问题(problem)
描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。
3. 解决方案(solution)
描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。
4. 效果(consequences)
描述了模式应用的效果及使用模式应权衡的问题。尽管描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。
2.1.2 一些基本的设计模式
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
Adapter：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Builder：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Composite：将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户对单个对象和复合对象的使用具有一致性。
Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言， 它比生成子类方式更为灵活。
Facade：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Factory Method：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。
Flyweight：运用共享技术有效地支持大量细粒度的对象。
Interpreter：给定一个语言， 定义它的文法的一种表示，并定义一个解释器， 该解释器使用该表示来解释语言中的句子。
Iterator：提供一种方法顺序访问一个聚合对象中各个元素， 而又不需暴露该对象的内部表示。
Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
Observer：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。
Prototype：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy：为其他对象提供一个代理以控制对这个对象的访问。
Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy：定义一系列的算法，把它们一个个封装起来， 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
2.1.3 设计模式之Factory
工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如A a=new A() 工厂模式也是用来创建实例对象的，所以以后new时就要多个心眼，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。
以类Sample为例， 如果我们要创建Sample的实例对象：
Sample sample=new Sample();
实际情况是，通常都要在创建sample实例时做点初始化的工作，比如赋值 查询数据库等。
可以使用Sample的构造函数，这样生成实例就写成：
Sample sample=new Sample(参数);
但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了（就需要Refactor重整）。
初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中，相当于将很多鸡蛋放在一个篮子里，是很危险的，这也是有背于Java面向对象的原则，面向对象的封装(Encapsulation)和分派(Delegation)告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来(减少段和段之间偶合联系性)，这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。
首先，将创建实例的工作与使用实例的工作分开， 也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。
这时就需要Factory工厂模式来生成对象了，不能再用上面简单new Sample(参数)。还有，如果Sample有个继承如MySample， 按照面向接口编程，需要将Sample抽象成一个接口。现在Sample是接口，有两个子类MySample 和HisSample ，我们要实例化他们时，如下：
Sample mysample=new MySample();
Sample hissample=new HisSample();
随着项目的深入，Sample可能还会"生出很多儿子出来"， 那么要对这些儿子一个个实例化，更糟糕的是，可能还要对以前的代码进行修改:加入后来生出儿子的实例.这在传统程序中是无法避免的。
但如果一开始就有意识使用了工厂模式，这些麻烦就没有了。
建立一个专门生产Sample实例的工厂：
public class Factory{
　　public static Sample creator(int which){
　　//getClass 产生Sample 一般可使用动态类装载装入类。
　　if (which==1)
　　　　return new SampleA();
　　else if (which==2)
　　　　return new SampleB();
　　}
}
在程序中，如果要实例化Sample时。就使用
Sample sampleA=Factory.creator(1);
这样，在整个就不涉及到Sample的具体子类，达到封装效果，也就减少错误修改的机会，这个原理可以用很通俗的话来比喻：就是具体事情做得越多，越容易犯错误。这每个做过具体工作的人都深有体会。相反，官做得越高，说出的话越抽象越笼统，犯错误可能性就越少。
使用工厂方法，要注意几个角色，首先你要定义产品接口，如上面的Sample，产品接口下有Sample接口的实现类，如SampleA，其次要有一个factory类，用来生成产品Sample，如图2-1，最右边是生产的对象Sample：

图2-1 类结构图
进一步稍微复杂一点，就是在工厂类上进行拓展，工厂类也有继承它的实现类concreteFactory了。
抽象工厂
工厂模式中有： 工厂方法(Factory Method) 抽象工厂(Abstract Factory)。
这两个模式区别在于需要创建对象的复杂程度上。如果我们创建对象的方法变得复杂了，如上面工厂方法中是创建一个对象Sample，如果我们还有新的产品接口Sample2。
这里假设：Sample有两个concrete类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和SampleB2。
那么，我们就将上例中Factory变成抽象类，将共同部分封装在抽象类中，不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂：
public abstract class Factory{
　　public abstract Sample creator();
　　public abstract Sample2 creator(String name);
}
public class SimpleFactory extends Factory{
　　public Sample creator(){
　　 .........
　　　　return new SampleA
　　}
　　public Sample2 creator(String name){
　　 .........
　　　　return new Sample2A
　　}
}
public class BombFactory extends Factory{
　　public Sample creator(){
　　　　......
　　　　return new SampleB
　　}
　　public Sample2 creator(String name){
　　　　......
　　　　return new Sample2B
　　}
}
从上面看到两个工厂各自生产出一套Sample和Sample2，也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2。
抽象工厂还有另外一个关键要点，是因为 SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如：制造工艺比较简单，所以名称叫SimpleFactory。
在实际应用中，工厂方法用得比较多一些，而且是和动态类装入器组合在一起应用。
以Jive的ForumFactory为例，这个例子在前面的Singleton模式中我们讨论过，现在再讨论其工厂模式：
public abstract class ForumFactory {
private static Object initLock = new Object();
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
　　private static ForumFactory factory = null;
　　public static ForumFactory getInstance(Authorization authorization) {
　　　　//If no valid authorization passed in， return null.
　　　　if (authorization == null) {
　　　　　　return null;
　　　　}
　　　　//以下使用了Singleton 单态模式
　　　　if (factory == null) {
　　　　　　synchronized(initLock) {
　　　　　　　　if (factory == null) {
　　　　　　　　　　　　......
　　　　　　　　　　try {
　　　　　　　　　　　　　　//动态转载类
　　　　　　　　　　　　　　Class c = Class.forName(className);
　　　　　　　　　　　　　　factory = (ForumFactory)c.newInstance();
　　　　　　　　　　}
　　　　　　　　　　catch (Exception e) {
　　　　　　　　　　　　　　return null;
　　　　　　　　　　}
　　　　　　　　}
　　　　　　}
　　　　}
　　　　//Now， 返回 proxy.用来限制授权对forum的访问
　　　　return new ForumFactoryProxy(authorization， factory，
　　　　　　　　　　　　　　　　　　　　factory.getPermissions(authorization));
　　}
　　//真正创建forum的方法由继承forumfactory的子类去完成.
　　public abstract Forum createForum(String name， String description)
　　throws UnauthorizedException， ForumAlreadyExistsException;
　　....
}
因为现在的Jive是通过数据库系统存放论坛帖子等内容数据，如果希望更改为通过文件系统实现，这个工厂方法ForumFactory就提供了提供动态接口：
private static String className = "com.jivesoftware.forum.database.DbForumFactory";
com.jivesoftware.forum.database.DbForumFactory可以使用自己开发的创建forum的方法来代替。
在上面的一段代码中一共用了三种模式，除了工厂模式外，还有Singleton单态模式，以及proxy模式，proxy模式主要用来授权用户对forum的访问，因为访问forum有两种人:一个是注册用户 一个是游客guest，那么那么相应的权限就不一样，而且这个权限是贯穿整个系统的，因此建立一个proxy，类似网关的概念，可以很好的达到这个效果。 
看看Java宠物店中的CatalogDAOFactory:
public class CatalogDAOFactory {
　　/**
　 　* 本方法制定一个特别的子类来实现DAO模式。
　　 * 具体子类定义是在J2EE的部署描述器中。
　　 */
　　public static CatalogDAO getDAO() throws CatalogDAOSysException {
　　　　CatalogDAO catDao = null;
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　//动态装入CATALOG_DAO_CLASS
　　　　　　//可以定义自己的CATALOG_DAO_CLASS，从而在无需变更太多代码
　　　　　　//的前提下，完成系统的巨大变更。
String className =(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
　　　　　　catDao = (CatalogDAO) Class.forName(className).newInstance();
　　　　} catch (NamingException ne) {
　　　　　　throw new CatalogDAOSysException("
　　　　　　CatalogDAOFactory.getDAO: NamingException while
　　　　　　getting DAO type : \n" + ne.getMessage());
　　　　} catch (Exception se) {
　　　　　　throw new CatalogDAOSysException("
　　　　　　　　CatalogDAOFactory.getDAO: Exception while getting
　　　　　　　　　　DAO type : \n" + se.getMessage());
　　　　}
　　　　return catDao;
　　}
}
CatalogDAOFactory是典型的工厂方法，catDao是通过动态类装入器className获得CatalogDAOFactory具体实现子类，这个实现子类在Java宠物店是用来操作catalog数据库，用户可以根据数据库的类型不同，定制自己的具体实现子类，将自己的子类名给与CATALOG_DAO_CLASS变量就可以。
2.2 应用框架
 框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。
可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。
构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。
框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。
应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。
应用框架强调的是软件的设计重用性和系统的可扩充性，以缩短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。
2.2.1 Spring Framework 
Spring是一个解决了许多在J2EE开发中常见的问题的强大框架。 Spring提供了管理业务对象的一致方法并且鼓励了注入对接口编程而不是对类编程的良好习惯。Spring的架构基础是基于使用JavaBean属性的Inversion of Control容器。然而，这仅仅是完整图景中的一部分：Spring在使用IoC容器作为构建完关注所有架构层的完整解决方案方面是独一无二的。 Spring提供了唯一的数据访问抽象，包括简单和有效率的JDBC框架，极大的改进了效率并且减少了可能的错误。Spring的数据访问架构还集成了Hibernate和其他O/R mapping解决方案。Spring还提供了唯一的事务管理抽象，它能够在各种底层事务管理技术，例如JTA或者JDBC事务提供一个一致的编程模型。Spring提供了一个用标准Java语言编写的AOP框架，它给POJOs提供了声明式的事务管理和其他企业事务--如果你需要--还能实现你自己的aspects。这个框架足够强大，使得应用程序能够抛开EJB的复杂性，同时享受着和传统EJB相关的关键服务。Spring还提供了可以和IoC容器集成的强大而灵活的MVC Web框架。
2.2.2 WebWork 
WebWork是由OpenSymphony组织开发的，致力于组件化和代码重用的拉出式MVC模式J2EE Web框架。WebWork目前最新版本是2.1，现在的WebWork2.x前身是Rickard Oberg开发的WebWork，但现在WebWork已经被拆分成了Xwork1和WebWork2两个项目。 Xwork简洁、灵活功能强大，它是一个标准