面向服务的

面向服务的（精选12篇）

面向服务的 篇1

●流量经营是数字服务的核心, 应针对个人、企业的不同层次需求, 最终形成类似“河道、航道、船、舱位”的不同层次、不同服务内涵的数据流量服务。其次, 运营商传统的基础语音和消息类服务面临着来自OTT厂商的巨大挑战, 演进到下一代融合通信是业务升级的主要方向。中兴通讯认为, 从运营商所面临的家庭客户、政企网客户角度, 也可以从多个角度拓宽服务领域, 围绕数字服务核心, 进一步精细化运营, 提升网络价值与带来盈利。

●家庭业务涵盖影音娱乐和智能家居两个领域。在影音娱乐方面, 运营商可通过OTT与IPTV的融合发展, 加快业务升级和丰富业务应用;在智能家居方面, 以掌控云服务平台和手机应用入口为重点, 运营商应大力发展家庭安防、家庭自动化创新服务。

●在政企网客户方面, 数字服务是通过打造面向企业的移动网络, 提供满足企业信息化发展需求的一体化服务, 并规模切入全球IT外包市场, 发展面向企业的云服务, 成为运营商差异化竞争的重要方向。同时在智慧城市的建设过程中, 搭建一个基于物联网、云计算、SOA (面向服务架构) 等先进ICT技术的城市运营中心, 构建智慧城市统一的应用框架, 抢占先机。

●在跨界创新方面, 物联网和大数据地位凸显:针对庞大的物联网市场, 电信运营商可以立足现有网络资源, 以完善和制定标准为手段、以物联网业务支撑平台为核心, 实现跨界行业市场的突破;大数据的挖掘应用成为电信运营商发展的新引擎, 主要方向为运营效率提升、精准营销/维挽、数据价值变现。

面向服务的 篇2

1.1 软件成本越来越高

计算机最初主要用作军事领域，其软件开发主要由国家相关部分扶持，因此无需考虑软件开发成本。随着计算机日益普及，计算机已经深入到人们生活中，软件开发大多面向民用，因此软件开发过程中必须考虑其开发成本，且计算机硬件成本出现跳水现象，由此导致软件开发成本比例不断提升。

1.2 开发进度难以控制

软件属于一种智力虚拟产品，软件与其他产品最大不同是其存在前提为内在逻辑关系。相较于计算机硬件粗生产情况，传统工作中的加班及倒班无法应用到软件开发中，提升软件开发进度无法通过传统生产方法实现。且在软件开发过程中会出现一些意料不到的因素，影响软件开发流程，导致软件开发未按照预期计划展开。由此可见不仅软件项目开发难度不断增加，软件系统复杂复杂性也不断提升，即使增加开发人手也未必能取得良好效果。

1.3 软件质量难以令人满意

软件开发另一常见问题就是在软件开发周期内将产品开发出来，但软件本身表现出的性能却未达到预期目标，难以满足用户多方位需求。该问题属于软件行业开发通病，当软件程序出现故障时会导致巨大损失。在此过程中软件开发缺乏有效引导，开发人员在开发过程中往往立足于自身想法展开软件开发，因此软件开发具有较强主观性，与客户想法不一致，因此导致软件产品质量难以让客户满意。

1.4 软件维护成本较高

与硬件设施一样，软件在使用过程中需要对其进行维护。软件被开发出来后首先进行公测，发现其软件存在的问题，并对其重新编辑提升软件性能，从而为客户提供更好服务。其次软件需要定时更新，若程序员在开发过程中并未按照相关标准执行会导致其缺乏技术性文档，提升软件使用过程中的维护难度。另外在新增或更新软件过程中可能导致出现新的问题，影响软件正常使用，并可能造成新的问题。由此可见软件开发成功后仍旧需要花费较高成本进行软件维护。面向服务体系架构原理

2.1 面向服务体系架构定义

面向服务体系构架从本质上是一种应用体系架构，体系所有功能均是一种独立服务，所有服务均通过自己的可调用接口与程序相连，因此可通过服务理论实现相关服务的调动。面向服务体系构架从本质上来说就是为一种服务，是服务方通过一系列操作后满足被服务方需求的结果。

2.2 面向服务体系架构优点

面向服务体系构架具有较多有点，抽象性较强，可操作性想，功能强大，可在多方面满足用户需求。其主要优点如下：

(1)面向服务体系构架可为开发方提供更具操作空间的开发模式，开发方可充分发挥自己的想法，有助于提升软件开发商开发方法先进性，提高软件开发效率。面向服务体系构架可充分利用软件提供者和使用者间较为松散的耦合关系，将复杂的逻辑关系屏蔽掉。相比于系统表示层，可在仅照顾服务接口的基础上实现软件开发，不需重视自身细节。通过标准接口可实现多种服务相互应用，无需进行平台开发语言等，极大提升软件开发效率。

(2)面向服务体系构架另一个优点是可在现有软件基础上进行研发，无需进行软件体系重建。且在情况允许的条件下利用现有软件开发框架可有效提升企业服务质量，该种方式可从根本上降低软件开发商的工作强度，提升工作效率，便于为用户提供更好服务。在此基础上将企业服务项目进行整合。面向服务体系构架忽略自身细节性问题，在复杂数据传输及软件开发中具有明显优势，有助于实现软件批量生产。面向服务体系构架的ECC系统总体设计

在进行面向服务体系构架的ECC 系统总体设计中可利用XML Web Services 实现对技术的展开。整个系统中每一部分均拥有其独立功能，均可提供相应的服务项目，客户通过网络接口便可享受到这些服务。在提供服务过程中，业务流程主要有两种途径，一种是提供单个服务，另一种是将多种服务整合在一起。

当前各种服务客户端中，多数可利用标准化网络服务接口实现面向对象的业务逻辑服务。通过设计可保证系统外部用户享受和内部用户一样的服务，这样便于实现企业内部和外部合作伙伴的业务整合。如在进行链子系统构建时可通过产品查询功能实现外部客户调动企业内部产品信息，此外企业不仅可实现为合作伙伴提供相应服务，还可在服务同时提升自身运营效率，即企业自身也是受益者。

当系统涉及到业务逻辑为可借助第三方服务帮助完成工作。例如企业需要在系统中加入采购、销售、仓管、财务等方面内容，该过程工作重点就是通过企业自身需求展开客户端设计，开发商通过远程连接向企业提供服务，这样不仅可降低软件开发周期和工作量，还可有效提升工作效率，为后续软件批量生产奠定坚实基础。结束语

面向新市民的档案信息服务研究 篇3

关键词：档案馆；新市民；档案信息服务

Abstract： The development of new urbanization has brought opportunities and challenges to the archives department. The archives should exert its advantage on the basis of resources， technology and policy， forming the new citizen archives information service model.And the archives should use technology to support the extension archives service， strengthen the collective memory， in order to provide archives information service for the new citizen to help them better in the city.

Keywords： Archives； New Citizen； Archives Information Service

新市民也被称为准市民[1]、半市民，是指未完成市民化状态的城市新移民，包括“就地城镇化”及“农村流向城市”两个主要群体。作为城镇化的产物，新市民这一特殊群体“市民化”的过程并不是简单的户籍身份、地理空间的改变，更重要的是熟悉城市文化、学习在城市的生存技能、内化新的规则和价值取向的过程[2]。在这一艰辛的过程中，新市民因其自身能力有限以及群体劣势，在融入城市生活过程中面临着社会选择危机；在市民角色的转换过程中又面临着身份认同危机。如何满足新型城镇化背景下新市民档案利用的需要，帮助新市民尽快融入城市，发挥档案部门在城市管理建设中的积极作用，提高档案部门的资政价值，成为当前档案事业发展的新课题与新挑战。

1 档案信息服务面向新市民的社会价值

“以人为本”是近年来国家各项事业建设的方向和目标，《国家新型城镇化规划（2014～2020）》更是提出推进以人为核心的新型城镇化。在此背景下，档案部门根据新市民群体的特殊性，结合其流动性、多重弱势、内部文化差距大等特征[3]，提供面向新市民的档案信息服务具有巨大的理论和现实价值。

1.1 强化身份认同，促进社会融入。新市民档案信息服务的缺失，造成了新市民城市生活记录的不完善，导致了其群体“失忆”状况严重，使其在城市社会文化和社会群体中处于被边缘化和自边缘化的尴尬境地，无法很好地在城市社会中找到自己的定位。面向新市民主动提供档案信息服务，一方面可以帮助新市民寻回属于他们的连贯准确的生活记录，证明其在城市社会建设中发挥的重要作用，避免成为“走过这个时代却没有留下痕迹的一群‘隐身人”[4]，强化其身份认同感；另一方面，可以将乡村档案资源与城市社区档案资源统筹起来，充分发挥档案的文化作用，促进新市民与原市民的沟通和交流，唤醒城乡二元文化中的同一性，满足新市民的情感需求，加强城市居民对乡村文化的了解，促进新市民的城市融入。

1.2 保障公民权利，激发参与意识。新市民在迫切融入城市的过程中，不仅争取自身的经济、社会权益，也希望在城市拥有自己的“话语权”[5]。但是由于其自身权利意识的缺失以及现行社会服务的不完善，使他们“在个人权益受到侵害时难以拿出维权的证据，从而遭遇种种不公，加重了他们与城市的疏离感” [6]，并被排斥在城市的边缘。面向新市民的档案信息服务以新市民诉求为出发点，不仅能够充分发挥档案的凭证工具价值，保障新市民这一弱势群体在面对社会矛盾和纠纷时处于更为有利的位置，合法合理地保障新市民权利，而且还能够促进新市民就业信誉度的提高，增强其市场竞争力，扩宽其就业渠道与范围，激发其参与城市建设管理的主人翁意识。

1.3 优化社会管理，服务政府决策。面向新市民的档案信息服务也是优化城市社会管理，服务政府决策的题中之义。新市民拥入城市后，对城市的基础设施、社会稳定、就业医疗等产生了巨大的影响。而新市民档案包含了大量有效信息，不仅可以为企事业单位用工管理提供便利，还“可以作为政府宏观规划的依据，给职能部门提供准确的信息依据”[7]，为政府部门如何管理新市民提供决策服务。实现新市民城市落户数量与城市基础设施建设速度之间的协调；实现新市民就业岗位类型与城市劳动力配置之间的协调；实现新市民城市生活需求与城市综合管理政策之间的协调。此外，新市民作为新型城镇化建设中的重要力量，其发展动态牵动着整个社会的稳定，建立面向新市民的档案信息服务体系也是党和政府保障民生、改善民生的助推器。

2 面向新市民档案信息服务的现状分析

档案馆拥有丰富可靠的资源、科学先进的技术和国家政策的支持，这些基础优势能为面向新市民的档案信息服务提供充足的内部支持和环境保障。但是，新市民档案工作涉及范围广、难度大，在服务方法、内容上还存在很多问题，其档案信息服务状况并不乐观。

2.1 新市民档案建设不完善。新市民人数多、流动性强，分布较为分散，档案形成的区域跨度大，导致了新市民档案建设的难度较大。同时，各地对于新市民档案建档内容，管理标准等缺乏统一的规范。另外，大部分地区只建立了城市大范围的流动人口档案，包括就业、健康医疗等，比如浙江湖州逐步建立针对工作半年以上外来者的健康档案，济南市建管局全国率先为建筑农民工建立“个人档案”等[8]，而对于新市民这一即将成为城市居民的群体，缺乏有效的关注，其在城市的生产、生活过程也缺乏有效的记录，更没有将符合条件的新市民纳入城市市民的统一管理体系，致使新市民档案建设的数量不足、门类不全、成效不大。

2.2 新市民档案信息服务方式落后。现有的新市民档案信息服务还停留在传统的被动式服务或浅层次服务状态。一方面，忽视了新市民群体的特殊性，没有对新市民群体内部进行分类，采取了“一刀切”式的档案信息服务。服务的内容也仅限于传统的档案利用，包括档案借阅、复制、展览等，而对于与新市民息息相关的生产生活类档案信息服务却涉及不多，比如针对新市民政策的现行文件查阅服务等。另一方面，“本位主义”思想严重，服务方法落后。忽视了网络新媒体技术的力量，没有采用微博、微信等备受年轻用户青睐的社交媒体提供主动式的档案信息服务，缺乏主动服务的意识，致使新市民档案信息服务的参与度和积极性不高。

2.3 新市民档案信息服务缺乏合作。区域档案部门掌握着科学的建档规则、保管方法和服务方式，政府部门拥有新市民城市生产生活广泛的记录，而社区作为城市管理的基本单元，是新市民接触最为频繁的集体互动空间，掌握着新市民基本的动态。但是，三个主要服务主体并没有形成良性的服务模式，各主体缺乏有效的沟通和合作，无法实现机构间优势互补，他们所掌握的资源也不能实现共建共享，极大地削弱了新市民档案信息服务的效力。

3 面向新市民的档案信息服务实现策略

档案部门开展面向新市民的档案信息服务是贯彻落实和谐社会建设及国家新型城镇化建设的战略举措。为了缓解新市民遭遇的社会选择危机及身份认同危机，进一步提升城镇新市民生活的满意度和幸福感，笔者认为应该形成多方参与的新市民档案信息服务机制，以技术为支撑，延伸档案服务，强化集体记忆，全方位、立体化地为新市民提供档案信息服务。

3.1 多方联动，资源共建。首先，全面构建以区域档案馆为主体，城市社区积极参与，以地方政府为协调的新市民档案信息服务模式（如图1）。一方面，广泛吸纳社区的力量，把档案馆与社区的力量联合起来，档案馆以主动服务者的身份向社区输送档案信息，特别要发挥社区档案室的力量，指导社区建设新市民档案信息服务平台；而社区则根据服务状况向档案部门反馈，以完善档案信息服务，社区不但是被服务者，更是档案信息服务的建设者。另一方面，地方政府部门要在政策、资金上给予档案馆及社区足够的支持，而档案馆则可根据新市民档案信息服务的情况，指导政府相关部门建立新市民档案，并向政府输送其所需要的档案信息产品，构建政府决策档案知识库，以辅助政府制定相关的政策。社区则可以根据新市民具体需求动态，及时反馈给政府相关部门。

其次，以新市民需求为着力点，合力共建新市民档案资源网络。一方面，档案馆作为平台的主导者，必须及时督促政府民生部门建立新市民档案，诸如医疗、社保、教育等部门要遵守新市民档案工作规范，并建立相应的配套制度。再者，档案馆要联合城镇社区力量，指导社区建立各自新市民档案库，包括社区生活、家庭健康、婚姻证明等均应该在其中有所体现。另一方面，要将区域内所有档案部门，包括城市地方档案馆及新市民原住地档案馆（室）的力量结合起来，与地方政府民生部门及城镇社区共建新市民档案资源网络，共建共享，互通有无，保障新市民档案接收的有效性和及时性。

3.2 技术支撑，创新方法。首先，转变技术手段，实现数字化、网络化服务。为了改变其被动式服务及浅层次服务的服务状态，亟须整合技术与方法，丰富服务渠道和服务形式。一方面，充分借用已有的各地档案网站、微信、微博服务平台，在其服务平台中增设“新市民档案服务”栏目，并开设网上定制、网络推送等主动服务方式。另一方面，由于新市民流动性较大，因此要重视新市民基层社区档案的建设，可以从城乡接合部及城市社区等新市民聚集地的建档工作抓起，加强新市民“一人一档”“一户一档”工作。

其次，积极引进大数据技术、云计算技术及人机交互技术，不断满足新型城镇化背景下新市民多样化需求，适应信息动态变换，提升新市民利用档案信息的效率。而在不断提高技术水平，简化操作程序的同时，也要及时规避“技术墙”[9]的产生，联合社区、政府部门及社会媒体做好对相关服务程序及服务技术的宣传解读工作，进一步推进新市民档案信息服务的人性化和无障碍化。此外，网络化服务及新兴技术的应用也对技术标准和信息安全提出了更高的要求，档案部门要及时出台相关的管理标准，比如软硬件标准和元数据标准，统一规范地管理新市民档案，保障服务的安全性和有效性。

3.3 延伸服务，立体辐射。首先，面向新市民提供档案信息服务的空间和内容应当有所延伸。一方面，囿于档案馆人力、物力的有限性与新市民流动性大、需求多样之间的矛盾，笔者认为可借助上海奉贤区庄行镇“档案信息服务中心”模式[10]，由上至下建立档案信息服务网络，或者与各地新成立的“新市民服务中心”合作，将档案信息服务纳入服务内容中，比如常熟新市民服务中心、佛山新市民服务中心等已经开展了包括政府信息公开等方面的服务工作。另一方面，延伸档案信息服务内容，从传统档案信息服务扩展到档案知识服务。新市民在融入城市的过程中必然会遇到许多现实性问题。档案馆通过对新市民档案资源的广泛收集和整理，在充分理解新市民需求的基础上，“利用自身处理和服务机制对信息资源进行二次挖掘、聚类和重组帮助其解决现实问题”[11]，比如针对新市民医疗健康档案及政府新市民政策形成的专题知识信息产品。

其次，新市民群体在职业、年龄、教育程度及市民化程度上的差异性决定了档案信息服务的多样性和多维性。一方面要保证服务可以横向、纵向、立体辐射到各个档案信息需求层次的新市民，真正做到均等、公平。另一方面，新市民来源地泛而广，对信息接收的方式及参与的积极性不同，因此需要结合新市民特点及地方特色，区别化、针对性地服务。比如对新市民的下一代群体，可加强互联网、社交媒体方面的档案信息服务，以提高其参与的热情；对文化素质不高的新市民，可利用方言提供档案咨询服务等。

3.4 强化记忆，扩大交流。首先，档案馆要通过档案资源强化新市民群体的集体记忆，帮助其更好地融入城市。一方面及时收集，整理出新市民为城市作出贡献的活动档案，广泛开展宣传展览活动，帮助其建立城镇生活的归属感、市民身份的认同感及城镇市民的主人翁意识。同时，为了保证新市民群体记忆的连贯性，档案馆应该借鉴哈尔滨农民工档案馆的经验[12]，设置专门的“新市民档案馆（室）”，并广泛收集新市民在当地的经济、文化生活等档案记录，展现不同时期新市民的历史风貌，扩大档案信息服务的范围，深入新市民的生活。

其次，以档案信息服务为契机，扩大新市民与城市原住民的文化交流。一方面，档案部门要多方统筹新市民来源地乡村档案，包括民俗民情、宗教文化及地方文娱等。同时，对新市民在城市的民俗、宗教等文化活动要及时记录和保护起来并在特定时期进行宣传和展览，加强原市民对新市民文化的了解。另一方面，充分发挥社区档案的文化功用，开展科普教育、群众娱乐等文化活动，积极引导新市民参与进社区文化的建设中来，形成团结互助、友善和谐的社区风尚，扩大双方的文化交流，丰富新市民的精神文化生活。

4 结语

国家新型城镇化的推进给档案部门带来了新的机遇和挑战，由于新市民档案工作范围广，难度大，区域档案馆面向城镇新市民的档案信息服务还处于探索阶段，面临着艰巨的任务，需要档案馆与社会各部门通力合作、相互支持，更需要全体档案工作者以主动服务的姿态，齐心协力推进档案服务社会民生的进程，为地方社会发展作出应有的贡献。

参考文献：

[1]任远，邬民乐.城市流动人口的社会融合：文献述评[J].人口研究，2006，03：87～94.

[2]张文宏，雷开春.城市新移民社会融合的结构、现状与影响因素分析[J].社会学研究，2008，05：117～141+244～245.

[3]孙红蕾，郑建明.新市民社区信息服务创新与思考[J].图书情报知识，2015，05：74～81.

[4]冯惠玲.当代身份认同中的档案价值[J].中国人民大学学报，2015，01：96～103.

[5]苏昕.“城市新移民”公民权的缺失及回归探析[J].中国行政管理，2012，05：46～50+97.

[6]冯惠玲.当代身份认同中的档案价值[J].中国人民大学学报，2015，01：96～103.

[7]王晶.农民工档案的建立与和谐社会的构建[J].上海档案，2010，11：18～19.

[8]成杏丽.中国新型流动人员——农民工档案初探[D].山东大学，2010.

[9]孙红蕾，郑建明.新型城镇公共信息服务平台构建策略研究[J].图书馆，2015，08：63～67.

[10]严永官.奉贤区庄行镇“档案信息服务中心”管理模式在全区推广[J].上海档案，2010，05：25.

[11]牛力，王为久，韩小汀.“档案强国”背景下的档案知识服务“云决策平台”构建研究[J].档案学研究，2015，05：74～77.

[12]闫金立.哈尔滨市建立第一个农民工档案馆[J].兰台世界，2012，01：36.

作者单位： 南昌大学人文学院历史系（前湖校区）

面向服务的流程优化研究 篇4

为了提高流程优化调整的效率，本文引入面向服务的思想，对企业的流程进行服务化改造，在此基础上给出一种灵活的流程优化方法。

1 面向服务的思想

面向服务的体系架构(Service-Oriented Architecture, SOA)是一个组件模型，将应用的不同功能单元通过服务之间定义良好的接口和契约联系起来。接口独立于实现服务的硬件平台、操作系统和编程语言，各种系统包含的服务可以以一种通用和一致的方式进行交互，使系统集成不必关注底层的实现细节。

SOA具有以下基本特点：

(1)面向服务。SOA以服务作为关注的重点，支持面向服务的开发方法。服务从更高的抽象层次上定义，与业务相对应，可通过面向过程、面向对象等方法来实现。

(2)松耦合。SOA强调服务之间松耦合，包括了三层含义。一是接口松耦合，即服务接口封装了所有的实现细节，使服务请求者看不到这些实现细节;二是技术松耦合，指服务请求者和服务提供者的实现和运行不需要依赖特定的某种技术;三是流程松耦合，指服务不与特定的业务流程相关，能够重用于不同的业务中。

(3)灵活性。在SOA的应用系统中服务是实现功能的基本单位。服务的可重用性和重组服务提高了业务的灵活性。

(4)标准化。SOA应用系统中的服务应尽量支持开放的标准，通过标准化提高互操作性。

2 流程服务化改造

流程服务化改造是指采用面向服务的思想，对企业的已有业务系统进行封装改造，使其成为由服务集成的业务系统。经过流程服务化改造的应用系统具备了服务赋予的灵活性，可以很好地适应需求的变更。流程服务化改造的关键是从业务系统中提取功能进行服务封装和建立支持可灵活重组服务的集成框架。

2.1 服务的封装

服务的封装根据良好定义的服务接口来进行，通过SOA的集成开发工具可以根据服务契约生成服务代理与服务框架代码。服务契约一般采用WSDL来进行描述，服务代理代码需要包含在服务请求者中，服务框架为实现新服务提供框架。服务通过接口与企业服务总线连接，使得不同的服务可以相互交换数据，参与业务流程，互相协作完成具体的业务操作。在进行流程服务化改造时，可通过适配器对现有流程中的功能进行封装，提供良好定义的服务接口，以适应新的SOA应用模式。

2.2 服务的集成框架

SOA应用系统的运行和流程的优化调整有赖于服务的集成框架。服务的集成框架将具有不同业务功能的服务按照一定方式编排完成完整的业务流程。该集成框架主要包括辅助工具、服务合成服务和其它服务运行支撑环境。辅助工具包括了业务建模工具、集成开发工具等。业务建模工具主要是用来进行业务的梳理、分析，实现对业务的准确理解，将业务流程与封装好的服务关联起来，完成服务的编排。服务合成服务主要是在系统运行的时候按照编排的要求调用不同服务，对外展现为一个业务流程。其它的服务运行支撑环境主要包括管理服务、企业服务总线和适配器等，实现服务的管理、服务之间的通信等功能。业务流程建模工具和服务合成服务是服务集成框架实现服务重组的关键。

3 流程优化过程

流程优化是指在管理业务流程的基础之上按照业务的变更需要对流程进行调整，使其达到较高的效能。在对业务流程进行服务化改造之后，流程的优化过程大体上包括以下两个步骤，交替进行，直到系统能够满足业务需求。

(1)流程的评估。流程的评估主要是依据业务的需要对系统包含的流程进行静态、动态的分析，从中发现与需求不符或效能低下的部分。由于系统的流程已经进行了服务化改造，那么通过使用辅助工具可以对系统现有流程进行静态分析。动态的流程分析可通过系统实际运行或者仿真运行来实现。

(2)流程的重组。流程的重组是对流程评估中发现存在问题的环节进行调整。首先通过业务建模工具对现有的业务需求进行分析，然后针对原有的流程中与需求不符的功能或者环节进行修改，将服务编排为满足用户需要的流程。

4 结语

本文从流程的服务化改造入手，提出了在面向服务的框架下对流程进行优化重组的思想，为提高企业应用快速反应能力、优化企业流程提供了一条新思路。

摘要：业务流程优化需要较高的成本。文章提出利用面向服务的思想改造企业流程, 以较小的代价基于服务重组实现流程的优化调整。

关键词：面向服务,流程优化,服务重组

参考文献

[1]赵亮, 姚青.基于SOA的可变业务流程管理系统[J].计算机工程与设计, 2010 (24)

[2]褚文永, 姚青.基于消息的可变业务流程模型的设计与BPEL实现[J].计算机应用研究, 2010 (7)

面向服务的 篇5

发布: 2010-10-19 14:40 | 作者: 徐志发 陈更新 | 来源: | 浏览:551次

字体: 小 中 大 | 上一篇 下一篇 | 打印 | 评论(1)

摘要 本文参照eTOM模型，从端到端的运营过程、面向集团客户的组织保障、面向集团客户的资源储备等几个方面，对移动运营商在信息运营时代面向集团客户的运营体系进行了初步的分析，旨在为向信息化转型中的移动运营商从流程、组织和资源开发等方面提供运营方面的一些参考建议。

关键词 转型 信息运营 集团客户 行业信息化 资源 流程

1、影响移动运营商面向集团客户信息化服务的主要因素

集团客户是各运营商的战略客户和重要收入来源，在企业转型时期集团客户更是企业间的战略争夺焦点。政府信息化、企业信息化、行业信息化构成了运营商外部信息化的主体，而这都可以归结为运营商面向集团客户的信息化，面向集团客户的信息化服务是“信息运营”的最重要的组成部分（下文中的集团客户运营即指面向集团客户信息化运营）。

由于种种原因，移动运营商在拓展集团信息化业务时，遇到了很多困难，这其中有市场竞争激烈、政策管制的因素，也有公司自身的因素。开拓集团客户信息化市场是综合性系统工程，需要整个公司资源的通力配合。结合移动运营商的特点来看，目前影响集团客户信息化服务市场开拓的主要因素有：

●网络资源：虽然拥有庞大先进的通信网络，但是移动运营商在接入层管道、光缆资源方面相对于固网运营商仍很缺乏，而最后一公里接入始终是制约移动运营商发展集团客户的瓶颈。

●组织架构：移动运营商多年来多专注于移动语音业务，公司的组织架构、资源配置均以移动语音业务为中心，对数据业务，特别是集团客户的数据业务缺少统一管理。并缺少为集团客户服务的专业维护体制和维护人员。

●运营流程：目前面向集团客户的业务开发、实现、保障等流程涉及环节多、效率低，需要调整、优化。

●产品开发：产品开发缺乏统一规范指导，没有形成完整的产品生命周期管理。

●营销方式：各类业务宣传、受理界面相互独立，没有统一的业务人口，很难相互引导带动，资费也不够灵活。

●合作模式：没有好的商业模式，不能充分调动社会力量，对代理商缺乏有效的管理，对集团客户缺乏有效的服务机制和流程。

●支撑系统：目前集团客户业务变更和业务资源分配工作需要通过客户经理手工完成，成本高，效率低。产品相关支撑系统接口复杂，扩展性差，难以支持合作伙伴业务模式。

这其中很多因素互为因果、互相关联，大多数都是传统的运营体制局限性所带来的副作用，这些问题在信息化转型过程中必须尽快解决，下面的分析主要依据中国移动公司的相关信息。

2、集团客户信息化运营的理论基础—eTOM参考模型

电信运营是一项极其复杂的企业活动，它需要市场营销、客户消费心理、网络建设、网络维护、企业管理等多个领域的知识与经验，对于竞争极为激烈的集团客户市场来说，就更需要一套完善的运营理论做指导。

经过多年探索，国际上的一些标准化组织、电信运营商以及电信设备商、开发商总结出了一套比较完善模型—eTOM，使电信运营过程逐步走向了标准化、规范化和科学化，并且使纷繁复杂的业务过程（流程）成为可量化、可穷举的过程。国际上多数知名的运营商已经参照这些模型，对已有的公司运营流程和IT系统进行了改造，在提高工作效率、改善客服水平、提高市场响应速度等方面取得了明显效果，因此移动运营商也可以参照这些模型来完善自身业务流程，尤其是完善集团客户的工作流程，以提高对集团客户的支撑能力。

TMF eTOM对电信运营企业的环境进行了整体描述，eTOM将企业环境分为三部分：战略、基础设施和产品过程组（strategy,infrastructure and product,SIP）、运营过程组（operations processes，OPS）、企业管理过程组（enterprise management,EM）。运营过程是eTOM的核心。它既包括日常的运营支撑过程。也包括为这些运营支撑提供条件的准备过程，以及销售管理和供应商／合作伙伴关系管理。

eTOM模型的各个功能组的划分如图1所示。

图1 eTOM Levell视图

eTOM模型来源于电信运营企业的实践，与电信运营企业中的各项企业活动以及所涉及的组织、人员与资源密切对应。简单来讲，eTOM模型可以从两个主要的视角来进行描述定位企业运营工作，一个是CIO（首席信息官，可以理解为公司的IT部门负责人）视角，一个是CEO（首席执行官，即公司老总）视角。CIO视角主要从模型的横向角度观察，侧重考虑公司运营相对独立的各类组织和各类资源（当然CIO视角下的诸多问题也是CEO所关注的，后面还会解释）；CEO视角主要从模型的纵向视角观察，重点关心公司的各项活动（这里主要考察的是生产活动）是如何充分利用公司各项资源完美实现，落实到eTOM模型主要就是一个端到端流程的问题。

首先简单看一下CEO视角下的集团客户运营的相关问题。

3、面向集团客户的端到端流程分析

端到端业务流程是指一项业务（或服务）的开展应具有明确的发起端和结束端，是完整、统一、可控、有序、闭合的过程，每一个环节具有明确的功能定义，并且确定了各环节之间的关系和接口，从而使业务（或服务）以一种透明、无缝的方式呈现给客户，在共用的、共享的平台上形成一个对客户完整的支撑，包括快速的业务提供、快速的业务定制和完善的资源管理，最终为客户提供所需要的满意的业务（服务）。只有将客户、业务与网络几个层面很好地结合起来实现端到端的业务流程管理，才能实现提高效率的目标。

图2给出了电信运营企业生产活动的7个端到端过程，基本涵盖企业运营的各个方面，涉及到了企业中各主要生产部门。7个端到端过程实际上是一些具体生产活动涉及流程的高度抽象，真实流程需要贯穿横向的组织和资源的支撑和保障才能最终成功完成。

图2 面向集团客户7大核心端到端过程

SIP中涉及3个过程，策略、基础设施生命周期管理和产品生命周期管理主要体现了企业内部的前期生产管理流程，基本上不与客户直接沟通，这3个过程主要是在运营环节之外制订企业的业务发展策略、预测资源需求以及针对不同客户开发适合的产品。

（1）集团客户信息化服务策略制定与发展规划

从前台（潜在的集团客户）到后台（潜在的合作伙伴／供应商），包括营销发展目标策略和中长期发展规划、业务发展目标策略和发展规划、资源发展目标策略和发展规划、供应链发展目标策略和发展规划，实现了策略制定和规划阶段的端到端的完整过程。

（2）集团客户信息化服务基础设施生命周期管理

从前台到后台，包括营销能力和产品提供能力的分析、预测、设计、交付，业务需求能力的设计和交付，资源需求能力的设计和交付，供应链需求能力的设计与交付，实现了支撑产品的基础设施的容量、能力需求的设计和交付的完整过程。

（3）集团客户信息化服务产品生命周期管理

从前台到后台，包括产品的开发和完结、业务的开发与完结、资源的开发与完结、供应链的开发与完结，实现了产品开发阶段的端到端的完整过程。

OPS包括了4个过程。它们直接服务于集团客户，其中的运营支撑和就绪保证是为实际的运营过程做准备的，进行一些市场、客户、业务、资源的运营设施、工具、平台的准备工作，包括最后测试、验证和检查等工作，FAB包含了业务实现、业务保障和业务计费3大过程，它们是整个电信企业运营中的核心生产过程，直接体现了运营水平。通过这些过程客户直接感知到运营商的产品质量和服务能力，是电信运营企业中最敏感的3个过程。这也正是移动运营商目前在开展集团客户信息化工作过程中比较薄弱的地方，未来几年应重点对这些过程所涉及的流程进行优化。

（1）集团客户信息化服务运营准备

从前台（真实的集团客户）到后台（真实的合作伙伴／供应商），包括客户关系管理的准备和相关工作的就绪保证。业务的准备就绪，资源的准备就绪和供应链的准备就绪，实现了面向客户运营准备阶段的端到端的完整过程。这一过程往往在运营阶段不单独出现。

（2）集团客户信息化服务业务实现

从前台到后台，包括销售响应和订单管理、业务配置和激活、资源指配、S／P征用，实现了面向客户运营业务实现阶段的端到端的完整过程。

（3）集团客户信息化服务业务保障

从前台到后台，包括故障处理和SLA管理、业务故障管理和业务质量管理、资源故障管理和资源性能管理、S／P故障报告和S／P质量管理，实现了面向客户运营业务保障阶段的端到端的完整过程。

（4）集团客户信息化服务业务计费

从前台到后台，包括出账和收费管理、业务划价和计费、资源数据采集和处理、S／P结算和计费管理，实现了面向客户运营业务计费阶段的端到端的完整过程。

为了顺利完成这些过程，需要各部门紧密配合，不仅要明确每个部门自身的职能职责，而且应明确部门之间的接口，确定部门的输入与输出，使这些流程成为闭合、完整、有序的过程集合。

集团客户运营体系中的端到端流程，实际上是一个类似矩阵形状的结构，纵向的端到端实际上需要横向的组织和资源的完整支持，而且局部的流程也具备端到端的特点。下面从几个方面对相关问题做简单论述：

（1）在客户服务（业务保障）方面

无论是业务受理、变更、咨询以及客户投诉等被动服务方式，还是向客户提供主动的服务（如向大客户及时通报网络覆盖等信息），不仅仅是客服部门的职责，更需要客服、市场、计费、网络部门都协力配合，共同向客户提供准确、完整、及时的信息。在该流程中，发起端为客户（包括普通客户和大客户），一般会经过客服部门、业务支撑部门、网维部门，最后再返回给客户。

（2）在业务实现方面

需要市场、客服、业务支撑、网络等多个部门相互配合开发出适应市场需求的多样化产品，同时应确保网络资源在容量、性能满足业务要求。在该流程中，发起端一般为市场开发部门。并分别从客服部门、网络部门以及业务支撑部门收集有关客户、网络和竞争对手信息，在此基础上开发出新业务。

（3）在网络运行方面

电信网络具有全程全网的性质，完成一项电信业务一般要经过接入层、承载层、交换层和业务层等众多专业网络的相互配合，因此电信网同样具有端到端的特点。

（4）在供应链管理和实现方面

随着市场进一步细分和市场竞争机制的逐步成熟，电信业务的交付必然向整个价值链上延展。作为传统电信业务来讲，供应商和合作伙伴的管理和支撑的IT化，也将改变现有的客户服务、业务提供和资源保障的诸多流程，特别是面向集团客户更需要考虑整个价值链上的端到端流程。eTOM最新版本也提出了B2B流程模型应对这一需求。这部分的内容这里不做进一步说明。

面向集团客户信息化服务的端到端流程建设是一个复杂的问题，需要结合企业自身的特点和需求，根据自己的定位和发展目标谨慎、深入地进行研究，才能更好地支撑移动运营商集团客户信息化服务的工作。

下面再从CIO视角对集团客户运营涉及的相关问题进行简单分析。包括运营组织相关问题和运营资源体系的构成等。

4、面向集团客户运营的组织保证

前面已经谈到，CIO视角的一个重要特点就是对企业的运营过程进行横向观察，得出不同部门之间的相关特征。因此eTOM的CIO视角是确立面向集团客户信息化服务组织保证的一个很好的理论依据。

图3给出了移动运营公司中的相关生产部门的职能对eTOM模型的大致映射情况。

图3 移动运营企业组织对eTOM模型的映射情况

横向的功能层是运营体系的“静态”部分，给出了移动运营商在开展集团客户信息化工作中应具备的各项职能。从满足客户需求的角度分析，服务于集团客户的与服务于普通客户的组织架构是一致的，通过图4可以看出移动运营商目前的组织架构基本覆盖了集团客户运营体系所要求的各项职能。

图4 移动运营公司面向集团客户信息化的支撑组织分布

为了更好地向集团客户提供高质量的业务和服务，真正实现面向集团客户的端到端的流程支撑，移动运营商应加强市场和网络部门中对集团客户的服务职能，不但大市场需要设立专业的集团客户（大客户）服务管理部门，大网络也应该成立相关专业部门（可以是虚拟的组织）。在大网络构建集团客户响应中心（组），直接监控、分析集团客户的网络运行质量与资源利用情况，并及时与大市场集团客户专业部门进行响应和支撑。

除了加强部门自身职能建设外。同样应重视部门之间的接口建设工作，明确每个部门的输入信息和输出信息，实现端到端的客户服务与网络管理。

5、面向集团客户的运营资源体系

电信运营企业的运营可以看成是围绕各种资源而进行的各种活动，资源是电信运营企业中各种内部的／外部的、物质的／非物质的、易变的／不变的功能元素或功能集合。通过有效的组合、利用这些资源，为客户提供服务，为企业创造价值。移动运营商现有的资源可以分为内部资源和外部资源。宏观意义上的内部资源包括公司的产品业务资源、网络资源等；外部资源主要包括客户（客户实际上也可以属于企业内部的资源之一）和供应商／合作伙伴等。在eTOM参考模型里，资源一般特指与网络和计算机系统相关的资源，包括网络、IT和应用，与上述概念并不完全一致。企业的内部资源又可以按照大市场和大网络的分界分为隶属于大市场范畴的客户资源、产品资源、业务资源和隶属于大网络的通信网资源、管道局房资源、IT资源等网络类资源。各种资源都是发展集团客户业务的关键资源，而且需要综合利用，很多资源实际上是一种依托关系，这也是前面所分析的端到端流程的另外的一种体现。如产品、业务资源其实质还是网络资源的一种抽象包装形式。下面简要分析一下各种资源的开发模式。

5.1 产品及业务资源的开发

与面向个人的基础语音业务相比，集团信息化业务需求更显多元性和差异性，同时随着全社会对信息化关注度的提高，市场竞争也会更加激烈。移动集团信息化业务要取得成功，一是产品要能满足集团客户的多元化、个性化需求。二是要有“移动”的优势和特点。

5.1.1 提供一体化“套餐”业务

一方面，随着社会信息化、网络化程度的不断提高，企业集团用户对通信业务的需求呈现出综合化、多样化的特点。除了固定通话、移动通话之外，企业集团用户还需要VPN、企业邮箱、商务会议、呼叫中心等业务。在这种情况下，让用户有一种需求就去申请一种业务就显得非常繁琐。因此，用户普遍希望电信运营商能够提供满足自身信息需求的一体化解决方案，而不仅仅是对某项单一业务的提供。这直接推动了电信业务提供模式由单一向组合转型的潮流。

另一方面，提供组合打包的业务也是电信企业拓展新市场的需要。例如一个中小企业对互联网的理解并不深，对宽带接入的需求也不强烈，但对自身的宣传很看重。如果我们将企业网站设计和宽带接入组合提供，用户往往会欣然接受。反过来说，如果仍单个地提供业务，不仅不能满足用户的信息需求，而且对用户的利益也是一种损害。通过“一站购齐”式的组合业务，用户的信息消费需求将被充分激发。

5.1.2 体现“移动信息化”特点

在固定数据业务方面，传统的固定运营商中国电信、中国网通有明显的竞争优势，移动运营商要想取得市场突破，必须充分发挥随时、随地、随身的移动通信优势，整合资源为社会各行业量身打造符合行业特点的移动信息化应用，使移动信息化逐渐成为行业信息化的主流，实现了社会各行业与其自身的可持续发展。

随着信息化与行业发展需求的深度结合，传统信息化与行业需求特点不能挈合的局限性已经显现。在人员流动性大、数据分散、信息化程度不平衡的行业信息化条件下，人们一旦离开固定网络所在的终端，往往就无所适从。而具有高到达率、高普及率和实时互动特征的移动信息化却可以突破这一壁垒，根据各个行业特点量身打造信息化解决方案，在现有信息资源整合的基础上提供适合行业特点的应用。

在行业内部，移动信息化可以打造随时、随地、随身的沟通平台，使内部信息资源的共享更加及时有效。在行业外部，移动信息化可以为行业机构与客户的信息沟通打造畅通的实时互动交流平台。比如在交通行业，智能交通综合信息平台可以实现驾驶过程中的信息查询、定位导航等应用；“银信通”、“手机银行”等使客户借助手机就可实现账户查询、联机转账等多种金融理财服务。

另外，庞大的用户群也为移动应用能在行业信息化发展中大有作为打下了坚实基础。我国移动电话用户总数已经超过了固定电话用户总数，这就使得在以信息化带动工业化的战略下，移动信息化能够逐渐成为行业信息化的主流，渗透到影响国民经济发展的各主要行业。

随着移动通信技术的不断进步，以及互动性更强的视频、多媒体等手段介入，移动通信网络将能更方便灵活地提供丰富多彩的个性化服务，极大地满足不同行业用户的不同需求。

5.2 外部资源（价值链）的开发

集团客户信息化有两层含义：一是提高企业自身信息化水平；二是利用移动公司的产品，集团客户为自己的客户提供信息化的服务。移动办公类产品基本都属于前一种情况，而移动商务类产品就是银行、商业等行业利用移动公司提供的产品再为客户提供诸如手机支付等信息化手段，对于这类产品，移动公司一般会与第三方进行合作开发。

在3G时代，合作模式将是移动运营商面临的重要问题，关系到电信运营产业链的建设，而产业链直接决定了未来整个电信运营业能否健康、高速、稳定的发展。主要有以下几类合作伙伴（也都是集团客户和潜在的集团客户）：提供内容服务的SP；使用该项业务的集团客户；软硬件厂商。

移动运营商应加强与软硬件厂商的合作。通过与硬件设备商、软件商及应用服务提供商建立广泛的合作联系，可以扩大产品覆盖范围，并且加速新产品开发及应用，以满足客户需求。在双方合作中可充分利用各自的优点：移动运营商拥有极为丰富的客户群，拥有大量客户的资料信息，并且在业务提供方面有丰富的经验；移动运营商具有广泛的无线网络基础设施，基本实现100%的覆盖；具有发达的销售和服务渠道。

而软硬件厂商一般具有以下特点：专业化的技术开发和维护力量；具有功能完善、性能稳定的专业软件；快速灵活的市场反应机制。

因此通过双方的合作，将进一步降低客户的购买成本，简化安装和维护量：拓展了移动运营商的市场空间，并且能根据企业客户的需求来订制专门的服务内容，提高了业务质量，提供SLA保障，增强了产品的竞争力。

5.3 网络资源体系分析

网络资源是移动运营商运营的核心资源，是开展所有业务的前提条件。在上述的几大资源里面，网络资源是目前移动运营商发展集团客户的瓶颈，网络资源的问题不解决，可能会在集团客户信息化服务的竞争中失掉先机，甚至对整个公司未来的运营效益带来巨大的负面影响。

现有的网络资源包括接入网、核心网、传送网、业务网和IT支撑系统。这些资源都可以为集团客户信息化服务。

为了更好地研究网络资源体系的能力和不足，确定网络资源的发展目标。把面向集团客户信息化资源配置体系进行细分显得非常必要。从整个企业运营支撑资源来讲，包括产品业务资源在内，企业内部运营支撑资源可以划分为八个层次：解决方案层、产品层、业务层、管理支撑层、业务能力层、业务接入层、网络承载层、基础资源层，如图5所示（以移动为例）。

图5 移动运营商集团客户信息化资源体系

从网络相关资源来讲，可以划分为五个层次进行分析研究：管理支撑层、业务能力层、业务接入层、网络承载层、基础资源层。对上述五个层次的网络资源按照功能和属性进行归类，基本可以归结为六大类资源：语音网络、移动数据网络、互联网与IP网络、业务网、支撑平台和基础资源。

移动运营信息化资源提供能力方面最大的优势是优质的移动通信网络资源，但在基础资源和后台支撑能力上，有明显的不足。为取得竞争优势，一方面应有针对性地加大建设力度，另一方面要跟踪技术发展，通过新的技术手段来弥补不足之处。

基于以上分析，可以对移动运营公司现有面向集团客户信息化的资源进行评估：

（1）语音网络资源

语音业务部分在集团客户信息化服务中所占比例（特别是技术实现难度）并不大，因此语音网络在集团客户信息化网络资源体系中属于丰富资源，不是发展的瓶颈。

（2）移动数据网络资源

移动数据网络包括现有的数据网络，也包括将来3G数据网络、WiMAX等网络，是支撑集团客户信息化服务的重要网络资源，今后网络需要不断建设和完善。移动数据网络也属于丰富资源，随着滚动建设和发展可以满足相关业务需要。

（3）互联网与IP网络资源

核心网络资源丰富，基本不存在资源瓶颈；IP城域网和接入网部分往往受传输资源限制，是重点发展资源。

（4）业务平台资源

业务平台和应用平台都属于此范畴。这部分资源未来发展空间很大，需要随着业务的发展而发展。

（5）支撑平台资源

支撑平台涉及语音支撑系统和数据业务支撑系统，随着3G业务的开展也会有新的平台出现，现有的平台也需要不断的完善和提升。

（6）基础资源

传输核心网络指的是骨干和汇聚网络，一般来讲资源丰富，能够满足未来发展的需要；传输接入网则是移动公司未来的发展重点；而管道线路则受到具体的市政局限，是未来发展的重点，但也是最大的难点。

6、移动运营商发展集团客户信息化业务的几点建议

集团客户是移动公司的战略客户群，也是各个电信运营商现在和未来竞争的焦点。集团客户信息化需求为移动公司发展集团客户提供了新的切入点。就目前而言，发展集团信息化业务既是市场竞争、吸引和发展移动用户的需要，也是适应和迎合我国社会信息化大发展的需要，同时也是提高企业经营效益，增加业务收入的有效手段。因此，移动运营商要着眼企业未来的发展，把集团客户信息化业务的发展放在战略的高度，采取积极的态度投入集团客户信息化业务领域竞争中，全力拓展移动运营商公司的业务市场，以确保移动运营商在集团客户信息化市场上占据一定的市场份额。建议目前工作重点如下：

●充分发挥移动自身资源优势。固网运营商依靠固定网络资源，已经占领了集团客户接入业务的大部分市场，在集团客户信息化方面抢得先机，移动运营商必须集中自身优势资源，以移动信息化为切入点，实现集团客户服务的新突破。

●结合城市信息化建设，利用移动语音、数据业务与固定数据业务进行组合，并通过资费的优惠、个性化的解决方案和优质的服务开拓企业市场，实现“专线接进去，移动信息化应用引出来”。

●针对现有集团大客户，深入了解其需求，利用优惠政策

结合现有数据行业应用捆绑销售数据专线业务，达到“深度捆绑”，减少流失风险。

●以各行业有影响力的大企业为突破点，建立示范工程和样板工程，以点带面，促进移动信息化的区域性扩散。

●在业务开展初期，受接入网络资源所限，可以考虑其它的一些业务发展方式，如可以和广电、电力以及社会上的其它商业用户合作，借助外部网络资源发展用户。以各种方式和较低成本推动中小型客户接入业务的发展，解决最后一公里瓶颈。

●采取灵活的策略，吸引社会上各类信息化服务提供商，共同发展集团客户。信息化是一个庞大的系统工程。依靠单个运营商自身的力量很难做到对客户的全面服务，在这方面可以借鉴中移动“梦网模式”，加强与社会力量合作，实现“双赢”。

面向“三农”　延伸服务 篇6

日前，记者采访了太和县农村信用联社理事长徐红光。徐红光思维敏捷，谦逊平和，其求真务实、开拓超前的工作作风，深受县委书记刘家坤的好评。在以徐红光为首的联社党委带领下，太和县联社围绕改革、发展的目标，认真做好三大业务。一是做大做优负债业务。积极吸收各类低成本存款，优化存款结构，巩固农村储蓄阵地；二是做大做稳资产业务。树立营销观念，细分信贷市场，改善信贷资产结构。面向“三农”，巩固农村市场；面向城镇社区，延伸金融服务，面向农村中小企业，培育黄金客户；三是做大做强中间业务，做实利润。

信贷支农 深入到户

近年来，太和县联社一手抓改革，一手抓发展，全面服务于“三农”，对促进地方经济发展和新农村建设起到了主力军作用。

徐红光告诉记者，联社以服务“三农”为己任，面向“三农”定位市场。要求信贷人员深入到村、组、户，谋划发展项目，安排生产资金，建立完善了农户经济档案，办理了小额信用贷款证。在农户小额信贷发放上突出“四优先”，即社员贷款优先、守信户贷款优先、农户贷款优先、农业贷款优先。2006年，全县信用社累放农户小额贷款48957万元，有力地支持了李兴中中药材生产加工、税镇木线板材、双浮毛发、赵庙“三粉”、赵集树苗、朴人商厦、六本食品、三泰面粉等一大批农产品生产加工及商贸企业的发展。今年上半年，先后发放涉及医药、运输、加工业流动资金22989万元，办理贷款证177622户，占全县农户总数的55%，发放小额信贷21480万元，新增农户小额信贷占各项贷款的70.2%，为新农村建设提供了有力的资金保障。

队伍建设 主抓培训

安徽省太和县农村信用联社的队伍建设重在政治思想和业务素质全面发展。

一是深入开展“落实科学发展观、转变作风、服务发展”的主题教育活动。二是加强业务培训，县联社先后举办了综合业务、非信贷资产风险分类、信贷资产风险管理、信贷业务操作与管理学习等多个培训班，为服务 “三农”做足了内功。

内部改革 激活潜能

徐红光强调，2007年票据兑付是太和联社的工作重点，县联社以专项票据兑付促进了产权制度改革，推动了经营机制转换。目前，徐红光和他的同仁们正认真对照票据兑付政策，精心准备，力争年内成功兑付。

主要工作：一是提高非信贷资产五级分类质量。2007年在巩固已有信贷五级分类成果的基础上，全面实施了非信贷资产五级分类；二是改革分配制度。在2006年工资分配制度改革基础上，全面推进了客户经理业绩工作制，彻底打破了平均分配制，激活了员工的内在潜能；三是改革经营管理方式。为实现由传统组织形式向流程银行的根本转变，为客户提供快捷、满意的综合化金融服务。

面向服务的体系结构 篇7

面向服务的体系结构 (Service-Oriented Architecture, SOA) 也叫面向服务架构.是指为了解决在Internet环境下业务集成的需要, 通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型, 它将应用程序的不同功能单元 (称为服务) 通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。对于面向同步和异步应用的、基于请求/响应模式的分布式计算来说, SOA是一场革命。一个应用程序的业务逻辑 (Business Logic) 或某些单独的功能被模块化并作为服务呈现给消费者或客户端。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用而无须理解服务的底层实现。举例来说, 一个服务可以用.NET或J2EE来实现, 而使用该服务的应用程序可以在不同的平台之上, 使用的语言也可以不同。

2 SOA的特征

在Internet这样松散的使用环境中, 任何访问请求都有可能出错, 因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术, 如EJB、COM或者CORBA, 都需要有一个宿主 (Host或者Server) 来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候, 在该宿主上运行的其它应用服务就会受到影响。

对于.NET Remoting、EJB或者XML-RPC这些传统的分布式计算模型而言, 他们的服务提供都是通过函数调用的方式进行的, 一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下, 这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计, 但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐采用大数据量的方式一次性进行信息交换。

由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。在COM、CORBA这些传统的组件模型中, 从服务器端传往客户端的是一个二进制编码的对象, 在客户端通过调用这个对象的方法来完成某些功能;但是在Internet环境下, 不同语言, 不同平台对数据、甚至是一些基本数据类型定义不同, 给不同的服务之间传递对象带来很大困难。由于基于文本的消息本身是不包含任何处理逻辑和数据类型的, 因此服务间只传递文本, 对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。

虽然面向服务的体系结构不是一个新鲜事物, 但它却是更传统的面向对象的模型的替代模型, 面向对象的模型是紧耦合的, 已经存在20多年了。虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务, 但其整体设计却是面向服务的。由于它考虑到了系统内的对象, 所以虽然SOA是基于对象的, 但是作为一个整体, 它却不是面向对象的。不同之处在于接口本身。SOA系统原型的一个典型例子是通用对象请求代理体

系结构 (Common Object Request Broker Architecture, CORBA) , 它已经出现很长时间了, 其定义的概念与SOA相似。

3 SOA的优势

(1) 编码灵活性:可基于模块化的底层服务, 采用不同组合方式创建高层服务, 从而实现重用。此外, 由于服务使用者不直接访问服务提供者, 这种服务实现方式本身也可以灵活使用。

(2) 明确开发人员角色:例如, 熟悉BES的开发人员可以集中精力在重用访问层, 协调层开发人员则无须特别了解BES的实现, 而将精力放在解决高价值的业务问题上。

(3) 支持多种客户类型:借助精确定义的服务接口和对XML、Web服务标准的支持, 可以支持多种客户类型, 包括PDA、手机等新型访问渠道。

(4) 更易维护:服务提供者和服务使用者的松散耦合关系及对开发标准的采用确保了该特性的实现。

(5) 更好的伸缩性:依靠服务设计, 开发和部署所采用的架构模型实现伸缩性, 服务提供者可以彼此独立调整, 以满足服务需求。

(6) 更高的可用性:该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节, 这样服务提供者就可以在Web Logic集群环境中灵活部署, 使用者可以被转接到可以的例程上。

4 SOA的使用

对SOA的需要来源于需要使业务IT系统变得更加灵活, 以适应业务中的改变。通过允许强定义的关系和灵活的特定实现, IT系统既可以利用现有系统的功能, 又可以准备在以后做一些改变来满足系统之间交互的需要。下面举一个具体的例子。

一个服装零售组织拥有500家国际连锁店, 它们常常需要更改设计来赶上时尚的潮流。如果零售商和制造商之间的系统不兼容, 那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用WSDL接口在操作方面的灵活性, 每个公司都可以将它们的现有系统保持现状, 而仅仅匹配WSDL接口并制订新的服务级协定, 这样就不必完全重构它们的软件系统了。这是业务的水平改变, 也就是说, 它们改变的是合作伙伴, 而所有的业务操作基本上都保持不变。这里, 业务接口可以作少许改变, 而内部操作却不需要改变, 之所以这样做, 仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变, 在这种改变中, 零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店, 这可以看作是采用店中店 (Store-in-Store) 的业务模型。这里, 虽然公司的大多数业务操作都保持不变, 但是它们现在需要新的内部软件来处理这样的出租安排。在这种情况下, SOA模型保持原封不动, 而内部实现却发生了变化。虽然可以将新的方面添加到SOA模型中来加入新的出租安排的职责, 但是正常的零售管理系统则如往常一样。

5 结束语

SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准, 为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用;SOA能够使客户或服务消费者免予服务实现的改变所带来的影响;SOA能够升级单个服务或服务消费者而无需重写整个应用, 也无需保留已经不再适用于新需求的现有系统。总而言之, SOA以借助现有的应用来组合产生新服务的敏捷方式, 提供给企业更好的灵活性来构建应用程序和业务流程。

参考文献

[1]王卫.SOA, 别忘记网络[J].IT时代周刊, 2007 (13) .

[2]徐涵.SOA十大原则[J].程序员, 2007 (5) .

[3]丁兆青, 董传良.基于SOA的分布式应用集成研究[J].计算机工程, 2007 (10) .

[4]李春旺.SOA标准规范体系研究[J].现代图书情报技术, 2007 (5) .

面向服务体系架构的研究 篇8

关键词：面向服务的软件体系结构(SOA),Web Service,面向服务的分析与设计

1 SOA的定义

从总体上来讲,面向服务体系结构SOA(Service Oriented Architecture)是一种结构模型,它可以根据需求并通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。现在关于SOA尚未有一个统一的的定义,甚至有些还相互冲突。目前大多数人将SOA定义如下:“面向服务的体系结构是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来,接口是采用中立的方式进行定义的,独立于实现服务的硬件平台、操作系统和编程语言,使得构建在各种这样的系统中的服务可以用一种统一和通用的方式进行交互。”

2 SOA与传统架构的比较

由于SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范,这就决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用。

SOA被认为是传统紧耦合的、面向对象模型的替代者。像通用对象代理架构CORBA和分布式组件对象模型DCOM。与传统架构相比,SOA具有更多优势:基于标准、松散耦合、共享服务、粗粒度和联合控制。SOA与大多数通用的客户端/服务器模型的不同之处在于它着重强调软件组件的松散耦合,并使用独立的标准接口。

SOA不是一种全新的技术,而是对更传统的、紧密的面向对象模型的另一种选择。而且SOA并没有排斥面向对象,系统的总体设计是面向服务的,但是具体到某个服务的实现可以是基于面向对象设计的。SOA是允许对象在系统内存在的,所以SOA其实也是基于对象的,但是SOA作为一个整体就不是面向对象的,可以说SOA是更高层意义上的架构。SOA和面向对象的区别在与接口上,面向对象的接口是给其他对象使用的。而SOA的接口是可以给从组件到系统来使用的,SOA的接口一般使用web服务、EJB、CORBA等分布的技术来实现。

3 SOA的元素

3.1 SOA参考架构模型

SOA的模型描述了三个角色(服务提供者、服务注册库和服务请求者),执行三种操作(发布、查找、绑定),具有简单、动态和开放的特性。图l简明地表述了SOA模型。

SOA模型中的角色包括:

1)服务提供者(Service Provider):从企业的角度看,是服务的所有者。从体系结构的角度看,是被访问服务的运行平台。服务提供者是一个可通过网络寻址的实体,它接受和执行来自服务请求者的请求,它将自己的服务和接口契约发布到服务注册中心,以便服务请求者可以发现和访问该服务。

2)服务注册中心(Service Registry):服务注册中心是服务发现的支持者,它包含一个可用服务的存储库,是可搜索的服务描述的注册中心。服务提供者在此发布他们的服务描述,同时服务请求者也可以从服务注册库以外的其它来源得到服务描述,例如本地文件、盯P站点、Web站点等。静态绑定中,服务注册库是可选的,因为服务提供者可以把描述直接发送给服务请求者;在动态绑定中,服务请求者通过查找(Find)动作实现对服务的查询并获得在服务描述中的绑宁信息。

3)服务请求者(Service Request。r):从企业的角度看,是要求使用某些特定功能的企业。从体系结构的角度看,是寻找并调用服务的应用程序,或是启动与服务交互的应用程序。服务请求者是一个应用程序、一个软件模块或需要一个服务的另一个服务,它发起对服务注册库中的服务的查询,通过传输绑定服务,并且执行服务功能。

SOA中的每个实体都扮演着服务提供者、服务请求者和服务注册库这三种角色中的某一种(或多种),在这些角色之间使用三种操作:

发布(Publish):为了使服务可访问,服务提供者需要发布服务描述以使服务请求者可以发现和调用。

查找(Find):服务请求者定位服务,方法是查询服务注册中心来找到满足其标准的服务。

绑定(Bind):在检索完服务描述之后,服务请求者根据服务描述中的信息来调用服务。

3.2 SOA的组成元素

基于SOA的参考模型,我们抽象出SOA的4个组成元素:应用程序前端、服务、服务库和服务总线,如图2所示。

“应用程序前端”是业务流程的所有者。“服务”提供业务功能,可供应用程序前端和其他服务使用。服务的“实现”提供业务逻辑和数据。服务的“合约”为服务客户指定功能、使用和约束。服务的“接口”物理地公开功能。“服务库”存储SOA中各个服务的服务合约。“服务总线”将应用程序前端和服务连在一起。

4 SOA与Web Service

为了能够实现SOA,业界给出了一套SOA的标准。用服务作为建模单元并非最近才有的,正如前文所说DCOM和CORBA等都是在早期萌发SOA雏形的初步设想阶段的产物,但是他们的努力并没有使SOA发扬光大。而随着技术的发展,更主要是随着Web Services的出现,大大刺激了SOA的发展。它给出了一个目前最好的实现SOA的方式。Web Services本身的特性决定了它能够满足SOA提出的要求,比如Web Services本身也是基于Internet的、基于标准的消息描述语言或网络传输协议等。但是我们有理由相信Web Services这种技术终将被另一种更先进的技术所取代。

4.1 Web Service与SOA的关系

SOA与Web Services是两个不同层面的问题,前者是概念模式,面向商业应用;后者则是实现模式,面向技术框架。SOA概念并没有确切地定义服务具体如何交互,而仅仅定义了服务如何相互理解。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面,Web服务在需要交互的服务之间如何传递消息有具体的指导原则。从战术上实现SOA模型是通过HTTP传递的SOAP消息的Web服务模型。

Web Services建立在开放标准和独立于平台的协议的基础之上。Web Services通过HTTP使用s OAP(一种基于XML的协议),以便在服务提供者和消费者之间进行通信。服务通过WSDL(服务描述语言)定义的接口来公开。UDDI是一种语言无关的协议,用于和注册中心进行交互以及查找服务。但是值得注意的是Web Servi。es仅仅是实现S以的一种技术,与SOA是血与肉的关系。只是因为Web Service S的发展,在很多层面满足SOA的实现需要,所以使得web Services成为目前开发SOA应用程序的优秀选择。

从本质上讲,Web Servces是实现SOA的具体方式之一。基于Web Services的SOA具有以下优势:

1)它是基于标准的,这意味着机构不再需要对专有解决方案进行投入,以免受制于个别厂商。

2)它支持解决方案间的互操作,令你可以使用不同厂商的、具有单项优势的产品,以显著降低成本。

3)它支持机构内的集成,而且可被扩展为支持跨机构和机构间的集成。

4.2 基于Web Serv1ces的SOA集成模型一WSOA

随着Web Services技术的成熟,尤其是所依托的XML,SOAP,wSDL,UDDI均已成为开放行业标准,使得基于Web Services的SOA实现,成为了公认的实施SOA架构最好的方式,是很多企业采用的一种应用集成方法。本文将SOA与Wob Services结合起来,提出了个基于Web Services的SOA集成体系架构模型一WSOA,如图3。

WSOA架构模型仍然是基于SOA架构的三类主体(角色)的,即离散Web服务资源的服务提供者、UDDI注册库、通用客户端的服务请求者。根据WSOA模型,我们在对企业进行SOA的实施时,首先对现有应用系统进行分析和服务界定,把原有系统的一些需要对外暴露的功能进行Web服务封装,部署到应用服务器。这样,现有应用系统既能被其它应用程序通过Web服务进行调用,又能保证原有应用的运行不会受到影响;然后服务提供者对应用服务器上的Web服务进行WSDL描述,通过SOAP协议将其在UDDI注册库中进行注册和发布,如果这些Web服务之间存在着一定的关系,则UDDI注册库管理系统对注册服务之间进行关联和动态组合,以便服务请求者调用服务;通用客户端就是服务的请求者,通用客户端通过到UDDI注册库查找并发现服务,再通过SOAP消息动态、按需地获取服务的WSDL文档的地址,然后解析WSDL文档,调用Web服务,进行服务集成。

在图3所示的模型中,我们把服务划分为遗留系统所封装的服务,和新开发的单独的服务,或者是由其他厂商提供的服务。客户端可以是任何一个需要进行SOA实施的应用。如果是对遗留系统的改造,则可以与左边的遗留系统提供的服务进行交互,如果是己用SOA架构开发松耦合系统,只是需要扩展现有功能,则可以采用和右边的新增服务及其他服务进行交互的方法。当然客户端也可以是一个待构建的全新SOA系统,那么它就可以完全通过在UDDI注册库中查找所需服务来构建一个新系统。UDDI注册库是一个可用服务的存储库,存储了所有可用服务的信息,以供请求者查找。

5 总结

SOA作为一个新兴的软件体系架构,越来越受到人们的重视,其技术也处于不断的发展与更新之中。全面应用Web Servies及ESB/SOA的开发方法仍然有不足的地方。对于旧的系统,需要进行改造才能支持SOA,这个修改不是一件简单的事情。除了需要资金,用户还需要时间、勇气、理念,以及抗风险的充分准备。另外开发人员己经习惯旧的设计和开发模式,采用截然不同的新模式和工具,需要重新培训。不过最大的问题还是开发调试的问题,基于SOA的系统一般需要集成很多的系统或者模块,还会使用很多包装好的控件、服务,这些都是经过很多层包装的组件,开发人员很难深入了解这些组件,当他们抛出错误的时候(例如底层跑出NullPointer Exeeption),由于信息不够明确或者stacktrace太长,将会很难找到问题的所在。但是,SOA是未来发展的必然趋势。随着IBM,微软,oracle,Bea等多个大公司在SOA方面加大力度,更多的优秀产品投入市场,我相信在未来几年SOA将迅速成为企业级Web应用的主流技术架构。未来的Web应用系统的开发就会好像桌面应用系统开发那样简单。

参考文献

[1]IBM.What is Service-Oriented Architecture(SOA)[EB/OL].http://www-128.ibm.com/developerworks/webservices/newto/#1

[2]Principles of SOA Design[EB/OL].www.webservices.org.

[3]O’neil M.Web服务安全技术与原理[M].冉晓旻,郭文伟,译.北京:清华大学出版社,2003.

面向服务架构技术的接口设计 篇9

特别是, 在服务逻辑之前先创建服务契约会带来下列好处:

· 能够将服务设计成能精确表达服务候选的语境和功能。

· 服务的操作名称使用约定, 将使端点定义标准化。

· 可将操作粒度建模成提供一致性和可预知的接口设计。

· 要求底层应用遵照服务设计来表示。

· 业务分析师能进行业务服务的设计。

本文以Student服务的设计步骤, 初步的要求是能够执行一个查询以获得他的学籍基本信息和宿舍信息, 通过赋予以下两个操作候选来表达这两个功能:GetStudentDetailInfo。

GetStudentDormInfo

1 第一步:审查现存服务并定义实体Schema

设计新服务的第一步是确认它是否是必须的, 如果其他服务存在, 它们也许已经提供了在操作候选中识别出的部分或者全部功能;或者它们已经建立了适当的语境, 通过它能够实现这些新操作。

SOAP消息在其封装的Body部分携带了有效负载数据。需要对该数据进行组织和分类, 我们依靠XSD schema可以完成这一操作。实际上一个单独的schema可以嵌入到type结构中, 在那里可以定义每个表示SOAP消息体的数据元素。

对于该Student服务从需要识别的数据着手, 这些类别的数据将履行“学籍基本信息”的处理需求。以定义两个复杂类型结束:一个包含Student服务接收的请求消息所要求的搜索准则, 另一个包括服务返回的查询结果。有意识的命名类型, 使类型与各自的消息相关联。这两个类型组成了新的StudentInfo.xsd.schema文件。如下:

但是我们发现从StudentInfo.xsd.文件中派生出的schema并不包括宿舍信息, 该信息是不在学生信息采集系统中的, 而是在宿舍管理系统中, 于是我们使用不同的targetNamespace来识别截然不同的起源, 命名为StudentDorm的schema。

为了提高可复用性, 并且允许单独维护WSDL的每个schema文件, 将 XSD schema语句 import 用于把两个 schemas的内容放到Student服务 的WSDL文件的 types 结构中。

2 第二步:派生抽象接口

接下来, 我们将分析服务的候选操作, 并且遵照下列步骤来定义初始的服务接口。

(1) 确认每个操作候选是恰当的, 并且通过合理的逻辑封装粒度来保证重用。

(2) 在WSDL文件中创建portTpye域, 并用候选操作的operation结构来展开它。

(3) 列出每个操作的逻辑处理所需要的输入和输出值。这可以通过引用子集part 元素中的XSD Schema 类型, 定义合适的message结构来完成。

决定使用GetStudentDetailInfo () 和GetStudentDormInfo () 两个操作。

随后进入抽象定义的剩余部分, 以下就是定义了message和portTpye结构后的结果:

3 第三步:应用面向服务原则

根据本文前面分析的对于Web Service没有提供的4条面向服务的原则来进行分析:

服务可复用性;

服务自治;

服务无状态;

服务可发现性。

可复用性会在第四步进一步推广, 第四步可将设计扩展到更容易的需求。

由于以实体为中心的服务经常要求组合成服务层, 而且他们依赖应用服务层来执行某些业务逻辑, 所以他们的即时自治通常都定义的良好。

同样, 无状态也是相对可管理的, 以实体为核心的服务一般并不拥有大量的工作流逻辑, 并且那些要通过调用多个应用来执行操作的情况, 首选的是延期状态管理。

可发现性是以实体为核心的服务设计和后续部署需要利用的重要部分, 正如第一步中所述, 我们必须确保设计的服务并不是重复已存在的逻辑, 发现机制会使这个决定更加简单。同样, 我们可以采用documentation元素的元数据细节来使其更容易被发现。

在审查了初始的抽象服务接口后, 可以确定结合少量修改就能够更好地支持基本的面向服务、。特别是, 将元消息增加到WSDL定义中, 这样能更好地描述两个操作及其相关消息的目的与功能。

以下是用额外的元数据文件来补充服务接口的结果:

4 第四步:标准化和简化服务接口及其扩展服务设计

调整抽象服务接口, 特别是将命名约定结合到标准化的操作名称中去, 使用命名标准对内在互操作性提供了本地支持, 这是当代SOA的关键特性。

以下是具有新的标准化名称的两个operation结构:

本步骤包含执行一个推理分析, 在它预定义的功能语境中应该为这个服务提供哪些其他类型的特性。实现新功能一般有两种方法:填加新操作和在现存操作中填加新参数, 虽然后一种方法可能更有效的简化服务接口, 但它可能会违背直觉, 因为太多的参数与操作相关, 可能要求服务请求者了解房屋的众多内容以便有效利用它。所以填加操作是提供与实体相关的明显功能最直接的方式, 以实体为核心的服务的一组经典操作是:

GetSomething

UpdateSomethng

AddSomething

DeletSomething

标准操作在业务服务层构建了一致的互操作水平, 促进了可复用性, 但是不要为了潜在的可复用性使操作过度复杂化。

为此对于本服务我们分析能够增加到Student服务的几类操作如下:

GetDetailInfo

GetDormInfo

UpdateDormInfo

下面示例显示了portType结构如何扩展补充操作的。

5 小结

本文给出了一个具有指导意义的服务的设计步骤与过程, 并在设计过程中应用设计服务的指导原则, 比如使用命名标准, 注重于可扩展性, 识别当前和未来的服务请求者, 使用模块化WSDL, 以及使用原数据说明服务。通过本章的分析, 我们可以看到, 把以实体为核心的业务服务设计为精确表示现存业务的实体, 而保存业务的处理不可知。这其中可能需要一些推理分析, 以便用所需范围的通用操作适当地以配备以实体为核心的业务服务。

参考文献

[1]朱振杰.SOA的关键技术的研究与应用实现[J].电子科技大学硕士文, 2006.

[2]Mark Endrei, Jenny Ang, Ali Arsanjani, et a1.Patterns:Service Oriented Architecture and Web Services.IBMIn.temational Technical Support Organization, April 2004.

[3]Mark colan.Service-Oriented Architecture expands the visionof Web Service http://www-128.ibm.com/developer-works/webservices/library/ws-soaintro.html, 2004.

浅析面向服务架构体系的搭建 篇10

一、SOA的定义

SOA, 是一种基于服务的业务组建模型, 它通过服务间定义良好的接口和契约联系起来。接口采用中立的方式定义, 独立于具体实现服务的硬件平台、操作系统和编程语言, 使得架构在这样系统中的服务可以使用统一和标准方式进行通信。

SOA架构的基本元素是服务, 服务是代表着一定业务功能且可以被其他方请求调用。服务是独立而自治的, 它屏蔽了平台、语言、业务流程等具体技术问题, 具有标准化的接口, 使用服务的用户只关心服务给出的结果, 而不用关心业务细节和技术实现方式, 可以在未来很方便的加入或取消服务。

二、SOA模型的角色关系

万维网联盟 (W3C) 给出了SOA模型中服务提供者、服务请求者、服务代理者等角色的关系。

服务提供者主要提供符合契约的服务, 并将它们发布到服务代理;服务请求者也叫服务消费者, 它发现并调用其他的软件服务来提供商业解决方案, 消费者可以是终端用户、应用程序或者别的服务;服务代理者, 作为储存库, 产生由服务提供者发布的软件接口。

这三种SOA参与者通过3个基本操作:发布、查找、绑定相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务, 并绑定到这些服务上。服务提供者和服务请求着之间可以交互。

三、SOA体系搭建

SOA体系包括服务的提供、使用、说明、中介等四个方面。

搭建SOA体系, 首先要定义原子服务, 从业务角度讲, 每一个原子服务可以是每一个基本的业务单元, 将原子服务进行合成为可以使用的服务, 当然, 单独的原子服务也可以为服务, 然后, 对服务进行编排, 定义各自的业务流程, 最后构建服务消费者访问和使用服务的方法。

为了更清楚地描述SOA的搭建过程, 我们通过实现银行业IT系统的例子来进行分析说明, 银行的核心业务系统为SOA角色中的服务提供者, 企业服务总线系统为SOA角色中的服务代理者, 而使用服务的系统, 如网上银行、ATM、柜员、手机银行、中间业务平台等系统则为SOA角色中的服务消费者。核心业务系统向企业服务总线系统发布服务, 企业服务总线系统则对这些服务进行合成、编排, 组成很多的业务流程, 并分别发布给网上银行、ATM、柜员、手机银行、中间业务平台等各种各样的服务以供使用。如简单的ATM取款交易, 客户在进行取款交易时, 客户触发取款动作后, 在拿到现金以后, 同时可以自动看到自己账户的余额, 这就是通过企业服务总线系统将核心业务系统的取款、余额查询等二个原子服务编排成一个简单的业务流程对ATM系统进行发布。而同样的取款交易, 通过柜员系统进行取款时, 企业级服务总线系统则可能只将核心业务系统的取款原子服务组成一个业务流程对柜员系统进行发布。这是不同的业务需求对业务流程的不同要求。

一个成功的SOA系统应该总在变化之中的, 可以很灵活、敏捷的适应业务需求的变化, 服务总是位于业务和技术之间, 通过业务驱动服务, 服务驱动技术。

四、SOA的特征

通过对SOA体系的搭建, SOA体系具有一些特征:

封装和重用性:原子服务可以按照业务流程进行不同的封装, 封装可以隐藏复杂性, 服务发布后可被很多服务消费者重用, 这种设计降低了业务变更成本, 使变更便的更为简单、可行。

自治性:SOA体系屏蔽了平台、语言、业务流程等具体技术问题, 强调架构的自我管理和恢复能力。SOA体系应该良好的支持事务处理、队列冗余部署、集群管理等技术。

松藕性:服务消费者可以在未来很容易的加入或取消服务, 或者选择新的服务, 而不需关心服务提供者实现的技术细节, 甚至不必知道响应自己需求的服务的位置及原子服务。

五、小结

SOA体系已被做为一种通过对齐IT和业务来促进业务敏捷性的方法而被广泛接受, 通过SOA架构可以相对较低成本的获得某种敏捷性, 适应业务的快速变更、灵活发展, 但SOA并不是适应于各个业务系统的, 它只是一种基于业务复用的架构方法, 如果对业务变化理解力不足, SOA带来的麻烦可能比普通系统更多。为了尽早达到后期低成本的多次业务迭代愿望, 在项目实施早期为此目的而构造企业架构是非常有意义的。

摘要：面向服务架构 (SOA) , 是一种形式化的方式分离服务的架构风格, 在构建弹性架构强烈的需求背景下发展起来, 对整个企业级软件架构设计带来巨大的影响。本文首先对SOA的定义进行简单介绍, 并对SOA模型的角色关系、体系搭建及特征等进行分析。

关键词：SOA,体系搭建,服务

参考文献

面向Web服务的消息中间件模型 篇11

关键字： Web服务；消息中间件；面向服务的体系架构；XML

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2007)18-31491-02

A Model of Message-Oriented Middleware Oriented Web Services

QI Yan-ke1, 2, XU Hong-bing1

(1.School of Computer Science & Engineering, Southeast University,Nanjing 210096, China; 2.Zhengzhou Institute of Aeronautical Industry Management, Zhengzhou 450015,China)

Abstract:Combining Message-Oriented Middleware (MOM) with Web Services, the cut-in and advantages are nailed down by introducing Web Services and MOM in detail relatively. The design goals of Web Services-oriented MOM system are indicated. Finally, a MOM model is put forward and discussed.

Key words:Web Services; Message-Oriented Middleware; Service-Oriented Architecture; XML

1 引言

随着Internet在各个领域应用的深入，分布式计算和三层/多层体系结构得到了长足的发展。企业级的应用也向着三层和多层体系结构的分布式环境不断迈进。开发和利用异构平台上的企业级应用迫切需要一种基于标准的、独立于计算机硬件及操作系统的开发和运行环境。中间件技术应运而生。

中间件（Middleware）介于操作系统和各种分布式应用程序之间，通过屏蔽分布环境的异构性和复杂性，以简化分布式应用程序的开发和维护。

2 Web服务和消息中间件

2.1 Web服务

Web服务（Web Services）是新一代的开放分布式处理技术，可以方便地实现Internet上跨平台、语言独立、松散耦合的异构应用的交互和集成。

2.1.1 Web服务的概念

我们可以从不同的角度理解Web Services[2]。技术层面上，Web服务基于XML、采用SOAP协议，是一种软件互操作的基础设施；应用层面上，Web服务用于集成应用，作为一种协作措施，将原有的软件系统改造为基于消息的松散耦合系统或者构建新的松散耦合系统。

2.1.2 体系架构及技术规范

Web服务采用面向服务的体系架构（Services-Oriented Architecture, SOA），通过服务提供者、请求者和注册中心之间的交互实现服务调用。如图1。因此，消息交换是Web服务的核心内容。

图1 Web Services体系结构

Web Services涉及的技术规范包括XML、WSDL、SOAP和UDDI[1]。WSDL是程序员描述Web Services的编程接口；Web Services通过UDDI注册自己的特性，其他应用程序通过UDDI找到需要的Web服务；SOAP则提供了应用程序和Web服务之间的通信手段。WSDL，SOAP和UDDI都建立在XML基础之上。

开放分布式处理中的互操作性一直是其要解决的根本问题。Web服务使用SOAP协议实现异构应用之间的互操作性。SOAP协议基于HTTP。然而，HTTP协议无状态、不可靠等不足，使其不能为企业Web服务提供可靠、安全的消息传输机制。

2.2 消息中间件

消息中间件（Message-Oriented Middleware, MOM）是中间件中发展较为迅速，也是比较成熟的一类中间件。

2.2.1 核心技术

消息中间件以消息的形式收发不同系统中的应用程序数据，解决不同系统或应用间的通讯问题。通信的双方以异步、非阻塞、确定的方式收发消息，不需要实际的物理通路。因此，消息中间件很适合松散耦合系统。

消息传递是消息中间件的关键技术。消息中间件采用多种机制以保证消息可靠、高效、安全的传输，如核心的异步机制、多路由的管理、优先级机制等。

2.2.2 体系结构

在企业级应用的三层体系结构中，消息中间件位于中间层，即业务逻辑层。消息中间件通过核心的API，可扩展到不同的系统和平台上，从而满足Internet环境下快速、可靠地连接异构资源的需求。消息中间件的结构如图2。

图2 MOM结构

消息中间件为消息通信提供了质量良好的底层通信框架，为企业级应用开发提供了统一、健壮的通讯平台。然而，传统的消息中间件更多地专注于企业局域网应用环境，在扩展到Internet环境时显得不足，难以满足复杂网络环境下大规模交互的需要。

2.3 Web服务与消息中间件的结合

通过以上分析，一方面消息中间件需要通过Web服务扩展以更好地适应Internet环境；另一方面，为构建企业级应用，Web服务需要消息中间件提供其所需的异步性和可靠性，以扩展Web服务的应用领域。

3 设计目标

利用Web Services中的SOA思想组建消息中间件，可以实现以下目标：

（1）灵活性

依靠具有独立架构的服务接口，为消息中间件提供强大的重用性和灵活性；

（2）可靠性

通过服务扩展和重组，更增强消息传输的可靠性；

（3）交互性和扩展性

采用统一的XML消息格式，具备良好的交互性和扩展性。

同时，Web服务通过消息中间件可以进一步提升应用性能，扩展应用领域。

4 一种消息中间件模型

目前比较有影响的消息中间件产品和规范有IBM的MQSeries产品、Sun的JMS（Java Message Service）规范和Microsoft Message Queuing。但他们都存在明显的不足。如JMS 定义了一系列API，但JMS基于Java语言，限制了它与非Java语言实现系统之间的交互。

我们提出一种面向Web服务的消息中间件模型。模型提出的主要思想是将MOM和SOA结合，以Web服务的形式提供MOM的API，能够使Web服务和优势互补，更好地为企业级的分布应用开发提供支持。图3所示为三层体系结构中该消息中间件的架构。

图3面向Web Services 的消息中间件

在该消息中间件模型中，主要由Web Services接口、代理Agent、消息队列、注册服务队列以及队列管理器组成。

4.1 功能架构

4.1.1 消息格式

该模型采用XML作为统一的消息格式。

首先，XML格式的消息数据可以非常方便地在异构平台间传递；其次，XML 的自我描述特性，使得基于XML 的消息可以在不同的应用之间进行交换与处理，不需要相应的应用程序对消息数据进行定制。另外，XML 对多种语言的支持也有利于该消息中间件模型适应多语种应用的开发。

4.1.2 Web Services Interfaces

Web服务本身就是一种“组件”，可以对其封装，使消息中间件的API以Web服务的形式提供给应用程序，便于各分布式应用的交互；而且，服务本身能够根据需求进行扩充或重组，具有良好的扩展性。

4.1.3 Agent

该模型通过一个消息代理进行通信，通讯双方不直接通信，而是通过消息代理进行。消息发布者将消息传递给消息代理，消息代理可以实现消息的动态路由功能，负责路由消息给相应的接收者。因此，该模型适合松散耦合系统，并能够安全地实现消息的异步通信。

4.1.4 消息队列

消息的异步传输使得应用间交换和处理的消息可能不能及时得到传输。未传输的消息就暂时存放在消息队列中，等待消息代理。因此，该模型中消息队列的主要作用是进行简单的负载平衡。

4.1.5 注册服务队列

MOM以Web服务的形式为各应用程序提供接口。系统中其他服务器的Web服务接口信息需要向该服务器注册，注册信息包括Web服务的类型及所在的服务器等，保存在注册服务队列中。应用程序的服务请求或者消息处理结果通过查询注册服务队列确定待发送或者返回的Web服务接口。在进行服务的注册、扩充或重组时，需要同时修改注册服务队列，便于Web服务接口的及时发现。

4.1.6 队列管理器

队列管理器主要负责消息队列或注册服务队列的创建和删除。

4.2 模型的运作流程

（1）服务注册与注销

系统中某个服务器进行了服务扩充或者重组等，需要重新注册服务。服务注册的消息传输到目标服务器后，队列管理器负责注册服务队列的修改，Agent负责该服务注册消息的继续传输。服务注销时则删除服务注册队列中相应的服务器信息。

（2）服务请求

在接收到应用程序的服务请求消息后，系统在注册服务队列中搜索匹配的注册服务器信息，并将该信息封装到消息中，转交给Agent。Agent根据消息中封装的目标服务器信息，进行动态的路由，同时根据约定的格式转发消息。

（3）服务响应

目标服务器完成处理要求后，转发处理结果给发送服务器。处理结果同样以系统既定的消息格式表现。发送方服务器接收到结果消息后，根据消息中的参数信息得到应用所需的数据，返回给应用程序。这个过程可直接完成，不涉及注册服务队列的操作。

（4）消息传输

消息传输从应用程序发出发送服务请求开始。经由服务请求过程、Agent路由转发完成。在消息传输的过程中，如遇网络故障、阻塞等情况，消息队列负责暂时存储待传输的数据，保证传输数据不丢失，同时起到负载平衡的功能。

5 结束语

文中提出了一种面向Web服务的消息中间件模型，对该模型的功能模块与运作流程进行了简单介绍。该模型能够达到所提出的设计目标。但是，还有注册服务队列的性能与维护、Agent的动态路由以及消息安全加密技术等问题有待我们进一步探讨。

Web服务与消息中间技术的结合涉及计算机领域的多个经典问题，如网络消息的安全传输、Web服务的事务处理、负载均衡等值得进行深入研究。我们相信，这些问题将依然是研究热点，并推动企业分布式应用的进程。我们也将对这些问题继续研究和讨论。

参考文献：

[1]杨涛，刘锦德. Web Services技术综述——一种面向服务的分布式计算模式[J]. 计算机应用. 2004，24（8）：1-4.

[2]廖军，谭浩. 新一代开放分布式处理技术——Web Services[J]. 计算机应用. 2004，24（8）：5-9.

[3]苗春雨，史美林，姜进磊. MOM_S：基于Web服务的消息中间件系统[J]. 通信学报，2006，27（11）：96-100.

[4]唐俊，吴永英. 面向服务的消息中间件模型及实现[J]. 计算机应用. 2005，25（11）：2703-2704.

[5]胡光强. 基于Web Service技术的消息中间件的设计与实现[D]. 北京：北京交通大学软件学院，2006.

面向服务的标绘系统设计与实现 篇12

标绘系统是服务于作战指挥自动化和战场环境的数字化建设,是能够提供战场空间和时间态势认知的信息系统。目前国内用于作战指挥的标绘系统基本都是基于桌面环境应用的,而国外关于标绘图形系统的研究也绝大部分是桌面应用程序,美军目前正在研究网络协同作战指挥系统。对于由多军、多兵种参与的作战或演习,必然要求各单位共享作战态势,进行标绘作业。由于参战单位的分布性,用单机的标绘系统不能进行全面的标绘。伴随着网络的发展,Web方式的广泛应用,标绘系统的应用也将由桌面应用方式向网络应用方式转变。

基于桌面环境开发的标绘系统,在网络环境下实现基于Web标绘具有局限性,其原因主要是由于在实现标号的算法解析后,直接将标号图形绘制到了显示设备上。而网络环境下的标绘系统,服务器和最终的显示设备是分离的。目前的标绘系统在设计的时候并没有实现真正的模块独立,耦合度较高,限制了应用范围。因此在设计基于Web的标绘系统时,采用面向服务的思想重构系统结构是一个比较合适的手段。就标绘图形处理系统而言,其关于标号的算法部分本身是一个独立的模块,与绘制设备是无关的,因此在实现基于网络的标绘系统时,采用面向服务架构SOA(Service-Oriented Architecture)的设计思想进行模块的分离,将标号算法实现等可以独立的模块从以前的系统结构中解耦出来,以服务的形式发布,浏览器在获得数据后进行绘制显示。利用面向服务的思想重构以前的结构后,不仅可以实现基于浏览器下的标绘系统,对于其他语言(比如Java、C++)编写的前端也能使用服务接口构建标绘系统。因此利用SOA设计标绘系统大大增强了原有系统的灵活性,也带来多种应用模式的扩展。

1软件服务化相关介绍

1.1SOA

面向服务架构(SOA)模型可以根据需求在网络环境中,分布式部署、组合、使用松散耦合的粗粒度应用组件。SOA并不是一个具体软件技术,而是一种业务和架构的组织思想,是一种在分布式环境中设计、开发、部署、应用软件的模型。SOA的兴起来源于网络技术的发展和分布式计算环境的需求,从SOA的实现技术发展来看,大致有这几种技术在SOA架构的发展中扮演了重要的角色:公共对象请求代理架构CORBA、分布式组件对象模型DCOM、Web Service。从一般的意义上来讲,SOA体系结构可以简单描述成如图 1所示。

1.2Web服务

Web服务基于XML和HTTPS。在Web服务的实现标准中,采用了基于SOAP简单对象访问协议的通信协议实现客户端和服务器之间通信。为了客户端能够访问服务器发布的Web服务,使用了Web服务描述语言WSDL对Web服务进行描述。为了客户端能够发现和获得服务器的元数据,使用了统一描述、发现和集成协议UDDI协议。在部署了具体的Web服务后,使用SOAP协议的任何客户端应用程序都可以发现,然后调用发布的Web服务。关于Web Service的核心技术简介如下所述。

1) XML和XSD Web服务采用XML作为其数据表示的基本格式。XML具有易于建立、易于分析、平台无关和厂商无关等优点。使用XML可以解决数据如何表示的问题,使用XSD(XML Schema Definition, XML语法定义)则解决了数据类型表示以及数据类型扩展的问题。其中XSD是W3C制定的数据类型以及数据类型扩展的标准。

2) SOAP 简单对象访问协议(SOAP)提供标准的RPC(Remote Procedure Call,远程过程调用)方法来调用Web服务。在SOAP协议中,定义了客户端向服务器请求服务的消息格式,并且规定了客户端如何通过HTTP协议发送SOAP封包。在SOAP协议的规范中,采用了XML进行数据编码,使用XSD对传输的数据类型进行了规定。SOAP协议具有可扩展、简单、和厂商无关、和平台无关等优点。客户端可以通过多种方式访问Web Service,比如Java、C/C++、JavaScript、PHP等。

3) WSDL 在基于XML语言的WSDL中描述了服务器发布的Web服务,其中主要包括了具体发布的Web服务函数接口、参数和函数返回值。WSDL是基于XML语言的,因此具有XML的优点,既能被机器识别,也可人工阅读。具有这些优点,因此WSDL可以通过工具自动生成,比如目前的J2EE开发平台中就提供了WSDL自动生成工具。

4) UDDI UDDI被称为统一描述、发现和集成协议,其主要实现了在Web服务注册中心定义SOAP接口的功能。对于任何希望通过Web服务部署的代码,使用UDDI协议可以将服务描述添加到Web服务注册中心。

为了实现标绘系统服务化的要求,需要将标绘系统中的标号绘制算法服务化,使得开发人员可以通过多种方式调用标绘系统的服务化的接口,获得标号的绘制方法,然后采用多种前端图形绘制技术,构建不同的标绘系统。

2标绘系统相关介绍

2.1桌面版标绘系统结构

标绘系统从本质上来说,也是一个图形处理系统,只是针对军事应用MGS(Military Graphic System),用于绘制态势情况。为了跨平台的移植需求,针对桌面应用的标绘系统也进行了分层设计,其结构示意图如图 2所示。系统结构中包含的数据部分有标号库(符号库)和战场态势数据。标号库(符号库)存储了标号的绘制方法,标绘系统的数据处理层通过读取符号库进行标号的解析绘制。在完成一幅战场态势后,标绘系统将态势数据通过一定格式存储到战场态势数据库中。

2.2标绘系统接口介绍

目前已有标绘系统基于军用图形处理系统MGS,具有标号绘制、编辑、态势图保存等功能,并且以动态库的形式提供了二次开发接口。MGS包含了如表1所示的接口。

2.3已有系统存在的局限性分析

从前面的体系机构,我们可以看出MGS系统的结构是面向桌面的,系统结构是至上而下的,数据处理层解析标号的绘制算法,然后直接调用绘制设备进行渲染。体系结构虽然进行了分层,将标号数据管理、标号算法等放在了标号数据处理层,将与底层绘制设备相关的放在了图形绘制层,这种结构适宜于在不同的桌面环境下进行移植,但是这种体系结构从根本上来说还是和绘制设备耦合的,对于实现基于网络的标绘系统是不适合的。实现基于浏览器的标绘系统时,进行渲染显示的浏览器和服务器是独立分开的,因此在实现基于网络的标绘系统时需要对已有的系统体系结构进行改造。

为了实现基于浏览器的标绘系统,大致可以有这几种实现手段:一是所有的标号在服务器端以图片的方式生成然后推送到浏览器进行显示;二是使用插件技术,比如使用Active插件可以实现在IE下调用MGS动态库然后在IE上绘制标号;三是采用SOA的体系结构,将标绘系统中核心的标号以数据服务的形式提供接口,从而浏览器端可以调用服务,获得标号数据进行解析绘制。这三种实现方式中,使用图片服务器的压力比较大,并且浏览器端的用户交互体验比较差;使用插件技术不仅依赖于不同的浏览器,并且和操作系统相关。

SOA的软件体系结构设计思想,要求软件模块能够降低耦合度、可以分布式部署。针对原有系统的体系结构,存在的问题就是即使实现分层设计,但是并没有将标绘系统中与绘制设备无关的标号算法模块完全独立出来。而使用SOA的软件设计思想,可以实现模块的独立,使标号的算法以数据服务的方式提供接口,不仅使用浏览器的客户端可以调用服务接口实现标绘系统,也使用其他语言编写的客户端也可以调用服务接口实现不同类型的标绘系统。

3服务化标绘系统结构设计

3.1系统设计思想

已有系统在经过了广泛的使用后,已经比较成熟稳定,因此在设计面向服务的标绘系统时候应该利用已有的系统,而不是抛开已有系统,重新搭建。基于上述思想,以及考虑系统的可扩展性,系统设计思想如图 3所示。

已有的MGS虽然将数据与绘制显示进行了分层,可以比较方便地实现跨平台移植,但是这种软件体系结构是不适用于网络应用的。因此在对MGS系统进行改造的时候,首先考虑将与系统绘制无关的MGS核心剥离出来,做成一个与系统无关的核心模块,然后通过不同的技术手段调用核心模块,实现基于多种技术的标绘系统。

在系统的设计思想中,关键是将MGS改造成为一个与系统绘制无关的模块,只和数据相关。当需要实现标号绘制时,MGS核心模块是输出标号的数据描述,而不再像以前的结构,是直接输出到绘制设备渲染显示。使用这种设计思想的好处可以有在移植到不同的操作系统中时,只需要重新编译MGS核心模块即可。下面对设计思想中的内容进行简单的说明:

1) MGS核心 基于已有的标绘系统,采用C++进行编写,主要包含了标号的绘制算法、态势数据管理等功能。这是实现SOA设计思想的关键模块,将只与数据相关的部分完全独立出来,设计成独立的模块,其他的组件模块都是在这个核心模块的基础上进行扩展的。

2) 基于.NET的MGS组件 通过.NET技术可以调用MGS核心模块,生成基于.NET的MGS组件,在这个组件的基础上可以实现基于.NET的桌面标绘系统,也可以发布Web服务构建基于.NET的Web标绘系统。

3) 嵌入式MGS组件 在嵌入式软件环境中,通过调用MGS核心模块,可以编写针对嵌入式环境的态势标绘软件。这个模块是为了实现态势标绘系统在嵌入式环境中使用而设计的,体现了SOA设计中模块能够实现独立部署的思想。该组件并不发布Web服务,仅供嵌入式设备使用。

4) 基于Java的MGS组件 通过在Java中调用MGS模块,可以组装成基于Java的MGS组件,使用该组件可以实现基于Java的桌面标绘软件和基于Web的标绘系统。

3.2客户端设计

为了实现服务化的标绘系统,客户端需要完成标绘面板、态势标绘、标绘图形管理等功能。其功能模块如图 4所示。

针对客户端设计的功能模块,简单对功能模块需要实现的功能进行介绍。

1) 标绘面板

标绘面板对于军用图形系统而言,是用户进行标绘的入口,标绘面板上列出了军用图形系统支持的标号的种类,以及对每个标号的样式进行了预览展示。服务器将图 2中的符号库以Web服务方式发布,提供了浏览器访问服务器符号库的接口。浏览器通过解析来自服务器的数据,可以以树形结构展现符号库的层次结构。

2) 态势标绘

态势标绘模块的具体功能是实现在接受到服务器端对标号的描述后,采用一定的绘制技术将标号绘制出来。服务器的Web服务接口提供了生成标号描述的接口,浏览器端通过调用服务器开放的接口,获得标号的数据描述,在接收到标号的数据描述后,浏览器采用渲染技术对标号进行显示。

3) 标绘图形管理

标绘图形管理模块实现的功能是在客户端完成对标号的编辑功能,实现标号图形的放大、缩小、平移等操作。对于桌面版本的标绘系统而言,实现标绘图形的管理可以简单的请求MGS核心模块,然后重新绘制标号即可,但是对于网络应用的态势标绘软件而言,如果在编辑标号的时候不断的请求服务器,那么无疑会加重服务器的负担,同时也会造成用户操作的延迟,带来不好的用户体验。因此对于基于Web的标绘系统而言,需要在客户端(浏览器)实现标绘图形管理的功能。在浏览器端进行编辑后,需要调用服务器提供的保存数据服务接口,将修改后的标号数据存放到服务器。

3.3服务器端设计

在本文设计的服务化标绘系统中,服务器提供了系统数据管理服务、标号绘制服务、用户数据管理服务等功能。服务器端的功能模块图如图 5所示。这三个服务模块分别对应了客户端的标绘面板、标号绘制、标绘图形管理。

服务器的模块设计主要分为两层进行设计,一层是用于发布Web服务的服务接口,被称为MGS服务器,另一层就是对应于各类服务接口的MGS核心模块。针对服务器设计的服务接口模块,下面对模块需要实现的功能进行简单介绍。

1) 系统数据管理服务

系统数据管理服务提供了供浏览器生成标号面板的功能。浏览器需要生成标号面板时,请求服务器发布的Web服务接口,可以从服务器获得当前系统支持的标号的种类,以及标号属性等信息。服务器存储的标号库可以动态增加、删除,浏览器端的标号面板为了能够与服务器同步,可以定时请求服务器实现。

服务器实现系统数据管理服务主要调用了MGS核心模块中的军标符号库管理模块。军标符号库管理模块提供了访问符号库数据的功能,能够实现查询标号库中的标号信息以及标号属性。数据管理服务接口通过调用MGS核心模块,然后发布Web服务接口,从而实现网络环境下能够访问标号库的功能。从其本质上来说,利用SOA的设计思想,将军标符号库管理模块独立出来,通过发布Web服务接口,实现了在网络上共享标号库资源的功能。

2) 标号绘制服务

标号绘制服务主要完成调用核心的标号算法库,发布Web服务接口的功能。浏览器端在接收到服务器的标号数据描述后,以指定的格式规范进行解析,然后采用不同的显示技术进行标号显示。标号绘制服务改变了桌面系统直接绘制标号的体系结构,转变成为提供标号描述的服务方式。

标号绘制服务模块和MGS核心模块中的标号算法模块相关。标号算法模块可以从符号库中读取关于标号信息的描述,然后根据传入的参数生成标号的矢量描述。标号算法模块的实现采用C++实现,在本文的原型系统中通过JNI调用动态库,然后发布Web服务。当浏览器端调用时,获得标号的矢量描述后,进行解析绘制,从而完成态势标绘的功能。

3) 用户数据管理服务

用户数据管理服务调用MGS核心模块的战场态势数据管理模块,然后发布Web服务接口,供浏览器端调用接口,将用户标绘数据存储成为态势文件,同时也提供了浏览、打开用户标绘的态势图。

用户在浏览器端标绘完态势图后,需要将数据进行保存,用户也需要在浏览器打开标绘的态势图,服务器端的用户数据管理服务提供了相关的功能支持。MGS核心模块中的战场态势数据管理模块主要实现的功能就是保存、打开态势数据的功能。态势数据可以采用文件的方式存储态势数据,也可以采用数据库的方式保存文件。

3.4Web服务发布

在设计思想图中,我们有两个模块是可以发布Web服务的,一个基于.NET的MGS组件,一种基于Java的MGS组件。下面分别对两种组件如何发布Web服务进行简单说明。

1) .NET组件发布Web服务

在Windows应用平台下,我们可以通过微软的.NET框架调用MGS核心模块生成.NET组件,在发布Web服务时也可以使用微软提供的VS开发环境创建ASP.NET Web服务,将组件功能以Web服务进行发布。

2) Java组件发布Web服务

对于Java实现Web服务而言,可以使用JNI(Java Native Interface)技术调用MGS核心模块,然后基于J2EE发布Web服务。本文中实现的原型系统就是使用JNI调用MGS核心模块,然后发布Web服务,实现基于浏览器的标绘系统。

在发布Web服务的时候,服务器实现调用MGS核心模块的接口,然后通过UDDI将服务发布到注册中心,关于服务的接口在WSDL中有详细描述,包括请求的接口、参数、返回值等。客户端请求Web服务时,首先在注册中心查找服务器提供的Web服务,然后在根据WSDL描述的接口类型,通过SOAP协议,将请求传递给服务器,服务器计算后将结果返回给客户端。其中WSDL描述是以XML格式表示,而传递请求以及结果的SOAP封包也是用XML的形式表示。

3.5SOA体系结构优势分析

SOA的软件体系结构设计思想带来的最大好处就是软件模块的耦合度最低、能够分布式部署。将图 5设计的系统结构,与图 2的桌面版本标绘系统结构对比,我们可以看出使用SOA的思想设计标绘系统体系结构具有以下的优点:

1) 采用SOA的思想重新设计体系结构后,MGS核心只与数据相关,完全与设备无关,系统结构更加灵活,具有更好的扩展性。比如将军标符号库管理模块独立发布Web服务接口可以实现符号库的网络共享功能,将与设备相关的标号算法模块与绘制部分解耦,可以实现在网络上发布标号描述的功能。

2) 采用SOA的体系结构,在充分利用已有的桌面标绘系统成果时,扩展了新的应用模式,可以构建基于浏览器的标绘系统,这在以前的系统结构是很难实现的。

3) 使用面向服务的思想设计标绘系统结构,不单是浏览器可以调用服务的接口,实现基于浏览器的标绘系统,对于使用其他语言编写的客户端也可以调用服务的接口。比如我们可以编写一个Java的桌面应用程序,通过JNI的方式调用MGS核心模块,可以构建一个基于Java的桌面标绘系统,当然我们也可以采用Java访问服务的接口也可以构建一个标绘系统。因此通过SOA的设计思想重新调整了标绘系统体系结构,新的体系结构可以适应更多的应用模式。

4系统实现与分析

4.1系统具体实现

实现原型系统时服务器端使用JNI技术,调用标绘系统核心模块构建基于Java的MGS组件,然后利用J2EE发布Web服务。浏览器端使用Flex技术完成标绘面板、态势标绘、标绘图形管理功能。下面就这三个功能模块的实现进行简单介绍。

1) 标绘面板

标绘面板的实现主要是通过调用服务器发布的系统数据管理服务接口。在服务器提供了两种符号库描述的接口,一种是采用XML描述的符号库,另外一种是使用JSON数据格式描述的符号库。当前端使用Flex技术时,由于Flex提供了对XML的支持,可以调用XML服务接口,获得符号库的描述进行显示。当浏览器端使用其他技术显示树结构时,可能使用JSON数据更加方便。因此在实现服务接口时提供了两种接口。

在实现原型系统时,浏览器端采用了Flex技术作为浏览器端的显示手段。在服务器端,关于标号库数据的结构描述使用XML文档进行存储,因此浏览器端通过请求发布的getXmlBhmb服务接口,获得标号库的描述,然后浏览器端利用Flex提供的XML显示接口绘制树形结构。关于服务器生成的标号库XML描述文件示意如下。

<node label=″通信标号″>

<node label=″指挥机构″libid=″64″grpid=″2″>

…

</node>

2) 态势标绘

服务器和浏览器之间关于标号图元的描述采用自定义的矢量数据格式,数据格式定义遵循以下的两个规则:(1) 标号的每一段图元用<>表示,多个图元组成一个标号;(2) 每个图元描述中包含了绘制的方法,以及图元的样式描述,比如线宽、线色、线型、填充等。目前在实现的系统中主要定义了以下几种图元:(1) 路径:<P >标签描述,由相连的线段组成;(2) 圆弧、圆、椭圆:<A >标签描述,在图元描述中指明是弧线还是椭圆;(3) 贝塞尔曲线:<B >标签描述,给出贝塞尔曲线的控制点序列;(4) 文本:<T >标签描述,给出了文本的内容、文本的显示位置等信息。

以绘制一个比较简单的标号说明系统是如何实现态势标绘,主要就是通过请求服务器获得标号描述后,然后浏览器实现标号功能。当浏览器端请求在(497,400)处绘制libid为32,code为1900,宽度为40,高度为40的标号时,通过调用服务开放的标号绘制服务getDotJbDescrip接口,接受到来自服务器的这样一组数据描述:<P d="497 367 538 367" style="255;1;0;255;1"><…><…>…。这些数据是服务器MGS核心模块计算出的标号矢量描述。浏览器解析数据后进行标号绘制可以绘制如图 6所示的标号。

3) 标绘图形管理

在浏览器端实现标绘图形管理模块时,需要实现对标号的编辑功能和对标绘数据的保存功能。在实现标号编辑的时候可以有两种实现方式,一种是重新请求服务器,生成标号的描述,另一种是在浏览器端基于态势标绘时已经获得的标号矢量描述进行编辑。当然编辑时请求服务器可以降低浏览器端的工作量,但是会带来服务器负载加重和交互体验差的问题。因此在实现标绘图形管理时采用在浏览器端基于矢量图元的编辑方式完成。实现矢量图元编辑时利用二维图形的几何变换可以实现标号放大、缩小、平移等功能。

原型系统实现时,前端的Flex提供关于图元二维变换的接口,通过调用flash.geom.Matrix类的方法实现图元的二维变换。Matrix类提供二维图形平移、缩放的基本变换。比如实现图形的平移时可以使用以下的代码。

//获得选中标号的变换矩阵

var m:Matrix=selectMark.transform.matrix;

//平移变换

m.translate(deltaX,deltaY);

//更新选中标号的变换矩阵

selectMark.transform.matrix=m;

当标绘编辑完数据后,需要将标绘数据保存成态势文件,调用服务器提供的用户数据管理服务接口saveSmlFIle实现态势文件的保存。

4.2SOA技术体现

为了说明SOA技术在服务化标绘系统中的作用,在介绍了功能模块的具体实现后,下面对SOA技术在实现中的体现进行简单总结:

1) 服务器端使用的MGS核心模块采用了SOA的设计思想,使模块更加独立,并且只是与数据相关;

2) 客户端在实现相关功能的时候都是通过请求服务端发布的Web服务接口实现的。比如在实现标绘面板的时候是通过调用服务器发布的系统数据管理服务接口,访问服务器存放的标号库资源。在实现态势标绘功能的时候,也是通过请求服务器发布的Web服务接口,获得标号的数据描述,然后在前端解析绘制。在实现标绘图形管理的时候,为了减少对服务器的请求,在前端实现了基于矢量图元的编辑功能,而在保存态势数据的时候,也是通过请求服务器的Web服务接口完成的。

4.3原型实现

为了验证本文提出的系统结构设计,搭建了原型系统进行了测试,图 7是原型系统的效果图。对于图形作业系统,用户尤其关心交互体验,本文对这一性能进行了测试。在100M的局域网环境中,结果表明在客户端向服务器请求标绘服务后,客户端接受到来自服务器的响应,然后进行图形绘制的时间大概在80ms左右,使用感觉流畅。当网络不好的时候,可以通过在客户端减少对服务器的请求,提升用户体验。

4.4实验分析

原型系统的实验结果表明了采用面向服务的设计思想设计标绘系统,能够满足标绘系统的需求。

SOA设计降低模块耦合度的思想,对于本文设计服务化的标绘系统有较好的指导意义。对比原有的桌面系统体系结构,采用SOA的体系结构带来了以下的优点:

1) SOA的设计思想改变了将标号输出到绘制设备的体系结构,将标号以数据服务的方式提供接口供客户端调用绘制显示。桌面系统的体系结构设计虽然能够比较方便实现跨平台,但是面向绘制设备的结构限制了体系机构仅限于桌面环境,而提供数据服务的体系结构,由于拥有了标号的数据描述,使用的方式可以更加灵活。

2) 采用SOA的体系结构能够构建更多的应用模式,可以适应不同的业务需求,低耦合度的MGS核心模块除了能够在网络环境中以Web服务的方式发布接口,还能单独部署在多种环境中使用,比如桌面环境和嵌入式环境。

3) 基于SOA的标绘体系结构设计最大限度地降低了系统的耦合度,能够满足分布式的需求。标号绘制服务模块,可以部署在一台服务器上,而标号的数据存储服务模块也可以部署在另外一台服务器上。

4) 基于SOA的标绘系统由于在服务器上存储了不同用户的标绘数据,提供了天然的协同标绘支持。所谓协同标绘,就是不同人员可以在同一幅态势图上共同进行协同作业,由于用户的数据是存储在同一个服务器上,因此方便实现数据的共享以及协同操作。

5结语

本文针对专用的标绘系统提出了一种改造的方案,通过发布核心模块的接口,可以实现在网络上的标绘系统,从而满足标绘系统服务化的需求。推而广之,对于一般的图形处理系统而言,也可以采用本文提出的实现方法,实现图形系统的服务化需求,比如可以实现基于Web的CAD系统,或者对于Visio等专业的作图软件,也可以实现基于Web的作图系统。

参考文献

[1]张永红.基于Web的态势标绘及应用技术研究[J].中国电子科学研究院学报,2009(1):45-49.

[2]尹小君.基于Web Service的WebGISVisA体系结构研究与实现[J].计算机应用与研究,2007(10):298-301.

[3]黄凯伟.SVG开发实践[M].北京:电子工业出版社,2008.

[4]杨强.三维静态军标的实时生成与标绘[J].计算机工程与设计,2007(14):3419-3422.

[5]徐远.基于面向服务体系结构的企业服务总线研究与实现[D].南京:南京航空航天大学,2007.

[6]巨亚荣.SVG技术在军事标图中的应用研究[J].重庆科技学院学报:自然科学版,2008(3):118-120.

[7]梁莹.基于Web方式的反恐维稳指挥系统的设计[J].计算机工程,2007,33(8):262-266.

[8]杨强.三维静态军标的实时生成与标绘[J].计算机工程与设计,2007,28(14):3419-3422.