框架之轻量级和重量级
框架体系知识点总结
框架体系知识点总结一、框架概述1.1 框架定义1.2 框架特点1.3 框架分类二、框架体系结构2.1 框架组成2.2 框架层次2.3 框架模式三、框架设计原则3.1 抽象原则3.2 封装原则3.3 继承原则3.4 多态原则四、常用框架介绍4.1 Spring框架4.2 Hibernate框架4.3 Struts框架4.4 框架4.5 Django框架五、框架应用实例5.1 Web开发框架应用5.2 移动端应用框架实践5.3 大数据框架应用案例5.4 人工智能框架应用场景六、框架技术发展趋势6.1 微服务框架6.2 前端框架发展趋势6.3 容器化框架6.4 人工智能开发框架七、框架体系的扩展7.1 插件化框架7.2 模块化框架7.3 可扩展性框架八、框架体系实践经验8.1 项目选择框架考虑因素8.2 框架组件选择与适配8.3 框架应用性能优化8.4 框架升级与维护以上是框架体系知识点总结的框架，接下来对每个部分进行详细的介绍。
一、框架概述1.1 框架定义框架是一种软件体系结构，它提供了开发应用程序所需的基础结构。
框架通常包括设计模式、类库、工具和其他组件，以及规定了开发过程中使用的约定和标准。
1.2 框架特点- 通用性：框架是通用的，可以用于不同领域的应用开发。
- 可重用性：框架中的组件和设计模式可以被多次使用。
- 优化性能：框架提供了经过优化的设计模式和算法。
- 易维护性：框架提供了模块化的设计，易于维护和扩展。
- 标准化：框架约定了开发过程中的标准和规范。
1.3 框架分类- 按应用领域分类：Web框架、移动端框架、大数据框架、人工智能框架等。
- 按语言分类：Java框架、.NET框架、Python框架、JavaScript框架等。
- 按设计模式分类：MVC框架、RESTful框架、ORM框架等。
二、框架体系结构2.1 框架组成一个完整的框架通常包括以下组成部分：- 核心组件：框架的基本组件和核心功能。
IPD集成产品开发体系
IPD集成产品开发体系目录1.基本介绍2.IPD框架3.IPD项目管理4.IPD-SE三个最常见的概念−Product Data Management产品数据管理，是一门用来管理所有与产品相关信息PDM PLM IPD（包括零件信息、配置、文档、CAD文件、结构、权限信息等）和所有与产品相关过程（包括过程定义和管理）的技术−Product Lifecycle Management产品生命周期管理，PLM是对产品从创建、使用，到最终报废的全生命周期的产品数据信息进行管理的理念。
−PLM强调对产品生命周期内跨越供应链的所有信息进行管理和利用。
PLM软件产品的价值重点在于与ERP、SCM、CRM的集成使用−Integrated Product Development集成产品开发，是一套产品开发的模式、理念与方法。
−IPD是E2E的开发模式，包括产品开发的组织、流程、绩效等方面.IPD是站在整个公司的角度进行产品研发体系的IBM 自身案例：通过实行IPD 改变了产品与市场的脱节的局面，使IBM 的产品重新具备了市场竞争力IBM 面临的问题IBM 对产品研发的要求研发原因缩短上市时间 市场表现产品上市时间长提高赢单的比例 销售收入停止增长提高重用度，降低成本减少中途废止项目的数量配套产品开发的项目管理方法研发费用高利润急剧下降研发损失费用高IPD的思想精髓是将产品研发从关注产品的研发过程转变为关注市场，关注满足客户需求产品开发是一项投资决策−强调对产品开发进行投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向−强调产品创新一定是基于市场需求和竞争分析的创新，把正确定基于市场的开发组织义产品概念、市场需求作为流程的第一步，开始就把事情做正确跨部门、跨系统的协同−采用跨部门的产品开发团队，通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的−就是通过严密的计划、准确的接口设计，把原来的许多后续活动并行开发模式结构化的流程提前进行，这样可以缩短产品上市时间流程−产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡1.基本概念2.IPD框架3.IPD项目管理4.IPD-SE流程Product Requirement Management DCP Decision Check Point 决策评审点 PRM 产品需求管理 CDCP Concept DCPPDCP Plan DCP概念决策评审点 计划决策评审点 RAT RMSE Risk Analysis Tool 风险分析工具需求管理Requirement Management System Engineering/Engineer Transition Decision Check PointTDCP 移交决策评审点 系统工程/系统工程师 可获得性决策评审 点ADCP Availability DCPAR Allocated Requirements 分配需求EOL DCP TR End Of Lifecycle Decision Check Point生命周期终止评审 点DR DS Design RequirementDesign Specification设计需求（开发需求） 设计规格Technical ReviewInvestment Review Board 技术评审IRB 投资评审委员会 BBIT Building Block Integration and Test 构建模块集成和测试DFMDesign For Manufacturability可制造性设计 Integrated Portfolio Management Team IPMT 集成组合管理团队Design For Manufacture and可制造性及可安装性 设计 DFMA AssemblyDFTDFX CBB Design For Testability Design for x-abilityCommon Building Block可测性设计 Integrated Technology Management TeamITMT 集成技术管理团队 工程特性专项设计 共用基础模块 PDT Product Development Team 产品开发团队 CCB Change Control Board变更控制委员会 Technology Development 技术开发团队TDTTeamCMO Configuration Management Officer 配置管理员IPD 框架投资评审委员会(IRB)市场管理MM以往策略 市场信息 客户反馈竞争对手信息 技术趋势 目前产品组合执行产制定业 品组合务策略 分析与计划 优化 业务 计划了解 市场细分 市场管理业务计划、评估绩效集成组合管理团队(IPMT)IPD 流程任务书材 料包 概念 计划 开发 验证 发布 生命周期Charter Package在研发组织设计上，IPD 把产品开发视为一项投资，通过IRB 、IPMT 、 PDT 三级组织确保产品开发能满足市场预期收益要求投资评审委员会(IRB)−制定公司战略，负责战略决策−确定投资项目的优先次序和商业目标 −批准项目投资和开发预算−授权IPMT 负责进行产品开发管理，并 检查IPMT 的工作通常一个公司会有一个IRB ； 每个独立的产品线/BU 会有 一个IPMT−关注：公司收入、投资回报、市场份 额、客户满意度… …集成组合管理团队(IPMT)−对开发项目的商业前景进行分析，并向IRB 汇报−对项目的关键评审点（DCP ）负责，对项目的继续、 停止、转向做出决策−授权PDT 进行产品开发，并对PDT 进行管理和考核 −关注：产品线收入、产品路标、客户满意度… …产品开发团队(PDT)IPD开发组织的设计是以产品为中心，由相关功能角色参与的跨部门、矩阵式架构−IRB、IPMT、PDT、LMT都是跨部门的组织，切忌把行政组织直接作为IPD定义的组织跨部门团队的好处依据各职能部门代表在项目组中的权责不同，通常可分为“轻量级”和“重量级”两种模式轻量级重量级−在项目组内是职能部门的联络人，工作任务的分配由职能部门主管负责−对项目任务的交付情况承担次要的责任−在项目组内作为职能部门的全权代表，对项目任务的交付情况直接负责−与部门主管保持必要的联系职能部门组员角色职能部门主管角色项目经理角色−给组员提供必要支持来完成项目交付的任务−必要时针对重要事项与项目经理直接沟通、协调−接收项目任务，组织相应人员完成−对项目任务的交付情况负责−负责人，直接管理组员的工作和交付情况。
spring
轻量级与重量级概念的划分
经常会有同学问到spring属于轻量级框架,还是重量框架?其实划分一个应用是否属于 轻量级还是重量级,主要看它使用了多少服务.使用的服务越多,容器要为普通java对 象做的工作就越多,必然会影响到应用的发布时间或者是运行性能.
对于spring容器，它提供了很多服务，但这些服务并不是默认为应用打开的，应用需要某种服务，还需要指明 使用该服务，如果应用使用的服务很少，如:只使用了spring核心服务，那么我们可以认为此时应用属于轻 量级的，如果应用使用了spring提供的大部分服务，这时应用就属于重量级。目前EJB容器就因为它默认 为应用提供了EJB规范中的所有功能,所以它属于重量级。
使用Spring,不再需要我们处理复杂的事务传播行为
使用Spring，我们只需要通过声明式的事务属性配置就可以轻松地实现这两种业务需求 1.要求Bean1.update()和Bean2.save()的在同一个事务中执行 2.要求不管Bean1.update() 的事务是否成功，都需要记录日志。 @Transactional(propagation=Propagation.Required) public void payment(){ Bean1.update();//更新金额 Bean2.save();//记录日志 }
使用dom4j读取spring配置文件
public class xxxClassPathXmlApplicationContext { private List<BeanDefinition> beanDefines = new ArrayList<BeanDefinition>(); public xxxApplicationContext(String filename){ init(filename); } private void init(String filename){ SAXReader saxReader = new SAXReader(); Document document=null; try{ URL xmlpath = this.getClass().getClassLoader().getResource(filename); document = saxReader.read(xmlpath); Map<String,String> nsMap = new HashMap<String,String>(); nsMap.put("ns","/schema/beans");//加入命名空间 XPath xsub = document.createXPath("//ns:beans/ns:bean");//创建beans/bean查询路径 xsub.setNamespaceURIs(nsMap);//设置命名空间 List<Element> beans = xsub.selectNodes(document);//获取文档下所有bean节点 for(Element element: beans){ String id = element.attributeValue("id");//获取id属性值 String clazz = element.attributeValue("class"); //获取class属性值 BeanDefinition beanDefine = new BeanDefinition(id, clazz); beanDefines.add(beanDefine); } }catch(Exception e){ e.printStackTrace();
C++库介绍
在C++中，库的地位是非常高的。
C++之父Bjarne Stroustrup先生多次表示了设计库来扩充功能要好过设计更多的语法的言论。
现实中，C++的库门类繁多，解决的问题也是极其广泛，库从轻量级到重量级的都有。
不少都是让人眼界大开，亦或是望而生叹的思维杰作。
由于库的数量非常庞大，而且限于笔者水平，其中很多并不了解。
所以文中所提的一些库都是比较著名的大型库。
【GUI】在众多C++的库中，GUI部分的库算是比较繁荣，也比较引人注目的。
在实际开发中，GUI库的选择也是非常重要的一件事情，下面我们综述一下可选择的GUI库，各自的特点以及相关工具的支持。
1、MFC大名鼎鼎的微软基础类库（Microsoft Foundation Class）。
大凡学过VC++的人都应该知道这个库。
虽然从技术角度讲，MFC是不大漂亮的，但是它构建于Windows API 之上，能够使程序员的工作更容易,编程效率高，减少了大量在建立Windows 程序时必须编写的代码，同时它还提供了所有一般C++ 编程的优点，例如继承和封装。
MFC 编写的程序在各个版本的Windows操作系统上是可移植的，例如，在Windows 3.1下编写的代码可以很容易地移植到Windows NT 或Windows 95 上。
但是在最近发展以及官方支持上日渐势微。
2、QT参考网站：Qt是Trolltech公司的一个多平台的C++图形用户界面应用程序框架。
它提供给应用程序开发者建立艺术级的图形用户界面所需的所用功能。
Qt是完全面向对象的很容易扩展，并且允许真正地组件编程。
自从1996年早些时候，Qt进入商业领域，它已经成为全世界范围内数千种成功的应用程序的基础。
Qt也是流行的Linux桌面环境KDE 的基础，同时它还支持Windows、Macintosh、Unix/X11等多种平台。
3、WxWindows参考网站：跨平台的GUI库。
因为其类层次极像MFC，所以有文章介绍从MFC到WxWindows 的代码移植以实现跨平台的功能。
电信API：轻量级模式重量级功能
天 ， 面 对 用 户 消 费 模 式 的 变 迁 大 潮 ，互 联 网 的 骨 灰 级 创 新 模 式 以 及 新 媒 体 的 广 泛 传 播 ，甚 至 还 有 Ｉ 厂 商 、 内 容 整 合 者 与 消 费 电 子 厂 商 向运 Ｔ 营 领 域 的 渗 透 ，运 营 商 正 以积 极 、融 合 、开 放 的 态 度 ，努 力 尝 试 开 放 其 电信 能 力 ， 发 挥 第 三
ＷＷＷ．ｔ ．ｏｍ ｒ ｇ７ ｔｍ ｃ ｃｌ
表 １ 全 球 运 营商 开 放 电信 能 力行 动
公司 计 划 说 明
ａｔ ｌ ＆
ｄ 、 ｎ ａ ｅ（ ｔ Ｉ ， ｒ
建立 了包含３ 个级别的成 员计划 、ａ＆￣ 证计划 、Ａ ｐ Ｂ ｔ客户测试与反馈计划：广 泛的设备支持 ，开 ｔｔ Ｘ ｐ ｓ ｅａ 放 消息 、定位和家长控制等电信 能力 ； 是Ｗｅ ２ Ｅ １ ｂ Ｒ ｓ仪ＭＬ Ｐ 以及Ｇ Ｍ ｅ Ｐ的支持者 ０ Ｉ Ａ Ｓ ＡＯｎ Ａ Ｉ
Ｏｒ ｇ ａ ｅ ｎ
Ｐ ｒ ｅ ａ ｎｒ ｔ
针 对多种第三 方支持的大型 计划 ，已经 有 ６ 万多名成员 ，包含两个级 别的成员 ：ＡＰ类 型广泛 ，包括 Ｉ Ｓ Ｓ Ｍ 、点击 呼叫、定位 、电子邮件 、语音 邮件和多媒体会议等 开放式发 展倡议 （ Ｄ ） Ｏ Ｉ 主要面 向大型企业开发商 ．采用的形式是对应用和设备进行认证。联 合创新实验 室 ｛ Ｉ 还吸ｇ 了Ｓ ｆ ａ ｋ ＪＬ） ｌ ｏ ｂ ｎ 、中国移动 以及沃达丰的参与 ， 在处于测试阶段 ，主要 目标在于提供开发 现 商支持 、Ｓ Ｋ Ｄ 和测试 计划、Ｗｅ ２ ￣ ｇ ｔ 用商店 ｂ ． ｄ ｅ的应 ０Ｖ
偏向锁、轻量级锁、重量级锁
偏向锁、轻量级锁、重量级锁为了换取性能，JVM在内置锁上做了⾮常多的优化，膨胀式的锁分配策略就是其⼀。
理解偏向锁、轻量级锁、重量级锁的要解决的基本问题，⼏种锁的分配和膨胀过程，有助于编写并优化基于锁的并发程序。
内置锁的分配和膨胀过程较为复杂，限于时间和精⼒，⽂中该部分内容是根据⽹上的多⽅资料整合⽽来；仅为⽅便查阅，后⾯继续分析JVM源码的时候也有个参考。
如果对各级锁已经有了基本了解，读者⼤可跳过此⽂。
隐藏在内置锁下的基本问题内置锁是JVM提供的最便捷的线程同步⼯具，在代码块或⽅法声明上添加synchronized关键字即可使⽤内置锁。
使⽤内置锁能够简化并发模型；随着JVM的升级，⼏乎不需要修改代码，就可以直接享受JVM在内置锁上的优化成果。
从简单的重量级锁，到逐渐膨胀的锁分配策略，使⽤了多种优化⼿段解决隐藏在内置锁下的基本问题。
重量级锁内置锁在Java中被抽象为监视器锁（monitor）。
在JDK 1.6之前，监视器锁可以认为直接对应底层操作系统中的互斥量（mutex）。
这种同步⽅式的成本⾮常⾼，包括系统调⽤引起的内核态与⽤户态切换、线程阻塞造成的线程切换等。
因此，后来称这种锁为“重量级锁”。
⾃旋锁⾸先，内核态与⽤户态的切换上不容易优化。
但通过⾃旋锁，可以减少线程阻塞造成的线程切换（包括挂起线程和恢复线程）。
如果锁的粒度⼩，那么锁的持有时间⽐较短（尽管具体的持有时间⽆法得知，但可以认为，通常有⼀部分锁能满⾜上述性质）。
那么，对于竞争这些锁的⽽⾔，因为锁阻塞造成线程切换的时间与锁持有的时间相当，减少线程阻塞造成的线程切换，能得到较⼤的性能提升。
具体如下：当前线程竞争锁失败时，打算阻塞⾃⼰不直接阻塞⾃⼰，⽽是⾃旋（空等待，⽐如⼀个空的有限for循环）⼀会在⾃旋的同时重新竞争锁如果⾃旋结束前获得了锁，那么锁获取成功；否则，⾃旋结束后阻塞⾃⼰如果在⾃旋的时间内，锁就被旧owner释放了，那么当前线程就不需要阻塞⾃⼰（也不需要在未来锁释放时恢复），减少了⼀次线程切换。
拳击擂台上的比赛类别
拳击擂台上的比赛类别在拳击擂台上，各种不同的比赛类别为观众带来了激烈的对决和精彩的表演。
这些类别根据选手的体重、技术水平和年龄等因素来划分，以确保公平竞争和保护运动员的安全。
本文将介绍几种常见的拳击比赛类别，包括重量级、轻重量级、中量级、轻量级和次轻量级。
一、重量级重量级是拳击比赛中最高级别的类别，也是最令人瞩目和关注的。
选手在比赛前称重，其体重上限根据不同的拳击组织或协会而异。
根据国际拳击协会（IBF）的规定，男子重量级选手的上限是200磅（约90.7公斤），女子则是175磅（约79.4公斤）。
重量级比赛往往具有极高的破坏力和威力，选手们拥有出色的体能和打击技巧。
重量级比赛也是赛场上最受瞩目的，著名的拳王如穆罕默德·阿里、迈克·泰森等都曾在这个类别中崭露头角。
二、轻重量级轻重量级是拳击比赛中肉眼可见的重量级别，选手的体重在重量级和中量级之间。
根据世界拳击协会（WBA）的规定，男子轻重量级选手的上限是175磅（约79.4公斤），女子则是160磅（约72.6公斤）。
轻重量级选手既具备重量级选手的力量，又具备中量级选手更灵活的特点。
他们通常拥有出色的技术和速度，能够在擂台上展现出多样的拳击风格，给观众带来绚丽的比赛。
三、中量级中量级是拳击比赛中体重较轻的一个类别。
男子中量级选手的上限根据不同的拳击组织而异，一般在160磅（约72.6公斤）左右。
而女子中量级的上限通常为154磅（约69.9公斤）。
中量级选手拥有灵活性和爆发力，他们可以在比赛中快速躲避对方的攻击并做出有效的还击。
在中量级比赛中，选手们会展现出精准的打击技巧和出色的身体控制能力。
四、轻量级轻量级是拳击比赛中体重较轻的一个类别，男子轻量级选手的上限一般在135磅（约61.2公斤）左右，女子轻量级的上限通常为132磅（约59.9公斤）。
轻量级选手通常拥有较高的速度和敏捷性，他们具备出色的反应能力和灵活的拳击技巧。
轻量级比赛往往非常激烈和技术性较高，选手们会以迅猛的攻击和快速的躲避技巧来争夺胜利。
轻量级锁和重量级锁的区别？
轻量级锁和重量级锁是在并发编程中用于实现线程同步的两种不同的锁机制，它们的主要区别在于锁的获取和释放的开销和效率。
1. 轻量级锁（Lightweight Locking）：
- 锁状态：轻量级锁是在对象头部分使用CAS（Compare-and-Swap）操作来实现的。
当一个线程尝试获取轻量级锁时，它会将对象头中的一部分数据复制到线程的栈帧中，并将对象头部分替换为指向栈帧的指针。
- 锁的竞争：当一个线程尝试获取轻量级锁时，如果没有竞争，它可以成功获取锁，并继续执行。
如果有竞争，那么轻量级锁会膨胀为重量级锁。
- 开销：相对于重量级锁，轻量级锁的获取和释放的开销更小，因为它不需要涉及操作系统层面的调度和上下文切换。
2. 重量级锁（Heavyweight Locking）：
- 锁状态：重量级锁通过操作系统的互斥量（Mutex）或信号量（Semaphore）来实现。
当一个线程获得重量级锁时，它会进入阻塞状态，如果已经被其他线程持有，那么当前线程就会被挂起等待锁的释放。
- 锁的竞争：重量级锁存在严格的竞争关系，当多个线程同时请求一个重量级锁时，只有一个线程能够成功获取锁，其
他线程会进入排队状态。
- 开销：相对于轻量级锁，重量级锁的获取和释放的开销更大，因为它涉及到操作系统层面的调度和上下文切换，需要更多的系统资源。
总体而言，轻量级锁在较低级别的竞争下表现良好，并且相对快速和高效。
而重量级锁适用于高度竞争的情况，它可以确保资源的独占性，但是会带来更多的开销和延迟。
具体在应用中使用哪种类型的锁取决于并发环境的性质和需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
框架之轻量级和重量级
一：基本概念：
量级主要是看容器的依赖性所决定的,依赖性越小,越轻量.
1、轻量级框架
1.定义：在Java应用程序开发环境中，“轻量级Java”主要是指两个东西：简化的编程模型和更具响应能力的容器。
轻量级Java旨在消除与传统J2EE API有关的不必要的复杂性和限制。
它也将缩短应用程序的部署时间，这对于支持开发最佳实践（比如频繁单元测试）非常重要。
2.现在比较重要的轻量级以及对终端用户的帮助：控制反转(IoC)模式在这个领域有着重大的影响。
使用IoC，开发人员不需要编写复杂的代码来执行查询、处理基础架构异常或管理连接，就能够解决对象依赖性问题。
这有助于简化代码、将业务逻辑与基础架构分离，从而使应用程序更易于维护。
轻量级Java的另一个关键特征是，它不会强迫业务对象遵循平台特定接口。
这允许开发人员在普通旧式Java对象(POJO)中实现业务逻辑,从而提高生产率。
与具体的类相反，当把开发的最佳实践与界面相结合时,这些特性也使得对代码进行单元测试容易得多。
由于业务逻辑实现在POJO中，所以不再需要将对象部署到重量级容器中以在单元测试中练习它。
因此，将对象宿主在诸如JUnit之类的简单测试环境中和为快速迭代单元测试“模拟”外部依赖性就变得微不足道了。
3.现在典型的轻量级框架：Struts、Hibernate、Spring、Beehive.....
注：感觉转向轻量级技术越来越猛了，传统的重量级EJB也推出EJB3.0也基本上是以使得轻量级Java盛行的概念为基础。
2、重量级框架
dev2dev:人们在想起应用服务器供应商时，通常把它们置于“重量级阵营”。
我想您正在努力改变这种状况，对吧？换言之，许多人认为应用程序供应商已经在实现重量级组件（比如EJB2.0）上付出了很大的代价，它们不愿意轻易放弃这些成果。
Jim:首先，我认为没有理由放弃在EJB上的现有投资，因为在某些场景中它仍然是最好的技术，例如当您希望通过RMI远程公开业务服务时。
当然，诸如EJB之类的开放标准在保护客户投资方面的价值也不能低估。
已经说过,我觉得人们经常过分强调EJB在应用服务器中的实际价值。
尽管这一点未必对所有的应用服务器供应商都适用，但是BEA只投入了相对较少的一部分开发资源来支持J2EE API。
我们工作最主要的目标是为宿主应用程序构建最可靠、可伸缩和容错的内核。
这些品质以及分布式事务服务、高速消息传递、遗留系统集成、高级Web服务、配置管理、诊断和故障排除和高级安全性，代表了WebLogic Server的真正价值，而且对总体拥有成本（TCO）有着巨大的影响。
幸运的是，这些附加值对基于Spring或Beehive的应用程序的相关性和适用性与采用EJB构建的应用程序是一样的。
虽然轻量级Java技术使得应用程序的开发和维护更容易，但是它们不会代替真正高端应用服务器的品质。
实际上，我们认为轻量级Java与WebLogic Server是一致的。
dev2dev:BEA有没有一个轻量级Java策略？BEA实现轻量级Java的方法是什么？
Jim:我们的策略是接纳所有有利于提高开发人员生产率、在市场上为部署这些技术提供最佳平台的技术。
轻量级Java 有助于降低开发成本,WebLogic Server则有助于降低运营成本,它们是一个非常强大的组合。
3、应用程序框架
dev2dev:由BEA赞助的Beehive项目显然是一个轻量级Java组件模型。
您能否谈谈关于Beehive的情况，以及它在你们的整个策略中的地位？
Jim:Beehive是一个应用程序框架，致力于使J2EE应用程序和基于SOA的应用程序的开发更容易，它基于我们发布WebLogic Workshop的经验。
它基于POJO和用于配置依赖性、服务质量等的元数据提供一个编程模型。
元数据以J2SE5.0代码注解和外部XML文件的形式获得支持。
存在一些用于访问J2EE资源、定义业务和Web服务以及基
于MVC模式开发Web应用程序的组件。
在我们努力提高开发人员生产率、巩固Java整体市场的过程中，Beehive是非常关键的一部分。
ev2dev:Beehive可以被认为是一个“应用程序框架”。
在Spring Framework中提供了一种非常流行的轻量级Java方法。
Spring（以及其他类似的框架）对于BEA有多重要？
Jim:任何能够帮助我们的客户提高生产率的东西都对我们非常重要。
我们欢迎并且接纳这些技术,在适当的时候也可以在技术层面上集成或者共享这些技术。
dev2dev:你们考虑过明确支持这些框架吗？
Jim:就像我原来说过的,WebLogic Server具有很多方面的特性，能够提供基于轻量级Java技术的应用程序。
许多都是隐含的，然而在某些情况下，最小量的集成工作就能为轻量级Java开发人员提供重要的价值。
举个例子，当今存在的一些适配器允许Spring应用程序使用WebLogic Server的分布式事务能力，无需改变任何应用程序代码。
我们正在调查许多其他的机会，当然也一直在倾听客户的需求。
dev2dev:我们已经看到轻量级框架对EJB3的一些影响。
您认为这会扩展到J2EE的其他方面吗？
Jim:是的。
我认为JSR175（即Java元数据）对于简化J2EE编程模型是一种关键的支持技术。
EJB3.0使用了它，而且它也是JSR181（即Web Services元数据，一个BEA倡导的规范）的基础。
没有理由相信它会就此停止。
4、轻量级持久性
dev2dev:IoC容器看起来是轻量级Java的中心。
另外的一个关键因素是POJO和轻量级持久性。
您能针对这个问题谈谈看法吗？
Jim:同样，共同的主题是简化编程模型。
没有比POJO更简单的了。
当然，企业开发要求我们有能力应用附加的品质,比如持久性规则、事务语义和POJO的安全约束。
盛行很广的方式是在元数据中定义这些品质，要么作为代码注解，要么放在外部文件中。
dev2dev:您是否觉得因为有多种方法用于完成持久性这样的事情而存在一些危险？比如，我们很快将会有EJB2、EJB3、JDO、Hibernate，等等。
Jim:我认为这只是成熟领域的一个实际情况。
多年来，J2EE规范没有完全涵盖这个特定的领域，自然就会导致其他规范的出现。
就我所知道的在JCP中发生的事情，我们似乎正在走向统一。
这对于整个行业来说是一件好事。
5、未来
dev2dev:您能预见一下轻量级Java和BEA的未来吗？
Jim:我们将会继续活跃于这个领域中，既通过诸如Apache Beehive、XMLBeans、Eclipse和JCP之类的渠道推动创新，又吸收诸如Spring这样的其他领先技术，并且为了客户的利益而展开协作。
6、总结
重量级的开发倒并不是指EJB或者是JNDI，很大意义上，重量级的开发都是需要依赖一个非常庞大的容器系统进行开发，在EJB的开发中，我们所有开发的内容基本都需要放置在一个容器系统中进行运行，这些容器因为基本针对大型企业应用，所以体积庞大，占用资源过多，在开发的过程中效率很低，因为使用大型容器作为开发环境的话，我们很大一部分时间都用在了Deploy、Run，这样的过程上，有时候改动一个小小的部分，需要等等很长的时间才能看到结果，如果做单元测试也比较麻烦，虽然现在有很多针对容器的单元测试框架，但是还是没有很好的解决Deploy的等待问题，所以在开发者这里，EJB逐渐失去了很多的吸引力，因为感觉实在是太笨重了。
轻量级框架的优势很大程度上是因为加速了开发的速度，我们不用部署一个很庞大的容器系统就可以实现以前需要容器才能实现的功能，我们可以使用Spring代替EJB中的Stateless Session Bean，可以使用Hibernate代替EJB中的Entity Bean，而且我们可以直接写一个Application运行已经完成的系统，马上可以看到结果，做单元测试非常的简介，不需要做太多的工作就可以构建系统，这些特性对于开发人员来说非常的有吸引力。
关于轻量级和重量级之间的论战已经由来已久了，也最终没有出现一个很好的结果，重量级框架在大规模运行的时候会表现出非常优异的性能，劣势主要是开发效率较低，轻量级框架正好相反，开发的时候非常迅速，但是在大规模运行的时候，性能比重量级框架还是有差异。
但是随着最近一些框架标准的成熟，可以有新的选择，因为不管是轻量级还是重量级框架，基本解决的是两个问题，一个是“事务控制”，一个是“持久化控制”，在JPA标准发布以后，我们看到一个很好的解决方式，“持久化”的开发可以和任何框架没有关系，直接使用JPA的标准注解即可，所以开发“持久化”部分的时候可以使用JPA进行注解，开发时期用Hibernate作为JPA的实现进行开发测试，需要上线运行的时候就可以直接部署到EJB的EntityBean上，在EJB3.0之后，已经很好进行移植部署。
关于“事务控制”，现在所有的实现方式都比较简单，针对方法进行注解事务类型即可，开发的时候可以用一个转换器将这些注解转化为Spring的映射，快速的进行开发，在上线运行的时候，直接使用EJB 的Session Bean进行部署就可以解决，这些方式实现起来并不困难，可以很好解决“重量级”和“轻量级”之间的矛盾。