多模式人脸检测方法的研究.pdf

1．1 SOA在国内外的研究进展

1．1．1国外的研究进展

1996年，Garmer最早提出SOA(Servi ce．Ori entedArchi tecture，面向服务架构)

的思想，2002年12月，Gart ner提出SOA是“现代应用开发领域最重要的课题”，

预计到2008年，SOA将成为占有绝对优势的软件工程实践方法。Gart ner为SOA

描述的远景目标是：在于让IT变得更有弹性，以更快地响应业务单位的需求，实

现实时企业(Real ．Ti me Enterpri se)Il l 。SOA是在计算环境下设计、开发、应用、

管理分散的逻辑(服务)单元的一种规范。这个定义决定了SOA的广泛性。SOA

要求开发者从服务集成的角度来设计应用软件，既使这么做的利益不会马上显现。

SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让

SOA这个术语代表了一种模型，该模型中自动化逻辑被分解成了更小的独立

逻辑单元。聚集起来，这些单元就组成了一个较大的业务自动化逻辑块。目前，

世界上大的软件公司Mi crosoft ，BM，SUN等纷纷推出自己架构的基于SOA信息

开发平台和解决方案，使得这些公司走在SOA技术发展的最前沿。下面，就这些

新的实现作功能分析：

1．Mi crosoft的Indi go平台

Mi crosoft用于构建基于SOA应用程序的Indi go平台，使得专门用于创建SOA

应用程序的技术得到广泛应用[ 21。Indi go允许目前创建面向对象应用程序的开发人

员采用．NET Framework以相似的方式来创建面向服务的应用程序。同时为了让

这些应用程序能够与运行在Wi ndows和其他平台上的软件有效地进行交互，

Indi go还实现了SOAP和其他Web服务技术，这样开发人员就可以创建可靠、

安全且能够与运行在任何系统上的软件实现互操作的事务型服务。

Indi go基于．NETFramework 2．0并对其进行了扩展，提供了创建由客户端访问

的服务的基础，这一基础主要由一组运行于公共语言运行库(CLR)上的类来实

现。客户端与服务通过Indi go的内置协议SOAP进行交互。Indi go采用了一些

更新的Web服务技术，这些技术统称为WS．· 规范。这些文档定义了用于添加

可靠消息传输、安全性、事务以及更多基于SOAP的Web服务的多供应商方式。

2．mM的ESB( Ent erpri se Servi ces Bus，企业服务总线)平台

IBM实现了基于WebSphere产品族的ESB平台，构成了IBMSOA的基础架

构，提供了ESB的基本功能，如服务路由、消息转换、中介、传输协议、消息传

递模式、服务集成方式等，以及ESB的非功能属性的支持，如安全性、事物、性

能、可靠性、服务的监控和管理等131。通过不同模块可以支持您在复杂的企业IT

环境中构建稳定、安全、可靠的ESB，为整个企业基础设施向SOA架构迁移提供

3．SUN的“SOAPat h"( SOA路径) 服务导向架构

这一SOA实际执行方式与Sun提出的服务导向架构(SOA)解决方案计划组成

完整的体系。这一SOA实际执行方式在SOA技术的整个生命周期内．从概念论证、

准备阶段，到实际执行．等各个关键时刻，采用Sun的Java平台和SOA执行经验。

这一新的SOA架构，实际执行方式强化了支持Sun JavaES平台、SOA和Web

服务标准，以及运行于获奖的Sol ari sl 0操作系统的产品和服务的提供。这些产品

和服务包括：Sun Java Syst emAppl i cat i on Pl at formSui te(Java系统应用平台套件)一这

是一个解决方案，它直接通过一组Web服务来集成各种不同的企业系统；Sun Java

W曲Infi - astrueture Sui te(Java W曲基础架构套件)[ 41。这是一个快速启动Web服务的

方法；以及Sun Java Ident i t y Management Sui te(Java身份识别管理套件)一这是业界最

完整的和最具综合性的可以安全地执行用户身份识别管理的一整套产品。

1．1．2国内的研究进展

目前，国内针对SOA的研究，主要体现在部分中间件产品上，而基于SOA的

ESB整体解决方案非常缺乏，更多的是一些中间件产品和协同软件产品。但是，

有些公司已经推出了一些与SOA密切相关的软件产品。如：

1．中和威推出了国内首个支持SOA架构的ESB产品一nterBus，方便了企

业级信息系统的应用整合与服务。

2．北京点击公司开发的基于SOA的协同系统GK．St ar，已经在一些政府，军

队，电信的行业有了应用。

3．上海(复旦)协达软件科技有限公司也在今年年初推出了基于SOA的协同软

这些基于SOA的系统平台有些共同特性，都是基于原有的一些中间件产品，

在外围增加一些Web服务包装器，再把一些消息处理机制整合到原有的系统中，

实现在面向服务的开发中模块的松散耦合。这些都离企业级、完整的、规模的基

于SOA原理设计的系统解决方案有一定距离。

　　1．2研究意义

SOA( Servi ce．Ori ent ed Archi tecture，面向服务的架构)是一种建立、维护、

管理rr系统和业务流程的方法。在SOA架构下，以服务或组件形式出现的业务

逻辑可以被共享、重用和配置，如此以来，应用集成变得轻而易举。过去，应用

开发一直采用先开发、后集成的模式，而在SOA架构下，任何一种应用都由若干

种服务组成，这些服务在开发之初就已经考虑到重用问题，提供了标准的接口，

可以被各种应用和其他服务所调用。现在随着网络技术的发展，在信息化建设中

产生了大量为满足产品或服务需要的软件系统，如：ERP、CRM、OA、CAD等一

系列、电子商务和电子政务软件系统，但其间却往往缺少关联和通讯，导致这些

组件成为了一个个“孤岛"，但这些组件恰恰又是企业不能放弃的重要投资。而SOA

架构出现，则使在需要改变I- r系统时的灵活性大为增加。

本论文的意义在于把SOA理论应用于轻量级SOA系统的实现上，将革命性

地改变传统的基于C／S、B／S结构的信息系统实现方式，使作为主体的人、作为客

体的企业以及经由网络传输的数字信息世界三者无缝的结合起来，实现不受任何

时间和空间局限的互动，最终目的是根本性地改变人与数字世界、人与真实世界

的交互方式，能够为任何信息系统的实现、整合、跨平台服务提供新的模式p】。

1．3论文主旨与创新点

论文主旨是将SOA理论应用于实际的管理信息系统开发中，使得在管理信息

系统的生命周期中特别是设计与实现阶段上以一种全新的模式开展。论文是以一

个鲜花零售管理信息系统开发项目作为研究的主体，主要以系统中的订单管理、

配送管理、职员管理和业务报表管理等作为设计和实现的对象。论文有很强的实

践性和实际应用价值。

论文的独特之处在于信息系统框架实现技术的先进性，通过研究弄清SOA这

个与管理信息系统实现密切相关的新理论如何为管理信息系统实现的进一步发展

和应用提供新的途径和方法。进而为今后SOA理论在不同信息系统中的广泛应用

论文是在SOA研究蓬勃发展的形势下提出的。一方面，管理信息系统普遍存

在于应用主体的各级应用中，为提高应用主体的运行效率已经起到了不可代替的

作用；另一方面，SOA理论的先进性已经得到理论界的普遍认可，对提高信息系

统的灵活性可以起到至关重要的作用。现在，管理信息系统与SOA结合发展也就

成为了顺理成章的事。

　　1．4论文研究背景

2004年3月，东软股份大连分公司和美国Neul i on公司合作进行工作流产品、

鲜花零售管理系统、报表实现平台框架等项目的合作。

鲜花零售管理系统项目深入分析了SOA的实现准则，研制实现了一套轻量级

的SOA框架，管理系统基于这个轻量级的SOA框架实现了所有的业务功能。

1．5本文的组织结构

本文在轻量级SOA框架上，设计和实现鲜花管理系统中相关模块功能，总结

出了一套基于SOA实现信息系统的方式。论文的组织结构为：

第一章为“绪论"。介绍了SOA在国内外研究状况，论文研究的意义、研究

第二章为“SOA架构概述"。首先对SOA体系结构做了全面的介绍，接着给

出了SOA系统实现模型，最后分析现有的Web服务和SOA的区别、安全控制实

第三章为“基于SOA架构的信息系统设计"。本章主要完成了系统逻辑结构

的设计，包括服务模型分层、服务接口设计和服务回调结构的设计。

第四章为“基于SOA架构信息系统的实现”。本章主要完成了业务分层实现，

业务模块实现，报表模块实现。

第五章为“系统验证刀。本章主要介绍了系统实现的环境和验证结果，最后对

　　2．1体系结构

　　2．1．1起源

第二章SOA架构概述

1996年，Gartl l er最早提出SOA(Servi ce．Ori ented Archi tecture，面向服务的体

系结构)的思想，2002年12月，Gart ner提出SOA是“现代应用开发领域最重要

的课题”，预计到2008年，SOA将成为占有绝对优势的软件工程实践方法。Gartner

为SOA描述的远景目标是：在于让IT变得更有弹性，以更快地响应业务单位的

需求，实现实时企业(Real ．Ti me Enterpri se)。

研究SOA，不能不关注软件构件技术，基于构件技术提供网络服务是SOA的

重要思想起源，做SOA研发的公司无不对构件技术有一定研究【6】。在SOA架构中，

流动的应该是构件，而不是已经集成在一起的整个系统软件。一个用户选择了一

款软件，一般都有定制的要求，尤其是系统管理软件，如ERP、CRM等。构件化

技术为不同用户的定制要求提供了可能，把常用功能做成可供选择的构件，用户

就有了更为灵活的选择。没有构件化时，软件系统的各个部分是紧密结合在一起

的，因而会牵一发而动全身，采用了构件化技术后，软件的各个功能模块就可以

独立地实现、升级，而不会影响系统整体。

理论上，面向服务的体系结构这种思想，在其简易性上，十分吸引人。如果

你能够用定义很好的机构封装应用，就有可能将一个单一的应用加入到一个服务

的集合中。封装的过程创建了一个抽象的层，屏蔽了应用中复杂的细节(不用关

心用的是哪一种编程语言，什么操作系统，应用程序用的是什么数据库产品)。唯

一相关的就是服务所描述的接口。

SOA的优势在于高可复用性，灵活性，以及更好的扩展性和可用性。经过20

年的软件体系结构的创新，在一系列应用开发项目中，SOA的优点得到了体现。

SOA的首次尝试，只是用于新的业务逻辑的开发，只提供有限的功能，而系

统的主体部分，并不采用面向服务的原理构建。另外，竞争和创新意味着多样的，

不同的SOA实现方式使得集成没那么容易。

统一采用一种方案，共同获取这是不可能做到的。因此现实世界中，需要能

够融合各种差异。吸引早期的教训，各方供应商最终将聚在一起，为SOA提供一

SOA作为新一代的软件构架，在未来5"- ' 10年里将给软件产业带来革命性的

变化。在SOA时代，任何一个大的应用软件系统，都不再由一个软件开发商独立

完成，而是由不同厂商生产的基于基础标准和接口的中间件相互协作完成。到时

会出现各种消息通信、内容管理系统、工作流引擎、身份认证提供者、整合应用

和门户服务器等不同类型的中间件厂商。

　　2．1．2体系结构

SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些

服务之间定义良好的接口和契约联系起来[ 71。接13是采用中立的方式进行定义的，

它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这

样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务

之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性；另一点是，当组

成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存

在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构

是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵

活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作

伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性

质。我们称能够灵活地适应环境变化的业务为按需(Ondemand)业务，在按需业

务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它

企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变

更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师

来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还

未知的业务需求。要满足这种业务敏捷性，SOA的实践必须遵循以下原则：

· 业务驱动服务，服务驱动技术

从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计

师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面同样

要理解服务与提供这些服务的底层技术之间的关系[ 71。

· 业务敏捷是基本的业务需求

SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的搿元需求力，

而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满

足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个rI’环境的灵活

注册中心发布它们的服务，而服务使用者可以通过服务注册中心发现或查找可用

的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。

· 策略是一组条件和规则，在这些条件和规则之下，服务提供者可以使服务可

用于使用者。策略既有功能性方面，也有与服务质量有关的方面；因此，我们在

功能和服务质量两个区中都有策略功能。

· 安全性是规则集，可以应用于调用服务的服务使用者的身份验证、授权和访

· 传输是属性集，可以应用于一组服务，以提供一致的结果。例如，如果要使

用一组服务来完成一项业务功能，则所有的服务必须都完成，或者没有一个完成。

· 管理是属性集，可以应用于管理提供的服务或使用的服务。

　　2．1．3优越性

可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，

这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这

种服务实现方式本身也可以灵活使用。

· 明确开发人员角色

‘例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则

无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。

· 支持多种客户类型

借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客

户类型，包括PDA、手机等新型访问渠道。

服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以

彼此独立调整，以满足服务需求。

该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须

了解提供者的实现细节，这样服务提供者就可以在WebLogi c集群环境中灵活部署，

使用者可以被转接到可用的例程上。

2．2 SOA的系统实现

SOA本身是应该如何将软件组织在一起的抽象概念。它依赖于用XML和

Web服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安

全性、策略管理、可靠消息传递以及审计系统的支持，从而有效地工作。还可以

通过分布式事务处理和分布式软件状态管理来进一步地改善它【扪。整个系统的实现

要完全基于服务的理念去设计，把SOA的原则应用到系统从设计到开发的每个环

　　2．2．1系统协作

图2．2展示了SOA中的协作。这些流程遵循“查找、绑定和调用"范例，其

中，服务使用者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹

配的服务[ 91。如果服务存在，注册中心就给使用者提供接1：3契约和服务的端点地址。

下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。

图2- 2 SOA中角色协作

SOA中的角色包括：

· 服务使用者：服务使用者是一个应用程序、一个软件模块或需要一个服务的

另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行

服务功能。服务使用者根据接口契约来执行服务。

· 服务提供者：服务提供者是一个可通过网络寻址的实体，它接受和执行来自

使用者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务使用

者可以发现和访问该服务。

· 服务注册中心：服务注册中心是服务发现的支持者。它包含一个可用服务的

存储库，并允许感兴趣的服务使用者查找服务提供者接口。

SOA中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的

某一种(或多种)。SOA中的操作包括：

· 发布：为了使服务可访问，需要发布服务描述以使服务使用者可以发现和调

· 发现：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的

· 绑定和调用：在检索完服务描述之后，服务使用者继续根据服务描述中的信

SOA中的构件包括：

· 服务：可以通过已发布接口使用服务，并且允许服务使用者调用服务。

· 服务描述：服务描述指定服务使用者与服务提供者交互的方式。它指定来自

服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和服务质

除了动态服务发现和服务接口契约的定义之外，面向服务的体系结构还具有

· 服务是自包含和模块化的。

· 服务支持互操作性。

· 服务是松散耦合的。

· 服务是位置透明的。

· 服务是由组件组成的组合模块。

2．2．2 SOA实现技术

实现SOA的核心技术．Web服务。正如我们前面所讲的，服务是整个SOA

实现的核心，Web服务相关技术自然成为实现SOA的首选。

Ⅺ沮。1．0(可扩展标记语言，Extensi bl e MarkupLanguage)标准是一个基于文本

的Worl d Wi deW曲组织(W3C)规范的标记语言【101。与HTML使用标签来描述

外观和数据不同，舭严格地定义了可移植的结构化数据。它可以作为定义数据

描述语言的语言，如标记语法或词汇、交换格式和通信协议。

简单对象访问协议(Si mpl e Obj ect Access Prot oc01)是一个基于XML的，用于

为了发布和发现其他SOA服务，UDDI通过定义标准的SOAP消息来实现

服务注册(Servi ce Regi st ry)。注册是一种服务代理，它是在UDDI上需要发现服务

的请求者和发布服务的提供者之间的中介【11】。一旦请求者决定使用特定的服务，

开发者通常借助于开发工具并通过创建以发送请求并处理响应的方式访问服务的

代码来绑定服务。SOA不需要使用UDDI，但由于UDDI是建立在SOA上来完

成自身工作的，所以UDDI是服务发现的一个好的解决方案。

2．2．3实现SOA的方法学

SOA强调松散耦合，强调跨平台集成，这与模型驱动的架构和开发不谋而合。

模型驱动的架构和开发(Model

Dri ven Archi t ect ure, MDA以及Model

Devel opment，MI)D)并没有把业务模型和平台无关模型分开来，而是把平台无关模

MDA由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待

创建的系统有一个形式化的UML的模型。MDA首先给出一个平台无关的模型来

表示系统的功能需求和用例，根据系统搭建的平台，架构设计师可以由这个平台

无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来

直接生成需要的代码。

基于MDA的思想，利用MDD方式，我们可以对SOA进行建模，在此基础

上，实现各种形式的模型转换或扩展实现SOA。

　　2．3系统安全控制

通过修正和重建网络、计算机系统以及软件来增强安全性和可靠性可能在短

期是必要的，但是这些不足以满足整个国家的网络的安全要求，很难在已有复杂

的系统中增加安全性的要求。既使一切最好的防范措施都被充分地使用，如果对

信息安全没有本质上的改变，我们仍将无止境地修补“堤坝上的漏洞”[ 121。因此，

全新安全模式的研发需要从基础软件架构开始。通过对这些年来的软件安全问题

进行计算模型上的分析，可以看出原有的软件体系架构已经无法满足日益复杂软

件系统对安全的要求，新的、更安全的软件架构呼之欲出，SOA就是新安全体系

传统的软件架构并没有在安全性方面进行系统级支持，这是由于在软件产业

发展的初期，人们更关心的是软件的功能和效率，而对软件的安全并不是很重视。

随着计算机和软件开发技术的普及，软件的安全隐患陆续暴露出来，从病毒、盗

版、到蠕虫，软件的安全性面临巨大的挑战。PIG就是在这种背景下诞生的安全架

构，其部分解决对于信息认证及反盗版方面的问题，但对于原有的软件体系架构

源的同时，也为信息安全提供了系统级的支持。以软件构件化为基础的新的计算

模型，将对SOA的深度开发与普及起促进作用。

2．4 SOA与Web服务

SOA服务和Web服务之间的区别在于设计。SOA概念并没有确切地定义服务

具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就

是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web

服务在需要交互的服务之间如何传递消息有具体的指导原则【14l ；从战术上实现

SOA模型是通过HTTP传递的SOAP消息中最常见的SOA模型。因而，从本质上

讲，Web服务是实现SOA的具体方式之一。

尽管我们觉得Web服务是实现SOA的最好方式，但是SOA并不局限于

Web服务。并且一个基于Web服务开发出来的应用也不代表就是一个基于SOA

构架应用。Web服务只是服务实现的一个典型，是实现企业SOA的一个组件(非

必需组件)。SOA为基于服务的分布式系统提供了概念上的设计模式。Web服务则

是基于标准的、可经济实惠地实现SOA的一项技术。其他使用WSDL直接实现服

务接口并且通过XML消息进行通信的协议也可以包括在SOA之中。正如在别处

指出的，CORBA和mM的MQ系统通过使用能够处理WSDL的新特征也可以参

与到SOA中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息

传递协议，但是数据接口允许相同的信息交换。

既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以

及审计方面的要求，在SOA体系结构的框架中加入了一个新的软件对象。这个

对象就是企业服务总线(Enterpri se Servi ce Bus，ESB)，它使用许多可能的消息传

递协议来负责适当的控制流，甚至还可能是服务之间所有消息的传输。虽然ESB

并不是绝对必需的，但它却是在SOA中正确管理您的业务流程至关重要的组件。

ESB本身可以是单个引擎，甚至还可以是由许多同级和下级ESB组成的分布式

系统，这些ESB一起工作，以保持SOA系统的运行。在概念上，它是从早期比

如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而

SOA将I- I．资源透过服务这样一个在业务上有重要涵义的概念来提供、共享，

把IT与业务的距离更加拉近了一步。服务在涉及的层次上要比组件、函数、流程

等更高，而且往往在业务上可以找到与之直接对应的概念或实体，例如报价、订

单。服务打破了rr系统间的藩篱，就像一家公司的各个部门，平常各自扮演特定

对内或对外服务的角色，但彼此间如果能有效地通过共通的语言及文字，进行良

好的沟通，便能协力达成更大、更高的目标。

随着SOA和Web服务的潮流，带来了组合式应用(composi t e appl i cati on)的

开发方式和观念，开始逐渐被大量应用在Port al (门户)和Int egrat i on(集成)上。

组合式Portal 的做法，就是通过Portal 界面所提供的应用，往往不是真的在Portal

服务器上执行，而是将Web服务即时抓过来，再加以呈现，同时汇总给Port al 的

使用者【141。在整合方面也是采用组合式的方式。通过高级工具来设定，使系统得

以灵活地配合任务的调整，对各项以Web服务方式提供的服务进行不同形式的串

联和协作，同时快速地加以部署。

如果说Web服务等技术是SOA的血肉，那么正确的服务设计理念及系统运行

平台则是SOA的灵魂。SOA试图让IT能更快和业务同步，在规划上以提供弹性

在中间件领域，SOA架构日益成为中间件软件供应商争夺的新焦点。谁都希

望自己能够先于竞争对手提供最优的SOA技术实现平台，BEA也不例外。从技术

上来说，Web服务、组件技术的采用将有助于SOA的进一步普及，从业务上来说，

企业用户要求性价比更高的应用系统，SOA恰恰适应了这样的趋势。

　　2．5小结

本章主要介绍了所设计的SOA框架的体系结构。本章首先对SOA规范作了

介绍，接着介绍SOA框架的实现基本情况，接着介绍了系统安全控制，最后介绍

了SOA与普通的Web服务的区别。通过分析SOA框架规范，给出了基于实现SOA

的系统结构，最后对要实现基于SOA框架的管理系统的实现路线给予介绍。

　　3．I系统逻辑结构

第三章基于SOA架构的系统的设计

　　3．1．I系统概述

该系统为鲜花零售商开发的一个管理信息系统．系统实现POS管理(Poi nt

Sa；e)，库存管理mveatofy Managemen0，应收帐管理(Aceount s Recei vabl e)，订单

Management )，配送管理∞el i very M壮ag锄ent)，职员管理皿abor

Management )，系统配置管理(sy豇em)和业务报表管理(P．eport s)- 系统基于B／S

(Browser／Server)结构，用户可在瘦客户机可使用HTTP／HTTPS协议通过网络实

现不受地域限制的访问。图3- 1展示了系统的逻辑拓扑结构，图中的各元素描述如

f气罗p司——些L国囱

圉3．1系统逻辑拓扑结构

· 客户机通过浏览器访问中心服务器，各商店通过网络使用I- rl TP／HTTPSs

协议访问花商管理信息系统。

· 在中心服务器上部署花商管理信息系统服务器。

· 花商管理信息系统通过适当授权，可是使用支付处理系统，与银行联机处

理信用卡和支票交易信息。

· 通过Bl oomLi nk数据交换网络实现与其他花商的数据交换。

· 花商管理信息系统通过使用Some MQ消息代理集群与其他配套系统进行数

　　3．1．2系统架构

基于Web的花商管理信息系统可以通过Intemet／] ntranet访问，整个系统使用

Java语言开发实现，系统运行于基于SOA架构的SRVRBnR平台。所有功能模块实

现之后，放置于发布框架(Publ i shi ngFramevcork)，通过发布框架各功能模块可以

接受客户端发送的数据和生成显示结果发送给客户端【”】。每个模块通过企业信息

总线(ESB)调用其它相关模块、日志记录功能、系统审计功能、安全认证／授权

和数据访问等功能，实现系统功能整合。图3- 2展示了花商管理信息系统整体框

架(图中深色背撮的业务模块为本论文研究对象)：

　　1web■辅

| | 嘲l牌卜解慝豳一豳麟

±业锓t据月镕目茬口

3．1．3功能模块设计

圉3- 2花商管理信息系统框架

功能模块是系统功能的执行单元，彼此之间相对独立。合理的模块划分有助

于实现系统功能的不同裁剪。图3- 3展示了花商管理信息系统的功能模块结构，如

· 职员录入(Empl oyee Entry)

· 职员出勤(Empl oyee Attendance)

· 考勤卡管理(Ti me Card Mai ntenance)

· 费率管理(Defaul t Rat e Mai ntenance)

· 司机费用(Dri ver Rat e Mai ntenance)

· 职员打卡(Cl ock．In Cl ock．Ou0

· 司机薪水总览(Dri ver Payrol l Summary)

· 司机薪水细目(Dri ver Payrol l Detai l )

· 订单管理(Orders Management)

· 订单队列查询(Queue Browse)

· 订单消息录入(Message Entry)

· 订单预览(Order Previ ew)

· 入站队歹tJ(Inbound Queue)

· 出站队列(Outbound)

· 出站确认对列(Outbound Confi rmed Queue)

· 出站验证队列(outbound Veri fi ed Queue)

· 业务报表管理(Reports)

· 统计报表(An Reports)

3．2 Web服务模型

本系统中使用Java实现Web服务，通过发布框架，对外提供功能接口。图3_4

展示了客户端调用服务的模式。通常情况下在Web容器的前端，控制器(Servl et )

实现对客户请求拦截，检查用户提交的数据中是否有验证标记，如果发现验证标

图3．4服务实现模型

记，控制器产生相应的事件，把请求数据发送到验证器和转换器中进行验证，如

果验证成功则把用户请求发送到服务引擎，调用相应的服务1161；否则，返回客户

端相应的错误提示信息。服务引擎接受到客户请求后，通过配置文件调用相应的

服务实现，以便执行业务逻辑。

在Savanna框架中控制器、事件、验证器、转换器、服务引擎、工作者、实体

引擎等都已经作为平台的功能已经部分获全部实现，作为针对用户的业务逻辑，

主要实现服务和数据库存储结构。

针对服务的实现，考虑到使用平台的功能，划分为三层：服务接口层，业务

组合层，数据访问层。各层详细描述如下：

· 服务接口层，从服务引擎接受客户端请求数据，把业务层返回数据按照服

务定义包装，再返回给服务引擎。

· 业务组合层，解析客户端请求数据，进行业务计算，把计算结果返回该服

· 数据访问层，在业务计算中需要请求数据库的数据，由该层实现。

服务分层【15】的做法，主要为了移植和开发的方便，当用户需求发生变化时，

只需对业务组合层做相应的算法调整，避免对整个服务实现进行大的调整，减少

调试和测试的工作量。

3．3 Web服务接口设计

在平台中，服务的定义，通过编写配置文件实现，在配置文件中可以指定服

务接收参数，返回参数等配置项，下面一段代码显示approveTi meCardsOJ] 艮务的配

engi ne=。：] i ava' ’i nvoke=”approveTmaeCards”

l ocati on=”fl owers．retai l ．1abor．TtmeCardServi ce”

export ="t rue”>

Creat e a message，send i t<／dcscri pti on>

opti onal =“true”胁

opti onal =”true“／>

o衅i onal =’1仇帕“今

<／servi ce>

⋯<／servi ce>定义一个服务

属性：

向外界公布的服务名称，也即服务端可调用的服务名称，可谓服务

调用该服务的引擎，对大多数服务使用j ava引擎·

l ocati on

服务实现的位置．也即服务所实现的类的名称。

表示是否可被服务引擎调用。

对服务的个简单描述。

定义服务参数。一个q廿、骨节中可包含任意多个节

属性：

参数模式，表明该参数是接收才参数，还是返回参数a

o口t l onal

在上面的a9DroveTi mecards服务定义中．定义两个可选的输入(IN)参数，

数据类型均为St ri ng：一个可选返回(OLrr)参数．数据类型为Map；该服务执行

使用j ava引擎。当服务调用时，服务根据输入参数，可能返回一个Map结构型数

据，该类型结构可被客户端识别，或被服务引擎绑定到显示页面的控件中。另外，

要选择可被序列化的数据类型定义参数，以便HTTP／SOAP／JMS传输。

3．4 Web服务回调结构

在配置文件中，定义了返回的服务和需要单独返回参数的结构。在服务的定义

中，一般情况下只是定义返回参数的名称。定义为结构类型，为了使返回参数有

更多的包容性，需要单独的文件对每个返回参数结构进行详细定义。返回参数结

构中可以包含不同类型的数据，甚至可以包含可序列化的对象，服务引擎可以直

接把这些数据或对象，在视图中已定义绑定的情况下，直接绑定到视图控件中，

或者客户端使用脚本语言，把返回参数结构转化成DOM对象，再进行解析和数据

绑定。图3—5展示了approveTi meC＆rds服务的返回参数结构定义：

口互墨互互瞄墨Ⅱ蛋圄霹黯窭雹显墨：二．’

■■■●■■■医墨雹互——■■●_

●1^。_- 1”‘( r

　　1’r。q’’"

[二二二二j三夏二二二二二]| =__二二二二二苎三二二二l【

图3- 5服务返回参数结构

上图中所展示的是按照DOM对象模型定义的返回参数结构。文件夹图标表示

节点是复杂类型节点，可以包含子节点或属性；属性图标表示该节点只代表具体

的数值。对属性节点可以指定其数据类型，当数据绑定是，可以按照数据类型进

行一些必要的匹配验证。

服务返回参数定义完毕后，保存在配置文件中，服务引擎在加载该服务时，

同时加载该参数结构文件。当服务引擎接收到从服务接口层返回的数据时，调用

该配置文件，对返回数据进行匹配，所有已定义的参数会发送回客户端或执行视

图绑定，而其他未指定的数据被忽略掉。这样就可以减少一些由于附加数据造成

3．5数据存储结构设计

系统中所有的数据保存在数据库中，数据库系统采用Oracl e 9i 关系数据库。

依照实体关系模型分析获得订单管理，配送管理和职员管理的数据表结构。图3- 6

展示了订单管理和配送管理的数据表结构：

omordtr．．”viw_queue

州吖且numb| l【lO)

’flumr呲．v岫ar2伽

age ddvered date：越瞳髓

哪．house：dl坤)

ngJ∞鸶。川篡m删kc曲-仰

r朗| da：删叫：胁妇坤町

-Iap．刚e：曲州

妇It-吐咖七el《1田

md iu：var唧!

rn．j x吐nm,(1q

om_mess讶t queue

oHI-眦s踟．J憎oIy

．IIl腿s踟州、，、

lf嘲9ej t咖咧1 oJ

眦mge id：咖七eI(10)

++ 腱囊驴．吐栅吲1 a)

埔oP．code：d曩棚

thop code：曲afc8)

mhop mde：西邢)

腱嗣驴—咖：dIafI对

眦瑚gej 辨：曲删

order nu栅憎妇相

dow．ddetE ahaz(t)

message由IEdal 西ame

dea南g-h叫豫9rde【m删蛔：如『(8)

message．踟嘲艟．p州‰眦妇啊

h嘀：c『Ia『15)

’d岫曲ou眇哺_删讣。．，

ulna：nunuoe(5)

如ariIg．h嘴蛔cade：dl『田

order n帅k协曲删l

deamQhue：dIa唧

电而g_h叫叫蛔眦出￡咖晌

如响g_h舢姥：曲a巾)

蚰gjl硼蛐印-∞de：出田Ij)

tP．呷矾蜘甑V岫a嘲

operI吒eIfl目岬∞血：椭ar2cl哪

饥日删．蜘efV确硝50I

operalel：．付蜊I

卸-| 蜘地：哪啪∞

●谵l l al nel v' ar曲列1m

．出响l l Iou。乞，L倒弛

- 傩out 越eri e

嘲叩．∞de：cha吒町

_ejoc蛳．啪E何嘲

却曲I隍j l e：wh| 2420l

reisoll：憾喃ar2(30)

delvered敞由蜘

Ile_n珊：小| (仞

I翻code：蜊1)

mr／vn' =2㈣

_n恼d鲫—咿融：_dqr却q

“dl JkJi l oUSt ．om．queut ：·

maoe．吐哪嘲1唧

■汹I-『I_醒霄嘲

lie．n锄e：din(12)

, m, , hmmme：vmtm距O)

图3．6订单管理和配送管理数据表结构

以上关系图中连线代表了两个表间的主键和外部键关系。

　　3．6访问安全控制

系统利用框架结构和Web容器的各个优势，采用数据库验证和XML绑定验

证。用户从登录页面输入用户名和密码，提交后密码验证服务把用户名和密码进

行匹配，如果匹配成功，则返回该用户所有可以访问的权限列表。获得认证的用

户后，系统为该用户建立一个Sessi on，保存用户的基本信息和访问列表。所有用

户使用角色进行分类，

分别为DRIVER，

ASSOCIATE—NONRETAIL

ASSOCIA_TE—RETAIL

ASSTSTORE—MGR，STORE—MGR，DISTRICT—MGR，REGIONAL—MGR，

FRANCHISE—MGR，WESTBURY—BASED，EXECUTIVE，ADM吨S1RATOR，

使用角色界定了用户权限级别。

用户获得相应级别权限后，仍需要与具体功能模块建立关联，来限制访问权

限。服务引擎在加载一个页面时，会按照当前系统的验证服务所返回的访问列表，

利用XML解析器，匹配加载当前用户可以访问的页面。下面一段代码显示了如何

接收页面属性，页面列表和角色列表

sdect=”／page／coment／i tem／page l i st／i tem／pgname”／>

l i st mt hⅢ>

<／xsl t：i f>

这样可以防止通过即时通过认证的客户，也不能访问没有获得授权的资源。

因为)眦。匹配也是发生在服务器端，这样当页面加载到客户端后，既使通过查看

源码方式，也不能看到未授权资源的任何信息。

　　3．7报表实现设计

系统中所有的报表采用统一的报表控制器来控制报表的创建于显示，报表控

制器采用Servl et 实现，通过Web容器的配置文件，把所有报表访问导向到控制器

中，由控制器完成报表参数封装、格式转换等功能‘171。下面一段代码为控制器配

t hrows Except i on；

pubi c MapgetParamsO

ret urn thi s．params；

pubfi c Li st getDataO

i f(data—nul l

0 data．i sEmptyO)

／／thi s i s for prevent i ng bl ank report i ng pages

dat a=newArrayLi st0；

data．add(newHashMapO)；

return data；

pubi c St ri ng getFi l eName0

return thi s．fi l eName；

　　3．8小结

本章详细介绍了基于SOA框架的信息系统设计。首先给出系统逻辑结构，接

下来介绍了Web服务模型、服务接口设计和服务回调设计，然后针对服务的要求，

给出了系统安全控制实现的设计，最后介绍了报表实现设计。

第四章基于SOA架构的系统的实现

4．1 Web服务模式分层

整个系统使用Web服务实现各模块功能函数，利用XML配置文件对外发布。

如前所述，服务分为三层：服务接口层、业务组合层和数据访问层，每一层均有

不同的实现方式和接口类型。

4．1．1服务接口层

服务接口层文件通常情况下定义为xxxxxxxServi ce，以表明该文件应用于服务

接口层方法定义。在XML配置文件中，使用服务接口层方法作为服务的入口，也

作为对外公布的接口，这样远程调用端只需要知道服务接口层的配置参数，隐藏了

后面业务组和层和数据访问层。下面_段代码显示了服务接口层方法approveTmaeCards

pubfi c stati c Map approveTi meCards(Di spatchContext detx,

Map context)

Map resul t =newHashMapO；

Tt meCardHel per t cHel per=newTtmeCardHel per0；

result．put(”condition”，

tcHel per．approveTtmeCards(eontext))；

ret urn resul t；

catch(getai l Excepti on e)

resul t．put(Model Servi ee．RESPONSE_MESSAGE，

Model Servi ee．RESPOND_ERROR)；

m_log．e舯“e．getMessageO)；

嘞l mresul t；

服务接口层方法必须使用静态方法(st at i c)实现，返回类型也必须为Map对

象。因为Map类可以封装其他的任何数据类型，可以保证返回参数中包含结构化

数据，满足客户端的不同数据要求【侈】。

服务接口层方法作为对外公布的方法接口，远程调用通过服务引擎调用器实

现，服务引擎作为一个发布框架中的公共调度机构，必须有统一的接口，这样就

要求所有的服务接口层方法要又统一的接口样式。所以，在系统中所有服务接口

层方法均有两个参数：

Di spat chCont ext dct x服务引擎在系统加载的时候被创建，针对每次

服务调用，服务引擎均会产生一个于该服务相关的Di spat chCont ext

对象，包含服务引擎相关的参数和配置信息【19l 。同时，Di spatchComext

也保留着一些系统级对象的引用，可以保证在一个服务内，同步或

Map cont ext 该参数是由发布框架中的服务引擎，针对每次调用所创建

的运行时数据和用户数据的封装，服务引擎把远程提交的数据封装

到Map中【l 明；同时，把用户认证后保留在系统Sessi on中的用户信息

也封装在Map中，这样，在服务内部可以提取所有这些参数，用于

服务接口层方法返回参数必须是Map类型，在返回参数Map中，可以根据需

要封装其他的Map、Li st、Stri ng、Date等可序列化的对象。返回参数Map的结构，

必须按照服务回调结构定义进行封装。因为当服务调用返回时，在服务引擎中，

会把返回参数Map和回调结构定义进行匹配，同时与页面绑定。如果封装顺序和

定义的顺序不相同，服务引擎认为定义的参数为Nul l ，在远程客户端将得不到任

4．1．2业务组合层

业务组合层文件通常情况下定义为xxxxxxxHel per，以表明该文件应用于业务

组合层方法定义。通常情况下，业务接口层实现的所有方法是被服务接口层所调

用，由普通类实现即可，不需要在XML配置文件中配置。而且，对业务组合层方

法的接口参数没有严格的限制，可以根据功能需要定义接口参数类型。

在服务接口层方法approveTi meCards()中定义的类Ti meCardHel per就是一

个业务组合层类，在随后的代码中调用了该类的approveTi meCards()方法。下面

一段代码显示了业务组合层方法approveTi meCards()的实现：

pubfi c Map approveTi meCards(Map context)throws Ret ai l Except i on

Stri ng shopCode=Mi scUti l ．getShopCode(comext)

t hi s．recei vi ngShopCode=seq；

pubhc Stri ng get MsgSeqNumber0

ret urn t hi s．msgSeqNumber；

模型类定义时，所有内部变量使用私有(pri vat e)类型，同时建立相应变量的

get方法和set方法，方便外部读取。

4．1．3数据访问层

数据访问层文件通常情况下定义为xxxxxxxDAO，以表明该文件应用于数据访

问层方法定义。通常情况下，数据访问层实现的所有方法是被业务组合层或服务

接口层所调用，由普通类实现即可，不需要在XML配置文件中配置。而且，对数

据访问层接口参数没有严格的限制，可以根据功能需要定义接口参数类型。

数据访问层主要封装数据库访问逻辑，可以隔离由于数据访问方式的变化对

整个业务逻辑的影响。在Java程序中数据库的连接建立、连接释放、SQL语句执

行、数据转换等，在不同的模块中使用方法都相同，所以在实现数据访问层时定

义一个父类，实现所有公用功能。下面一段代码显示了数据访问层父类(BaseDAO)

pubhc cl ass BaseDAO

pri vat e stati c fi nal St ri ng DBCONNECT=”dbname”；

pubhc DBSource get DBSource0

pubhchat update(Stri ng sql)

pubhc Li st query(Stri ng sql)

业务模块中要定义具体的数据访问方法时，每个定义的数据访问层类都从这

个父类继承，避免了代码重复。数据访问层类只需专注于SQL语句的创建、返回

结果的合并等于业务相关的功能。下面一段代码显示了数据访问层娄Tmi eCardCal cul ati on

pubi c cl ass TmaeCardCal cul at i onDA0 ext ends BaseDAO

publ i c i nt approveTi meCards(St dng ernpl oyeeCode，

Dat e workDat e，

Stri ng ui d)

t hrows Ret ai l Excepl i on

St ri ngBuffer sql =newSni ngBuffer(' ‘INSERT INTO”)，

returnthi supdate(sql toStri n90)；

　　4．2业务模块实现

4．2．1配送管理(Del i veryManagement)

4．2．2职员管理(LaborManagement)

4．2．3订单管理(LaborManagement)

图4- 9订单消息录#, (Message卧打y)

i 篡鋈i 薯篓{蠢垂

豳l | | | i 篓

篡篓i l 黧{薹篆

4．2．4统计报表(AHRepot s)

4．3报表模块的实现

图4- 12统计报表(Al l Repo也1

在系统中，报表通过Serv] 融创建和输出，客户端可以接收输出流或文件。所

有报表的实现不需要建立基于XML配置文件的向外公布的方法。报表的实现分为

两层：数据转换层和数据访问层。报表的展现需要报表模板文件，模板文件需要

单独设计，在系统中采用Jasper报表模板文件，设计之后经过编译生成j asper的

二进制文件，发布到配置目录中，Servl et即可自动加载。

4．3．1数据转换层

数据转换层由报表控制器Report Servl et 类和相应的报表类实现。一般报表类

定义为xxxxxReport ，该类继承Report Act i on，在Report Acfi on类中封装了一些公

共参数的转换与实现。下面一段代码展示了如何实现ReportActi on类：

publ i c abst ract cl ass Report Act i on ext ends geport Act i onBase

pri ‘vate Stri ng shop_code

pn。vate St ri ng user name

pn‘vate St ri ng丘om_dat e

pri 。vate St ri ng t o_dat e

pri 。vate St ri ng to—ti me

pri 。vate St ri ng sal e蛳pe

publ i c voi d openReport(HttpServl etRequest request)

t hrows Except i on

=request．getParameter(”shopcode”)；

2 request．getParameter(“usernRr／l e”)；

from—dat e

=request．getParameter(”fromdate”)；

2 request．getParameter(”todate”)；

2 request．getParameter(”toti me”)；

sal e_t ype

2 request．get．Parameter(”sal etype”)；

／／create report

createReport(request)；

publ i c abst ract voi d createReport(HttpServl etRequest request)

t hrows Excepti on；

／／下面定义类私有变量的Get方法和Set方法

要实现具体的报表类(xxxxxReport)时，继承该类后，只需要实现ereatReport

方法即可，该方法的参数request为ReportServl et类接收到用户提交的数据。下面

一段代码展示了报表类(POTal l yReport )的实现：

publ i c cl ass POTal l yReport ext ends Report Act i on

publ i c voi d createReport(HttpServl etRequest request)

t hrows Except i on

POTal l yDAOdao=newPOTaIIyDA00；

dao．getPOTal l yData(request．getParameter(”shop_code“)，

request．getParameter(”desi gner”)，

request．getParameter(”vendor_name”)，

request．getParamcter(“begi n_number”)，

request．getParameter(”end_number”)，

request．getParameter(“begi n_date”)，

request．getParameter(”end_date”))；

params=(mshMap)dao．getParametersO；

createReport()方法中通过POTal IyDAO类获得数据封装好后，由ReportServl et

类传递给报表模板文件，生成相应的二进制流或文件。

4．3．2数据访问层

数据访问层的功能和Web服务三层结构中的数据访问层功能完全一样，起到

隔离数据封装和数据获取的作用。数据访问层实现类一般都定义为xxxxxDAO，同

样继承BaseDA0类。例如上面代码中的POTal l yDAO类。

4．4客户端实现相关问题

整个系统基于B／S(Browse／Server)结构实现，在客户端(Browse)需要使用

脚本语言实现一些功能，例如数据类型验证，数据组合等。在本系统同中，考虑

到于不同浏览器的兼容性，所有脚本使用JavaScri pt。

在基于B／S结构的系统中，整个页面提交会产生较大的通信量。所以，根据

实际业务需要，使用后台隐藏提交部分数据，而获取相关数据的方式。下面一段

代码展示了以隐藏提交数据方式实现职员删除：

获得当前浏览器类型。

vaf i si e=(wi ndow．navi gator．userAgent．i ndexof(”MSIE”)>O)；

vat url =“empl oyee_del ete_mth?empl oyee_code2[ empl oyee_code] ”；

var method=‘‘POST' ’；

If(i si e)

浏览器为m时，要创建XMLHTTP对象

var request er=newActi veX0bj ect(”Mi crosoft．XMLHTTP”)；

requester, open(method，u吐fal se)；

requester．sendO；

浏览器为Fi reFox，Net scape时，要创建XMLHt t pRequest 对象

var request er=newXMLHttpRequest0；

requester．open(method，u吐fal se，⋯。，Ⅲ’)；

requester．send(data)；

获得返回DOM对象，包含所有返回数据。

var ret urnDat a=request er．responseXML；

返回数据的结构就是在函数回调方法中定义的结构，按照以定义的结构可以

从DOM对象中解析出所有数据。

　　4．5小结

本章介绍基于SOA的信息系统的详细实现，包括Web服务分层实现、业务模

块实现、报表模块实现和客户端调用实现，并给出了服务实现和调用中的相关问

　　5．1系统环境

●CPUCderon 1．OG

· 内存：512 M

系统开发软件环境要求：

操作系统：W．mdows 2000 Professi onal

开发工具：WebSphere Appfi cafi on Devel oper 5．1．2(WAD)

操作系统：W_mdows 2000 Server，Red Hat Li nux 9．0

数据库系统：Oracl e 9i Wmdows，Oracl e 9i Li nux

应用服务器：WebSphere Appl i cat i on Server 5．0 Li nux

　　5．2系统开发

系统运行中，使用两台数据库服务器模拟现场的数据环境。一台安装Wi ndows

2000 Server，运行Oracl e 9i Wmdows版，用来模拟中心数据库；一台安装RedHat

Li nux 9．0，运行Oracl e 9i Li nux版，用来模拟协作数据库。

系统开发环境安装Wi ndows 2000 Professi onal 、Oracl e 9i Wi ndows版客户端和

WAD。WAD包含程序开发和调试运行的所有环境，可以直接在开发环境中调试程

使用WAD开发Web服务程序的Java类，开发Web页面需要启动WAD内置

服务器运行Savanna平台，Savanna平台是一个基于Web的页面开发工具，在该平

台上可以设计页面布局，设置Web服务和页面控件的数据绑定刚。图5．1展示了

在Savanna平台创建职员录入页面(empl oyee ent ry

　　5．3系统测试

系统运行于WAD内置服务器中，可以使用WAD的调试工具调试Web服务

单步跟踪每条Java语言的执行。图5- 5展示了职员管理的调试：

t“q‘■⋯⋯ⅡJ【

醉⋯”⋯弘1掣牌’?‘j ?_”：等。

m=! 黑，’”掣?⋯4鼍唑⋯。1等1冀’，叫’“。=“。?辱

在客户端，可以使用特殊参数查看服务返回的数据结构。在每个页面后面增

加参数cocoon- vi ew=cont ent 即可看到返回数据结构。图5_6展示了职员查询页面

圈5- 6页面察看服务返回值

通过页面查看方式，可以看到服务设计参数结构及对应数据，显示的结构形

式就是DOM对象的结构形式，通过这种方式查看，当要读取一个节点数据时，可

以清晰地查看到该节点路径。

　　5．4测试的分析

从上面的结果可以看出，使用基于SOA的框架开发出来的系统，使用Web服

务实现业务逻辑功能，在调试和性能检测方面非常方便，特别在跨平台开发中使

用标准浏览器，即可完成调试与测试。

另外，对于使用Java语言的Web服务开发，在不同平台里实现也非常方便，

在这里就不详细介绍了，客户端程序的调试与开发需要考虑Web服务调用和响应

的协调，在Web服务调用中要根据传输数据量的大小和接收格式决定使用同步或

　　5．5小结

本章介绍了系统开发和测试中遇到的一些问题，然后对实现的Web服务测试

提供了可行和简便的方式，得到了较为满意的结果，最后对所得到的测试结果进

本文研究了轻量级SOA框架在信息系统中的应用。由于普通的B／S或C／S系

统在实际的应用中，对同一平台下或不同平台下的数据难以整合，造成了现实中

信息“孤岛”的形成。SOA的出现，为解决系统之间的整合给出了应用的指导方针；

目前，在实际应用上很难找到一个开发和部署的复杂度和难度都适中、应用成熟

的SOA框架。所以，本文中引入Servl et 技术和XML技术，参照SOA原则，实

现了一套轻量级的SOA框架，在信息系统开发和部署上可以达到简便、快速，可

以实现信息系统的所有功能。经过初步测试，效果较为满意。

本文完成了如下工作：

1．针对当前SOA缺少成熟的系统框架，本文研究了使用Servlet技术和舭

技术实现的一个轻量级SOA框架，使用XML文件配置、发布Web服务，减少了

部署服务注册中心的繁琐步骤。

2．应用三层服务模型实现业务模块服务：服务接口层、业务组合层和数据访

问层，实现了粗粒度Web服务。各层分工明显，当系统需要移植到N层系统中时，

把服务接口层替换，既可插入到新的Web服务体系统；把数据访问层替换，可以

很方便插入专用的数据访问层或持久化层。

3．针对传统单一的系统密码安全验证，在系统安全验证中，使用了普通加密

密码验证和XML数据解析验证相结合的技术，实现了在页面级数据访问控制；在

两层验证中，保证了数据访问的授权的有效性。

4．针对普通Web服务的返回数据多样性和数据绑定的复杂性，考虑到跨平台

的应用，使用XM：L字符串格式封装了所有数据。在不同平台上，都可以实例化成

DOM对象，应用于现有的客户端工具中，可以很容易解析所有数据，快速绑定到

5．在传统报表控件中，固定的数据输出格式和配置，限制了报表输出的多样

性。本文研究使用Servl et 技术实现了报表控制器，通过XML．文件中的配置参数

和调用参数指定报表输出格式，为报表Web方式下打印和保存提供了简便方式。

6．对整个框架和系统进行了初步的测试，得到了较为满意的结果。

【1】申德荣，于戈，等．应用于Web服务合成的一种有效的W曲服务发现策略田．

小型微型计算机系统，2005年10月，V01．26，No．10：1803—1806．

【2】Don Box, AGui de t o Devel opi ng and Runni ng Connect ed Syst ems wi t h Indi go，

http：／／msdn mi crosoft．corn, 2002．

【3】Greg Fl urry．ESB i n Practi ce．http：／／www- 128．i bm．corrddevel operworks／, 2003．

【4】Documentati on Cent er HomPage．http：／／www．sun．corn．

【5】柴晓路，梁宇奇著．W- eb Servi ces技术、架构和应用【M】．北京：电子工业出版

【6】杨昌锋，王冠，司建辉，等．基于SOA构建新一代的企业应用集成【J】．计算机

应用与软件．2005年10月，V01．22，No．10：122—124．

【7】Wi l l i am Moore，Corvi l l e Al l en, Ral f Bracht ，Sook Chua．Managi ng Informat i on

Access t o

al l Ent erpri se Informat i on Syst emUsi ng J2EE and Servi ces Ori ent ed

Archi tecture[M]．U．S．：Internati onal Busi ness Machi nes Corporat i on, 2005．

【8】单世民，邓贵仕，何英吴．基于消息驱动的分布式协同计划系统的设计与实现

闭．计算机应用，206年1月，V01．26，No．1：84—88．

【9】【美】James Snel l 著，胡军译．SOAPWeb服务开发咖．北京：中国电力出版社，

　　2002。

【to] xNm1．o，Extensi bl e Markup Lauguage(Thi rd Edi 矗on)【s】．http：I／www．w3．otg／TR／2004／REC-

xml ．20040204／．

【11】刘洋，魏飞著．精通／Boss- - E／B与Web Servi ces开发精解【M】．北京：电子工

业出版社，2004．’

【12】汪伦伟，廖湘科，王怀民．认证可信度理论研究闭．计算机研究与发展，2005年

3月，V01．42，No．3：501．506．

【t3] q匕海．全电子支付系统的设计．中国科技论文在线[ EB／OL] ．http：I／www．papex．

eAu．cn／process／downl oad．j spTfi l e=200603-460，2006—04-10．

[1 4】Xi u- Li Sun, Wen- YmZhang, Ji n- Zhao Wu．Event—Based Operat i onal Semant i cs

and a Consi st ency Resul t

Real · Ti me

Concurrent

Processes wi t h Act i on

Rufi nement[J]．Journal

of Comput er Sci ence and Technol ogy, November 2004，

19(6)：828—839．

【1 5] 杨朝君，杨乃定，张亚莉，等．基于模式复用的业务建模研究叨．计算机应用，

2005年11月，V01．26，No．11：113．117．