企业应用集成(五)

企业应用集成
鲍亮
baoliang@mail xidian edu cn 西安电子科技大学软件工程研究所
baoliang@
用户界面集成
主要内容
用户界面集成简介
1
2
实例研究与CAB介绍
3
小结
主要内容
用户界面集成简介
1
2
实例研究与CAB介绍
3
小结
用户界面集成简介
用户界面层面上的应用集成是所有EAI层面上最基础的，也是最必要的
其它层面上的应用集成层面可能具有较高的技术含量，并且比较有效，但是对于大多数系统来说，用户可能是访问逻辑和数据的唯一途径
尽管用户界面集成看起来“没有什么技术含量”，但是它能在不改变原有系统的情况下完成集成工作
用户界面集成简介（续）
在用户界面集成的上下文环境中，用户界 在用户界面集成的上下文环境中用户界面就是应用集成的接口
这个过程也称为界面抓取（screen scraping），或通过编程的手段，采用中间件驱动用户界面访问屏幕信息，从而访问系统的流程和数据
在许多应用集成的环境中，除了通过用户界面，没有其他的方式能够获取应用程序的数据和流程
用户界面集成
同应用程序接口集成和方法集成相比，界面集成同应用程序接口集成和方法集成相比界面集成相对比较简单
采用界面集成的技术相对比较单一，风险也比较采用界面集成的技术相对比较单风险也比较小
尽管如此，仍然需要注意一些问题：
在采用用户界面作为集成手段时，需要考虑如何有效
的获取所需的信息，因为用户界面的设计更多会考虑
易用性，不大考虑数据获取的有效性
由于用户界面形式上的多样性，要求集成人员能够根
集
据实际的系统情况合理选择，而且在实际的集成过程
中，复杂的消息、事件处理等也是个不小的挑战
中复杂的消息事件处理等也是一个不小的挑战
用户界面集成（续）
如前所述，用户界面集成一般情况下是访 如前所述用户界面集成般情况下是访问遗产系统的“最后一招（last ditch）” 只有当没有合适的应用程序接口，或不能做数据集成时，才会考虑这种方法
但是我们不能就此说用户界面集成就是没有必要的
在许多情况下，采用界面集成是获取已有系统信息和调用系统功能的成功方式
界面集成的特点
其他形式的应用集成大都是由架构师或开发人员负责理解现有系统、系统的体系结构和数据库的详细信息
在界面集成这个层次上，对系统的理解想要达到以上的层次十分困难
这是由于作出界面集成这样的决策，通常是下列几种可能：
特殊的封闭系统，只能访问用户界面
其他层面上的应用集成不适用
业务等其他非技术因素，不希望改变已有系统业务等其他非技术因素不希望改变已有系统
理解应用系统
为了实现用户界面集成，有必要理解应用 为了实现用户界面集成有必要理解应用系统
其中包括理解底层的数据存储模式，大多数的应用逻辑，最重要的是了解信息是如何呈现在用户界面上的
与其他的集成方式不同呈现在用户界面 与其他的集成方式不同，呈现在用户界面上的信息有可能不会写回到数据库中
理解应用系统
用户界面上的许多数据元素，都是通过应 用户界面上的许多数据元素都是通过应用程序的逻辑计算得到的，一般情况下不直接从数据库中获取
直接中
这就要求集成人员仔细阅读文档，理解应用程序的逻辑，理解在某个上下文环境中的数据含义以及数据是如何生成的
如果没有理解文档，或者文档缺失（只剩下源代码），就容易导致数据的理解偏差，出现错误
创建屏幕分类
一旦数据库模式和应用程序逻辑得到正确 旦数据库模式和应用程序逻辑得到正确理解，一个出现在用户界面上的信息分类建来
必须创建出来
般情况下，首先抓屏，对出现在每屏一般情况下，首先抓屏，对出现在每一屏上的数据元素进行分类
除了简单的对数据元素进行分类数据的 除了简单的对数据元素进行分类，数据的计算逻辑（数学计算、用户的随意输入等）也要记录下来
创建屏幕分类
屏幕通常分类为：
屏幕通常分类为
屏幕名称
数据元素
描述
数据库引用
对应的业务处理逻辑
采用这种方法能够从对应的屏幕上有效地得到合适的信息。

此外，这些信息也能够辅助企业更新自身的元信息
映射屏幕
除了需要创建屏幕分类外，有必要对同样
除了需要创建屏幕分类外有必要对同样
的信息位置进行有效的定位
这个过程称为屏幕映射（screen mapping） 这种技术决定了数据元素在每一个屏幕上
的位置，其包含的位置和其他相关信息
一块同样的信息可能同时出现在应用程序
许多不同的屏幕上，这样就需要对相同信
息的不同出现进行映射和关联
从屏幕上获取信息
乍看起来，从屏幕上获取信息是一件十分 乍看起来从屏幕上获取信息是件十分直白的事情
目前存在两种从屏幕上获取信息的技术 静态信息获取技术
动态信息获取技术
这两种方式都有自身的优缺点，应该结合使
起来使用，取长补短
静态信息获取
静态信息获取意味着无论采用何种技术， 静态信息获取意味着无论采用何种技术
信息是从屏幕上一个静态的点上获取到的 相应的，没有必要查询整个屏幕或采用某相应的没有必要查询整个屏幕或采用某种逻辑条件查找信息
静态获取的优势在于其简单性，不需要为每个屏幕抽取创建逻辑结构，获取信息每一个屏幕抽取创建逻辑结构，获取信息仅仅意味着从预先定义的位置取得
其缺点在于数据元素的位置是固定不变的 其缺点在于数据元素的位置是固定不变的，当发生变化时，提取过程可能会获得错误的信息
动态信息获取
与静态信息获取相比，动态信息获取要复 与静态信息获取相比动态信息获取要复杂一些
采用条件逻辑的方式描述屏幕上的对象 例如，采用关键字搜索的方式查询并得到相关的信息
采用动态信息获取的方式能够自动适应用程序的变化，并应对屏幕的结构变化
另外一个好处是能够描述获取过程的逻辑另外个好处是能够描述获取过程的逻辑序列和步骤
从屏幕上获取数据的方式
存在两种从屏幕上获取数据的方式 将屏幕看作原始数据
将屏幕看作对象
这两种提取方式都模拟用户对用户界面的实际操作，从虚拟的用户接口中获取数据 般情况下，不可能只从单的用户界面一般情况下，不可能只从单一的用户界面上获取所有的必要信息
通常会在数以千计的用户界面上获取需要的信息，并将其组合起来，得到需要的结果
将屏幕看作数据
将屏幕看作数据这种情况下认为个屏将屏幕看作数据这种情况下，认为一个屏幕是一个简单的文本流
信息从屏幕上提取出来后以文本的方式在程序中交互
信息会被解析，确认，转换，并在程序中负责处理用户界面的逻辑部分进行处理
将屏幕看作数据的优缺点
采用这种方式的优点是简单性，信息并不 采用这种方式的优点是简单性信息并不实际改变状态，也能够保持易于理解的方式，屏幕信息不直接和处理信息的方法直接关联
其缺点是只有信息能够被追踪，处理这些信息的方法没有被追踪这样得到的结果信息的方法没有被追踪，这样得到的结果是不完整的
将屏幕看作对象
将屏幕看作对象的场景要远比将屏幕看作数据的场景复杂
采用这种技术需要将用户界面收集来的信息转换为应用程序中的对象（Java对象，CORBA或COM对象）
在转化的过程中需要添加操纵数据的方法
采用这种方法的有点是易于将对象应用在支持面向对象的系统中，可以采用消息代理等方式进行处理
开发者还可以扩展对象的能力，适应新的问题和应用
主要内容
用户界面集成简介
1
2
实例研究与CAB介绍
3
小结
界面集成——实例讲解
DB
Linux
业务遗留系统
COBOL
Network
主机系统Win NT
没有应用DB
程序接口
DB
界面集成——实例讲解（续）
为了从用户界面中提取需要的信息，集成 为了从用户界面中提取需要的信息集成人员需要了解如何能够得到合适的界面，在界面上定义合适的信息，读取需要的信最终信
息，最终处理这些信息
通常的做法是创建一个自动程序，来模拟实际的用户，模拟键盘动作，读取屏幕信实际的用户模拟键盘动作读取屏幕信息到内存中，进行解析、重构，传输到多个中间层，最终发送到目标系统中
个中间层最终发送到目标系统中
界面集成——实例讲解（续）
前面这个过程中，能够很好的模拟真实的 前面这个过程中能够很好的模拟真实的业务实例至关重要
需要创建一个常用的业务案例，仔细分析用户界面的出现规律和对应的数据，观察数据的流向，最终得到系统集成的主要流程
整个过程需要细致和耐心，并辅助以自动化程序
界面集成案例研究
公司中有许多小的业务系统，这些业务系 公司中有许多小的业务系统这些业务系统彼此独立开发，没有任何关系
小系统没有任何接口，数据格式也差别很大
某种角色的业务人员在工作时经常需要打开两三个与自己业务相关的系统界面
公司希望提供个整合的系统，即能够在A 公司希望提供一个整合的系统，即能够在系统执行时看到B系统的信息，反之亦然，提高业务人员的效率
界面集成案例研究（续）
应用系统1
2
应用系统
应用系统3
应用系统4
界面集成案例研究（续）
举一个例子，一个采购员的角色，需要关 举个例子个采购员的角色需要关注产品、负责采购、了解收货情况、了解当前库存和退货情况等
等
这就至少牵扯到三个系统：
产品信息系统（产品信息）
采购信息系统（采购，退货，收货等）
采购信息系统（采购退货收货等）
库存信息系统（当前库存）
这些系统除了能够操纵界面，不能进行其他的集成行为
界面集成案例研究（续）
究其原因，可能是该开始的时候公司可能 究其原因可能是该开始的时候公司可能没有统一的规划，或者业务发展太快导致最初的系统逐渐不能适应新的情况
初
这就让集成人员不得不面对这种集成的复杂度
在理想状态下，只有一个系统，通过不同在理想状态下只有个系统通过不同的权限控制每个人访问的内容
但是在实际的企业级应用中，这显然是不能实现的梦想
界面集成案例研究（续）
针对这种情况，微软启动了一个称为“智 针对这种情况微软启动了一个称为“智能客户端”的项目，专门应对这种问题
CAB(C it UI
该项目称为CAB (Composite UI Application Block)，它是一组.NET2.0的类，用来减轻构建复杂Windows窗体应用类用来减轻构建复杂
程序的难度
重点在于解耦构成一个复杂应用程序的代码
CAB还提供了一种在用户界面层次解耦元素的能力
界面集成案例研究（续）
界面元素的解耦能力意味着能够在不改变组成应用程序模块的前提下对UI的组织形
变
式进行改变
对于小型的应用系统，没有必要采用CAB 进行解耦，但是对于大型系统，尤其是基
的桌面应用系统采用
于Windows的桌面应用系统，采用CAB能够将复杂的界面管理集中到一个统一的模式下
CAB的主要思想
区分开发活动中的三种不同行为：
区分开发活动中的三种不同行为
书写界面逻辑：需要在Windows窗体，用户控制，表现和行为
基础构建组件对于每个应用程序都进行构 基础构建组件：对于每一个应用程序都进行构
建，或者被其他应用程序重用
业务逻辑：用户界面，逻辑，实体和具体应用
程序的服务代理
应用程序体系结构支持开发者和团队在构建一个应用程序时拥有不同的视角
采用CAB分离关注点
表现层
业务逻辑
远程服务代理
CAB的模块化
这种结构允许你将业务逻辑，可视化组件， 这种结构允许你将业务逻辑可视化组件基础组件，表现者和控制者组件和其他系统中需要的组件以模块化的方式进行组织中模
智能客户点和可视化部分的开发者负责用户界面的设计与实现
业务逻辑开发者负责实现用例逻辑
基础层开发者提供公共的服务日志，
——
安全特性等
CAB的扩展性
组合UI应用程序块（CAB）提供了一种通 ）提供了种通用的shell体系结构，能够采用不同的方式进行扩展：
替换缺省的行为和策略，换为你自己的实现 根据应用程序的要求添加定制的服务和行为
采用CAB带来的好处
模块化：构建松耦合的分离模块相对比较 模块化构建松耦合的分离模块相对比较容易，能够采用独立但有协作关系的模块构成客户端
端
扩展性：能够以多种形式扩展个应用程扩展性：能够以多种形式扩展一个应用程序，可以在不访问某些模块源代码的情况下扩展程序
可测试性：分离的模块降低了耦合度，为系统的测试带来了方便
CAB的组成元素
依赖注入
事件代理
UI元素、智能部件和命令适配器 工作项
作项扩展
工作项扩展
工作区间
模块
服务
CAB中采用的模式工作项：采用
工作项采用MVC和MVP，
及状态模式
模
对象工厂：采
用依赖注入，
工厂方法和构
建器模式
CAB中采用的模式 服务采用策Shell服务：采用策
略模式决定呈现方式，采用命令模式定制具体的命令和行为
CAB中采用的模式 核心服务采用核心服务：采用
订阅/发布模式
通过事件代理完
成请求与响应
CAB中采用的模式
模块加载层：
模块加载层
采用插件技术，
提高扩展性
高
41
西安电子科技大学软件工程研究所/
2010-6-3042。