孤岛问题困扰数字校园
SOA是近几年在IT界非常热门的名词。那么,SOA对于高校的信息化来说,有什么意义?
我想首先回顾一下我们高校信息化建设面临的问题。最近几年,高校的校园网建设成绩斐然,但是尽管如此,存在一个很大的挑战:信息不畅通。主要体现在以下三个方面:
1. 校内各部门在业务系统建设时各自为阵,其管理信息系统和数据资源类型各异、来源不一,最终导致大多数可共享的数据重复录入,无法共享使用。
2.由于没有统一接口的应用平台,各项应用的入口不统一,界面不统一,用户名和密码不统一,认证方式也各异,从而使得师生陷入了用户名和密码堆中,同时也使得管理和维护的成本非常高。
3. 目前国内高校在进行信息化建设时遇到的最大难题是管理与协调问题。比如:校领导分管不同的业务,缺乏沟通;各个校级管理部门相对独立,交流并不频繁;各个院系之间也联系较少,经验不易共享;学校管理部门给院系的联系通常是指令性的,不易优化业务流程。
由于校内各部门之间的信息系统各自独立,信息和数据无法在各个系统之间传递和共享。这几年随着信息化对人们工作和生活方式的改变,需要共享的资源与信息越来越多,各学校希望通过“数字校园”建设来将各个孤立的系统整合在一起,从而解决校内数据和信息无法传递的问题。
那么,我们可不可以从企业信息化借用“面向服务的架构(SOA)”来解决数字校园建设的瓶颈问题?我认为,通过SOA解决学校信息与业务沟通不畅的瓶颈问题应该是个很好的途径。
SOA的概念就如同搭积木一样,只要把业务模块添加到所需要的位置就可以了,而不需要每次重新开发。这样做的一个很大的好处是:以服务的理念为用户带来个性化的、可持续发展的系统架构。这能很好的适应用户的需求,但是对技术人员的要求非常之高。
大部分的信息化部门管理人员都比较了解SOA的概念,但是采用了SOA架构的学校却少之又少。目前SOA在国内数字校园领域的应用几乎为零。那么,造成这一现象的基本原因是什么?
首先是成本的原因,在采用SOA架构之后,产品的成本至少增加50%以上,这是很多高校无法承担的。
其次在技术方面,基于SOA架构的产品对用户的技术力量和服务能力都有很高的要求。在高校做SOA技术的研发,更多的是一种技术探索。所以,我们才看到,一些高校虽然采用了SOA,但是范围非常之小,只是为了技术力量的存储。
要不要选择SOA?
那么,什么学校可以采用SOA架构实施学校的数字校园?要想清楚到底要不要采用SOA,各学校需要分析自己的数字校园建设情况,各项业务是否需要SOA来整合,或者说是否已经到了可以采用SOA技术进行整合的阶段了。如果了解和分析自身的特点,以下两个方面的观点也许有些帮助:
第一,我国教育信息化建设整体上在从“粗放型”向“精细型”转变的阶段。
教育信息化由点及面已经推广了多年,现在正在从粗放型教育信息化走向精细型教育信息化。“粗放型”教育信息化,是指主要依靠建设基础设施、开发信息资源、培训信息技术来改变教育教学过程。而“精细型”教育信息化,则是主要依靠共享信息资源、发展信息服务和提升信息素养来优化教育教学过程。
目前的情况是各个大学的差异很大,就是清华大学和北京大学这样校园相邻、各方面环境比较相似的高校,在信息化的状况方面也差异很大,更不用谈及各不同规模大学的差异性了。要寻找一个模式将信息化的情况完全套进去是不可能的,因此,要客观地评估各学校所处的信息化状况还需要学校对自身情况的完全了解与充分掌握。
第二,校园网发展与应用从“开始建设”到“成熟”通常需要经历特征明显的几个阶段。按照有关研究,校园网建设可以分为以下四个阶段:
1. 信息提供阶段:通过网站发布与学校相关的各种静态信息,如学校新闻动态、学校历史、招生信息、联系信息、公文内容等。
2. 单向咨询阶段:校园网站提供各种信息资料,同时也向师生提供在线互动工具,如信息检索、表格下载、Email咨询与服务、图书目录检索、教学资源查询、课件下载、校长信箱等。
3. 校务处理阶段:校园网站向师生提供多种互动式的交流工具,可在线进行各种日常事务的申请和处理,如“入学申请”、“电子商务”(网上支付)、“学生贷款申请”、“入学注册”、“在线课程”和“网上选课”等。
4.整合参与阶段:通过网站实现教学、科研与校园生活的双向互动,利用统一的Portal(门户网站技术)实现校内各种信息系统之间的无缝连接与整合,师生利用一个电子身份验证码即可获得与自己身份相关的全部信息与服务。
而在整合参与阶段,打破信息孤岛至关重要,换言之,当你处于这样一个阶段的时候,也许可以利用SOA技术去整合业务与信息系统,但无论处在哪个阶段,SOA的理念和思想均可以借鉴,从这个意义上说,SOA是一种方法论。
如何实施SOA?
如何利用SOA架构优化数字校园的业务支撑平台?其具体实现的技术和可选用的工具、产品很多,差异性也比较大,但其方法和流程是基本一致的,比较典型的模型有IBM的SOA商务整合参考架构可供参考。
在实施SOA的过程中,有如下的问题可能需要好好地考虑:
第一,我们的目标是什么?过去我们的平台是什么?我们的业务是什么?实施SOA,我们需要达成一个什么样的目标?必须心里有数。
第二,清楚业务主体的差异性以及业务主体行为特征问题。在整个平台上来说,必须把各种业务的特点考虑进去,并以计算机可“理解”的语言表达清楚,比如,学生、教师的不同需求在哪里。我们是否可以就这些不同需求建立一个良好的业务环境。
第三,需要明确有没有合适的绩效考察方法。高校的绩效可能是会比较困难,企业的绩效就是企业的盈利,这样的绩效是惟一性的,也可以较好地表达出来,但是在高校里的绩效考察则比较模糊,考核的内容会更加多元化,所以难度较大。
第四,需要预测业务的动态变化过程。过去我们实施信息系统开发,对每一个系统都做了详细的需求分析,但是几十年管理信息系统开发的经验告诉我们这是不够的。原因之一在于你很难调查清楚业务的“变化”到底将会是什么,原因之二是信息技术一旦用到业务里,业务就会随之而产生变化,而这又是很难预料的。
此外,也是最难之处,在于驱动力来自哪里?也就是说,我们将以什么方式去驱动。是为领导的意志决定?为教师职工的管理服务?还是某个职能部门服务?而在高校,由什么方式来驱动带有很强的随机性。而对于信息平台开发来说,这可不是我们所希望的。信息平台强调的是规范,所以从这个意义上说,采用SOA是很难的。
总之,实施基于SOA的架构,是一种很好的选择,它既是一种技术,更是一种方法论。需要明确的是,不要跟风,不要因为一个技术很热而去盲从,同样的,也不要把所有企业中很流行的技术和架构简单地“迁移”到数字校园建设中,应当有所甄别。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突