移动BOSS系统总体技术架构设计Word格式文档下载.docx

移动BOSS系统总体技术架构设计Word格式文档下载.docx

《移动BOSS系统总体技术架构设计Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《移动BOSS系统总体技术架构设计Word格式文档下载.docx（8页珍藏版）》请在冰豆网上搜索。

日期

变动听

批准日期

批准人

*变动状态：

建立,修改,增加,删除

修订表3

第1章前言5

1.1目的范围5

第2章总体技术架构设计6

2.1技术架构6

2.1.1架构图6

2.1.2架构说明6

2.2SFC（ServiceFlowControl）7

2.2.1解析引擎核心模块（Runner）7

2.2.2图形化工具7

2.2.3支持的服务类型7

2.2.4服务流程引擎数据库（SFC-DB）8

2.2.5服务流程描述语言（SFDL）8

2.2.6SFC的优点8

2.3客户端开发8

2.4业务与服务9

2.4.1业务与服务流程9

2.4.2服务间状态9

2.4.3服务的事务10

2.4.4服务层的粒度10

第1章前言

1.1目的范围

本文档用于描述江苏移动BOSS系统1.5版总体技术架构.BOSS1.5总体架构是公司移动支撑网产物的基础技术架构,结合SOA思想,同时兼顾到未来可预见的架构扩展特性.

第2章总体技术架构设计

2.1技术架构

2.1.1架构图

图表1

2.1.2架构说明

结合目前BOSS系统情况,BOSS1.5总体技术架构如上图所示,包括四层：

1、界面层：

该层直接面向用户,将forms展现给用户,而且完成与用户的交互功能.forms主要可以分为三种类型：

UnixForms（UNIX系统下的字符页面）、WindowsForms（WINDOWS系统下用Delphi开发的页面）、WebForms（浏览器下页面）.该层可以分为两类,一类是表达型,自身生成页面及页面逻辑；

另外一类为解析型,通过接入层生成页面及页面逻辑,在解析后展示.

2、接入层：

该层负责接收界面层的业务请求并通过调用服务流程控制层完成业务功能响应给界面层.在界面层为解析型的情况下还要负责生成页面及页面逻辑响应给界面层.

3、服务流程控制层（SFC）：

该层负责接收接入层的业务请求并根据配置的业务模板对业务进行分解,并调用相关的服务来完成完整的业务功能.

4、服务层：

该层负责完成具体的应用功能,面向业务,以组件化的方式分布.

2.2SFC（ServiceFlowControl）

2.2.1解析引擎核心模块（Runner）

Ø

按预界说的服务流程执行各个服务

管理整个服务流程生命周期中的状态

管理业务中的事务

服务流程Cache（性能优化）

流程控制（循环、分支）

2.2.2图形化工具

服务界说、服务流程界说

服务流程控制、管理

服务、服务流程的管理布置

监控

2.2.3支持的服务类型

以插件的形式扩展,屏蔽服务的通讯协议与数据格式,具有很好的灵活性与扩展性,支持的类型：

TongEasy交易中间件提供的服务

Tuxedo交易中间件提供的服务

WebService

DLL服务

Socket服务

其它服务

2.2.4服务流程引擎数据库（SFC-DB）

以内存数据库形式寄存以下信息：

服务界说

服务流程界说

性能信息

管理、布置配置

2.2.5服务流程描述语言（SFDL）

拜会文档《服务流程界说语言概要设计》.

2.2.6SFC的优点

将交易中间件客户端从界面层剥离,界面层面向的是一个通用的类似SOA架构,不用考虑业务的具体实现.原先界面层占用的资源（如数据库连接）变少.以后可以很方便的向SOA架构过渡.

静态配置和定制业务,不用考虑展现层,开发简单,升级容易,维护管理方便.

业务层对外接口统一,面向应用以业务的方式来开发、布置服务,可以降低服务耦合度、提高整个系统的柔性、最年夜水平的复用服务.

使用插件的方式屏蔽服务的协议与数据格式的不同性,灵活的扩展,不用依赖于某个交易中间件.插件的实现可以采纳各种语言实现.

简化界面层的布置,真正做到瘦客户端,并采纳标准的HTTP/XML协议与SFC进行通讯,以后可以很方面的过渡到soap协议.可支持http代办署理,并可越过防火墙,可轻松实现远程接入.

开发人员分工明确,使用统一接口,更易于开发.

实时监控服务流程使用情况与系统压力,根据统计信息可以分析指标参数.

2.3客户端开发

根据分歧客户端类型,可采纳Delphi开发Windows下客户端,采纳C/C++在Unix下开发CUI或接口应用类型的客户端,采纳HTML/Java开发Web类型的客户端.

2.4业务与服务

2.4.1业务与服务流程

一个业务实质上就是一个服务流,业务是通过描述一个服务流的形式实现的,与服务的具体实现形式无关.业务的接口与具体的服务的接口无关（虽然都是XML格式暗示）.事务鸿沟：

业务.

2.4.2服务间状态

组成一个业务的服务是否每个都被调用、以及调用的顺序是由业务规则来确定的.服务之间的调用、参数传递形成了服务间的状态交互活动.

如果直接调用增年夜了服务间的耦合度,一般的配置描述难以表达复杂化的业务过程.

所以引入了服务流程控制层,通过数据耐久化（数据库、XML）来保管服务状态,通过模板定制实现高耦合的参数传递.

2.4.3服务的事务

事务是由交易中间件或者数据库来保证的,在业务的开始发起事务,根据服务执行流程中的状态控制事务的回滚与提交.在一个业务中的事务类型只有一种.一个需要事务环境的业务中,其实不是每个服务都需要事务环境的.

2.4.4服务层的粒度

服务层在开发时面临一个粒度的问题.

如果粒度太粗：

管理、布置容易了

失去了组件化开发的意义：

重用、替换、扩展、配置

分工开发困难

如果粒度太细：

接口设计工作量太年夜

调用条理太深

管理、布置、配置工作量太年夜

设计时应该注意的处所：

服务在设计时应该由规范控制,不能任由开发人员自由设计

服务应基于业务的原子举措