- 16
- 0
- 约2.8千字
- 约 5页
- 2018-04-07 发布于北京
- 举报
专家视点 ·聚焦
栏 目编辑 粱春丽 E-mail:liangtizi505@l63corn
间共享。IFX规范为金融机构、服务 干个子服务,把子服务转发给相应 (四)服务交付层的架构
提供商和软件开发商提供了一个数 的服务构件去完成。 服务交付层的基本架构是由一
据交流的通用模型,把银行的各种 3.服务流程控制 组结构大致相同的程序组成,这一
服务、支付、管理活动的交易信息 对于复杂服务,服务交付层一 组程序可以称之为服务交易引擎。
归纳为约300对标准报文。目前IFX 方面要把服务分解成若干个子服 其中每个程序与流程相似的一组交
已经发展为使用最普遍的电子银行 务,另一方面要按一定的顺序把这 易相对应,而每一组流程相似的交
标准。 些子服务交给相应的服务构件。因 易通常对应一个标准报文。
(三)标准的功能 为各个子服务之间通常有一定的因 服务交付层还有一组与交易相
服务总线只提供有关服务的管 果关系,前一个服务的输出往往是 对应的配置表。交易引擎就是通过
理功能,如服务分析、服务分拆、服 下一个服务的输入。所以服务交付 检索配置表解释其中内容,以确定
务转发、服务流程控制、服务路 由 层还要控制整个服务流程的走向。 交易的具体处理内容、服务流程、
控制、服务结果返 回等,不提供服 因为服务流程比较长,每一个环节 服务构件、服务路由、服务返回代
务本身的服务功能。也就是说,所有 都会出现一些使业务流程不能正常 码等。
业务功能全部交给其他业务应用系 完成的事件,有些是由于提交的服
统实现。 务要求没有完全符合业务规则,如 三、企业级总线与总线结构
1.服务分析 余额不足等,也可能是环境的原因, 建立了上述的服务总线后,就
通常,应用系统的客户通过应 如网络问题等。当某一个服务环节 解决了应用系统大板块之间的松耦
用系统的各种人机交互界面,向应 出了意外,整个服务流程也许不能 合,实现了宏观的总线架构。其实,
用系统提交服务要求。该服务要求 完整走下去,需要转到另外的错误 总线结构可以在应用系统内进一步
通过系统的各种渠道送到系统的渠 处理流程。 展开。
道整合层;渠道整合层把客户各种 4.服务路由控制 随着应用系统的业务处理系统
各样的服务要求整合为标准的服务 服务交付层要把各子服务转 不断发展,其处理不但覆盖了核心
申请报文,送到服务交付层。这些标 发给各服务构件,要解决服务构件 银行业务,还包括了客户管理业务、
准报文的头部通常都有相应的服务 的物理位置和逻辑名称。根据SOA 代理业务、内部管理业务等。所有这
交易代码或功能代码。服务交付层 松耦合的概念,松耦合既包含了软 些业务可以分类组成若干个大的业
通过对交易代码的分析,就能知道 件模块之间的松耦合,也包含了软 务板块。其中有一些板块不仅包含了
本服务申请的具体服务要求。 件与硬件之间的松耦合。应用系统 许多业务,且板块内部的各种业务相
2.服务分拆与转发 的架构不强求规定哪一项服务配 互间关系比较密切,与板块外部业务
服务交付层知道了服务要求的 置在哪种机器,也不强求规定该机 的关系则相对松散。对于这些大的
具体内容后,把服务交给后面的
原创力文档

文档评论(0)