SaaS系列介绍之十四: SaaS软件开发分析

1 引言

　　真正的问题，不是电脑是否具有思考能力，而是人类是否具有这种能力

　　                    ________B.F.Skinner《计算机科学》

　　SaaS模式不一样于传统软件不只仅体如今运营的服务上，同时在软件开发的方式和技术上也有很大的不一样。

　　如何开发SaaS软件，开发SaaS软件将用到哪些技术这都是咱们要研究的主要内容。

　　2 实现SaaS软件的关键技术

　　l SOA技术

　　SOA与SaaS被被称做挛生姐妹确实并不为过，SOA与SaaS是现代软件服务领域的二架马车，它们奔蹄狂奔、并驾齐驱。

　　面向服务架构(SOA)最先是由Garnter公司在上世纪90年代末提出的概念，强调服务的重要性。国内大多数消费者是经过SOA领域的老大IBM的宣传逐步对其认识和理解的。

　　随着时间的推移，应用软件开发厂商向SOA领域涉及的程度愈来愈深，如今能够绝不夸张地说，SOA已经无处不在。随着SaaS的愈发火热，SOA的继续深刻，2007年12月微软率先在业界提出了“软件+服务”(S+S)战略，旨在打通“内部业务整合(SOA)+外部业务拓展(SaaS)+丰富用户体验”等多重资源，将“软件”和“服务”有机地结合在一块儿，达到IT价值的最大化，实现SaaS和SOA“鱼和熊掌兼得”。

　　根据微软在一份技术白皮书中作出的定义，“软件+服务”是一把“IT大伞”，它综合了不少IT现有的技术和理论，包括SaaS、SOA和Web2.0。随着不一样厂商从不一样的切入点切入，整个IT业正在托起”软件+服务”这把大伞，走向IT将来之路。

　　“IT环境的日益复杂，使得人们对科技产品的需求不断增长，将来10年的科技发展趋势已经昭示，单1、模式化的技术产品或服务将不能知足社会经济的发展需求，全球科技生态系统将向多元、动态、服务性等方向健康发展”。微软院士、微软CTO办公室成员DonaldFerguson认为，在服务领域，用户能够买前试用，按需支付;在软件领域，用户有彻底的掌控权--自行定制、一次性支付，想用多久就用多久。用户若是选择了纯软件或纯服务的途径，实际上就等于放弃了另一方面的优点。“S+S”能够很好地解决这一问题。“S+S”的理念针对用户的多种需求，既可选择得到服务，也可选择继续拥有软件，或两者兼得。

　　“SOA对那些开展SaaS的软件厂商而言也至关重要”。Interarbor Solutions有限公司首席分析师Dana Gardner指出，缘由在于SOA能帮助其更有效地进行应用程序软件的传递。并且，与传统的打包应用软件厂商相比，他们从价格方面得到了竞争优点。

　　微软中国首席技术官李志霄博士表示，软件与服务在“S+S”中扮演了互补的角色，2008年将是微软对“S+S”战略加紧布局的重要一年。另据SAP Business ByDesign总监刘钦中透露，SAP也将在2008年大变脸，以SOA架构产品拓展SaaS新渠道，从而得到SaaS和SOA的双重收获。

　　l 云计算技术

　　SaaS做为应用软件的一种全新的销售方式已经开始蓬勃发展起来，可是随着SaaS软件客户的增加，网络存储和带宽等基础资源就会逐步成为发展的瓶颈，对众多企业来讲，自身计算机设备的性能也许永远没法知足需求，一个简单的办法是采购更多、更先进的设备，随之而来就是设备成本急剧增加，利润随之下降，有没有更加经济有效的解决途径呢?“云计算”的出现也许为这个问题的解决推开了大门的一个缝隙。

　　云计算(Cloud Computing)是基于互联网的一种新兴的共享基础架构的方法，一般为一些大型服务器集群，包括计算服务器、存储服务器、宽带资源等等。它利用高速互联网的传输能力，将数据的处理过程从我的计算机或服务器移到互联网上的服务器集群中，这些服务器集群由一个大型的数据处理中心管理着，数据中心按客户的须要分配计算资源，将巨大的系统池链接在一块儿以提供各类IT服务。以达到与超级计算机一样的效果。云计算将全部的计算资源集中起来，并由软件实现自动管理，无需人为参与。这使得企业无需为繁琐的细节而烦恼，可以更加专一于本身的业务，有利于创新。

　　一般状况下，SaaS供应商更专一于软件的开发，而对网络资源管理能力较弱，每每会浪费大量资金购买服务器和带宽等基础设施，但提供的用户负载依然有限，而云计算提供了一种管理网络资源的简单而高效的机制，其分配计算任务、工做负载从新平衡、动态分配资源等等，能够帮助SaaS厂商提供不可想象的巨大资源给海量的用户，SaaS供应商能够再也不服务器和带宽等基础设施上浪费本身的资源，而专一于具体的软件开发和应用，从而达到最终用户、SaaS、云计算三方的双赢。

　　因而可知，云计算在企业软件市场上具备至关大的潜力，对于SaaS供应商来讲也是一大机遇，他们能够选择云计算平台，使用云计算的基础架构，使用及其低廉的价格为海量的用户群提供更为稳定、快速、安全的应用和服务。

　　要快速掌握云计算的概念的话，咱们能够用网络架构图上的那朵云的概念来类推。在网络架构图上，一般以云来把因特网联机架构给隐藏起来，就不需理解联机的复杂性，而能以简化的概念来沟通;云计算的概念，则是要把运算系统的复杂性给隐藏起来，让开发者能够没必要了解提供运算资源的系统架构为什么，只要把运算的数据丢进系统，最后系统就会传回结果。

　　云技术能够算是网格技术的一个子集合，二者目的相同，都是要把系统的复杂性隐藏起来，让使用者只要使用而不须要了解系统内部如何运做。

　　l Ajax技术

　　Ajax(Asynchronous javascript and XML)是一组开发Web应用程序的技术，它结合了JavaScript、XML、DHTML和DOM等编程技术，可让开发人员构建基于Ajax技术的Web应用，并打破了使用页面重载的惯例。它使浏览器能够为用户提供更为天然的浏览体验。每当须要更新时，客户端Web页面的修改是异步的和逐步增长的。这样，AJAX在提交Web页面内容时大大提升了用户界面的速度。在基于AJAX的应用程序中没有必要长时间等待整个页面的刷新。页面中须要更新的那部分才进行更改，若是可能的话，更新是在本地完成的，而且是异步的。让用户享受SaaS应用服务的同时能够实现页面的局部刷新，使用基于浏览器的B/S软件像象使用传统的C/S软件同样习惯、流畅。像Ajax这样的应用正不断透过SaaS使用到软件行业中来。

　　l WebService技术

　　Web Service是一种以SOAP为轻量型传输协议、以XML为数据封装标准、基于HTTP的组件集成技术。

　　Web Service主要是为了使原来各孤立的站点之间的信息可以相互通讯、共享而提出的一种接口。Web Service所使用的是Internet上统1、开放的标准，因此Web Service能够在任何支持这些标准的环境(Windows，Linux)中使用。它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操做性，从而使存在的应用程序可以被普遍的用户访问。

　　Soap技术是Web Service的核心，它以XML的标准格式封装数据包，其中封装的沟通讯息是以文本方式来表达的，而且遵循标准的封装规则。这意味着任何组件模型、开发工具、程序语言和应用系统只要支持XML和文本格式的数据，就能够顺利的使用该技术。而如今全部组件模型、开发工具、程序语言、应用系统和操做系统都支持XML和文本格式，固然就能够彻底支持Soap了。

　　在SaaS软件中，Web Service提供组件之间相互沟通的机制。Web Service技术将极大提升系统的扩展性，使各类不一样平台、不一样开发工具的应用系统无缝集成起来。同时，做为Web Service技术核心的Soap是一个开放的标准协议;它不只突破了应用壁垒，并且可以结合企业防火墙和内部信息系统，同时提供安全和集成的应用环境;容许企业封装任何自定义信息，而不须要修改应用系统的源代码，提供了强大的系统弹性。

　　l 单点登陆技术

　　对现代网络应用易用性的基本要求之一，至少在咱们系统内部，咱们要作到用户一次登陆，便可访问全部他有权访问的全部子系统。

　　Single Sing On(单点登陆)就是要实现经过一次登陆自动访问的全部受权的应用软件系统，从而提升总体安全性，并且无需记忆多种登陆过程、ID或口令。

　　在WebService 环境中，单点登陆扮演着很是重要的角色。在WebService环境中，各式各样的系统间须要相互通信，但要求每一个系统都维护彼此之间的访问控制列表是不实际的。用户也须要更好的体验以不须要繁琐的屡次登陆和身份验证来使用一个业务过程当中涉及到的不一样系统。在WebService的单点登陆环境下，还包含这样一些系统，它们有着本身的认证和受权实现，所以须要解决用户的信任状在不一样系统间进行映射的问题，而且须要保证一旦一个用户被删除，则该用户将不能访问全部参与的系统。

　　SAML是一个将认证和受权信息以XML格式编码的标准。一个Web Service所以可以从一个SAML兼容的认证和受权服务中请求并收到SAML断言，并据此验证和受权一个服务请求者。SAML能够用来在多个系统间传递信任状，并所以被用于单点登陆的方案中。

　　3 软件工厂的产品线生产

　　经过应用重要的新方法可以克服阻碍从技术到生产转变的经济和技术问题，这些方法在对付复杂性和变化方面采起了新的方式。这些新的方法目前也存在，同时在商业产品方面表现出了明显的潜力，尽管它们大多数还不成熟。主要在四个方面：系统重复利用、组装开发、模型驱动开发、过程框架。让咱们逐一进行考虑。

　　l 系统重复利用

　　软件开发中一种最重要的新方法是定义软件产品族，它们的成员在变化，可是却共享着许多共性的特征。像Parnas，这样一个族提供了一种环境使成员中共性的问题可以集体解决。经过识别和区别特性，这些特性或多或少的存在于多产品和那些变化中，咱们可以采用一种系统的方法去重复利用。一个软件产品族由组件或整个产品组成。好比，一个族应当包含不一样的应用程序投资管理，包含不一样用户管理框架，用户管理框架是由应用程序投资管理和用户关系管理应用程序使用的。

　　软件产品族是由系统整合业者(SIs)开发的，从一个用户到一个用户移植应用程序，或者改进已存在的应用程序来建立新的应用程序。他们也经过独立的软件供应商开发软件产品族，开发区域多应用程序像CRM，或者多版本应用程序经过维护和改进。他们也经过IT组织来开发软件产品族，改进已存在的应用程序，开发多关系的应用程序，或者多版本应用程序经过维护和改进。

　　l 软件生产线的实践

　　软件生产线开发软件产品族，经过标识共同特性和填写特殊领域变化的表格，使软件产品族中成员的开发变得更快、更便宜、更少的风险。而不是寄但愿于暂时的重复利用，他们系统的捕获如何开发家族成员的知识，使重复利用资产变得可能，在家族成员开发过程利用那些资产。做为一个家族的产品开发，能够重复利用需求、构架、框架、组件、测试和其余资产。

　　固然，开发一个生产线须要成本。换句话说，生产线体现了经典的成本-利益权衡。等式一边的利益不可以经过在支持有限发布的市场上生产许多备份来增长收益时，可是能够经过生产许多相关的、惟一性的产品来增长收益，如许多案例研究所述[CN01]。利用软件生产线是通向软件工业化的第一步。使它们的建立和运行变得更加便宜是第二步。图1在一条生产线上描述了主要任务的执行、工件生产和利用。

　　

　　图1 软件生产线

　　生产线开发者应用开发资产去开发软件族成员的方式正如平台开发者建立设备驱动和操做系统以供应用程序开发商使用同样。开发产品资产的一个重要的步骤是开发一个或者更多的区域模型，这些模型描述了由生产线提供的共同问题特性和描述不一样的表格。这些模型共同定义生产线的范围，被用来限定预期的软件族成员。软件族成员的需求就是源自于这些模型，提供了一种方式使需求的变化和构架的、实现的、执行的、开发过程的、项目环境的、和软件生命周期的其余部分的变化相互联系。

　　l 模型驱动的开发

　　提升抽象水平是一个重要的过程，它减小了抽象的范围，所以实现的时候也减小了开发者的控制。失去控制的损失是权力相应的增长。大多数商业应用程序开发者，好比宁愿使用更高水平的像这些用C#和.NET框架的抽象，而不是组装语言和系统调用。更高水平的抽象产生许多好处，包括更高的生产率，更少的缺陷，更易维护和改进。

　　不幸的是，咱们看到了提升抽象水平和工具很是昂贵。假如咱们可以找一些方法使它变得更快、更便宜、更容易，不过咱们可以为小的问题域提供更高水平的自动化。这就是模型驱动开发(MDD)的目标。模型驱动开发利用模型驱捕获高层次的信息，一般是非正式的表述，自动实现，或者经过编译模型来执行，或者经过它们令人工开发执行变得容易。这是重要的，由于信息目前在低层的工件里还找不到，好比源代码文件、很难进行跟踪，维护和持续改进。

　　一些开发活动，好比构建、配置和调试目前都是经过利用从源代码文件和其余实现工件中捕获的信息来实现部分或者彻底的自动化的。利用经过模型捕获的信息，MDD也可以提供更多可扩展的自动化活动，和更多自动化优化表格，好比模型调试和自动化配置工具。如下是一些例子：

　　² 平常的任务，好比从一种东西生产另一种东西，一般可以充分的自动化。好比，测试用具一般可以从用户界面模型自动生产，使页面之间进行转换以模拟用户的活动。

　　² 其余任务，好比解决工件之间的差异，可以部分实现自动化。好比，表中的列和表单的域中多是满满的问题待用户去解决，而后由用户决定自动进行校订。

　　² 适配器，好比Web service wrappers在实现技术里可以从模型到桥的差异自动生成。模型也可以用来表示，协议配置，和其余适应的集成机制。

　　² 模型能够用来定义工件配置，这些工件由配置单元组成，使配置过程自动化。模型的配置环境可以用来约束设计，以便可以正确的实现设计。

　　² 模型可以用来描述配置部件的配置，捕获操做特征的信息，好比下载平衡，失败恢复，资源分配策略，自动化管理活动，数据收集和报告。

　　l 特有领域语言

　　为了MDD，咱们再也不对一些末端语言如4GLs感兴趣，也不对用一种高水平的语言以实现全部方面的开发感兴趣。这些战略的弱点已经被充分证实。咱们也再也不对会议上提交的模型感兴趣，还有笔记。不幸的是，模型一般用来编成文件供人来用而不是计算机。这些形成了一种印象，模型不是第一类用源代码的开发工件。咱们对用工具来处理模型感兴趣，咱们也计划用一样的源代码方式去用它们。用这种方式，文档设计的模型不能用语言来表达。模型必须是准确的不含糊的。同时，为了提升抽象水平，建模语言必须着眼于小的区域而不是一种通用的编程语言。有以下要求：

　　² 语言设计的目标必须明确规定，以便熟悉领域的评审人员可以评价语言和决定它是否实现了目标。

　　² 这种语言必需要能使工做在该领域的人员可以捕获业务概念。用于开发和装配Web服务的语言必须包含一些概念如Web服务、Web方法、协议和基于协议的链接。一样的，一种语言用来可视化和编辑C#源代码必须包含一些概念(像C#那样)，好比类、成员、域、方法、属性、事件和代理。

　　² 这种语言必须让其用户熟悉其概念的名称。好比，一个C#开发人员发现一个拥有域和方法的类的模型比发现个拥有属性和操做的类的模型更天然。

　　² 语言的符号，是图片或者文字，必需要容易用来解决问题。人们平常做的事情必须容易用概念来表达。好比，它必需要容易用一种可视化和C#源代码编辑的语言来操做一个继承。

　　² 这种语言必需要有一套定义好的规则，叫作语法，管理组成概念的表达式。这样使得用工具检测表达式是否正确变得可能，同时帮助用户写概念。

　　² 每个表达式的语义都必须定义无缺，以便用户能建立其余人也理解的模型，工具可以从模型中产生合法的实现，从模型中捕获的元数据当用来处理任务时可以作其所指望的事情，像配置服务器。

　　知足这些标准的语言称为领域专用语言(DSL)，应为它为那些特殊领域概念进行建模。DSL比通常的建模语言更加严格。像一种编程语言，它也有文字或者图片符号。SQ和HTML就是DSL的两个例子，分别为关系数据定义和Web页面定义服务。

　　图2是两个说明DSL的图示的例子，是Microsoft Visual Studio 2005 Team System的一个屏幕截图。左边的DSL描述了组件，像Web服务。它被用来实现组件开发和配置自动化。右边的DSL描述了数据中心的逻辑服务类型。它被用来设计和实现数据中心配置。Web服务开发是经过把服务部件拖到逻辑服务器上。逻辑服务器上资源需求和可用之间的不一样，充满了确认错误和图示。

　　

　　图2 领域专用语言

　　l 增量代码生成

　　高效代码生成的关键是少生成概念上差异小的代码。这样就能够容许工具利用平台特色，生产集中的、高效的、平台特性的实现。一种使代码生成增长更多的方式是让模型更切近平台，如图3所示。好比，用编程语言类型系统定义的专用编程语言比使用类型系统定义的建模语言能实现更加真实的建模。这个模型如今变成了一个代码视图，开发者图形化操做程序结构像操做类和方法定义同样。这个工具体现了在代码中难以看到的关系和依赖，节省了为程序结构生成代码的时间和努力。它使得实现了像基于关系收集的编程风格，或者提供高级的特性像重现和模式构造、应用和评估。

　　

　　图3 SaaS运营人体关系群

　　固然，经过限制在可用的平台上进行抽象，这减弱了建模的做用，或者做用不大像编程风格。那咱们如何工做在较高的抽象层呢?咱们使用了更加抽象的模型，经过框架或者转换使平台和模型更紧密，如图4所示。让咱们逐一看看这些。

　　

　　图4 编程语言建模

　　使用高层抽象

　　² 咱们能够用框架去实现模块中的高层抽象，用这些模块在框架扩展点去生成小段代码。相反，模型帮助用户完成框架经过可视化框架概念和用直觉的方式体现扩展。当开始用微软的操做系统时，好比构建图形应用是困难的。随后，Microsoft Visual Basic经过表单和控制概念使得图形应用变得更加容易。

　　² 咱们能够建立更低层次的DSL描述语言，代替构架或模型语言。为了领导这种革命性的变革，咱们还能够利用两个以上的DSL描述语言跨越更宽的跨度，用最高层次的DSL语言描述的模型能够经过提炼转换成可执行的软，如图4所示。这说明了编译器如何工做，如何将高级语言像c#和java转换成中间代码像字节或IL，经过JIT编译成目标平台的二进制格式。

　　l 组成机制

　　固然，手写的代码必须一般和框架代码结合产生一个完整可执行程序。一些不一样的机制能够用来作这些东西。它们之间重要的区别是帮定时间。

　　

　　图5 设计时间的组成

　　运行时绑定的两个优势是，经过接口使手写代码和框架代码结合起来，容许经过对象置换来实现动态配置。同时，委派类容许手写代码经过再生来进行保护。一个比较小的缺点是运行时间常常是方法调用。在组件编程模型中，一些基于运行时绑定的机制很是流行，如图6所示。它们在大规模的商业产品中都很是成功。

　　² 在编译以前，在同一个工件中的设计时间主要是手写代码时间和框架代码二者的时间，如图5所示。这包括为了不用户修改框架代码的编辑经验的约束(好比，用只读区域的编辑器)。在其余工具中，用户在一个特别的窗口中添加手写代码。经过异步回调，运行时绑定合并手写代码和框架代码。一种基于代理的运行时绑定机制经过设计模型来描述，好比、如下从Gamma，et.al.：events(Observer)，adapters(Adapter)，policy objects(Strategy)，factories (Abstract Factory)，orchestration(Mediator)，wrappers(Decorator)，proxies(Proxy)，commands (Command)?and?filters(Chain of Responsibility)[GHJV95].运行时绑定的两个优势是，经过接口使手写代码和框架代码结合起来，容许经过对象置换来实现动态配置。同时，委派类容许手写代码经过再生来进行保护。一个比较小的缺点是运行时间常常是方法调用。在组件编程模型中，一些基于运行时绑定的机制很是流行，如图6所示。它们在大规模的商业产品中都很是成功。

　　² 手写SUB类。用户提供手写代码在框架里的SUB类中。在框架代码中的抽象方法定义了显示覆盖点。好比，用户写了一个框架实体子集，域内经过模板方法模式引用了手写代码，和突出函数调用。

　　² 框架SUB类。用户在框架代码的父类中提供了手写代码。手写代码的一个抽象方法在框架代码中被重写。好比，一个框架实体域引入了关于手写代码的父类函数调用，和突出函数调用。

　　² 手写委托类。用户在委托类中提补充写代码。好比，一个框架实体在制定处调用一个手写实体，在设置属性值的以前或以后。实际上是一种代理服务器模式。

　　² 框架委托类。用户补充手写代码去得到框架服务。好比，一个手写代码实体调用框架实体去设置或者获得属性值。

　　

　　图6 运行时构成

　　² 在编译期间绑定合并手写代码和框架代码，如图9所示。在编译期间利用部分规格和编译时合并是一种很好的方式。在Visual Studio 2005中的Visual Basic和C#语言就是编译期间构成。

　　

　　图7 SaaS运营人体关系群

　　l 组装开发

　　平台无关协议领域的重要革新有，自描述，变量的封装，经过流程的组装和构架驱动的开发。

　　l 平台无关协议

　　Web服务技术成功了，早期的组件组装技术从实现技术中分离出用于特定和组装的组件却失败了。因为XML是一种管理信息的技术，不是一种构建组件的技术，Web服务利用封装去映射Web方法调用到本地方法调用，基于下面的组件实现技术。虽然CORBA试图用一种类似的策略，它的复杂性须要平台供应商的大量投资，为此也限制了它的使用范围。基于XML的简单协议明显下降了实现困难，确保它们的广泛性。经过编码远程方法调用请求像XML，它们避免了由平台特殊远程调用编码和参数集结所引发的协同工做问题。同时，经过得到普遍的工业标准承认，它们从一开始就设计了平台的协同工做能力。

　　l 自描述

　　经过改进组件包装来使推断，依赖，行为，资源消耗，性能和证实明显，自描述减小了构架不匹配的状况。它提供的元数据能够用来自动进行组件发现，选择，许可，得到，安装，调整，组装，测试，配置，部署，控制和管理。

　　自描述最重要的表格是用来描述组件推断，依赖和行为，所以开发者能够推出组件之间的交互，工具才可以验证组装。在面向对象中用途对普遍的规格表是类和接口声明。它们定义了类提供的行为，可是经过在方法签名中命名其余类和接口，仅仅说明了重要的推断和依赖。合约是一种丰富的规格说明。一个合约管理着组件之间的交互。它不知道什么时候去调用一个组件。一个合约描述了交互顺序，和响应协议非法和其余不可预知的条件。

　　固然，合约除非是强迫的不然也没有什么用。这有两种方法强制合约。

　　² 不用不匹配的合约来组装组件

　　² 用合约提供的信息去提供适配器，这种适配器使的组件之间直接交互，或者协调它们之间的交互。

　　Garlan建议使用标准适配技术菜谱和提供封装与数据转换的工具[Gar96]。一种最有但愿的适配策略是发布部分组件，这些组件可以在组装期间经过封装各个方面来完成，这些方面提供了组装须要的代码。这种策略，称之为变量封装，描述以下。

　　关于自描述的另一个重要方面是证实。假如组件可以证实仅仅有指定的依赖，消耗了指定的资源，在必定的条件下具备特定的功能特性，或者有一些公开的弱点，那么它可以推断由这些组件组装成的软件所具备的功能特性和操做特性。这已经在卡内基梅隆大学软件工程学院里进行研究，它被认为是可保证组件的可预见组装(PACC)。

　　l 变量封装

　　咱们已经看到，静态封装减小了这种可能性--一个的组件经过静态绑定其功能方面或者没有功能或上下关联的内在方面可以用于特定装配。变量封装减小了构架之间的不匹配经过发布部分封装的组件，这些组件经过利用其功能性方面来选择和编制适当的非功能性方面，使得可以适应新的上下文关系，如图8所示。在特定组装中的组件形式可以经过它位置上的上下文来决定。经过使得组件边界更有弹性，和减小构架之间的不匹配能够改进灵活性。经过移除非功能性假设，可以容许功能性部分在组件边界上进行重制。有效的调整能够预先标识，在一些例子中甚至能够经过工具来自动完成。

　　

　　图8 变量封装

　　变量封装是面向切面编程的改写(AOP)。AOP是系统的不一样方面各自进行先分离后组合的方法[KLM97]。变量封装在三个方面和AOP不一样。

　　² 变量封装编入了封装的方面，然而AOP，做为普通的实践，编入了非封装的代码行。编入非封装方面，当组装很差的组件包时产生了一样的问题，叫作构架不匹配和不可预见。的确，基于方面编入源代码更倾向于这些问题而不是组件组装，由于组件至少有描述行为和一些防止无依赖的包装。AOP缺少包装使得开发者难于推断个方面的兼容性和编入的功能特性，或者执行结果特性，几乎使得利用工具检查方面编入都不可能。

　　² 在组件开发期间AOP编入方面，可是变量封装编入却比他们晚，好比在组件组装或者配置期间。这很是重要，由于组件可能置入的上下文直到组件发布时才知道。事实上，为了支持组装开发，如文章所述，第三部分必须可以预知组装和部署无依赖的开发组件。这须要一种正式的方式去分割方面，封装方面，说明方面和包装方面。变量封装也能够是累进的，它能够在不一样的阶段发生。好比，咱们能够绑定一些方面在组装期间，一些方面在开发期间，一些方面在运行期间。

　　² 变量封装是构架驱动的，然而AOP却不是。这些从功能内核分离出来的方面必须经过接口、抽象类、WSDL文件或其余形式的合约来明显定义。

　　l 流程管理组装

　　若是有充足的合约机制，服务能够经过流程管理引擎，好比Microsoft BizTalk Server，去管理它们之间交流的信息顺序，如图9所示。流程管理组装使得组装开发更加容易，由于服务之间的依赖远比二进制组件少。不像类，它们没有必要驻留在同一个执行中。不像组件，须要平台特定的协议，它们可以经过平台边界来组装。若是它们之间的合约是兼容的，两种服务之间能够相互做用。它们能够分别开发和部署，而后经过流程管理来进行组装。假如适当的拦截重道服务可用，它们甚至可以驻留在不一样的管理和组织区域。换句话说，流程管理组装消除了不一样组件之间的设计、编译、部署时间依赖。

　　

　　图9 流程管理组装

　　流程管理组装实质上是一种仲裁，像Gamma的仲裁模式描述的那样。一个仲裁管理组件之间的交互流程。一个仲裁有强大的属性。其中一个功能是过滤或者翻译组件交互时的信息。另一个功能是控制交互，若有必要能够经过多路调用来维持状态。这容许仲裁去推断交互，若有必要能够经过条件逻辑改变它们。仲裁同时可以执行一些有用的功能，好比日志，增强安全策略，不一样技术或者同一种技术的不一样版本之间的联系。一个仲裁一样可以成为组装的功能部分，增强商业规则或者执行商业功能，好比达成商业交易。

　　l 架构驱动的开发

　　当防止组装不匹配组件好过于构建非法的组装时，那么就没有必要提高匹配好的组件的可用性。这就是架构的目标。依照Shaw和Garlan，一个软件构架描述了组件的组装，它们之间的交互和可接受的构成模式，减小了良好设计的构架不匹配和约束设计决定的风险。

　　固然，开发软件架构是具备挑战性的。这使得不少架构师花费了许多年才可以精通有限的构架风格或者应用领域。若是没有在架构实践方面明显的进步和软件构架方面更多的信任，组装开发不可以在工业规模上实现。

　　这些是架构驱动的软件开发(ADD)的目标，包括：

　　² 用于描述、复述和使用架构的标准。

　　² 用于预知设计决定效用的方法。

　　² 模式或者架构风格，它用来整理设计专家意见，帮助设计者开发组件分割再现模式。

　　一个架构风格是一个粗糙的模型，它给抽象框架提供了一组家族系统。它定义了一套指定不一样种类组件的规则，这些组件可以用来组装一个系统，不一样种类组件的关系能够用在组装中、组装时的约束中和组装的设想中。好比，一个Web服务成分风格可用来指定组件提供端口。这些成分是Web服务定义好的，经过链接端口来创建联系，只有两个端口兼容才能够链接，经过HTTP用SOAP来进行通讯。其余的架构风格包括：数据流、分层和MVC风格。一个架构风格经过提供频繁出现问题的解决方案，促进了划分和提升了设计重用，同时也有以下促进。

　　² 经过标识普通的架构元素来实现再使用，这些构架元素是基于这种风格的、被系统共享的。

　　² 经过定义标准构架来表示明白。

　　² 经过定义标准的通讯机制来提升协同工做能力。

　　² 经过定义标准的表示法来提升可视化。

　　² 经过定义强制的约束来提升工具开发。

　　² 经过标识基于这种风格的系统突出特性来分析。

　　一个构架描述就是一个定义了软件构架的文档。IEEE标准1471，被推荐用来描述密集型软件构架，提供了描述构架的指导方针[IEEE1471]。根据这些指导方针，一个系统有一个或者更多的股东。一个股东有特殊的关注和关于系统某些方面的利益。为了对股东们有用，一个架构描述必需要求有能使股东们明白的形式和结构。ADS就是一个用来描述一个系统家族架构的模板。一个正式的场景定义了一个视图，这个视图能够描述软件产品的一部分;它也提供了一种模式，这种模式用来进行描述，定义范围，目标和听众，习俗语言和用来开发它的方法。

　　这些突出的元素用来详细说明一个场景包括：

　　² 一个标识符和其余介绍性的信息(好比，做者，日期，参考文件，等等)。

　　² 与场景的利害关系。

　　² 习俗、语言和基于场景用来产生视图的方法。

　　² 确认视图的一致性和完成测试。

　　一个视图从一个给定的场景描述了一个软件产品。一个视图是语义上接近的，意味着它从那个场景描述了一个软件产品。一个视图包含一个或者多个工件，每个都根据场景需求来开发。一个视图是一个场景的实例，为了更好的成形视图必须和场景是一致的。一个视图遵循网页设计场景，好比，应该描述特殊软件产品的网页布局，应该用场景定义好的符号来描述网页布局。这些突出的元素用来详细说明一个视图包括：

　　² 一个标识符和其余介绍性的信息(好比，做者，日期，参考文件，等等)。

　　² 视图遵循的场景标识符。

　　² 用习俗、语言和场景定义的方法构建的软件产品描述。

　　为了明白视图和它的场景差异，考虑为商业应用程序进行逻辑数据库设计。逻辑数据

　　库设计是应用程序的一个视图，更确切一点，是一个构成组件的视图。应用程序方面和用来描述它的语言都在逻辑数据库设计场景中规定好了。许多不一样的商业应用程序可以规定下来，经过用相同的场景，产生了不一样的视图，每一个视图描述了一个为一些商业应用程序的逻辑数据库。这些视图可以描述一样的方面，用同一种语言，可是它们会有不一样的内容，所以每一个内容都描述了一个不一样的应用程序。一个组装视图能够从相同的场景中分解出各个组件的视图。

　　根据IEEE1471，一个架构描述必须标识所用的场景和用这些场景的原理。做为特殊目标的ADS，能够经过列举其所用的一套场景来定义。好比，一个消费者对商业的Web应用程序的ADS可能须要一个对网页布局的场景和一个对商业数据布局的场景。每个在架构描述中的视图，都必须遵循一个由ADS定义的场景。

　　l 过程框架

　　随着项目规模、地理分布或者时间而复杂度提升时，过程成熟的关键是保持灵活性。经验告诉咱们不多有结构经过减小必须的工做量增长了灵活性。这原理可以在软件产品家族中应用，经过运用过程框架去管理复杂的产品同时不减小灵活性。

　　正式过程的一些困难是它们太抽象了。它们提供的指导对于老程序员是明显的，可是对于初学者就不怎么具体充分了。为了增长使用价值，它必须下降目前项目的细节，由于每个项目在许多方面都是独特的，咱们不可能产生一种能知足全部项目的过程。咱们知道如何解决此类问题，咱们能够为一个特殊产品家族定制和裁剪出一个正式的过程。若是没有专业供应商，以上的东西是不能在市场上成功的。一些供应商为了给特殊用户定制过程，一般从其余过程如XP添加一些有用的东西。其余的，尤为是系统集成者和ISVs，裁剪过程以适应特殊的产品或者咨询性的实践。每个方式，高效使用任何过程的关键是使其对于一个给定的项目高度特殊化，以便它仅仅包含直接可用的资源。由这种定制产生的改变是很是复杂的，产生了和原来过程不多类似的结果。

　　一个高度集中的过程包括详细的项目信息，如工具配置、网络共享路径、开发者根据指导来工做、API文档、关键过程的重要联系人物的名字像CM，缺陷跟踪和处理，关于check-in的小组策略，编程风格和同等检查，还有其余的关于项目和项目小组的细节特征。和其余形式的系统重用一块儿，仅当咱们可以不止一次用它，这种定制才会有用。一样，重用高集中的过程资源经过消除工做增长了其灵活性，就如同其余的重用资源同样。如同Jacobson常说的，构建东西最快的方式是重用一些已经存在的东西，尤为可重用的资源可以定制和扩展。不少东西均可以系统地重用，开发过程也同样。

　　一个过程框架分解成一些更小的过程，这些过程附上了ADS的场景。每个小的过程描述了产生视图的需求。它可以列举出关键的决策点，标识了每一个决策点的转换联系，描述了必须和可选的活动，描述了每一个活动所需的资源和产生的产品。每一个工件处理以前都有一些约束，和一些后置条件，工件稳定时所需的不变环境。好比，咱们须要在循环开始以前获得循环条件，在退出时获得结束条件。咱们须要全部的代码都构建和测试正确。咱们称这种架构为过程框架，由于它定义了可能合并过程的空间，依赖于给定项目的需求和环境，而没有必要为全部的项目都描述一个过程。当一个过程框架定义好了，小的过程可以组合成项目所需的任一工做流，包括自顶而下，自下而上，由里到外，测试编码和编码测试，任何组合或者混合流。

　　这些工做流能够由资源来驱动，容许经过PERT和CPM来进行优化，当资源可用时启动工做流。许多种类资源能够驱动计划，包括需求和源代码，开发人员和程序管理人员，配置管理产品或者缺陷跟踪系统，像在服务器上打开一个端口或者分配存储器的设备。这称为基于约束的计划。基于约束的计划利用少许的架构需求，平衡了灵活性的需求。基于约束的计划提供了指导，在开发工件上添加了约束，而不是规定过程。灵活性的产生，能够经过一个工做流在约束中动态产生来获得，适应大量环境变量，同时总结学习经验，减小知识再发现的费用和时间。

　　一个过程框架没有必要太大或者过细，可能包含或多或少的须要的细节。这提供了一种衡量过程大小的方式，依赖于环境。好比，一个小而灵活的小组可使用小的框架，这种框架仅提供了一些主要的关键实践，如XP。一个大的组织，能够添加许多构建过程的细节，检查过程，测试过程或者组件共享规则。

　　4 小结

　　本文介绍了SaaS的开发模式。经过对实现SaaS软件的关键技术的介绍让咱们有目的性的去了解有关这方面的知识。软件工厂的产品线生产源于传统的制造业，制造业中流水线的做业是否可在软件业上应用还面临着一些问题，但真正实现软件的工厂化也不是不可能。谈到开发确定少不了系统的体系架构，软件的体系架构是主要是软件的分层问题。本节就.net与J2ee都经过实例来讲明软件的架构问题。产品的研发不只仅是技术路并且是企业的决策问题。不一样公司可根据公司实际状况采用有效并最佳的研发模式。创建并积累本身的开发体系有助于您复用代码并极大地下降开发成本。