【IT168 技术文章】

    人们总是偏爱“大词”。一个表达方式，如果听起来足够响亮，写在纸上能够吸引眼球，那就会变成很多人的新宠。但同样是这些大词，经过太多人的传递、消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：几乎没有人知道这些说法到底是指什么了。在IT业界，“平台（platform）”、“框架（framework）”、“构架（architecture）”等等就是这种人见人爱的大词。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。久而久之，这些说法似乎适用于各个领域、各个层面：所有的软件系统都是“平台”，所有的开发者都在自矜于独有的“框架”。原本有确切意义的“好词”，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords”，供市场营销人士们玩味了。

　　我想让这些词中的一个——“框架”——荡污涤垢，重现青春。要完成这样的任务，必须动用重典才行。软件业圣经《设计模式》对框架有如下定义：“A framework is a set of cooperating classes that make up a reusable design for a specific class of software（一个框架，就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计）”。这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这个词的核心含义：框架是软件系统的设计、开发过程中的一个概念，它强调对以完成的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的软件系统。

　　为了更好地说明框架是什么，也许还应该看看框架不是什么。

　　框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二次开发”，实现为具体的应用系统。

　　框架不是“平台”。后者的概念更加浮泛和模糊——人们说的一个平台，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此“平台”几乎成了所有系统软件的统称。在平台的大家族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务而起作用。

　　框架不是工具包（toolkit）/类库（library） /API。目前流行的很多框架中，就包括了大量的类库和API，但是调用API并不就是在使用框架开发。仅仅使用API时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，“二次开发者”只是像做填空题一样，根据具体业务，完成特定应用系统中与众不同特殊的部分。

    框架不是构架（architecture）。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比构架更具体，更偏重于技术实现。确定框架后，构架也随之确定，而对于同一种构架（比如web开发中的MVC），可以通过多种框架（比如Apache Struts或Apache Velocity）实现。

　　那么，在企业应用系统开发中，框架具有什么样的意义？要阐明这一点，大概要看一看在这个领域里软件开发方式的演变。在计算机应用普及之前，只有少数大企业才负担得起企业信息系统软件，这一类的软件开发也已委托定制（custom-made software）为主。在企业信息化基础设施逐步完备之后，多数中、小企业也要在预算不高的前提下实施企业应用系统，按照以前的方式逐个定制开发，是这种类型的企业难以承受的。因此，对于一些需求简明的系统，往往会购买现成软件（shrink-wrapped software）解决问题。但是各个企业具体业务不同，需求很难统一，现成软件只能满足最通用的情况和最一致的操作（比如财会系统、网站内容发布系统等），对于头绪众多的业务处理就难以胜任了。

　　如何最大程度地萃取不同企业应用系统的共性，重复使用已经完成的设计和代码，对企业应用系统中典型场景给出非常好的解决方案——这是一个“一般性”的问题；如何让一个早先完成的软件产品贴切地适应极为多变、复杂的企业需求——这是一个“特殊性”的问题。作为对这一组冲突的一种解决方案，不少厂商推出了自己的企业应用框架。这些框架往往是从大量的委托项目开发中精选出的系统“不变项”，因此具有很强的普适性和实用性。

　　目前，主流企业应用框架中大都包含对以下问题的现成解决方案：

　　* 持久性（persistence）：实现数据存储、处理，数据与对象映射，数据缓存（caching）。
　　* 事务（transaction）：确保一组关联操作正常、完整的执行。
　　* 安全性（security）：保证系统的通信安全、数据安全。
　　* 负载均衡（load balance）：在大量并发访问时，保持系统可用。
　　* 监控（system monitoring/management）：监控系统运行状况，设置系统参数。
　　* 日志（logging）：记录系统运行情况和异常，记录特定用户操作。
　　* 应用集成 （application integration）：与其他系统、应用程序集成。
　　* 认证/权限/组织角色管理（authentication/authorization）：管理系统用户、组织职权结构，限制特定用户对特定功能、特定数据的访问。
　　* 业务模型（domain model）：管理系统中业务对象的属性、字段。
　　* 业务逻辑（business logic/rules）：实现业务规则和业务逻辑。
　　* 工作流（work flow）：实现多用户、多环节之间的业务处理流程。
　　* 文件管理（file management）：管理文档，实现系统内部的文件传递。
　　* 报表/打印 （reporting/printing）：实现数据打印，实现报表的定制和输出。
　　* 门户/信息发布 （portal solution）：发布企业相关的信息、新闻，提供企业客户的访问入口。
　　* 通信（communication/messaging）：系统内部的消息、通知；系统与外部角色（比如企业客户）之间通过不同通信媒介（电话、网站、邮件等）的互动。
　　* 特定行业/领域模块 （business modules）：实现特定行业、流域相关的业务模块。

　　以上诸方面中，除了前四项目前主要由应用服务器解决之外，其他的部分本身都是专门的软件开发领域。框架的作用，在于确定上述每种因素的具体技术实现，并规定它们在系统中的组织方式和协作方式，从而给出完整的企业应用解决方案。

　　企业应用框架的特点首先是，当应用框架确定之后，系统的整个构架，也就是主体结构就已经固定。因此框架的选取往往是方案选型的首要问题。

　　其次，人们常常听信“组件式开发”的一面之词，认为系统搭建的过程类似于搭积木，好像是用胶水代码（glue code）拼合现成的组件或模块。其实采用框架开发时，系统的构建过程更类似于填空——系统骨架早已完成，开发者填写特定的代码，由系统来调用。《设计模式》中提到的“好莱坞原则（the Hollywood principle——Don't call us, we'll call you）”，非常符合我们谈的这种情况。很多框架还允许下游厂商开发系统插件（plug-ins），以满足特定需要——这是另一种形式的“填空”。

　　另外，对于实现具体应用系统的二次开发者来说，不少任务都无需通过编程实现。比如要给一个业务模型增添一个新字段，或是要设置一种新的工作流程，这些工作都可以通过简单的图形用户界面（GUI）操作，或是修改部署描述符（DD），或是编写脚本来完成。也就是说，相当多（而不是全部）的开发任务是通过声明/配置的（declarative），而不是编程的（programmatic）的方式实现的。系统往往会在启动或运行时载入相关的配置，据此实现特定的功能。