本文是《基于 Web 2.0 下一代网上银行》系列的第二篇，本系列的
第一篇介绍了基于 Web 2.0 的下一代网银的理念和特征。从这篇开始的接下来的几篇会介绍如何利用
Web 2.0 的技术及理念去架构和开发下一代网络银行的应用，包括基本组件和架构、前端创新型设计、智能渠道的整合、创新型应用模式、后端智能支持等等。这篇文章主要介绍下一代网银的技术架构和基本元素。
IBM 基于 Web 2.0 的下一代网络银行，是以用户为中心的网络银行。从用户角度看，IBM 基于
Web 2.0 的下一代网络银行为用户提供属于自己的个性化网络银行平台。用户登录网络银行后看到的网银界面可以根据自己的喜好定制，并且不同用户的操作界面互不影响，用户可以在自己的网络银行平台上去订阅自己感兴趣的服务；从银行产品和服务角度上看，IBM
基于 Web 2.0 的下一代网络银行是“金融产品超市”，基于 Web 2.0 技术，该平台提供了集成各种第三方服务的能力，为终端用户提供丰富的服务，提高了用户体验；从银行营销角度看，IBM
基于 Web 2.0 的下一代网络银行为银行提供了营销平台，信息发布平台，以及服务平台。它和以往的网络银行不同，支持分类区分客户，为不同的客户在合适的时间提供合适的产品。在区分客户的基础上，更加了解客户，并容易对客户的兴趣点进行分析，便于实现目标营销以及渠道互动销售。在为客户提供更好的服务的同时，为银行创造了更多的利润。
综合上面的分析，基于 Web 2.0 的下一代网上银行技术结构首先要满足业务上的个性化、集成化、平台化和智能化的需求，所以基于
Web 2.0 的下一代网上银行有以下主要特性：
- 基于 XML 的定制化的工作区。以往的网上银行的界面和工作区是固定的，包括内容也是固定的，不能满足用户界面上的个性化需求。基于
Web 2.0 的下一代网上银行采用 XML 来描述每个用户的界面和工作区，不同的用户有不一样的 XML
布局描述。网银中的 Web 2.0 引擎会负责解析这些描述并在页面上呈现相应内容。
- 基于 XML 的服务仓库。在商业银行和各种金融机构电子平台中，服务大多以代码的方式散落在各处，既没有有效地组织方式，更没有统一的管理方式。
Web 2.0 网上银行架构中，所有的服务都通过 XML 描述，并存储在统一的服务仓库中。最后由业务管理员统一管理分配给相应的客户群。
- 基于 Widget 规范的银行服务。Widget 能够在前端承载银行的各种服务，甚至第三方服务，如
Google Map、某些电子商务等。Widget 规范为网上银行的各种服务提供了良好的易用性、开放性和交互性。虽然当前
Widget 的规范还没有完全统一，但 IBM 内部的 Web 2.0 产品都遵循 iWidget
规范。
- 界面风格和主题控制。基于 Web 2.0 的网上银行可以切换展现，如友好的 Windows XP
桌面的风格，或者的绚丽的 Mac 桌面风格，每种风格还会有不同的主题。这需要网银系统中加入界面风格和主题控制的支持，包括前端页面上的控制处理引擎及渠道和后端的支撑。
- 智能渠道。网络银行架构中的渠道作为连接前端和后端桥梁，即能融合前后端和自身的各种数据做智能分析，也能为前端和后端提供有效地反馈。在基于
Web 2.0 的下一代网上银行的技术架构中，智能渠道即 Smart Channel 将会为 Web
2.0 前端展现框架做强大的支撑，同时也将 Web 2.0 的各种应用模式与 Web 2.0 的前端技术联系起来。
下面是基于 Web 2.0 下一代网上银行的架构图：
图 1. 基于 Web 2.0 下一代网上银行架构图
从图中可以看出，基于 Web 2.0 的下一代网上银行，是 Web 浏览器上的集成交易平台：
- 基于浏览器之上，是一系列的应用程序。这些应用程序可以是网上银行，可以是网上商城，或者是内部基于浏览器的办公应用。
- 基于这些应用之上的是下一代 Web 2.0 网上银行框架。它可以作为一系列 SOA 应用的整合前端，也可以用于集成一系列企业已有的
B/S 应用，集成基于 Widget 标准。这些 Widget 就组成了一系列的前端服务，可以被业务人员所分配管理。
- 角色、用户服务管理，是一组管理机制，用于进行客户细分，管理网上银行服务库，并且为不同类别的用户分配不同的服务内容。
- Workplace 指的是工作区，用户定制的服务可以拖放到工作区中进行办理。用户可以随意定制化自己的工作区。
图 2. 基于 Web 2.0 下一代网上银行运行图
从运行图中可以看出，基于 Web 2.0 的下一代网上银行，左边是一系列的服务，而右边中间则是工作区。服务以
Widget 的方式组织。Widget 可以是普通的 Web 应用，可以是后台 SOA 服务的前端展现，可以是第三方的
Web 应用，还可以是新开发的交易。
开发基于 Web 2.0 的个性化网上银行，包括下面几个部分：
- Widget 开发，并封装交易为 Widget 组件。
- 将 Widget 组件配置发布成网上银行服务。
- 业务管理人员管理用户、角色以及服务。业务管理人员可以细分用户，并根据用户的喜好分配终端用户感兴趣的服务。
- 终端用户登陆个性化网上银行，订阅感兴趣的服务。用户可以随意定制化自己喜欢的页面布局，并订阅自己感兴趣的业务。
- 交易开发。
下面的几个章节，将会详细介绍这五个步骤使用到的组件和开发步骤：
Widget 是基于 Web 2.0 的下一代网上银行服务的载体，网银上所有的金融产品和服务的页面展现都可以封装为
Widget 的实例。而一个 Widget 的实例是通过对一个 Widget 的定义做参数配置后的实例化。如图
3 所示，一个 Widget 的定义会有两部分文件组成：一个 XML 文件和若干的资源文件。资源文件包括
JavaScript 文件、CSS 文件、图片文件、HTML 文件、视频文件和音频文件。这些资源文件不一定都会存在，而且这里所说的
Widget 的资源文件是 Widget 实例化时引入的资源。例如，一个 Widget 定义确定会显示一些的图片，那么这些图片就是
Widget 的资源；而如果某个图片是在 Widget 生成实例并显示在页面上时，通过某个 Widget
的参数输入的 URL 链接进去的，那么这样的图片不包含在这个 Widget 定义中。一个 Widget
的定义可以理解为一个 XML 定义和若干资源的组合。
图 3. Widget 的定义图
一个 Widget 被定义并实例化后才可以在 Widget 容器中运行。从一个定义好的 Widget
到生成一个在线运行的 Widget 实例，一方面需要运行环境的支持，另一方面需要通过适当的形式为 Widget
的实例化输入适当的参数。Widget 的运行环境包括在浏览器上运行的 JavaScript 服务和引擎，同时也包括服务器端的一些支持如
Widget 对象的持久化、Widget 的 XML 定义的传递等等。Widget 运行环境在浏览器端的服务和引擎被统称为
Widget 容器，如图 4 所示。
图 4. Widget 容器
一个定义好的 Widget 会被注册在 Widget 注册表中。借助该注册表，Widget 容器可以通过代表这个
Widget 定义的 ID 找到 Widget 定义的具体位置。而服务列表中则利用那个 ID 和对 Widget
的属性配置来定义一个 Service。Widget 运行环境最终会通过 Service 的定义来初始化
Widget 的实例，并展现在工作区上。如图 5 所示。
图 5. 展现在工作区上的 Widget 实例
从上文的描述中可以看到，从最初的定义一个 Widget 到最终的运行一个 Widget 实例，需要完成以下几步：
- 定义 Widget 的 XML 描述文件
- 开发 Widget 的资源文件
- 注册 Widget 的定义
- 利用 Widget 定义服务
- 运行 Widget 实例（服务）
作为例子，下面会根据这五个步骤创建并运行一个简单的 HTML Widget，这个 Widget 的主要功能就是根据参数
URL 的值来链接到相对应的网页。而且用户可以 Widget 实例上直接编辑参数 URL 的值。
- 定义 Widget 的 XML 描述文件
一个 Widget 的 XML 描述文件主要包括 Widget 的名字、Widget 的 scope
对象、Widget 的事件、Widget 支持的展现转换模式、Widget 的默认展现内容、Widget
所需要的 JavaScript 文件和 CSS 文件、Widget 的属性、Widget 的展现内容定义等等。
下面的清单 1 展示了如何定义一个简单的 Widget。
清单 1. Widget 的 XML 定义
<iw:iwidget name="simpleHTMLWgt" xmlns:iw="http://www.ibm.com/xmlns/prod/iWidget"
iScope="simpleHTMLWgt" supportedModes="edit max close collapse refresh" mode="view">
<iw:resource uri="HTMLWgt.js" />
<iw:itemSet id="attributes" private="true">
<iw:item id="url" value="http://www.ibm.com"/>
<iw:item id="height" value="400"/>
</iw:itemSet>
<iw:content mode="view">
<![CDATA[
<iframe class="rootFrame" id='rootFrame' width=100% height=200></iframe>
]]>
</iw:content>
</iw:iwidget>
|
清单 1 中，节点“iwidget”及其子节点构成了这个 Widget 的 XML 定义。在“iwidget”节点的属性中，“name”指定了
Widget 的名字，“iScope”指定了 Widget 的 scope 对象，这个 Widget
的 scope 对应的类型在 Widget 的资源节点所指定的某个 JavaScript 文件中，在这里为
HTMLWgt.js，“supportedModes”指出了这个 Widget 在一般状态下所支持的展现转换模式，这里设定这个
Widget 支持的五种展现转换模式，分别为编辑、最大化、关闭、收起和刷新，Widget 容器会根据
Widget 定义中的展现转换模式在其实例窗体上添加对应的按钮，如图 6 所示，“mode”指定这个
Widget 默认使用的展现内容模式，其中“view”会被以“content”子节点的形式定义出来
在“iwidget”的子节点中，“resource”节点会指定 Widget 定义所需的 JavaScript
文件和 CSS 文件，“itemSet”指明定义 Widget 定义中所包含的数据项，“id”为“attributes”的“itemSet”会给出
Widget 的属性，这里的 Widget 包含两个属性：“url”和“height”，“content”节点定义了
Widget 的展现内容。
图 6. Widget 的展现转换模式
- 开发 Widget 的资源文件
Widget 的资源文件包括 JavaScript 文件、CSS 文件、图片文件、HTML 文件、视频文件和音频文件等，其中
JavaScript 文件和 CSS 文件会在 Widget 定义中通过“resource”节点指定出来，而其余的文件则是通过
Widget 的 XML 定义文件、JavaScript 文件和 CSS 文件中的引用来表明其与
Widget 定义的关系。这些 JavaScript 文件中包含着 Widget 定义中的大部分的逻辑内容，而
Widget 定义中所指定的 scope 对象也会被定义在这些 JavaScript 文件中。在这个例子中，Widget
的定义只需要一个 JavaScript 文件 HTMLWgt.js，列表 2 给出了这个文件的内容，里面定义一个
simpleHTMLWget 的 JavaScript 类型，这与前面 Widget 的 XML
定义中的“iScope”的属性值是匹配的。Widget 容器会为 Widget 实例生成一个对应的
JavaScript 对象，就是前文所提到的 Widget 的 scope 对象。这个类重载了两个方法“onLoad”和“onSave”，Widget
容器会负责在适当的时候回调它们，“onLoad”会在 Widget 实例初始化的时候被调用，而“onSave”会在用户完成
Widget 实例在线的属性编辑触发保存动作的时候调用。
清单 2. Widget 的定义中的 JavaScript
文件
function simpleHTMLWgt() {
this.onLoad = function() {
this.rootFrame = this.iContext.getElementById('rootFrame');
this.rootFrame.src = this.iContext.getAttributeById("url");
this.rootFrame.height = parseInt(this.iContext.getAttributeById("height"));
}
this.onSave = function(){
this.rootFrame.height = parseInt(this.iContext.getAttributeById("height"));
var url = this.iContext.getAttributeById("url");
if(this.rootFrame.src!=url)
this.rootFrame.src = url;
}
}
|
- 注册 Widget 的定义
Widget 定义完成后需要注册到 Widget 注册文件中才可以被用来生成实例，这一过程很简单只需要注册文件中加入以下一行定义。其中的“definition”属性表示
Widget 的 XML 定义文件的位置。
<entry id='simpleHTMLWgt' definition='../widget/basic/HTMLWgt.xml'></entry>
- 利用 Widget 定义服务
利用 Widget 注册的 id，通过具体的参数配置就可以定义相应的服务，并注册在服务库中。这里，我们利用刚注册的
simpleHTMLWgt 来向 Web 2.0 On-Demand Workplace 中添加一个显示
IBM 网站的服务。在服务库的 XML 注册文件中，添加以下服务定义，如清单 3 所示。
清单 3. 利用 Widget 定义的服务
<Service id="0.1" name="html_service" desc="html_service"
logo="theme/servicelogo/navlogo.gif">
<Widget name="simpleHTMLWgt">
<attribute name="url" value="http://www.ibm.com" />
</Widget>
</Service>
|
- 运行 Widget 的实例（服务）
定义好的服务会被放到服务库中，用户可以将其添加到自己的服务列表中。当用户选择服务列表上的服务项后，的
Web 2.0 框架就会触发 Widget 容器利用服务定义中的 Widget 的 id 和参数值生成一个
Widget 实例，并呈现在工作台上，如图 7 所示。
图 7. 服务列表和运行的 Widget 实例
在基于 Web 2.0 的下一代网银架构中，服务会由一个或一组 Widget 实例组来完成一项或几项电子银行业务，如由一个单一的
Widget 实例实现的转账服务，由几个 Widget 实例组成的汽车贷款服务等等。在上面的例子中，我们用
HTML Widget 实现了一个连接 IBM 网站的简单的服务。而在真实的 Web 2.0 网银系统中，银行所提供的服务可能会有成百上千项，这需要一种合理、有效的的管理机制，一方面能灵活有效地组织服务，另一方面能有极强的扩展性和对个性化良好的支持能力。所以在
Web 2.0 的下一代网银中，银行服务库和用户服务列表用来组织、管理银行服务同时向用户提供个个性化的支持。
银行服务库中包含银行提供的所有服务，这些服务都是通过参数配置 Widget 定义的。用户会在页面上看到服务列表，服务列表是银行服务库的一个子集，银行可以根据用户的个人信息、交易记录等向用户推荐服务列表，同时用户可以根据自己的需求从银行服务库中选择相关的服务添加到自己的服务列表上去。服务库和服务列表上的服务会被分类组织，如图
8 所示。
此外，用户的服务列表还可用于数据挖掘以便于银行更好的了解客户、发现商机。
图 8. 服务库和服务列表
上一节中提到每个用户可以从银行服务库中选择所需服务并添加到服务列表中，同时银行也会根据用户的情况为其推荐一些服务列表，服务列表中的服务将是银行服务库的一个子集，这里用户看到的银行服务库实际上也不完整，银行会根据用户的情况为其生成服务库。所以这就包含这两层的个性化服务管理，一层是服务库的生成和服务列表的推荐，另一层是服务列表的选择。对于服务列表的选择，网银系统只需要在服务器端为用户服务列表提供持久化的功能，因为服务列表的选择是由用户自己完成。而服务库的生成和服务列表的推荐则需要网银系统来负责。所以为了能有效的实现个性化服务管理，基于
Web 2.0 的网银架构使用角色将服务的访问权限和推荐管理起来。一个角色定义了其所包含的用户允许访问的银行服务，同时也指定了在这些允许访问的服务中，哪些将会被推荐给用户。每当一个用户进入银行系统时，他就会被赋予一系列的角色，而通过这些角色所包含和推荐服务的并集，网银系统就可以帮助这个用户构造其特有的服务库同时做出准确的推荐。用户可以在银行的推荐的基础上来定制自己的服务列表。
一个用户所具有的角色将根据用户的个人输入、帐户信息、用户信息、交易记录等来确定。而一个角色的定义及其所能包含和推荐的服务则可以通过一些
Eclipse 或 Web 上的工具来完成。
随需定制的网银工作台是基于 Web 2.0 的下一代网上银行用户登录后进入的界面，是以服务为中心的网页工作台，是网银服务和
Widget 的容器和展示平台。通过 Widget 标准，工作台可以方便地整合各种服务，包括网银交易服务以及各种第三方的服务。
工作台结构如下图所示。典型的网银工作台是由服务列表和工作区组成的。服务列表是用户定制的树状列表，展示了当前用户定制的所有服务。点击服务后，相应的服务会展现在右侧的工作区中。工作区的布局是分层次的：工作区页面包含标签页；标签页中包含多个列；列中包含很多个行；每个行就是一个服务
Widget 的容器。
图 9. 工作台结构
个性化是 Web 2.0 的基本特征之一，基于 Web 2.0 的下一代网银工作台采用灵活的布局管理和服务管理机制，使得用户定制界面变得容易，个性化的特征更加明显。随需定制的网银工作台体现了对用户需求的理解和满足。基于随需定制的工作台，银行可以更容易地区分客户，从而能够做到在正确的时间提供正确的服务给正确的客户。
工作台的定制主要体现在 3 个方面 :
- 定制个人服务列表
传统的网银，界面复杂，服务繁多，大部分服务都是用户不经常使用的或不感兴趣的，用户登陆后往往需要花费很长的时间搜索自己需要的服务。基于
Web 2.0 的下一代网银工作台允许用户订阅自己感兴趣的服务，从而减少了无效搜索服务的时间。
- 定制界面布局
传统网银的界面布局是固定的，但用户的使用习惯却有很大的不同，固定布局无法满足所有用户的喜好和要求。基于
Web 2.0 工作台灵活的布局管理允许用户定制个性化的布局，满足用户不同的使用需求。用户定制界面包括以下几个方面：
用户可以自由地添加标签页，修改标签页的标题和图标 , 排列标签页；
在一个标签页中，用户可以添加列，调整列的宽度；
用户可以把服务加入特定的列中，可以把 Service Widget 拖动到其他列中，可以对 Widget
进行最大化和最小化。
- 定制界面风格
用户可以定制界面的语言以及界面风格。通过切换风格，网银界面的颜色，字体等元素都可以轻松定制化。有经验的用户可以编写自己的系统风格包，方便地切换系统风格。
基于 Web 2.0 的下一代网上银行基于 XML Layout 技术，每个用户的界面和工作区都通过
XML 文件进行描述，不同的用户有不一样的 XML 描述文件。该 XML 文件被引擎解析并生成相应的用户界面。用户的定制后的工作台服务和界面可以保存。下次登录后，自定义的用户工作台就能重新展现。通过
XML 文件进行用户服务列表和界面布局的描述。每个用户都有各自的服务列表 ServiceList.xml
文件和 界面布局 Layout.xml 文件。其中，ServiceList.xml 文件保存用户定制的服务列表；Layout.xml
保存用户定制的界面布局信息。用户登录后，系统解析对应用户的 XML 文件，生成个性化的工作平台。用户对平台进行修改并保存后，系统将变更写入对应用户的
XML 文件中。
在基于 Web 2.0 的下一代网银中，存在着两种交易开发模式。一种是直接将银行的所要提供的服务定义成
Widget，比如一个转账服务的 Widget 或是一个基金查询服务的 Widget，基于这种方式开发交易的过程与前面介绍的开发
HTML Widget 大体上相同。不同之处在于，交易服务的 Widget 需要在 Widget 的 XML
定义文件中填入交易页面的内容，所以 Widget 定义中的内容会比 HTML Widget 多，另一方面交易服务
Widget 需要网银渠道提供对 Web 2.0 方式接入的支持，如支持 XML 或 JSON 格式的数据传输。另外一种交易开发模式是首先用传统的
Web1.0 的方式将交易开发出来，再借助 HTML Widget 将交易发布到 Web 2.0 的平台上，这种方式能够简单方便的将传统网银的交易直接转换为
Web 2.0 服务。
与 Widget 定义的思路相同，对交易内容也可以用 XML 的方式进行定义，即包括单独的操作也包括由几个操作串接起来的操作流，在操作流里面还可以加入页面展现从而形成一个页面逻辑流。下图给出了这三种定义形式。
图 10. 交易内容定义的三种形式
将 Widget、服务和交易内容都用 XML 的格式定义有利于得到图形化开发工具的支持，比如通过拖拽的方式定义页面逻辑流中的页面状态、操作等等。这些开发工具可以极大地加速基于
Web 2.0 的下一代网上银行系统的开发过程。
本文介绍了基于 Web 2.0 的下一代网上银行前端的基本架构和元素，包括：Widget、服务、服务列表、服务库、工作台、交易内容等，阐述了其中的设计思想和架构方式。架构的实现可以使用
IBM 的支持 Web 2.0 技术的前端产品，如 Websphere Multichannel Bank
Transformation Toolkit（WMBTT）、Lotus Mashup、Websphere
Portal 等等，她们都会对本文所描述的框架和元素提供一定的实现和支持。更值得一提的是，WMBTT 在提供了
Web 2.0 框架的支持同时还提供后端的运行时框架、各种开发工具等等。本系列的接下来的几篇将会围绕着基于
Web 2.0 的下一代网银介绍前端创新型设计、智能渠道的整合、创新型应用模式、后端智能支持，通过这些设计方式可以打造一个完整的智能化的基于
Web 2.0 的下一代网上银行。
| 
