内容


开发和部署:为云优化的 4GL 应用程序

哪个平台 — 3GL、4GL 或两者 — 对于您的数据驱动云应用程序是最优的?

Comments

针对云开发和部署应用程序不一定比针对传统环境更复杂,特别是当开发人员选择提供开箱即用的云支持功能的工具时。

对于数据驱动的应用程序,开发人员通常选择两种平台类型:

  • 第 4 代编程语言(4GL)
  • 第 3 代编程语言(3GL)

每个平台在技术领域中都有自己的位置,在整个软件开发历史中都有自己相对流行的时期。

了解如何及为何从 3GL 转移到 4GL 并在最近又从 4GL 回到 3GL。另外,探索开发人员现今面临的针对云开发应用程序方面的挑战和选择,并找到我们应对该挑战的独特方法 — 一个结合 4GL 工具和 3GL 平台的最佳平台。

钟摆摆动

上世纪 90 年代涌现了一些 4GL 工具(比如 FoxPro、Delphi、Progress、Oracle Forms 和 Informix 4GL),它们当时非常受欢迎,因为它们不仅降低了应用程序开发和维护的总体复杂性,还提高了开发人员的生产力。

4GL 工具通常自动化大多数应用程序常用的基础层,比如数据访问、数据绑定、原生 GUI 组件的组装等。由于不需要再考虑这些问题,开发人员可以专注于用户体验和具体业务逻辑,从而导致更快的开发周期和更精炼、更简单的代码基。一个额外好处是,这只需一个规模较小且不太专业的团队来维护它,使得 4GL 工具比 3GL 平台拥有明显的优势。

然而,到上世纪 90 年代末,4GL 开始显示其局限性。随着互联网的崛起,出现了一种范式转移,其标志是远离 “胖客户机”、客户端处理和原生窗口化界面,倾向于服务器端计算以及业务逻辑和呈现层的普遍分离。

有趣的是,没有一个经典 4GL 回应这个基于互联网的计算范式,因此许多开发人员再次回归 3GL 平台(主要是 Java™ 和 C#),以满足不断增长的 web 应用程序需求。

今天,开发人员正面临许多新挑战,原因是新技术已经促成了另一个范式转移 — 对软件即服务(SaaS)和基于云的应用程序的迫切需求。现代 SaaS 应用程序要求这样一种基于 web 的交付:安全、灵活、容错且拥有原生应用程序的可靠用户体验。要满足这种需求,需要一些新技术,下面是一个简短列表:

  • 针对交互性的完整 Ajax 支持
  • 跨浏览器支持
  • 安全性
  • 多租户
  • 集群化和负载平衡
  • 自动部署
  • 生产生命周期(版本控制)
  • 强大的 Linux® 支持

即使这些附加的要求得到满足,开发人员仍面临严峻的选择,3GL 与 4GL 的争论大战已升级。下面我们仔细检查一下每种选择。

通往云的 3GL 途径

3GL 的基本问题是一个生产效率和维护问题。在 3GL 环境中,开发人员负责构建和维护应用程序的基础层。尽管这种方法提供处理基于 web 的环境的细粒度,但开发人员需要付出生产力降低和复杂性增加的代价。

针对云进行构建时,生产力问题将变得更加严重。增加的要求将转换为需要构建和维护的其他基础层。代码基(code base)可能会变得非常大,代码基的大部分只处理管道工程,处理实际应用程序特定功能的部分则很小。

我们来前前后后仔细考虑一下一个基于云的应用程序的一些方面:

  • 开发人员必须编写代码来实现数据访问层,包括优化 SQL 查询、缓存结果以优化性能,而不会损害应用程序的规模。
  • 他们必须实现呈现层。对于基于浏览器的系统,这涉及生成标记、CSS 和客户端 JavaScript™。
  • 另外,开发人员还必须构建和维护 Ajax 层,将浏览器 DOM 事件绑定到调用服务器端业务逻辑的客户端脚本,所有脚本都必须针对每个构建迭代、浏览器和移动设备测试和调试。
  • 开发人员还必须严肃考虑一些云主题,比如弹性、添加/移除容量、集群化技术、负载平衡等。

目前为止我们还没有提到我们身边的真实任务 — 开发特定于应用程序的功能并阐述有效的用户体验。

实际情况是,3GL 团队必须非常专业并专注应用程序的这些基础层,他们交付核心功能的能力可能会受到损害。

这个问题的一个常见解决方案是使用第三方框架 — 本质上可重用的代码和类,它们提供具体功能的高级抽象。当这种方法减轻开发负担时,它也有自己的缺点。

软件团队必须评估、集成并维护兼容版本。例如,要对一个现代 ERP 应用程序启用云计算,需要 10-30 个框架来处理这些基础层。

因此,考虑到增加的开发和维护负担,重新考虑 4GL 可能有好处。我们仔细看看经典 4GL 工具为何不太适合基于云计算的应用程序的原因以及如何解决这个问题。

通往云的经典 4GL 途径

从架构角度看,4GL 是一组预先选择、良好编排的框架,用于处理应用程序的基础层。4GL 供应商承担这些框架的维护责任,开发人员重新获得自由,可以专注于用户界面和核心业务逻辑。为此,4GL 通常提供图形编辑器来支持以可视方式设计 GUI,并提供专有脚本语言和 API 来将用户驱动的事件绑定到特定业务逻辑。

其优点是简单 — 提高生产力并降低复杂性,其代价是灵活性降低。除非 4GL 供应商提供可扩展性甚至源代码,否则开发人员必须在工具的限制范围内操作。这可能会令人沮丧,因为经典 4GL 通常使用专有语言、协议甚至数据库,使得集成和扩展更加困难。但是,在云应用程序上下文中,最大的限制是可伸缩性

最大限制:可以伸缩吗?

经典 4GL 工具中有限的可伸缩性的根源是它们的底层架构。传统 4GL 采用一种两层设计。这在本质上意味着原生客户端直接连接到数据库。这个设置已针对一个更小的安装基础优化,该安装基础在一个局域网(LAN)上运行。4GL 工具不能支持一个更大的并发性,因为每个额外的客户端都需要自己的数据库连接;因此,当更多用户访问一个应用程序并使用太多的连接来增加数据库的负荷时,系统性能将下降。

由于以下安全性和性能原因,4GL 工具不能在广域网(WAN)上运行。

  • 组织不能通过公司防火墙公开数据库。
  • 当胖客户机必须通过 WAN 连接到数据库时,两层系统的性能较差。

伪造云途径

克服这种 WAN 不兼容性的一种常见方法涉及一种 “伪造云” 途径。这通常涉及一些视频流技术,比如 Terminal Services、Citrix 和 VDI。原生客户端在 LAN 中运行,它的视频映像通过 WAN 投射到一个远程客户端。

通过将一个原生客户端复制给一个远程用户,这种途径克服了通过 WAN 部署两层系统的安全性问题。而且,这是一个简单的解决方案,因为不必修改现有应用程序。

但是,伪造云途径不能解决两层系统固有的可伸缩性问题。它不能减小数据库并发性负担,需要的技术通常成本高昂,无法实施。简言之,它是一种 “快但不计后果” 的途径。

总之,两层系统不能满足云应用程序的要求。

但是,这不是浏览器对原生客户端的胜利

这并不是说原生客户端已成了明日黄花,所有新应用程序都必须是基于浏览器的。尽管大多数开发人员都认为 “云” 自动暗示基于浏览器的应用程序,原生客户端仍然可以通过 n 层技术部署在 WAN 上。

事实上,某些浏览器不能访问的任务就需要原生客户端,比如与客户端文件系统、硬件和软件交互。但经典 4GL 没有适当的架构来交付这种 “智能客户端” 技术。

那么,有可能在一个平台内同时拥有经典 4GL 的生产力与简单性和一组云优化的 3GL 框架的灵活性和可伸缩性吗?

通往云的现代 4GL 途径

开发人员在选择新平台时有很多问题需要考虑;我们来检查一下一个现代云优化 4GL 应该满足的一些要求。

  • 下一代 4GL 平台应该通过提供 n 层架构来解决服务器端计算的需求。这种设计模式在中间层中引入了一个应用程序服务器,中间层代理客户端和数据层之间的代理。这种途径极大地提高了高并发性的容量,因为数据库连接在客户端之间共享连接池。而且,n 层架构允许将应用程序安全地部署在 WAN 上,同时数据库能够在公司防火墙之后得到保护。应用程序服务器层还应该针对云部署优化,以包含对安全性、多租户、集群化和负载平衡、自动部署、生产生命周期(版本控制)的开箱即用支持。
  • 现代 4GL 平台还应该为原生客户端和基于浏览器的部署提供可靠选项。如果平台能够从单个代码基提供这些选项而不必重写代码,那么部署时间和维护又会极大减少。

    一个真正智能的客户端在互联网上运行,使用标准协议 — HTTP 和 SSL — 来避免代理和防火墙问题。它的响应速度将像本地运行的应用程序或基于浏览器的应用程序一样快。它无需安装即可部署到任何操作系统,自动进行更新,并提供与本地文件系统、硬件和软件的集成。

  • 对于可靠的、基于浏览器的部署,4GL 应该支持所有现代浏览器而无需插件或专有技术
    • 这种平台应该动态生成标记、CSS 和客户端 JavaScript。
    • Ajax 层应该以这样一种方式完全自动化:开发人员能够轻松捕获 GUI 事件并将其绑定到业务逻辑,且执行业务逻辑无需刷新页面。
    • 业务逻辑和呈现之间应该明确分离。应用程序特有的代码不应该在浏览器中暴露,从而改善安全性和性能 — 也许最重要的是 — 提供像原生应用程序那样轻松调试基于浏览器的应用程序的能力。
  • 云优化平台应该支持行业标准并独立于数据库供应商和操作系统。例如,应用程序可能使用 MSSQL 数据库在 Windows™ 机器上进行开发和测试,但使用 Postgresql 数据库在云中的一个 Linux 实例上进行生产运行。
  • 下一代 4GL 平台应该提供一个可靠的、可扩展的集成开发环境(IDE)。与经典 4GL 相反,新平台不应该引入任何专有语言或协议。它们应该提供对 Subversion (SVN) 这样的标准版本控制系统的支持,并支持自动完成、调试、重构、配置所有代码及其文档记录和单元测试。

我们已经介绍了几个要求,有一点可能已经变得清晰起来,那就是现代云优化 4GL 与经典设置看起来不太一样。但它们的目的是相同的:提供一些工具来大幅提高开发人员生产力,同时减小部署和维护的复杂性。

现在我们来检查一个真实平台,该平台重新改造了 4GL 来满足这些要求。

通往云的新途径

我们采用的途径结合了 3GL 和 4GL 的一些特性,解决了经典 4GL 的一些限制,允许您:

  • 用更少的时间开发复杂业务应用程序。
  • 同时在本地和互联网上部署。
  • 提供可伸缩智能客户端技术。
  • 提供一个基于标准的平台。

我们开发的平台是一个开发、部署和集成套件,向开发人员提供一个代码基,开发人员可以从该代码基快速构建和部署原生客户端和浏览器应用程序,这两种应用程序都适用公共和本地(on-premise)云和内部系统(图 1)。

图 1. 架构
架构
架构

本文余下部分将描述这个架构,并提供一个简单的开发环境示例,该环境同时使用 3GL 和 4GL 的特性来将应用程序部署到云中。

n 层部署架构

Servoy 环境采用一个 n 层架构,该架构包括跨数据库支持、高级应用程序服务器以及呈现层中的各种部署选项。下面我们仔细看看这些层。

数据访问层
我们提供一个独立于数据库的数据访问层(图 1 底部)。它结合使用了 JDBC、Hibernate 和 Servoy 扩展来使其独立于数据库,因此,它可以在 IBM DB2®、Microsoft® SQL Server、Oracle®、Sybase、MySQL、Postgresql 等数据库上运行。开发人员不必特意为此编写代码。

应用程序服务器层
Servoy Application Server(自下而上第二层)是一个高级应用程序容器,代表已连接的客户端管理数据事务。它有许多职责,其中包括:

  • 部署和生命周期管理
  • 实施安全性
  • 生成 HTML、CSS 和客户端 JavaScript
  • 与已连接的客户端的双向通信
  • 状态管理
  • 集群化
  • 负载平衡
  • 数据库连接池
  • 数据广播

业务规则层
这个层(自下而上第三层)负责执行所有逻辑。这个层可以是客户端的,也可以是服务器端的。

使用 web 客户端时,它总是服务器端的:将业务规则部署到浏览器将向终端用户公开业务规则,对执行和性能的控制能力更小,调试也非常复杂......将业务规则放置到服务器端,这些问题都可以避免。

智能客户端能同时在本地和服务器端运行代码。通过在本地运行代码,服务器将被卸载,交互性通常会得到提高。负载大的操作或数据密集型操作仍然可以通过无外设客户端在服务器端运行。还可以使用一个批处理程序基于实时基础、一个预定的时间间隔或在某个时点在服务器端运行计划任务。

呈现层
这个层(位于顶端)用于向终端用户展现可视化应用程序。对于原生客户端,它们将呈现原生操作系统的观感。对于浏览器应用程序,我们的平台将生成标记、CSS、JavaScript 和 Ajax,使用户界面支持动态体验。Apache Wicket 框架将用于这个目的,我们已经对这个开源项目做出了巨大贡献。

我们的平台还拥有发布 web 服务的能力,充当 HTTP、SOAP 和 REST 连接的一个中间层服务器。

开发环境

我们的开发环境包含一个 “所见即所得(what-you-see-is-what-you-get,WYSIWYG)” 图形表单构建器。这种构建器对于大多数 4GL 平台很常见,与需要编写大量代码来生成 GUI 组件的 3GL 环境相比,4GL 环境提供了一个生产力优势。

这个环境还提供一些复杂的数据建模工具、一个脚本编写/调试引擎、以及可一些靠的 API。与经典 4GL 一样,这些 API 本质上比较简单,但提供构建现代应用程序所需的复杂性。整个应用程序被存储为许多简单的元数据文本文件,这些文件可以与开发人员钟爱的版本控制系统轻松同步。

这个开发工具作为开源的、行业标准的 Eclipse 集成 IDE 的一个插件交付。

我们的平台中的基本开发单元称为 解决方案(solution)。解决方案涵盖单个应用程序的所有表单、脚本和数据建模元素。但是,解决方案也可以包含其他解决方案,那些被包含的解决方案称为 “模块(Module)”。通过使用一种模块化方法,开发人员可以跨多个应用程序重用组件和代码。

连接到数据
我们的平台使用 Java Database Connectivity (JDBC) 技术连接到任何关系数据库。要建立一个连接,只需 JDBC 驱动程序和连接参数。

开发人员可以从我们平台的 IDE 之内或通过他们选择的 DB 管理工具设计他们的数据库。在运行时,这个平台将管理所有数据库事务,发出 SQL 查询,缓存结果并将结果绑定到表单和 API 对象。开发人员不必拥有使用 SQL 的经验。

图 2. 数据库连接在一个设计程序中以可视方式配置
数据库连接以可视方式配置
数据库连接以可视方式配置
图 3. 当一个数据库连接被配置好后,平台将检查表结构
检查表结构
检查表结构

构建表单
开发人员也不必编写任何代码来生成 GUI 元素;此平台提供可以放置到一个表单上的元素的一个综合调色板。这包括所有标准控件(按钮、文本区域、组合框、单选按钮)和特殊控件(类型前置字段、树形视图控件、上下文弹出菜单)。

开发人员还可以在他们的解决方案中随意使用图像媒体和图标。所有组件都可以通过 CSS 设置样式,这样,通过调整样式表,就可以轻松重置整个应用程序的皮肤。通过 表单继承(form inheritance) ,此平台还支持面向对象设计,允许组件和表单级代码被继承和覆盖。

表单被绑定到指定的数据库表,其中的所有数据控件都可以用于显示和编辑表的列,无需编写代码或 SQL。但我们的表单不仅限于在单个表中工作;单个表单可以通过关系对象为多个表显示和编辑数据。

图 4. 用户可以在表单向导中指定数据源、CSS 等
表单向导
表单向导
图 5. 通过表单编辑器修改表单
表单编辑器
表单编辑器

建模数据关系
两个表之间的关系通过指定链接表的键列来定义,最常见的常规关系比如 “客户-订单”。但是,我们的平台被设计为支持使用多个键和运算符(= 除外)的关系。关系的键定义中也可以使用脚本变量,从而使一个关系变得动态,比如在某个指定日期的 7 天之内发生的 “客户-订单”。

图 6. 在 Relation Designer 中配置关系
Relation Designer
Relation Designer

一个关系通过图形方式定义,无需编写代码;它可以满足一个应用程序中的多个目的:

  • 首先,它可以用于显示/编辑一个表单上的数据。
  • 另外,通过一个关系,整个表单可以在其他表单之内显示。

在这里,已包含的表单的记录集将受到关系的约束。因此,跟随我们的示例,您可以在客户表单中显示客户的最近订单列表,方法是通过一个关系添加一个二级(second)、一些订单和一个表单。通过继续这个过程,您就可以构建一个复杂的、完全由数据驱动的用户界面,无需编写任何代码和 SQL。

图 7. 可以使用一个关系在一个表单内放置整个表单
表单内的表单
表单内的表单
图 8. 运行时在一个浏览器表单中显示的客户订单
显示的客户订单
显示的客户订单

找到并过滤数据
执行复杂的数据搜索而不用编写 SQL 是可能的。为完成这个任务,我们的平台提供了一个称为 发现模式(find mode)的特性。在发现模式中,一个表单的所有数据绑定字段都可以用作搜索标准。当搜索运行时,它将生成需要的 SQL 来返回记录。标准可以由用户手动输入,也可以以编程方式输入。我们的平台上的发现模式能够提供广泛的运算符、逻辑运算符、通配符字符串搜索等。

图 9. 用于复杂数据搜索的 3 行代码,没有 SQL
无 SQL 数据搜索
无 SQL 数据搜索

实现业务逻辑
我们的环境使用 JavaScript 作为主要编程语言;它公开了一个可靠的、自我建档的 JavaScript API,并使用该 API 来完成大多数编程任务。

与其经过编译的竞争对手相比,传统脚本语言总是提供大量灵活性和生产力,但由于其解释特性,它们也有一些缺点:

  • 难以调试
  • 性能问题
  • 弱类型化和强类型化
  • 代码重构

我们通过扩展 Mozilla 的 Rhino 项目解决了这些问题。Rhino 是一个基于 Java 的 JavaScript 引擎。在后台,我们平台中的每个 JavaScript 函数都映射到一个底层 Java 类。这种方法提供纯 Java 代码的性能,以及 JavaScript 的生产力和减小的复杂性。而且,如果愿意,开发人员也可以用 Java 编码。这通常在与一个第三方 Java 库集成时有用。

我们遇到一个较大问题是调试。为解决这个问题,我们共同创建了一个名为 DLTK(dynamic language toolkit,动态语言工具箱)的 Eclipse 项目,该项目提供一些工具来调试动态语言。最近这个项目已经扩展为支持强类型化,通过其他一些扩展,强类型化允许高级代码重构。参考资料 包含了更多信息。

图 10. 这个 JavaSCript 方法被绑定到选中的文本字段的设计时、基于数据更改的事件
绑定到更改事件的 JavaScript 方法
绑定到更改事件的 JavaScript 方法
图 11. 处理基于数据更改的事件的 JavaScript 代码
处理事件的 JavaScript 代码
处理事件的 JavaScript 代码
图 12. 在运行时,JavaScript 方法在字段数据更改时执行
执行 JavaScript 方法
执行 JavaScript 方法

部署环境

应用程序开发后,可以轻松部署到我们使用的应用程序服务器。部署过程只需要几秒钟。只需少量单击,就可以从开发环境导出一个项目并将其导入应用程序服务器。

导入完成后,应用程序就作为一个跨平台、自安装的原生客户端和一个跨浏览器的 web 应用程序对外界可用。后续构建迭代遵循相同的步骤,应用程序服务器将管理这个应用程序的大量生产版本,且具有只需一次单击即可向前和向后滚动的能力。

另外,导入过程也将可选地更新数据模型,以便针对一个开发数据库所做的架构更改将被自动推到生产中。

随着应用程序生命周期管理极大简化,开发人员能够解放出来追求更具进取心的构建计划并使他们的用户开心。

结束语

与针对一个更传统的环境开发应用程序相比,针对云开发应用程序应该没有太大区别,也不会更加困难。

在本文中,我们简要介绍了云应用程序开发如何在一个 3GL 平台上工作,如何在一个 4GL 平台的经典和现代版本上工作,然后我们详细介绍了我们自己的平台的内部工作原理,这个平台设计用于利用 3GL 和 4GL 平台的面向云的最佳实践。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=751296
ArticleTitle=开发和部署:为云优化的 4GL 应用程序
publish-date=08082011