引言

在《面向服务体系架构（SOA）和业务组件（BC）的思考》（以下简称《 SOA 和 BC 》）一文中介绍了基于面向服务体系架构（SOA）的组件模型，本文按照“分离”的原则，通过比较当前多种流行的客户端和服务器端的通讯机制，进一步把业务组件进行分离，采用面向资源体系架构（ROA）把业务组件界面层和业务逻辑层分离开，构建一个多终端多技术平台可复用的组件模型。

多层架构中的通讯方式

软件体系架构是沿着单机到 CS 架构，再到 BS 的三层架构甚至多层架构逐步发展过来的，关于多层架构，本文不再详细介绍，可以参考相关的资料，下面首先来分析一下当前比较流行的客户端技术以及客户端和服务器之间的通讯方式。

基于 MVC 的 J2EE 多层模型

在一个标准的基于 MVC 的 J2EE 的模型架构的代码中，从对象的类别来看，一般包含 BO、DAO、POJO 等 Java 类，另外还包含 JSP、Servlet 等，如下图所示：

图 1. 基于 MVC 的 J2EE 多层模型

POJO：简单 Java 对象（Plain Ordinary Java Object，POJO），一个中间对象，在不同阶段可以转化为 PO、DTO、VO，POJO 持久化以后就是 PO，在应用中的不同层次传递为 DTO，直接用来对应表示层就是 VO。

PO：持久对象（Persistant Object，PO），也称为 Data 对象，对应数据库中的 Entity，可以简单认为一个 PO 对应数据库中的一条记录。PO 中不包含任何对数据库的操作。

VO ：表现层对象（View Object，VO）主要对应界面显示的数据对象。对于一个 WEB 页面，或者 SWT、SWING 界面，用一个 VO 对象对应整个界面的值。根据业务的需要可以和表对应，也可以不对应。

DTO ：数据传输对象（Data Transfer Object，DTO） 主要用于远程调用等需要大量传输对象的地方。对象不应该包含业务逻辑，其仅仅需要传递需要的属性，而不是 PO 的所有属性。

BO：业务对象 （Business Object，BO）主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。通常一个 BO 包含多个 PO，通常需要将 BO 转化成 PO，才能进行数据的持久化，反之，从 DB 中得到的 PO，需要转化成 BO 才能在业务层使用。BO 建议只包含业务方法，属性在 POJO 中。

DAO：数据访问对象（Data Access Object，DAO）主要用来封装对数据库的访问。通过它可以把 POJO 持久化为 PO，用 PO 组装出来 VO、DTO。主要用来封装对 DB 的访问，把 POJO 持久化为 PO。

JSP 是通过 HTTP 请求，直接调用 Servlet 的。当前，在 J2EE 架构下，有 Struts 、Spring 、Hibernate 等开源架构完美的实现了界面、逻辑和实例化的操作。

Applet 和 J2EE 的通讯

Applet 可以直接连接数据库，可以使用象 JDBC、RMI 这样的协议来访问象数据库、LDAP 目录和 Enterprise JavaBeans 组件这样的后端信息。也可以通过 HTTP 连接后台的 Java Servlet，和 JSP 连接方式相同，通过 Servlet 处理后台逻辑，Applet 仅仅用来处理前端的工作。

Flex 和 J2EE 的通讯

Flex 是 Macromedia 发布的展现服务 (Presentation Server)，根据 mxml 文件 ( 纯粹的 XML 描述文件和 ActionScript) 产生相应得 swf 文件，传送到客户端，由客户端的解释执行。 Flex 提供了三种方式和 Java 进行数据交互：HTTPService，RemoteObject 和 Web 服务。其中，HTTPService 方式可以传输 Text、XML 或者 JSON (JavaScript Object Notation) 等。由于 Flex 具有 Flash 打下的良好用户基础，同时具有丰富的展现效果，正在成为一种流行的客户端展示实现技术。

AJAX 和 J2EE 的通讯

AJAX(Asynchronous JavaScript and XML) 是多种技术的综合，它使用 XHTML 和 CSS 标准化呈现，使用 DOM 实现动态显示和交互，使用 XML 和 XSTL 进行数据交换与处理，使用 Javascript 绑定和处理所有数据，Javascript 是一种粘合剂使 AJAX 应用的各部分集成在一起，中 JavaScript 主要被用来传递用户界面上的数据到服务端并返回结果。AJAX 使用 XMLHttpRequest 对象进行异步数据读取， XMLHttpRequest 对象用来响应通过 HTTP 传递的数据，一旦数据返回到客户端就可以立刻使用 DOM 将数据放到网面上。在 Ajax 中，XMLHttpRequest 是核心，XMLHttpRequest 对象在大部分浏览器上已经实现而且拥有一个简单的接口允许数据从客户端传递到服务端，但并不会打断用户当前的操作。使用 XMLHttpRequest 传送的数据可以是任何格式，包括可以传输 Text、XML 或者 JSON。

其他客户端和 J2EE 的通讯

除了前文所描述常见的浏览器支持的技术标准，当前富客户端（Rich Internet Applications ，RIA）发展也很快，比较流行的有 AIR、WPF 、JavaFX 等。

AIR (Adobe Integrated Runtime) 是 Macromedia 发布一个跨操作系统运行的 RIA 技术解决方案，利用现有的 Web 开发技术（Flash，Flex，HTML，JavaScript，Ajax）来构建富客户端，并部署为桌面应用程序，其本质上采用的是前述 Web 开发技术和后台通讯。由于 AIR 可以访问客户端的资源，并可以实现离线操作，所有具有广阔的应用前景。

WPF (Windows Presentation Foundation) 是 Microsoft 的 .Net 平台的 RIA 技术解决方案，WPF 通过扩展应用程序标记语言（eXtensible Application Markup Language ，XAML）把界面和业务逻辑分开，以开发出界面炫丽，功能强大的应用程序。WPF 可以通过基于 SOAP 的 Web 服务或者 RESTful Web 服务跟后台 J2EE 服务器交互。另外轻量级的基于浏览器的 Silverlight 可以采用这种技术。JavaFX 是 Java 的 RIA 技术解决方案，和早期的 Applet、 Java Web Start 等技术一脉相承， 其使用的是领域专用语言（Domain Specific Language，DSL），和后台通讯方式同 Applet。

通讯方式总结

如前文所述，客户端和服务器端的通信有很多种，但是有两种是都支持的，基于 SOAP 的 Web 服务和 RESTful Web 服务。

Web 服务是通过简单对象访问协议（Simple Object Access Protocol，SOAP）传输的，SOAP 是一种基于 XML 的协议， 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（ HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME），基于“通用”传输协议是 SOAP 的一个优点。它还支持从消息系统到远程过程调用（Remote Procedure Call， RPC）等大量的应用程序。SOAP 提供了一系列的标准，如 WSRM（WS-Reliable Messaging）形式化契约确保可靠性与安全性，确保异步处理与调用；WS-Security、WS-Transactions 和 WS-Coordination 等标准提供了上下文信息与对话状态管理。

相对而言，SOAP 协议属于复杂的、重量级的协议，当前随着 Web2.0 的兴起，表述性状态转移（Representational State Transfer，REST）逐步成为一个流行的架构风格。REST 是一种轻量级的 Web Service 架构风格，其实现和操作比 SOAP 和 XML-RPC 更为简洁，可以完全通过 HTTP 协议实现，还可以利用缓存 Cache 来提高响应速度，性能、效率和易用性上都优于 SOAP 协议。REST 架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应 HTTP 协议提供的 GET、POST、PUT 和 DELETE 方法，这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST 架构尤其适用于完全无状态的 CRUD（Create、 Read、 Update、 Delete，创建、读取、更新、删除）操作。基于 REST 的软件体系结构风格（Software Architecture Style）称之为面向资源体系架构（Resource-oriented Architecture，ROA）。按照 REST 原则设计的软件、体系结构，通常被称为“REST 式的”（RESTful），在本文中以下称之为 RESTful Web 服务，以便于和基于 SOAP 的 Web 服务区别。

服务器端采用 J2EE，客户端采用 JSP、Flex、JavaFX、AIR 等可以直接调用 Servlet，其他的实现技术基本上不能直接调用，但是无论是那种客户端，对于基于 SOAP 的 Web 服务或者基于 RESTful Web 服务务都是支持的，如 AJAX 的 XMLHttpRequest、Flex 的 HTTPService 等。如下图所示：

图 2. 客户端和服务器端的通讯方式

基于 SOAP 和 REST 的分层模型

结合前文所述客户端和服务器端的通讯方式比较和分析以及在《 SOA 和 BC 》一文中描述的业务组件模型，下文给出了在界面层和业务逻辑层采用轻量级的 RESTful Web 服务，不同业务组件之间采用基于 SOAP 的 Web 服务的业务组件模型。

基于 ROA 的业务组件界面层和业务逻辑层接口

在多层架构下，特别是当前客户端技术发展迅速，有不同的技术实现方式，将界面层和业务逻辑层分离将能更好的实现业务组件的重用，业务逻辑不受不同客户端技术技术影响，从而更好的保证了业务逻辑的重用。为了支持各种客户端技术，需要采用各种客户端技术都能支持的标准的接口方式，在前文所述两种通用标准中，SOAP 相对来讲属于重量级协议，而且基于 SOAP 的 Web 服务将会增加软件开发的难度，影响系统的性能，因此采用轻量级的 RESTful Web 服务务，来实现界面层和业务逻辑层的分离，如下图所示：

图 3. 界面层和业务逻辑层的通信模式

为了保持和基于 SOAP 的 Web 服务方式传输的内容一致，其传输的数据格式均采用标准的 XML，比如传递一个客户信息，基于 SOAP 的 Web 服务传递的参数和 RESTful Web 服务格式分别如下：

清单 1. XML样例

<?xml version="1.0" encoding="gb2312"?>       <CUSTOMER>       <ORG_CODE> 1000 </ORG_CODE>        <CUST_CODE> 100010001</CUST_CODE>         <CUST_NAME>张三</CUST_NAME>      <CUST_TYPE_CODE>11  </CUST_TYPE_CODE>    <CUST_STATUS>01 </CUST_STATUS>  </CUSTOMER>

这样不管是通过基于 SOAP 的 Web 服务和和基于 REST 的 XML，在业务逻辑层，可以通用一个 toString 方法，转换成一个 XML 文件就可以了。最终是采用 SOAP 的 Web 服务还是 RESTful Web 服务，只是通过配置输出不同的协议就可以了。Axis2 可以很好的支持这个架构，Axis2 是一套崭新的 WebService 引擎，该版本是对 Axis1.x 重新设计的产物。Axis2 不仅支持 SOAP1.1 和 SOAP1.2，还集成了 RESTful Web 服务，同时还支持 Spring、JSON 等技术。

清单 2. 生成XML代码示例

public String  toString (){    String strXML=””;   ······;   if (null != orgCode) {   sb.append("<ORG_CODE>");      sb.append(orgCode);      sb.append("</ORG_CODE>");    }  if (null != custCode) {   sb.append("<CUST_CODE>");   sb.append(custCode);   sb.append("</CUST_CODE>");    }   ······;        return strXML;    }

这样业务组件只是提供一个标准的 XML 格式输出，由 Axis2 来管理生成基于 SOAP 的 Web 服务或者 RESTful Web 服务。界面层和业务逻辑层的通讯全部通过 RESTful Web 服务，不管客户端采用什么实现技术，可以重用一个接口。

在业务组件内部可以进一步分层，把协议层和业务逻辑层分离开，不管是采用直接调用 Servlet 还是 REST、SOAP 等，其后台业务逻辑不变，使得业务逻辑更加独立。如果是采用多层架构，如上图所示，其业务逻辑部分的代码甚至可以在单机程序中使用，这样分离之后，可以更方便的对代码进行测试，本文不再进一步详述。

采用 REST 架构，实现界面层和业务逻辑层分离，业务逻辑在业务组件中实现重用，不会因为界面层的变化而引起业务逻辑层面的变化，实现界面层和业务逻辑层的独立升级而不会有大的影响。界面层分离出来之后就可以实现界面开发和业务逻辑开发分开，在界面层可以任意采用基于 BS 架构的的 JSP、HTML（DHTML）、ASP.NET、PHP、Applet、Flex 等，基于 CS 架构的 Java、.Net、AIR 等任何一种界面开发技术，界面层的开发可以由独立的 UI 小组完成，其成员可以不用关心业务逻辑，从而更加专注于人机交互体验的完善。

基于 SOAP 和 REST 的业务组件（BC）接口模型

一个完整的业务组件需要实现松耦合，需要对外提供三种类别的接口：界面、服务、数据。界面主要是实现业务组件和人之间的人机交互媒介，服务是业务组件和业务组件或者系统之间的交互，是信息系统之间的交互媒介，数据是业务组件和共享数据库之间的交互媒介（参见《面向服务体系架构（SOA）和数据仓库（DW）的思考》所述共享库的概念），其中服务根据作用又可以进一步分成三小类：和人机交互相关的服务、和业务组件之间的交换以及和数据库之间的交换。如下图所示：

图 4. 业务组件接口模型

人机交互媒介： 采用 Portlet 标准，对外提供标准的门户程序，通过门户集成平台进行门户集成。对外的门户程序可以以两种方式提供，一种是完全独立的门户程序，可以任意的集成到任何一个独立的门户界面，但是如果所有的界面都定制，考虑到性能和定制工作量比较大，可以采用另外的一种方式，即把多个界面定义到一个门户程序中，可以将一系列的界面在一个门户程序中完成，减少配置以及管理的工作，使得系统更加易于集成。比如可以把客户信息展示作为一个简单的门户程序，仅仅实现客户信息展示，也可以把客户维护，客户信息展示、客户拜访管理、客户分类管理等所有客户相关的信息在一个门户程序中实现，并且在门户程序中以菜单的方式进行选择，相当于是内嵌了一个小的应用功能界面。

Portlet 属于比较重量级的标准，但是由于 Web2.0 尚未统一标准，如果轻量级的 Web2.0 有通用标准之后，采用 Widget 等将会是未来的发展方向。

对于同一一个开发商来说，在内部可以采用自己定制的 Widget 标准方式，包含 Widget 的定义、Widget 之间的数据交互、界面风格设定等。服务接口： 服务接口按照类型可以分为 6 种，其中人交互服务和信息服务比较特殊，，分别实现人机交互和数据交换的功能，是以服务的方式提供人机交互媒介和数据接口内容。

人机交互服务，将人机交互内容以服务的方式提供，通过处理后在界面层次统一展示，通过这种方式，可以实现将不同的业务组件的服务混搭（Mashup）成一个门户程序，而不是通过两个门户程序进行整合。人机交互服务和 Portlet 的差异是采用的标准不同，前者基于 Portlet 标准，后者基于基于 SOA 的 Web 服务或 RESTful Web 服务；前者直接以界面的方式对外提供，后者主要提供数据（可以同时提供展示方式，即一段 HTML 代码），通过前端的定制工具实现界面展示，通过这种方式，在门户系统进行界面整合，将不同系统的数据在界面进行统一展示，比如可以将财务系统的人员工资信息、人力资源信息等分别以服务的方式对外提供，然后在门户的界面整合工具在门户中统一进行展现，而不是通过 Portlet 的方式实现。如前文所述，采用 RESTful Web 服务

业务服务，业务组件为实现的业务组件核型功能的对外相关服务，是业务组件核心服务，主要用于本业务组件和其他的业务组件之间的业务交互，使得多个业务组件或者系统共同完成企业的业务流程。为了保证业务组件的高内聚，松耦合，要合理的规划业务组件对外提供的服务的粒度，即能保持灵活性，又可以保证对外提供的服务不至于太多，不宜管理。业务组件的 web 服务结构是企业业务组件规划中的最为重要的标准化功能，用于确定不同业务组件之间的边界。

主数据服务，主数据相关的服务，是共用的服务，主数据管理业务组件也是属于企业公共服务平台管理范围，是企业级的公共业务组件。

流程服务，涉及工作流程的服务，相关信息提供到工作流引擎，是共用的服务，流程管理业务组件也是属于企业公共服务平台管理范围，是企业级的公共业务组件。

系统管理服务，是由系统管理公共组件提供的服务，主要包含用户认证、权限管理等相关的服务，是共用的服务，系统管理相关业务组件属于企业公共服务平台管理范围，是企业级的公共业务组件。主数据服务、流程服务和系统管理服务是企业架构平台提供的公共服务，是集成平台的核心内容。

信息服务，和数据库相关的服务，直接从数据库获取相关信息。由于业务组件的数据是私有的，为了保证业务组件的数据能够得到更好的应用，需要将业务组件的数据公布出来，基于企业的数据模型，把业务组件的私有数据公开为企业数据中的数据。信息服务可以采用实时、或者准实时的方式对外提供。在某些特殊情况下，可以认为业务组件不存放数据，业务组件仅仅是获得数据，处理数据，然后将数据在放到企业数据库中。

数据接口： 基于视图或者表直接对数据库进行操作，即业务组件对外提供一个直接访问数据库的接口，如果数据库结构是按照这个接口设计的，这个业务组件可以直接访问数据库，而不需要通过其它的服务，需要明确每个组件对表的读写权限，并进行严格管理，通过数据接口的方式，核心是需要建立企业数据架构，建立共享的数据结构。通过数据联邦、数据复制实现。一般来说，不建议这样实现，特别是跨应用的数据访问，尽量通过信息服务实现。

以上通对业务组件模型对外提供的接口类型进行分析，规划了一个业务组件接口模型，所有的业务组件将对外提供以上三类对外的接口。

基于 SOA 和 ROA 的整体技术架构

结合当前流行的 SOA、Web2.0、3G、三网融合等技术，在基于 SOAP 和 REST 的分层模型的基础上，开发的时候采用组件化开发，业务组件和业务组件之间的交互采用基于 SOAP 的 Web 服务作为接口模式，实现组件时间的松偶合，降低组件之间的关联关系，不同的业务组件可以由不同的厂商实现；业务组件界面层和业务逻辑层之间的采用 RESTful Web 服务作为接口模式，实现界面层和业务逻辑层分离，客户端可以采用电脑、手机、电视、各种 POS 机以及各种特殊终端设备，客户端实现技术可以任意采用基于 BS 架构的的 JSP、HTML（DHTML）、ASP.NET、PHP、Applet、Flex 等，或者基于 CS 架构的 Java、.Net、AIR、C 等，在服务器端采用 J2EE 平台实现业务逻辑，构建一个多终端多技术平台可复用的业务组件模型，如下图所示：

图 5. 基于 SOAP 和 REST 的业务组件模型

比如建立一个购物网站，在界面层可以采用 Flex 实现虚拟现实的 3D 技术实现游戏风格的界面，同时实现业务操作，以提高用户的使用体验，使得网站更加有趣味性，更好的黏住用户；或者采用 Flex 控件实现在 CS 架构下才能实现的易用性，让用户在浏览器中能体验到 CS 架构程序的方便。采用 Flex 对于网络的要求比较高，可以采用 JSP 实现基于 HTTP 的传统的网页购物界面和基于 WAP 手机购物界面，网页购物界满足大信息量，快速的数据浏览的需要，用户可以快速完成交易；WAP 手机购物满足无法上网，或者临时无法上网的用户，可以提供基于 WAP 的简单网页浏览，通过手机之间完成购物。

通过以上所述多终端多技术平台可复用的业务组件模型，实现了业务逻辑的重用，并能够灵活适用于各种场景。

总结

通过对 SOAP 和 REST 的对比分析，本文给出了一种基于 SOAP 和 REST 的组件模型，从而给出了了业务逻辑和界面展示分离的方法以及业务组件之间的服务定义。在界面层和业务逻辑层采用轻量级的 RESTful Web 服务，不同业务组件之间采用基于 SOAP 的 Web 服务将会是未来最有生命力的发展方向。

来自： http://www.uml.org.cn/soa/201512292.asp