内容


SOA 与情景应用程序,第 1 部分

改变企业中的计算

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: SOA 与情景应用程序,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:SOA 与情景应用程序,第 1 部分

敬请期待该系列的后续内容。

引言

在过去的几年中,面向服务的体系结构得到了越来越广泛的认可,并成为支持业务转换的重要企业体系结构,面向服务的体系结构在业务流程和支持 IT 之间提供了更紧密的联系。已经有了大量文章介绍了成功的面向服务的体系结构实现采用和成功实现面向服务的体系结构的障碍方面的内容。

当企业定义和采用面向服务的体系结构计划时,专业程序员和知识员工中新出现的基层计算强调了另一种不同的开发方法。在此方法中,最了解手头业务问题的那些人员可以快速开发解决方案,省去了传统 IT 方法的开销和形式。通常由业余程序员使用迭代和协作方法开发的新型情景应用程序 (SA) 可以缩短传统的编辑–编译–测试–运行形式的开发生命周期。情景应用程序能够以更节省成本的方法更加直接地解决业务问题,抓住直接影响最终用户的 IT 部分和处理以前负担不起或处于较低优先级的领域。

本系列文章将介绍关于情景应用程序的以下主题:

第 1 部分:

  • 学习针对企业中新出现的社区驱动的情景应用程序开发的使用模式和技术,将其与更传统的、侧重于企业的面向服务的体系结构提议进行比较。
  • 解释每种技术在生命周期、技术及其社会方面的影响。
  • 了解如何在企业中使用景情应用程序改进企业计算的现状。

第 2 部分:

  • 了解 IBM SAE 是为让个人和小型团队创建临时复合应用程序以满足直接业务需求而构建的。
  • 探索构建此类环境所需的企业改变和在构建时必须解决的问题,其中包括企业数据的访问以及隐私和安全问题。
  • 介绍一些轻量级开发工具。

第 3 部分:

  • 分析几个代表性的情景应用程序,了解利用这些情景应用程序可以解决哪些各种业务问题。其中一些业务问题通常发生在业务部门 (LOB),具有广泛的代表性。其他挑战则特定于某些 LOB,但这些正是能够被情景应用程序成功解决的典型挑战。
  • 介绍作者必须为每个应用程序去克服的障碍,并提供对最终解决方案、使用的技术、工具和技能的体系结构层次的概述。
  • 了解获得的实际业务效果、最佳实践以及从每种情景应用程序得到的经验教训。

基于 Web 情景应用程序的出现

Clay Shirky 的文章“Situated Software”(请参阅参考资料中的链接)描述了一类软件,它们是“为特定的社区团队使用(而不是一般的‘用户’组)而设计的”。他认为“大多数以为大规模用户使用或者以永久使用为目标的软件一般都会已失败而告终。”。

还没有得到公认的术语情景应用程序 描述了为解决特定的情况、问题或挑战而构建的应用程序。此类应用程序的开发生命周期与传统 IT 开发的、基于 SOA 的解决方案有很大区别。情景应用程序通常由临时程序员使用较短的迭代开发生命周期构建,该生命周期通常用天或周度量,而不是用月或年度量。当使用应用程序的小型团队的需求更改时,情景应用程序通常会随即改进,以适应这些更改。重要的需求改变可能导致原有的应用程序全部废弃;在某些情况下,开发新应用程序比升级正在使用的应用程序更容易。

在企业中,“最终用户设计”这一想法并不新鲜。临时的程序员结合使用 IBM Lotus® Notes®、Microsoft® Excel 电子表格与 Microsoft Access 或其他工具来开发应用程序的情况非常普遍。这种混合开发方法的新颖之处是随着总体计算机技能的提高而使基于社区的计算大量增长、引入新技术和增加对业务需求的敏捷性。

Asynchronous JavaScript + XML (Ajax) 的出现(利用对基于 Web 的数据的便捷访问和富用户界面 (UI) 控件)以及与 Web 服务的 Representational State Transfer (REST) 体系结构样式的结合为基于浏览器的高交互性应用程序的组装提供了易于使用的操作平台。

与基于 SOA 的解决方案类似,情景应用程序很少从头开发,而是从现有构建块(或称为可用块)组装。Mashup 是情景应用程序较为有名的子集。多种简单的应用程序编程接口 (API) 和支持 Ajax 样式的 Web 组件(例如,ProgrammableWeb.com 列出的 Yahoo Developer Network 设计模式和 API)有助于此开发风格的日益普及。甚至旧的 Web 技术(如 JavaScript)也在重新复兴。

表 1 列出了在知识员工和专业开发人员中有利于普及基于 Web 的情景应用程序的因素。

表 1. 有利于普及基于 Web 的情景应用程序的因素
因素有助于普及基于 Web 情景应用程序的方式
技术和技巧(如 Ajax、REST、Atom 和 RSS 源)简介具有较低技能的用户可以快速创建高交互的应用程序和使用简单的可用格式访问数据。
全面的计算机知识大量用户可以“编程”。
采用 SOA 用户可以更方便地创建和使用由其他人创建的可用的构建解决方案。将遗留的应用程序功能组件化为可用服务,使之可用于情景应用程序。
接受基于社区的计算和协作开发人员和用户可随时共享构建块,并改进彼此的工作。
大量增加 API 和 Web 组件情景应用程序构建者拥有一个可以选择大量可用模块的操作平台。
公共域中存在大量可用的 mashup 和情景应用程序情景应用程序新手通过查看他人编写的应用程序进行学习。
较低的基础设施成本情景应用程序不需要集中部署;可以将单独的计算机用作服务器。
对业务敏捷度需求的增加LOB 不能等待较长的 IT 开发和预算周期;他们需要快速解决方案来解决他们的业务问题。

SOA 和情景应用程序的比较

一些人认为 SOA-SA 之间的关系是人为建立的。他们认为,面向服务的体系结构侧重于提供健壮的企业级解决方案,而情景应用程序是自已动手完成的应用程序,它无法通过扩展来满足企业业务需求。

还有一些人认为二者之间存在协作关系,这在一个博客日志中进行了描述,该博客日志将 Web 2.0(情景应用程序是其中的一个方面)描述为“面向服务的体系结构的大量实例”(请参阅参考资料以获得此博客日志的链接)。

我们的研究表明,尽管面向服务的体系结构和情景应用程序具有不同的开发生命周期和动机、不同的使用模式,甚至不同的支持技术,但它们也有重要的共同之处:

  • 将遗留应用程序的功能分离并公开为可重复使用的服务
  • 将软件作为服务
  • 用可重复使用和重新混合的分布式部件组合或组装新的解决方案

尽管对于面向服务的体系结构,组合的重点在后端,但是许多情景应用程序都将 Web 用作平台,通常侧重于在消费者体系结构层透明 地组合。

开发生命周期和使用模式

与通常需要数月和甚至数年的基于 SOA 的开发不同,情景应用程序的开发人员可以从改进工作效率和功能方面得到好处,并且可以缩短从确定需求到在生产中使用应用程序所需的时间。这些解决方案可以通过十分节省成本的方法解决一些紧急的业务问题——抓住直接影响知识员工的 IT 部分——并解决以前对包括在企业 SOA 项目中负担不起或处于较低优先级的领域,这些领域有时也被称为长尾(Long Tail),它是由 Chris Anderson 首先提出并得到普及的一个术语(请参阅参考资料中相关的链接)。通过采用此开发范例,IT 能够使以前被认为环境特殊的业务领域实现自动化。

与企业级面向服务的体系结构开发相反,情景应用程序可以被视为“移动的目标”,并永远处于测试状态。提出需求甚至实现需求的用户通常不是应用程序的最初作者或用户,展示了早已从企业应用程序的传统控制环境消失的社区兴趣和所有权思想。请参见表 2,了解面向服务的体系结构和情景应用程序的对比。

表 2. 面向服务的体系结构和情景应用程序开发生命周期
SOA/传统 IT 开发情景应用程序
产生价值的时间(生命周期长度)数月或数年数天或数周
开发阶段定义良好、按协议的时间表进行(但经常更新时间表)未定义阶段、里程碑或时间表

侧重于使用足够适用的解决方案来解决紧急问题
功能需求 由有限数量的用户定义

IT 需要“冻结”需求才能转移到开发

需求渐变 通常由不断变化的业务需求导致
当需求改变时,情景应用程序通常会更改,以适应业务改变

情景应用程序鼓励非预期使用
非功能需求分配资源用于解决性能、可用性和安全问题

侧重于这些需求和其他非功能需求(如可伸缩性和可维护性)通常可以开发出健壮的解决方案
很少或不关注可伸缩性、可维护性和可用性等
测试由 IT 人员和一些用户参与由用户实际使用来进行
资金投入通常与年度 IT 计划一致

需要预算审批
无正式预算

在公司 IT 的控制下开发和运行

社会方面

面向服务的体系结构和情景应用程序之间的根本区别是社会方面,也是 Web 2.0 技术潮流被广泛关注的原则(中心驱动的面向服务的体系结构也可以从中获得好处)。情景应用程序通过用户社区的反馈不断向前发展;而其存在依赖于参与的体系结构。表 3 比较了社会方面。

表 3. 社会方面——面向服务的体系结构和情景应用程序之间的区别
面向服务的体系结构情景应用程序
利益相关人LOB 的高级管理人员/公司 IT单独开发人员/自发组织的小型团队;围绕情景应用程序形成的用户社区
目标用户大型的通用团队知名个人(通常为应用程序构建者)或小型团队;吸引非特定的用户
管理集中、正式基层、基于社区
发展自顶向下的控制,以中心为驱动,依赖于可用资金投入基于用户反馈和参与

情景应用程序构建者公布了由于他们的工作和“被控制”的感觉而带来的满意度的改进。 IBM 市场调查显示情景应用程序的用户将它们视为核心价值。超过一半的用户认为它们是“任务关键型”的应用程序,称其对日常活动、部门和公司的成功“非常重要”(摘自“Changing the corporate IT development model:Tapping the power of grassroots computing”一文,2007 年 10 月;请参阅参考资料中的相关链接)。

技术

现在,我们深入了解一下促使出现情景应用程序的技术变化(表 4 进行了总结)。

情景应用程序侧重于用户体验和高交互式客户端应用程序,可随时反映技术和工具的使用。Ajax 通过利用丰富的用户界面控件和对基于 Web 的数据的访问,主要改进了 Web 应用程序响应能力和性能。Ajax 通过在服务器中检索部分页面和刷新浏览器以实现高交互性。

表 4. 面向服务的体系结构和情景应用程序的技术对比
面向服务的体系结构情景应用程序
成熟度高成熟和经验证的技术经常使用的不太成熟的新兴技术
首选技术、体系结构模型和标准Web Services Description Language (WSDL)、WS-*、SOAP、Business Process Execution Language (BPEL)、Java™ 2 Platform、Enterprise Edition (J2EE) 和 XMLAjax、REST、Atom、RSS、JavaScript Object Notation (JSON)、XML、microformats、Flash、Ruby on Rails、PHP 和 JavaScript
用户界面无侧重点侧重于富 Internet 应用程序 (RIA),使用的技术是 Ajax、Adobe Flex、Adobe Integrated Runtime (AIR)、OpenLaszlo 和 XAML Browser Application (XBAP) 以及透明模式集成
工具独立的集成开发环境 (IDE)基于浏览器

REST 体系结构样式使用统一资源标识符 (URI) 识别 Web 资源,允许平等地从浏览器、移动设备、服务器应用程序通过电子邮件和书签中的链接来访问那些资源,此编程风格对大量的客户端应用程序具有很大的吸引力。因为 REST 样式服务可以使用 Web 基础结构进行缓存,所以它们可以实现更快的响应时间。假设 REST 不需要维护通信状态,您可以改进对服务器使用的可伸缩性——可以使用不同的服务器处理初始和后续请求。

情景应用程序对企业的适用性

企业中形成的 Web 2.0 社区通常用于解决公司 IT 无法使用 SOA 满足的业务需求。尽管许多情景应用程序爱好者认为面向服务的体系结构是重型的(heavy weight),但二者也有有惊人的相似之处(本文前面的内容已经提到)。

面向服务的体系结构和情景应用程序的开发通常是由业务灵活性推动的。公司 IT 不应忽略面向服务的体系结构和情景应用程序的互补特性;情景应用程序为面向服务的体系结构提供了重要的补充,其中包括:

  • 用户关注和参与。
  • 构建高交互应用程序的技巧。
  • 有机会解决以前认为环境太特殊领域的问题。

情景应用程序的好处

通过利用企业中基于社区开发的巨大潜能,情景应用程序可以为以面向服务的体系结构实现的组织带来更广泛的好处。情景应用程序带来的机会特别多,现总结如下。

情景应用程序可以通过以下方式提高业务能力:

  • 鼓励部门和个人级别的创新——知识员工可以快速响应业务情景。
  • 在业务和 IT 实现之间消除对需求的错误传达和解释。
  • 通过更好的解决方案和授权鼓舞员工士气。

情景应用程序可以通过以下方式改进业务解决方案:

  • 创建更适于解决 LOB 问题的应用程序。
  • 满足知识员工的短期需求。
  • 满足特殊环境市场(长尾)需求。
  • 结合基于情景应用程序的战略解决方案和总体 IT 组合。
  • 以最终用户为中心和创造丰富的用户体验。
  • 使用独有的、难以再造的数据(由个人和小型团队创建)丰富 IT 数据组合;当更多人使用它们时,这些数据会变得更加丰富和“简洁”。

情景应用程序有助于提高投资回报:

  • 缩短开发生命周期。
  • 消除不需要的正式的开发活动,从而提高了生产效率。
  • 降低总体开发过程的成本。
  • 创建以前因支付不起而没有编写的应用程序。

情景应用程序面临的挑战

同时,将情景应用程序引入企业计算环境会增加 IT 部门面临的挑战,现总结如下。

IT 部门可以将情景应用程序视为“可控制的”无序状态,因为:

  • 不存在正式预算;情景应用程序是在中心 IT 控制下构建和运行的。
  • 参与型的体系结构将用户视为共同的开发者。
  • 自行开发和改进的应用程序始终处于测试状态。
  • 很少关注非功能需求,如可伸缩性、可用性和可维护性。
  • 在企业中不存在相应的采用最佳实践。

将情景应用程序的集成推向边缘,因为:

  • 控制从应用程序转移向针对到细粒度的服务和数据源。
  • 内部和外部的服务和数据源在企业防火墙内部混合。
  • 在全局范围内共享应用程序。
  • 公司必须采用 Web 作为执行业务的平台。

情景应用程序和企业应用程序的管理非常复杂,因为:

  • 存在多种开发和操作环境,如 J2EE、Linux、Apache、MySQL、PHP/Perl (LAMP) 和 Microsoft .NET。
  • 在混合环境中端到端的系统管理(例如,监视、事件分析、根源检测和补丁管理)日益困难。

情景应用程序会带来数据安全性、隐私和完整性问题,其中包括:

  • 企业数据作为一种提供者;开放企业数据源是一个慢长和复杂的过程,涉及许多利益相关人。
  • 由 LOB 和个人产生的独有数据所有权将引发数据归属问题。
  • 鼓励非特定人员对情景应用程序的使用。

总结

在企业中使用情景应用程序需要现有企业基础设施中的其他灵活性。例如,通过重复使用面向服务的体系结构计划为情景应用程序管理、操作和监控提供的服务和基础设施,面向服务的体系结构有助于减轻某些问题的危害。

正当许多 IT 部门怀疑情景应用程序对公司计算的有用性或对外部开发的 API 在防火墙中使用持谨慎态度时,IBM 的 CIO 办公室已经决定在企业中使用情景应用程序。为更好地了解采用基于社区的开发带来的挑战和机遇,IBM 的 CIO 办公室制定了称为情景应用程序环境(Situational Applications Environment,SAE)的计划。他们将 SAE 视为观察和获得最佳实践的实际实验室,图 1 中描述了 SAE。

图 1. IBM 中的 SAE 概念
SAE
SAE

请关注本系列文章的第 2 部分,第 2 部分将描述构建此 SAE 的体系结构和经验教训。下面是得到的早期业务好处的总结:

  • 围绕感兴趣的常见业务主题自发建立协作社区,从而增加资产和解决方案的重用。
  • 改进某些应用程序以包括其他和改进的功能,应用程序构建者最初并未想像到该功能。通过评论和直接贡献,使用户的应用程序对自已和他人更加有用。
  • 业务用户的需求迫使 IT 部门开放公司数据源,作为支持对数据细粒度访问的可用服务。
  • 情景应用程序开发使 LOB 能够在决定执行哪些项目以及如何完成(使用情景应用程序或传统开发)方面采用更多的控制。

在企业计算中利用情景应用程序开发和面向服务的体系结构可能从根本上将 IT 角色从解决方案开发人员转换为解决方案实现者。我们认为这是 IT 角色的必然改变。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=296802
ArticleTitle=SOA 与情景应用程序,第 1 部分: 改变企业中的计算
publish-date=03242008