中间业务逻辑层

中间业务逻辑层（共6篇）

中间业务逻辑层 篇1

摘要：随着软件规模的日趋复杂化,迫切需要一个良好的框架或统一的方法开发业务逻辑层。在深入研究规则引擎的工作原理及Rete模式匹配算法的基础上,采用Web Service分布式计算技术具体构建了一个基于规则引擎的Web应用框架,该框架可使业务逻辑与应用程序代码高度解耦,可对业务规则进行单独的管理和维护。因此,可极大提高软件的柔韧性,降低软件的维护与升级成本。最后,利用该框架具体构建了一个实际的订单系统原型,并通过实验结果分析了在采用规则引擎后对系统性能的影响,在实际中具有一定的参考价值。

关键词：规则引擎,Web应用框架,业务逻辑,Rete算法

0 引言

在现今的Web系统架构中,大多数企业级应用一般均采用B/S/D三层Web架构。企业级Java应用也相应地分为三层:表现层、业务逻辑层和数据持久层。通常使用某种框架来开发和部署企业级应用,表现层常用的框架有Struts,JSF和Spring等,持久层常用的框架有Hibernate和EJB等。而在业务逻辑层中往往是大量随外部条件不断变化的业务规则。但到目前为止,对于业务逻辑层却没有一个标准的构建方法。像EJB和Spring等只能在高端实现业务逻辑的构建,但却不能组织代码。因此,商业决策者和应用开发者就非常迫切地需要能将商业决策逻辑和技术决策分离出来。这样,就可以在运行时动态地管理和修改业务规则,并且使用在可配置性、可读性和重用性等方面能够带给我们极大利益的框架来代替那些繁杂的条件判断语句,从而可提高系统的柔韧性和适应性。

另外,随着商业以及市场的迅猛发展,企业级应用的更新和升级变得越来越频繁。因为对业务逻辑层没有标准的框架和统一的开发方式,使得系统的维护和升级将花费更大的代价。这就更加迫切需要一个框架或统一的方法来开发业务逻辑层。很多的系统架构师已经注意到了这一点并且正在进一步研究与探讨。针对目前Web应用开发现状及存在的问题,本文通过对规则引擎及模式匹配算法的研究,给出一种较好的业务逻辑层的构建方案,以降低系统开发、升级与维护时花费的巨大代价。

1 Drools规则引擎

Drools是完全遵守JSR-94标准的规则引擎。而且是A-pache模式许可下的完全开源框架。它利用XML文件格式定义规则,大大简化了规则引擎的解析和执行过程[1]。Drools分为两个主要部分:构建和运行时[2,3]两个过程。

构建的过程涉及到.drl或.xml规则文件的创建。规则文件被读入规则文件解析器,并使用ANTLR 3语法进行解析。解析器对规则的语法进行正确性检查,然后产生一种中间结构“descr”,descr用AST来描述规则。然后,AST被传到包生成器,由包生成器来产生包对象。包生成器还承担着一些代码产生和编译的工作,这些对于产生包对象都是必需的。包对象是一个可以配置的、可序列化的,是由一个或多个规则组成的对象;运行时过程是指规则引擎在运行时,规则库(RuleBase是一个运行时组件,它包含了一个或多个包对象)可以在任何时刻将一个包对象加入或移出规则库。一个规则库对象可以在任意时刻实例化一个或多个工作记忆对象,并在它的内部保持对这些工作记忆的弱引用。当应用程序中的对象被断言(这里采用了Java的assert的概念,是指对象是否满足规则的LHS。如果满足则将该对象利用Java的assert函数添加到工作记忆中,否则继续检查下面的对象)进工作记忆后,可能会导致一个或多个激活过程的产生,然后由议程负责安排这些激活过程的执行。

2 Rete算法简介

规则引擎采用的规则匹配算法决定它的效率是否能满足需求[4],而Rete算法是目前效率最高的一个前向链推理算法[5],其核心思想是将分离的匹配项,根据内容动态构造匹配树,以达到显著降低计算量的效果。Rete模式匹配算法是在模式匹配中利用推理机的时间冗余性和规则结构的相似性,通过保存中间过程及模式共享来提高推理效率的一种模式匹配算法。在模式匹配过程中,规则的前提(LHS)中可能会有很多相同的模块,因此在匹配规则的前提时,将进行大量的重复运算,这样就带来时间冗余性问题。Rete模式匹配算法很好地解决了基于规则的系统所具有的时间冗余性。它的实现是通过存储不断循环中匹配过程的状态。并仅考虑在事实列表中发生了的且又反映到本次状态中的变化。也就是说,如果在一个执行周期中,一组模式找到三个所需事实中的两个,则在下一个执行周期中,就无需对已经找到的这两个事实进行检查。此时,只有第三个事实才是需要关注的。另外,许多规则通常包含了相似的模式或模式群。利用这一特性,Rete算法通过将公共部分放在一起来提高效率,因为公共部分不必多次计算。这便是模式共享的基本思想,推理引擎的推理步骤如下:

1)将初始事实输入工作记忆;

2)使用模式匹配器比较规则库中的规则和事实;

3)执行的规则存在冲突,即同时激活了多个规则,将冲突的规则放入冲突集合;

4)冲突,将激活的规则按顺序放入议程;

5)执行引擎执行议程中的规则,重复步骤2)-5),直到执行完毕所有议程中的规则。

3 Web应用框架设计

3.1 总体框架设计

如前所述,大多企业级Java应用一般分为:表现层、业务逻辑层和数据持久层三层结构。其中,业务逻辑层无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求相关的系统设计。业务逻辑层在体系架构中处于数据访问层与表示层中间,起到了数据交换中承上启下的作用[6]。在传统的开发模式中,是将这些业务逻辑和代码逻辑混杂在一起。一旦业务规则发生变化,就得修改每个类中相应的代码,亦即业务规则的不断变化,就得不停地修改程序代码。特别是当越接近系统实现的后期时,这种修改就越加困难。因此,当系统越大、开发周期越长、成为“遗憾工程”的可能性也就越大。

为解决上述问题,本文在业务逻辑层中使用Web Service这种分布式计算技术,将这些复杂的业务逻辑单独部署到一个独立的服务器上,对系统中的业务规则进行单独的管理与维护,Web应用的总体框架结构如图1所示。这种框架结构可在极大的程度上降低了规则引擎服务同系统其它部分的耦合性,降低业务规则的变更对系统的影响,从而可极大地提高系统适应性和灵活性,减少系统的开发和维护成本。

3.2 业务逻辑层的设计

1) Web服务概念模型设计

如前所述,业务逻辑层采用Web Service分布式实现,该层定义了Web服务接口,这些接口用来描述Web服务。Web服务描述语言(WSDL)采用了xml语法,用于描述Web服务及其函数、参数和返回值,而服务的具体实现部分在规则引擎服务端。为了测试采用规则引擎后对系统性能的影响,系统中定义了两套Web服务的接口,分别是:IorderFormService (不采用规则引擎)和IOrderFormRulesService(采用规则引擎)。该Web服务的概念模型如图2所示。

其中:IOrderFormService和IOrderFormRulesService这两个接口的参数是相同的,但这两个接口并不是同时使用,在服务运行时,可以通过配置文件的配置来选择采用哪一个接口。系统两端还定义了两个视图对象ItemVO和DoSumVO,这两个视图对象主要是定义了传输数据时的数据格式,可以看作是通信的协议。相应地,系统中还定义了两个业务对象ItemBO和DoSumBO,这两个业务对象的具体实现和其对应的视图对象的实现是完全相同的,只是为了强调业务逻辑执行时操作的参数是业务逻辑相关的。这里只列出视图对象的具体实现:

2) Web服务的描述

根据视图对象的定义,在WSDL中需要对这些数据类型进行描述。同时,在WSDL中还要对Web服务进行描述,即描述服务端提供什么样的服务,以及调用该服务的URL信息等。Web服务描述如下所示:

4 订单系统的实现

4.1 订单系统概述

该系统框架结构采用Struts+Drools+Hibernate来实现。前端表现层采用Struts框架,后台数据持久层采用Hibernate框架,业务逻辑层应用开源的规则引擎一Drools框架。同时,利用传统方式再构建该系统的业务逻辑层,其目的是为了分析采用规则引擎与不采用规则引擎开发模式对系统性能的影响。系统的开发环境是:Eclipse+MyEclipse+Tomcat+DroolsIDE+MySQL,Web总体架构见图1。由于本文研究的核心是业务逻辑层,因此只给出业务逻辑层部分的实现。

4.2 规则引擎服务的实现

IOrderFormService接口调用服务的方法为doSum;IOrderFormRulesService接口调用服务的方法为doRulesSum。其中,函数doSum是不采用规则引擎时的Web服务函数;函数doRulesSum是采用规则引擎时的Web服务函数。下面分别给出doSum和doRulesSum的具体实现:

其中,doVipSum得到的是vip客户的订单核算结果;doSum1得到的是普通客户的订单核算结果。这个函数是由纯Java代码实现的。

4.3 规则库的定义

在程序清单7中可以看到,首先需要创建一个规则库,然后利用该规则库生成一个工作记忆,并将对象断言进该工作记忆,最后激发规则并得到规则匹配的结果,也就是订单的核算结果。下面针对该系统的客户,定义了如下的订单核算规则:

程序清单8订单核算规则

(1)如果客户不是VIP

1)所有item先按折扣分别计算单个item的花费之和;

2)如果单个item数量超过10个,在其花费基础上乘以95%:

3)求出所有单个item的花费和;

4)如果item种类超过5个,在总花费基础上乘以95%

;5)如果最终花费大于10000,在总花费基础上乘以85%。

(2)如果客户是VIP

1)所有item先按折扣分别计算单个item的花费之和;

2)如果单个item数量超过8个,在其花费基础上乘以90%;

3)求出所有单个item的花费和;

4)如果item种类超过3个,在总花费基础上乘以90%;

5)如果最终花费大于8000,在总花费基础上乘以80%。

要满足上述所有的规则,根据排列组合的规律,应该需要23×2=16种规则组合。但由于最后两条规则不需要任何计算,所以至少应该有14种规则组合。下面给出规则文件中客户是VIP时规则2)的规则语言描述(其它规则的描述略):

5 性能测试及结果分析

性能测试是任何分布式或Web应用程序测试计划的重要组成部分。本文中所说的性能测试主要是对两种方式(使用规则引擎和不使用规则引擎)实现的系统之间的性能比较。该测试主要采用Apache的JMeter[7]进行。在JMeter的性能测试中,主要的测试内容有:平均值、偏离值、吞吐量和中值。该测试的核心内容就是系统平均响应时间(平均值)。测试分为两组,第一组测试采用100个样本,每个样本循环发送8次请求,一共800次请求。第二组测试采用10000个样本,即10000个请求同时并发。其测试结果如表1所示(曲线图略)。

通过上面两组实际测试的结果可知,采用规则引擎实现方式的响应时间比不采用规则引擎实现方式的响应时间略长,第一组测试平均响应时间相差0.181秒,第二组测试平均响应时间相差0.351秒,且这个时间差是在人们的忍受范围之内。因此,采用规则引擎框架来实现业务逻辑层是完全行之有效的。

6 结论

规则引擎技术为管理复杂、多变的业务逻辑提供了一种有效的解决方案,使用规则引擎开发的应用系统,虽然使系统的性能略有降低,但是却极大地降低了开发和维护的难度和代价。由于规则是写入到规则文件的,而规则文件又是满足规则语言要求的,所以可读性要远比将逻辑写入代码中的可读性要好得多。现今,规则引擎的框架及工作越来越多,正说明了规则引擎的应用越来越广泛。同时,在企业级Web应用中,越来越多的应用规则引擎也是企业级Web应用的一个发展趋势。

参考文献

[1]闫欢,张宜生,李德群.规则引擎在制造企业MES中的研究与应用[J].计算机工程,2007,33(7):210-224.

[2]Ricardo Olivieri.Implement business logic with the Drools rules engine [EB/OL].http://www-128.ibm.com/developerworks/cn/java/j- drools/.2006,06,19.

[3]张彪.基于Rete算法的数据库通知引擎技术研究[D].上海海事大学硕士学位论文,2004.

[4]尤俊欣,饶若楠,詹晓峰.基于规则引擎的Web框架[J].计算机应用与软件,2007,24(2):2-22.

[5]JBoss Rules User Guide[EB/OL].http://labs.jboss.com/file-ac- cess/default/members/jbossrules/freezone/docs/3.0.5/html/index. html.

[6]PetShop之业务逻辑层设计[EB/OL].http://www.cnblogs.com/ wayfarer/archive/2006/11/05/550723.html.

[7]肖菁.使用JMeter进行性能测试[EB/OL].http://www-128.ibm. com/developerworks/cn/java/l-jmeter/.2004,2,13.

中间业务逻辑层 篇2

文国泰君安银行团队邱冠华 王剑 赵欣茹 张宇本文第一部分简述我国银行理财业务发展史，重点回顾它如何脱离资产管理本质，而沦落为影子银行，以及这期间监管部门的应对。第二部分则是理论分析，阐述银行存贷款业务与资产管理业务在逻辑本质上的区别。第三部分，分析理财业务的这种沦落，会带来哪些后果。第四部分是我们对监管取向的预期。第五部分则是在前述监管取向下，理财业务的未来出路。

一、理财业务野史银行原本的主业是存贷款业务。储户们把钱存在银行，大家有存有取，但终归会沉淀下一笔相对稳定的金额，银行就将其用于放贷，并以此赚取贷款利率、存款利率之间的息差。这一模式已延续几百年，老少兼知。后来，我国银行业于2004年开始出现了理财业务。关于理财业务的定义，银监会2005年颁布的《商业银行个人理财业务管理暂行办法》（银监会令2005年第2号，以下简称《暂行办法》）第二条指出：

本办法所称个人理财业务，是指商业银行为个人客户提供的财务分析、投资顾问等专业化服务，以及商业银行以特定目标客户或客户群为对象，推介销售投资产品、理财计划，并代理客户进行投资操作或资产管理的业务活动。

也就是，理财业务大致包括两大类：（1）理财顾问服务，就是咨询，银行只仅出主意，卖点子；（2）综合理财服务，即理财产品的设计与销售，暂行办法定义为（第八条）： 个人理财综合委托投资服务（以下简称综合理财服务），是指商业银行在向客户提供顾问服务的基础上，接受客户的委托和相关授权，按照与客户事先约定的投资计划和方式，由银行选择、决定投资工具的买卖并代理客户进行资产管理等的业务活动。在综合理财服务活动中,客户授权银行代表客户按照合同约定的投资方向和方式，进行投资和资产管理，投资收益与风险由客户或客户与银行按照约定方式承担。后一类是我们研究的重点。具体实践中，大致就是银行设立一个理财产品（含具体合同），向投资者（一般就是银行原有的存款、贷款客户）出售，以此募集了资金。然后银行作为受托管理人，把这些资金按约定进行投资，取得的收益按约定分配给投资人，自己则收取管理费。一听起来，这应该是资产管理业务，不属于存贷款业务。（发债、ABS和产业基金业务合作请添加微信476353122）

1早期投向债券为主起初，理财资金投向就是银行间市场的各种高等级债券，所以我们觉得它和货币基金、债券基金非常类似

其背景，是银行间市场早年就实现了利率市场化，利率较高，但个人不能直接参与。个人的存款利率则受管制，较低。两者间存在明显利差（仅极少数时期倒挂），而货币基金、债券基金实则可充当两个市场的套利工具，个人购买基金，基金再投向银行间市场的债券。既然这事基金公司能做，银行还不如自己做……于是他们就开始做了。但理财产品和公募基金又有很大区别，公募基金的管理人只收取固定管理费（但这又太过死板了，对基金管理人激励不足），套利空间的其余部分都归属投资者。而理财业务，则可双方自行约定。通行的做法，是给客户一个固定的收益率，剩下的都归银行管理人，被称为“超额留存”（这和公募基金刚好相反，投资者拿了固定部分，银行拿走了套利空间的其余部分）。虽然这并不违反规定（《暂行办法》允许双方自行约定），但这约定的收益率却给后来的刚性兑付埋下了伏笔，有点偏离资产管理业了。再者，由于银行获取的是“超额留存”，他们就存在拉大套利空间的动机，而其中一个简单的方法就是期限错配，为管理期限错配，又对资金池产生需求，进一步偏离资产管理业。

2非标纳入投资范围但是，“非标准债权（非标）”纳入了理财资金和投资范围，我们就猛然发现理财业务加速变味了。所谓非标，本质就是向企业的贷款，贷款条件由双方议定，不是证券那样的标准化合约，所以称为非标。由于早期规定，银行理财资金用途有限，且没有投资人主体，所以作为规避，有银行发明了“银信合作”，先由信托公司设立一只信托计划，向借款人发放贷款，然后银行理财资金去购买信托计划。简单粗暴，只需要一个信托计划作为通道，理财资金就实现了向借款人放款。同时也可以以信托计划出面，投资其他领域，包括股票一级市场（打新）、二级市场、另类投资等。另一头，银行又继续向理财产品投资人支付稳定的收益率，刚性兑付正式确立，已和高息揽储类似。由此，银行理财业务本质上已经是存贷款业务，只不过利差薄一点而已（因为理财的收益率高过存款利率）。这种表外的存贷款业务，是一种典型的影子银行。

因为银行存贷款业务是赚取息差的，那么在息差率稳定的情况下，规模越大越赚钱。所以，银行一般来说都会有强大的动机去做大规模。然后，风险越高的贷款客户，其贷款利率也越高，有些银行会为了盈利，去拓展这些客户（贷款业务的风险偏好上升）。这些行为都会加大银行风险，但由于银行“大而不倒”，出事时国家会救，所以银行行长们并不担心这一点，拼命做大规模，放大风险。这是银行业务本质决定的。所以，各国均对银行施以严格监管，设置资产充足率、不良率、流动性等监管指标，遏制其无度扩张，不让其风险失控。但是，理财资金投向非标（本质是贷款），实质上已经成为了存贷款业务，且不受资本充足率、不良率、流动性等监管指标制约，风险有可能失控。

监管层很快发现了这种做法，于是发文叫停。但是，银行又有了新的发明，理财资金不再去直接购买信托计划，而是购买了信托计划的受益权……意思是说，我没购买该信托计划本身，只是买了其受益权。

这几乎是中世纪信托问世的翻版。有钱人的财产继承要课重税，所以就不继承了，而是把它委托给受托人，受托人管理财产，财产收益则支付给受益人（比如子女）。子女拥有受益权，这种受益权可转让。

银行就像欧洲中世纪的大财主一样，找到了信托计划这一利器，理财资金几乎实现了所有的投向。尤其是在2010年开始的宏观调控中，监管层不允许银行信贷投向房地产、地方融资平台、两高一剩等领域，而银信合作则绕开这一监管。于是，银监开始着手遏制，2008-2011年竟然连发十文干预此事，狂刷存在感，比某些证券分析师发深度报告还勤快。（发债、ABS和产业基金业务合作请添加微信476353122）2008年9月《关于印发的通知》（银监发[2008]83号）2009年7月《关于进一步规范商业银行个人理财业务投资管理有半问题的通知》（银监发[2009]65号）2009年12月《关于进一步规范银信合作有关事项的通知》（银监发[2009]111号）2009年12月《关于规范信贷资产转让及信贷资产类理财业务有关事项的通知》（银监发[2009]113号）2010年8月《关于规范银信理财合作业务有关事项的通知》（银监发[2010]72号）2010年12月《关于进一步规范银行业金融机构信贷资产转让业务的通知》（银监发[2010]102号）2011年1月《关于进一步规范银信理财合作业务的通知》（银监发[2011]7号）2011年5月《（办公室）关于规范银信理财合作业务转表范围及方式的通知》（银监办发[2011]148号）2011年6月《（非银部）关于做好信托公司净资本监管、银信合作业务转表及信托产品营销等有关事项的通知》（非银发[2011]14号）2011年7月《关于进一步落实各银行法人机构银信理财合作业务转表计划有关情况的函》（银监办便函[2011]353号）如果这些文件被严格执行，这些表外资产全部回表，估计好多银行的监管指标会“爆表”。但是，就在银监与银行进行猫和老鼠的游戏时，2012年证监会突然间来给银行提供了神助攻。当年的券商创新大会后，券商资管、基金子公司、期货公司资管都被允许充当通道，流程和信托一样。银监会发现自己当初刷屏用的十道令牌全成了废纸，于是一改监管方式，干脆直接规定非标资产的总量上限。2013年，银监会颁布《中国银监会关于规范商业银行理财业务投资运作有关问题的通知》（银监发[2013]8号），规定理财资金投向非标资产，不得超过理财总额的35%，亦不得超过银行总资产的4%。该文件于3月27日公告，次日，银行股行业指数大幅低开，全天暴跌超6%，足可见威力之强大。但是，监管层这相当于承认自己无法杜绝影子银行，只能退而求其次，限制其规模。该规定取得较好效果，此后非标总量得到控制。但仍然有部分银行，将非标资产通过种种手段包装成标准化债券（所谓“非标转标”），从而规避了监管。

二、理财业务本应是资产管理业把市场搅得鸡飞狗跳的理财业务及其监管，到底问题出在哪呢？我们认为，这还是要从业务的根本商业逻辑上去找到关键点。存贷款业务和理财业务（资产管理业务），虽然表面上都把客户把钱交给银行，银行再去投放，但其实本应有是截然不同的商业逻辑。存贷款业务，即通称的银行表内业务，是两层债权-债务关系。首先是存款，储户把钱借给银行（第一层债权-债务关系），银行以自身信誉为保障，只要银行不倒闭，这钱就可随时还给你（或按约定时间还给你）。此时，储户不用在意银行把这钱拿去做了什么，反正不管做什么，只要银行不倒闭，存款就能还你。然后，银行留一部分存款资金用来应付储户的取款，其余的大部分沉淀资金则拿去放贷款（第二层债权-债务关系）。而且，银行所有来源（包括存款）的资金会汇总在一起使用，即俗称的“资金池”，存款和贷款间没有科目对应关系，某笔存款和某笔贷款间更不存在一一对应关系。资金池是银行表内业务的终极神器，有了它，银行可实现资产与负债之间规模（积少成多）、期限（续短为长）、信用风险（用低风险资金为相对高风险业务融资）的错配，从而能够动员社会闲散资金，集中形成资本，用于生产。然后，银行开始工作。他们要履行筛选、审查、监督借款人的工作（为克服信息不对称而进行的信息生产工作），这也理解为是一种专业的债权投资管理服务；此外，如果借款人万一还不了钱，银行则自己承担损失（信用风险由银行吸收，银行用利差收入覆盖坏账，不转嫁给存款人）；而如果突然间来取款的储户特别多，银行自己留存的资金不够，那么它还得向金融市场或央行紧急借款（不能以贷款还没到期收回为由拒绝储户取款），并为此承担成本（流动性风险也由银行吸收）。因此，银行是基于：（1）信息生产工作；（2）承担信用风险；（3）承担流动性风险等，获取其相应回报。这是银行存贷款业务的商业逻辑。而资产管理业的逻辑则完全不一样。资产管理业，是投资人将资金托付给资产管理人，请其为自己从事投资（《暂行办法》称是委托关系，但也接近信托关系）。资产管理人按照事先约定的方式收取管理费（可以是管理资产的固定比例，也可以是投资收益的分成），然后把扣除管理费后的投资收益交还给投资人。资产管理人以自己的专业能力，勤勉地为投资人提供资产管理服务，但投资结果由投资人自行承担，不保证收益。而且，资产管理业务不应该有“资金池”，每项资产管理产品（可以有多个投资人）的资金来源与运用是清晰的，不会和别的产品的钱混在一起使用，这样才能算得清投资人的收益。比如典型的资产管理业是公募基金业，基金公司是基金管理人。比起投资人自行投资，这样做的好处，一是基金公司的基金经理在投资方面更为专业，二是公募基金汇集了众多投资人的资金，能够更好地实现分散化投资或履行股东权利，实现规模优势。资产管理人的回报仅来自专业的投资管理服务，管理人不为投资人承担流动性风险（有些资产管理产品可随时赎回或转让，流动性较好，但这种流动性并不是管理人提供的，所以不属于“管理人承担流动性风险”）、信用风险等。所以，这本该就是两门生意，有着截然不同的商业逻辑。我们将两者作个简单对比：银行存贷款业务，是用资金池来吸收流动性风险，用资金池的错配来赚取利差，利差又是用来覆盖坏账。而资产管理业务，不用承担这两种风险，所以理论上不必设立资金池。而且，理财业务设了资金池，还为利益输送创造了空间（多只理财产品的资产混在一起运用，边界不清，管理人可随意调节某只理财产品的收益）。而银行的理财业务，理应是资产管理业务。它肯定不能是存贷款业务，否则就应该一并纳入表内，统一实施资本充足率、不良率、流动性等监管。但是，我国银行理财业务，却因有意无意的混淆，也不像是真正的资产管理业务。比如，我国银行理财业务一直存在资金池操作，屡禁不止。还有，银行发行理财产品，很多情况下竟然是向投资人约定收益率的，而不是约定管理费。以及其他问题。最后，就形成如今这种现状，即理财业务既不是存贷款业务，也不是真正的资产管理业务……那它到底是什么呢？

三、逻辑扭曲带来的影响在法律人士、从业人士继续探讨理财业务终究是什么的过程中，这一现状所带来的影响却纷纷显现。其中也有好的影响，但更多是负面的影响。（1）倒逼利率市场化：这一点是积极影响。我国利率市场化进程接近末尾，这几年进展较快，而理财业务对起到积极的推动作用。况且，从其他国家经验上看，利率市场化其实是经济发展到一定阶段后的内生要求，即使监管没放松，市场也会自发地用其他方式突破。理财业务就是一例。理财业务使更多投资者获得投资性收入，使更多借款人拿到融资，有其积极意义。（2）整体风险不明：部分理财业务本质上接近存贷款业务，或者说是把部分表内放款业务转移到表外（但风险依然由银行承担），从而规避了监管，使部分监管指标失真。比如，理财资金投放的非标，不用计提拨备和资本占用，也不计算不良率，也不用回避高风险领域（比如监管层叫停向地方政府融资平台、房地产开发商等领域投放信贷，但理财资金投放可规避此监管），最终导致监管层对整个银行体系的风险评估不准确，可能引发严重后果。（3）抬高无风险收益率：由于银行在我国仍然拥有极高信誉，他们发行的理财产品又因为刚性兑付，被很多投资者默认为无风险，从而，理财产品收益率实际上是一种无风险收益率。当然，结合第（1）点来看，如果原来的无风险收益率是人为低估的，那么抬高它也算好事。但问题是，刚好有时货币当局希望压低无风险利率时，实施宽松货币政策时，宽松的效果却被抵消了。因此，这造成了对货币政策传导效果的干扰。

四、监管取向及其影响监管的意思一直是明确的、坚定的，但执行却是稀里糊涂的。其实，早在2014年银监会曾颁布《商业银行理财业务监督管理办法（征求意见稿）》（以下简称《征求意见稿》），里面对理财业务多方面做出详尽规定，使其成为真正的资产管理业。其中包括：非标资产回表，非标资产不允许错配，穿透管理（解包还原）和限制通道层级，分组产品的监管，细化托管制度，不允许资金池，建立风险准备制度等……

通篇看下来，若严格执行，那么银行理财业务就回归资产管理了。但是，因为种种原因，该征求意见稿征求了两年多意见，依然没有下文。而这两年，理财业务规模疯狂增长到23万亿元（2015年底），占银行业表内资产比例高达20%多，已经到了不得不收拾的时候了。

首先，规模失控：2015年底总规模达到23万亿元，2016年上半年仍在增长。其次，投向失控：经过层层通道，理财资金已经实现多种投资，甚至包括风险极高的为恶意并购融资。虽然真正意义的资产管理业，理论上可以为合格投资提供所有种类的投资管理服务，当然也包括高风险投资。但是，这是建立在信托关系基础上。但目前理财业务仍有表外存贷款业务的嫌疑，还有，杠杆失控：经过多层通道，层层叠加杠杆，最终会使杠杆奇高，加大整个金融体系的潜在风险。理财业务的三失控，可能加大金融体系脆弱性，或对整个金融体系带来了较大的风险，且不能被监管部门有效监测。可时至今日，理财业务的系统法规依然没有出台，一个《暂行办法》暂行了十多年，后面只有几个补丁式的规章，无法从系统上管控理财业务风险。因此，我们预计正式文件出台时已不远，其基本要义与《征求意见稿》相近。在看到正式文件前，我们尚不能准确评估其带来的影响。但根据监管精神，至少可以肯定以下几点影响：

（1）理财业务量价齐跌。总量控制，甚至有所收缩。因不能错配、信用风险加大、业务成本加大等原因，理财的收益率会下降。（2）非标业务得到遏制，资金可能回流债券市场，或者干脆就离开理财业务。这对借款企业的流动性并不利，但利好债券市场。（3）信贷（非标）资产获取能力较强的银行形成差异化优势。

中间业务逻辑层 篇3

1 PLC的基本组成结构

1.1 电源。

电源是保证可编程逻辑控制器各项操作和指令正常进行的关键, 因此保证PLC工作过程中电源的稳定、可靠是极其重要的。正是考虑到电源对整个控制器性能的影响, 制造厂商在设计电源时要严格控制交流电压的波动范围, 通常情况下要控制在额定电压+10%左右, 在这种情况下, 可以不采用其他保护措施而直接把PLC连入交流电网中。

1.2 中央处理单元。

中央处理单元相当于整个可编程逻辑控制器的“大脑”, 它不仅负责对该控制系统中的各个操作单元进行指令下达和控制, 而且能够接受并储存用户编写的程序。当可编程逻辑控制器工作时, 首先以扫描的方式, 将用户编写的各种程序语言录入到内置存储器中, 然后从存储器中逐条读取程序指令, 并将指令与数据库进行一一比对, 最后将配对成功的指令下达到各个操作单元中, 完成数据的输出。各个基础操作系统接到中央处理单元发出的信号后, 进行相应的动作, 直到程序停止。

1.3 存储器。

顾名思义, 存储器就是对各种信息、程序和指令进行暂存和保管, 当存储器受到程序调用指令后, 将保存的各种信息、指令直接传递出去。根据存储内容的不同, 可以将PLC存储器分为两大类。一类是用于存放系统本身程序的系统程序存储器。可编程逻辑控制器在设计之初, 为了完成各种程序动作, 需要事先设置系统控制语言, 其目的是为了保证整个系统中各个协调动作的平稳运行。另一类是在系统使用过程中, 用于存储户编写程序的用户程序存储器。

1.4 功能模块。

可编程逻辑控制器要想完成各种操作, 必须依赖不同的功能控制模块。例如当数控机厂自动加工完成后, 需要提醒相关的管理人员将加工完毕的工件取走, 此时可以设置报警模块, 当检测到加工程序执行完毕后, 进行自动报警。除此之外, 常见的功能模块还有延时模块、计数模块和定位模块等。

2 PLC逻辑层的特点

由于PLC技术不断发展, 数控机床改造实现了技术多元化, 成为现代机械制造行业的先进术。数控机床控制是CPU和I/O设备之间交换信息的中转点, PLC数控机床控制出现问题则会大大影响数据处理效率。若PLC服务平台运转达不到预定要求, 用户处理数据时必然会出现多种问题, 约束了数控机床控制层次的应用型。设定逻辑层具有多样式特点, 可体现出数控机床自动化改造优势。

2.1 一体性。

一体化控制技术适用于PLC数据调配, 这类技术可根据控制系统运行标准, 实时转变原始数据处理模式。“一体化控制”是对数据的多样式调整, 并非固定为某一种数据形式, 而是要结合PLC具体作业状态拟定的调控模式。与常规数控机床控制模式不同, 逻辑层应用具有专项性特点, 针对数据库模式设定相应的传输方案, 把原始数据用于接口控制与筛分处理, 向用户给予更加全面的数据服务。

2.2 转换性。

对于大容量数据库而言, 利用一体化控制技术更体现出了PLC运行的专业性水平。数据兼容是转换的基本前提, 只有在相互融通的数据平台中, 才能实现彼此之间的相互融通, 建立符合数据传输要求的控制平台。PLC数控机床控制不仅具备基本的控制功能, 也能根据不同数据的格式、内容、存量等进行转换处理, 实现两种PLC语言的相互融通, 提高了数据一体化控制处理效率。

2.3 安全性。

近年来, 基于PLC的数控机床自动化控制在机械加工制造应用中体现出来巨大优势, 因此使用PLC的用户数量也呈现出激增现象, 为了优化用户操作体验, 提升PLC自动化控制水平, 许多企业都采用了一体化控制技术。该技术的优点在于改变了传统的用户服务机制, 将分散用户进行集中和统一管理, 对于保障系统稳定性有积极帮助。除此之外, 一体化控制技术还设置了数据备份功能, 即便是用户使用过程中出现文件损坏、丢失等问题, 也能够通过查找找回原始数据。

3 数控机床中PLC技术应用

3.1 数控端口。

当PLC接口长期处于不匹配状态下, 数据库自动收录信号能力将会减弱, 用户所接受到的数据也会出现误差。针对PLC数控机床控制应用存在的问题, 除了改变PLC软硬件系统外, 还要通过一体化控制器建立可靠的转换平台, 对外来数据及时收录与处理。基于数控机床控制转换中遇到的问题, 选定一体化控制技术作为操控模式, 能从根本上提高接口数据的智能化处理水平。

3.2 数控中心。

现代信息科技快速发展促进了端口技术革新, PLC在传输数据过程中也要注重一体化控制利用, 通过对原始数据优化筛选、智能调配、一体化控制等处理之后, 不断提高了数据资源的有效利用率。数控查询、中断处理、智能存储等是一体化控制技术不可缺少的应用方式, 用户要根据数控机床控制组合状态执行科学的程序命令, 为不同寄存器及控制器提供更加安全的的操控流程, 避免人工操作失误造成电路故障或数据丢失等问题。

3.3 数控传输。

由于互联网走向移动化方向转变, 传统PLC也开始转变为数控机床一体化, 软硬件设备同时升级而创造了更加优越的工作环境。基于移动网时代背景下, 要针对数控机床一体化拟定可行的智能控制方案, 进一步优化智能系统的可操作性能, 维持服务器内部数据处理流程的有序进行。因此, 移动网具有兼容性、广泛性、功能性等特点, 为网络数据传输处理提供了虚拟化平台, 提高了网络用户的实际操作服务水平。

结束语

PLC逻辑层从软件、硬件等两方面对控制系统进行规划, 设计更加先进的数控机床体系。数控机床数字化操控要设定专业平台, 建立更加完整的数字调度方案;结合PLC逻辑层选择可行的数字技术作为支撑点, 为数控机床控制提供智能化方案。

摘要：数控机床作为现代机械加工的主要设备, 具有加工效率快、加工精度高、自动化操作等优点, 在大多数机械加工、制造企业都得到了广泛的应用。将PLC作为数控机床的控制中心, 根据数控机床的实际工作特点制定与之相对应的操作系统, 利用编程语言实现对机床的程序化控制, 保证了机床加工、制造的精确度。文章首先介绍了现阶段PLC应用现状, 随后叙述了PLC逻辑层的特点, 并对PLC技术在数控机床中的自动机控制进行了分析。

关键词：PLC,逻辑层,数控机床,自动机控制

参考文献

[1]罗华丽, 李斌, 汤志斌.开放式数控系统中的软件PLC技术研究[J].组合机床与自动化加工技术, 2013 (2) .

对持久层和业务层关系的改进 篇4

目前在java web应用中的主流框架是sun的j2ee架构。下面给出大体结构

三层应用程序体系使得应用程序的结构非常清晰, 各层功能明确, 便于程序的维护。

表示层:提供与用户交互的界面。

业务层:实现各种业务逻辑。

持久层:负责存放和管理应用的持久性数据。

下面通过对用户信息的插入操作来说明:

Manager层各种业务逻辑完成以后, 下一步要做的工作便是和DAO层共同完成对数据的添加、修改、删除等操作。

代码实现:

由上面我们可以看到User Info DAO和User Info Manager两个类之间的具有较强的依赖关系, 违反了软件设计的开闭原则。如果我们动User Info DAO类, 那么User Info Manager类要相应改动。如果我们设计的系统比较大, 这工作量是非常大的, 使软件的扩展性非常差, 时也使软件丧失了灵活性。因此我们应该降他们之间的耦合性, 为此, 我们引进工厂模式

1 简单工厂模式的应用

类图的修改 (见图3

代码实现:

上面我们可以看到相比前者我们多引进了一个类和一个接口, 看起来好像麻烦了。但是我们仔细分析一下以上结构和代码不难发现:

1.1 多增加的基础接口使整个结构对DAO的扩展成为可能。

在一个比较大的web应用中不可能只有对用户信息的操作, 但是多个信息的操作又有共性。这样我们如果想扩充对其他信息的操作只需实现上面的IBase DAO接口即可。

1.2 多增加的工厂类使我们对DAO的修改变得简单。

现在我们不必在成百上千的Manager类中作一些无聊的工作, 只需在工厂类中修改即可。

但是这个结构美中却有不足:虽然DAO的修改变得简单但是工厂类未免有些权势过大, 一旦它出了问题, 整个系统便会陷于瘫痪。如何改进呢?

2 工厂方法模式

类图的修改 (见图4) :

代码实现:

这样做使得工厂类的扩展成为可能, 同时也可以通过增加工厂类的办法来降低权力过大的问题。工厂方法模式完全符合开闭原则。但是上面的结构还存在一个问题:每一个Manager类中都要定义一个Factory对象, 而我们实际中却只需一个这样的对象, 这样的做法未免有些浪费内存。那么我们如何改进呢?

3 单例模式

类图的修改:

代码实现:

单例模式的实现方法:

3.1 使工厂类中的构造方法私有化, 禁止其它类通过工厂类的构造方法创建工厂类的对象。

3.2 创建获得实例的方法。

在单例模式中工厂类把创建工厂对象的权力收为自身所有, 其他类只能通过工厂类提供的方法获得工厂类的实例。上面的结构似乎已经很完美了, 已经有了很好的扩展性和维护性, 但是上面打框的位置已经说明它们之间还具有较强的依赖性。如何做到彻底的解耦合呢?

4 翻转控制

由上面可知我们对User Info Manager类中的user Insert方法传递了一个DAO对象, 这样Manager和DAO之间便没有了任何依赖关系, 彻底降低了耦合。但是通过对User Test的观察我们不难发现这种做法的结果是把依赖关系全部转嫁给了调用者。有些开发框架利用这种办法把各种依赖关系集中处理, 方法是:把这些依赖关系转移到配置文件中去。

总结:通过这四个步骤的研究说明了软件的设计是非常灵活的, 一个好的设计方法对于软件的可维护性是何等重要。这不仅需要我们掌握大量的设计原理及模式的相关知识, 也需要我们在实践的过程中不断的探索和研究。

参考文献

[1]闫宏著.Java与模式[M].北京:电子工业出版社, 2002.

炼化企业统计平衡业务逻辑及实现 篇5

1 业务逻辑

统计平衡是在油品平衡的基础上, 以罐存和进出厂计量数据为基准, 通过基层统计日数据的获取和确认, 获取完备可信的全厂日数据, 为全厂范围内的日数据平衡提供基础数据, 形成全厂一致认可的基础数据, 同时综合考虑气体和固体等相关数据, 并实施人工干预调整, 进行全厂统计平衡计算, 最终生成企业一致的统计报表数据。业务流程如图1所示, 数据流程如图2所示。

(1) 数据汇总:收集和汇总油品平衡结果数据、罐存数据、产品进、出厂量数据、生产方案及其切换时间点信息、销售数据, 获取完备可信的全厂日数据, 提高数据的质量, 为全厂范围内的日数据平衡提供基础数据;

(2) 初步审查:从全厂物料平衡的角度对汇总上来的数据进行初步审查, 形成全厂物料平衡计算的基础数据;

(3) 基于完备的全厂日数据, 进行日数据平衡, 形成全厂一致认可的基础数据;

(4) 采用自动平衡与人工干预相结合的策略, 生成全厂一致的统计数据, 完成全厂范围内的原料、半成品、成品和生产装置的平衡;

(5) 对平衡计算的输出结果进行审核.确认后提交结果, 作为全厂物料平衡的最终结果;

(6) 基于一致的日数据, 形成以日为单位的时间段的累积数据:形成调度要求的平衡累积数据, 作为各种物料报表的数据源, 如:形成生产流程以及原料/半成品/成品平衡表。

2 软件功能设计

统计平衡的数据归并功能将车间班组录入的物料平衡数据按照一定业务规则进行自动提取, 相关业务人员在WEB页面上从统计物料或者装置的视角对提取归并后的数据进行展示查看, 并根据实际业务需求选择是否进行校正, 确认数据后对数据进行保存后即可利用统计平衡报表软件按照报表模版生成所需报表。

统计平衡模块为三层体系结构, 系统应采用B/S架构的设计, 通过WEB浏览器方式实现各级信息的采集, 查询, 审核确认和报表生成等功能。整个系统作为MES系统的一部分, 利用MES的数据平台和WPKS发布平台, 做到了和MES的结合和统一。

统计平衡子系统有效的统一和集成了企业各级的生产数据, 包括装置的投入产出, 逻辑罐的收拨存, 并进行车间级和分厂级的数据归并。系统应用的同时, 需要对这些数据按编码规则进行统一的编码, 增强系统的可移植性和可维护性。

系统以数据录入、审核、平衡、查询为流程较好的满足了炼化企业实际业务, 使企业生产数据的充分集成和展示, 并以报表形式进行企业数据的展示。下文将详细的介绍系统的体系架构。

对于物料平衡客户化开发软件2.0以上版本的软件。

统计平衡主要定义的应用为数据录入、基层数据归并和审核、分厂级数据归并和审核、报表展示。其应用分布于管理层和生产车间。系统结合了MES信息发布平台WPKS, 用户通过WEB方式即可方便的应用该系统。

1) 统计平衡基础数据配置。

统计平衡基础数据主要包括装置投入产出的移动数据、物理罐收入、拨出和库存数据。其中设备基础数据、设备层级数据、统计模型路由数据都是通过HoneyWell公司的TPI软件配置到后台数据库中的;而归并时的逻辑罐数据和统计平衡组数据则是通过WEB程序在浏览器中进行配置的, 并且通过WEB页面方式进行维护。

2) 数据查询归并功能。

统计平衡基础数据配置完成后, 在数据审核界面, 这些基础数据就会根据软件的布局, 展示在操作界面上, 用户通过简单操作即可方便的对企业各级单位生产数据进行查看且可以审核校正。对于分厂级的统计数据是按分厂+物料的模型进行归并的。

3) 其他数据录入。

除了装置, 罐区等班组录入的数据, 还有计划数据, 环保经济指标等也是统计业务的重要组成部分, 为了使数据更加完善, 设计开发了此部分, 业务人员可以在此完成这些数据的录入。此部分首先要配置相应的指标, 然后由相应的业务人员根据实际情况录入数据, 如:装置月计划加工量, 公司计划损失率, 公司计划商品率等等。

4) 统计报表展示与ERP接口。

为了将班组和统计人员录入、审核后的数据呈现出来, 设计了专门的报表组态软件, 该软件采用了先进的OWC控件, 用户可以灵活的, 通过无编码的形式来组态, 修改调整报表。报表中数据的一部分将作为ERP所需数据通过ERP接口提供给ERP系统应用, 为财务等更上层应用提供数据支撑。报表组态主要分为以下几步。

建立数据模型:根据报表规则建立相应的表或视图, 编写相应的存储过程, 运行后, 报表软件将可以利用该模型的数据。

组态报表模板:根据不同的模型建立相应的状态:如库存, 装置投入产出等, 即可选择模型, 选择指标, 选择状态, 选择相应报表模板属性, 如上反复, 报表模板完成, 报表模板可以修改。

生成报表:选择相应模板, 选择日期之后即可生成报表。

ERP接口:接口集成主要可以分为两大类, 即直接集成和间接集成。在此, MES与ERP接口采用间接集成的方式, 而间接集成又包括通过中间文件, 中间数据库以及XML数据流等, 在此, 采用的是中间文件集成模式。

具体实施时, 首先调研ERP所需数据, 包括数据范围, 数据格式等, 然后进行编码对照工作, 按照ERP需求, 按照规定格式将数据按照一定的频率放置到指定位置, 由ERP调用, 即完成ERP接口。这种策略即解决了MES与ERP的接口问题, 又使得双方数据库不受影响, 保证了数据安全。统计平衡与ERP接口数据流程, 如图3所示。

摘要：介绍了炼化企业统计平衡的业务逻辑及在MES中的实现方式, 明析了业务逻辑, 并针对业务逻辑, 详细地介绍了实现方式和功能模块。

关键词：统计平衡,业务逻辑,软件实现

参考文献

[1]王宏安.化工生产执行系统MES[M].化学工业出版社, 2007.

[2]彭瑜.加速制造执行系统MES的发展[J].电气时代, 2003.

[3]袁林, 赵向海, 何力健.炼油物料平衡系统的设计与应用[J].数字石油和化工, 2006.

[4]纪晔, 徐定宇, 雒士军, 等.国内炼油化工企业物料平衡系统的应用[J].石油规划设计, 2007.

中间业务逻辑层 篇6

移动数据业务正出于一个高速发展的阶段,作为承担着实现业务呈现、业务逻辑、业务管理以及运营支撑等角色的业务平台,是移动数据业务最为核心的基础设施。但从业务平台的现状看,由于移动数据业务是一个新兴的发展领域,平台的建设尚不能很好的适应移动数据业务自身的发展特点。一方面,每个新业务的推出,往往意味着一套完整的业务平台,在业务平台相似功能重复建设的同时,影响着数据业务的快速推出,而另一方面,各个业务平台之间呈竖井结构,很难实现业务之间的紧密联系和组合,在阻碍数据业务发展灵活性的同时,使数据业务平台的管理日趋复杂。在上述背景下,对移动数据业务平台的整合进行研究就显得十分的必要了。但是,对于业务平台的整合不是一蹴而就的,在具体的实施过程中需要根据业务平台的实际情况分步实施,本文以业务平台的逻辑架构作为研究对象,在对某运营商的业务平台进行充分调研的基础上,提出针对逻辑架构的整合的思路。

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 小结

当前,移动数据业务的发展面临着日益严峻的竞争,如何更好的支撑好数据业务的发展是当前移动运营商面临的一个重要课题。为夯实移动数据业务发展的基础设施,紧密联系实践,基于业务平台的实际现状来研究移动数据业务平台的整合就显得十分的必要,本文在对移动业务平台调研的基础上提出了若干整合的思路,为将来的业务平台的整合提供了一定借鉴。

参考文献