单页应用或可令BPM受益

日期:2015-4-29作者:Steve Weissman翻译:boxi来源:TechTarget中国 英文

BPM   单页应用   

【TechTarget中国原创】

权衡单页面应用方法在部分或所有BPM应用中的适用性时需要考虑以下一些因素。

之所以叫做单页面应用是因为它们通过浏览器赋予用户对业务应用的完全访问,不需要加载新的页面。这样做对于用户来说结果是更快、响应性体验更好,对底层基础设施的利用也将更加高效。

其“秘密武器”是格式化信息和应用处理逻辑的页面在首次点击前就已经下载了,然后由浏览器运行脚本去执行任务。这需要调用Web服务来获取数据,否则的话就得与后端进行交互,但是不再需要更进一步的与页面展示相关的数据获取了。相反,只有受影响的页面元素需要更新,其整体效果是采用“真实”桌面客户端而非浏览器。

这一技术好处是有的,因为将浏览器与那么多的“智能”打包在一起意味着服务器的负载降低,网络流量减少。(理论上)这还意味着应用可在任何支持Web的设备上运行,相应地也可以进行管理或者开发。

实现预期好处需要进行平衡工作

你可能会想,听起来不错。那么,有什么条件呢?只有这个:视应用情况不同,可能需要花费可观的精力去让浏览器变得合适,然后还需要相当长的时间才能完成初始的下载。必须在开发单页面应用所需的工作量与采用它可能得到的好处之间进行小心的平衡—尤其是像业务流程管理(BPM)这样复杂的场景。

也许单页面应用(SPA)最简单的形式包括那些以一个长页面呈现的网站,上面还有一些链接,一旦点击则会导致某些不太复杂的功能在页面内发生(如打开一个通信录表格),而不是带你去到一个新的页面。此处脚本以相对直接的形式被触发出来,被放到了浏览器上的命令能够做的事情完全是在浏览器能力范围之内的。

另一方面,像BPM这样的应用则要复杂得多,处理放在核心的业务规则和引导逻辑的计算能力也要多得多。因此,怀疑把所有需要的功能都塞进浏览器中是否值得是合理的。

SPA还是BPM?看情况

其答案跟平常一样,基本上归结为“看情况”:要看用户预期,看你的技术基础设施,要取决于你植入的技能组合等等。以下是权衡针对全部或部分BPM应用采用SPA方案适用性时需要考虑的若干要素。

用例的性质。如果流程的步骤定义清晰且捆绑紧密的话用SPA最有意义。案例管理就是一个很好的例子,因为工作流步骤往往是清晰且可预测的。这一提供给浏览器的“指令集”可以预先定义好并且进行有效处理,这么做没有过载风险,而这种风险最终会抵消SPA本来具备的部分好处。

一致界面的需要。尤其是当大家一直使用同一工具有很长时间的时候,维护熟悉的界面外观对于简化升级或替换应用的过渡阶段来说就显得至关重要。采用SPA让你可以在很大程度保持前端界面与之前一样,哪怕后端的东西发生了改变。这一点在极大的舒适源自于“以一直以来习惯的方式做事”的流程充裕型的应用中特别重要。

浏览器支持JavaScript。SPA严重依赖于JavaScrip,所以对于那些对恶意软件及安全很敏感,要限制浏览器独立行动能力的的组织来说不是他们的选择。此外,许多浏览器,尤其是旧一点的浏览器也许并不能扛起这一重担。所以开发根本就不能在那种环境下运行的SPA几乎没什么意义。

带宽。不必持续加载页面信息意味着更少信息需要在服务器与客户端之间移动,而反过来又意味着支撑应用的带宽需求变低。这一点在发电厂建筑工地这类的地方可能会特别有用,因为这些地方基本上一开始几乎都是脱离电网的,但是又有很多流程需要执行和汇报。另一方面,会话开始是由于有那么多的页面和逻辑信息需要下载,在低带宽或带宽不稳的情况下加载该SPA可能会变得慢得不可接受。

离线的需要。在客户端运行所有逻辑意味着与服务器断开连接也没什么大不了。如果你支撑的用户需要在飞机或野外消耗时间的话,那么SPA可能就有意义了,因为哪怕在没有连接的情况下本地处理仍能继续。此外,记住Word of Pie首席分析师Laurence Hart的话:“你不能一直假定浏览器会正确退出,在客户端处理可以减轻这一点。”

云价格。如果你用了云提供商,并且事务要收费的话,那么服务器调用越少意味着成本越低—像BPM这样的重度处理的应用尤其如此。

必要技能。SPA开发要沉浸在脚本和网页编程上面,一般还要利用像Backbone、Angular, Ember以及React这样的SPA框架来完成。不是每一个组织都有员工熟悉这些框架,所以必须做出培训投资或者从外面带人进来完成工作这样的安排。

单页面应用未必适合所有情况

正如你所看见的一样,单页面应用可以是在采用浏览器上Web时赋予用户桌面式体验的一个相当有效的手段。与此同时,SPA也可以给后端带来一定的效能,甚至哪怕这并非SPA的主要初衷。

然而,SPA的构造意味着它们未必适合所有情况,在正确匹配工作需要与预期好处上面必须多加小心——尤其是在做BPM的时候,其影响程度足以令单页面展示不切实际。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

BPM>更多

  • Red Hat披露更加架构驱动的BPM模型愿景

    Red Hat的一个更加结构化的BPM设计方案有望搭设应用开发界与业务流程管理的桥梁,让企业架构师、开发者和业务侧的人更快速更容易地实时新的业务流程。

  • 创新类编辑推荐:Sequence iBPMS平台

    Sequence是工作流管理的IBPMS平台。它是一个完全基于浏览器的平台,允许企业创建业务关键的“工作流”,或者任务,并且允许终端用户顺序完成这些工作流。

  • 用BPM策略对遗留应用现代化

    一些人提议把业务流程管理作为应用现代化的手段之一,但也有人对此提出质疑,但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。

  • 普元发布广电互联网开放平台白皮书

    在“三网融合”进程加快的发展趋势下,国内领先的软件基础平台与解决方案提供商普元信息技术股份有限公司,于近日发布《面向业务创新与融合的广电互联网+平台供应商》这一广电互联网开放平台白皮书,有效助力广电企业应对互联网+挑战。

相关推荐

  • 在iBPM和BPM间做选择 不一定非此即彼

    大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。

  • 用BPM策略对遗留应用现代化

    一些人提议把业务流程管理作为应用现代化的手段之一,但也有人对此提出质疑,但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。

  • RESTful API设计给开发人员带来怎样的未来?

    在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。

  • BPM和元数据帮助你消除流程孤岛

    你的公司是否有四个以上的部门?是否已经成立超过了五年?大部分中层管理人员是不是不得不花很多时间工作?我敢打赌这些部门没有使用业务流程自动化系统来跨越部门障碍。

技术手册>更多

  • SAML技术手册

    安全是所有Web项目在设计时都要考虑的一个重要因素。无论是选择最短口令,决定何时使用SSL加密HTTP会话,还是通过自动登录cookie来识别用户,都经常要付出重大的设计努力,以保护用户的身份信息和他们可能存放于Web站点的其他资料。糟糕的安全性可能带来公关灾难。下面我们就来具体看一下SAML在这里所起到的重要作用。

  • 敏捷扩展:大型网站项目最佳实践

    其实从某种意义上讲,敏捷软件开发是自身成功的一个牺牲品。随着项目的进行,焦点一直集中在需求定义上,一边编写一测试,一边交付工作软件的各个部分,所以可以看出敏捷是多么好,以致于许多组织都在试图扩展它的使用,而不仅只是局限在单一的团队项目中。但怎样才能把敏捷方法从小项目转移到大型项目中呢?

  • 开源框架Ruby on Rails

    Ruby on Rails, 也称RoR或简称Rails, 是一个使用Ruby语言写的开源网络应用框架,它是严格按照MVC结构开发的。它努力使自身保持简单,来使实际的应用开发时的代码更少,使用最少的配置。

  • 商业智能:BI

    商业智能也称作BI,是Business Intelligence的缩写。商业智能的概念最早在1996年提出。当时将商业智能定义为一类由数据仓库(或数据集市)、查询报表、数据分析、数据挖掘、数据备份和恢复等部分组成的、以帮助企业决策为目的技术及其应用。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算