文档库 最新最全的文档下载
当前位置:文档库 › 跟我学J2EE 系统构架和设计模式——面向服务架构(SOA)及应用示例

跟我学J2EE 系统构架和设计模式——面向服务架构(SOA)及应用示例

跟我学J2EE 系统构架和设计模式——面向服务架构(SOA)及应用示例
跟我学J2EE 系统构架和设计模式——面向服务架构(SOA)及应用示例

1.1跟我学J2EE 系统构架和设计模式——面向服务架构(SOA)及应用示例

1、目前企业应用系统所面临的问题----“信息孤岛”和“应用异构”

(1)信息孤岛

随着信息技术的迅速发展,我国信息化建设取得了显著的成果,各个政府部门和企业的信息化建设日趋完善,但与此同时,建设过程中潜在的一些问题逐渐显露出来,“信息孤岛”就是其中一个很大的问题。

“信息孤岛”的存在,使企业和政府的大量信息无法共享,业务无法协同,造成了信息资源的极大浪费以及信息化的重复建设。

同时也为解决B2B 以及EAI (企业应用集成)等方面的问题带来障碍。

(2)如何解决政府与企业内的各个“信息孤岛”之间的互连互通问题

为了解决政府与企业内的各个“信息孤岛”之间的互连互通问题,B2B 以及企业应用集成(EAI)一直是IT界的热点问题。传统的EAI的集成方式可以将不同的应用系统联系起来,但由于没有统一的标准和方法导致系统之间的连接是紧耦合的,在系统变化或部署新的应用时,需要对原来的系统进行变更或重新开发,集成的代价非常高。

(3)企业级的应用程序是异构的

企业级的应用程序开发者都知道,企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来,而这种集成将花费很大的开发力量。

应用程序经常需要从运行在IBM主机上的程序中获取数据;或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上,不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service,应用程序可以用标准的方法把功能和数据“暴露”出来,供其它应用程序使用。

【导读】

早在1996年,Gartner最早提出SOA的预言,2002年12月,Gartner又提出了SOA是“现代应用开发领域最重要的课题”,并预计到2008年,SOA将成为占有绝对优势的软件工程实践方法,主流企业现在就应该在理解和应用SOA开发技能方面进行投资。

2、SOA产生的技术背景

(1)组件编程技术

我们知道,最早软件开发方法就是编程、写代码的,其缺点在于无法复用,为此提出了组件化的软件开发方法,通过把编程中一些常用功能进行封装,并规范统一接口,供其

它程序调用,例如我们开发一个新软件,可能要用到组件1、组件2、组件3,那么,我们只要对其进行本地组装,就可以得到我们想要的应用软件。

(2)SOA是对组件技术的进一步发展

在互联网得到普及重视之后,软件开发方法在构件化基础上又有新发展,核心思想是软件并不需要囊括组件,所需要的仅仅是组件的运行结果,例如编写一个通信传输软件,就可以到网上寻找组件,并提出服务请求,得到结果后返回,而不需要下载组件并打包,这就是现在所说的SOA。

想要现实SOA,就要规范组件接口,同时还要规范组件所提交的服务结果,如此,新的软件开发的思想才能够行的通。

但SOA并不是一个产品,而是一种思想方法,而实现这种方法的基础,如今看来只有中间件。

3、面向服务架构------SOA 架构(Service-Oriented Architecture)

(1)SOA采用了很多业界所共同遵守的标准或规范

面向服务架构SOA是最近两年新提出的解决应用系统互联互通的一种新架构和新思想,SOA采用了很多业界所共同遵守的标准或规范,这种设计架构即将成为软件应用系统集成的主流架构。

(2)SOA 既不是一种语言,也不是一种具体的技术,它是一种新的软件系统架构模型它是一个基于标准的,松散耦合的,灵活性和扩展性非常高的平台,适合于对企业组织的各种异构系统进行整合,并为以后开发的各种面向服务的应用提供自动的集成,当企业的业务需求有变化时也不需要对原来的系统进行改造,真正达到“按需互连”的效果。(3)SOA 定义了一系列详尽的体系规范、范例和实现应用程序间进行松散耦合交互的最佳准则。

4、什么是基于SOA的架构

(1)SOA本身就是一种面向企业级服务的系统架构

简单来说,SOA就是一种进行系统开发的新的体系架构,在基于SOA架构的系统中,具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是Service)组合构建起来的。

(2)SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性

业务灵活性的目的

业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到

竞争优势的能力。对企业级架构设计师来说,创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。

SOA框架的特点

它是以服务为中心,它把应用程序划分成具有明确定义接口的模块,从而得到服务和应用程序之间相当松散的耦合。

(3)利用基于SOA的系统构建方法

右图中所示的一样,一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中,我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统,而这些功能模块就是SOA架构中的不同的服务(Service)。

(4)基于SOA的系统构建的一些基本要求

1)SOA 基于定义明确的接口,促进多个应用程序间的松散耦合交互

2)服务的实现是独立的,且不依赖上下文信息以及其他服务的状态

3)服务间数据交换主要基于文本类型的格式,使用基于标准的消息模型。

4)服务自身并不知道服务提供者和服务消费者之间传输级的通讯交互。

(5)面向服务的架构的优点主要体现在以下几个方面

1)降低应用开发费用和维护费用。

2)增长公司敏捷性。

3)生成对应用程序和设备的故障、中断更具免疫力的系统,提高整体的可靠性。

4)提供了一条应用系统的升级途径,对比使用单一的应用程序的时候,需要替换整个

应用系统的标准升级方法,显然更为经济,更不容易失败

5、如何使应用系统满足上面的SOA的要求

(1)系统中的各个主要的功能组件设计为WebService组件

SOA可以通过很多方式来实现,但最常用的SOA是用Web Service来实现,这主要应为Web Service的独立于平台的特性和其它特性更符合SOA 的规则。

(2)明确定义服务具有的接口(合约)是SOA 的核心定义

1)普通对象概念的接口包括:数据类型、期望的输出、必需的输入和错误信息。

2)SOA的合约扩大了接口的概念,包括:

所提供的功能

需要的输入和期望的输出、

先决条件(服务激活前存在的输入或者应用程序的状态,最常见的输入是安全口令)后置条件(请求被处理以后服务的状态。比如服务作为某个事物的一部分来调用的,

这时候服务必须接到事务协调者的通知后才能完成这个事物的提交。)

错误处理和服务品质保证(包括诸如:性能、多线程、容错之类问题的描述)等。(3)实现远程业务访问时的系统集成

6、SOA 最主要的应用场合

SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是:

(1)大量异构系统并存,不同计算机硬件工作方式不同,操作系统不同、编程语言也不同;(2)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定;

(3)无法完成服务(service)的版本升级,甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

7、SOA 架构的典型特性

(1)松耦合性---以消息传递作为其通信方法

要求SOA 架构中的不同服务之间应该保持一种松耦合的关系,也就是应该保持一种相对独立无依赖的关系。

(2)位置透明性

要求SOA 系统中的所有服务对于他们的调用者来说都是位置透明的,也就是说每个服务的调用者只需要知道他们调用的是哪一个服务,但并不需要知道所调用服务的物理位置在哪里。

(3)协议无关性:要求每一个服务都可以通过不同的协议来调用。

通过这些SOA 架构所具有的特性我们可以看到,SOA 架构的出现为企业系统架构提供了更加灵活的构建方式,如果企业架构设计师基于SOA 来构建系统架构,就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性,这都为未来企业业务逻辑的扩展打好了基础。

8、Web Service和SOA之间的关系

(1)SOA看成一个架构模型

(2)Web Services是一种技术平台

它可以实现SOA,但也存在其它的实现选择,只不过WebServices是现在实现SOA的最流行最合适的选择----它是目前实现SOA应用的一项基本的,适用的技术,它为服务的访问提供了一个被广泛接受的开放标准。

Web服务已经成为一种实现面向服务的体系结构的标准方法。

9、SOA与OOP在应用上的不同点-----SOA 原则与面向对象范式、原则有着显著不同

主要不同在于SOA的服务间交互的接口被定义了更多面向数据的行为。一个孤立的服务也许会采用面向对象原则和技术,但是,服务之间的交互很少采用这些手段。

相反,这些接口更适合于基于文档的交换。面向对象的行为是绑定数据,而面向服务从行为中分离数据。

10、构建SOA 基准基础的核心原理

(1)服务是可重用的——不管是否存在立即重用的可能性,服务都要设计为支持潜在的重用。

(2)服务共享一份正式协议——为了使服务能够交互,它们只需要共享一个定义了信息交换术语和其他服务描述信息的正式协议协议。

(3)服务是松散耦合的——服务必须设计为在松散耦合的基础上进行交互,并且它们必须

维护该松散耦合状态。

(4)服务将底层逻辑抽象化——服务唯一对外可见的部分是通过服务描述所公开的内容。在该描述中没有表示的底层逻辑是不可见的,并且与服务请求方没有关系。

(5)服务是可组合的——服务可以组成其他服务。这允许逻辑以不同的粒度级别表示,并促进了抽象层的可重用性和创建。

(6)服务是自治的——由服务管理的逻辑驻留在一个显式边界中。服务在该边界内具有完全的自治权,而不依赖于其他服务来执行这种管理。

(7)服务是无状态的——不应该要求服务来管理状态信息,因为那样就会妨碍它们保持松散耦合的能力。服务的设计应该在最大程度上实现无状态性,即使这样做就意味着在其它地方拖延状态管理。

(8)服务是可发现的——服务应该使它们的描述可以被人们和服务请求方发现和理解,以便服务请求方可以利用它们的逻辑。

这八条当中,自治性、松散耦合、抽象和需要正式协议可以视为构建SOA 基准基础的核心原理。

11、构建SOA架构时应该注意的问题之一:SOA系统中的服务粒度的控制

(1)SOA中服务粒度

在SOA中服务粒度有两种相关的意思,即服务是如何实现的,服务使用和返回了多少数据或多少消息。

1)细粒度服务执行了最小的功能,发送和接收少量的数据。

2)粗粒度服务执行了较大的业务功能,并交换了更多的数据。

(2)SOA系统中的服务粒度的控制是一项十分重要的设计任务

通常来说,对于将暴露在整个系统外部的服务推荐使用粗粒度的接口,而相对较细粒度的服务接口通常用于企业系统架构的内部。

从技术上讲,粗粒度的服务接口可能是一个特定服务的完整执行,而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。

举个例子来说,对于一个基于SOA架构的网上商店来说,粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作,而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务,比如说创建购买记录,设置客户地址,更新数据库等一系列的操作。

(3)建议使用粗粒度服务接口作为外部集成的接口

虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性,但同时也意味着引入较难控制的交互模式易变性。也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口给系统的外部用户,就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。

而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然面向服务的体系结构(SOA)并不强制要求一定要使用粗粒度的服务接口,但是建议使用它们作为外部集成的接口。通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。

12、构建SOA架构时应该注意的问题之二:无状态服务的设计

(1)SOA系统架构中的具体服务应该都是独立的、自包含的请求

SOA系统架构中的具体服务应该都是独立的、自包含的请求,在实现这些服务的时候不需要前一个请求的状态,也就是说服务不应该依赖于其他服务的上下文和状态,即SOA 架构中的服务应该是无状态的服务。

当某一个服务需要依赖时,我们最好把它定义成具体的业务流程(BPEL)。

(2)具体的实现方法

我们就可以将无状态的Session Bean暴露为外部用户可以调用的到的Web服务,也就是把传统的Session Facade模型转化为了EJB 的Web服务端点,这样,我们就可以向Web 服务客户提供粗粒度的服务。

由于几乎所有EJB 容器都提供了对无状态会话Bean 群集的支持以及对无状态Session Bean 池与资源管理的支持,使Web 服务能够有效地响应多个客户请求。

13、SOA的特性说明

(1)SOA 有以下特性

1)服务具有明确的接口(合约)与策略。

2)服务通常代表业务功能或者领域。

3)服务拥有模块化的设计。

4)服务被松散的耦合在一起。

5)服务是可以被发现的。

6)服务的位置对客户是透明的。

7)服务是独立于传输层的。

8)服务是独立于平台的。

SOA可以通过很多方式来实现,但最常用的SOA是用Web Service来实现,这主要应为Web Service的独立于平台的特性和其它特性更符合SOA 的规则。

(2)服务具有明确的接口与策略

明确定义服务具有的接口(合约)是SOA 的核心定义。合约应该包含两部分内容,一个是接口,另一个是业务策略。

(3)普通对象概念的接口包括:

1)数据类型。

2)期望的输出。

3)必需的输入。

4)错误信息。

(4)SOA的合约扩大了接口的概念,包括:

1)所提供的功能-----确切说明服务允许完成什么。

2)需要的输入和期望的输出----服务期待什么样的输入以及它能提供什么样的输出,

对客户来说这是一个重要的信息。

3)先决条件。

◆后置条件。

先决条件:服务激活前存在的输入或者应用程序的状态,最常见的输入是安全口令。

后置条件:请求被处理以后服务的状态。比如服务作为某个事物的一部分来调用的,这时候服务必须接到事务协调者的通知后才能完成这个事物的提交。

服务如何应对错误是绝对的后置条件,系统出错以后不同的错误系统应该是什么状态,这点必须写清楚。

◆错误处理

错误处理是另外一个需要在合约中说明的领域,从UML的观点来看,错误是一个通道,所有错误都不返回参与者所期望的价值产品。

客户需要知道描述错误的数据结构或者其它信息。

◆服务品质保证等。

服务品质(QoS)是可选的,但确是合约的重要组成部分,因为消费者很大程度上可以根据提供者提供的服务水准,来选择它们的提供者。

服务品质包括诸如:性能、多线程、容错之类问题。

4)注册表

注册表(Registry)把所有的东西联系到了一起,它是服务保存信息和登记信息的地方,也是消费者找寻和履行合同的地方。

注册表这个术语有很多意思。一个注册表可以为消费者提供一个指定的查询标准,来查找合约的机制。然后消费者将和服务联接在一起。

注册表可以由企业、独立来源、或者需要提供服务的其它业务组织来维护和提供,所有的注册表都需要实现允许独立登记,让消费者查找服务提供者并且和它们连接的应用程序编程接口(API)。

注册表是把消费者和服务方分离开来的核心机制,这种分离允许SOA增加需求能力,并且提供连续可用的服务。

注册表并不一定需要包含合约,注册表可以包括提供者所提供的服务以及合约地点的描述信息,这样可以允许提供者在本地维护自己的合约,这样也可能更加方便。

(5)服务代表业务领域

服务可以用来建立各种各样的问题的领域,即可以是企业领域,也可以是技术领域。

SOA真正的能力,在与可以为企业领域建模,因为业务服务通常比技术服务更加难以实现,无论对内和对外都更加有价值,所以SOA真正持久的价值在于建立一个重要业务过程的服务。

(6)服务拥有模块化设计

服务由模块组成,模块花设计对SOA来说是很重要的,模块可以被看作是一个执行具体、明确功能的软件和子系统。

模块应该表现为高的内聚性,而且是完整的功能。

粗粒度做法是构造一个完整的转账模块,这种模块提升了系统性能,但减少了可重用性。但是,SOA通过网络实现服务,网络拥挤可能是主要矛盾,因此,SOA推荐的是粗粒度设计。这点非常重要。

(7)服务应该松散耦合

服务客户和服务提供者之间应该实现松散耦合,也就是客户和提供者之间没有静态的、编译时刻的依赖关系。

服务把它履行职责的细节隐蔽起来。

这种隐蔽,几乎大部分资料都是建议主要通过GoF 的外观模式(Facade)实现。(8)服务应该是可以被发现并且支持内省的

SOA的灵活性和可复用性另外一个关键点,就是动态发现和绑定的概念。

服务和客户之间没有任何静态连接,SOA客户通过注册表来查找它们想要的功能,而不是使用编译的时候静态连接。因此,服务和客户都可以自由修改。

服务还可以在一个有限的时间内被提供,这就是说它们可以被租借,当客户超过有效时间以后,将会被迫转回到注册表,重新绑定合约或者选择另外的合约。

(9)服务是独立于传输机制的

客户使用网络来访问和使用服务,SOA 应该独立于访问服务的网络种类,服务独立于用来访问他的传输机制,意味着需要建立一个适配器来支持访问它的各种传输机制。通常情况下,适配器需要根据情况来构造(HTTP或者RMI),同一个适配器,也可以被多个服务所使用。

(10)服务的位置对客户是透明的

服务的位置对客户透明,实施上表达了客户调用服务的时候,并不需要关心服务具体的位置。这就使SOA在实现过程具有巨大的灵活性。服务可以被放到最方便的地方去,必要的时候(比如企业整顿),服务业可以放到第三方提供者那里。或者服务中断的时候,可以把服务请求转发到完全不同的另一个地点。

(11)服务应该是独立于平台的

服务应该独立于平台和操作系统。

对于Web 服务来说,虽然在理论上,Java和.NET使用着相同的协议和标准,因此,进行互操作是没有问题的,但实际上,由于SOAP、协议中有很多模糊和未定义部分,所以,这之间的互操作还是存在不少问题,需要我们认真加以研究和试验。

1.1.1WebService的应用案例---Web Service技术在出入境信息查询中的应用

1、引言

(1)要求实现一个高效的信息查询系统

随着我国改革开放力度的加大,出入境人员越来越多,个人证件也越来越多,为了对出入境人员证件的有效性更好地进行管理

境人员证件的快速有效查询是公安部出入境管理部门的一项重要工作,对维护国家安全和社会政治稳定,保障正常的出入境管理秩序起着非常重要的作用。

(2)原有的出入境信息查询系统的缺点

原有的出入境信息查询是直接通过公安部出入境管理局的信息查询平台进行查询。这种查询方式有以下缺点:

1)/

统之间的切换,使用起来非常不方便。

2)性能差。现有的查询系统是通过信息查询平台直接连接后台的数据库,这就意味着

每次都要进行数据库的连接和释放,这样使得数据库的开销加大,从而导致性能降低。

3)直连数据库就使得数据库的用户/口令在客户端,安全可靠性差。

4)查询效率低。平台和系统之间的切换,查询条件的反复输入,直接导致了人员的验

放时间加长,查询效率降低。

2、改进的技术方案

(1)可行的两种技术实现方案

由于原有查询系统的以上缺点,随着出入境人员的数量增多,提高验放效率就迫在眉睫。如何才能提高验放效率,目前大体有两种方案:

一是在各个验放口岸建立地方数据库,部中心将所有数据定时下发。建立地方数据库会使得系统的软、硬件成本增加,资源浪费,同时部中心要定时下发数据也会造成大量的网络资源没必要的占用,所以这种方案可行性不高;

二是利用WebService技术提供服务接口,由验放口岸自行调用,这种方案不仅提高了验放系统的灵活性,节约成本,而且保证了数据的一致性。

(2)新的查询系统利用WebService技术将验放系统与查询系统很好地融合在一起该实现方案无需进行系统切换,也无需输入查询条件,同时WebService技术是通过连接池来连接数据库,提高了数据库的使用效率,增强数据库的使用性能,使得查询时间缩短,从而缩短了验放等待时间,克服了原有查询系统的缺点。

3、WebService组件中的方法

由于查询的护照信息包括护照的基本信息和照片信息,所以WebService实现了两个方法:从数据库中取照片getUserPhoto()和取文本信息getUserInfo (),传入参数为护照号码。

相关文档