（计算机应用技术专业论文）基于osgi的自适应软件架构.pdf

基于o s g i 的自适应软件架构 基于o s g i 的自适应软件架构 摘要 随着信息系统应用领域的发展，其应用环境日趋复杂，应用模式变化迅速。 为了解决复杂多变环境中，软件开发跟不上需求变化的问题，需要设计一套既适 合复杂应用环境又具有自适应能力的软件框架。在深入研究o s g i 规范的基础 上，采用软件架构支持增量式开发，应用服务组件相互协作和软件类对象能够自 变化的方法，来满足需求的不断变化和扩展。最终形成了基于o s g i 的自适应的 软件框架，使得软件开发能即时适应需求变化。 本论文的研究内容主要包括以下几个方面： 首先介绍o s g i 联盟的组织结构，o s g i 规范的的基本框架和特性，以及o s g i 规范在不同领域的应用案例。 其次对传统的瀑布开发模型和现行的几种常见的开发模式进行了说明和比 较，阐述了增量式开发的优点，并结合0 s g i 规范的内容来分析为何能基于o s g i 规范很好的进行增量式开发。 基于服务的应用协作是实现复杂应用模式的一个有效方法，通过服务的协作 与组合可以实现更为强大的功能。本文研究了基于o s g i 规范应该如何实现代码 共享和服务协作，以及在实现的要点和关键技术。 再次，在o s g i 规范支持增量式开发的基础之上，本文研究了如何使得软件 类对象能够自变化、自演进，从而适应需求变化。增量式开发主要是侧重于开发 过程，而类对象的自适应能是侧重于代码本身。两种的相互结合使得软件体在宏 观和微观两个层面都能支持需求变化。 最后本文通过简单的应用案例来分别说明b u n d l e 开发、添加o s o i 服务、类 对象自变化的应用。并展望了基于o s g i 的应用与 f 2 e e 体系的结合。 希望本论文的研究能够有助于软件开发中常见问题的解决，提高编程效率并 延长软件的生命周期，同时促进o s g i 规范在软件业的应用。 关键词：o s g i ，b u n d l e ，增量式开发，服务，自适应，类装载器，j 2 e e 基于o s g i 的自适应软件架构 a b s t r a c t w i t ht h ed e v e l o p m e n to fa p p l i c a t i o nf i e t do fi n f o r m a t i o nt e c h n o l o g y , t h eu s a g e e n v i r o n m e n tb e c o m e sm o r ec o m p l i c a t e da n dt h eu s a g em o d e lc h a n g e sq u i c k l y t o r e s o l v et h ep r o b l e mo f s o f t w a r ed e v e l o p m e n tc a l ln o tm a t c ht h er e q u i r e m e n tc h a n g i n g i nt h i sc o m p l i c a t e da n dd y n a m i ce n v i r o n m e n t ，w en e e dt od e s i g nas e to fa d a p t i v e s o f t w a r ef r a m et h a tw o r k si nt h i sc o m p l i c a t e da n dd y n a m i ce n v i r o n m e n t a f t e rd e e p l y s t u d yo no s g is p e c i f i c a t i o n ，w ed e s i g nas o f t w a r ef r a m e w o r kt h a tc a ns u p p o r t i n c r e m e n t a ld e v e l o p m e n t ，s e r v i c ec o o p e r a t i o na n da d a p t i v ec l a s so b j e c t f i n a l l y , t h e a d a p t i v es o f t w a r ef r a m e w o r kb a s e do no s g ii sg e n e r a t e d t h i st h e s i sm a i n l yf o c u s e s0 nt h ef o l l o w i n ga s p e c t s ： a tt h eb e g i n n i n g ，t h eo r g a n i z a t i o no fo s g ia l l i a n c e ，b a s i cc o m p o n e n t sa n d c h a r a c t e r so fo s g is p e c i f i c a t i o na n dt h eu s ec a s eo fo s g it e c h n o l o g ya r ei n t r o d u c e d t h e ni tc o m p a r e sa n dd e s c r i b e st h et r a d i t i o n a lw a t e r f a l ls o f t w a r ed e v e l o p m e n t m o d e la n dc u r r e n t p o p u l a r s o f t w a r ed e v e l o p m e n tp r o c e s s e s i td e s c r i b e st h e a d v a n t a g e so fi n c r e m e n t a ls o f t w a r ed e v e l o p m e n tp r o c e s sa n dt h er e a s o no fw h yi t w o r k sf o ro s g is p e c i f i c a t i o n s e r v i c eo r i e n t e dc o o p e r a t i o ni sa ne f f i c i e n tw a yf o rc o m p l i c a t e da p p h c a t i o n s e r v i c ec o o p e r a t i o na n da g g r e g a t i o nc a nf o r mam u c hm o r ep o w e r f u lf u n c t i o n ，i t s t u d i e sh o wt oi m p l e m e n tc o d es h a r i n ga n ds e r v i c ec o o p e r a t i o nb a s e do no s g ia n d t h ek e y p o i n t sd u r i n gt h i sp r o c e s s f u r t h e rm o r e ，i ts t u d i e sh o wt om a k ej a v a c l a s s a d a p t i v e b a s e do s g i i n c r e m e n t a ld e v e l o p m e n tf o c u s e so ns o f t w a r ee n g i n e e r i n gw h i l ea d a p t i v ej a v ac l a s s f o c u s e so np r o g r a mc o d e f r o mt h em a c r oa n dm i c r oa s p e c t s ，t h e ym a k e t h es o f t w a r e s u p p o ac h a n g i n gr e q u i r e m e n t f i n a l l y , i tu s e ss i m p l ec a s e st od e m o n s t r a t eb u n d l ed e v e l o p m e n t ，a d d i n go s g i s e r v i c ea n da d d i n ga d a p t i v ej a v ac l a s s i ta l s op r o v i d e saw a yt oj o i n to s g i a p p l i c a t i o na n dj 2 e ee n v i r o n m e n t ih o p et h er e s u l to ft h et h e s i sc a nh e l p sr e s o l v es o m ec o m m o np r o b l e m sd u r i n g s o f t w a r ed e v e l o p m e n t ，p r o m p tt h ep r o g r a m m i n ge f f i c i e n c ya n de n d u et h es o f t w a r e l i f ec y c l e a tt h es a m et i m e ，i tc a np r o m p tt h eu s a g eo fo s g it e c h n o l o g yi ns o f t w a r e f i e 】d k e y w o r d s ：o s g i ，b u n d l e ，i m c r e m e n t a ld e v e l o p m e n t ，s e r v i c e ，a d a p t i v e ，c l a s sl o a d e r j 2 e e 铺3 碰 一 苎王旦! 旦塑皂垩壁墼生塑塑 第一章序言 在2 1 世纪这个商业全球化、电子化快速发展的时代。随着通信、汽车、娱乐、 以及手持设备的发展，输入设备日益丰富，获取数据和服务的方式也越来越多， “e 这些设备通过互联网络相连，快速进行信息交互。这样复杂的应用环境无疑 使得软件功能日益复杂、规模日益庞大、开发周期更长、成本更高。并且在这样 的动态环境中，商业与应用模式变化迅速，己开发软件很快就不能适应新变化。 有的软件甚至是刚刚开发完就已经不适合应用了。为了解决这一问题，需要设计 一套具有自适应能力的软件框架，从而满足需求的不断变化。 按照达尔文进化论的观点，在这个世界上得以生存下来的物种，往往并不是 那些最强大、最智能的物种，而是那些最能适应变化、适应环境的物种p 】。同样 的观点也可适用于软件本身。开发软件的方法随着软件工程的发展有了很大的突 破但基本上都包含需求、设计与实现三部分。在传统的应用模式中，需求和应 用环境相对是比较静态的，由此开发出来的软件可以较好的满足需求，软件的适 用期也比较长。 然而现今的应用环境较之以往有了很大的变化： ( 1 ) 应用环境复杂；支持的设备很多，设备的类型也往往不一致，并且各 设备之间还有各种数据交换。 ( 2 ) 需求变化快：操作模式与商业模式变化迅速，导致需求变化周期缩短。 ( 3 ) 不断有新需求、新功能：随着应用领域的拓展，新的功能与需求层出 不穷。 在这样的动态环境中，非自适应性软件不能满足上述要求： ( 1 ) 软件的构架仅仅是为了满足最亳珂的需求，难以支持在开发过程中发生 的需求变化。这些新变化要在该软件的下一次版本升级过程中才有可能添加进 来。如果软件的开发周期较长，那么该软件产品的h i j 效性将会降低很多。 ( 2 ) 当需求变化时，软件结构难以迅速变化以适应需求变化。软件代码的 可重用性与可适配能力差。在软件的使用过程中，往往会产生新的需求。非自适 应性软件不容易在现有软件架构基础上迅速调整以适应和支持新需求，所以其软 件在版本升级的开发过程中往往代价较大，有时甚至需要推翻原先架构。 基于上述的分析，我们首先要求软件系统能够适应复杂的应用环境，而o s g i 规范则是一个不错的选择。o s g i 规范适用于居家、交通、电信、工业等行业， 支持移动通讯设备、汽车、嵌入式设备、家庭网关、个人电脑、高端服务器等设 备。并且o s g i 规范可以使得运行于不同设备的功能服务进行相互协作。 其次，要求软件系统能够在丌发周期内能够适应和支持需求的变化。也就是 说软件的开发模式要能支持增量式开发。从比较大型的r a t i o n a l 统一过程( r u p ) 基于o s g i 的自适应软件架构 到流行于小型软件开发组织的敏捷软件开发方法，这些较新的软件工程学理论， 采用不同的方法使得软件开发过程以迭代的方式进行，并且在每一次小的迭代过 程中添加最新的变化。当整个软件开发过程结束时，软件产品包含了最新的需求。 o s g i 规范在设计的时候，已经将模块化、组件化等适合增量式演进的现代软件 开发方法融入到其架构与具体的规则中，确保了基于o s g i 规范的软件体可以很 好的采用支持增量式开发的现代软件工程学。 最后，要求软件系统在一个开发过程完成后，能够支持生产使用过程中产生 的需求变化。一个具体软件系统本身有一个成熟过程，只有通过几次开发与使用 交替的过程后，软件系统才能逐步达到适合应用环境的真实需求的程度。一个软 件系统的功能在这样过程中逐步被细化、丰富和完善。如果在每次的版本升级开 发中都能够最大限度的利用已开发软件的架构、功能模块和代码，同时很好的保 证软件代码的质量和清晰度，那将大大节省软件开发和维护的成本。利用o s g i 规范的代码重用机制和服务协作机制可以迅速的通过功能重组来添加新的服务。 并且在此基础上我们设计了一套软件框架使得j a v a 类对象能够自动适配成新对 象，从而可以扩展已开发代码的功能。这两者的结合使得软件体能够很好的支持 版本升级的需求。 基于o s g i 的自适应软件架构 2 1 0 s g i 联盟 第二章0 s g i 简介 o s g i 联盟成立于t 9 9 9 年，它的目的是为了创建、推进和提升工业界对开放 服务和管理平台的采用。o s g i 联盟是服务提供者、开发者、生产商以及消费者 这个协作系统的焦点。作为一个独立的非盈利性质台匀组织，o s g i 联盟也为其所 有的成员公正而统一的创建和发布o s g i 规范标准、参考实现以及测试用例等f ”。 基于o s g i 规范的技术鼠前已经应用于很多全球f o r t u n e 榜排名前1 0 0 名的 公司的产品与服务中。o s g i 为居家、交通、电信、工业等行业提供了一个理想 的水平软件集成平台。并且这样的集成不仅可以是某一行业内部的，而且可以是 跨行业的集成。 o s g i 联盟的主要组织结构如图2l 所示： 玉巫豆垂亘互 j 亟亟至亟三 王堕亘垂垂二 ! 至垂堕亟圈 至堕亘豆至堕习 图2 1o s g i 联盟组织结构 除去管理机构外，o s g i 联盟中技术与市场组织对o s g i 规范的发展起很大 的作用。现简要介绍如下： 核心平台专家组：简称c p e g ，该专家组为o s g i 平台制定规范和应用 编程接口( a p i ) 。c p e g 主要关注构成o s g i 执行环境的组件，并提供 适合所有o s g i 执行环境的基础服务，比如曰志、安全等服务。 交通专家组：简称v e p ，该专家组的主要工作是裁剪和扩展o s g i 核心 规范的内容，使之适用于交通运输行业，它主要从汽车、运输公司中获 取需求，以确保o s g i 规范能适用于该领域。 通讯专家组：简称m e p ，该专家组的主要工作是裁剪和扩展o s g i 核心 规范的内容，使之适用于通讯行业。m e p 在技术方面的工作主要包括确 基于o s g i 的自适应软件架构 定通讯服务需求、功能模块规范、数据格式、传输协议等内容。 市场工作委员会：该委员会的主要目的是对o s g i 平台进行市场推广， 它的主要工作是每年举行三次成员大会：向业界进行信息发布和产品展 示等。 市场需求委员会：该委员会以市场需求文档( 简称m r d ) 的形式记录 了市场对于o s g i 联盟的需求，它是制定o s g i 规范的依据，并被用于 跟踪o s g i 规范是否符合市场需求。m r d 是仅向o s g i 联盟成员发布的 内部文档，不对外发布。 2 20 s g i 规范 o s g i 规范是由o s o i 联盟制定的，并且随着市场需求与技术演进的进程在 不断的更新，其最新版本是2 0 0 5 发布的第4 版。目前包括i b m ，h p ，c i s c o ， i n t e l ，s u n ，m o t o r o l a ，n o k i a 等在内的1 0 0 多个公司声明支持该规范。o s g i 的系统架构如图2 2 所示。o s g i 规范中定义的几个主要组成部分有【5 l ： ( 1 ) b u n d l e ：提供一定功能或服务的代码和文件。这些功能可以通过代码共 享或者对象共享的方式提供出来。而对于非代码文件，刚可以通过数据流或者信 息流的方式析出给应用。b u n d l e 是o s g i 架构的基本组成单元。 ( 2 ) 系统b u n d l e ：又称系统框架，是整个o s g i 规范的核心与基础。o s g l 架构由系统b u n d l e 支撑，其他所有的应用b u n d l e 都运行于系统b u n d l e 之上。系 统b u n d l e 管理所有其它b u n d l e 的生命周期，管理由各个b u n d l e 提供的服务，并 提供元数据( b u n d l e 装配表信息) 管理、代码装载等功能。 ( 3 ) o s g i 服务：由各个b u n d l e 提供的希望被别的b u n d l e 所使用的功能， 它通过对象共享的方式注册于系统b u n d l e 。在o s g i 规范中制定了一些基本的服 务，比如h t t p 服务器服务、日志服务、x m l 服务、配置管理服务、设备访问 服务、用户管理服务、权限管理服务、j a v a 包管理服务、u r l 处理器服务等。 通过o s g i 服务，各个应用b u n d l e 可以以标准的方式实现交互与协作。 ( 4 ) o s g i 服务注册表：由系统b u n d l e 管理的，可被其他b u n d l e 查询的服 务列表。通过这个服务列表，系统b u n d l e 才能确认某个被请求的服务是否存在、 是否启动，并把这个状态反馈给当前请求的b u n d l e 。 基于o s g i 的自适应软件架构 图2 2o s g 系统架构 o s g i 规范为网络服务定义了一种标准化的，组件化告勺计算环境。主要的特 性有以下几点嘎 ( 1 ) 组件生命周期管理：指对每一组件的安装、启动、运行、停止和卸载 这些生命活动的管理，这些生命活动的转换关系如图2 - 3 所示。 为了实现对组件生命周期的管理，o s g i 规范提供了以下功能： 应用的包装格式：o s g i 采用b u n d l e 的格式来包装应用。b u n d l e 中包含 装配表信息、j a v a 代码、数据信息等。整个b u n d l e 又被压缩称基于z i p 格式的j a r 文件。 安装b u n d l e ：指把b u n d l e 本身和执行b u n d l e 所需的其他部件都装在o s g l 框架中，并准备执行。 c 启动停止b u n d l e ：已经被安装了的b u n d l e 可以被o s g i 框架启动或者 停止。启动一个b u n d l e 使得该b u n d l e 的功能和资源可被应用，而停止 b u n d l e 则停止功能并清除其所提供的资源。在一个o s g i 服务平台内， 所有的应用都在同一个j v m 中启动，这样就大大节省了内存、c p u 等 计算资源。 更新b u n d l e ：o s g i 框架首先停止已经存在的应用b u n d l e ，从而可以清除 该b u n d l e 的代码与资源。然后就更新该b u n d l e 代码。在更新完成后就重 新启动该b u n d l e 。整个更新过程不需要重新启动j v m 。 卸载b u n d l e ：在b u n d l e 的生命期的最后，通过从系统中清除b u n d l e 的代 码和资源，从卸载该b u n d l e 。 基于o s g i 的自适应软件舅构 图23b u n d l e 的状态转换 ( 2 ) 远程组件管理：通过远程管理服务来管理远端的设备与组件，并且不 限制使用何种远端通信协议。 在网络设备中，有很多都是远离系统管理者的，并且有些设备与网络的连接 不是时对保持的。在这样的情况下，0 s g i 服务平台专门设计了远程组件管理。 管理远程设备需要相应的通讯与管理协议。在面对诸如s n m p 、c m i s e 、c i m 、 o m a d m 等众多协议对，选定一种最恰当的协议并不是一件很容易韵事。 因为没有一种协议适应于所有的设备与所有应用环境，o s g i 联盟于是决定 不设定任何一转协议优先于另一种协议。如图2 4 所示，在每一个o s g i 服务平 台中都有个管理服务，并且有一个负责与远程管理系统通讯的管理引擎 ( a g e n t ) 。这样远程管理系统通过某种通讯协议与管理引擎通讯，并且将具体的 管理指令传递给管理服务，而管理服务则会调用具体的管理a p i 实现代码来真 正执行。 在不设定具体通讯协议的情况下，管理系统可以根据传输载体本身的特点来 优化性能。例如，基于g p r s 的移动电话，有很长的延迟、代价昂贵的带宽， 并且不总是在线。相反，家庭网关设备一般总是在线、有很小的延迟、带宽的费 用也很廉价。这样，适用于移动电话的协议不能利用家庭网关的优点，反之亦然。 而o s g i 远程管理模型使得这两个应用设备都可咀采用最优的协议，并其不影响 互操作性。 销9 止 一一 苎竺! 旦! 堕! 重星竺堡塑型 图2 , 4 远程组件管理 ( 3 ) 应用协作：应用b u n d l e 可以向服务注煅表注册服务。之后，剐的应用 b u n d l e 就可以使用已经注册过的服务。 现今有很多的j a v a 应用服务器存在，例如m i d p 、j 2 e e 、a v a l o n 、 p i e o c o n t a i n e r 、j m x 及其他。然而，除了o s g i 服务平台，其它所有的j a v a 应 用服务器都只是提供了一个可供应用单独运行的封闭容器。每一个应用可以调用 j a v a 运行环境中的j a v a 代码库，但是并不能为其它应用提供功能与服务。 相反，o s g i 服务平台不仅可以共享出代码，而且可以共享出服务。代码共 享相当于使得各个b u n d l e 的代码可以像j a v a 运行环境中的代码库一样使用。而 在诸如j 2 e e 这样的封闭应用环境中，每一个应用! 必须安袈所有所需的代码，即 便其中的某些代码在容器的其他应用程序中已经存在。而通过o s g i 的代码共 享，则可以使多个应用b u n d l e 使用同一段共享代码，从而大大减少存储于设备 的代码量，使得应用更小。 举例来说，很多企业应用都需要用到j a v a 消息服务( j m s ) ：一套用于企业 级后台通讯的a p i ，大概有3 0 - - 4 0 k 的代码。因为在m d p 容器中并没有提供 j m s 代码，应此在每一个需要j m s 的m i d p 应用中都需要包含这3 0 - - 4 0 k 的代 码。这就意味着如果有6 个这样的应用要运行，就大概有2 0 0 k 左右的空间被浪 费了。而在o s g i 服务平台中，稀缺的内存资源可以被节省，j m s 库可以一次安 装，然后被所有的应用b u n d l e 所共享。 除了代码共享外，o s g i 服务平台还允许b u n d l e 将某些功能以服务的形式析 出。o s g i 服务平台提供了一整套轻量级的发布、查找与绑定服务的模型。这个 模型使得o s g i 应用能够支持以服务为导向的体系架构，并且使得各个应用之间 基于o s g i 的自适应软件架构 可以以松耦合的方式进行应用协作。 在o s g i 规范中，服务这个词是有非常精确的定义的，它指得是：- - j f e e 允许 一个b u n d l e 向其它b u n d l e 提供功能的机制。一个o s g i 服务实际上是个b u n d l e 内的对象，被允许出现在其它b u n d l e 中，并被其它b u n d l e 所使用。 o s g i 服务可以是以大粒度的服务，比如h t t p 网络服务器的形式来表现， 也可以用小粒度的服务，例如在小范围内发现蓝牙( b l u e t o o t h ) 设备等。 在确定好o s g i 服务的操作接口以后，o s g i 服务可以由不同的开发商以不 同的方式实现，而对于提供相似功能的不同设备，也可以根据设备本身的特点而 有不同的实现。这样不仅能够发挥不同开发商不同的优势，充分利用设备的特点， 而且在服务的使用方式上还是统一与一致的，不影响互操作性。 o s g i 服务模型允许将个复杂的应用分解成多个小应用，而这些小应用的 交互与协作可以完成原先复杂应用所需完成的功能。举例来说，一个企业级的应 用可以有：为不同图形用户界面( g u i ) 而编写的多个u i 组件、一个商、啦处理 组件、个数据库处理组件、多个消息通讯组件等。一个企业应用的部署者可以 根据目标环境的硬件配置和应用要求，自由的组合上述不同的组件。 通过代码共享与面向服务的应用协作，不仅使得应用的开发更为简便，而且 使得应用程序更小巧、更灵活。 ( 4 ) 部署简单：在o s g i 服务平台被安装后基本上不需要在设备端做任何 的复杂的部署操作。 在个具体环境中部署一个应用程序往往是个困难的操作，并且这种困难经 常被人为的低估。因为j a v a 语言试图尽可能的对具体的硬件应用环境进行抽象， j a v a 应用程序的部署问题更是显得特别困难。部署一一个j a v a 应用程序，需要确 定：应该使用哪一个j a v a 虚拟枫( m ) ；应该妇侮配置应用参数和环境参数； 如何能确保应用程序能够被正确的启动、停止和监测。 而采用由o s g i 联盟所提供的技术则可以大大简化部署与配置过程。由于 o s g i 服务平台屏蔽了具体底层环境的差异，旦o s g i 服务平台被安装以后， 部署应用就成了一个很顺利的过程。 ( 5 ) 其他还包括对动态装载与更新、安全、策略及日志等一些基本服务的 支持。 o s g i 规范应用的范围非常宽泛，可以应用于移动通讯、汽车、嵌入式设备【6 1 、 家庭网关、个人电脑、高端服务器等领域。 2 3o s g i 应用实例 o s g i 服务平台是应用于网络设备的经优化的基fj a v a 的应用服务器。不管 笫i l 负 基下o s g i 的自适应软件柴构 可以以松耦合的方式进行应用协作。 在o s g i 规范中，服务这个词是有非常精确的定义的，它指得是：一种允许 一个b u n d l e 向其它b u n d l e 提供功能的机制。个o s g i 服务实际上是一个b u n d l e 内的对象，被允许出现在其它b u n d l e 中，并被其它b u n d l e 所使用。 o s g i 服务可咀是以大粒度的服务，比如h t t p 网络服务器的形式来表现， 也可以用小粒度的服务，例如在小范围内发现蓝牙( b l u e t o o t h ) 设备等。 在确定好o s g i 服务的操作接口以后，o s g i 服务可以由不同的开发商以不 同的方式实现，而对于提供相似功能的不同设备，也可阱根据设备本身的特点而 有不同的实现。这样不仅能够发挥不同开发商不同的优势，充分利用设备的特点， 而且在服务的使用方式上还是统一与一致的，不影响互操作性。 o s g i 服务模型允许将一个复杂的应用分解成多个小应用，而这些小应用的 交互与协作可以完成原先复杂应用所需完成的功能。举例来说，一个企业级的血 用可以有：为不同图形用户界面( g u l ) 而编写的多个u i 组件、一个商业处理 组件、一个数据库处理组件、多个消息通讯组件等。一个企业应用的部署者可以 根据目标环境的硬件配置和应用要求自由的组合上述不同的组件。 通过代码共享与面向服务的应用协作，不仅使得应用的开发更为简便，而且 使得应用程序更小巧、更灵活： ( 4 ) 部署简单：在o s g i 服务平台被安装后基本上不需要在设备端做任何 的复杂的部署操作。 在一个具体环境中部署一个应用程序往往是个困难的操作，并且这种困难经 常被人为的低估。因为j a v a 语言试图尽可能的对具体的硬件应用环境进行抽象， j a v a 应用程序的部署问题更是显得特别困难。部署一个j a v a 应用程序，需要确 定：应该使用哪一个j a v a 虚拟机( m ) ；应该如何配置应用参数和环境参数； 如何能确保应用程序能够被正确的启动、停止和监测。 而采用由o s g i 联盟所提供的技术则可以大大简化部署与配置过程。由于 o s g i 服务平台屏蔽了具体底层环境的差异，一旦o s g i 服务平台被安装以后， 部署应用就成了一个很顺利的过程。 ( 5 ) 其他还包括对动态装载与更新、安全、策略及日志等一些基本服务的 支持。 o s o i 规范应用的范围非常宽泛，可阻应用于移动通讯、汽车、嵌入式设各1 、 家庭网关、个人电脑、高端服务器等领域。 2 。30 s g i 应用实例 o s g i 服务平台是应用于网络设备的经优化的基j j a v a 的应用服务器。不管 o s g i 服务平台是应用于网络设备的经优化的基1 = j a v a 的应用服务器。不管 第】 一苎三q ! 型塑! 垩生塾堡塑塑 这些网络设备是小型的还是大型的，这些非专有的服务平台，可以应用于以下领 域【7 1 ，如图2 5 所示： 数字移动电话 汽车 远程通讯 嵌入式设备 家庭网关 工业电脑 桌面p c 高端服务器，包括主框架机。 图2 5 0 s g i 的应用领域 目前，业界已经有一些典型的基于o s g i 规范的产品用例： ( i ) 下一代智能电话( s m a r t p h o n e ) j a v a 在移动电话市场取得了很大的成功。现今，有超过2 5 0 ，0 0 0 ，0 0 0 部移动电话运行j a v a 应用。这些j a v a 应用必须遵循m i d p ( m o b i l e i n f o r m a t i o nd e v i c ep r o f i l e ) 规范。但是m i d p 只适合小应用和小游戏， 而不适合系统和商业应用。现今的移动电话生产商需要一个占用很小存 储并且灵活、可靠、可扩展的服务平台，o s g i 觌范可以满足这些需求。 当前，o s g i 联盟正在和j a v a c o m m u n i t y p r o c e s s ( j s r 2 3 2 ) 起工作， 以便在o s g i 中添加一下新的规范从而满足移动电话生产商、运营商和 企业的需要。 ( 2 ) s h e l lh o m e g e n i e 筑1 2 基于o s g i 的自适应软件架构 最近，s h e l l 公司在m o t o r o l a 、s u nm i c r o s y s t e m s 、x a n b o o 和p r o s y s t 的帮 助下，开发了一套基于o s g i 的家庭自动化系统h o m e g e n i e 。在 h o m e g e n i e 这套系统中，用家庭网关与监视器、传感器、温度控制器、 电源开关等相联。而运行于家庭网关设备内的o s g i 服务平台有s h e l l 公 司的控制中心管理【引。通过h o m e g e n i e ，s h e l l 公司可以透明的向最终用 户提过服务，在家庭网关上部署、升级、维护应用等一些技术工作都可 以通过远端的o s g i 管理平台来管理。 ( 3 ) e c l i r s e e c l i p s e 是开发源代码组织e c l i p s e 的产品。e c l i p s e 是一个集成开发环境 ( i d e ) ，最初是由毋m 公司的v i s u a la g e 产品而来。1 9 9 8 年，i b m 决 定将其开源。最初e c l i p s e 并没有采用o s g i 规范，整个e c l i p s e 的体系由 e c l i p s er u n f i m e 来管理。e c l i p s e 的体系架构从下到上依次为：r u n t i m e ， w o r k s p a c e ，s w t ，j f a c e ，w o r k b e n c h 等。 2 0 0 4 年发布的e c l i p s e3 0 版本采用了o s g i 规范，e c l i p s e 之所以才用 o s g i 规范是因为原先的r u n t i m e 只支持对插件( p l u g i n ) 的静态更新， 而o s g i 规范则具有动态更新等性能。 ( 4 b m w5s e r i e s 在汽车行业，将网络信息、网络服务与汽车本身结合起来已经是一个趋 势。这样的结合使得汽车不仅能获得路况、定位信息，而且可咀获得商 业办公、娱乐资讯等信息。b m w 在其5s e r i e s 汽车中采用了o s g i 服务 平台。b m w 之所以选择基于o s g i 的服务平台，处理集中管理，灵活 配置等优点外，更是考虑到汽车市场的广泛性。而o s g i 规范是一个开 发的标准，允许不同的实现，以及这些不同实现的兼容。 ( 5 ) i b ms m f s m l 7 是m m 开发的基于o s g i 规范的管理平台，它可以应用于p d a 、 智能手机等嵌入式平台，用以实现功能应用与服务管理。s m f 也可基于 o s g i 的管理模式实现企业设备管理等功能。 苎主旦曼91 壁堕重壁鏊生塑塑 3 1 软件工程 第三章增量式开发模型 软件工程是研究软件系统构造的计算机科学领域。我们可以将软件工程定义 为“工程在软件中的应用”。更精确地讲，m e e 标准6 1 0 1 9 9 0 的软件工程的标 准术语表将软件工程定义为：系统的、规范的、定量的方法在软件的开发、操作 和维护中的应用 9 1 。 在传统的软件生存期模型中，每个阶段都有良好定义的起点和终点，并明确 地指明下一阶段可以交付使用的内容。以瀑布型生存期模型为例( 见图3 1 ) ，它 包含如下阶段【9 】： 需求分析和规范：需求分析通常是大型软件开发项目的第一阶段。它在 可行性研究之后进行，以确切地定义软件系统的成本和效益。该阶段的 目的是识别出系统的确切需求，并用文档记录它。这种研究可以由客户、 开发人员、营销组织或者上述三者的任何组合来执行。 系统设计和规范：一旦记载了系统的需求，软件工程师可以设计个软 件系统来满足它们。有时，该阶段分成两个子阶段：结构设计和详细设 计。 编码和模块测试：在这个阶段，工程师编制出真正的代码，并将作为运 行系统提交给客户。 集成和系统测试：在这一阶段，之前开发的并经单独测试的所有模块都 必须在起，即集成起来，并作为一个整体系统进行测试。 交付和维护：一旦系统经过了所有的测试，就把它交付给客户使用并进 入维护阶段。软件初次交付后，任何变更都在这一阶段完成。 基于o s g i 的自适应软件架构 这种经典的软件开发过程的最大问题是，它将风险留到后面的阶段，并且依 次传递，见图3 2 。例如，如果任何测试揭示出系统存在的故障，我们至少必须 返回到编码阶段，也许要回到设计阶段以纠正某些错误。通常，任何阶段都有可 能揭示出前面阶段存在的问题。在出现这种情况时，则有必要返回到前面的阶段， 并重做早期的某些工作。因此清除早期阶段引入的错误要付出巨大的代价。个 早期的设计很有可能并没有注意到系统的关键需求，而在后期发现设计中的缺陷 可能导致巨额的花费，甚至是项目的失败。正如t o m g i l b 的高明之见：“假如你 不积极地解决你的项目中存在的风险，它们就会积极地解决掉你。” 1 0 】 风 险 图3 2 瀑布式软件开发的风险时间 基于o s g i 的自适应软件架构 3 2 几种增量式开发模型 3 2 1r a t i o n a l 统一过程 r a t i o n a l 统过程简称r u p 。r a t i o n a l 统一过翟是种软件工程过程。它提供 了如何在开发组织中严格分配任务和职责的方法。它的目标是：按照预先制定的 时间计划和经费预算，开发高质量的软件产品以满足最终用户的需求。r a t i o n a l 统一过程是个过程产品。r a t i o n a l 软件公司开发并维护着这个产品，并将其与 r a t i o n a l 软件公司自己的一系列软件开发工具集成。r a t i o n a l 统一过程有自己的 过程框架，这个框架可以被改造和扩展以适应采纳此方法的组织 】。 r a t i o n a l 统一过程以一种大多数项目和开发组织都能适应的形式，捕获了很 多现代软件开发中的最佳的实践。这些实践活动主要包含六个方面： ( 1 ) 迭代地开发软件。 ( 2 ) 管理需求。 ( 3 ) 应用基于构件的构架。 ( 4 ) 为软件建立可视化的模型。 ( 5 ) 不断地验证软件质量。 ( 6 ) 控制软件的变更。 其中，迭代开发是r a t i o n a l 统一过程推荐的方法( 见图3 3 ) ，通常有以下几 个原因使它优于线性开发方法即瀑布开发方法。 迭代开发可以使我们考虑需求的改变。实际上需求是不断变化的。需求 的该变和需求的扩展经常给项目造成很大的麻烦，导致不能按时交付， 赶不上进度，不能满足客户需求，以及使得开发入员灰心丧气。 在r a t i o n a l 统过程中，集成工作并不是最后结尾时的“大爆炸”；相反， 元素是逐渐集成起来的。迭代方法就是这样一个不断集成的过程。 迭代开发可以在早期降低风险，因为通常只有在集成过程中才能发现风 险或者将风险解决。在早期的迭代开发过程中，我们要检查所有的过程 构件和项目的很多方面，如工具、可应用软件、工作人员的技能等。已 发现的风险将证明不再是风险，但薪的来知风险将逐渐被发现。 当由于某种原因对产品做战略性改变时，迭代开发提供了相应的变更管 理方法侧如与已经存在的产品进行竞争。我们可以减少些系统功 能，从而提前发布一个版本，以击败竞争对手，或者可以为某个特定的 技术接受另一个卖主。 迭代玎发可以促进重用，因为它能够很容易地在设计或实现过程中确定 捕】6 基于o s g i 的自适应软件架构 公共部分，而不需要在一开始没有设计或实现任何部分时就将公共部分 完全确定。确定并开发重用部分是十分困难的。在早期迭代的设计评审 中允许构架师确定那些不容怀疑的潜在重用，然后在后续的迭代过程中 开发公共代码，并使之成熟。 因为可以在几个连续的迭代过程中不断修正错误，所以构架会变得更加 坚固。我们在早期的迭代过程中就发现了缺陷，此时产品还没有从初始 阶段过渡到细化阶段，也没有进入到最终的大量测试阶段。性能瓶颈在 还有时间解决的时候就发现了，而不至于在交付前夕引起恐慌。 开发人员可以在开发过程中不断地学习，他们各种各样地能力和专长在 整个周期中都可以充分发挥出来。测试人员可以很早就开始进行测试工 作，技术文档撰写人员可以很早就开始写技术报告，等等。而在迭代开 发中，这些工作人员要一直等待着他们工作地开始，一遍一遍地做计划 而没有丝毫实质性的进展。当产品仅仅是摆在书架上的一叠设计文档时， 测试人员又任何开始测试昵? 在评估中可以及早地发现对培训的地需求 和对额外人员的需求。 开发过程本身也在不断提高和精化。在每个迭代过程结束时进行的评估 不仅仅从产品，进度的角度来看项目的状况，还要分析组织和过程中有什 么需要改变，以便在下一个迭代过程中更好地完成任务。 曩日d 倒岫 b u s i , mh 硪瓤口 嘲u h 恻驹 n 越姻b & t i a 1 m p h n - 嘲t b n 和甓 i ；) e p l o y n l e r d ： o 嗍w - b 蝴 t o 嚆n 弘f t 蓼嚏 p 州吐m g e n m n t b w f r o m 朝t 图3 3 r u p 模型 笫17 “ 基于o s g i 的自适应软件架构 3 2 2 极限编程 极限编程简称x p 。x p 是一种轻量、高效、低风险、柔性、可预测、科学而 充满乐趣的软件开发方式( 见图3 4 ) 。它与其他方法论的不同之处在于【1 2 1 ： 它的短周期内的早期、具体和持续的反馈。 它递增地进行计划编制，这种方法迅速提供个总体计划，然后在项目 的整个生命周期内不断发展它。 它针对不断变化的业务需求灵活地对功能的实现进行计划的能力。 它依赖于由程序员或客户编写的自动测试来监控开发进度，使得系统得 以发展并及早捕获缺陷。 它依赖于口头交流、测试和源代码来沟通系统的结构和意图。 它依赖于在整个系统存在期间一直持续的进化式设计过程。 它依赖于技术水平一般的程序员之间的紧密协作。 它依赖于能同时满足程序员的短期本能和项目的长期利益的实现。 x p 项目以探索阶段开始。探索的目的是确定需求、区分各种需求的优先次 序和对需求进行评估。一旦确定了足够的需求以便能够提供将给客户带来收益的 最小系统之后，即规划第一令版本。随着时间的推移，进一步的