业务系统架构（共12篇）
业务系统架构 篇1
0引言
随着人们生活水平的提高与个体差异带来的观视体验的不同。使得人们对电视的观看由直播向点播转变, 由被动接收改为主动查找方式的变化。这给广电运营带来了新的挑战、新的机遇, 新的业务增长点。目前重庆有线的机顶盒类型多, 版本多, 且后期还有新的终端设备接入现网, 如家庭网关、智能终端、手机、平板、电脑等。而目前的认证平台已无法支撑后续灵活业务部署。在这样的背景下, 就需要一个具有支持多个不同类型, 多种类型的终端接入认证平台, 点播业务认证, 授权平台来支持后续的业务发展。
由此需要替换目前的机顶盒认证系统, 更换具有更强认证功能的系统来支持不同的终端接入。加入互动认证的模块, 支持互动业务的开展。
1系统介绍
新业务认证系统, 应保证目前现网所有的终端的开机流程不做改变的情况下能够正常认证, 除此之外还要支持新的终端。如:家庭网关、智能终端、手机、平板等。且接入的接口应尽可能的统一或限定在有限的个数。具备互动业务的认证、鉴权、询价、点播确认等功能支持点播业务的开展。同时支持为促使用户点播、满足市场的推广策略系统应具备一些优惠策略。如时段优惠、片源优惠、订购优惠。
1.1系统范围
SSO (单点登录认证) 认证服务是互动业务认证系统的子系统, 位于用户 (STB/PC) 和双向互动服务簇之间。担负终端用户身份认证、请求接入、业务路由等功能。也为后台管理系统提供管理员登入的身份认证。为信息认证系统提供终端认证凭证的管理和校验, 代理服务凭证的发放和校验。如图1所示。
本系统不参与处理信息系统的具体业务, 也不负责数据的维护。本系统不侵入其他系统的代码中, 只是负责过滤和检测。
1.2总体介绍
互动业务认证系统主要完成互动业务的验证、授权和记账。其主要功能用于管理何种用户可以访问何种对应服务设备的权限, 具有访问权的用户可以获得对应服务为那些。如何对正在使用的系统资源的用户所使用的资源数量进行记录。具体为:
1.验证:完成对用户身份的确认, 确认用户是否可以获得对应服务的访问权限。
2.授权:定义用户可以使用哪些指定资源的存取权。
3.记账:记录用户对各种网络服务的用量, 并提供给计费系统。
首先, 认证部分提供了对用户的身份的确认。整个认证环节是采用在终端输入用户名与密码的方式来进行用户身份的权限审核。认证的原理是每个用户都有一个唯一的权限标识。由业务认证服务器将用户的唯一标识同后台数据库中所有用户的标识进行逐一比对。如果符合, 则返回认证通过。如果不符合, 则拒绝对用户提供后续业务连接。
接下来, 用户需要通过获取响应授权来获得对应服务的权限。比如, 登陆系统后, 用户可能会执行查询来进行自身相关信息的查询, 授权会在这一过程中检测当前用户是否拥有执行这些命令的权限。授权过程是一系列控制策略的组合, 主要用于确定服务的种类或质量分别为那些, 用户所被允许使用的服务有哪些。一旦用户通过了认证, 他们也就被授予了相应的权限。
最后一步是记账, 这一过程将会计算用户在使用服务过程中消耗的资源数量。
验证授权和账户同样由业务认证服务器来提供。业务认证服务器是一个能够提供这三项服务的程序。
2系统架构方案
2.1系统运行环境
依赖本认证系统的应用是各种应用的增值系统, 所以本系统也发布为Tomcat下的http/https服务与后台服务的web service服务两种方式, 方便与其他系统的灵活集成与接入。
2.2系统部署架构
如图2所示。
2.2.1系统服务网络
负载均衡器:负载均衡器能够支持各种各样的负载均衡策略。大大提高各节点网络的性能和可靠性。
防火墙:防火墙对系统的后台服务器进行保护, 其防范对象是来自公共网上的对后台系统安全的威胁;
局域网交换机:实现对认证系统的服务器、BOSS系统、VOD平台等的互连, 可以在此划分VLAN。
2.2.2应用系统主机和存储系统
统一认证服务器:存储用户认证信息, 并提供目录服务;完成所有地区的用户使用互动业务、增值业务及未来其他业务的统一认证和授权处理, 配置4台服务器, 通过负载均衡服务器实现负载。
SSO管理服务器:负责同终端接口进行对接, 保证现网终端版本无需升级;配置2台服务器, 考虑负载均衡。
开发测试服务器:用于软件版本上线前的现场的开发、测试。
3系统总体设计
3.1业务功能
如图3所示, 业务认证系统会对接很多的外围系统, 包括企业内部的运营支持系统、BOSS、客服、网管、支付。对外的增值系统, 信息平台, 游戏平台, IMS系统等。
业务认证系统包括如下几个模块:系统管理, 统一会员管理、业务认证、用户管理、合作伙伴管理、业务管理、产品管理、订购管理、统计分析, 外围接口。
该方案可将不同系统的不同账号通过统一会员管理将账号统一, 避免由于系统过多导至用户需要记住大量的账号与密码的问题。进行模块化划分与开发, 各个模块的边界与功能进行清楚的界定, 有助于各小组专注于本模块的功能、性能开发。
针对业务我们根据功能与职能不同分别设计了三个模块。SDP (业务分发平台) 、SSO (单点登录认证) 、AAA (认证平台)
SDP:提供外围系统的接入能力, 并进行用户管理, 订购管理等, 采用java开发, B/S模式。
SSO:提供终端的开机认证能力, 包括登录, 开始登录。采用C++开发, 只提供后台服务。
AAA:提供包括点播在内互动业务内证的认证、授权、计账。包括优惠策略的计算。采用C++开发。提供后台的认证服务。
3.2总体架构
系统内部架构如图4所示。
统一业务认证的建设目标是为互动业务平台、相关增值业务系统提供可扩展的、稳定的、高效的认证、授权和记账服务。
通讯协议处理部分功能:该模块用于接收第三方系统认证通信请求, 并将经过认证系统处理后的认证结果返回给第三方系统, 需支持WebS ervice、TCP/IP、UDP等不同种类通讯协议。
格式解析处理部分功能:用于第三方系统发送过来的认证请求数据包根据接口协议进行内容解析, 其中包括对第三方数据来源校验、属性解析等部分;对认证完成后的数据按照同第三方系统约定的格式进行封装。
认证授权记帐处理池:对已经通过解析处理模块后的认证请求进行具体的业务或服务的认证、授权、记帐处理。该部分涉及到大量的策略计算、数据查询修改等操作, 是认证业务最核心部分, 在该阶段采用多线程并行处理机制。
公用功能:分为系统日志、配置功能界面、注册重载几个功能。
数据存储MyS QL:用于存储认证运行中的临时数据, 包括用户token, 用户基本信息、用户订购信息、产品信息、资费信息、服务信息、服务供应商等信息。
3.3业务流程设计
开机业务流程如图5所示。
说明如下:
1.终端通过携带智能卡号询问登录;
2.SSO生成随机token返回给终端;
3.终端将密码与和token进行组合加密发回至SSO进行密码验证;
4.SSO验证通过, 返回给终端访问首页。
首页分发业务流程如图6所示。
4技术要点
4.1设计思想
在设计时参考已有的成熟的开源软件, 吸收其成熟的架构。同时, 充分利用原有系统的工作成果, 在原有系统的基础上, 融入先进的解决方案。基于以上的改进和扩展, 划分出终端认证管理、门户负载调度、启动以及SOAP认证服务/客户端等模块, 与SSO核心模块共同构成SSO认证服务。
系统前期开发, 负载均衡采用较简单的平均分配原则。认为所有portal服务器的配置相同, 负载能力相同。在请求到来时, 转发分配给用户一个指定好的某IP段的portal服务器。
点播业务的量与频率会非常高, 需充分考虑到程序的处理能力可使用C++语言进行程序编写进行细粒度的控制, 提高程序执行效率。
4.2关键技术介绍
4.2.1 Web Service技术
Web Service是一种新的web应用程序分支, 通过Web通讯协议及资料格式的开放式标准 (例如HTTP、XML及SOAP等) 来为其他的应用程序提供服务。部署Web Service以后, 其他Web Service应用程序可以自动发现并调用其提供的对应服务。Web Service的主要体现的便利性为跨操作系统和业务平台的互操作性。因此, Web Service完全基于XML (可扩展标记语言) 、XSD (XMLSchema) 等并独立于操作系统平台和独立于软件规范标准的新平台。
Web Service通过wsdl格式文件来定义同不同服务之间通讯所使用到的接口名称、动作、传输的数据类型。服务端和客户端可以依据定义好格式的wsdl文件来用工具依据协议规范独立的生成代码框架。
4.2.2 Memcached技术
Memcached是一个高性能的分布式内存对象缓存系统, 主要用于动态网页应用, 以减轻核心后台数据库负载。它通过在内存中缓存数据和对象来减少读取核心后台数据库的次数, 从而提高用户访问网站的响应速度。其客户端可以用任何语言来编写, 并通过memcached协议与守护进程通信。
系统中用到的基础数据配置、用户登录token都存储在memcached中, 这样大大提高了开机认证的过程的响应时间, 提升用户体验。
4.2.3 Hibernate技术
Hibernate是一个开放源代码的对象关系映射框架, 它对JDBC (Java Database Connectivity Java数据库连接) 进行了非常轻量级的对象封装, 使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate不仅负责从Java类到数据库表的映射 (还包括从Java数据类型到SQL数据类型的映射) , 还提供了面向对象的数据查询检索机制, 从而极大地缩短的手动处理SQL和JDBC上的开发时间。同时Hibernate可以在应用EJB的J2EE架构中取代CMP, 完成数据持久化的重任。
使用Hibernate来管理对象和关系数据库的映射, 使得开发人员在开发中不用去考虑数据的检索和修改SQL, 而由Hibernate来做中间的转换。
4.3技术架构特点
4.3.1灵活接入多业务
随着广电行业的发展, 在业务上也呈现出业务的多样性。直播业务, 互动业务, 游戏业务、开机能力业务等等。而这些业务的认证、鉴权没有一个统一的平台进行管理、某些甚至是空白。从目前与今后的发展来看, 业务会不断增多、接入终端也有很多种。
系统正是基于这样的背景而设计开发的。业务认证平台支持不同业务的接入, 如:机顶盒开机业务, 点播业务, 游戏业务等。系统的认证、鉴权都是基于标准的WebS ervice协议的。只要终端可以过通接口调用服务就可以进行业务的认证、鉴权。而不关心具体的终端。终端可以是手机, 电脑, 智能机顶盒, PAD等等。
4.3.2不同业务认证模式灵活
认证模式灵活是指对于开机的机顶盒是否是广电设备进行认证的不同模式。一种是严格检查模式确认已有终端的存在关系, 只有现网的, 并存在于系统中的终端才能允许接入。而非广电系统中的终端不允许接入。另一种是免认让模式, 只要是来询问的设备都认为是合法设备可以接入广电网络。
4.3.3支持OTT类业务
OTT是“Over The Top”的缩写, 是指通过互联网向用户提供各种应用服务。这种应用和目前运营商所提供的通信业务不同, 它仅利用运营商的网络, 而服务由运营商之外的第三方提供。OTT同时也是国际互联网运营商对互联网电视机顶盒业务的“昵称”, 其本质是利用统一的内容管理与分发平台, 通过开放的互联网, 向智能机顶盒提供高清的视频、游戏和应用, 是全球性的“云电视”技术系统架构, 例如将通过互联网传输的视频节目传输到TV上, 终端可以是电视机、电脑、机顶盒、PAD、智能手机等等。
4.3.4认证系统进程的单点故障防范
在业务认证系统中, A1主机和A2主机上各起一个实时计费进程, 两个实时认证进程均能独立实在业务认证系统中, A1主机和A2主机上各起一个实时计费进程, 两个实时认证进程均能独立实现实时认证的功能。
认证进程配置两个实时认证进程对应的地址和端口, 在发送请求时采用随机均衡发送。
当有某个进程连接异常时, 将该连接标志为异常, 所有请求均从另一个连接发送。同时间歇探测异常连接是否可重新使用。
5业务认证平台发展方向
5.1广电业务互联网化
目前认证提供的客户群体主要是广电在网终端用户, 受众群体存在一定的局限性。互联网化是将更多的客户引入到系统中来, 而非局限在广电网络内的客户。通过会员注册的方式, 将大量游离客户纳入到系统管理, 通过广电特有的一些服务将客户吸引进来。后续可推出大量的增值业务, 系统加入多样的第三方支付, 来方便客户的支付。业务认证平台可对接各式各样的外围系统, 可收集各系统对业务认证平台的修改意见与想法, 持续的改进系统, 向着互联网化越走越远。
移动化、娱乐化的互联网业务作为广电业务的发展方向, 在各大运营商都积极介入和发展自身的大众互联网服务, 也同其他互联网业务公司合作, 为广电的客户、互联网用户带来更好的体验, 业务认证系统为多类型的互联网用户接入提供接口, 各类互联网用户通过该平台接入系统, 享受广电的视频、娱乐、游戏等业务。
5.2多维度认证
增值业务平台为互联网用户提供各类认证模式, 不管是匿名用户还是通过账号登录, 以及广电自有用户可以通过客户信息直接进行业务登录, 认证系统为用户提供多维度, 多类型的接入方式, 满足不同渠道的用户登录需求。
5.3互联网支付
互联网用户在享受广电提供的各类增值服务中, 会涉及到费用支付, 特别是对于互联网匿名用户支付业务, 具有偶发性、匿名性、快速性等特点, 这类用户要求支付体验必须便捷、快速、安全等需求, 因此对互联网用户可以采用目前比较流行的第三方支付来保障支付的安全可靠。
同时为了便于支付的统一管理, 在增值业务管理平台对所有的支付进行分类汇总, 如果支付宝支付的账单模式, 可以提供给用户等相关的查询和对账, 账务统一也便于与财务收入的对接和分类汇总, 也为收入和市场提供很好的数据支持。
5.4增值业务接入
除了运营商自身的增值业务, 与运营商合作的第三方增值业务提供方就像增值业务超市一样, 可以为用户提供各类丰富的体验, 在与第三方合作过程中, 双方会在用户数据、业务数据上进行共享和交互, 增值业务平台需要将用户信息, 订购行为通过接口同步到第三方平台用户, 广电用户就可以享受第三方提供的各类增值服务, 通过收入结算方式将合作费用结算给第三方。
5.5与运营商传统核心业务计费系统对接
5.5.1订购同步
广电用户在第三方业务平台注册并订购业务后, 由第三方平台将用户的订购行为同步到增值业务平台, 增值业务平台记录后同步到计费系统, 计费系统按照订购时间、产品等要素进行计费。
广电用户在订购了第三方业务之后, 同步到增值业务平台, 平台记录该订购信息后将其同步给第三方平台进行业务开通激活, 为用户提供实时的服务。
当以上业务在任何一个平台发起退订或者注销后, 都同步到增值业务平台, 由增值业务平台记录后同步给对应的系统, 保障业务和计费数据的一致性。
5.5.2计费话单
第三方系统的计费话单生成之后, 可以直接同步给核心计费系统供各渠道查询, 业务可以经过增值业务平台进行二次的加工处理, 增加必要的要素有同步给计费系统, 对于部分增值业务平台够识别的完整计费要求, 可以直接进行话单的生成和处理。
6结束语
随着互联网化的发展和移动业务的日益月新, 如何为客户提供多样性的增值服务, 提高客户的粘稠度, 就必然需要给客户提供新颖性、趣味性、便捷性的增值服务或第三方服务, 如果进行这些增值业务的统一管理和运营, 就是业务认证系统下一步需要进行的系统性规划建设。
参考文献
[1]李昌金, 陈锦宇.电信企业信息系统统一身份认证平台[J].信息与电脑:理论版.2011 (05) .
[2]李勇.统一认证授权平台的构建[J].成都理工大学.2008.
业务系统架构 篇2
随着农业银行完成股份制改造和公开上市，我国大型商业银行已全部完成了股份制改革，迄今为止，我国主要的商业银行都已经成为上市银行。中国银行业的股份制改造和公司治理结构完善已经跨出了里程碑式的步伐。与此同时，尽管全球经历了百年一遇的国际金融危机，中国银行业的财务状况、盈利水平和资产质量却都已达到世界银行业的前列。然而，新的问题依然被提了出来：中资银行下一步该怎么做？中资银行又如何能经过下一个五年，不仅依然是规模全球第一，而且还能做到质量高、竞争力强，挺拔地屹立于世界银行之林？
笔者认为，借势巴塞尔新资本协议（Basel III），结合我国银行业的实际情况，推行更加规范严格和有效的监管，进一步提升中资银行的盈利能力和抵御风险的能力，构建更为合理的业务基础和更为坚实的财务基础，毫无疑问应当是下一阶段中资银行的重要任务。同时，中资银行应在顺应新的监管要求的同时，积极推进内部体制机制的改革和创新，彻底转变传统的经营理念，彻底改革传统的组织架构，彻底改造传统的业务流程。中资银行应抓住当前和未来一个时期难得的历史性机遇，推动自身实现脱胎换骨式的组织架构改革和业务流程的改造，也只有这样才能使相关的监管要求真正落到实处，为中资银行百年基业打下坚实的基础。
当前中资银行在组织架构和业务流程方面的主要差距
虽然中资银行近年来推进了一系列改革，引进了国际著名金融机构作为战略投资者，成功上市等，但与国际上实施以先进架构流程为主导管理模式的商业银行相比，仍然存在较大的差距。
首先，传统的管理理念仍然根深蒂固。虽然随着金融体制改革的不断深化，中资商业银行的经营管理理念已经发生了相当大的变化，新的经营管理理念正在逐步替代传统的经营管理理念。但是许多落后的传统理念依然还有很深的根基。一是“部门利益至上”，不少中高层经营管理人员习惯于用传统的以自我为中心的方法和手段管理银行，部门之间画地为牢、揽权推责的现象普遍存在。二是“官本位”思想一时难以改变，不少经营管理人员处理银行业务往往不愿认真按照流程进行，导致正常的业务流在同级之间衔接困难，往往要由上级来协调才能得以完成。三是地方分支机构负责人“唯我独尊”，习惯于独揽各项资源大权，强调只有权力高度集中才能推动业务发展，实现上级确定的利润目标。这些陈旧的理念给银行内部体制机制的改革创新带来了很大的阻碍。
其次，组织架构和业务流程依然主要沿袭传统模式。一是以客户为中心的组织架构设置虽然已初步成形，前台业务板块总体上已按大的客户类型进行了安排，但在具体环节安排上仍是更多地以产品为中心；二是业务单元自上而下的垂直运作和管理机制尚未形成，主要商业银行的分行作为独立的经营单元“岿然不动”；三是业务流程明显存在弊端，来自部门与区域利益要求的干扰和总行端设计者的脱离实际，导致业务流程中存在较多的不合理和扭曲；四是后台业务集中处理还是十分初步的，虽然部分银行进展较快，但大部分银行要实现前中后台分离与相互制约仍有大量的工作要做；等等。
再次，信息化建设和管理会计等技术条件尚跟不上业务发展的需求。中资银行近年来大力推进了数据大集中工程和管理会计方法的应用，取得了一系列阶段性成果。应该看到，数据大集中为业务的标准化和规范化构建了基础的信息平台，管理会计为业务考核提供了科学的依据。但目前中资银行数据集中主要还只是物理的集中，还未真正做到逻辑集中；与国际上先进商业银行相比，中资银行业务流程的信息化、自动化和智能化水平还较低；管理会计开发还处于起步阶段，真正的使用价值不高，实际业务的大量需求仍未能真正得到满足；中资银行的管理信息系统尚处在较低水平。
当然应该看到，近年来中资银行对组织架构改革和业务流程再造进行了不懈的探索，以客户为中心、以利润为导向，前中后台相互分离制约，纵向经营为主、横向管理为辅的经营管理理念正在深入人心。部分中资银行正在按照上述理念逐步加快了组织架构改革和业务流程再造的步伐；有的中资银行已开始大刀阔斧地实施整体性的组织架构改革和业务流程再造，在前中后台推行了力度较大的条线管理，尽管遇到了不少困难，但依然卓有成效。然而从总体上看，迄今为止只有少数大型银行和中型银行推行了目标明确的改革，中资银行的主体尚处在以传统模式为主的状态。
中资银行组织架构改革和业务流程再造的主要原则
笔者认为，当前和未来一个时期中资银行组织架构改革和业务流程再造应遵循以下五方面原则。
一是坚持以客户为中心的原则。商业银行组织架构改革和业务流程再造首先应坚持以客户为中心的原则，即要按照客户的需求为客户提供最方便和最优质服务的思路，重新安排组织架构与设计各项业务流程，建立能以最快的速度响应和满足客户不断变化需求的运营机制及相关的业务流程；将决策点定位于业务流程执行的地方，在业务流程中建立控制程序，从而消除各部门之间的摩擦，降低管理费用和管理成本，减少无效劳动，提高银行的市场竞争能力。在这里，客户既指银行的外部客户，也指内部的客户，前台客户部门就是后台支持保障部门的客户，银行客户部门的工作质量由银行的客户来评价，银行支持保障部门的工作质量也应该主要由它的客户——前台客户部门来评价，而不应主要由其上级来评价，银行的财务预算、风险管理、会计核算、人力资源等管理部门不能再以管理者自居，而应以支持者和服务者的角色出现。只有建立“一线为客户服务、二线为一线服务”，“总行为分行服务”的经营理念和相应的业务流程，才能从根本上提高银行客户服务水平和市场竞争能力。
二是坚持垂直条线经营为主、横向管理为辅的组织架构的原则。组织架构是业务流程的基础。业务流程再造需要依据一定的原理和基本框架进行设计，这一基本原理就是以客户为中心，基本框架就是前中后台相互分离，垂直经营为主、横向管理为辅的矩阵型的组织架构体系。因此应根据组织架构的大体框架来设计顺畅的流程。
三是坚持部门职责服从于业务流程的原则。业务流程再造强调“组织为流程而定，而不是流程为组织而定”。因此应“先流程后部门”，即先设计好银行的各项业务流程后，再根据流程的需要设置相应的职能部门，将目前的部门职能进行归并和整合，将对流程运行不利的多余、重叠甚至起阻碍作用的部门取消。
四是坚持充分应用先进信息技术的原则。中资银行在集约化经营中对信息技术的利用多限于自动化，即把原来由人干的工作，代之以机器，但整个工序和办事的方式少有改变。这固然加快了处理速度，提高了单位时间内业务的处理量和准确性，但却只是对信息技术最低层次的开发。业务流程再造是银行利用现代信息技术彻底改造业务流程的过程，应超越目前对信息技术主要限于初步的文字、数据和图表处理的阶段，发挥其智能化和标准化的巨大潜力，创新作业程序。
五是坚持突破性再造与连续性改进相结合的原则。尽管组织架构改革和业务流程再造强调根本性和突破性，但不可能通过一项作业而一劳永逸地消除一切问题。对于商业银行来讲，外部宏观政策和经济环境会经常发生变化，内部管理上存在的问题也不是一天两天形成的。因此，在实施组织架构改革和业务流程再造中应避免好高骛远，走入过分追求完美的误区，应清醒地认识到这是一个长期的、不断渐进的过程，不可能一蹴而就。中资银行在业务流程再造时，应坚持整体设计、分步推进的方法，通过不断的连续性的改进，逐步改革组织架构，优化各项业务流程。
中资银行组织架构改革和业务流程再造的主要任务
中资银行组织架构改革和业务流程再造是一项长期的艰巨任务，主要涉及以下四个方面内容。
深化组织架构改革，构建业务条线垂直运作管理和考核为主、横向管理为辅的业务单元制。具体而言，一是进一步以客户为中心梳理和整合主要业务板块，前台应重点根据中资银行的业务构成，建立企业与机构业务板块、零售与私人银行业务板块和市场与资金业务板块，而在中后台形成风控、营运、IT、战略和人事等板块，使这些板块更清晰地按照以客户为中心的要求设置，顺应本外币业务一体化运作的趋势，为流程优化创造条件，打好基础。目前部分主要商业银行已经大致合理划分了业务板块，但在板块内部构成的合理性和分行相应板块协调性方面，仍有进一步梳理完善的空间。二是推进业务条线垂直运作、管理与考核，形成业务单元制。加快推进业务条线垂直运作、管理改革的进程，使事权、人权和财权逐步过渡到以业务单元为主，推行垂直管理为主、分行横向管理为辅的模式；推行全行业务单元的一体化考核，明晰业务单元的绩效；在总行层面形成相对独立的业务单元领导体制，不断加强对分支机构的垂直管理。以条线垂直管理为主、横向管理为辅的模式彻底取代“块块”模式，使组织架构与业务流程更好地相匹配。近年来，部分中资银行在总行层面设置了业务板块或条线的委员会制度，取得了较好的效果。下一步应强化委员会对全行整个条线的协调、管理和考核的职能，以有效推进条线经营管理的步伐。
推进营运条线改革，实施后台业务集中化。成立真正意义上的总行业务处理中心，并根据需要成立若干分中心，包括结(清)算中心、单证处理中心、票据中心、信用卡账户管理中心、放款中心和托管业务处理中心等纯业务操作中心。利用电子影像技术和工作流技术，将过去分支机构处理的后台业务包括复核、授权、审批、单证处理、财务处理和风险监控等工作集中到中心来处理，实现分行前台受理、中心后台处理的运营模式，使基层机构网点成为客户营销和服务平台，以增强客户服务能力、提高运作效率，更有效地控制操作风险。近年来，部分主要商业银行在营运改革和后台集中方面投入了大量的财务和人力资源，取得了明显成效。但主要是新建机构的进展较快，存量机构的后台业务集中仍有待继续推进；营运条线改革尚需进一步清晰目标、大力推进。
实施各项业务流程的整合与优化。在建立以客户为中心，以条线垂直运作、管理和考核为主的组织架构以及集中整合后台业务的同时，开展各项业务流程再造工作，大的方面来说，应主要涉及企业与机构业务单元、零售与私人业务单元、市场与资金业务单元、风险管理、财务管理、人力资源、营运管理以及IT部门等。重新审视这些业务的发生、发展和终结，按照客户便利、简便快捷和以利内控的要求，梳理、优化和整合各项业务流程。这方面近年来中资银行持续在推进，但由于理念、架构等方面的限制，成效不够明显。
实现业务流程的信息化、自动化、标准化和智能化。充分运用先进的电子技术手段，将优化了的业务流程编制成信息化的系统运作程序，使各项业务都转换成自动化、标准化和智能化的电子流，更好地实现高效运作和强化风险控制的目的。从中长期看，中资银行在这方面仍然任重而道远。
笔者认为，上述四大任务之间关系十分密切。以客户为中心是组织架构改革和业务流程再造的内在要求和运作目标，以条线垂直运作管理考核为主的组织架构则是流程优化的基础和条件，后台业务集中化和各项业务流程的优化是业务流程再造的核心内容，而标准化、信息化、自动化和智能化则是业务流程再造实现的重要技术方式。
按照上述任务实施的组织架构改革和业务流程再造，将推动中资银行的运行和管理带来八个方面的提升。一是较好地贯彻以客户为中心的经营理念，优化对客户和银行有附加值的业务流程；二是以纵向顺畅流动的业务流程，保证法人战略意图得以有效地贯彻执行；三是强调业务条线的系统营销和系统管理职能，确保各大单元业务在相对独立的前提下在银行内部顺畅的流动；四是实现从职能管理到面向业务流程管理的转变，将业务的审核与决策点定位于业务流程执行方面；五是形成简洁、高效的业务流程，缩短信息沟通的环节和时间，提高对顾客和市场的反应速度与内部组织运转效率；六是修正流程局部较优而整体偏弱的状况，构筑整体业务流程优化的系统平台；七是形成由流程控制、制度控制、电脑软硬件控制和权限控制组成的立体型风险控制体系，强化风险管控；八是充分运用现代信息技术，实现信息共享、自动识别、分析和决断的作业流程。
组织架构改革和业务流程再造是未来一个时期中资银行进一步深化内部体制机制改革创新的核心内容，也是中资银行提升国际竞争力的重大实践之一。这项改革和创新应结合我国国情和商业银行的实际加以稳步推进，有理、有节和有序地开展。在我国，确实存在着一系列限制组织架构改革和业务流程再造的外部因素，包括不合理的区域管理和行业监管政策等，在技术上也存在某些障碍，当然还存在一系列相关风险因素。但从在中国经营的外资银行已成功地实施先进架构和流程的实践来看,上述制约和障碍不是不可以逾越和克服的。
传统的基础架构阻碍业务创新 篇3
近日，博科（Brocade）公司公布了一项委托第三方调查机构对全球CIO所做的调查报告。这项调查显示，传统的基础架构正阻碍业务敏捷性和企业业务的创新，企业网络需要更富创新性的解决方案。
为进一步对此次调查进行更深入的了解，本报记者独家采访了博科大中国区副总裁于肇烈，他详细分析了当前CIO们面临的挑战以及由此显现出的发展契机。
调查背景
随着新技术的不断出现，企业中IT部门的作用也在变化中，其角色已经从基础架构管理者转变为业务支持者，这是推进创新的全新工作方式，从而彻底改变了客户互动和交易流程。于肇烈认为，在这当中，CIO将发挥比以往更重要的作用，在战略业务投资方面为董事会和高管团队提供咨询。因此，CIO的观点和想法对IT技术未来的发展趋势有着重要的作用。
为此，2014年年底，博科公司委托专业的独立调查机构Vanson Bourne对来自中国、法国、德国、俄罗斯、英国和美国的200名CIO进行了一系列深度采访，以期了解CIO在当今快速变化的IT环境中所面临的挑战。于肇烈介绍说，所有受访者都供职于员工规模超过250人的企业，其中81%的受访者供职于500～5000人的企业。这些企业代表了广泛的垂直行业。在被访问的200位CIO中，来自中国和美国的CIO数量最多，均为50位，其余4个国家均为25位。调查采取了电话深度采访的形式，结合定量和定性回答。
转型趋势中CIO担心什么？
在大数据和云计算时代，企业要想在竞争中生存并获得发展，就必须实现业务和技术上的转型。在业务转型中，CIO考虑最多、最忧虑的问题是什么？在此次调查中，有79%的CIO担心支持业务增长的新服务的交付问题；有77%的CIO则对如何实现数据分析和数据挖掘心存疑虑；而68%的CIO则表示非常担心如何改善整体服务交付；对如何降低运营成本的问题关心的CIO将近2/3。
而对于技术转型，CIO更多的关心是在应用、运营与协作方面。调查数据显示，有68%的CIO表示，他们对“快速部署新应用”非常忧虑；65%的CIO同时表示非常担心“从多种设备快速访问应用”；只有23%的CIO对部署运营平台，如SAP、Oracle等，表示很担忧；接近2/3的CIO认为通信与协作是令人操心的领域。有近一半的CIO表示非常在乎对满足企业诉求的厂商的选择。
对于以上调查数据，于肇烈认为，综合来看，让CIO头疼的问题是如何保持业务正常运转，他们中有超过半数的人要花费50%以上的时间去被动地处理问题，而这些问题最有可能来自网络停机或可用性，这一结果在规模超过1000人的企业CIO中更加突出。于肇烈说，从调查中可以发现，CIO最关注的问题是安全性、快速部署、适应新应用与服务，其重要性甚至超过了大数据与分析、通信与协同办公或法规遵从。而CIO亟需解决的技术问题包括运营平台（Oracle、SAP）、数据中心升级或扩展、虚拟化、安全、网络升级或扩张等。
网络问题突出
无论是业务还是技术，转型已经大势所趋。CIO面临的挑战是如何实现转型，如何从笨重、缓慢、被动变得敏捷、快速、主动；如何在大量数据涌来时，不是任其泛滥，而是实时分析并获取洞察；如何不使IT成为问题，而是变成IT即服务。
于肇烈认为，传统的IT基础架构阻碍了业务敏捷性和创新，成为企业转型的一个重大障碍。此次调查数据显示，有75%的CIO表示，网络是实现企业目标的一个问题，而有近1/4的CIO则表示，网络是一个“重大”问题。于肇烈认为，由此可见，企业转型变革中最大的障碍在于传统的IT基础架构不适应新的需求，而其中最大的症结在于网络问题，“新IP提供了应对这些问题的方法，它能让企业目标得以实现。”于肇烈说。
网络转型推动业务转型
近两年，由IDC提出的第三平台概念得到越来越多厂商和业内人士的认同。于肇烈表示，第三平台带来了网络的变革，而如何变革则取决于使用什么样的新技术，博科则将这种面向第三平台的网络称为新IP。
“简单地说，新IP是业务运营的新方式。它改变了运营商的网络，帮助应对网络流量和联网设备的增加而推高的网络成本。新IP是开放的并由生态系统驱动，让运营商能够快速创新并向客户提供新的高利润服务。新IP无限灵活，因此运营商可以按照自己的方式和时间表实施。各种规模的运营商、教育机构、政府和企业客户都可受益于新IP。通过新IP，运营商最终可以自由地重新思考长期业务模式并迎接IP革命。”于肇烈认为，第三平台与之前的第一、第二平台在规模、架构、计算等方面都存在较大差异，而面向第三平台的网络，即新IP的主要特征包括：动态和自动化、开放与开源、网络层智能、以生态系统为核心，以及创新平台。新IP的这些特征恰恰符合企业业务转型对网络的需求。
于肇烈表示，在新IP中，博科提供了多种解决方案，可以帮助用户迅速、方便地转型，实现网络现代化。
业务系统架构 篇4
截至2014-03, 根据GSA的统计, 有6个LTE FDD网络完成了Vo LTE语音方案的商用部署, 其中3个为韩国运营商;而在1 563款智能手机中, 已经有57款支持Vo LTE, 比上季度的42款增加了35%.
2014年, 各国运营商积极推动Vo LTE商用部署进程。在韩国市场中, 有3家运营商均已商用Vo LTE, 成为了先锋阵营;在美国, T-Mobile近日宣布, Vo LTE在西雅图商用, 并将尽快推广;AT&T宣布, 5月底开始在个别地区商用Vo LTE, 进而将其推广到全国。除了韩国和美国外, 日本NTT Docomo也于近日宣布, 将在2014-06推出Vo LTE商用服务。ABI Research预测, 2014年Vo LTE用户数将达到5 960万, 到2019年, Vo LTE用户数将超过12亿, 超过LTE用户数的50%.
Vo LTE是今天语音和视频通话的增强版, 它充分利用了LTE的优势, 改善了用户的体验, 是LTE话音的最终解决方案, 这也在业界达成了共识。
1 Vo LTE网络架构
Vo LTE网络架构是由E-UTRAN、Evolved Packet System (EPS) 和IMS控制域组成的。E-UTRAN主要包括基站 (e Node B) , 核心网 (EPS) 主要包括MME、S-GW和P-GW等。其中, MME是EPS控制面的实体, S-GW是本地的移动性锚点, P-GW是连接外部分组数据网络的锚点, 并能分配IP地址。IMS包含的主要网元是CSCF。其中, P/I/S-CSCF (call session control function) 为呼叫会话控制功能实体, 主要完成呼叫会话过程中的信令转发、路由和具体控制功能。Vo LTE语音业务网络架构如图1所示。
由图1可知, P-CSCF用于IMS网络的第一个入口点, 用来接收用户的所有SIP信令, 位于归属或拜访网络;I-CSCF作为进入归属IMS网络的入口点, 选择和指派S-CSCF, 位于归属网络;S-CSCF负责SIP注册、会话管理和鉴权、路由选择, 与HSS交互获取用户信息, 位于归属网络。
Vo LTE业务的实现方案是以LTE作为接入和承载的网络, 以IMS作为语音和多媒体等业务的控制网络, 通过PCC (Policy and Charging Control) 架构与EPS协同提供Qo S保障机制, 从而满足端到端的语音业务需求。
2 单小区容量测试实例
2.1 测试目的
该测试主要用于验证在满足相应Vo LTE指标情况下单小区能够容纳的最大用户数。
2.2 测试原理
在LTE中, 将物理资源块 (Physical Resource Block, PRB) 作为空中接口物力资源分配的单位。1个PRB在频域上包含12个连续的子载波, 在时域上包含7个连续的OFDM符号。LTE通过设置不同的子载波数目, 可以映射为不同的资源块 (PRB) 数目。其中, 20 MHz系统带宽的子载波数为1 201, PRB数目为100个。
每个PRB同一时刻一次只能供一个用户调度使用。系统分配给UE的资源在频域上是以RB为单位的, 在时域上是1个或多个完整的上行子帧, e NB可以决定哪个UE在哪个上行子帧发数据, 也可以决定哪个UE在频域上占用了几个RB。这样, e NB可以在时域和频域上对UE资源进行二维的划分。
LTE受PHICH容量的限制, PHICH组=Ng×NRB/100, Ng∈{1/6, 1/2, 1, 2}, 这是由上层决定的。在20M带宽下, PHCIH最大有25组, 而PHCIH组中最大可以承载8个用户的ACK/NACK消息, 因此, 可以计算出200个用户。
2.3 测试参数配置
网络按照支持基于Vo LTE的IMS之Qo S要求配置Qo S参数, 并建立默认承载、信令承载和专用承载, 从而保证Vo LTE话音可以打通, 具体配置如表1所示。
2.4 测试步骤
在测试时, 具体的步骤是:1业务配置为高清23.85 kbps语音速率、静默因子为0.5, 使用上下行3DL:1UL时隙配比;2开启头压缩功能、CDRX功能, 并按照预置条件设置;3终端仿真仪表模拟200个UE在小区正常入网, 200个用户发起高清语音业务, 观察5 min后, 通过终端仿真仪表的log查看每个用户的平均端到端RTP时延是否小于100 ms、端到端RTP时延抖动是否小于40 ms、平均端到端残留丢包率是否不大于1%、高清语音MOS分是否大于3.5;4如果步骤3的200个用户中有部分用户的指标不满足要求, 则以10为步进减少终端数量, 直到所有入网打电话用户的UE都满足指标要求, 观察5 min后, 如果200个用户的指标都满足要求, 则转步骤5;5如果步骤3的200个用户指标满足要求, 则以10为步进增加终端数量, 直到有用户的指标不满足指标要求, 这时就要观察5 min。
2.5 测试结果分析
在实际语音质量评价中, MOS (Mean Opinion Score) 法最常见, 最后的测试结果参考表2作评判。
在终端模拟仪表上经过反复研究和测试, 最终得出带宽为20 MHz时, 宽带语音业务 (语音速率23.85 kbps) 接入成功200UE, 观察5 min后, 得到了大量的测试数据, 如图2所示。
从图2中可以看出, 真正打通电话的用户数为200个, 其平均MOS值为4.463.通过对终端模拟仪表的记录日志的总结得出, 在200UE中, 语音电话失败数为0, 丢包率均小于1%, RTP时延抖动均小于40 ms, 并且RTP平均时延全部小于100 ms。
3 结束语
Vo LTE是各大运营商基于LTE网络的语音业务演进的必然结果, 它不仅拥有传统Qo S保障机制和其语音特征, 还拥有新的语音特性, 高清语音、RCS/RCSe业务特性等。只有Vo LTE拥有非常好的服务质量和用户体验, 才能迎接OTT通信类软件的挑战。当然, 要想实现Vo LTE还需要考虑很多问题, 比如产业链投入成本或网络演进策略等。但是, 考虑到Vo LTE技术能够充分利用先进网络技术的优势, 并围绕相关内容提高用户的感知体验;再加上运营商自身的特点, 相信Vo LTE在未来一定能够被广泛应用。
参考文献
[1]张志林.3GPP LTE物理层和空中接口技术[M].北京:机械工业出版社, 2011.
[2]郑侃, 赵惠, 王文博.3G长期演进技术与系统设计[M].北京:电子工业出版社, 2007.
[3]沈嘉, 索士强, 全海洋.3GPP长期演进 (LTE) 技术原理与系统设计[M].北京:人民邮电出版社, 2008.
系统架构师学习心得 篇5
到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。在很多技术公司里，架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型。如果其对技术一直很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终“修成正果”。
对照自身而言，我不是技术人员出身，目前所从事的工作，主要是担任公司前沿技术，和前沿产品的前期准备工作，但正因为是前沿技术或产品，了解和接触的人很少，这就显示出我的这项工作和系统架构师有着异曲同工的作用，即对之后的产品路线与产品框架的制订有着至关重要的作用。
在经过一段时间的学习后，我对系统架构也有了一定的认识，一名合格的系统架构师应该具备以下几点：
1.系统架构相关的知识和经验。
2.很强的自学能力、分析能力、解决问题的能力。3.写作、沟通表达、培训。
对照我目前的工作，个人认为我同样需要具备以上几个工作特点，首先在调研一项新产品或技术的时候，应该了解该领域的相关知识，做到专业，这样在今后工作中，能够从专业的角度对同事进行帮助。其次，要有很强的自学能力、分析能力、解决问题的能力，才不会在面对新的领域茫然，有自己的解决方法。最后，就是能将自己学到，了解到的付诸于文字，能生成有效的文档，对之后需要接触该领域的同事有借鉴和帮助。
作为系统架构师，必须成为所在开发团队的技术路线指导者；具有很强的系统思维的能力；需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，哪些是无效的。架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善沟通和决策能力强的人。丰富是指他必须具有业务领域方面的工作知识，知识来源于经验或者教育。他必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定那种技术最优，或组织团队开展技术评估。优秀的架构师能考虑并评估所有可用来解决问题的总体技术方案。需要良好的书面和口头沟通技巧，一般通过可视化模型和小组讨论来沟通指导团队确保开发人员按照架构建造系统。
可以看出，成为一名优秀的架构师是需要具备很多素质的，分析自我，我觉得我个人在某些方面还要不断的成长，才能一步步成为一名优秀的架构师，在今后的工作中我也将注重自己一下几点的培养，让自己在工作中更上一层楼：
业务系统架构 篇6
关键词：移动应用；混合模式；软件架构
中图分类号：G434 文献标识码：A 论文编号：1674-2117（2015）15/16-0119-03
移动应用的发展和开发模式
2000年，中国移动互联网诞生，2010年已被业界普遍认为是移动互联网的元年。从2000到2010的十年时间里，中国移动互联网呈爆发式发展，使得在移动终端上使用各种互联网应用渐渐成为一种习惯。移动应用的发展激发了广大开发者进行移动应用创作的极大热情。目前，移动应用开发方式主要分为三种类型：原生开发模式、移动Web开发模式和混合开发模式。
原生开发模式使用移动终端操作系统所支持的程序语言来编写移动应用。目前市场上移动终端操作系统有很多种。因此，要使用原生开发模式开发出一款能够适用于各种操作系统的原生应用，开发者需要花费大量的时间和精力来进行平台间的移植工作，这就决定了采用原生开发模式进行移动应用开发具有周期长、开发门槛高、开发成本高、不跨平台等缺点。当然，原生开发模式也有优点，它可以访问移动终端的所有功能，速度更快、性能更高、用户体验更好，等等。
移动Web开发模式使用传统的Web开发技术进行开发，通过移动终端浏览器进行访问。较原生开发模式，它具有开发周期短、开发门槛低、开发成本低、跨平台等优点，但是移动Web应用是基于浏览器的，无法调用移动终端系统API来实现一些高级功能，用户体验差。
混合开发模式采用Web开发技术，通过中间件包装成各平台的应用程序，可以通过中间件的集成，调用大部分常用的移动终端系统API。因此，混合开发模式同时具有原生开发模式和移动Web开发模式的优点，即具有跨平台、开发门槛低、开发成本低等优点。
校园移动应用发展现状
目前国内各大高校基本完成了校园无线网的基础设施覆盖，为移动终端开展各项应用打开了方便之门。但就目前的情况看，校园的移动应用还存在一些问题，成熟的校园移动应用很少，部分校园移动应用是由学生团体自发组织进行研发，研发过程缺乏统一的规划和科学的工程性管理，可维护性比较差，难以实现可持续发展。要想使校园移动应用更好地、持久地服务于广大师生，就需要构建一个校园移动应用软件架构，学生通过简单的学习就可以进行校园移动应用的开发和维护工作，这样就可以保持移动应用的研发团体相对稳定，也可以保证校园移动应用的可持续发展。
校园混合模式移动应用软件架构的构建
混合开发模式具有开发门槛低、跨平台开发的优点，是今后移动应用开发的主流，也是进行校园移动应用开发的首选。但目前采用混合开发模式的校园移动应用较少，大部分应用仍处于摸索阶段，并没有形成成熟的技术体系。因此，在对基于HTML5的混合开发模式研究的基础上，我们构建了混合模式移动应用软件架构，并应用此架构进行校园移动应用的开发，力求通过使用该架构，探索出校园移动终端应用开发的新途径。
基于混合开发模式的混合移动应用软件架构分为服务器端业务逻辑处理和移动应用UI设计两个部分，如下图所示。
1.服务器端业务逻辑处理
服务器端业务逻辑的处理我们采用了MVC设计模式，在具体的处理上，采用了Spring MVC框架和MySql数据库。为了便于移动应用的数据显示，架构采用了JSON数据交换格式。通过配置Jackson类库，实现JSON的输入和输出，并在此基础上提供了WEBService接口，将处理后的数据转化为JSON格式。采用Spring MVC中的@ResponseBody将JSON数据传递给客户端。这里重点介绍Spring MVC配置、数据库操作和JSON传递的实现方法。
（1）SpringMVC配置
在Java Web项目中导入Spring的类库集，并按照如下内容的配置web.xml文件。
其中DispatcherServlet是前端控制器设计模式的实现，提供Spring Web MVC的集中访问点，而且与Spring IoC容器无缝集成。然后在spring-servlet.xml文件中配置数据库、注解、反射、国际化，并创建Controller、Service、Dao的相关基类，用于被未来MVC中使用的类来继承，通常情况下，基类中配置了日志处理，基本的增、删、改、查的方法，便于最大范围地实现多态。
（2）数据库操作
Spring MVC的Dao层和Service层是处理数据库操作和业务逻辑功能的部分。通过Dao层完成针对数据库系统的增、删、改、查，通过Service层进行业务判断。通过继承JdbcDaoSupport类定义Dao基类，再针对每一个数据结构定义自己的Dao类，这样便于数据独立性的处理，也可以为持久化奠定基础。
（3）JSON传递
Spring MVC支持JSON，一定要引用jackson-core-asl和jackson-mapper-asl的类库，并在Spring的配置文件中，增加如下配置。
public class JsonData {
public List
public JsonData（List
super（）；
this.legend = legendList；
}
}
在服务器端定义如下JSON数据类。
通过Controller类中的方法将数据JSON化。在Controller类中，定义@ResponseBody，直接将JsonData实例传递给客户端就完成了JSON数据向客户端推送。具体实现代码如下：
@RequestMapping（"test.do"）
@ResponseBody
public JsonData test（） {
List
JsonData data=new JsonData（legend）；
return data；
除上述关键点以外，考虑到服务器端向外提供接口的时候，有信息安全的要求，在客户端访问服务器端接口的时候需要通过HTTPS协议进行安全认证，并遵照软件架构的自身要求进行协议握手认证，这样就防止了校园关键信息的泄露和恶意攻击。
2.移动应用UI设计
我们的移动应用UI设计部分采用成熟的JS组件与原生API混合形式进行，当进行普通画面显示的时候，采用HTML、CSS3和JQuery Mobile技术，当需要设备端功能的时候，调用原生API。这里重点介绍获取并显示JSON数据、本地存储和移动应用界面效果的实现方法。
（1）获取并显示JSON数据
在移动应用端获取JSON数据，通常采用ajax方式，这样客户的体验感受会更好，配合Loading的显示，整个移动应用端非常流畅。JQUERY提供了非常完善的ajax方法。下面代码是在Id为show_div的div中显示JSON数据的实现方法。
$.ajax（{
type： "post"，
url： "test.do"，
dataType： "json"，
success： function （data） {
$（"#show_div"）.val（data[0]. legend）；
}，
error： function （XMLHttpRequest， textStatus， errorThrown） {
alert（errorThrown）；
}
}）；
（2）本地存储
为了保证用户在离线的情况下，可以查看本地已经下载完成的数据信息，如校园的新闻信息、课程信息等，需要将一些数据信息保存在本地，保证非实时在线的情况下应用是可用的。我们采用HTML5的存储方式，存储少量数据的时候，使用Local Storage来实现，如果存储的数据偏大，使用Web SQL Database来实现。通过HTML5操作Web SQL Database的openDatabase、transaction、executeSql三个基本方法，分别规定了数据库打开、事务处理、执行SQL语句的使用方式。我们定义了基本的客户端数据库结构以后，通过这些基本方法操作数据库将信息保存在本地。
（3）移动应用界面效果
通过JQUERY Mobile实现客户端的界面效果，主要是将一个应用中的多个Page实现出来，再经过各种效果的页面跳转，构成整个界面风格的主体。
Page是JQUERY Mobile的重要组成部分，由data-role="page"属性产生，每个Page由header、content和footer组成（不是必须的），配合JQUERY Mobile提供的标准控件，构成一系列常用的Page库，这个Page库就是移动应用的UI框架。当然作为后续扩展开发者，可以自定义Page来实现自己的应用界面。
将上述这些功能集成为一套功能集合，就形成了一个混合模式移动应用软件架构的雏形，在此基础之上，开发人员可以更多地关注业务本身，而不需要考虑底层的技术问题，这样既保证了应用的完善性，也将共通性功能进行了最大化的资源共享。
结语
混合模式移动应用软件架构的实现，有利于简化移动应用开发流程，有利于高校移动应用的发展，从而推进智慧校园建设和深化校园移动信息化建设，促进“互联网+”发展战略的实施。后续我们还会将架构的应用引入学生的兴趣社团，将校园移动应用开发的工作以项目的形式组织学生来完成，通过基于项目的实践教学，深化实践教学改革，促进卓越工程师培养计划的实施。
参考文献：
刘欢，张增修，晨辉.华东师范大学：混合开发移动应用[J].中国教育网络，2013（7）：63-65.
业务系统架构 篇7
OTT(Over The Top)业务最典型的特征是,其运营者利用网络服务提供商(ISP)的网络开展新媒体业务[1]。从世界范围来看,全球OTT有三种发展模式:第一种是美国完全以互联网架构为基础的开放模式;第二种是欧洲的兼顾传统广播电视与OTT业务的Hbb TV模式;第三种则是中国强调内容监管的可管可控模式。
1.1 美国开放模式
美国业界将数字电视设备定义为以开放互联网服务为核心的终端,依托浏览器技术实现业务的传递与呈现。在该架构下,传统广电运营商、内容提供商、电信运营商、互联网企业、硬件设备商等产业链各环节均可根据各自的优势条件,直接参与OTT业务的运营。因此,这一进程推动了OTT业务向互联网电视、蓝光播放器、PC、i Phone、i Pad、Android、Xbox、Wii、PS3等多终端的全面覆盖。美国OTT行业的代表企业有谷歌(Google)、苹果(Apple)、Netflix、Hulu等。
1.2 欧洲HbbTV模式
HbbTV(Hybrid broadcast broadband TV)作为一种混合广播技术,其与DVB标准相兼容,除最基本的广播之外,Hbb TV在互动媒体服务方面则有VOD、时移电视、互动广告、在线购物等应用。随着家庭接入网速度的提高和信号质量的改善,基于互联网的宽带媒体也变得越来越可靠。但是欧洲的数字电视运营商认为应该以电视服务为核心,再在此基础上开展数字电视增值业务,对互联网应用需要进行有限度的兼容和采取围墙式的管理。
1.3 中国OTT电视的可管可控模式
中国OTT电视行业的发展必须符合中国国情,内容的可管可控是必须正视的问题。目前,针对互联网电视,国家广电总局采取牌照制的方式保证了对OTT业务的可管可控,由广电总局认可的集成牌照方负责提供内容播控,且互联网电视与牌照方客户端完全绑定,通过牌照方的集成播控平台对客户端实行控制和管理。
2 架构介绍
本文所提出的面向OTT业务的智能电视系统架构,从技术上以嵌入式操作系统为基础[2],通过移植并扩展Web Kit浏览器内核以实现OTT业务的传递与呈现。同时,为遵循我国对开展OTT业务所制定的相关政策要求,本架构在设计上,向互联网电视牌照方及电视生产商提供了网络管理接口层,支持特定的网络接入策略进行二次开发,以实现对OTT业务的可管可控。
在本架构中,基于Web Kit浏览器内核的智能电视应用程序基于Web技术构建,利用Web技术开发应用程序,有着部署成本低、迭代更新快捷、跨平台等优势,开发人员通过编写HTML、CSS、Java Script代码即可实现功能逻辑的跨平台运行。在此种架构中,浏览器内核负责网络通信、内容渲染和脚本解释运行等内部底层工作,并提供人机界面以呈现页面及响应用户交互操作。
本架构自底向上分别为Linux Core(内核)层,Way land层,Qt Lib层,系统管理层和基于Qt接口的Web Ki层,以及Java Script框架层。图1展示了本文所提出的系统架构。
2.1 Linux内核
Linux作为开源操作系统内核,广泛应用于嵌入式系统、移动终端、服务器及个人电脑等领域。选用Linux内核作为底层操作系统主要是由于它的开源特性使得系统可以根据项目的需求进行定制。同时,其在ARM架构和X86架构下都有现成的操作系统作为参考借鉴,例如An droid,Web OS等[2]。
Linux内核层为底层硬件加载了操作系统,且为上层的Wayland提供支撑环境。
2.2 Wayland
Wayland是一个新兴的轻量级窗口管理系统。它的架构使得它可以直接绘制和合成窗口,这样带来的最为直接的好处就是桌面图形的渲染效率将会非常高。这对于智能电视系统架构无疑是一种明显的优势。
同时在最近的GTK+和Qt 5版本中,已经对Wayland提供了相应的接口。图2描述了Wayland的工作模式。
2.3 Qt库
Qt是一套跨平台的GUI程序开发框架,本架构使用Qt的主要原因是Qt对Web Kit的内核封装的较为完善,而且其特有的信号槽技术使得事件处理得到简化。
2.4 系统管理器层
该层基于Qt库,为整个系统提供内容管理、进程间的通信、窗口切换等管理功能。其中的网络接入管理模块(Network Acess Manager)通过调用Qt提供的网络管理库以及相应的底层驱动模块实现对网络接入的管理。在此模块的基础上提供相应的接口,牌照商和电视生产商可以利用接口层针对特定的网络接入策略进行二次开发,以实现对OTT业务的可管可控。
2.5 Web Kit浏览器内核
Web Kit内核引擎包含Web Kit,Web内核和Java Script内核三大部分。Web Kit层为上层应用提供了一个呈现的平台。使得应用的界面通过简单的CSS与HTML标签得到呈现。相较于传统的GUI编程,这无疑大大简化了开发者的工作量。同时,Java Script的“无须编译,解释执行”的特点,缩短了开发周期。
2.6 Java Script封装
Java Script封装层的作用类似于Windows操作系统下GUI编程的MFC[3]。通过对Web Kit层进行内核级的C++扩展开发,使得Java Script具备一些操控底层硬件的功能,并通过封装,为上层的开发者提供API接口,使得应用程序的开发者可以更为方便地进行应用的开发。
3 关键部件设计
3.1 Qt库和Wayland窗口系统的连接
Qt库提供了一个名为Qt-Lighthouse窗口系统的抽象层,为Qt图形库屏蔽了窗口管理系统的异构性,这使得Wayland窗口管理系统对于Qt库是“透明的”。
针对不同的Wayland模块,Qt库也提供了与之对应的封装。在Wayland窗口系统中,Compositor模块向上层提供显示服务,对于该模块,Qt封装了一层Qt-Compositor作为Qt-Lighthouse访问Wayland Compositor的接口。显示信息传递到Wayland-client模块,由Qt-Lighthouse Wayland Plugin接口获取,Qt应用程序就可以利用Qt-Lighthouse Wayland Plugin的API获取到显示信息(如图3所示)。
3.2 系统管理层(System Manager)的结构
系统管理层的功能是管理运行于Web Kit环境之上的多个应用程序及实现对各种资源的调度[4]。
应用程序运行在Web Kit平台之上,其资源的调用需要通过系统管理层。举例来说,应用程序需要打开位于硬盘里的某个文件,则需要向系统管理层发送请求,由其通知文件管理系统以打开文件。除了文件管理,进程的管理、各种应用程序间的通信都要通过系统管理层进行[5]。系统管理层结构如图4所示。
3.3 网络接入管理
网络接入管理由位于系统管理层的Network Acess Manager模块实现,其主要目的是为硬件厂商和内容的提供方提供一个可以操作网络接入方式的有效途径。Network Acess Manager模块将提供一个编程接口(SDK包),这样,便可以通过二次开发,定义网络接入方式、控制网络访问策略,从而对OTT业务在网络接入层面进行管理。
在本文提出的架构中,将提供一个Network Acess Interface抽象类,提供了包括HTTP协议的get请求、post请求、是否接入网络(Network Accessibility)等在内的纯虚函数。内容提供方可以通过继承此抽象类、重写纯虚函数的方法,按照自己的需求定制网络接入服务的具体逻辑。而Network Acess Manager模块提供的只是一种如何与本架构进行交互的“规范”。
3.4 对Web Kit的扩展
原生的Web Kit内核主要针对标准浏览器进行页面解析及渲染,而针对在智能电视终端上开展的OTT业务,需要在其支持标准的,和基础上进行一定的扩展开发[6]。
对Web Kit的扩展主要有两个方面,一是扩展Web Kit从而形成针对智能电视的插件体系,二是扩展Java Script的执行上下文(Execution Contexts)。插件的目的在于使Web Kit的功能得以扩充,完成对智能电视底层资源的调用。而对Java Script执行上下文的扩展是实现Java Script Encapsulation层的基础[7]。
利用Qweb Pluginfactory类,可以定制开发构建出基于Qt Web Kit的插件体系。通过这种方式,可以在Web Kit内核中嵌入用C++扩展的应用程序,实现本地应用程序与基于Web的应用程序交互。例如:可以用C++编写存储介质中音视频文件检索及访问的扩展,通过插件的方式嵌入到智能电视内核中,并通过Java Script脚本与之进行互操作,完成具体业务逻辑。以上思路的实现方法是,在Qt Web Kit提供的API中,向浏览器对象模型(BOM)的根节点window添加扩展对象,以该对象为桥梁,即可实现应用程序的C++模块与Java Script之间的互操作,流程如图5所示。
4 结论
在三网融合及新媒体终端不断涌现等多种因素的带动下,以互联网为基础而形成的OTT业务以其形式多样、内容丰富、交互性强的特点,将成为下一代电视的发展方向。本文提出的以Linux操作系统为基础,以Web Kit内核为核心,通过适当扩展而形成的智能电视架构,因其开放性和可扩展性,为OTT业务的开展提供了技术支撑。
与此同时,在本架构设计中,充分考虑到了对内容可管可控的要求,在网络接入管理层提供了二次开发接口,以支持特定的网络接入策略,保证内容提供方在获得监管部门许可的情况下向用户推送OTT业务。
希望中国OTT业务的开展与相关技术体系的发展能够相互促进,为推动三网融合起到正向牵引作用。
参考文献
[1]BERTIN E,CRESPI N,L’HOSTIS M.A few myths about Telco andOTT models[C]//Proc.the 15th International Conference on Intelligence in Next Generation Networks,2011.[S.l.]:IEEE Press,2011:6-10.
[2]Apple IOS、Android、WebOS系统体系架构对比[EB/OL].[2012-03-03].http://my.oschina.net/zjhe223/blog/13070.
[3]HE Xiangzhen,WU Zhiqiang,MENG Xianghe,et al.Research into mobile learning based on WebOS[C]//Proc.2011International Con ference on Internet Technology and Applications(iTAP).[S.l.]:IEEE Press,2011:1-3.
[4]VAHDAT A,ANDERSON T,DAHLIN M,et al.WebOS:operating system services for wide area applications[EB/OL].[2012-01-03].http://www.cs.berkeley.edu/~culler/papers/hpdc98.pdf.
[5]李阳,黄文明.IPTV中EPG模块的设计与优化[J].电视技术,2011,35(21):73-76.
[6]蒋章概,陈榕.基于CAR构件的WebKit本地扩展策略[J].计算机应用,2009,29(S2):195-197.
业务系统架构 篇8
网上业务系统是企业级应用的核心部分,企业从成本和收益等经济效益角度考虑,通常希望对企业应用程序的开发周期尽量短,而且还要保证系统稳定、高效的运行。这对从事企业应用的开发人员提出了非常高的挑战,若采用传统的从零开始的方法,是必然无法达到这个目标的。因此,在这种需求的推动下,对轻量级架构的研究和实践越来越引起学术界和产业界的高度重视。
2 轻量级架构
目前,J2EE已经成为许多企业应用程序开发的标准,其中的Servlet/JSP,EJB框架等技术已经被广大客户接受并使用,但也存在着许多的不足。J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。为解决传统J2EE架构中的不足和满足企业级开发新的要求,提出了轻量级J2EE架构。一个典型的轻量级J2EE架构,它的Java类都运行在同一个JVM中,业务对象是用POJO实现的,所有对象需要部署在IOC容器中运行,所有的调用都是针对业务接口。Web层是业务逻辑层之上的一个薄层,只负责处理用户输入,并将业务处理的结果展示给用户。数据访问层使用轻量级的O/R映射层,提供透明的持久化。
使用这种轻量级架构,开发过程提高了代码复用度,更好的执行了OO原则,提高了代码的开发效率和可测试性。尤其重要的是,让企业有了传统J2EE架构之外的选择,而这样的选择允许企业可以轻松的缩放规模,而不必修改应用代码,同时降低了开发复杂度,毕竟不是每个企业都需要分布式的,业务逻辑相当复杂的系统。下面以某公司网上业务系统为例,介绍这种轻量级架构的开发模式。
3 系统基本框架
3.1 用户管理模块,包括以下功能
1)管理员管理;
2)实现管理员用户的注册,用户角色权限的分配,用户证书的管理等;
3)参与人及分支机构管理;
4)实现参与人管理、参与人分组管理、参与人用户管理、参与人用户角色分配、参与人用户证书管理等功能。
3.2 栏目信息管理模块,实现以下功能
1)主页栏目管理;
2)主页图片新闻管理;
3)主页市场概貌管理;
4)主页资料管理;
5)栏目资料管理。
3.3 权限管理模块,实现以下功能
1)角色管理;
2)角色资源管理;
3)用户访问权限管理。
3.4 证书管理模块,主要实现以下功能
1)证书申请;
2)证书更新;
3)证书冻结;
4)证书解冻;
5)证书作废。
4 系统实现
4.1 应用层的实现
业务层向表现层提供的接口,根据业务逻辑的不同可分为两类:
*简单性业务逻辑,对象的CRUD操作,如添加用户,更新角色等不涉及与其它类的交互。
*复杂性业务逻辑,涉及到类与类的交互,如为用户添加角色,为角色分配权限等。
1)编写UserManager接口。
2)针对UserManager接口编写测试用例UserManagerTest,测试面要覆盖以上所有的方法。
3)接口UserManager主要是通过调用IBaseDao实现。业务层中的接口和类都是由轻量级容器Spring来配置和管理的。UserManager的实现类是UserManagerImpl,它对IBaseDao的调用采用设值注入的依赖注入方式。在Spring的配置文件applicationContext-service.xml中的配置如下:
4)运行测试,重构
运行UserManagerTest,如测试不通过,再重构代码。
4.2 数据层的实现
系统中应用了Spring中提供的一站式的TransactionProxyFactoryBean对事务进行声明式的管理。其为一个特定的目标类定义了事务语义,但是并不需要建立一个标准的AOP ProxyFatoryBean和TransactionInterceptor。由于本权限管理系统是基于单个的Hibernate SessionFactory的事务,并没有分布式事务处理需求,所以
使用了HibernateTransactionManager来处理具体的业务过程。在applicationContext-dao.xml中配置如下:
4.3 UI层的实现
图1为系统实现界面。
5 结束语
通过本架构,提供了企业开发简单Web应用所需要的服务,克服了传统的基于EJB的J2EE架构所带来的资源的额外开销大,难于测试和成本高等问题。此外,该开发架构还为基于Java平台下企业应用的开发提供了安全模型,通用业务的模板接口和实现类等,具有很强的复用和扩展功能。
参考文献
[1]Java Home Page[EB/OL].http://java.sun.com.
[2]J2EE home Page[EB/OL].http://jav.sun.com/j2ee.
[3]Allamaraju S.Professional Java Server Programming J2EE Edition[M].Wrox Press,2001.
业务系统架构 篇9
关键词：云计算,4A系统,业务支撑网
1 云计算现状
云计算[1]是一种按使用量付费的模式,这种模式提供可用的、便捷的、按需的网络访问,进入可配置的计算资源共享池(资源包括网络,服务器,存储,应用软件,服务),这些资源能够被快速提供,只需投入很少的管理工作,或与服务供应商进行很少的交互。好比是从古老的单台发电机模式转向了电厂集中供电的模式。它意味着计算能力也可以作为一种商品进行流通,就像煤气、水电一样,取用方便,费用低廉。云计算为人们带来便利的同时其安全性也不容忽视:2011年4月22日,Amazon的云计算服务器再次出现大面积的岩机;2009年2月24日,Google Mail邮箱爆发全球性故障,服务中断长达4小时;同年3月17日,Microsoft的云计算平台Azure停止运行约22小时;众多的案例引发了人们对云计算安全的思考,安全问题解决不好,将严重制约云计算的可持续发展,有效解决云计算的安全问题势在必行。
2 基于云架构的业务支撑网技术方案
目前移动业务支撑系统包括BOSS系统、经营分析系统、运营管理系统等子系统,云架构的移动业务支撑系统平台,通过采用iaas私有云技术,把BOSS系统的众多服务器,网络设备,数据库等设备组成“云端”基础设施服务提供给维护人员[2]。并将CPU计算能力、内存、I/O设备和存储整合成一个虚拟的资源池为BOSS业务提供所需要的存储资源和虚拟化服务器等服务。经营分析系统和运营管理系统则通过采用Saa S技术将应用软件统一部署在业务支撑网云平台上,营业厅、客服、渠道、市场部门的营业人员、客服人员、业务管理人员及集团客户经理等用户根据需求通过互联网使用软件服务[3]。
这种模式在为业务人员和维护人员提供快捷便利的同时,业务支撑系统的安全性和保密不容忽视。采用传统4A系统和业务支撑系统相结合后在一定程度上提高了系统的安全性,但仍然存在以下三个问题:(1)账号管理变更频繁,每天营业员、集团客户的权限都有大量的变更需求,不能建立岗位权限互斥的安全模型。(2)随着业务支撑网内应用系统的不断增多,各自独立的缺乏关联分析(以自然人为核心进行关联的统一集中的系统登录、登出、正常维护、异常操作)的审计系统已不能满足需要。(3)在日志量达到T级别后,系统的检索性能急剧下降,无法进行有效的数据检索和日志分析,导致无法实时分析和告警正在发生的危险行为。
3 云架构的4A系统应用在移动业务支撑网
云架构的4A系统[4]在系统架构上划分为三层:统一入口层;云采集层;云审计层。
统一入口层:为普通人员和管理人员提供了Web方式登录界面以及堡垒主机群。
采集层:主要功能是实现用户资源系统之间的数据交互,资源从账号的收集和同步管理,日志采集以及告警数据发送。为了避免出现日志采集遗漏等情况,并提高采集系统的运行稳定性以及日志解析处理能力,通过使用云架构,使采集系统能够支持分布式采集功能,同时引入搜索引擎,以达到优化底层查询逻辑,减少垃圾数据量,提升用户使用好感度。
审计层:统一身份管理,资源及认证管理,账号授权管理,访问控制管理,安全审计管理,安全合规管理,安全事件管理。云架构的审计选择Hadoop作为审计数据分布式处理的技术框架,通过存储方式的变化、存储结构的变化以及分析、检索框架调整,提供高效、多任务并发的数据分析处理能力以及高效的审计数据全文检索能力。
4 该云架构的4A系统应用在移动业务支撑网中的优点
云架构的4A系统应用在移动业务支撑网系统架构图,如图1。
4A认证云平台为业务支撑网各应用系统提供统一、多样化的帐号、认证、授权和审计方面的安全服务机制,主帐号与从帐号实现集中化、基于角色的管理,针对应用资源实现角色级授权;针对系统资源的权限控制实现实体级别授权。自然人通过与主帐号的关联,对身份信息和岗位角色进行统一规划与管理,不同应用系统中的帐号的创建、分配、同步进行集成到4A管理平台进行统一管理,建立起从帐号的单一视图(业务支撑实体资源-应用资源及后台系统资源),以及主帐号的单一视图管理(业务支撑系统中使用者)从而有效的解决了授权变更频繁以及岗位权限互斥的安全模型的建立。
采用基于统一访问入口的主帐号的集中指纹强身份认证方式,并根据用户使用业务支撑网各应用系统中的应用资源和系统资源的具体情况进行相应的权限分配与稽核,实现不同岗位、角色的用户针对对不同部分实体资源的访问权限控制。建立完善的自然人对实体资源的的授权管理。从而解决问题2(自然人登录缺乏相应从账号的关联问题)。
采用Hadoop分布式文件系统(HDFS)的可靠数据存储服务对原始数据进行存储,可以轻松应对PB级的海量数据而且硬件成本低;利用Map Reduce技术的高性能并行数据处理服务可以大大提高运算的效率,从而解决了问题3(数据量超大后缺乏有效分析)。
参考文献
[1]Mell P,Grance T.The NIST definition of cloud coputing.National Institute of Standards and Technology(NIST),Washington,USA:Technical Report Special Publication 800-145,2011.
[2]田峰,等.中国移动业务支撑网4A系统安全技术规范v3.0[S].中国移动集团技术规范,2013,4:88-92.
[3]田峰,等.中国移动业务支撑网数据安全管理办法[S].中国移动集团技术规范,2008,4:1-3.
基于业务应用集成体系架构探讨 篇10
随着互联网的发展, Web的出现使得一种围绕Web服务的计算模式成为当前计算机应用的主流模式, 并推动了软件开发、软件应用、应用集成方式的重大变革。为了更好满足现代企业业务敏捷性需求, 就要创建一个业务敏捷的IT架构, 它不仅可以处理当前的业务应用, 还可以满足未来的业务需求。业务敏捷性是指企业对变更快速和有效地进行响应, 并且利用变更来得到竞争优势的能力。该IT架构能够满足这种业务敏捷性, 同时实践必须遵循“业务驱动服务, 服务驱动技术”的原则。
1 计算模式
随着Web的出现, 原有的集中式计算和客户机/服务器模式表现出很多不足, 已经不能适应Web的发展。人们需要利用互联网, 将应用分布到整个Web中, 而不是局限于企业局域网内部, 这就催生了一种更加灵活的多级分布式计算模式, 即浏览器/服务器 (B/S) 模式。它是一种基于Web的协同计算, 是一种三层架构的计算模式:第一层为客户端表示层, 只保留一个Web浏览器, 其运行代码可以从第二层的Web服务器下载到本地的浏览器中执行;第二层为应用服务器层, 由一台或多台Web服务器组成, 处理应用中的所有业务逻辑、对数据库的访问等工作;第三层为数据中心层, 安装数据库服务器, 负责整个应用中的数据管理。B/S模式比较其他计算模式, 体现了用户可以在任何地点使用系统的良好开放性和相同浏览器界面跨平台访问系统的通用性, 有效降低了整个系统的运行和维护成本。
2 Web服务及其体系架构
Web服务 (Web Service) 是一种新型的软件开发模式, 它可以将软件功能模块封转为Web服务, 实现业务级别的重用和集成。Web服务使用标准化的XML消息传递机制作为基本的数据通信方式, 消除使用不同组件模型、操作系统和编程语言的系统之间存在的差异, 使异类系统能够作为计算网络的一部分协同运行。
Web服务的体系结构由3个参与者和3个基本操作构成。3个参与者分别是服务提供者、服务请求者和服务代理, 3个基本操作分别为发布、查找和绑定, 其关系如图1所示。
3 软件体系架构演变
从计算机诞生到现在, 计算机硬件技术和网络技术在发展的同时, 计算机软件也在悄然地发生巨变。这种变化不仅表现在计算机软件的内涵、应用方式上, 同时也表现在软件的设计模式和开发方法上。软件开发思想的演化, 使得在Web流行的今天, 推动了面向服务的体系架构的产生和发展, 使其成为下一代软件体系架构的主流。
3.1 基于组件的体系架构
1991年, 对象管理组织 (OMG) 发布了公共对象请求代理体系架构 (CORBA) , 它是一种标准的面向对象分布式应用程序的标准结构。它的目的是为了简化开发分布式应用程序的复杂性, 用于创建一个基于对象的跨平台的分布式结构。为了实现上述目标, OMG组织制定了OMA (Object Management Architecture, 对象管理体系结构) 参考模型。该模型描述了OMG的规范所遵循的概念化的结构基础, 其核心部分是ORB (Object Request Broker, 对象请求代理) 。基于ORB机制就可以充分利用分布的、可以互操作的对象构造和可以互操作的应用。这种优势是明显的, 用户可以在不了解实现交互细节的情况下, 建立共享资源的应用。
CORBA可以看作一种软件总线, 它希望一个用户的软件系统是由运行在其上的一个个独立的软件组件对象构成。为了解决代码共享和分布应用问题, 微软分别提出了组件对象模型 (COM) 和分布式组件对象模型 (DCOM) , 在微软的系统上, COM/DCOM发挥了应有的作用。但由于协议开发没有跟进, CORBA的思想实现得并不理想。同时由于互联网是一个存在着巨大异构的环境, 伴随着Web服务的出现, 2000年后面向服务的体系架构 (SOA) 随之兴起, CORBA架构逐渐淡出。
3.2 面向服务的体系架构 (SOA)
SOA (service-oriented architecture) 是面向服务的体系结构, 是一类分布式系统的体系结构。这类系统是将异构平台上应用程序的不同功能部件 (称为服务) 通过这些服务之间定义良好的接口和规范, 按松耦合方式整合在一起, 即将多个现有的应用软件通过网络将其整合成一个新系统。
SOA的体系结构仍旧是三层或N层结构 (如图2) , 但对异构平台各层之间的联系, 不是用CORBA或J2EE的方式, 而且用Web的服务协议来实现, 概念简单统一, 目前都是采用嵌入ESB服务总线的平台来实现, ESB是一个中间件群, 确保系统实现服务功能、各种中间件功能及松耦合连接等。另外, 普遍采用BPEL (业务过程执行语言) 来描述用户需求, 由BPM (业务过程管理平台) 来解释执行。
SOA架构的5个层次分别如下 (按照从下到上的顺序) :①可操作系统:表示现有IT资产, 说明IT投资非常宝贵, 应该在SOA加以利用;②服务组件:实现服务, 可能通过使用可操作系统层中的一个或多个应用程序来进行。如模型中所示, 使用者和业务流程并不能直接访问组件, 而仅能访问服务。现有组件可以在内部重用, 或在合适的情况下在SOA中使用;③服务:表示已部署到环境中的服务。这些服务由可发现实体进行治理;④业务流程:表示将业务流程作为服务编排实现的操作构件;⑤使用者:表示用于访问业务流程、服务和应用程序的通道。
SOA的主要优点:①利用现有的资产。方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值, 而不必重新从头开始构建;②更易于集成和管理复杂性。将基础设施和实现发生的改变所带来的影响降到最低限度。因为复杂性是隔离的。当更多的企业一起协作提供价值链时, 这会变得更加重要;③更快地整合和现实。通过利用现有的构件和服务, 可以减少完成软件开发生命周期所需的时间。这使得可以快速地开发新的业务服务, 并允许组织迅速地对改变做出响应和缩短开发时间;④减少成本和增加重用。通过以松散耦合的方式公开业务服务, 企业可以根据业务要求更轻松地使用和组合服务;⑤SOA业务流程是由一系列业务服务组成的, 可以更轻松地创建、修改和管理它来满足不同时期的需要。
Web Service平台是一套标准, 它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言, 在任何你喜欢的平台上写Web Service, 只要我们可以通过Web Service标准对这些服务进行查询和访问。Web Service的目标是即时装配、松散耦合以及自动集成。
Web Service是技术规范, SOA是设计原则。从本质上讲, SOA是一种架构模式, 而Web Service是利用一组标准实现的服务。Web Service是实现SOA的方式之一, 用Web Service实现SOA的好处是:可以实现一个中立平台, 来获取服务, 获取更好的通用性。
3.3 云计算模式的体系架构
3.3.1 云计算技术
美国国家标准与技术研究院 (NIST) 定义:云计算是一种按使用量付费的模式, 这种模式提供可用的、便捷的、按需的网络访问, 进入可配置的计算资源共享池 (资源包括网络、服务器、存储、应用软件、服务) , 这些资源能够被快速提供, 只需投入很少的管理工作, 或与服务供应商进行很少的交互。“云计算”概念被大量运用到生产环境中, 国内的“阿里云”与云谷公司的XenSystem, 以及在国外已经非常成熟的Intel和IBM, 各种“云计算”的应用服务范围正日渐扩大, 影响力也无可估量。云计算可以认为包括以下几个层次的服务:基础设施即服务 (IaaS) , 平台即服务 (PaaS) 和软件即服务 (SaaS) 。IaaS、PaaS、SaaS分别在资源层、平台层、应用层实现。
3.3.2 云计算模式的体系架构
云计算的体系结构由5部分组成 (如图3) , 分别为应用层、平台层、资源层、用户访问层和管理层, 云计算的本质是通过网络提供服务, 所以其体系结构以服务为核心。
云计算体系架构的5个层次分别如下:
(1) 资源层是指基础架构层面的云计算服务, 这些服务可以提供虚拟化的资源, 从而隐藏物理资源的复杂性。物理资源指的是物理设备, 如主机、服务器、网络设备、存储设备等。服务器服务指的是操作系统的环境, 如linux集群等。网络服务指的是提供的网络处理能力, 如防火墙、VLAN、负载均衡等。存储服务为用户提供数据存储能力。
(2) 平台层为用户提供对资源层服务的封装, 使用户可以构建自己的应用。数据库服务提供可扩展的数据库处理的能力。中间件服务为用户提供可扩展的消息中间件或事务处理中间件等服务。
(3) 应用层提供软件服务。企业应用是指面向企业的用户, 如财务管理、客户关系管理、商业智能等。个人应用指面向个人用户的服务, 如电子邮件、文本处理、个人信息存储等。
(4) 用户访问层是方便用户使用云计算服务所需的各种支撑服务, 针对每个层次的云计算服务都需要提供相应的访问接口。服务目录是一个服务列表, 用户可以从中选择需要使用的云计算服务。订阅管理是提供给用户的管理功能, 用户可以查阅自己订阅的服务, 或者终止订阅的服务。服务访问是针对每种层次的云计算服务提供的访问接口, 如相对应用层的访问, 提供的接口可能是Web。
(5) 管理层是提供对所有层次云计算服务的管理功能:安全管理、服务组合及管理等。
3.3.3 云计算平台具有的主要特征
(1) 资源配置动态化。根据消费者的需求动态划分或释放不同的物理和虚拟资源, 当增加一个需求时, 可通过增加可用的资源进行匹配, 实现资源的快速弹性提供;如果用户不再使用这部分资源时, 可释放这些资源。云计算为客户提供的这种能力是无限的, 实现了IT资源利用的可扩展性。
(2) 需求服务自助化。云计算为客户提供自助化的资源服务, 用户无需同提供商交互就可自动得到自助的计算资源能力。同时云系统为客户提供一定的应用服务目录, 客户可采用自助方式选择满足自身需求的服务项目和内容。
(3) 以网络为中心———云计算的组件和整体构架由网络连接在一起并存在于网络中, 同时通过网络向用户提供服务。而客户可借助不同的终端设备, 通过标准的应用实现对网络的访问, 从而使得云计算的服务无处不在。
(4) 服务可计量化。在提供云服务过程中, 针对客户不同的服务类型, 通过计量的方法来自动控制和优化资源配置。即资源的使用可被监测和控制, 是一种即付即用的服务模式。
(5) 资源的池化和透明化———对云服务的提供者而言, 各种底层资源 (计算、储存、网络、资源逻辑等) 的异构性 (如果存在某种异构性) 被屏蔽, 边界被打破, 所有的资源可以被统一管理和调度, 成为所谓的“资源池”, 从而为用户提供按需服务;对用户而言, 这些资源是透明的、无限大的, 用户无需了解内部结构, 只关心自己的需求是否得到满足即可。
4 结语
不同种类的操作系统、应用软件、系统软件和应用基础结构 (application infrastructure) 相互交织, 这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程 (business processes) , 因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化作出快速反应, 利用对现有的应用程序和应用基础结构 (application infrastructure) 的投资来解决新的业务需求, 为客户、商业伙伴以及供应商提供新的互动渠道, 并呈现一个可以支持有机业务 (organic business) 的构架。SOA凭借其松耦合的特性, 以及云计算强大的资源可灵活配置能力, 使得企业可以按照模块化的方式来添加新服务或更新升级现有服务, 以解决新的业务需要, 并通过不同的渠道提供服务, 从而保护了现有的IT基础建设投资。所以, SOA与云计算相结合的体系架构是业务应用集成的最佳实践平台。
参考文献
[1]郝兴伟.Web技术导论[M].第3版.北京:清华大学出版社, 2012.
[2]卢致杰.SOA体系设计方法研究[J].工业工程, 2004, 7 (6) .
[3]魏东.基于SOA体系结构的软件开发方法研究[J].微电子学与计算机, 2005, 22 (6) .
浅析分层架构视频会议系统 篇11
【关键词】视频会议；分层架构系统
引言
目前主要的视频交互应用主要有以下两种：第一种是点对点的视频双向交互，例如QQ，微信视频等；第二种是多对多的视频双向交互，例如华平、网动、宝利通等视频会议系统。点对点视频不适用于需要展开讨论或者面向用户比较分散的情况，在我们的实际工作中，召开会议时多对多的情况最为普遍，所以下面主要阐述多对多的视频架构。
一、视频会议主要实现目标及问题
现阶段我们基于分层架构的网络视频会议主要为了实现三个目标：低延迟、高质量、低网络负荷。
1.低延迟：双向互动的网络视频会议，音视频延迟是很重要的一个指标。单向的直播会议，参加会议远程接收主会场音视频的与会人员，因为没有参照物所以对延迟的感觉不是很明显。但是在双向互动应用中，对话双方一个发言后过了很久另一方才接收到对方的音视频然后做出回应，首先交互双方就已经感觉到不适，更不用说收看他们进行互动过程的其他用户的感受了。为了使会议能够流畅交流我们一般应将最大可感知延迟控制在1s之内。
2.高质量：以前限于采集设备和网络的制约，1CIF已经是属于网络视频的标准，1CIF相当于352*288的分辨率，像QQ视频因为主要的应用场景就是互联网，基于互联网网络的复杂性，所以他的视频分辨率就只有320*240。目前普通的USB摄像头支持320*240，352*288，640*480等多种分辨率，如果是采用高清摄像机的话还可以支持到1080P。由于大型视频会议都需要将视频进行投影后播出，所以320*240的视频质量是很难有好的表现，对视频的质量要求不断的提高。除了分辨率外，视频流畅度也是衡量视频质量的重要指标，一般的交互视频为了达到低延迟，往往主动抛弃了一些数据帧，用来达到画面的实时性，但是这样往往会让用户感觉画面不连续，有跳帧，看久了就会视觉疲劳，不利于视频会议的开展。
二、实际应用中的视频会议分层架构系统
1.公司简介
目前在中国应用比较多，做的比较好的就是宝利通的视频会议系统了，宝利通公司拥有目前最多的国家骨干网成功案例，80%的国家骨干网采用全套的宝利通产品。其中绝大多数的视频会议项目都采用了多级级连，分层架构的方式，将原本建设的系统扩展到全国的各级分支节点。
目前全球最大的视频会议企业网——中国工商银行视频会议系统，采用了31台宝利通MGC，400多台宝利通终端，连接包括37个一级分行和274个二级分行在内的单位，而且系统还在不断的向各二级分行的下属单位扩展。
2007年初，国家邮政总局和平安保险，全部采用宝利通的高清设备，搭建自己高清视频会议系统。
2实际案例
下面以一个实际设计方案来说明基于分层架构的宝利通设备的应用，某一个公司需要架设视频设备，总部旗下有4个分部，每一个分部都会有一个发言会议室与多个同步观看设备。
图中有两钟设备，RMX 500C和HDX7000，RMX500C即我们在分层架构中所说的互动服务器，负责系统调度，超级站点生成，站点分配策略配置，会场发言站点切换策略配置等，但因为实际中整个系统所使用的是同一型号的设备，且每一个分部和总部都配置了相同的高清视频终端，所以不需要超级站点分配和站点分配，可以把每个地方的HDX 7000高清视频终端看做一个超级站点，其下可以再外接其他的站点视频设备。
当需要举行会议时，所有视频会议设备接入外部IP网络，由总部的RMX 500C设备负责调度，如切换发言人，切换会议主题等等，每个分部只需引入高清视频设备HDX 6000一条网络带宽即可，如果分部很多地方都需要同步视频内容，可以从高清视频设备HDX 6000同步引出多条线路，用来观看同步视频，此时，每一台高清视频设备HDX 6000都可以视为一个超级站点。
当然我们也可以不使用专门的视频设备，使用普通的PC机配合软件和摄像头麦克风也能达到视频会议的效果，但是软件的设计和配置，PC机，摄像头麦克风等综合起来，成本更高，效果也达不到使用专门视频会议设备的效果，所以现在越来越多的公司会优先配置视频会议的设备而不是使用PC机。
基于分层架构的网络视频会议系统整合了基于P2P视频会议系统和基于服务器转发会议系统的优点，并且弥补了以往传统视频会议系统的缺点。在成本和会议效果之间找到一个平衡点，达到和实现视频会议的成本与效果之间的平衡。
在现在的工作中，视频会议正变得越来越实用化，经济化，便捷化，我们所使用的基于分层架构的网络视频会议系统也是未来视频会议发展的趋势所在，随着技术的进步和发展，我相信视频会议技术也会得到相应的发展和提高，在未来的新技术里占有一席之地。
【参考文献】
[1]国家博物馆HDX8000高清视频终端产品培训
[2]神州数码视频会议系统建设方案
[3]网络视频会议系统的研究与应用刘晓昱
[4]视频会议系统的实现与优化王喆
[5]视频会议中基于P2P技术的视频分发原型系统的实现胡倩
[6]面向服务的云会议系统架构及其关键技术研究李俊超
[7]http：//baike.baidu.com/link？url=k_x9MeLukOX8eTq1Rig1k0
业务系统架构 篇12
移动数据业务正出于一个高速发展的阶段,作为承担着实现业务呈现、业务逻辑、业务管理以及运营支撑等角色的业务平台,是移动数据业务最为核心的基础设施。但从业务平台的现状看,由于移动数据业务是一个新兴的发展领域,平台的建设尚不能很好的适应移动数据业务自身的发展特点。一方面,每个新业务的推出,往往意味着一套完整的业务平台,在业务平台相似功能重复建设的同时,影响着数据业务的快速推出,而另一方面,各个业务平台之间呈竖井结构,很难实现业务之间的紧密联系和组合,在阻碍数据业务发展灵活性的同时,使数据业务平台的管理日趋复杂。在上述背景下,对移动数据业务平台的整合进行研究就显得十分的必要了。但是,对于业务平台的整合不是一蹴而就的,在具体的实施过程中需要根据业务平台的实际情况分步实施,本文以业务平台的逻辑架构作为研究对象,在对某运营商的业务平台进行充分调研的基础上,提出针对逻辑架构的整合的思路。
1 移动数据业务平台逻辑架构现状
1.1 认证授权记账
认证授权记账(Authentication,Authorization,Accounting AAA)主要指对业务受理和交付的管理。在业务请求时需要对用户和业务的合法性进行认证;身份认证通过后,基于用户的权限,来决定用户可使用的服务内容;在业务使用过程中,需要对业务使用资源的情况进行记录,作为最终计费的依据。在一个完整的业务平台中,AAA的设计是决定业务平台逻辑架构的核心,也是不同数据业务实现中最具共性的部分。
从对现有业务平台的分析来看,各业务平台的AAA并实现没有得到集中,实现方式因各业务平台的不同而不同,主要包括由平台自身实现、由业务管理平台实现、借助与其他业务平台实现。就业务管理平台而言,平台对部分类型业务进行了管理,从而实现了AAA的一定的集中。但总体而言,不同的AAA实现方式给业务带来了受理使用渠道不够全面统一、难以实现灵活的资费策略、部分合作类业务无法实现监管等一系列的问题。
1.2 业务功能
整个业务应用的实现通常会划分成诸多的业务功能。而正是这些功能决定了业务之间的一个差异。从当前对数据业务平台的调研情况来看,当前各个平台的规划建设都相对独立,往往导致了每个业务平台功能的划分缺乏统一的规划。每个业务平台的功能之间耦合度高,结构不清晰,很难实现各个业务平台之间功能的复用,在拉长建设周期的同时,也降低了投资效益。此外,为了满足业务需求,数据业务平台的开发周期整体较短,这就导致了在平台的开发过程中,没有考虑到业务功能复用,也加剧了开发周期不够理想,开发投入浪费的情况。例如,每个业务平台都会涉及到对能力网元的调用,如通过短信网关进行短信的单次下发、定期群发、交互问答等,这些功能开发的工作量是整个业务平台开发工作量中很大的一部分,对于这些功能进行统一规划和开发实现,完全可以做到对所有业务平台重用。但是,当前许多业务基本属于重复开发,这往往使得业务上线时间不能很好的保证,也增加了业务运营成本和投资成本。因此,对于部分数据业务的开发实现对业务功能的复用在当前就显得十分迫切。
2 业务平台逻辑架构整合方案研究
针对以上对现有业务平台逻辑架构的分析研究,可以从以下角度来实现对业务平台逻辑架构一定程度的整合:
2.1 AAA整合
针对AAA的整合,部分运营商提出了自己的相应的规范要求。例如中移动的DSMP规范对所有接入移动梦网的合作伙伴的业务进行管理,实现了集中化的AAA。但是仍旧有相当部分的业务,包括运营商的自有业务的AAA并没有得到整合,因此对于该部分业务整合就显得尤为重要。通过AAA的整合平台为实现业务统一受理、统一组合营销提供了便利。
统一的AAA整合平台通常应该包括以下几部分功能:
2.1.1 用户管理
用户管理功能模块的应用主要分为用户基本信息管理和用户扩展信息管理,其中用户基本信息管理主要是对用户基本信息的查询和修改,如新建用户、注销用户、修改密码、重置密码、修改用户信息、浏览用户信息等
2.1.2 业务管理
业务管理功能模块包括业务目录、业务系统接入、业务定义、业务测试、业务提供、业务维护和业务终止功能。
2.1.3 订购关系管理
订购关系管理用户和产品之间的订购信息,该信息决定了用户是否可以使用业务,并作为计费的依据。该信息可以根据业务需要同步给业务平台,由业务平台扩充其个性化的信息。
2.2 业务功能的整合
相比业务平台的整合而言,业务功能的整合的需求更为迫切,这是因为虽然AAA尚未得到全面整合,但运营商已有若干业务管理平台对部分业务的AAA进行了整合,而业务功能本身的个性化决定了业务功能的整合是非常的困难,但正因为如此,业务功能的整合所带来的效益是更大的。对于业务功能的整合,可以分步实施,从业务有重复功能入手,在对业务平台的分析的基础上得出,对于业务的内容管理的整合较为容易实施。
移动业务平台的内容管理主要是对内容类业务,内容类业务包括新闻信息类、手机电视、图片铃声下载、音乐下载播放、手机游戏等。移动业务平台的内容管理可以分为标准内容管理和稀缺内容管理两类。标准内容管理指业务平台具备完整的内容管理功能,具备内容上传、编辑、审核及入库等流程,所管理的内容格式较为标准,该类内容通常以文件的方式存储。同一类内容可由多个CP上传,形成内容集市或仓库,供业务平台统一使用。稀缺内容管理只需实现对内容上传、存储,无需编辑和审核。该类内容一般是稀缺内容,合作方是一些垄断性的机构组织,在内容的使用和业务的开展中有较强的掌控力,该类内容不需要也无法由移动进行编辑和审核。因此,内容的格式差异性较大,通常以数据库方式存储。针对标准内容的整合,可以考虑建立统一的标准内容管理平台。由于不同的内容类型具有不同的描述特性,该平台应该具备可扩展的内容模型,以支持包括普通文本信息、图片、铃声、手机主题等内容的管理。标准内容管理系统还应该向CP提供上传界面,对运营人员提供内容的编辑、审核,以及审核通过之后的统一入库功能。此外,为考虑到不同业务内容管理流程的差异性,该平台的应该能够支持基于不同业务的内容管理流程的配置。考虑到稀缺内容的来源不同于标准内容,不需要进行编辑、审核,并且以数据库的存储方式也不同于标准内容管理的文件存储方式。另外,由于商务模式等原因,稀缺内容的使用需要遵守内容来源机构一些规定,如安全、保密等,不能直接转交给业务平台或第三方。因此,稀缺内容管理的整合需要独立于标准内容管理整合进行实施。
从实现的角度来看,统一的稀缺内容管理平台需要具备以下两个功能。
(1)稀缺内容的接入管理稀缺内容的来源方通常以文件或API方式提供内容。对于文件方式,需要提供个性化的内容上传功能和灵活的文件格式解析;对于API方式,需要实现外部内容接口与移动业务平台之间接口的适配管理。
(2)稀缺内容的提供管理需要建立内容提供的安全机制,如内容传输的加密、内容访问的控制等,以保证内容在提供给第三方业务时的安全性和可靠性。[1]
3 小结
当前,移动数据业务的发展面临着日益严峻的竞争,如何更好的支撑好数据业务的发展是当前移动运营商面临的一个重要课题。为夯实移动数据业务发展的基础设施,紧密联系实践,基于业务平台的实际现状来研究移动数据业务平台的整合就显得十分的必要,本文在对移动业务平台调研的基础上提出了若干整合的思路,为将来的业务平台的整合提供了一定借鉴。
参考文献