基于Java的SOA分层研究与设计*

徐遇霄

(武汉市长虹桥37-1号 武汉 430064)

1 引言

霍金曾说:复杂性是21世纪的科学。当代对复杂系统的研究也表明,复杂性是由简单性进化而来的。那么,我们如何将复杂的难事变为简单的易事?对一般的复杂问题,将其分割为简单的横向子问题,就可以达到效果。对于更加复杂的问题,则需要在横向子问题分割的基础上,实行纵向分层。纵向分层也是一种抽象的分解复杂问题的方法。现在,一个软件系统,往往是一巨型复杂系统。对于这种复杂系统的分析与实现,分层理论认为,降低其复杂性与提高效率的最好办法是将系统分层实现。从软件研究和开发的发展历史、现行软件的体系结构来看,分层方法一直都是软件研发普遍适用的基本的思想方法。因此,在软件体系结构中,把层次性系统作为架构风格,应用的相当广泛。

2 SOA的分层研究

SOA的主要特点之一是平台中立,平台中立的Java Web服务技术是构建SOA系统一种很自然的选择。在Java世界中,J2EE多层架构是一个典型的分层体系,同样,基于Java的SOA系统也可采用分层模型。SOA有3个角色,其中服务请求者是服务的最终消费者,它对服务进行应用,则位于SOA的顶层-应用层。服务注册中心负责服务的注册,以便请求者能发现服务,在一定程度上履行了服务接口的功能。服务提供者构建实现服务的业务逻辑,部署服务并提供调用服务的环境。业务逻辑都由业务组件构成,业务逻辑层应该是独立的一层。业务组件需要部署为服务,并要提供服务的描述以及调用服务的环境,请求者才能消费服务,因此,在应用层与业务层之间,可定义服务接口层,以实现业务层到应用层的平滑过渡。业务层一般要访问数据库,但不是直接访问,可通过一个中间层来进行。中间层的作用是屏蔽访问不同数据库的差异,使数据库对业务层是透明的。因此,数据库位于系统的最底层,而业务层与数据库之间的中间层可定义为数据接口层。至此,基于SOA的应用系统从上到下可划分为如下5层:应用层、服务接口层、业务层、数据接口层和数据库层,如图1所示。

图1 基于Java的SOA分层架构

服务接口层为应用层调用服务提供标准化的接口,从而使得该服务可提供给任何异构平台和任何本地或者远程用户使用。

业务层主要提供系统的业务逻辑和控制,由一些基本的组件构成。

数据接口层为业务层提供统一的访问数据库的方式,以屏蔽业务层访问不同数据库的差异。

数据库层完成数据的持久化功能。它提供了数据信息和数据逻辑,所有与数据有关的安全性、完整性、数据的一致性、并发操作等都在数据库层。

数据接口层和数据库层统称为数据层。

3 数据层的设计

1)数据实体类的设计

在数据接口层的上一层业务层中,对数据的操作体现在业务管理类和业务处理类与业务数据类的交互。业务数据类是数据实体类的一部分。为了使业务层以一致的方式处理数据,首先,数据实体类应该采用一致的数据表示方式。在业务层中,所有的数据都由数据实体类来统一表示,这些类是基本的JavaBean,被称为POJO或ValueObject,只有属性和Get/Set方法,其作用就是供业务类使用,是业务类操作的对象。为了增强程序的可读性并方便记忆,可将类的名称定义为与表名相同,将类中的属性名与表的字段名定义相同。这些数据类与数据库进行映射,一般将数据实体类的属性映射为数据库中对应表的字段,非原子属性则映射为表,这种映射关系通常由一个XML映射配置文件来完成。由于基于XML文本的配置文件可以灵活的改变,因此提高了系统的可移植性及易维护性,同时也在数据层体现了系统的松耦合性。

2)持久化技术的选择

目前,在基于Java的程序设计中,常用的主要有以下几种持久化技术:

(1)BMP(Bean-Managed Persistence),即Bean本身管理持久化。这种方式由在Java组件中嵌入JDBC代码来实现,显然,这是一种紧耦合的方式。

(2)CMP(Container-Managed Persistence),即容器管理持久化,表示由EJB容器来管理实体EJB的持久化。EJB容器封装了对象/关系的映射及数据访问细节。这是一种框架化的持久性机制,在这类机制中,由框架调用业务处理的类。这种机制的一个特点就是它提供一个管理环境,在这个环境中进行对象持久化。一旦离开这个环境,代码就不能运行了。并且,理解并使用EJB的规范也不是很轻松的事情。

(3)JDO(Java Data Objects),Sun公司制定的描述对象持久化语义的标准API。严格的说,JDO并不是对象/关系映射接口,因为它支持把对象持久化到任意一种存储系统中,包括关系数据库、面向对象的数据库、基于XML的数据库,以及其他专有存储系统。由于关系数据库是目前最流行的存储系统,许多JDO的实现都包含了对象/关系映射服务。JDO的出现似乎有了一些改观,但是,JDO没有一个好的开源免费实现。好的产品一般都是商业产品,并且在国内没有销售和技术支持。JDO也不是一个轻量级封装,它建立的持久层框架很不完善,造成了JDO感觉比较笨重,使得很多操作方式很是烦琐,JDO的应用在人们心理上一直布满阴影。

(4)Hibernate,轻量级的开源ORM模型。它的一大优势就在于可以把被持久化的对象实现成脱离这个持久化环境依然可以运行的类。Hibenate利用XML文件将应用程序的数据实体类与数据库中的表进行映射,并通过框架的内部机制对复杂的数据操作提供支持,包括记录的添加、修改和删除等操作。因此,在基于Java的程序设计中,Hibernate成为持久层流行的框架技术,而它对于构建基于SOA的应用系统,也无疑是一个很优的选择。下面简要介绍Hibernate的原理。

Hibernate是一种比较彻底的Java对象关系映射工具,支持使用各种Java思想,如Inheritance(继承),Association(关联),Composition(组合),Collections(集合)等来实现对象关系映射。它可以直接映射大部分的POJO型的JavaBean,而不需要对它们作任何修改,即使需要修改,最多只在Bean里面加上一些私有访问方法。它还可以将一个用户定义的多个类的实例映射到一张表的同一行,甚至可以利用代理模式来简化载入类的过程。这些功能都大大减少了利用HQL从数据库提取数据的代码编写量,从而节约开发时间和开发成本。Hibernate利用Reflection机制,在系统启动时生成SQL语句,进行对象的持久管理。Hibernate对每一种数据库都有对应的Dialect进行操作优化,从而提高它在各种情况下的效率。

图2所示 Hibernate的持久化服务在一个数据库应用中的作用:应用程序通过

图2 Hibernate持久化原理

Hibernate 连接到数据库,对数据进行操作。Hibernate自身通过Properties或类的映射文件(Mapping XML)将数据实体类映射到数据库的行。因此Application可以通过持久化的数据类直接访问数据库,而不必使用JDBC和SQL进行数据的操作。

Hibernate具有很大的灵活性,界于它的最大模式和最小模式之间的某些功能构件是可选的。在最小模式下,可选择使用JDBC,可以利用JTA管理自己的事务,也可以使用JNDI。这时Hibernate通过 SessionFactory提供 Session,在 Session中对持久化对象进行操作。在最大模式下,Hibernate在自己的底层管理 JNDI、JDBC和 JTA,在上层向外提供 SessionFactory、Session和 Transaction的接口,供 Client控制Persistent Object之用。

3)数据库访问的设计

(1)数据实体类与表的映射

Hibernate定义了类到数据库的基于XML的映射文件。映射文件中的“class”元素定义了需持久化的类与数据库中表的映射关系,“name”属性指定了类名,而“table”属性指定了数据库中的表。“id”元素定义了键属性。“property”元素定义了类的属性与表中字段的映射。具体的映射文件可见后文的实现部分。

(2)配置 Hibernate

配置Hibernate通过设置其配置文件来完成。该文件描述了数据库的驱动程序以及数据库的URL等连接数据库的信息。Hibernate在应用程序启动时自动进行初始化工作。配置描述文件可以是hibernate.cfg.xml或 Hibernate.properties文件。

Hibernate对JDBC进行了封装,自动进行JDBC连接,并使用SessionFactory来打开数据库的连接。使用Hibernate时,我们可以提供外部连接池,亦可配置Hibernate使用它自己直接支持的池(C3PO,Proxcool)。Hibernate可以根据用户的数据库设置一个正确的hibernate.dialect语言。它支持 Oracle、Ms SQL、My SQL 、DB2等多种语言 。Hibernate提供的HQL也支持外部连接查询,这些连接类型是从SQL中借鉴来的:inner join(内连接)、left outer join(左外连接)、right outer join(右外连接)、full join(全连接,并不常用)。但外连接也可通过设置Outer-join属性为False来禁止,因为使用它会占用过多的资源。

Hibernate可灵活地设置数据库的驱动程序及数据库的URL。这样,在进行系统设计时,我们可以不去关心底层采用的是何种数据库。加之我们引入ORM技术,使得业务逻辑和数据逻辑分离。在此二者基础上,我们就构建了出一个抽象层—数据接口层。数据接口层的引入一方面增强了系统的灵活性和可移植性,另一方面也体现了SOA的松散耦合性。

(3)使用Hibernate进行数据库访问

Hibernate运用框架模型如图3所示。

图3 Hibernate应用框架模型

其中:*.hbm.xml是数据实体类与表的映射文件,*_Access.class是数据访问类文件,*.class是POJO型的数据实体类文件。

4 业务层的设计

1)业务逻辑的实现策略

我们可以将业务层类分为三大类:业务管理类、业务处理类和业务辅助类,如图4所示。在数据接口层提供的数据实体对象和对象的持久性存储机制的基础之上,就可以将这些对象根据业务需求由业务层的类组合起来,构建系统的业务逻辑处理程序。

图4 业务层类框架图

2)服务粒度的选择

我们可以用服务树来刻画服务的粒度。所谓服务树,是把要部署为服务的功能模块用树型结构来进行表示,如图5网上定购服务树所示。

图5 服务树图

服务树清晰地反映出了服务的粒度,是构建SOA系统时决定服务粒度的有力工具。我们可以利用服务树找到SOA系统最佳的服务粒度方式。

服务接口层通过部署,将业务层的业务管理类暴露为服务,因此,业务管理类所实现的业务逻辑的粒度就决定了系统服务的粒度。SOA倾向于粗粒度的服务,在进行系统之间的通信时,这有很大的优势,因为粗粒度的服务减少了系统之间的交互,提高了系统的运行效率,特别是异构异地的系统之间的通信。但在进行企业内部应用系统之间集成,或系统内部的构建时,粗粒度的服务降低了系统的灵活性,增大了系统的耦合性。所以,我们在构建SOA系统时,要选择一个合适的服务粒度。

5 服务接口层的设计

1)Web服务引擎AXIS

Apache可扩展交互系统(Apache eXtensible Interaction System,AXIS)是在基于可配置的消息链和Handler对象重新设计SOAP的过程中发展而来的。它是基于 Java的、最新的SOAP规范(SOAP 1.2)和SOAP with Attachments规范的开源实现。图6表示了AXIS引擎的基础结构。

图6 AXIS基础结构

AXIS可作为Web服务引擎工作于服务接口层,也可作为服务请求方环境运行于应用层,因此,它是构建基于Java的Web服务的良好选择。

2)使用AXIS部署服务

使用AXIS将业务层的组件部署为Web服务有以下3种方式:

(1)最简单的方式:jws方式

AXIS提供了一种将带有.jws扩展的Java类部署为Web服务的简单方式。它的实质是AXIS将Servlet引擎中的Java Servlet自动部署为Web服务。常用的Servlet引擎是Apache的 Tomcat容器。这种方式以Java类的源文件为基础,部署方法很简单,只须将以.java为扩展名的源文件,重命名为以.jws为扩展名的文件,复制到Axis Web应用程序的主目录中。当该Web服务被访问时,Axis会根据.jws文件自动生成相应的 WSDL及SOAP端点,即自动将.jw s文件部署为Web服务,而无需WSDD部署描述符。这种方式也无需编译该文件,Axis运行库会自动进行类及其所有方法的编译。

获取该服务的WSDL与其它方式相同,只需在访问该服务的URL后加“?WSDL”参数即可,如“http://localhost:8080/axis/HelloWorld.jws?WSDL”。

以.jws文件形式创建Web服务的方法,从简易性及可操作性的角度来看,非常类似于JSP。这种方式一般用于建立单一的或简易的Web服务。

(2)使用WSDD将JSE组件部署为Web服务

以.jws文件部署基于Java的Web服务虽然既简单有快捷,但缺乏服务部署的灵活性,例如,我们需要将JSE组件中的某些方法而非全部发布为Web服务。Axis提供了 Web服务部署描述符(Web Service Deployment Description,WSDD)的方法,可以对Java Web服务进行一些高级的定制部署。该方法需要创建一个部署服务(deployment)的XM L描述文件(*.wsdd)和一个卸载服务(undeployment)的XML描述文件。这些文件将告诉AXIS如何处理对Java Web服务的特定调用。

(3)使用WSDD将EJB部署为Web服务

在开源的EJB服务器(或容器)中,我们选择JBoss公司的JBoss服务器。JBoss集成Axis时,需将Axis文件夹复制到JBoss的部署目录中。另外,我们还要确保Axis能够为EJB载入类文件,方法是将该EJB的.jar包文件复制一份到Axixlib文件夹中。一般情况下,我们使用Axis将JBoss中的无状态会话(Stateless SessionBean)类型的EJB发布为Web服务,目前可采用如下两种常用的方法:

①使用基于EJB的WSDD,这种方式同上述第2种情形大致相似,只是WSDD中有更多的元素来描述EJB,因为EJB相对于JSE,有更多的要遵循的规范。

②使用JBoss的 JBoss.NET模块,用 XML Web服务描述符来部署。JBoss.NET[29]是JBoss集成了Axis后的部署Web服务的一个工具。利用它进行部署工作要依赖于.wsr文件,该文件可视为打包版的Axis的WSDD。.wsr文件是一个标准的.jar文件,仅包含一个名为META-INTweb_service.xml的XML Web服务描述符。

JBoss公司目前正在进行一个被称为“JBoss-WS”的项目,其目标是重构JBoss应用服务器,以使用他自己的SOAP协议栈而不是集成Axis。

6 应用层的设计

应用层客户端在构建用户的业务流程时,一般要先完成调用服务以及基于XML的数据处理两项任务。客户端调用服务大多数情况下是为了进行数据通信。对于服务的请求方和提供方,二者都基于XML的数据格式进行通信,因而在调用服务进行数据通信时,需要将用户关心的数据进行串行化或反串行化(AXIS引擎只自动实现SOAP消息的串行化或反串行化)。所谓串行化数据是指将应用程序的数据格式转换为XML格式,反串行化则反之。根据数据的流向,可分为两种情形,一是通过调用服务向服务提供方发送数据(如图7所示),如向网上商店提交的订单,需要进行数据串行化。

图7 串行化流程

二是调用服务从服务提供方获取数据(如图8所示),如获取商家的产品信息,这与第一种情形正好相反,需要进行数据的反串行化。

图8 反串行化流程

对于第一种情形,客户端应用程序先将数据串行化为XML格式,然后用SOAP协议进行封装,调用服务发送即可。对于另一种情形,客户端一般先接收调用服务所获取的基于XML格式的字符串,然后将其反串行化为用户所需类型的数据。

图9 应用层数据处理架构

客户端在调用服务发送数据,进行数据的串行化之前,需要采集原始数据。而在调用服务获取数据并进行反串行化之后,需要显示数据或进行持久化。因此,应用层除了要进行数据串行化或反串行化外,还需要实现数据的显示或提交逻辑。对于客户端,这一处理逻辑可以基于C/S方式,为用户提供灵活友好的使用界面,进行显式处理,或直接用程序组件隐式处理。客户端亦可基于B/S方式,建立精美的Web页面显示或提交数据。应用层数据处理的架构如图9所示。

7 结语

本文所论述的应用层侧重于服务调用的设计,而没有过多涉及应用系统客户端的具体实现。因为实际上,客户端程序都将调用服务作为函数(或过程)来实现。系统开发人员在构建客户端应用程序时,可以采用B/S或C/S方式,并在其中调用访问Web服务的函数,来构建最终的应用系统。而不论是B/S还是C/S,都已经是很成熟的模型,这两种模型也都有非常成熟的技术可以实现。

作为一个刚刚步入实践的新事物,SOA还面临着很多的挑战。SOA还正处在不断的发展之中,它的成熟度和完善性还有待于研究人员和企业在理论和实践中不断的加以提高和改善。虽然被称为是继面向过程和面向组件的下一代软件体系结构,但目前还没有以上两种架构成熟,且目前的应用才刚刚起步。然而,由于SOA自身具有的优势顺应了未来软件发展的趋势,并随着各大软件供应商在此展开的深入研究和激烈竞争,它必然会成为成熟的下一代软件体系架构和主流开发技术而得到广泛支持和应用。可以预见在未来的几年里,SOA将会取得长足的发展。

[1]胡光.基于Jini的查找服务实现[J].计算机应用研究,2005(2)http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/technical/web_services

[2][美]科耶尔.XM L、Web服务和数据革命[M].袁勤勇,等译.清华大学出版社,2003

[3]蔡月茹,柳西玲.Web Service基础教程[M].北京:清华大学出版社,2005,6

[4]张凯.软件复杂性与质量控制[M].北京:中国财政经济出版社,2005,11

[5]姜璐.复杂系统的层次结构,复杂性研究[M].北京:科学出版社,1993,7

[6]伽玛,等.设计模式:可复用面向对象软件的基础[M].李英军,等译.北京:机械工业出版社,2000,9

[7][美]尼戈潘,等.Java Web服务开发[M].庞太刚,陶程,译.2004,5