智慧城市案例分析

智慧城市案例分析

【篇一：智慧城市案例分析】

场景描述

我们的场景中的鹿特丹市建立了水广场来预防强降雨带来的洪水。

在干旱期，水广场可用作娱乐场所，比如儿童游戏场或体育运动场。在强降雨期间，水广场用于容纳过量的降水。城市水管理部门然后

以可控的方式将水排放到当地的排水沟中。

一个智慧城市指挥中心监视与水相关的事件，比如即将来临的强降雨。该城市机构必须迅速有效地制定决策，以主动防御城市洪水泛滥。他们必须考虑各种因素：

预测的降雨量已观察到的降雨量水广场目前的状态可用来帮助疏散

水广场人员的公共安全行政人员水广场周围的交通状况他们使用一

个城市门户，如图1 所示。该门户提供了一个指挥中心仪表板视图，以显示来自各个部门的 it 系统的信息。(查看图 1 的更大版本。)

图 1. 智慧城市指挥中心

解决方案的业务需求

在智慧城市指挥中心场景中，城市工作人员制定的许多决策可使用

一个决策服务有效地自动化。我们的场景中的城市的决策服务具有

以下需求：

必须能够自动化复杂的业务逻辑

为规则管理流程的所有参与者提供基于角色的访问能力

必须使非技术性的业务用户能够维护业务逻辑

必须能够轻松地频繁更改业务逻辑，而无需 it 干预

包含审计和跟踪业务决策的能力

提供准确的执行报告

回页首总体解决方案

在我们的智慧城市指挥中心企业架构中，使用了一个 brms 来实现

决策服务。它提供了一个中央存储库来定义、修改和维护所有业务

规则。使用 websphere ilog jrules 实现一个业务规则子系统，可为

业务用户(也就是城市指挥中心人员)提供动态和按需定义和修改业务

规则的能力，而无需 it 人员干预。

websphere ilog jrules 允许我们将 brms 实现为任何其他子系统都

可调用的服务。它可使用 web 服务或服务组件架构 (sca) 来调用，

进而实现面向服务的架构 (soa)。在我们场景中的架构中，决策服务

由一个事件处理子系统使用 web 服务调用。如果我们的企业使用一

个企业服务总线 (esb)，可使用 web 服务或 sca 从 esb 调用相同的

决策服务。

图 2 显示了智慧城市指挥中心解决方案架构。

图 2. 解决方案架构

websphere ilog jrules 概述

websphere ilog jrules 提供了基于角色的模块，如图 3 所示。

it 开发人员 -- 负责开发业务规则应用程序。

开发人员使用一个名为 rule studio 的基于 eclipse 的 ide 来进行设计、java 开发和规则项目开发。

业务线用户 -- 负责业务规则的创作和管理。

业务用户使用一个基于浏览器的 rule team server 来编写和维护业

务规则。业务用户也可在rule team server 上执行用户测试和模拟。生产管理 -- 负责在企业中集成、监视和审计决策子系统。

管理员能够访问 rule execution server 来监视部署的规则集和管理

决策服务。此外，他们可使用 decision warehouse 执行细粒度审计。

图 3. brms 应用程序开发

决策剖析

决策服务的用途是基于传入的恶劣天气事件，智能地向各个部门生

成通知和指令。此规则引擎的输入和输出遵守 common alerting protocol (cap)，这是 oasis/itu-t 9 发布的一个 xml 规范(参见参考

资料)。输入数据包含有关天气警报的信息，比如降雨和起雾。图 4

显示了一个示例 cap xml 的输入片段。

图 4. 输入 xml 片段

(查看图 4 的更大版本。)

基于这些警报，决策服务制定为各个城市部门生成通知或指令的决策，从图 5 中的示例输出片段可以看出。

这些智能通知和指令由业务规则生成。

图 5. 输出 xml 片段

(查看图 5 的更大版本。)

回页首决策服务创建流程

基于规则的开发的一个重要优势是，它从应用程序代码中外部化了

业务规则，并分离出了开发周期。基于规则的开发将应用程序开发

和部署周期与规则的开发和部署跟踪分离开来。因此，创建基于规

则的应用程序的流程不同于传统的开发流程。创建一个决策服务的流程如图 6 中的流程图所示。可在此流程图中看到，创建一个决策服务需要规则分析师、规则架构师和业务主题专家协同工作。(查看图 6 的更大版本。)

图 6. 创建决策服务的流程

应用程序开发流程中所涉及的任务包括：

初始化

规则发现

规则分析

准备环境

开发

项目创建

规则设计

规则创作

部署和执行

部署

审计

支持业务用户

创建场景 excel 模板

发布到 rule team server

规则维护

编辑/编写规则

测试

部署

从总体上讲，该流程从以下步骤开始：

初始化阶段，规则分析师发现并获取业务策略。

然后分析策略以创建无歧义的业务规则。

规则开发人员使用 rule studio 创建规则项目和编写初始规则集。然后将规则部署到 rule execution server (res)，它利用websphere ilog jrules 的托管透明决策服务 (hosted transparent decision services, htds) 功能来将规则集公开为 web 服务。

要使业务用户能够维护业务规则，需要将规则发布到 rule team server (rts)。业务用户不仅可在 rts 中编写规则，他们还可使用决策验证服务 (decision validation service, dvs) 从 rts 测试这些规则。