SOA安全技术（精选7篇）
SOA安全技术 篇1
摘要：提出了一套有效的基于SOA的商业系统信息安全技术,解决商了业系统中亟待解决的安全问题,为商业系统提供了访问控制、数字签名、身份认证以及分布式入侵检测技术等安全性保障。
关键词：SOA,商业系统,信息安全技术,访问控制,数字签名
1 引言
信息安全的范围很大。大到国家军事政治等机密安全，小到防范商业企业机密泄露、防范青少年对不良信息的浏览、个人信息的泄露等。基于SOA的商业系统的信息安全技术是保证其信息安全的关键，包括各种安全协议、安全机制(数字签名、信息认证、数据加密等)，其中任何一个安全漏洞便可以威胁全局安全。信息安全服务至少应该包括支持信息网络安全服务的基本理论，以及基于新一代信息网络体系结构的网络安全服务体系结构。
信息是社会发展的重要战略资源。国际上围绕信息的获取、使用和控制的斗争愈演愈烈，信息安全成为维护国家安全和社会稳定的一个焦点，各国都对信息安全给以极大的关注和投入。信息安全已成为亟待解决、影响国家大局和长远利益的重大关键问题，它不但是发挥信息革命带来的高效率、高效益的有力保证，而且是抵御信息侵略的重要屏障，信息安全保障能力是21世纪综合国力、经济竞争实力和生存能力的重要组成部分，是世纪之交世界各国都在奋力攀登的制高点。我国的政治、军事、经济、文化、社会生活的各个方面受到信息安全问题的影响，如果解决不好将使国家处于信息战和高度经济金融风险的威胁之中。在网络信息技术高速发展的今天，信息安全已变得至关重要，信息安全已成为信息科学的热点课题。
2 SOA架构是商业系统的趋势
2.1 SOA的概念
SOA即Service-Oriented Architecture的缩写，也就是面向服务的架构，它是一个组件模型，是一种流行的软件设计架构，它将应用程序的不同单元通过这些它们之间定义良好的接口和契约联系起来，这些单元称为服务。服务之间通过简单并且精确定义的接口来进行通信。SOA体系架构中包含服务提供者、服务注册中心和服务使用者以及三种关于服务的动作：发布、查找和绑定。其中，服务提供者进行发布和响应服务，服务注册中心注册、分类和搜索服务提供者，服务使用者查找和使用服务提供者提供的服务。
2.2 商业系统采用SOA架构的必然性
商业系统的各个子模块也可以作为一种服务来看待,它可以为用户提供各种商业系统的各种服务功能，因此，商业系统与SOA架构结合是非常可行的。在基于SOA的某某商业系统的体系结构中，对商业系统服务构件，进行详细设计和开发，可以重复使用和共享已经实现的商业系统服务构件，这为其他具有类似功能模块的烟草商业系统的构建提供了便利条件，能够节省大量的时间，提高系统开发效率，为众多复杂的烟草商业系统的构建提供了可行的解决方案。因此，采用SOA架构是商业系统的必然趋势。
2.3 SOA对信息安全技术的要求
面向服务的体系结构(SOA)跨越了计算机系统和企业边界，一个应用软件的组件可以非常容易地跟属于不同域的其他组件进行通信。但是，SOA尚未能达到事务的不可否认性、事务撤回机制等最高可靠性，所以保证相互连接的系统之间的安全性是比较复杂的。
SOA作为一个具有发展前景的应用系统架构，仍然正在不断地发展，其安全性问题至关重要，对信息安全技术的研究也提出了新的要求。与传统系统相比，在基于SOA的商业系统中，提出请求的主体和提供服务资源的客体都具有较高的动态特性。由于主体操作方式的多样性和用户的计算环境的异构性造成了主体动态特性。服务本身的动态性主要表现在以下两个方面：可能扩充或修改服务提供的功能，服务的组成也具有动态的变动性。这就要求信息安全技术应该能够对这种变化动态地适应，能够根据安全相关地环境采取合适的信息安全技术。
3 基于SOA的商业系统的信息安全技术
3.1 访问控制
在基于SOA的商业系统的信息安全技术中，访问控制技术是最重要的安全技术之一，也是可信计算机系统评估标准中的评价系统安全的主要指标之一。访问控制就是主体依据某些控制策略或权限，进行客体本身或是其资源的不同的授权访问。访问控制主要由以下三个要素组成：主体、客体和访问控制策略。
(1)主体：是提出请求或要求的实体，是动作的发起者，但是它不一定是动作的执行者。主体可以是用户或者进程、作业和程序等任何代理用户行为的实体。实体可以是一个物理设备、数据文件、内存或进程等计算机资源或者是一个合法用户。
(2)客体：是接受其他实体访问的被动实体。客体可以是能够被操作的信息、资源、对象。在信息社会中，信息、文件、记录等的集合体，网路上的硬件设施，无线通信中的终端，都可以看作是客体，甚至客体之间可以互相包含。
(3)访问控制策略：是主体对客体的操作行为集和约束条件集，也就是主体对客体的访问规则集。在这个规则集中，对主体的作用行为和客体对主体的条件约束进行了直接的定义。访问控制策略体现了不超越规则集的客体对主体的权限允许这样一种授权行为。
由于基于SOA的商业系统的访问用户往往种类繁多、数量巨大、并且动态变化，增大了授权管理的负担。为了防止直接将访问权限授予主体，从而方便管理，系统采用了基于角色的访问控制模型RBAC。
基于角色的访问控制模型RBAC如图1所示。
3.2 数字签名
在基于SOA的某商业系统中，使用了数字签名技术。数字签名是实现认证和非否认的一种方法。认证允许一个人进行数据和身份的确认，而非否认防止一个人对其行为进行否认。
数字签名技术是不对称加密算法的典型应用。数字签名的应用过程是，数据源发送方使用自己的私钥对数据校验和或其他与数据内容有关的变量进行加密处理，完成对数据的合法“签名”，数据接收方则利用对方的公钥来解读收到的“数字签名”，并将解读结果用于对数据完整性的检验，从而对签名的合法性进行确认。在网络系统虚拟环境中，数字签名技术是进行身份确认的一种重要技术，可以将现实过程中的“亲笔签字”完全代替，在技术和法律上有保证。在数字签名应用中，可以很方便地得到发送者的公钥，但是需要严格保密发送者的私钥。
3.3 身份认证
身份认证是计算机及网络系统这样一个虚拟的数字世界确认操作者身份的过程。由于在计算机及网络系统中，是用一组特定的数据来表示包括用户的身份信息在内的一切信息的，因此，计算机只能识别用户的数字身份，也是针对用户数字身份的授权进行所有对用户的身份认证。现实世界中，每个人都拥有独一无二的物理身份。如何保证操作者的物理身份与数字身份相对应，是一个非常重要的问题。身份认证技术解决了这个问题。主要包括以下几种常用的用户身份认证技术：传统的基于口令的身份认证、基于随机口令的双因素认证技术、基于PKI体制的数字证书认证技术等。
基于口令的身份认证技术是指当被认证对象要求访问认证方的服务时，提供服务的认证方要求被认证对象提交口令，认证方将收到的口令与系统中存储的口令进行比较，从而对于被认证对象是否为合法访问者进行确认。具有构建方便、使用灵活、投入小的优点，适合一些封闭的小型系统和安全性要求不是很高的系统。
PKI是利用公钥理论和技术建立的提供安全服务的基础设施，是信息安全技术的核心。对于信息系统中的机密性、真实性、完整性、不可否认性和存取控制等安全问题，PKI能够有效地解决。基于PKI体制的数字证书认证技术适合大型系统和安全性要求很高的系统。
结合基于SOA的商业系统的实际需要，本系统采用了基于PKI体制的数字证书技术。
3.4 分布式入侵检测
在分布式入侵检测技术方面，基于SOA的商业系统使用了基于规则分析的策略。基于规则分析的策略的入侵检测的决策依据，是一些预先定义好的规则，通常情况下，由管理员进行输入或者是系统自动创建这些规则。基于规则分析的入侵检测系统在实现中最常见的两种形式分别是专家系统和神经网络。在异常入侵检测中，已经应用了SOM神经网络。研究表明，由于神经网络具有高效、并行、有学习能力等多种优势，非常适用于建立复杂多变的基于SOA的商业系统。
4 结语
随着SOA的发展，传统的信息安全技术很难满足应用系统的动态性和开发性的要求。采用面向服务的架构进行应用系统的开发，已经成为一种必然的趋势。但是，安全性和管理的复杂性已经成为阻碍其发展的重要原因。在基于SOA的商业系统中，提出请求的主体和提供服务资源的客体都具有较高的动态特性，要求信息安全技术应该能够动态地适应这种动态特性，信息安全技术面临着严峻的挑战。随着面向服务的架构技术的成熟，SOA的体系架构将被更广泛地应用，对于信息安全技术的要求会越来越高。安全性问题是基于SOA的系统的一个永恒话题，信息安全技术的研究和发展应该受到重视。
参考文献
[1]李益文.湖南商业系统信息安全运维管理体系建设的思考[J].信息网络安全,2009,(02).
[2]李勇.信息安全管理工作重要性认识初探[J].信息化建设,2007,(03).
[3]丁红萍,王甲佳.管理信息系统的创新革命——关系计划PK企业资源计划[J].物流技术,2009,(12).
[4]齐芳.从国内获得ISO27001认证企业看行业认证需求[J].信息安全与通信保密,2009,(04).
[5]杨晋.现代电子商务安全技术研究[J].网络安全技术与应用,2007,(01).
[6]刘涛,姜文志.军事管理信息系统安全管理研究[J].网络安全技术与应用,2008,(10).
[7]傅川,陈云.高校信息系统安全体系研究与实践[J].中山大学学报(自然科学版),2009,(S1).
SOA电子公文交换系统的安全性 篇2
1 SOA架构
在SOA架构的建立过程中, 首先要以业务流程来对电子公文进行详细的划分, 一般电子公文的交换过程, 见图1。
在实际应用过程中, 如RPC、EJB等通信系统都是基于服务构建的。但它们在实现上存在一定缺陷, 在交互过程中或多或少的会存在问题。然而, SOA则不同, SOA所围绕的服务都是基于技术实现的, 这也接造就了SOA可以与目前存在的任何系统相适应, 更好的解决了电子公文的交换, 合理的提高了政府的部门在办公上的工作效率。目前实现SOA主流的方法是通过Web服务实现, 在Web服务描述、数据格式、通讯协议上采用一些标准技术, 便于开发者在现有的开发平台上完成开发任务, 对现有人力资源和软硬件进行应用。
2 电子公文交互系统的安全性研究
在进行公文交换过程中必须要对安全问题加以考虑, 在一些特殊部门中的电子公文交换, 安全问题则显得更加重要。电子公文的发出与接收都会受到一定的限制, 与其它服务相同, 在安全问题上, SOAP在发送和接收消息时, 要确保信息的机密性和可信任性。以SOA架构为基础的电子公文交换系统在安全性上的保证主要由以下两个方面决定。
2.1 消息安全凭证
要确保Web服务安全, 首先需要在请求方与服务器间建立信任。在请求方和服务两者之间建立信任关系可以通过多种方法实现, 安全凭证是其中效果较好, 常用的一种。
采用安全凭证时, 请求方安全性不但需要被Web所熟知, 同时还需要获取到其信任。一般服务器在应用过程中可以都中机构进行应用, 从而生产自己的认证证书, 并将其发送给相应的权限请求者。请求者在得到安全证书后, 将会发送一条信息给服务器, 在信息中包含了已经签署的安全性凭证, 同时在信息中还应当包含与安全性具有密切关联的密钥证明。整个过程中, 服务器需要对所有的操作进行核实证明码, 并且要对安全凭证进行评估。签署在安全凭证上的信息必须是科学有效的, 同时服务器必须对其产生直接信任, 只有这样服务器才会对信息完成处理, 并将处理结果及时发回, 否则服务将不会对信息进行处理, 更加不会返回结果, 消息安全凭证确保了电子公文交换系统的安全性。
2.2 双重加密技术的应用
服务需要对所有用户开放, 在电子信息时代, 电子信息服务越来越广泛, 当一个客户进行了某项服务申请后, 服务器将会返回一些信息, 这些信息在有可能会被活动于网上的黑客截取。因此, 在实际操作过程中, 在电子公文传播过程中, 系统必须采取合理的措施进行安全防护。
在加密方式上, SOA架构与其它系统相比有较大不同。SOA在提供服务商主要以发布服务的方式进行, 服务提供方在消息发送时的解析工作必须要服务提供方完成, 同时服务请求者的消息的解析工作也需要由服务提供方完成。而加密工作则是在另一端进行, 这样在实际运行工作中就需要服务提供方和服务请求者在密钥上完成交换。
RSA和DES加密算法是在SOA加密过程中常用的两种算法, RSA为非对称算法, DES为对称更加密算法。DES的加密和解密效率要比RSA算法更加优越, 当从管理角度来看RSA可以通过公开的形式实现加密密钥而定分配, 因此加密更新显得更加容易, 并且在不同的通讯中进行应用是, 只需要保密自己的机密密钥即可, 安全性相对较高。在以SOA架构为基础的公文交换系统的加密过程中, 合理的将RSA和DES加密进行综合应用, 可以大幅度的提高系统的安全性, 通过RSA公钥交换, 实现了对DES密钥的加密传送, 从而实现电子公文的安全传统。
3 结语
SOA在现代社会发展中有着重要作用, 尤其是在电子政务中有着其它技术无法代替的作用。基于SOA的电子公文交互系统的安全性随着电子信息技术的发展得到了进一步提高, 这为我国的电子公文交换的发展提供了有力的支持。
参考文献
[1]徐克红.基于面向服务的电子公文系统设计研究[J].上海铁道科技, 2013, 3 (25) :13-15.
[2]李蓉.电子政务公文交换系统的设计与实现[D].山东大学, 2013, 10 (20) :1-15.
[3]陈思.基于SOA架构的电子政务门户系统的研究[J].南昌大学, 2010, 1 (3) :1-21.
SOA安全技术 篇3
2009年1月5日收到虽然SOA的概念已出现多年,但是在业界和学术界,基于WEB SERVICE 的SOA还是一个正在研究和发展的领域。现在基于WEB SERVICE标准的A2A或者B2B的系统集成越来越多。消息交换是SOA架构中的核心服务之一,它通常是通过SOAP来交换的,因为消息可能传输一些重要的商业信息,所以通过SOAP协议传输的消息的完整性和机密性[1]就需要给予很大的重视。正确使用WS-POLICY [2]和WS-SECURITY [3]这些规范的时候,可以避免XML重写攻击。但是在现实中,人们对这些规范的不正确应用很容易导致系统比较脆弱。
现提出SOAP消息的结构信息的使用,即SOAP Account,它能够有效地防止XML重写攻击。虽然使用SOAP Account可以让合法的消息接收者在接收时较早地探测出重写攻击,但是SOAP Account本身也可能是攻击者的目标,所以要重点分析SOAP Account本身的完整性保护。并且使用WS standards来描述WEB SERVICE的安全架构,重点从消息级别的安全来说明了它的重要性,以一个虚拟的恶意攻击例子来说明怎样实现SOAP Account完整性。
1 术语和技术
1.1 SOA
SOA架构是一种松耦合的服务集合,也就是说,服务是自包含的,松耦合的,不一定完全依靠另一个服务。SOA不是一个新的概念, Microsoft的DCOM技术、基于CORBA中的ORB(Object Request Brokers)技术就是SOA的最初应用。 SOA的基本架构:服务请求者发送一个请求消息给服务提供者,服务提供者返回一个响应消息,服务注册目录用来注册服务,服务请求者可以通过它找到请求的服务。
1.2 SOAP
SOAP[4]为Simple Object Application Protocol 的缩写,是Web Service的标准通信协议,是一种标准化的传输消息的XML消息格式。SOAP请求(request)消息将客户端的服务请求消息发给服务器,如需要调用什么样的服务接口,以及接口参数值等;SOAP答复(response)消息是从服务器返回给客户端的消息,如服务接口实现后的结果返回值或者调用服务时的错误信息等。
2 Web Service 安全
现从各个方面,Web Service描述了一些开放标准(如SOAP,WSDL,UDDI)交互,和不同平台(J2EE,DotNet等)的实现和应用。如此多的技术都在SOA安全方面有所应用,针对SOA的安全方面标准和技术正在快速发展。在这节中,我们简单介绍Web Service安全方面的架构[5] (图1)。
2.1 Web Services安全架构中WS*标准
在端对端的安全方面,WS-Security[2],WS-Policy[3],WS-SecurePolicy[5]和其它的Web Services标准是先后进化的过程。图1是不同的Web Services安全标准和一个简单架构,上述三个标准是这些标准中的核心标准。
WS-Security:描述了怎样提供对SOAP信息的头部提供签名和加密,以及安全tokens,包括二进制的tokens,比如X.509和Kerberos。WS-Security使用现有技术(如加密,签名)去保护SOAP信息的安全。
WS-Policy和WS-SecurePolicy:当SOA在不同的实体(如服务提供者,服务消费者和中介)提供松耦合的服务时,WS-Trust描述了一个框架,它能使Web服务去安全的交互。
2.2 Web服务的典型信息流
使用WS标准,Web服务的典型信息流(图2),服务请求者(request)首先从Security Token Service申请安全token,协议栈按照规则生成SOAP信封,并在WS-Security下的<Security>头标记下增加集成和机密的凭证,头标记块可以包含安全方面的信息给特别的接收者。这种类型的元素也许会在SOAP消息中出现多次。一个经过多个中间介的消息也许会增加多个新的子元素到这个头标记块中。
2.3 一个可能的重写攻击的例子
这里给出一个例子来说明SOAP消息在面对这种攻击时的脆弱性(图3、图4)。
例子:一个在线书店的消费者需要购买一些喜欢的书并为之付费(图3)。每一个成功的请求就会导致一次付费。假设这个SOAP节点(最终的接收者)去处理SOAP的header和body。消费者A为了购买想要的书,所以从他的账户转1 000元到书店
老板B账户上(图3)。一些恶意的攻击者拦截了这个消息并且转换了它的状态:转账1 000元变成了转账5 000元(图4)。一个攻击者能够在SOAP在传输过程中拦截并且处理这个消息,他能插入一个新的假的Header(比如<Bogus>图4),其它的,包括论证和签名都保持不动。因为元素reference URI仍然保留在消息中并保存有原来的值,这也许会导致消费者请求一次却付费数次。
2.4 SOAP Account
针对上面例子中的XML重写攻击,提出了SOAP Account技术,其实就是SOAP消息的元素结构的一个记录,这些元素包括头元素的数量,签名对象的数量,签名对象的继承信息等。
图5显示了SOAP Account消息的结构图,重写攻击主要的利用SOAP消息的结构语法,主要的工作就是在SOAP Account中,去捕捉这些信息的结构,我们使用AddSOAPAccount模型去增加这些信息去SOAP消息中。特别是绑定到WS-SECURITY规范的<Security> 头部。从而来避免XML重写攻击。
3增加了SOAP Account后应对XML重写攻击的情况
为了探测重写攻击,在SOAP消息被发送到它的合法接收者之前增加了SOAP Account信息到SOAP消息中(图6)。为每一个SOAP消息设计和实现了一个AddSOAPAccount模型去计算SOAP Account信息,同时在每一个SOAP处理节点中,有一个相应的CheckSOAPAccount模型去检查收到的SOAP消息的安全性。
SOAP Account本身面对XML重写攻击是脆弱的。因为在整个SOAP Account信息被发送到它的合法接收者之前,攻击者可能会用在节2.3中相同的方法去伪造它,SOAP处理节点中的CheckSOAPAccount模型就是扮演一个安全保护者,去保护任何可能的针对SOAP Account的重写攻击。
为了预防这种攻击,当SOAP消息到来时,CheckSOAPAccount模型会去做一些例行的检查。首先是确保收到的SOAP消息一定有一个SOAP Account头部,如果有的话,然后会验证SOAP Account的签名。如果数个中间介都有它自己的SOAP Account,那么会有一个嵌套的签名。如果上面的验证成功,CheckSOAPAccount模型会继续做下面的工作。图8显示了SOAP消息中有SOAP Account,同时攻击者试图去仿造一个SOAP Account头。这个攻击者增加一个新的头部,同时在新的头部Bogus下面拷贝了一封SOAP Account来使签名有效。但是当CheckSOAPAccount像检查SOAP头部一样检查SOAP Account的头部时,因为SOAP Account头部被拷贝放置在一个新的元素下,所以它不再是一个SOAP Account。模型会立刻一个抛出异常并说这个SOAP Account已经被攻击了,这样我们在对SOAP消息做下一步处理前我们就探测到了这个攻击。
即使这个攻击者提供了它自己的SOAP Account,在进行SOAP Account签名检查时,也将会立刻被检查为无效,原因如下:虽然攻击者提供了它自己更改SOAP结构信息后的SOAP Account消息,但是它不能在已经存在的<Security>标签中提供签名密钥信息。这个<Security>标签中包含信息的合法发送者的密钥信息(图7)。在图7中,合法的发送者是A,他在标签<KeyInfo>中提供了被用作签名验证的密钥信息。另外,一个受攻击的SOAP Account信息将会被放置在一个新的假头部下面(图8是在标签<BogusHeader>下面),这个假的头部将会在CheckSOAPAccount模型的探测过程中被探测到,这个攻击者也可能去插入一个新的<Security>标签和自己的密钥信息去验证加入的SOAP Account,同样CheckSOAPAccount也能使用上面同样地的方法探测到在标签<Security>增加的假密钥信息。所以,这样的重写攻击在SOAP Account的签名检测之前就会被探测到,更进一步,嵌套的SOAP Account签名消息将会使攻击者更难去伪造SOAP Account。这样就避免了XML重写攻击。
4 结论
提出一个有效的保护SOAP消息,避免XML重写攻击的方法SOAP Account,因为SOAP Account本身有可能是攻击者的目标,并论述了SOAP Account本身的集成安全性。其中通过一个真实的商业实例去分析了SOAP Account避免XML重写攻击的过程。还在基于有SOAP Account和没有SOAP Account上讨论了两种不同的信息流,显示了SOAP Account在SOA中的简单应用。考虑到真实世界中的系统可能有成百数千的SOAP消息的交换传输,使用这种方法的性能测试还需要去进一步去研究和证明。
参考文献
[1]祝伟华,周颖,杨丹阳.Web服务的安全性研究.计算机科学,2005;32(6):76—78
[2]Bajaj S,Box D,Chappell D.et al,Web services policy framework(WS-Policy),September,2004,http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy0904.pdf
[3]Bhargavan K,Fournet C,Gordon A D.Verifying policy-based security for web services.In:11th ACMConference on Computer and Commu-nications Security(CCS’04),October2004:268—277
[4]Rahaman M A,Marten R,Schaad A.An inline approach for secure SOAP requests and early Validation.http://www.owasp.org/images/4/4b/AnInlin eSOAPValidationApproach-MohammadAshiqurRaha-man.pdf,December,2005:132—135
SOA安全技术 篇4
计算机和互联网等信息技术促使各级单位的业务管理越来越多的依靠计算机管理, 而其核心就是各种文档的管理。各级单位管理文档随着时间的积累也越来越多, 存在着文档不易查找等现实困难, 同时企业的文件存在着安全控制问题, 有些文件可以公开, 查看有些文件需要一定的权限, 有些文件某些人可以修改、删除。所有这些问题在各个企业内部时有发生, 对于领导、部门负责人等来说, 文档的安全控制相当重要, 同时要尽快的查找到需要的文件, 由于文档查找不便给他们造成的时间浪费将会带来重大损失和严重的后果。
单位的文档管理混乱, 主要体现在以下几个方面:
(1) 文档过多, 忘记文件名, 查找不便, 若文件查找不到, 则需重新起草, 浪费了大量时间;
(2) 日积月累, 许多资源无法快速有条理的集中整理, 无法集中共享;
(3) 文件审批周期长, 上传下达过程中信息衰减严重, 影响企业执行效率;
(4) 安全性无法控制, 公司资料常被员工拷, 公司的各种信息面临着泄密的巨大风险。
为了根本上解决以上问题, 以有效提高公司文档的安全共享, 提高管理水平, 开发了文档安全管理应用系统。它融入先进文档管理理念, 运用领先网络和编程技术开发, 切实有效的解决企业文档管理工作中的难题。通过本系统可把单位业务管理中的各种电子文件 (如office文件、pdf文件、文本文件、CAD文件、音视频、图片等) 统一在一个平台上按照公司统一的文件组织架构进行科学管理, 实现单位、部门、个人之间的权限管理下的共享使用, 可以有效的控制不同人员对公司不同文件的查看、预览、下载、在线修改、删除等权限。实现单位文档的安全化共享, 对于提升单位管理水平具有十分积极的意义。
2 总体设计
系统需求:对服务器的相关文件实现管理, 实现文件的有序组织管理。客户端可以登录服务器共享服务器中的文件。实现对单位部门和员工的管理。实现不同部门和不同员工对不同文件的权限管理。
文件权限控制分类:
查看权:公司员工可以检索到服务器中的文件名、文件大小、文件类型等信息。
预览权:对于可以预览的文件 (文本文件、office文件、pdf文件、图片文件, CAD文件等) 员工可以在线预览但不能拷贝。
下载权:员工可以将服务器中的文件下载到自己的计算机中。
修改权:员工可以对服务器中的文件在线编辑, 编辑完成后自动保存到服务器中。
删除权:员工可以对服务器中的文件删除。
服务器中的所有每一个文件均实现对不同员工的上述五种权限的控制。
数据库设计:要实现文件的权限控制, 并对文件的使用过程进行记录, 因此系统的实现是基于数据库和文件系统的组合之上, 文件系统保存文件信息, 数据库系统对文件的相关信息进行记录, 当需要查找文件时首先在数据库上进行查询, 然后定位到文件系统进行下载阅读, 由数据库系统和程序结合对文件的权限进行控制, 这样就有效的实现了系统需求的目标。数据库系统设计包括用户表、文件信息表、字典表、权限表、日志表、文件使用记录表等。
系统设计:整个系统采用服务器/客户机模式, 由文档管理系统服务器和文档管理系统客户端组成, 系统采用微软VS.NET2012开发, 使用SOA的设计模式, 通过WCF技术实现客户端和服务器端的连接, 同时使得系统可以在互联网环境下运行, 系统架构见图1所示。
3 系统实现
计算机编程技术日新月异, 只有采用最新的技术, 才能用最少的代码和代价实现最优秀和最可靠的功能, 因此本系统的实现采用了微软最新的VS.NET2013来实现。采用的最新技术有实体数据集 (EF) 技术和WCF技术, 实体数据集技术实现了数据库表抽象成类, 因此极大地减轻了程序对数据库的处理工作, 通过微软的LINQ语句可以极为优雅的实现数据库处理的各种功能, WCF即Windows通信基础, 它采用互联网技术实现了编程的服务化, 客户端和服务器之间通过服务调用来完成相关功能, 使得客户端可以在Internet上运行, 并且服务可以共享。系统的开发分为两部分:文件管理服务器端开发和客户端开发, 服务器端的开发已建立服务和接口为主, 通过精心的设计建立了相应的服务和接口, 客户端开发以用户界面为主, 调用服务端的相应服务获取或保存数据, 与用户界面相交互。
4 结束语
文档安全在各种单位和企业中具有重要的意义, 随着互联网技术的发展, 产生的各类文档越来越多, 文档在生产和管理中的作用越来越重要, 加强对文档的管理成为许多单位和企业的迫切需求, 本论述实现的文档安全管理系统有助于满足这些需求。
参考文献
[1]夏普.Visual C#2010从入门到精通[M].北京:清华大学出版社, 2011.
[2]夏普.WCF4从入门到精通[M].北京:清华大学出版社, 2011.
SOA安全技术 篇5
1 与校园一卡通的连接
校园一卡通的设计采用基于SOA的设计框架,使用基于XML的WEB Service技术,提供通用的对外接口,在系统设计过程中,采用了Adapter(适配器)设计模式,可以通过配置来灵活支持Oracal、SQL Server、DB2等数据库,可充分利用学校现有的资源。采用基于面向服务的设计思路,我们制定了统一的服务调用规范,给出了一个系统平台体系设计框架,见图1。
机房管理系统与校园一卡通系统中信息的交换,必须建立两者的关联和交换机制,针对机房的应用,设计出完备的身份验证安全体系,按金融标准密钥生成控制体系,动态分配,按金融标准密钥分为6个组,数据采用DES/MD5/HASH的国际标准加密方法,卡片采用一人一密,一卡16密,这样可以确保数据在网络上的安全畅通传输[1]。
2 机房计费管理系统结构
我校分为东西两个校区,逻辑上属于并列模式,共用一个出口跟校园网进行连接,每个校区采用独立的计费服务器管理,个人密码、消费金额等全局数据通过一台总计费服务器来跟外网交换,结构清晰,具体如图2。
3 安全节点分析
作为校园网的一部分,结合上述图例可以看出,机房计费系统的安全节点可以归纳为如下:
3.1 总服务器与校园网的链接处
作为SOA体系的一个接入模块,此处是物理结构上的唯一链路,也是逻辑结构上的唯一通路,机房计费管理系统的所有数据和信息都必须通过这个节点,此处是过滤有害信息的关键所在,如图2所示(1)处。
3.2 各校区计费子服务器
对于分校区机房内部来说,这个节点又是内部与外部的链接要道,在此处对信息的安全措施到位,可以大大提高整体的安全性,如图2所示(2)处。
3.3 各校区核心交换机
在核心交换机上对虚网等的划分可以有效减少病毒的传染,避免病毒迅速在整个网络上蔓延开来,如图2所示(3)处。
3.4 客户端
终端用户是病毒来源的关键,学生通过上网等途径都有可能把病毒下载到系统中,从而进行传播和破坏,如图2所示(4)处。
4 安全节点的具体措施
根据分析出的安全节点,我们采取如下具体措施:
1)在(1)处架设双穴主机网关(DualHomedGateway),采用大内存高性能双接口PCI-E网卡来连接受保护网和外部网,堡垒主机上运行防火墙软件,转发应用程序,提供服务等,双穴主机网关堡垒主机的系统软件不仅可以对有害信息起到初步过滤的作用,而且可用于维护护系统日志、硬件拷贝日志或远程日志。
2)图示的(2)处在整个系统中处于最关键位置,它的稳定运行关系到整个系统的安全,所以这里从硬件和软件上对其进行详细分析。
(1)因为服务器要确保24小时不间断地运行,所以必须提供机器的备份,以防意外发生时候能及时恢复。在种类繁多的备份方案中,考虑到系统的重要性,我们采用了双机热备的方式,确保设备在故障发生后能立即切换到备份服务器继续正常运行。
考虑到系统数据量相对较少,结合经费预算等问题的限制,这里采用了集群应用中最简单的一种,即双机同步模式(Synchronous),将计费程序复制后以同步模式工作,把源节点的数据变化截获下来,实时传输到备份节点,并且同步写入,确保数据实时性,即使出现单点故障[5],也可以提迅速恢复,具体如图3。
除此之外,考虑到外部突发事件的因素,所以还需提供UPS的不间断供电方案,确保服务的稳定运行。
(2)软件层面主要包括系统的设置和软件的功能,基于目前对服务器进行的端口扫描并攻击病毒技术,对计费服务器尽量关闭无用的端口,我们可以通过系统的IP安全策略,添加屏蔽TCP某端口的筛选器,让外部电脑无法通过这个端口连接你的电脑,例如:TCP的135、139、445、593、1025端口和UDP的135、137、138、445端口都应该被关闭。而且服务器应该单独使用,不要加入其它应用,这样就可以只开放一个端口,包括数据库在内的所有端口都可关闭,尽量减少病毒和黑客的攻击[2]。
在服务器、数据库服务器和外网之间架设防火墙,过滤尽可能多的恶意攻击。
在软件设计中,对于数据库的访问只能进行计费服务器的单向访问,切断与学生端、管理端、刷卡端等的访问链接,确保数据库安全;
3)图示(3)处是整个内网的数据交换枢纽,有效划分虚网并设置访问规则,可以有效抵挡病毒的迅速传播,减少病毒的感染范围。我校根据实际情况,把每个机房都单独划分成一个Vlan进行管理,而且相互之间禁止访问,只能通过核心层进行数据流通,这样可以有效减少网络风暴等病毒蔓延的破坏,使破坏最小化[3]。
4)图示(4)处是终端用户,对于使用者来说首先当然是采取防病毒的各项措施来提高安全性,其次考虑到蓄意破坏计费系统的用户来说,我们在软件设计上也应该采用多种先进的保护技术,破坏者无法通过终止进程、反复注销、修改注册表、删除修改文件、动态跟踪调试、使用黑客工具等手段绕过或破坏客户端,以下是通过Delphi编写的代码,实现无法结束进程的功能:
5 对教学事故的防范机制
机房管理系统的认证和控制都要依赖机房网络环境,对网络的高依赖导致了以下矛盾:客户端门禁控制在网络瘫痪时将造成机器无法使用,容易导致教学事故;如果控制不严格又容易让学生钻空子,绕过收费系统逃费,为此,系统应采用下列的技术。
1)防ARP欺诈技术,可以有效解决ARP欺诈导致的网络瘫痪。2)智能判断网络故障的原因是使用者人为破坏还是系统网络问题,如果是前者,系统将锁定计算机不允许使用,如果是后者可允许使用。3)自动判断机器的使用性质,如果是上课,则在上课期间内即使拔掉网线也可正常使用。4)设置超级密码功能,对于少数网络不通(如网卡损坏,IP配置错误等)的机器,可以通过超级密码进入[4]。
6 结束语
基于SOA的机房计费管理系统作为校园网的一个接入模块,在安全方面存在很多的问题,不同的网络环境和需求面临的问题也多种多样,我们要通过体系结构对安全节点进行仔细分析,并给出相对应的措施才能有效解决安全问题。
参考文献
[1]袁宝兰.基于SOA的校园一卡通平台设计及其应用[J].吉林师范大学学报:自然科学版,2009(1):134-137.
[2]周义刚.校园一卡通系统与图书馆业务系统的集成研究[J].科技情报开发与经济,2009(8):26-28.
[3]白鑫,张娟.校园一卡通与图书馆管理信息系统的集成研究[J].软件导刊,2009(8):106-108
[4]联创机房管理系统项目组.技术白皮书[R].2007.
SOA技术在广播中的应用 篇6
中间件的出现无疑是分布式计算技术发展史上的一次重大变革, 在早期的分布计算中, 两个分布式应用程序之间的通信, 是在物理网络协议的基础上直接实现。编程人员必须处理物理网络的细节。中间件的出现, 封装了低级通信机制的技术复杂性, 对应用程序开发人员隐藏了通信技术库的细节。
比如以北京英夫美迪公司的S1自动播出系统 (以下简称S1系统) 为例, S1系统也是一种分布式系统, 不同的系列台可以分布在不同的服务器上, 播出库、节目库以及资料库等不同的库也都可以部署在不同的服务器上, 这就是一种分布式应用系统。由于S1系统是传统的播出系统, 没有采用中间件技术, 所以所有的客户端都需要是直接访问服务器, 那么程序员在编程的时候就必须处理所有的准确细节, 比如节目库位于哪台服务器、它所使用的数据是SQL Server还是Oracle等。这种方式的缺点就是可重用性低、可移植性和可维护性低。比如, 对于同样是查询节目这个功能, 必须在播出程序、节目管理程序以及节目查询浏览程序等不同程序中分别编写代码来实现, 显然这样的可重用性低, 而且开发工作量大。还有, 例如由于播出程序功能修改的需要, 系统变更了数据库的一个字段, 则必须通知所有其他模块的开发人员, 让他们修改他们所负责的代码, 以适应数据库的变化, 所以可以维护性低。而且由于这种紧密连接的关系, 想升级数据库时, 比如把Access数据库升级为SQL Server数据库, 或更换为Oracle数据库的时候, 所有的客户端程序都需要重新修改, 系统的可移植性低。
我们再来看看如果采用中间件技术, 是怎样一种情况。这个时候, 客户端不直接访问数据库服务器, 而是访问中间件服务器, 所有对数据访问的细节被中间件封装起来了, 应用程序开发人员不需要了解。比如同样是查询节目库的功能, 该功能被封装在了中间件中, 是中间件提供的一项标准功能。所有客户端的编程人员都不需要在每一个程序中编写相关的实现代码, 只需要在程序中调用中间件服务器提供的对应功能, 这样大大简化了客户端的开发。客户端程序只需要在调用相关功能的时候, 说明它需要查询的信息的参数就可以了:比如要查询“新闻频道”中, 标题中包含“国庆”的所有节目, 就把查询的频道参数设置为“新闻频道”, 标题参数设置为“国庆”就可以了, 剩余的操作由中间件服务器来完成, 并把查询的结果反馈给客户端。客户端不需要知道新闻频率的节目是位于哪台服务器上的, 使用的是何种数据库等细节。这样带来的好处也很明显。首先相关功能代码的重用性好, 比如同样的查询, 播出程序、制作站程序以及审听浏览等不同程序都直接调用中间件服务器中的相关服务, 不需要自己分别实现, 代码的重用性高。而且如果修改了数据库某个字段, 而接口方式没有改变, 则只需修改中间件服务器的相关代码, 而不需要让所有的相关开发人员都去修改客户端程序。如果想要更换数据库或者把数据库服务器的操作系统更换为Linux的时候, 只需要修改中间件服务器的相关代码, 而不必更换所有客户端的程序, 系统的可移植性和可维护性好。
卓越的中间件框架提高了分布式应用程序的灵活性、互操作性、移植性和可维护性, 成为有效实现分布式软件架构的关键。
二XML技术的出现解决了“中间件异质性”问题
虽然中间件技术为单个系统的开发提供了卓越的基础结构, 封装和屏蔽了对后台系统平台的访问细节, 这样可以很容易地使如Linux、Windows等不同的操作系统, 以及ORCAL、SQL等不同的数据库所构成的后台系统整合在一起, 以一个统一的标准, 向前端的工作站服务。
但由于分布式计算概念、标准和产品过多, 产生了“中间件异质性”问题。也就是说, 虽然很多的厂家采用了中间件技术, 但是中间件技术和标准较多, Oracle有Oracle的解决方案, 微软有微软的解决方案, 这些不同厂家的中间件产品彼此不兼容。一个大型广播电视台所使用的业务系统是很多的, 包括播出系统、媒资系统、多媒体新闻系统、广告管理系统等, 这些业务系统不可能完全采用一个厂家的产品, 这样不同厂家的产品虽然可能都采用了中间件技术, 但中间件产品是彼此不兼容, 则这些不同厂家的系统则无法有效地融合在一起, 协调工作。
XML技术的出现很好地解决了这个问题。
XML称为可扩展标记语言 (e Xtensible Markup Language) , 是一种简单的数据存储语言, 使用一系列简单的标记描述数据, 而且这些标记可以用方便的方式建立。
XML的设计宗旨是传输和存储数据, 而非显示数据。这是XML与HTML的最大区别, XML与HTML的设计区别是:XML是用来存储数据的, 重在数据本身。而HTML是用来定义数据的, 重在数据的显示模式。
XML与其他数据表现形式最大的不同是:它极其简单, 是纯文本的。XML的简单使其易于在任何应用程序中读写数据, 这使XML很快成为数据交换的唯一公共语言。
XML是独立于软件和硬件的信息传输工具。XML是一种流行的、独立于中间件的格式, 可以在不同应用程序之间交换数据和文档。XML基本上是IT行业可以达成一致的最小公分母。XML不与特定技术或中间件标准绑定, 经常作为一种特殊格式来处理各个不兼容中间件平台的数据。那就意味着不同的应用系统可以很容易加载XML数据到程序中并使用它, 并以XML格式输出结果。
三Web Service技术实现了不同服务系统之间的集成和互调
1998年, 微软工程师利用SOAP (Simple Object Access Protocol, 简单对象访问协议) 发明了基于XML的Web Service (Web服务) 。
Web Service本质上是要以标准化的方式实现企业内外各个不同服务系统之间的互调或者集成。它的设计目标就是简单性和扩展性, 这有助于大量异构程序和平台之间的互操作性, 从而使存在的应用程序能够被广泛的用户访问。基于XML Web services标准的可互相连接和整合的软件产品和解决方案, 可以给广播电台带来巨大的好处:比如不同厂家的制播系统、媒资系统、多媒体新闻系统、手机广播系统等异构系统间通过Web Service技术实现相互访问和协调运作;电台的信息系统可以更方便地为听众提供更好的服务;电台信息系统可以与电视台、广告代理商等合作伙伴的系统进行更好的相连。
下面我们看看Web Service的定义, Web Service的定义多种多样, 下面就列举几个:
Web Service是一种新的web应用程序分支, 它们是自包含、自描述、模块化的应用, 可以发布、定位、通过web调用。Web Service是基于网络的、分布式的模块化组件, 它执行特定的任务, 遵守具体的技术规范, 这些规范使得Web Service能与其他兼容的组件进行互操作。
Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后, 其他Web Service应用程序可以发现并调用它部署的服务。
Web Service是一种应用程序, 它可以使用标准的互联网协议, 像超文本传输协议 (HTTP) 和XML, 将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。
下面用一种基本的方法来分析一下各个不同服务系统之间的互调或者集成的实现方法。假如电台的网站系统能够需要从媒资系统获取相关查询服务。我们这里称网站系统为服务A, 媒资系统为服务B, 即服务A要远程调用服务B上的查询服务, 要实现这个目的, 需要下面3个要素:
首先媒资系统 (服务B) 需要向外公布, 它能提供什么样的服务, 即媒资系统必须要以一种标准化的语言让电台的网站系统 (服务A) 知道, 它能提供什么样的服务, 以及如何调用它的服务, 它的服务在哪里等, 这就是Web Service的服务描述, 是What、How和Where部分;
那么媒资系统 (服务B) 对外公布的服务信息放在哪里?这个需要服务提供者把相关信息注册到相应的公共网址 (我们成为服务注册中心) , 这样外部其他系统能很方便地找到这些发布的信息;
那么网站系统 (服务A) 想要媒资系统 (服务B) 的查询服务的时候, 它如何操作?首先它到服务注册中心查找想要的服务, 找到后, 网站系统 (服务A) 得到媒资系统 (服务B) 所提供的服务在哪里、如何调用等信息。然后网站系统 (服务A) 要以一种标准化的通信消息格式告诉媒资系统 (服务B) , 它想用什么服务, 并加入相应的输入参数等。当媒资系统 (服务B) 完成服务后, 会同样以标准化的通信方式告诉网站系统 (服务A) 相应的服务结果, 是Web Service的服务消息的请求 (request) 和响应 (response) 部分。
从上面的可以看出, Web Services包括3种组件:
服务提供者:提供服务, 进行注册以使服务可用, 也就是上面例子中服务B:媒资系统相关服务的提供者;
服务代理:服务交换所, 服务提供者和服务请求者之间的媒体;
服务请求者:向服务代理请求服务, 调用这些服务创建应用程序。也就是上面例子中服务A:网站系统。
同样Web Services包括3种操作:
发布/不发布 (Publish/Unpublish) :服务提供者向服务注册中心 (代理) 发布 (注册) 服务或移去 (不发布) 这些服务的注册;
发现 (Find) :由服务请求者向服务代理执行查询 (find) 操作, 服务请求者描述要找的服务, 服务代理分发匹配的结果;
绑定 (Bind) :服务器请求者得到相关的查询结果后, 根据查找到的结果找到服务器提供者。然后和服务提供者之间进行绑定, 即服务请求者向服务提供者申请调用相关服务。
以上3个要素实际上对应于Web Service的3个组成部分——WSDL、SOAP和UDDI。
WSDL (Web Service Description Language) Web服务器描述语言:主要目的在于Web Service的提供者将自己的Web服务的所有相关内容, 如所提供的服务的传输方式、服务方法接口、接口参数、服务路径等, 生成相应的完全文档, 发布给使用者。WSDL是由Intel、IBM、MS、Ariba等共同提出。是一个基于XML的语言, 用于描述Web Service及其函数、参数和返回值。因为是基于XML的, 所以WSDL既是机器可阅读的, 又是人可阅读的。一些最新的开发工具既能根据你的Web Service生成WSDL文档, 又能导入WSDL文档, 生成调用相应Web Service的代码。
SOAP是Web Service的标准通信协议:是一种标准化XML格式的传输消息, 以便大家都用同一种格式来讲话, 可以相互完全理解, 服务请求者和发布者使用该协议进行沟通。即服务请求者要以标准化的SOAP通信消息格式告诉服务提供者, 它想用什么服务, 并加入相应的输入参数等。当服务提供者完成服务后, 会同样以标准化SOAP通信方式告诉服务请求者相应的服务结果。SOAP采用了已经广泛使用的两个协议:HTTP和XML。HTTP用于实现SOAP的RPC风格的传输, 而XML是它的编码模式。主要有以下优点:第一, SOAP是可扩展的, SOAP无需中断已有的应用程序, SOAP客户端、服务器和协议自身都能发展, 而且SOAP能极好地支持中间介质和层次化的体系结构;第二, SOAP是简单的, 客户端发送一个请求, 调用相应的对象, 然后服务器返回结果, 这些消息是XML格式的, 并且封装成符合HTTP协议的消息, 因此, 它符合任何路由器、防火墙或代理服务器的要求;第三, SOAP完全和厂商无关, SOAP可以相对于平台、操作系统、目标模型和编程语言独立实现。另外, 传输和语言绑定以及数据编码的参数选择都是由具体的实现决定的;第四, SOAP与编程语言无关, SOAP可以使用任何语言来完成, 只要客户端发送正确SOAP请求 (也就是说, 传递一个合适的参数给一个实际的远端服务器) , SOAP没有对象模型, 应用程序可以捆绑在任何对象模型中;第五, SOAP与平台无关。SOAP可以在任何操作系统中无需改动正常运行。
UDDI (Universal Description、Dis-covery andIntegeration) 通用发现、描述和整合, 是一种创建注册服务的规范, 以便大家将自己的Web Service进行注册发布供使用者查找。
图2是Web service的服务过程的示意图。
四SOA实现了Web Service技术更高程度的抽象
虽然Web Service技术实现了服务接口的传输和调用的标准化, 但是还是没有解决广播电台内部不同Web Service平台间的异质性问题, 异质性 (特别是中间件的异质性) 的存在是一个基本事实。
我们无法阻止它, 却可有效地管理它。所以要求现代架构必须支持所有这些技术和概念, 同时必须适应底层分布基础结构的不断变化, 正是这些需求推动了SOA (service-oriented architecture, SOA) 技术的产生。SOA相对于Web Service实现了更高程度上的抽象和平台无关化。
SOA的实质是一个组件模型。它将应用程序的不同功能单元 (成为服务) 通过这些服务之间定义良好的接口和契约联系起来。
SOA整合发布平台将完全无关的平台所提供的各种服务整合起来一起发布给外界, 包括实施安全控制和监控服务状态等, 客户端完全不知道真正的服务发布者是谁。
SOA是一种IT体系结构, 称为面向服务的体系结构。SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚, 轻松应对企业商业服务变化和发展的需要。
SOA是在计算环境下设计、开发、应用、管理分散的逻辑 (服务) 单元的一种规范。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件, 开发者超越应用软件来思考, 并考虑复用现有的服务, 或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法 (例如消息机制) , 通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后, 这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发, 使得在商业环境许可的时间内对变化的市场条件做出快速的响应。
SOA也不仅仅是一种开发的方法论——它还包含管理。例如, 应用SOA后, 管理者可以方便地管理这些搭建在服务平台上的企业应用, 而不是管理单一的应用模块。其原理是, 通过分析服务之间的相互调用, SOA使得公司管理人员方便地拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息, 这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。
SOA和Web Service都包含“服务”的概念, 并且都能对客户端封装服务的具体实现。但是两者是有本质的差别的, Web Service只是实现SOA的一种主要途径而已。
Web Service服务接口需要绑定具体实现的服务组件来实现服务, 它对具体的服务实现完成了封装, 但是它本身是知道服务是如何实现的, 另外客户端调用Web Service组件时, 需要知道Web Service的具体位置和传输协议。但是SOA架构平台只和服务接口进行绑定, 实现了服务接口的透明化, 服务位置的透明化, 服务传输协议的透明化。SOA本身也不知道服务具体是如何实现的。SOA实现了更高程度的抽象。
五结束语
从上面的描述可以看出, SOA是一种IT体系结构, 是一个组件模型, 是一种开发和应用的规范。当广播电台采用的SOA构架来构建电台内的业务系统以后, 电台的播出系统、制作系统、媒资系统、新媒体业务系统等不同厂商生产的子系统, 都可以方便地实现集成和信息交互, 并可以轻松应对企业服务的变化, 而不论这些系统是使用的是Windows或Linux等不同平台, 采用Oracal、SQL Server等不同的数据库, 甚至可以是PC服务器或小型机等不同类型的服务器。
摘要：随着IT技术的发展, 以及实现传统广播和新媒体业务有效结合、相互支撑的需要, 广播电视的技术系统越来越多地采用了基于SOA构架的方式来建设。SOA, 即以服务为导向的软件开发思想, 是当前技术界最热门的话题, 而且用Web Service (Web服务) 技术作为核心构件去搭建SOA架构逐渐成为主流。本文主要从这两种技术的发展历程出发, 并结合播出系统来说明这两种技术在广播系统中的主要用途及其主要特点。
SOA安全技术 篇7
关键词：面向服务的架构,Web服务,企业应用集成,企业服务总线
0 引言
随着企业信息化建设的不断加强和计算机技术的快速发展,以及互联网的深入应用,企业内部和企业之间的信息交流不断增强。由于不同平台、跨域异构系统的存在,导致了部门与部门、系统与系统之间的信息沟通性差,数据共享困难,对原有应用系统与实施的新应用系统不能进行有效集成,在企业内部形成大量的“信息孤岛”。为了让不同的系统之间信息能够共享和集成,业务操作能够有效衔接,实现将众多的“信息孤岛”联系起来的需求,企业应用系统集成应运而生并得到了快速的发展。
1 企业应用集成
1.1 企业应用集成类型
企业应用集成大致可分为:用户界面集成、数据集成、业务流程集成和服务集成4个类型。
(1)用户界面集成。用户界面集成是为了向用户提供一个企业应用的统一门户。实现组织内外部人员之间的沟通、协作和信息共享,提高组织生产力;
(2)数据集成。数据集成通常是应用集成的起点,发生在企业内的数据库和数据源级别,通过从一个数据源将数据移植到另外一个数据源来完成数据集成;
(3)业务流程集成。业务流程集成是一种更高级的面向过程集成,通过使用面向信息中间件、企业数据总线和业务流程管理等技术,实现企业内部2个或多个应用系统之间工作流和数据流整合,实现企业内部与上下游产业链之间的业务流程整合;
(4)服务集成。在面向服务的架构下,应用间的服务集成一般由企业服务平台这样的基础设施完成,使应用间的关系从网状变为总线结构,减少应用间的耦合度,实现服务的虚拟化。
1.2 性能比较
传统的应用集成存在着很多缺点,其中数据集成不是其他应用能共享的格式,扩展困难。业务流程集成只在企业内部进行,不适应企业间业务流程组合。这些集成方式不具备灵活性,集成方法复杂,成本高。而基于面向服务架构的企业应用集成,提供了一个统一的、标准的、可配置的业务集成平台,可以解决不同类型的异构系统之间难以有效整合的问题。具体来说,与传统的集成方法相比,该集成方式的优点有:
(1)降低复杂度。面向服务的集成方式与点到点的集成相比降低了复杂度;
(2)增加重用性。通过重用以前开发和部署的共享服务,实现了更有效的应用程序的开发;
(3)降低成本。用作可重用服务的遗留应用程序降低了维护和集成的成本。
2 面向服务的架构
2.1 SOA体系结构
SOA有服务提供者、服务请求者和服务注册中心3个角色,有发布、查找和绑定3个操作。服务提供者通过在服务注册中心注册来配置和发布服务,服务请求者通过查找服务注册中心所拥有的服务记录来找到服务,服务请求者绑定并使用可用的服务。
2.2 Web服务及其关键技术分析
2.2.1 Web服务
Web服务是由万维网联盟(W3C)制定的一套开放的标准的技术规范。一般认为它是一种新型的应用程序,向外界提供一个能够通过Web方式调用的接口。具有自包含、自描述以及模块化的特点,可以通过Web发布、查找和调用。从而可以把基于不同平台开发的、不同类型的功能块集成在一起,提供相互之间的操作,可以很好地实现SOA设计理念。
2.2.2 关键技术
关键技术包括:
(1)可扩展标记语言(XML)。XML对于Web服务是很关键的,是一种基础的技术。XML是松散耦合的并且具有很高的操作性,其本身就是文本,不论是现在的主流计算机系统还是使用了多年的老一代计算机都在使用XML,XML本身并不简单,但是可以用简单的一句话概括:XML就是一个文件或网络数据包中的文本;
(2)简单对象访问协议(SOAP)。SOAP是一个基于XML的,在分布式环境下交换信息的、简单的、轻量级的通信协议。由于SOAP消息的格式是完全基于XML标准的,所以可以用来在不同的计算机体系结构、不同的技术平台、不同的语言环境和不同的操作系统之间进行通信,这也是其优势所在。SOAP包括3个部分:封装结构、编码规则和远程过程调用(RPC)机制。即SOAP提供了标准的远程过程调用方法来调用Web服务,并在应用和Web服务之间传送命令、参数和XML文档;
(3)Web服务描述语言(WSDL)。WSDL以XML格式描述Web服务接口。WSDL首先对访问的操作和访问时使用的请求响应消息进行抽象描述,然后将其绑定到具体的传输协议和消息格式上以最终定义具体部署的服务访问点。简单来说,WSDL是用来描述如何来使用SOAP来调用Web服务的;
(4)通用描述、发现和集成规范(UDDI)。UDDI是在XML和SOAP的基础上定义了新的一层,在这一层,不同企业可以用相同的方法询问对方的服务、描述自己的服务。UDDI提供了通过网络注册、发现Web服务的机制,能为Web服务提供“一次注册,到处发布”的功能。
3 解决方案
3.1 企业服务总线
ESB是由中间件技术实现并支持SOA的一组基础架构,支持异构环境中的协议转换以及基于事件的服务、消息的交互,并且具有适当的服务级别和可管理性。ESB通过采用总线的结构来构建和管理各个应用之间的拓扑关系,使得消息和事件能够在服务器上便捷地进行交互和通信,为客户提供了在分布式异构环境中与服务进行交互的机制。作为传统EAI技术发展的新阶段,ESB并不等同SOA,而是SOA的一个典型的架构实现形式。
3.2 架构设计
目前自主研发的信息系统包括项目管理系统、生产管理系统、生产齐套与计划管理系统、物资管理系统、合同管理系统和质量管理系统。这些分步实施的、异构的应用系统造成了企业数据及业务资源分散,共享困难,用户体验不佳。现采用基于SOA架构的方法来实现企业应用系统的集成,将以上系统的核心业务功能转化为具有自描述能力的服务,并通过其间定义良好的接口和契约联系起来。接口通过统一的规划和定义,独立于事先服务的硬件平台、业务逻辑和代码逻辑,构建在各系统中的业务服务可以以一种通用、统一的方式进行交互和共享。基于SOA的企业应用集成框图如图1所示。
基于Web服务的SOA的关键是使用标准的服务接口和松耦合的连接,其具体实现过程如下:
(1)建立服务注册中心,实现服务的发布和管理;
(2)对于已有的应用系统业务逻辑进行封装,实现统一接口,以Web服务的形式发布,使其他系统可以通过SOAP进行调用。对于新应用系统,要基于Web服务构件式的开发,并作为业务构件发布预先规划定义的接口服务;
(3)将各系统发布的服务进行描述,生成服务的描述文档WSDL,并注册到UDDI注册中心,以便其他应用系统能够发现和访问这些服务;
(4)服务请求者发出消息请求。经过解析被封装成SOAP消息,发送给企业服务总线;
(5)通过ESB的消息转换和动态消息路由机制,用户将请求发送给服务提供者;
(6)服务提供者接收到请求信息后,提供服务,由服务代理调用服务,服务请求者绑定并使用服务。
3.3 主要功能实现
客户端应用集成是实现企业应用门户的关键,企业应用门户客户端集成的流程图如图2所示。
统一认证系统作为企业应用门户的系统组件,是企业门户平台的核心。其提供的服务有登录状态验证服务、认证标识创建和认证标识验证服务。权限管理组件能实现应用系统的统一权限配置、统一权限管理和分配,拥有独立的授权信息数据库,用于保存用户对于各业务应用系统的授权信息。各应用系统实现的功能有登录状态同步服务和登录状态失效转接服务。
4 性能测试结果分析
为评估系统的安全性和稳定性,考察系统在高负载下的执行效率,使用Load Runner开展了小规模的性能测试。企业门户登录模块200用户以1个用户/s的方式递增并持续加压5 min的测试结果如图3所示。
图3反映了平均事务响应时间[3]指标和吞吐量指标与用户数量的变化趋势一致,平均事务响应时间越小,说明系统处理的速度越快。而吞吐量越小,说明对系统的带宽依赖越小。从图3中可以看到,4 min时平均事务响应时间达到峰值为9.2 s,当用户数量达到峰值时,平均事务响应时间均值为7.5 s,基本满足系统的性能要求。3 min左右吞吐量达到峰值,为4 116 620 B/s,刚好为用户数量达到峰值时,远远低于100 M/s的局域网带宽,系统不存在带宽瓶颈。
5 结束语
上述提出了一种基于面向服务架构的企业服务总线的体系架构模型,这种集成方式更好地体现了连接松散耦合、服务位置透明、应用协议独立和调用异步执行等SOA的特点,能够很好地支持和适应业务需求的扩展,具有广阔的应用前景。?
参考文献
[1]焦烈焱,冯兴智,杨洪波.SOA中国路线图[M].北京:清华出版社,2009.
[2]刘贤梅,刘茜,徐锋.基于SOA的企业应用集成模型的研究[J].计算机工程与设计,2009,30(16):3 790-3 793.
[3]陈霁,牛霜霞,龚永鑫.性能测试进阶指南[M].北京:电子工业出版社,2010.
[4]桂荣枝,彭开慧,张建辉.基于校园网的单点登录系统的研究[J].计算机与网络,2010,36(20):60-62.
[5]张海军,史维峰,刘伟.基于SOA企业应用集成框架研究与实现[J].计算机工程与设计,2008,29(8):2 085-2 088.