企业数据移动化

企业正努力通过RESTful接口实现企业数据的移动化,但开发移动应用和REST API是非常耗时的工作。

我们研究了两种技术,可以显著缩短上市时间。可执行的Schema(建立于模型驱动开发和约定优于配置)从现有Schema创建RESTful API和多表UI,只需要几分钟时间。声明式的行为为逻辑和安全带来类似电子表格的强大功能和简单性,它基于完全可编程的JavaScript模型。

我们将简要地回顾现有的关键技术,借助它们的先进性,吸取市场中的教训。然后我们将提供可执行的Schema和声明式行为的具体细节。

当前的方法

承诺加快交付速度是很有吸引力的,在过去十年间确实诞生了一些很棒的产品。首先,让我们简要分析当前的方法,从而得出一些经验教训。

模型驱动开发

模型驱动架构[1]和模型驱动工程[2]这样的方法,已经在构建部分系统元素方面有一些成功案例。虽然有承诺,但其真正的机会在于:

  • 直接构建可执行的系统,而不是需要理解和集成的组件(如Beans、Transfer Object);
  • 借助云/移动技术;
  • 消除Model/Schema的冗余和同步的复杂性。

约定优于配置:Ruby, Grails……

生成可执行系统的概念已经被Ruby、Grails,Roo等流行的产品占据,它们使用约定优于配置[3],根据模型生成UI界面和代码。这是一个简单的Grails例子:

(点击查看大图)

企业数据移动化_第1张图片

(点击查看大图)

企业数据移动化_第2张图片

能够快速构建Web应用是一件好事,但如果要想获得显著的、更大的价值,就要实现:

  • 应用能够更加完整。例如提供可编辑的(内嵌Lineitem修改)主/从表(显示订单的Lineitem)Grid,自动关联显示产品名称而不是数字;
  • 提供多表业务逻辑支持(修改逻辑和安全业务逻辑非常冗长乏味);
  • 应用部署于云技术平台,REST和HTML 5/JavaScript;
  • 避免生成代码的缺陷,例如当原始输入(数据模型)变化时,重复生成或丢失自定义逻辑。

移动后端

移动后端即服务(Mobile Backend as a Service,MBaaS)是一个新的分类,关注于云技术,例如REST/JSON。DreamFactory和SlashDB这样的产品为你的SQL数据创建了完整的RESTful API,并提供了便利的表格浏览用户界面。

但这肯定仅仅是个开始,如果你能实现以下功能,就不难想像其价值了:

  • 扩展表浏览功能,实现完整的多表应用,提供主/从、导航等功能;
  • 提供业务逻辑,确保数据修改时触发正确的计算和校验;
  • 使用别名(Alias)/Projection提供自定义多表资源。

建议的方法

通过引入以下理念可以显著加强这些方法:

  • 可执行的Schema,将Schema作为模型,你可以建立REST/云服务,预先为多表UI和API提供通用行为模式,这是个立即可执行的系统;
  • 声明式、面向业务的行为能够提供声明式的API扩展、逻辑和安全行为支持。其真正的价值是在一个很高的抽象层面交付这些行为,这更像是面向业务的需求,而不是代码;
  • 在标准语言中集成命令式语言支持。使用像JavaScript这样的标准语言,为模型提供程序事件支持。

所以,开发团队能够在接近业务的抽象层运行和交付,显著提高了速度。他们能将BDD故事翻译成可运行的软件,以确认理解和发掘下一组行为。这样就明显地减少了误解,因为相关干系人已经看到了正在运行的软件,读懂了“代码”。

可执行的Schema

要想有立竿见影的效果来满足业务需求,我们要运行现成的应用。也就是说,只要将我们的系统连接到Schema,就会有完全可执行的API和应用软件,正如下面所描述的。

默认的应用程序

建立一个具有丰富功能、支持移动的后台应用是有可能的。前提是虽然“前台”应用需要UI草图,但数据维护这一大类应用遵循一套常见的模式,它们可以通过Schema来创建。

下图演示了一些数据维护应用完整功能的常见模式:

  • 搜索/过滤、分页列表/表单视图、可排序的列标题;
  • 外键驱动的多表应用软件行为:
  • * 主/从表(客户的多个订单);
  • * 下钻导航(第2张图,订单的项目,通过右下侧的放大镜或Zoom按钮);
  • * 自动表关联(Join):显示产品名称,而不是数字编号;
  • 数据编辑支持,包括可编辑的表格,查找(查找部分)和错误处理。

表关联功能非常有趣,它相当常见。在下面的例子中,Product外键是Product Number,而不是Name,这是很常见的模式。理想情况下,系统了解这种情况(数字外键,例如Product Number)并自动关联更适合的字段(Name)。我们不仅有可执行的Schema,而且是马上就能用的。

(点击查看大图)

企业数据移动化_第3张图片

(点击查看大图)

企业数据移动化_第4张图片

默认的REST API

RESTful API是云/移动应用的架构选择。该API不仅能提供移动应用接入,还可为其它系统提供Web Service访问。

数据库到REST的映射也非常直接,只需要:

  • 为每个数据库表、视图和存储过程建立REST Endpoint;
  • 提供Get/Put/Post/Delete支持(即常说的CRUD操作),并支持:
  • * 过滤和排序;
  • * 常见的模式,包括分页、分析数据库结构和相关的数据,以及乐观锁。

其结果是一个“扁平”的关系型API。这是个好的开始,但我们需要继续去扩展它。

声明式的行为

我们建议模型不要复制Schema,由于下面这些关键行为,因此有必要扩展它。

富REST API:多表资源、别名和Projection

我们的“扁平”API是个好的开始,但仍然需要富“面向文档”的API。该需求是为移动开发人员提供方便的API模型的同时,最小化多个查询的延时。

这样的对象有点像支持别名和Projection的关系型视图。但是,与视图不同,它们不是扁平的。它们支持嵌入的“子资源”对象,例如Order对象有LineItem和Shipment信息。

这样的“多表视图”可以通过点击,或者这样的语法进行定义:

Create Resource OrdersResource 
      from Orders (id as orderNumber, customer.name as customerName), 
      SubResource Items as LineItems via <fkName> 
         (name as product.name, qty as qtyOrdered...) 
      SubResource Shipment as Shipents via <FkName> 
         (...) 

逻辑:与电子表格相似的响应(Reactive)

业务逻辑是绝大多数系统的关键因素。它们通常是繁琐的代码、包含大量的变更检查和扩散逻辑,以及大量的SQL(包括缓存提升性能)等等。

通常认为,这样的逻辑是特定领域的(正确),并且必须以命令式和过程式语言进行开发(错误)。声明式的方法将能够显著提前和加速软件交付和维护。并且已经存在这样的解决方案。

目前越来越重视UI事件处理中的响应,例如模型到视图的同步。但最常用的是电子表格,当相关值发生变化时,单元格公式的响应,会进行重新计算,当然还能将它们串起来。虽然对非程序员来说很简单,但电子表格提供了足够的能力,解决了不同寻常的复杂性。

响应非常适合于数据库事务逻辑:

  1. 给数据库表的列,或者“虚拟列”(是模型的一部分,用于事务处理,但并不物理保存)设置表达式;
  2. RESTful Put/Post/Delete操作修改了关联的值时,将触发调整相应的值;
  3. 同时进行校验(余额<信用)。

最有趣的事务是多表,按照我们的表达式,可以引用关联数据(customer.balance := sum(orders.amount_total where paid = false)。这让系统不仅能够检测变化,还要提供持久化(读取/写入相关数据、缓存和优化等等)。

需要注意的是对列的逻辑封装将导致继承复用。上面的例子中,我们声明的系统观察和响应orders.amount_total或paid标志的变化。

声明式的逻辑肯定是无序的。因此系统必须推导出执行顺序,例如通过依赖图。这对维护很有意义。自动排序意味着你增加/改变逻辑时,不需要担心执行顺序的具体细节。

由于省去了依赖管理、扩散和SQL处理,实现了意义非凡的简洁性和可读性。意义非凡指的是扩展了order的幅度,因此下面的逻辑,是虚拟的需求规范,是可以直接执行的:

lineitem.amount = row.product_price * row.qty_ordered 
lineitem.product_price = copy(row.product.price) 
orders.amount_total = sum(lineitem.amount) 
customer.balance = sum(orders.amount_total where paid = false) 
validate customer as row.balance <= row.credit_limit 

但是,没有银弹。并不是所有逻辑都能够声明,关键的条款需要正确地集成处理逻辑。这些在下面描述。

安全性

大多数系统的另一个关键需求是安全性。除了熟悉的端点接入,系统必须实现行和列的实例级别的安全性。例如,您可能希望某些人只能看到自己所在地区的订单。

很多系统在视图级别提供这样的功能,但这导致定义和维护大量的视图。一个更好的办法是将基于角色的安全性封装到表中,并确保它能够在跨多表资源时可以重用。

Role SalesRep authorized for Orders 
     Columns(orderDate, …) 
     Rows (region = $user.region) 

其中$user表示一种建议的机制,将用户与命名的值(例如region)关联,可以用于过滤表达式的参数。

程序扩展

可执行的Schema和声明式行为能够提供价值,但仅当它们与常见的程序扩展进行集成后才潜力无限。

服务端JavaScript

通过Schema可以直接为每个表创建JavaScript行对象类型,以及列和相关数据的存取方法。这很像Ruby Active Record,它们是持久化感知(Persistence-aware)和逻辑感知(Logic-aware)的。它们确保了在处理修改时,执行正确的响应逻辑。

此外,你能在服务端JavaScript中处理它们发布的事件。事件包括常见的模型(插入前、修改前)并对JavaScript提供完全的访问(发送消息、启动程序等)。JavaScript是一种优秀的语言,它几乎运行于所有系统,而且大多数开发者都相当熟悉。

UI创建

客户端的扩展性也很重要。默认的UI可能很强大和有效,但主要适合于后台应用程序。对于前台办公应用,有很多要求,因此应能够开发任何UI界面。

有两种可行的方法。第一,默认的UI可以正向工程(代码生成)到你偏爱的平台/IDE中,你将它作为起点。

或者,可以将内在的模型移出,将默认UI制作成组件,以参数化的iFrame方式嵌入到更大的应用程序中。这保持了模型间的关联,避免代码生成的“你拥有它”的影响。

自定义API

最后,创建声明式API丝毫没有消除构建自定义API的能力和需求。

总结

我们在这列出了现实的方法:

  • 从现有Schema快速创建移动应用和默认的RESTful API;
  • 扩展API,定义多表层级资源;
  • 使用声明式“响应”表达式增加行为,管理修改逻辑和行访问,提供电子表格的简单性和强大功能;
  • 与服务端JavaScript集成,提供复杂的行为。

作者注:Espresso Logic已经在实现这个愿景,提供了一些前面所描述的元素。如果你想试试,我们提供了免费的评估版本和零安装系统,你可以使用自己的数据库。我们始终期待与你交换意见,以提高我们的技术。

参考文献

[1] The OMG effort

[2]Model Driven Engineering (see this, this and this)

[3]Convention Over Configuration

关于作者

Val Huber拥有超过20年的快速开发和维护业务应用的构建技术经验。在Espresso之前,Val是Versata公司的CTO,该公司是2000年前5大IPO之一,最初由一批远见者如Paul Allen和SAP的Hasso Plattner投资成立。在Versata,他领导J2EE环境下的大规模事务和流程应用开发。Versata支持数以万计的并发用户,部署于许多财富500强公司,包括ADP、Equifax、Fidelity、IBM和Sears等. 在Versata之前,Val是Sybase公司(现在是SAP的一部分)的架构师。他也是Wang的高度评价的PACE(Professional Application Development Environment,专业应用开发环境)背后的驱动力。PACE提供了关系型数据库,以及完全自动化的工具套件用于报表和交互式应用。Val拥有多项专利,并享有由他的团队开发的商业相当成功的系统。

查看原文链接:Restify and Mobilize Your Data

你可能感兴趣的:(企业数据移动化)