信息服务架构（精选11篇）
信息服务架构 篇1
1 SOA的思想根源
传统信息运作方式虽然大大推进了企业生产力, 但又反作用于信息技术, 促使企业内外部商务信息的大规模集成。从面向过程到面向服务的4个关键阶段可以看出, 程序语言发展的过程实质为逐步降低耦合性的过程, 也是接口与接口实现逐渐分离的过程 (见表1) 。
在Web Service的基础上发展起来的面向服务架构 (Service-Oriented Architecture, SOA) 的思想将企业应用看作一些可跨越企业边界、自我描述、实现某一特殊功能的服务集合。通过标准化的机制, 能够将这些服务注册于公共数据库中, 并能被感兴趣的请求者发现;服务者和请求者之间能够进行动态绑定和直接交互, 实现一定的企业功能逻辑 (SOA模型如图1所示) 。而作为SOA的一种实现手段, Web服务以其完好的封装性、松散的耦合性、协议规范的标准性以及高度的可集成性等特点, 能够良好地满足SOA应用模式的需求。
2从BPM到SOA的跃迁
商务流程管理 (Business Process Management, BPM) 在SOA之前出现并已成功实施。早期企业通常会建立各业务部门相对独立且相互之间缺乏协同的流程系统。随着部门分工理论的没落, 各方面的困难使BPM产品一度丧失了竞争优势。而如今, 缺乏灵活性、
高昂的变革成本、以IT为中心的传统应用等因素又促使BPM市场急剧增长。同时, IDC提出流程企业应进化到2.0阶段, 使用SOA的思想方法和技术架构组装企业的BPM, 而BPM的重新崛起在很大程度上又推动着SOA的发展。
在商务流程自动化 (BPA) 、异构系统的无缝整合 (EAI) 、企业流程建模分析 (BPM的核心) 和监控企业活动以实现流程持续改进 (BAM) 等每个BPM的应用场合中, SOA都扮演着至关重要的角色。要从BPM迁移到SOA, 跨越信息技术与业务之间的鸿沟, 需引入一个服务层, 该层包含支持特定业务域的服务线、可跨多个业务域共享的可复用技术服务以及Web Services平台, 允许以各种独立于底层服务和技术平台的方式定义和利用服务。从技术层面看, SOA和BPM结合的方法主要有以下两种:
(1) BPEL+WSDL。先定义好一个BPEL流程, 然后将其纳入到SCA容器。在定义构件时, 可使用子元素的process属性指明这个可执行的BPEL流程的目标名称。
(2) BPEL应用SCA的某个构件。例如, 一个BPEL的变量声明可以包含一个SCA的扩展, 表明这个变量代表了一个SCA构件的属性。
3基于SOA的商务系统信息集成应用建模
某国内知名IT企业ABC公司内部先后实施了由不同厂家提供或自主开发的办公自动化、企业资源计划、决策支持、电子分销、供应链管理等相对独立的商务子系统。随着业务的不断进展, 以及与其他企业的海量信息流通, 需要部署一个基于SOA的商务系统门户集成方案。
考虑到业务需求, 通过集成中间件平台对各商务系统的流程与ERP核心子系统进行实时无缝的链接, 使企业内部整体的商务流程更加完整和流畅。此外, 通过集成中间件平台集成ABC公司与其供应商Z公司之间的异构ERP系统, 使整个供应链的商务流程更加完整和流畅。
集成后的SOA架构应用模式为:OA系统首先根据内部登录人员的配置信息确定用户身份并给予相应权限, 根据此权限范围内的工作流程和列表提供流程表单。用户需在表单上填写与流程控制、ERP系统相关的参数及其他字段信息。工作流引擎根据流程定义文档控制流程执行, 当流程流转到某个需要调用Web Ser-vice的活动时, 发送SOAP请求信息给服务提供者。Web Service利用数据访问逻辑组件操作数据库表。以采购申请为例 (图2为采购流程定义) , 用户调用ERP的采购管理Web Service的“采购信息保存”方法, 将采购的物料编号、采购数量、价格范围、供应商等信息存储到ERP的数据库。服务提供者实现服务之后, 将包括单据编号和状态等信息的SOAP返回信息传回OA系统。工作流引擎根据WSDL文档解析该SOAP返回信息, 将它自动存入流程表单并将表单传送给服务器, 然后根据工作流控制数据和组织/角色模型将流程表单传递给下一个执行者, 并同时发送E-mail通知。
4结 语
基于SOA架构的BPM可使企业机构快速部署和改变流程, 有助于满足跨越系统、地域和组织界限的端到端商务流程需求, 使企业具备敏捷的商务竞争优势。下一步面临的问题是:如何持续改进BPM流程, 识别出最有价值的商务流程模型去实施企业级SOA;在此基础上, 如何逐步积累经验, 更深入广泛地推广BPM应用。实践表明, 在影响项目成功实施的各种因素中, 除了在战术层面需要能正确实施BPM和SOA的混合分步部署的系统架构师以外, 管理理念与组织协调等人为方面的难题远大于技术难题。因此, 要成功部署SOA, 企业不能仅关注技术, 更应把持续改进流程作为先进的管理理念和必不可少的长期商务战略。
参考文献
[1]罗鸿, 王忠民.ERP原理、设计、实施[M].北京:电子工业出版社, 2003:45-60.
[2]刘艳, 吴健.基于SOA的OA与ERP的整合应用[J].计算机应用, 2008, 28 (3) :816-818.
信息服务架构 篇2
1.1 模式描述
不管你选择哪种实现,有几个常见的核心概念都需要进行了解。第一个概念是独立部署单元。如图4-1所示，微服务架构的每个组件都作为一个独立单元进行部署，让每个单元可以通过有效、简化的传输管道进行通信，同时它还有很强的扩展性，应用和组件之间高度解耦，使得部署更为简单。
也许要理解这种模式，最重要的概念就是服务组件。不要考虑微服务架构内部的服务，最好是考虑服务组件，从粒度上讲它可以小到单一的模块，或者大至一个应用程序。服务组件包含一个或多个模块（如Java类），这些模块可以提供一个单一功能，例如为特定的城市或城镇提供天气情况，或也可以作为一个大型商业应用的一个独立部分，例如火车票的余票查询系统。在微服务架构中，正确设计服务组件的粒度也是一个很大的挑战。在接下来的服务组件部分对这一挑战进行了详细的讨论。
微服务架构模式的另一个关键概念是它可能是一个分布式的架构，这意味着架构内部的所有组件之间是完全解耦的，并通过某种远程访问协议（例如， JMS, AMQP, REST, SOAP, RMI等）进行访问。这种架构的分布式特性是它实现一些优越的可扩展性和部署特性的关键所在。
微服务架构另一个令人兴奋的特性是它是由其他常见架构模式存在的问题演化来的，而不是作为一个解决方案被创造出来等待问题出现。微服务架构的演化有两个主要来源：使用分层架构模式的单体应用和使用面向服务架构的分布式应用。
提示 : 单体应用, 即一个应用就是一个整体。
从单体应用到微服务的发展过程主要是由持续交付开发促成的。单体应用通常是由紧耦合的组件组成，这些组件同时又是另一个单一可部署单元的一部分，这使得它繁琐，难以改变、测试和部署应用。这些因素通常会导致应用变得脆弱，以至于每次有一点新功能部署后，如果由于这些新功能引发了异常，那么整个应用就不能运行。微服务架构模式通过将应用分隔成多个可部署的单元（服务组件）的方法来解决这一问题，这些服务组件可以独立于其他服务组件进行单独开发、测试和部署。
另一个导致微服务架构模式产生的演化过程是由面向服务架构模式（SOA）应用程序存在的问题引起的。虽然SOA模式非常强大，提供了无与伦比的抽象级别、异构连接、服务调度，并保证通过IT能力调整业务目标，但它仍然是复杂的、昂贵的,它很难理解和实现，对大多数应用程序来说它过于重量级。微服务架构通过简化服务概念，消除调度需求、简化服务组件连接和访问来解决复杂度问题。
1.2 模式拓扑
虽然有很多方法来实现微服务架构模式,但三个主要的拓扑结构脱颖而出，最常见和流行的有:基于REST API的拓扑结构,基于REST的应用拓扑结构和集中式消息拓扑结构。
基于REST的API拓扑基于REST的API拓扑适用于网站，通过某些API对外提供小型的、自包含的服务。这种拓扑结构,如图4 - 2所示,由粒度非常细的服务组件（因此得名微服务）组成，这些服务组件包含一个或两个模块并独立于其他服务来执行特定业务功能。在这种拓结构扑中,这些细粒度的服务组件通常被REST-based的接口访问，而这个接口是通过一个单独部署的web API层实现的。这种拓扑的例子包含一些常见的专用的、基于云的RESTful web service，大型网站像Yahoo, Google, and Amazon都在使用。
图 4-2
基于REST的应用拓扑结构基于REST的应用拓扑结构与基于REST API有所不同，它通过传统的基于web的应用或者客户端应用来接收客户端请求，而不是通过一个简单的API层。如图4-3所示，应用的UI层是一个web应用，可以通过简单的基于REST的接口访问单独部署的服务组件。该拓扑结构中的服务组件与基于REST API拓扑结构中的不同，这些服务组件往往会更大、粒度更粗、代表整个业务应用程序的一小部分，而不是细粒度的、单一操作的服务。这种拓扑结构常见于中小型企业等复程度相对较低的应用程序。
图 4-3
集中式消息拓扑微服务架构模式中另一个常见的方法是集中式消息拓扑，如图4-4所示。该拓扑与前面提到的基于REST的应用拓扑类似，不同的是基于REST的应用拓扑结构使用REST进行远程访问，而该拓扑结构则使用一个轻量级的集中式消息中间件（如，ActiveMQ, HornetQ等等）。不要将该拓扑与面向服务的架构模式混淆或将其当做SOA简化版，这点是极其重要的。该拓扑中的轻量级消息中间件（Lightweight Message Broker）不执行任何调度,转换,或复杂的路由;相反,它只是一个轻量级访问远程服务组件的传输工具。
集中式消息拓扑结构通常应用在较大的业务应用程序中，或对于某些对传输层到用户接口层或者到服务组件层有较复杂的控制逻辑的应用程序中。该拓扑较之先前讨论的简单基于REST的拓扑结构，其好处是有先进的排队机制、异步消息传递、监控、错误处理和更好的负载均衡和可扩展性。与集中式代理相关的单点故障和架构瓶颈问题已通过代理集群和代理联盟（将一个代理实例为分多个代理实例，把基于系统功能区域的吞吐量负载划分开处理）解决。
图 4-4
1.3 避免依赖和调度
微服务架构模式的主要挑战之一就是决定服务组件的粒度级别。如果服务组件粒度过粗，那你可能不会意识到这个架构模式带来的好处（部署、可扩展性、可测试性和松耦合）。然而,服务组件粒度过细将导致额外的服务调度,这可能会导致将微服务架构模式变成一个复杂、容易混淆、代价昂贵并易于出错的、重量级的面向服务架构。
如果你发现需要从应用内部的用户接口或API层调度服务组件，那么很有可能你服务组件的粒度太细了。同样的，如果你发现你需要在服务组件之间执行服务间通信来处理单个请求,要么是你服务组件的粒度太细了，要么是没有从业务功能角度正确划分服务组件。
服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库进行处理。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。
共享数据库可以处理信息需求，但是共享功能呢？如果一个服务组件需要的功能包含在另一个服务组件内，或是一个公共的功能,那么有时你可以将服务组件的共享功能复制一份，因此违反了DRY规则。为了保持服务组件独立和部署分离，微服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余，这在大多数业务应用程序中是一个相当常见的问题。小工具类可能属于这一类重复的代码。
提示 : DRY，即don’t repeat yourself.
如果你发现就算不考虑服务组件粒度的级别，你仍不能避免服务组件调度,这是一个好迹象,可能此架构模式不适用于你的应用。由于这种模式的分布式特性，很难维护服务组件之间的单一工作事务单元。这种做法需要某种事务补偿框架回滚事务,这对此相对简单而优雅的架构模式来说，显著增加了复杂性。
1.4 注意事项
微服务架构模式解决了很多单体应用和面向服务架构应用存在的问题。由于主要应用组件被分成更小的、单独部署单元,使用微服务架构模式构建的应用程序通常更健壮,并提供更好的可扩展性,支持持续交付也更容易。
该模式的另一个优点是,它提供了实时生产部署能力，从而大大减少了传统的月度或周末“大爆炸”生产部署的需求。因为变化通常被隔离成特定的服务组件，只有变化的服务组件才需要部署。如果你的服务组件只有一个实例，你可以在用户界面程序编写专门的代码用于检测一个活跃的热部署,一旦检测到就将用户重定向到一个错误页面或等待页面。你也可以在实时部署期间，将服务组件的多个实例进行交换，允许应用程序在部署期间保持持续可用性（分层架构模式很难做到这点）。
最后一个要重视的考虑是，由于微服务架构模式可能是分布式的架构，他与事件驱动架构模式具有一些共同的复杂的问题，包括约定的创建、维护，和管理、远程系统的可用性、远程访问身份验证和授权等。
1.5 模式分析
下面这个表中包含了微服务架构模式的特点分析和评级，每个特性的评级是基于其自身特点，基于典型模式实现的能力特性,以及该模式是以什么闻名的。
特性评级分析整体灵活性高整体的灵活性是能够快速响应不断变化的环境。由于服务是独立部署单元,因此变化通常被隔离成单独的服务组件,使得部署变得快捷、简单，东软新安全服务架构提高服务门槛 篇3
东软集团副总裁兼安全业务线总经理贾彦生告诉记者,重新梳理过的信息安全架构包括三个层次:专业级服务、方案级服务和产品级服务。
其中,专业信息安全服务包括风险评估、等保服务、渗透测试、安全加固、应急响应、现场值守、认证培训和通告预警服务等,这是东软作为信息安全专家顾问为用户提供的信息安全服务。例如,在信息安全风险评估方面,东软是信息安全风险评估国家标准的制定者之一,长期以来一直在开展这方面的工作。通过信息安全风险评估,用户能够客观真实地了解自身信息系统的安全现状,合理规划安全建设,提高运维效率,避免投资浪费。在等级保护方面,东软是信息安全等级保护的倡导者,能够协助用户更好地了解和把握国家最新等级保护政策动态,评估现有安全措施与相关定级要求的合规程度,合理引导用户制定后续的落实及改善策略,在合规基础上实现高效。安全加固服务是指东软参照国际权威的信息系统安全配置指南,结合用户业务系统的实际安全需求,提供量身定制的安全加固及配置优化服务,搭建起一套良好的动态安全保障基线。
解决方案服务主要是针对行业大型用户应用系统整体安全需求进行方案咨询、安全集成、系统调优和服务外包等服务。这类服务更加注重操作层面。
信息安全产品服务主要体现在产品的定制与开发、测试与租赁、安装与维修、升级与更新、技术与培训、巡检与回访等几个方面。
贾彦生介绍,目前在信息安全领域,很多厂商只能提供产品服务,部分厂商能提供方案级服务,只有少数几家专业厂商能提供专业服务。但是在过去,由于没有捋清这三者之间的关系,造成用户的迷惑不解,也造成信息安全服务领域的不规范、安全服务水平的良莠不齐,由此影响信息安全服务产业的发展。东软今天如此清晰地描绘了信息安全服务产品,就是希望能树立安全服务的新标准,由此提升整个信息安全服务产业的水平。
将服务架构重新规划后,保证这一架构能有效运行的能力也非常重要。好在,东软在信息安全服务领域已经有14年的专业信息安全项目建设经验,在中国第一家通过ISO9000和CMM5及CMMI5全球最高级别质量认证、第一批通过国家级计算机信息系统集成一级资质和涉密信息系统集成甲级资质、首批入选国家级计算机网络应急服务支撑单位、在中国最早通过ISO27001信息安全管理体系国际认证及ISO20000 IT服务管理体系国际认证,拥有信息系统集成一级资质、专业稳定、经验丰富的技术团队,已经为各行业用户提供个性化的信息安全整体解决方案,可以针对用户的个性化需求进行定制开发。这一切为东软能顺利实施信息安全新服务架构提供了良好的保证。
信息服务架构 篇4
指控信息系统的软件体系结构的发展主要经历了集中式、C/S (客户/服务器模式) 、三层体系结构、多层体系结构、分布对象、基于构件的体系结构等多种技术体制, 现有的指控信息系统中大多已经采用C/S技术体制, 在C/S体制中客户端和服务器端接口都是依赖于实现的, 即通过预先定义的协议进行通讯, 从而造成其软件的脆弱性, 适应外部需求变化的能力较弱。随着信息装备不断发展, 信息收集、处理能力不断提升, 战场信息种类日益增加, 同时, 由于各军兵种信息系统发展的不平衡以及信息系统的多样性, 战场信息格式呈现出多标准、多协议的局面, 造成未来网络中心战的信息壁垒, 因此迫切需要一套完善的架构方法, 以适应军事业务需求的变化, 实现系统灵活重组、快速部署和集成。这种架构方法称之为面向服务的体系架构 (Service Oriented Architecture, SOA) 。本文的第二部分简单介绍面向服务体系架构的基本概念和主要特点;第三部分将结合工程实践, 介绍某系统中运用面向服务架构实现信息分发的功能。
二、面向服务的体系架构概述
SOA的核心是“服务”, 即“服务提供者完成一组工作, 为服务使用者交付所需的最终结果”[1]。SOA基于三种角色 (服务提供者、服务注册中心和服务请求者) 通过三种操作 (发布、查找和绑定操作) 完成它们之间的交互。一般情况下, 服务提供者需要对服务进行一定的描述, 并把服务描述发布到服务注册中心。服务请求者通过查找操作从服务注册中心检索服务描述, 然后使用服务描述与服务提供者进行绑定并调用服务实现或同它交互。图1描述了这些操作、提供操作的角色及它们之间的交互。
SOA通过一系列规范将应用服务的描述进行标准化, 基于这些规范进行描述的应用服务能够独立于软件开发语言、操作系统和网络平台进行相互调用, 这使得构建在这样系统中的服务可以以一种统一和通用的方式进行交互[2]。松耦合系统具有极大的灵活性, 使客户系统总能使用当前最好的服务, 一旦某个服务出现故障或失败时, 可动态甚至是在不中断系统运行的情况下替换为另一个服务;当组成整个应用程序的某些服务的内部结构和实体逐渐发生变化时, 它能够继续存在[3]。这样就完全可以在服务请求模块不知不觉的情况下, 有不同的数据源来满足这个服务请求。另一方面, 新的数据源也可以去响应其它服务请求者提出的类似请求。总之, 采用面向服务的体系结构可以克服C/S技术体制的脆弱性, 提高系统的可连接性和协作性, 使系统具有良好的伸缩性和灵活性。
三、在工程中的应用
3.1基于C/S模式的信息分发。某区域信息组网系统要求具备信息分发的功能, 即用户通过系统认证成为合法用户, 然后自主进行定制, 系统采用按需、透明方式向用户提供信息, 实现“用户按需定制、系统自动分发”的功能。以前, 工程中采用的是基于C/S模式的信息分发, 即用户登录某一特定系统进行定制, 该系统为用户提供所需的信息。随着“以平台为中心”向“以网络为中心”的不断转变, 各区域组网系统将组成大区域组网系统。大区域组网系统将能够提供信息分发功能的各分系统或主机作为一个信息服务节点, 如果仍然采用现有的C/S模式, 将存在以下问题:
(1) 用户信息无法统一管理。受体制影响, 为落实责任, 信息服务节点独立管理各自的保障用户, 没有建立信息保障服务体系概念, 同一用户信息在大区域范围内得不到统一管理, 需要重复注册。
(2) 不能实现大区域统一定制, 用户需多点进行定制。受信息处理节点责任区域的制约, 用户在信息节点获取保障信息时, 不能满足跨区域遂行任务的需求, 用户需登录到不同的信息服务节点进行多次定制。
(3) 信息保障组织不灵活、信息服务不连续。目前系统受保障关系的影响, 信息用户和服务节点间维持着既定的保障关系, 不可随意动态调整, 当信息服务节点发生故障时, 用户必须得重新登录到其它节点进行定制, 造成对应的保障用户无法连续获取信息。
(4) 资源分配不合理、服务资源利用率低。信息服务资源是零散的、孤立的, 没有被统一地管理和调度, 没有形成体系化的服务能力。有些服务资源负载过高, 而有的服务资源非常空闲。有些服务节点负载过高, 有些服务节点没有负载。
针对以上原因, 迫切需要运用面向服务体系架构的思想, 来对大区域系统的信息分发软件进行重新设计。
3.2分布式信息服务体系。以信息栅格为基础, 可以做到节点间的关系扁平、组合随意、编成灵活、指挥高效、连接冗余、容灾抗毁, 提供全维一体化的态势信息共享支持[4], 层次化的、分布式的信息分发体系应运而生。
3.2.1软件架构。整个分布式信息服务体系的软件架构, 是由多个服务组成, 这些服务部署于服务管理中介和服务节点。图2表示了分布式信息服务体系的软件组成图。
核心层和运行支撑层是底层的硬件基础, 服务集成框架为服务提供者和服务调用者提供开发、集成、运行环境。
服务管理中介是核心服务层, 包含以下服务: (1) 用户管理服务:主要提供用户管理、用户权限分配等功能; (2) 资源注册服务:主要提供资源的登记、查找、维护等功能; (3) 资源发现服务:为各类资源的用户 (包括系统最终用户和系统开发者) 提供查询相关资源的接口, 使用户能够快速、准确的搜索到想要的信息; (4) 资源监视服务:主要负责对已提交的任务进行管理, 任务监视服务需要监视执行每个任务的服务节点的状态, 当发现服务节点出现故障时, 需要将分配给该服务节点的请求重新分配给其它可用服务节点; (5) 用户定制代理服务 (或门户服务) :提供了供用户进行操作的浏览接口, 这个服务不是面向开发人员的, 而是面向系统使用者的; (6) 信息定制服务:主要提供信息定制功能, 接收用户定制请求, 根据请求所需的资源, 分配到一个或多个服务节点进行服务。
信息分发服务是最终提供信息的服务节点, 可向用户提供所有按要求定制的服务。信息分发服务不直接接收用户的定制请求, 而是接收信息分发调度服务向其分配的服务请求, 然后向用户系统输出信息。孤立的信息分发服务不能形成完整的分布式信息分发体系, 它必须在信息分发调度服务的统一组织和管理下, 才能加入整个分发体系中, 与其它成员共同协作, 提供更加可靠和连续的信息服务。信息分发调度服务将零散的信息分发服务单元组织在一起, 统一管理和调度, 形成信息分发池, 实现资源的合理分配、动态调整, 由此提升信息分发服务整体效能。
3.2.2特点。分布式信息服务体系与以前的信息分发软件相比较, 具有以下几个鲜明的特点:服务分布式:一个用户请求能同时驱动多个资源工作, 同时连接到多个服务节点上, 由多个服务节点同时对一个客户请求进行信息服务。服务透明化:用户发出请求后无需关心信息服务的提供者是谁, 调度服务会根据资源分配原则, 调度合适的服务节点为其进行服务。服务连续化:中介要对所有服务节点进行监控, 当发现某个服务节点失效时, 需立即将该服务节点所担负的任务重新分配到其它服务节点。服务克隆化:在网格环境下, 用户系统也可以为其它用户请求进行服务, 服务的提供者和请求者界限不明显。服务和被服务是相对的, 同时也是分层的。这种方式如细胞克隆一样, 使得整个信息服务的计算能力将无限提升, 在理想情况下, 系统增加信息用户, 不但没有占用系统的计算资源, 反而在提升系统的计算资源。
由此3.1节中提到的问题均可以得到很好解决: (1) 用户信息统一管理。在大区域范围内, 用户信息只需注册一次, 无需重复注册, 实现一点注册大区域访问。 (2) 信息信息统一定制。在大区域范围内, 用户只需进行一次定制, 便可获取大区域态势, 无需多点定制, 实现一点定制大区域服务。 (3) 信息服务扁平化。信息服务关系不再受限于行政保障关系, 在权限允许范围内, 任何服务节点可以为任何用户提供服务。对用户系统而言, 整个组网系统是一个整体, 不是分散的、孤立的。 (4) 服务资源合理分配。信息服务关系不再由人工指定, 而是由调度软件进行统一管理和分配, 充分利用各个信息服务资源, 实现负载均衡、故障接替、服务连续。
四、结论
本文简要介绍了面向服务的体系架构, 并且基于SOA重新设计了面向服务的分布式信息服务软件。该软件已在某大区域信息组网系统中使用两年多, 常态化的为近百个用户按需分发信息, 系统稳定, 信息连续, 受到了用户单位的一致好评。
摘要：栅格技术在军事领域的应用是大势所趋, 基于面向服务架构的系统可以与基于栅格的系统无缝接合。本文介绍SOA的基本概念、特点及软件架构;并且结合工程实践, 对基于SOA的分布式信息服务体系作一些探讨。
关键词：面向服务体系架构,服务,信息分发,服务节点
参考文献
[1]万芳, 等.基于S O A的服务构建组合技术研究[M].昆明:第二十七届中国控制年会, 2008, 7:16-18.
[2]郭自忠.全球信息栅格关键技术分析[J].电子期刊, 2010, 2.
[3]李君灵, 等.综合电子信息系统面向服务的软件体系结构[J].系统工程, 2008.
惠普刀片统领融合架构动能服务器 篇5
由于受到x86服务器的竞争,Unix服务器的发货量逐年降低,但是它的市场份额仍然占到了服务器市场近40%。那么,Unix服务器如何增强自身的竞争力呢?
伴随着英特尔安腾9300系列处理器的推出,惠普也推出了一系列全新架构的动能服务器。新推出的服务器包括惠普Integrity BL860ci2、BL870ci2、BL890ci2刀片服务器和Integrity Superdome 2服务器。中国惠普企业业务集团关键业务服务器产品部市场总监陈武胜说, 惠普是目前惟一能够提供从x86到Superdome2的统一标准的刀片系统平台供应商,能够减少数据中心部署时间,满足新的关键任务的业务需求。
据了解,惠普新推出的这几款服务器都采用了英特尔安腾9300系列处理器、惠普刀片系统架构,以及采用模块化和能源效率设计,是首批可升级的刀片服务器。其中,BL860ci2、BL870ci2和BL890ci2刀片服务器可以分别配置2、4、8个四核安腾9300处理器,每个刀片服务器可以配置8、16、32个安腾处理器内核,相比上一代同配置服务器性能提高了9倍,能耗降低一半。
陈武胜说,根据惠普的计划,经过10年的发展,Superdome的性能应该提高100倍,能耗降低一半。而新推出的Superdome 2采用刀片架构,在相同的机柜里,其性能已经比第一代产品提高了100倍,售价降低了40%,能耗降低了50%。以前的产品可以包含64路 PA6800处理器,现在最多可以包含128路安腾处理器。Superdome 2能够让客户根据需要独立扩展I/O端口和处理器,以满足不断变化的业务需求。
另外,Superdome 2保持了第一代产品的高可靠性和可用性,满足关键业务应用的需求,它在灵活性、可扩展性和可用性方面有100多项技术创新。其中包括容错的Crossbar Fabric,该技术允许在刀片和I/O端口间对数据进行全冗余的智能路由,使基础设施的可靠性提高4.5倍。同时,Superdome 2模块化的刀片设计拥有可互换组件,且其附件适用于标准化机架,通过共同的管理环境以及共用的电源、风扇和输入/输出等选项,数据中心管理人员可以使用相同的零部件,简化了操作与管理。
信息服务架构 篇6
SOA是工业界的一个热点主题。它是一个策略、实践和框架的集合, 能够为提供跨域注册、动态发现和自动机制提供内建的基础设施。并且提供的服务封装, 通过消息协议提供可由双方共同操作的服务。SOA也为服务质量控制和资源管理及其它的监控服务和异常处理机制准备了基础设施。作为一个agility-pursued体系结构, SOA将企业逻辑从技术实现分离, 从而使围绕SOA体系结构建立的应用能够满足企业和技术领域持续变化的需求。它也将有益于可复用性和系统集成, 以及可扩展性、分布性和跨域注册。
1 问题发现
我们在SOA安全体系结构上的研究发现了以下几个问题。
(1) 缺少企业信息安全集成体系结构, 引入了不同的、相互独立的信息安全系统和解决方案, 这会导致整个系统的不兼容性, 导致无法达到期望的风险管理控制。
(2) 由于在信息风险管理系统的信息采集还处于半自动化阶段, 人工的信息采集过程会导致人为造成的错误。
(3) ISO/IEC 27002系统为企业信息安全管理提供非常好的方法和指南, 但由于缺乏合适的工具进行管理, 无法很好解决企业信息安全。
(4) 我们需要注意SOA自身的可靠性和安全性问题。
2 信息安全体系结构的设计
根据上述问题, 提出本文的基于SOA的信息安全体系的设计。
通过研究, 我们提出了一个面向服务架构的企业信息安全体系结构, 它是底层基于数据仓库/数据集市技术, 并以安全服务总线作为hub, 为企业信息安全活动提供集成信息安全的管理和有效的控制, 使用BPM (企业过程管理) 、规则引擎 (Rule Engine, RE) 和, 企业智能 (Business Intelligence, BI) 技术。它有益于企业公司达到需要的信息安全管理级别。并且建立一个PDCA (Plan-Do-Check-Act) 适配器, 以确保信息安全管理和风险控制活动, 能够进行自我优化。
2.1 体系结构的结构
参考七层OSI设计, 我们设计了五层的智能企业信息安全体系结构。自下向上为安全数据库层、安全应用层、安全服务总线、集成和智能层、信息安全框架。
(图1) 说明了智能企业信息安全体系结构的结构。
(1) 安全数据层。体系结构的底层是整个体系结构的基础层。这是因为安全数据易于被其它应用和服务使用。这一层的数据被分为两个部分:操作数据和分析数据。
(2) 安全应用层。应用层包括所有的信息安全系统, 如防火墙、入侵防御系统、反病毒系统, 以及被防护的设备, 如网络设备、服务器和桌面环境等。它也包括这些系统上的各种各样的操作系统。
(3) 安全服务总线。是基于SOA的信息安全体系结构的中枢。我们在这一层定义SOA服务总线的结构和需要的各种各样的信息安全服务。在面向服务的信息安全体系结构中, 我们能够将当前和未来的安全需求定义为安全服务, 但这些服务的实现是隐藏的。
(4) 集成&智能层。体系结构中数据、过程和应用都是在这一层进行处理实现的解决一个企业各种业务问题, 满足快速变化的环境。集成层具有“应用之间”和“过程之间”进行通信的能力, 通过适配器, 它还能够与其他企业过程、服务提供者或数据提供者通信。
(5) 信息安全辅助设计。这是信息安全对外的接口, 主要是由匀衡器、关键风险指示仪以及监控接口。
企业智能模型提供各种各样的服务例如报告、查询、OLAP、数据挖掘和多维分析。规则引擎, 作为工作流的一部分, 可以结合到BPM模型。因为有了规则引擎, 我们能够更加有效地执行信息安全管理和风险控制。PDCA适配器是一个特殊的工具, 它利用人工智能能够帮助公司达到信息安全管理中持续提高和自我优化的目标。
2.2 特点和优势
本文提出的企业信息安全体系结构具有以下特点。
(1) 集成。它也能够将信息安全管理和风险控制联合起来作为一个集成的框架。
(2) 可复用。体系结构是比较独立的, 适合于企业和小型组织。服务的封装使得可复用, 与其他服务联合使用。
(3) 面向服务的体系结构。SOA体系机构的采用提供了服务的独立性、自我管理和自我弹性。
(4) 集成的数据环境。集成的数据结构使之适合于各种数据库进行对接。
(5) 企业智能。这个体系结构将企业智能应用到信息安全管理, 信息安全管理主要使用了数据挖掘和模式识别技术。这可以大大减少由于人工误操作引起的损失, 增强信息安全管理和风险控制操作。
(6) 开放的体系结构。体系结构开放设计, 以满足整个企业的安全需求;面向服务的特征使得体系结构式开放的, 允许多个接口与外部应用通信。
3 结论
与传统的信息安全体系结构设计相比, 本文提出的体系结构设计具有几个优势, 包括开放、集成、可复用、面向服务、集成数据平台和商业智能。信息安全管理人员可以自由地执行重要的任务, 如风险分析等。最后, 这个体系结构式我们建立集成和智能企业信息安全体系结构的开端, 以后会有更多的、更好的产品出现。
参考文献
[1]魏东, 陈晓江, 房鼎益, 等.基于SO A体系结构的软件开发方法研究[J].微电子学与计算机, 2005, 22 (6) :73-76.
[2]叶宇风.基于SOA的企业应用集成研究[J].微电子学与计算机, 2006, 23 (5) :211-213.
[3]雷冬艳.SOA环境下的数字图书馆信息安全研究[J].科教文汇, 2010 (33) :189-190.
[4]李益文.基于SOA的商业系统的信息安全技术探讨[J].电脑编程技巧与维护, 20 10 (20) :114-115, 154.
[5]霍林.基于SOA架构的信息管理系统的设计实现[D].华中科技大学, 2006.
信息服务架构 篇7
医院是人们生活密切相关的场所,为广大患者提供轻松、有序、高效的就诊环境,不仅是创建数字化、信息化、智能化的三甲大医院的需求,更是社会进步的需求,人们个性化的需求。良好的就诊环境及个性化的需求更大程度上依赖医院信息化的发展。其中医院的信息发布系统是将信息从电脑终端传输到医院多媒体屏幕,主要包括如下几个方面内容[1]:发布医生出诊信息、挂号信息、物价信息、宣教导医信息;门诊等候排队叫号;医技检查排队叫号;药房取药排队叫号;医技检查报告结果发布等。即在整个流程中,给病人最充分的知情信息与有序的环境来提高患者满意度,提高医院的工作效率与提升医院整体的服务水平。
为提高信息发布的质量与效率,我院采用嵌入式IPTV机顶盒技术与面向服务架构,与医院信息系统(HIS)集成[2],构建了院内信息发布平台,介绍如下。
1 信息发布系统技术架构设计与实现
医院信息发布需求可分两大类:一是定制的个性化信息发布:如医院介绍、医院通知、宣教视频、天气预报等;二是与HIS集成的信息发布,此类信息可划分为主动型和被动型。主动型信息为医生出诊挂号信息、分诊排队信息、检查报告结果信息、物价信息、费用清单信息等;被动型为患者就诊信息的定控点播,如患者自助挂号、点餐服务等。
定制的个性化信息发布大多是多媒体信息素材,如图片、文字、视频、音频等;与HIS集成的信息发布是根据有无声音分为两类:一类是获取HIS的静态数据显示;另一类是需将文本信息合成为语音信息传输出的音频信号。
由于我院诊间、医技检查的排队叫号分布点多,本文构建的医院信息发布系统解决方案是建立在医院内网及HIS平台上,采用嵌入式的IPTV机顶盒技术和B/S与C/S模式相结合的面向服务架构开发[3]。
1.1 面向服务架构
面向服务架构(SOA)[4,5]可在不同子系统之间定义良好的接口,使得系统之间能以统一的方式进行交互,是独立于各子系统的硬件平台、操作系统和编程语言,使得服务的外部访问接口与内部技术相分离,从而提高各系统数据的安全性。
我院构建的信息发布平台,分布点数据主要来源于HIS与其他系统集成后的交互数据,主要采用基于Webservice技术[6]实现SOA。各子系统接口定义采用可扩展标记语言(XML)定义数据描述语言,采用SOAP消息通信协议。
1.2 诊间、医技检查排队叫号的实现
诊间排队叫号主要是面向病人在等候诊区排号信息的发布,医技检查的排队叫号主要是对病人做检查时排号信息的发布。系统包括医生工作站、护士分诊工作站及诊区/诊室显示设备。显示设备通过机顶盒进行控制,用VGA接口或HDMI接口连接,机顶盒接入内网,获取信息发布服务器模板显示的信息与来自医院医生诊室/ 医技检查室对HIS发起的叫号信息。医生诊室/ 医技检查室队列来自HIS分诊登记子系统形成的排队队列。
1.3 检查/化验结果发布的显示
检查结果发布信息主要是针对B超、放射、内镜检查结果发布信息,让病人及时知道相关信息,避免等待的着急心情和经常询问的麻烦和不满意。信息发布系统与医技检查子系统接口集成后,对返回检查结果信息表定制了定时自动轮询任务,检查结果状态为已出的,并将检索到的记录写入中间表,同时将数据刷新显示在显示屏上。如果病人已领检查结果报告,则更新检查结果状态。对于化验信息,因为信息量过大,采用的模式为将结果是否已出,自动推送给相应患者手机上(在患者同意的前提下),告知化验结果已出,可在自助机设备上自助查询打印。
1.4 药房排队叫号信息显示
药房排队叫号是对已缴费需拿药的患者服务的。在患者缴费后,药品信息自动传到药房,在药房预摆好药后,药剂师扫描条码进行摆药确认,相应的发药窗口屏幕显示候药患者信息。如果患者已领药,则更新患者取药状态,屏幕显示信息自动进行更新。
1.5 楼层宣教信息显示
楼层宣教信息显示主要是通过网络将编辑好的信息在高清的显示设备上进行播放显示。可播放音视频信号、图片和滚动的字幕信息,设置在人流密集的地方进行播放。
1.6 服务器部分
服务器部分主要包括:HIS数据库、HIS应用服务器、多媒体发布服务器。HIS数据库是存储排队叫号业务数据;HIS应用服务器是提供应用服务;多媒体发布服务器是信息发布系统的文件服务器和数据服务器,管理所有的多媒体终端,所有的多媒体终端可通过唯一IP进行统一监控[7],并存储客户端发起的音视频文件。
1.7 机顶盒
IPTV机顶盒[8,9]负责将客户端的请求发送给服务器,并对网络传输过来的多媒体数据进行接收、分析、解码,转换成模拟或数字式音频信号后送给显示设备进行播放。机顶盒通过RJ45 网络接口接入医院内网,IPTV机顶盒包括两部分:硬件设计和软件设计。硬件设计主要是网络设计、音频与视频的解码和输出;软件设计为机顶盒的关键技术,采用嵌入式操作系统的方式,其结构设计为三层结构,见图1。
(1)内核层:主要包含嵌入式操作系统的内核和各硬件驱动程序。
(2)中间件层:其作用是将应用程序和内核层分开,降低硬件依赖,将应用程序翻译成可执行的指令,利用硬件完成操作。
(3)应用层:由用户操作,实现媒体播放、信息浏览和配置。
2 信息发布设计解决方案的应用
基于HIS的门诊就诊流程嵌入信息发布系统后,每个就诊地点、检查室均有楼层宣教信息指引(图2)。挂号前有当天医生出诊情况信息和号源情况信息;诊室就诊、医技科室检查有排队电脑叫号、高清多媒体屏幕显示就诊信息。需取药的患者缴费后发票上提示取药窗口,药房LED显示屏在相应的窗口自动显示已摆好药患者的名字;需做检查的患者,在做完检查后,只需等待看结果发布显示屏是否有自己的名字,显示后再去领取检查报告。检验结果由手机短信信息提醒,患者获知检验结果出来后,到自助打印处打印化验报告结果。我院信息发布平台实现了医生出诊号源发布,诊间排队叫号,药房取药显示,抽血、B超、放射、心电、内镜的排队叫号与结果发布。
3 结果与分析
医院信息发布系统引入后给医院和患者都带来了一定的便利,让患者感受整个就诊流程公开、公平,在一定程度上避免时间的浪费,全程就诊实现了智能电子化、信息化[8]。同时也增加了医院的维护成本,特别是对显示设备与机顶盒的维护。并且在门诊诊区,一旦显示设备、机顶盒或网络出现故障,电子叫号方式被中断,就诊秩序就会被打乱。对C/S模式下的显示设备可以通过后台的监控中心进行监控。但在中断期间,叫号模式不得不恢复为人工方式。如何在设备故障时,缩短叫号模式恢复时间,是后阶段需要不断探索的过程。
摘要：利用嵌入式的IPTV机顶盒技术与医院信息系统(HIS)集成,采用C/S与B/S相结合模式和面向服务架构(SOA),设计了我院内部实时高清多媒体信息发布系统。本文详细介绍了系统实现所采用的技术和实施过程。
关键词：医院信息系统,信息发布系统,IPTV机顶盒,SOA
参考文献
[1]周海波,宁斌.医院智能导诊与信息发布管理一体化平台的需求分析与设计[J].中国数字医学,2009,4(12):62-63.
[2]沈崇德.医院数字化客户服务模式构建与规范化研究[D].南京:南京中医药大学,2014.
[3]孙鸿飞.面向服务架构的网络学习系统的研究与设计[D].北京:北京邮电大学,2008.
[4]李黎.基于Linux平台的IPTV机顶盒研究与开发[D].西安:西安电子科技大学,2010.
[5]殷俊华,黄刊迪.面向服务的医院信息集成方法研究[J].中国数字医学,2012,7(6):79-81.
[6]丁宇.Webservice高效安全数据传输技术研究及其企业级实现[D].北京:北京工业大学,2013.
[7]王波涛.基于嵌入式Linux的IPTV机顶盒软件系统的设计与实现[D].武汉:武汉理工大学,2014.
信息服务架构 篇8
变电站涌现出了大量的新理念、新技术以及新的应用, 诸如变电站自动化技术[1,2]、通信技术[3,4]、设备信息管理技术[5,6]、设备状态监测与状态检修技术[7,8]等等。智能变电站的功能之一就是为电网提供数据信息支撑, 如何提出一种面向变电站的全景信息整合方法, 做到物联网信息与其他电网信息系统以及公共安全信息系统间的有效集成, 对于实现在物联网大环境下的输变电设备智能监测与全寿命周期管理系统具有重要的基础性作用。变电站驾驶舱全景信息整合平台能为智能变电站提供数据源的支持。
1 变电站驾驶舱系统
变电站驾驶舱系统是电力公司统一生产指挥技术支持系统家族的重要一员, 利用类似于驾驶舱的中采集、智能分析、智能控制、智能展示等技术实现变电站内运行监控、设备运维管理、环境管理和仿真培训功能[9]。
2 驾驶舱全景信息整合平台技术架构
SOA (Service-Oriented Architecture, 面向服务的体系结构) 是由Gartner在1996年提出来的。IBM认为:在应用前景方面SOA比Web Services更加的广泛, SOA是一种构建能够交付终端-用户服务或构建其他服务的功能组件[10]。SOA是一个开放式的、敏捷式的、可扩展式的、可联邦式的、可组合式的技术架构。
全景信息整合平台采用规范化基础数据及信息的变电站数据源, 以统一标准的方式实现站内信息交互和共享, 为电力系统的保护和控制、运行及维护管理提供基础数据支撑, 提供能够反映变电站电力系统运行的稳态、暂态、动态数据以及变电站设备运行状态、图像等数据集合的平台。全景信息整合平台将全站信息和子系统融合, 是变电站系统的技术基础, 全景信息数据平台的主要任务即提供站内功能所需数据、信息服务, 建立变电站全景信息。
基于SOA全新的强大功能, 全景信息整合平台与SOA的结合成为了必然, 从而进一步突显了电力企业的竞争优势, 主要体现在以下几点:可利用现有的资产;更快的响应速度;更易于集成和管理;与技术的松散耦合;降低企业的风险。
基于SOA架构的变电站驾驶舱全景信息整合平台的技术架构按照数据的流向可分为3个主要的层次:基础设施层、数据接入整合层和应用服务层。
3 全景信息整合平台数据接口设计
数据接口设计的目的, 是将目前存储于不同应用系统的、不同格式的、与变电运行在线监测相关的数据, 抽取出来, 经过必要的处理, 转化为满足物联网全景信息模型要求的数据, 存储到数据库中, 为平台的数据服务构建提供数据基础。全景信息整合平台数据接口设计模型如图1所示。
全景信息模型的接口设计主要完成将现有的分散在各个系统中的异构数据按照全景信息模型接口, 将其转化为符合物联网全景信息模型的形式存入到数据库中, 或者直接提供给平台的基础数据服务使用。平台内数据流可以分为4个大的部分, 按数据流向依次为源数据系统、适配器、数据库、上层应用, 数据通过各个组件模块时, 被这些组件模块的各个功能模块处理, 最终发布为服务供上层应用调用。
3.1 数据获取
数据获取工作主要是根据各自不同的数据来源制定相应的数据获取策略, 通过总结现有电网中的数据获取方式, 可以将数据源类型划分为数据库、文件、规约数据流3种方式, 不同的方式其获取方法是不同的, 应该区别对待。3种不同的数据获取模式如图2所示。
3.2 数据解析
数据解析的功能是对获取到的源数据进行语法解析, 转换为内存中的变量或者对象数据。根据源数据格式的不同, 可以将其分为3种:CIM/RDF格式、普通的XML格式、特定格式的文本文件等。3种不同的数据解析模式如图3所示。
3.3 格式转换
格式转换是将解析源数据在内存中构建的对象数据转换为标准的CIM模型的过程。格式的转换和数据的解析一般构建在一个程序模块中, 直接将内存中的对象按照CIM模型进行定义, 在解析模型时, 直接采用解析后的数据即可。对于Java语言构建的格式转换来说, 一般采用Java Bean来实现, 数据格式转换模式如图4所示。
3.4 对象-关系映射
对象-关系映射 (ORM) 系统一般以中间件的形式存在, 主要实现程序对象到关系数据库数据的映射。ORM的使用会减少数据访问层的代码。目前常用的第三方ORM框架有Hibernate和i Batis等。
4 SOA基础环境的构建
面向服务 (SOA) 架构是全景信息整合平台实现技术, 主要任务包含搭建企业服务总线基础设施, 对变电运行设备全景信息整合平台各个服务进行抽象并建立相应的业务流程管理措施, 实现业务系统之间的流程贯通;建立各种高级数据服务, 明确异构数据库转换方法和透明访问机制, 构建具有“即插即用”标准应用程序接口;采用穿越隔离装置的文件与数据传输方法, 实现不同层级、不同分区内的文件与数据传输。变电站构建一个典型的SOA应用从人员、流程、信息、服务重用性和服务连通性等几个方面入手。确定好切入点, 构建服务即成为SOA环境的首要工作。
由于全景信息整合平台的应用服务层内各个服务完成的具体任务不同, 可以进行进一步层级细分, 主要可以分为以下几类服务:平台总线核心服务类、系统服务类、业务流程管理服务类、基础数据服务类、高级数据服务类以及展现服务类。这些服务类以全景信息整合平台接入的各种信息资源为基础, 以平台总线为依托, 实现全景信息整合平台不同层级和粒度的业务功能。
5 结束语
本文构建了一种基于SOA架构的变电站驾驶舱全景信息整合平台, 解决了目前变电站中存在的“信息孤岛”问题, 为变电站的智能化运行提供了一种新的方案。作为一个新兴的软件体系架构, SOA越来越受到人们的重视, 但是其技术也处于不断的发展和更新当中, 因此存在一些没有涉及和未解决的问题, 还需要今后进一步的研究。
参考文献
[1]张金江.基于多智能体技术的变电站设备信息集成研究[D].杭州:浙江大学, 2009.
[2]崔江峰.变电站自动化监控和实时数据库系统研究[D].武汉:华中科技大学, 2004.
[3]沈国荣, 黄健.2000年国际大电网会议系列报道——通信技术是变电站自动化的关键[J].电力系统自动化, 2001, 25 (10) :1-5.
[4]孙军平, 盛万兴, 王孙安, 等.新一代变电站自动化网络通信系统研究[J].中国电机工程学报, 2003, 23 (3) :16-19, 145.
[5]张富刚, 李建, 乔辉丽, 等.三维实景技术在变电站可视化信息管理中的应用[J].煤炭技术, 2011, 30 (3) :257-259.
[6]曹楠, 李刚, 王冬青, 等.智能变电站关键技术及其构建方式的探讨[J].电力系统保护与控制, 2011, 39 (5) :63-68.
[7]王红星, 黄曙, 马凯, 等.智能变电站间隔层设备在线式自我状态监测系统设计[J].广东电力, 2013, 26 (10) :69-74, 91.
[8]陈海波, 周建国, 李红雷, 等.基于设备状态信息化的数字化变电站初探[J].华东电力, 2008, 36 (11) :5-7.
[9]李云霞, 赵行, 鲁帆, 等.变电站驾驶舱技术的研究与应用[J].电气应用, 2014, 05:91-95.
信息服务架构 篇9
关键词：移动GIS,WebGIS,SOA,敏捷开发
移动GIS作为移动空间信息服务的基础设施, 其应用领域非常广泛。然而, 当前移动GIS还面临一些技术难题, 包括空间数据量大、计算能力不足、网络带宽窄、可靠性差、软硬件兼容性差等, 导致移动GIS项目实施面临技术门槛高、开发周期长、实施成本高、项目风险大等问题。该文以移动GIS项目共性需求为导向, 采用面向服务思想设计并实现了基于“云+端”模式的移动GIS快速开发平台。平台具有跨平台、高性能、可配置、易扩展、支持多语言二次开发等特点, 能帮助开发者快速构建业务敏捷的移动GIS应用系统, 具有重要的现实意义。
1 平台总体架构
经过多年发展, GIS己从单机工具型软件系统逐步走向了分布式、网络化的应用软件平台, 从独立GIS系统逐步过渡到具有高度资源整合能力和对外服务能力的服务式GIS。服务式GIS是一种面向服务软件工程方法的GIS技术体系, 它支持按照一定规范把GIS的全部功能以服务的方式发布出来, 可以跨平台、跨网络、跨语言地被多种客户端调用, 同时能聚合来自其他服务器发布的GIS服务。服务式GIS可以更全面地支持SOA, 通过对多种SOA实践标准与空间信息服务标准的支持, 可以使用于各种SOA架构体系中, 与其它IT业务系统进行无缝的异构集成, 从而可以更容易地让应用开发者构建业务敏捷应用系统。该文以面向服务的思想, 分析设计了基于SOA架构的移动GIS开发平台, 提出“云+端”的移动GIS开发模式, 由应用层、服务层、支撑层、核心层组成, 其总体架构如图1所示。
其中, 应用层是以移动GIS为工具的数据采集、设备巡检、移动执法等各类应用系统, 包括移动作业系统、在线监控、基于Web GIS的业务应用系统、指挥决策系统等, 这些运行环境不同、架构各异的应用系统, 通过调用、聚合平台发布的服务, 实现数据共享和互操作;服务层由一系列遵循一定规范的应用接口组成, 是平台暴露给应用层进行集成、扩展的应用程序接口;支撑层是平台的核心, 采用B/S和C/S相结合的混合架构, 对应用层各类系统起着数据管理、配置等支撑作用。
2 平台主要功能模块
2.1 GIS核心库
核心层由Hi Map SDK和Hi Web GIS引擎组成, 前者主要面向桌面端、服务器端和嵌入式设备的轻量级GIS应用程序的开发与部署, 而后者是面向Web GIS应用系统的二次开发组件。Hi Map SDK采用标准C++开发从底层构建实现, 支持跨平台 (Windows Mobile、Android、i OS、Win32等) 、多语言 (C#、JAVA、Object C) 、多并发、高性能的GIS应用程序二次开发。Hi Map SDK引入了硬件抽象层的概念, 提出分层开发模型OS-GAL-IAL。
在OS-GAL-IAL模型中, 与图形界面无关的算法、模型, 采用标准C++在内核中统一实现, 而对一些与操作系统有关的底层接口 (如Cash内存、文件、Debug、Frame Buffer、Thread、Timer等) 、人机界面、图形绘制等功能, 在内核中进行统一定义与封装, 在具体的语言开发包中实现。这种分层设计既能充分发挥C++计算性能的优越, 又能最大程度利用操作系统提供的接口, 保证了最佳计算性能和显示效果, 并有效地屏蔽了因嵌入式硬件环境和操作系统的改变而导致的平台移植性的问题。
2.2 数据管理系统
基础地图数据、业务对象数据的预处理是移动GIS应用项目中至关重要的一环, 由于这些数据通常是多源异构的, 在存储方式、数据格式、空间参考等方面存在差异, 需要对这些数据进行格式转换、坐标变换、拓扑检查、符号设置、缓存制作、压缩转存等数据预处理工作。数据管理系统综合考虑桌面系统和嵌入式应用系统在数据精度、显示分辨率、寻址计算等方面的差异, 进行全局的优化设计, 提供了丰富实用的功能插件。如:地图缓存制作插件可同时制作多种分辨率的地图瓦片, 并提供松散、紧凑两种存储格式, 确保数据能在桌面端、Web端和移动端均能逼真、流畅地展示。
2.3 通信传输系统
通信传输系统是承接移动GIS和服务器的关键部分, 其传输效率和系统的安全性、健壮性通常决定着一个移动GIS项目能否成功实施。用户在户外开始作业前, 移动GIS通过套接字 (Socket) 连接到通信服务系统进行合法性验证, 作业完成后, 现场采集的数据和轨迹数据通过通信服务系统实时地保存到服务器。当监控中心需要对户外用户进行指挥调度、多方协助时, 可通过通信服务系统将指令推送给现场终端用户。为了达到最佳系统性能, 该文采用完成端口 (I/O Completion Ports, IOCP) 管理套接字, IOCP充分利用内核对象的调度, 只使用少量的几个线程来处理和客户端的所有通信, 消除了无谓的线程上下文切换, 从而最大限度的提高了网络通信的性能。
2.4 运行维护系统
运行维护系统为应用层各类应用系统提供底层支撑, 包括GIS数据配置、权限配置两大部分。其中, Web GIS数据配置实现对GIS数据的组织、显示、查询、事件、字段等信息的设置, 这些配置项在Web GIS服务契约一一对应, 前端对服务调用结果依次按契约进行取值, 并在前端UI组件中展示。如:可配置当用户在Web GIS上点击某个要素时, 是否弹出一个对话框, 以及配置如何在对话框展示要素信息;配置前端参数取值字段, 可在Web端方便地检索出各要素的字段值, 从而可轻松地实现各种扩展应用。权限配置采用RABC模型, 即通过用户、角色、权限三者之间建立的一对多、多对多的关系来实现权限控制, 包括功能权限和数据权限的配置。其中, 对数据权限 (CRUD、统计、导出等) 实现了精细化控制, 包括对字段、记录的过滤控制等, 能满足实际项目中的绝大多数应用需求。
2.5 服务管理系统
服务管理系统是平台各种服务运行的宿主环境, 与IIS托管、Windows Services宿主不同, 自托管宿主具有便于管控等优势, 能方便地启动、停止、重启服务, 可有效地对服务消费者进行过滤、监控、报警等, 同时能有效聚合外部服务, 更适合于平台级的应用项目。
2.6 Web GIS展示组件
Web GIS是各类业务对象时空信息的综合展示窗口, 是Web端业务应用系统的重要组件, 是核心层Hi Web GIS引擎二次开发的综合示例。Web GIS组件中的所有展示方式、事件和行为 (如图层组织、符号样式、查询范围、空间分析、搜索结果、消息处理、事件响应等等) , 均源自运行维护系统对Web GIS的配置结果, 它们之间通过GIS服务契约和前端框架引擎实现“所配即所得”的快速定制效果。Web GIS展示组件内置了丰富的功能模块, 包括图层控制、鹰眼、图文互查、空间查询、图形编辑、专题地图、GPS轨迹、地图打印等模块, 程序员只须在页面中通过为地图对象添加工具组件的方式完成这些配置。
2.7 代码生成工具
为进一步提升移动GIS项目的开发效率, 降低该平台框架使用的复杂度, 该文设计并实现了基于微软T4模版引擎的代码自动生成工具。程序员通过简单向导, 便能自动生成对库表数据增、删、改、查等功能多层结构 (UI、BLL、DAO、Sql Map) 、标准化、高质量的源代码, 并有效地解决了多表关联等难题。
3 结语
该文以解决移动GIS项目实施中所面临问题为出发点, 根据移动GIS类型项目的共性需求, 设计并实现了基于“云+端”模式的敏捷开发平台。目前已成功应用到国土违法用地巡查执法、安监执法、道路养护与路政稽查、输配电设备巡检、市政管网巡查、土壤重金属污染防治普查和农村土地确权登记等领域的多个项目中。实践证明该平台具有多语言、跨平台、可配置、易扩展等特点, 能有效提高开发效率, 缩减软件开发周期, 降低项目实施风险, 受到开发商和最终用户的一致好评。
参考文献
[1]李德仁.论21世纪遥感与GIS的发展[J].武汉大学学报:信息科学版, 2003 (2) :127-131.
富士通：从云基础架构走向云服务 篇10
在峰会期间，记者就富士通对于云基础架构的设计、开发、实施和云服务采访了富士通（中国）信息系统有限公司基础架构服务战略部资深顾问王卓和富士通（中国）信息系统有限公司市场总部产品战略部资深总监李帆。
动态基础架构支撑智能社会
富士通动态基础架构是其整体化平台产品战略，其中包括三部分，即工业标准服务器PRIMERGY M1产品线、富士通全新的ETERNUS CD产品线，以及去年11月在德国慕尼黑举办的富士通论坛上推出的全新品牌PrimeFlex集成系统。
李帆介绍说，富士通工业标准服务器PRIMERGY是以业务为中心的服务器。1994年诞生了第一代产品，距今整整20年。之前就曾听李帆介绍过，富士通的PRIMERGY服务器是在德国生产的，因此无论从机箱外还是机箱内，都散发出德国制造的高品质特性。从PRIMERGY产品的命名上，新产品首次有别于之前S8的命名，而采用一个全新品牌的命名方式，称为PRIMERGY M1，目前PRIMERGY有四个主打系列，包括塔式TX系列、机架式RX系列、刀片式BX系列以及专门用于高性能计算和云计算优化的高密度服务器CX（Cloud Extentsion）。据介绍，目前PRIMERGY产品线的主要系列产品都已经完成了从S8到M1的更新换代。
以目前主流的四路服务器RX4770 M1为例，其每位字母或数字所代表的意义是：“RX”表示设备的形态，分别为塔式、刀片、机架、高密度;数字“4”则表示插槽数，即4路服务器;之后的“7”则表示英特尔E7处理器家族;最后两位数字“70”则代表其产品定位;“M1”表示产品世代。李帆介绍说，M1系列基于英特尔2600V3系列处理器，相比上一代产品，除了性能上的飞跃外，管理效能大幅提升，扩展性上也有升级。“M1系列中还有两项创新技术，一是DynamicLoM技术，使用户可定制服务器的网络配置，产品出厂时支持直接选配主板上网口是单口万兆或双口万兆，同时也支持4个千兆、2个千兆的选择，极大地增强了灵活性。二是Cool-safe散热系统，支持高阶热力，可以使工作温度达到40度。2015年，我们还会推出具备水冷的高密度技术。”李帆说。
在存储方面，富士通新推出了全新的CD系列产品线，主要针对非结构化数据和分布式横向扩展的应用。据介绍，首款上市的CD10000是超大规模的横向扩展平台，模块化设计、高性能、超大容量，并实现零宕机时间、快速数据恢复。CD10000目前支持分布式对象和分布式块存储，最多可扩展到224个节点，约50PB的容量，整体密度非常高。李帆透露说，将于2015财年推出的第二版CD10000中会实现分布式文件存储。
近年来，一体机或集成系统成为热点产品，富士通PrimeFlex就是一款集成系统，可实现预安装、预调试、预优化，以满足用户对于云和大数据的需求。PrimeFlex集成系统采用最新的IT技术，可融入到富士通的基础设施产品中使用。“PrimeFlex设计初衷就是为了让用户能够获得一款简单集成就可使用的产品”，李帆说，富士通集成系统的整体布局分为四部分，包括虚拟化与云计算系统（即云平台）、大数据的处理与加速、SAP 生态系统的革新，以及将在今年晚些时候推出的富士通数据库一体机系统。
富士通云服务：
可信、全球化、集成
目前，为了适应越来越多的业务开发和不同业务的组合，云已经成为大多数企业的选择和认可的发展方向。对于云集成服务，富士通可提供5种IaaS服务、十几种PaaS服务以及100多种SaaS服务。王卓介绍说，富士通不仅提供自己的服务，在整个云集成服务里，还可以为合作伙伴或其他公司的云做整合，帮助用户从基于企业本地的IT架构方式实现云化。他认为，富士通云的特点归纳起来有三点：可信、全球化、集成。
对于可信，王卓解释说，无论是企业、个人还是政府机构，在考虑云业务时，安全始终是头等大事。富士通始终提倡可信的云服务，提供运行率为99.9998%以上可靠性的云服务。关于全球化，王卓说，富士通在全球有100多个数据中心，其在世界各地所提供的服务、标准、平台都是统一的，“我们可以用分布在世界各地不同的服务平台提供30多种语言的服务，不管企业在哪里开展业务，用哪种语言，富士通始终能找到与之匹配的服务模式。”而对于集成，富士通有近2000名的云集成师，专门负责给企业的云业务做集成、规划、管理，使客户能实现全球化布局，并可对多云系统进行集成监控，并提供应用服务。
王卓介绍说，富士通云的框架最下层是网络，之上是富士通提供的云安全服务。在基础架构IaaS层，富士通能提供私有云、公有云，以及集成合作伙伴的云。“富士通可以将这三块完全整合，这是富士通的优势所在。”王卓说。
对富士通来说，PaaS层也是非常重要的服务内容。王卓介绍说，“如果PaaS做好了，能起承上启下的作用，为以后企业SaaS扩展甚至为IaaS的战略规划起到平台作用。富士通有自己研发的PaaS流程和工具，也可以和富士通的合作伙伴整合。”在SaaS层，富士通的业务内容非常广泛，有一部分是自己研发的应用，而大部分应用都是合作伙伴的应用。据悉，富士通目前有500多家世界顶尖的合作伙伴。
信息服务架构 篇11
随着我国民航运输业的蓬勃发展,民航机场的运营信息化也在持续不断地发展。机场的运营信息系统(以下也简称为运营系统)指的是以飞机从起飞到降落和旅客从出发到到达为主导的运营信息化,包括了航班信息、资源管理、离港、行李、航班显示、广播、呼叫中心等系统。机场航班流量不断增长以及航空枢纽竞争的加剧,对这些系统应用集成的要求越来越高[1]。企业应用集成EAI(Enterprise Application Integration)目的在于实现企业各应用系统之间无缝集成,将分散在各个企业系统中的数据、应用和流程紧密联合起来[2]。机场需要一个现代化的以航班信息为核心的企业应用集成系统来实现各种不同运营系统的互连,因此机场的企业应用集成又被称为航班信息集成系统。航班信息集成系统是机场生产运行的核心,它实时发布航班计划和动态信息,完成资源分配计划和实时调度,与10余个运营系统实时交互航班数据。
EAI的技术主要包括两类:点对点的集成技术和基于面向服务架构SOA的集成技术。点对点的集成方式是一种传统的集成方式,采用如消息中间件、CORBA、DCOM等分布式技术,这种集成方式会使企业原有系统耦合度过高、灵活性较差[3]。传统的机场系统集成设计采用的是点对点的集成设计,运营系统直接与核心运营数据库或其他已投入运营的机场运营系统连接,紧耦合的系统集成设计意味着机场的系统紧紧地捆绑在特定的系统供应商上,系统升级和修改将带来巨大的风险和高昂的成本[1]。
SOA是一种建设IT基础设施架构的逻辑方法,它以服务作为应用开发的基本元素,支持快速、廉价、可组合的分布式应用的开发。SOA具有粗粒度、松耦合、跨平台、服务封装性和服务接口标准化等优点,使IT基础设施更具有柔性、重用性和互操作能力[4]。SOA因为其高度灵活性而在EAI领域取得了较大的应用。基于SOA的机场运营信息系统集成方案通过引入柔性的系统集成方法能够获得较大的业务灵活性。基于SOA的集成设计的关键问题是总体架构设计和服务的设计,因此本文首先根据集成设计的需求给出基于SOA的集成架构方案,其次基于设计结构模型DSM(Design Structure Matrix)方法给出了业务服务和服务接口的设计方案,这种方法设计的业务服务具有耦合性低和业务导向等特点[5]。
1基于SOA的机场运营信息系统集成总体架构设计
机场运营系统与机场运营和服务质量有密切关系,运营系统包括许多子系统,子系统间具有复杂的关联关系,因此为了实现集成设计的灵活性,必须首先要明确设计的原则:
● 模块化原则 整体进行模块化设计,允许将来简单替换某个模块。遵守SOA设计准则,为满足系统集成要求而设计的各项功能被定制成“服务”,可以为多种流程使用,能够实现服务重用,减少系统接口的数量。
● 独立性原则 航班及资源的集中管理,每个模块之间的耦合度最低。每个模块能保持自己业务的独立性,在其它系统出现故障时,可以通过人工输入信息的方式以保持独立运行。
● 独特性原则 各模块专职于其自身的业务,而不是包罗万象,业务分工明确。
● 可扩展性原则 未来的航班应用系统,可以通过灵活的方式接入集成信息平台,进一步扩展集成系统的业务。
根据以上原则并参考IBM提出的SOA参考模型[6,7],本研究给出了基于SOA的机场运营信息系统集成的架构如图1所示。
该架构的核心为消息集成代理IMB(Interface Message Broker),所有的运营子系统都通过IMB,按照基于XML的接口标准来进行数据交换,IMB松散耦合的设计能够实现服务重用,减少接口数量,提高系统的灵活性和可扩展性。
该架构中包含了3个核心数据库:机场运营数据库(AODB)、机场管理数据库(AMDB)和航班查询数据库(FQDB)。其中AODB是机场集成信息系统的核心数据库,存储了航班信息数据。AMDB主要存储管理相关的信息数据,如收费数据等,AMDB还存放了航班数据的历史记录为将来商务智能分析做准备。FQDB主要是航班信息系统的查询,其另一个目的是为AODB提供一个备份,当AODB系统或者通讯线路无法工作时,则采用FQDB的数据。
航班的集中管理通过把所有航班信息保存在一个中心数据库(AODB)中的策略来取得的,其他系统通过使用接口服务来访问AODB,并受到IMB的控制。通过使用已经存在的接口服务,只涉及很小的系统集成工作就能引入一个新的客户端运营系统。对一些不能使用开放标准方法和IMB提供的相关服务的遗留系统,可通过适配器来使用遗留接口。
2 基于流程分析的SOA业务服务设计
业务服务设计是SOA设计的关键问题,常见的服务设计方法有组件业务模型方法[8]、基于i*和e3建模的方法[9]、基于设计结构矩阵DSM的方法[5]等。其中基于DSM的方法从业务流程入手,通过对活动依赖性建模进行服务设计,具有较好的业务导向性和松散耦合性,因此本文采用基于DSM方法设计机场集成系统的业务服务。该方法的思路是:首先分析端到端的业务流程,其次使用DSM对活动间的依赖关系进行建模,最后通过聚类方法得到业务服务和接口设计。
2.1 航班业务流程分析及DSM建模
航班业务流程在机场运营中占据核心地位,该流程覆盖了从机场获得航班计划信息到最终旅客值机登记的全程,共27个活动,图2是采用UML活动图作为工具的航班业务流程图。
航班业务流程中使用到的信息资源和系统资源类型见表1。
设计结构矩阵可以有效描述系统元素之间的依赖性,并且提供分析技术,DSM可应用在机械产品设计和开发、组织设计、软件设计、流程设计等广泛领域[10]。DSM是一个二维矩阵,使用DSM对流程建模时,行列表示流程活动,矩阵单元格的内容用以描述活动间的三种基本依赖关系:流依赖(一个活动产生的输出被另一个活动所使用),共享依赖(若两个活动共享同样的资源)和适应依赖(指多个活动产生同样的资源)[11]。
设业务流程是一个二元组BP=[A,D],其中:
● A={ai|1≤i≤n},表示流程中所有的活动的集合,n为活动总数;
● D={D(ai,aj)|,∀ai∈A,∀aj∈A},表示任意两个活动之间的依赖关系的集合。
则流依赖表示为一个集合Df(ai,aj)={(t1,l1),(t2,l2),…,(tn,ln)},共享依赖也表示为一个集合Dr(ai,aj)={(t1,l1),(t2,l2),…,(tn,ln)},其中t表示依赖的资源类型,l表示依赖强度,表示该信息对于信息接收方活动的重要性。DSM的单元格eij表示活动间的依赖关系:
根据以上定义,航班业务流程的DSM模型如表2所示。
表2 机场航班业务流程的DSM建模
该模型中每一单元格的表现格式为“AB”,含义分别为系统和信息资源的id(资源id参见表3,通过超链接的方式,点击矩阵的单元格,会展示出各个资源的信息及其依赖强度,依赖强度采取5分制,5为最强,1为最弱。例如,点击下矩阵1行2列所在的单元格,会展现以下信息。
2.2 基于DSM的服务设计
以上通过DSM对流程活动间的依赖关系进行了建模,在此基础上通过聚类算法可进一步设计出业务服务。为了进行聚类,首先需确定依赖性的度量值,指的是用一个数值表示两个活动间的依赖关系的大小,本文作出以下定义:
●
●
● |D(ai,aj)|=β(|Df(ai,aj)|+|Df(ai,aj)|)+γ(|Dr(ai,aj)+|Dr(ai,aj)|),其中,β和γ表示流依赖性和共享依赖性所占的权重,不同的流程活动β和γ有不同的取值。
流程活动依赖性的度量值可以推广到活动和流程、流程和流程以及流程内部依赖性的度量,流程BP内部的依赖性定义为
Min
服务粒度对于SOA项目成功具有重要的影响[7]。服务的粒度是服务的规模大小,即服务包含的基本活动数目,粗粒度的服务运行的协调成本低,柔性较差;细粒度的服务则柔性较高,协调成本较高。本算法增加了一个控制变量g以控制流程模块的粒度。服务粒度记为size(BS),ai是流程BP的一个活动,PMk是BP的一个流程模块,考虑了粒度控制变量g的ai与PMk的依赖性记为
① 将流程BP的每个活动ai指定为一个独立的流程模块PMi,此时流程模块数和活动数相同;计算流程BP的初始内部依赖性度量值
② 随机选择一个活动ak,计算ak与每个流程模块之间的依赖性
③ 若流程模块设置发生变化,则删除重复的模块,空模块,以及被包含的模块,重复步骤②,若流程模块设置没有变化发生重复步骤②。
④ 算法重复了多次后
对于复杂和密集的矩阵来说会有一些模块外的单元格被留下来,这些交互被定义为模块之间的交互点,交互点中的依赖关系可转换为服务与其他服务交互的接口。
根据机场航班业务流程的特点,取β和γ分别为0.6和0.4,在粒度控制变量g=1.5的条件下航班业务流程DSM矩阵聚类结果如表4所示。
表4 基于DSM的航班业务流程的聚类结果
从表4展现的航班业务流程的DSM聚类结果将流程模块转换为服务,则得到业务服务设计结果如表5所示。
根据各模块间交互点得到的接口设计如表6所示。
这些接口中最重要的是i2运营航班更新接口和i3航班分发接口,他们分别允许客户端获得机场运营航班详细数据,以及对这些数据进行更新。此外各业务服务与IMB的接口几乎是相同的,这能够简化管理、维护和测试过程。
2.3 服务接口规约设计
服务接口规约指服务接口消息的技术标准,机场信息集成系统接口采用JMS消息中间件平台标准,消息通信模式为发布/订阅模式。在交互消息的数据结构设计时首先须确定消息的载体。消息的载体选择XML格式,以XML形式构建消息,可以使用XML解析器来抽取消息字段的内容,而不必考虑内容的大小,因此消息标识的加长不需要编程更改,同时还可以方便地将新字段添加到消息头中。消息结构包括Envelope元素结构、消息头、消息体等内容:
(1) Envelope元素结构 每一个XML消息必须以<Envelope>元素作为根元素。在此之下包含消息头和消息体两部分内容。
(2) 消息头 消息头的设计参考了JMS规范,其定义主要包括以下5个部分:
● MessageSentDateTime:消息的发送时间,作为消息生命周期的计算基础。
● MessageSequenceNumber:消息在转递过程中的唯一标识,标识应连续。
● MessageType:不同的消息类型,会被按照不同逻辑处理。
● SourceSystemID:作为回应消息的目标地址,具体的物理地址通过系统保存的映射表读出。
● DestinationSystemID:信息交互接口通过该信息确定消息的路由。
(3) 消息体 消息体结构中包含所有的航班、资源元素的定义,所有其他服务使用的XML Schema中相关航班、资源元素都必须从该结构中引用,保证了消息构造的同一性。同时,航班、资源信息结构的更改也能很方便地通过对Common结构的XML Schema的修改和发布通知到外部系统。消息体采用TextMessage类型,分为以下几种类型:
● 航班、资源数据订阅请求/响应消息;
● 航班、资源数据的内容/数据操作消息;
● 接口状态请求/响应消息;
● 航班、资源动态的上传消息。
每种类型的消息体都根据具体内容定义具体格式,本文不再赘述。
3 结 语
基于SOA的机场运营系统集成具有松耦合、模块化的特点,具有很高的灵活性,这使得机场能够容易、低成本的修改、更新、替换现存的各运营系统,从而有效帮助机场提高其竞争优势。未来民航业的竞争是集团化的机场集群间的对抗,这需要将多个机场系统、航空公司及产业链上下游企业和机构的信息系统进行有效的协调组织,以整体的形式发挥最大的能力。因此未来研究应该聚焦在基于SOA的跨企业的系统、过程的应用的集成上,迅速高效地将新的外部的信息系统整合到现有SOA体系架构中,将能够有力支持民航营运模式的改变,为建立统一的区域机场集群实体铺垫坚实的基础。
参考文献
[1]吴念祖,等.浦东国际机场运营信息系统(上海空港系列丛书)[M].上海:上海科学技术出版社,2008.
[2]张海军,史维峰,刘伟.基于SOA企业应用集成框架研究与实现[J].计算机工程与设计,2008,29(8).
[3]周妍,李建军.基于企业服务总线的基于企业服务总线的模具企业应用集成研究[J].计算机工程,2011,37(10).
[4]刘贤梅,刘茜,徐锋.基于SOA的企业应用集成模型的研究[J].计算机工程与设计,2009,30(16).
[5]方丁,刘杰,赵卫东.一种基于流程的服务设计方法[J].计算机集成制造系统,2009,15(5).
[6]Carter S.The New Language of Business SOA&Web 2.0[M].IBMPress,2007.
[7]Crawford C H,Bate G P,Cherbakov L.Toward an on demand service-o-riented architecture[J].IBM SYSTEMS JOURNAL,2005,44(1).
[8]Ernest M J,Nisavic M.Adding value to the IT organization with theComponent Business Model[J].IBM System Journal,2005.
[9]Gordijn J,Yu E,Raadt B.e-Service Design Using i*and e3value Mod-eling[J].IEEE Software,2006,23(3):26-33.
[10]Tyson R B.Applying the Design Structure Matrix to System Decomposi-tion and Integration Problems:A Review and New Directions[J].IEEETransactions on Engineering Management,2001,48(3).