基于面向服务体系架构SOA和面向资源体系架构ROA的业务组件模型Word文档下载推荐.docx
《基于面向服务体系架构SOA和面向资源体系架构ROA的业务组件模型Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《基于面向服务体系架构SOA和面向资源体系架构ROA的业务组件模型Word文档下载推荐.docx（13页珍藏版）》请在冰点文库上搜索。
表现层对象（ViewObject，VO）主要对应界面显示的数据对象。
对于一个WEB页面，或者SWT、SWING界面，用一个VO对象对应整个界面的值。
根据业务的需要可以和表对应，也可以不对应。
DTO：
数据传输对象（DataTransferObject，DTO）主要用于远程调用等需要大量传输对象的地方。
对象不应该包含业务逻辑，其仅仅需要传递需要的属性，而不是PO的所有属性。
BO：
业务对象（BusinessObject，BO）主要作用是把业务逻辑封装为一个对象。
这个对象可以包括一个或多个其它的对象。
通常一个BO包含多个PO，通常需要将BO转化成PO，才能进行数据的持久化，反之，从DB中得到的PO，需要转化成BO才能在业务层使用。
BO建议只包含业务方法，属性在POJO中。
DAO：
数据访问对象（DataAccessObject，DAO）主要用来封装对数据库的访问。
通过它可以把POJO持久化为PO，用PO组装出来VO、DTO。
主要用来封装对DB的访问，把POJO持久化为PO。
JSP是通过HTTP请求，直接调用Servlet的。
当前，在J2EE架构下，有Struts、Spring、Hibernate等开源架构完美的实现了界面、逻辑和实例化的操作。
Applet和J2EE的通讯
Applet可以直接连接数据库，可以使用象JDBC、RMI这样的协议来访问象数据库、LDAP目录和EnterpriseJavaBeans组件这样的后端信息。
也可以通过HTTP连接后台的JavaServlet，和JSP连接方式相同，通过Servlet处理后台逻辑，Applet仅仅用来处理前端的工作。
Flex和J2EE的通讯
Flex是Macromedia发布的展现服务（PresentationServer），根据mxml文件（纯粹的XML描述文件和ActionScript）产生相应得swf文件，传送到客户端，由客户端的解释执行。
Flex提供了三种方式和Java进行数据交互：
HTTPService，RemoteObject和Web服务。
其中，HTTPService方式可以传输Text、XML或者JSON（JavaScriptObjectNotation）等。
由于Flex具有Flash打下的良好用户基础，同时具有丰富的展现效果，正在成为一种流行的客户端展示实现技术。
AJAX和J2EE的通讯
AJAX（AsynchronousJavaScriptandXML）是多种技术的综合，它使用XHTML和CSS标准化呈现，使用DOM实现动态显示和交互，使用XML和XSTL进行数据交换与处理，使用Javascript绑定和处理所有数据，Javascript是一种粘合剂使AJAX应用的各部分集成在一起，中JavaScript主要被用来传递用户界面上的数据到服务端并返回结果。
AJAX使用XMLHttpRequest对象进行异步数据读取，XMLHttpRequest对象用来响应通过HTTP传递的数据，一旦数据返回到客户端就可以立刻使用DOM将数据放到网面上。
在Ajax中，XMLHttpRequest是核心，XMLHttpRequest对象在大部分浏览器上已经实现而且拥有一个简单的接口允许数据从客户端传递到服务端，但并不会打断用户当前的操作。
使用XMLHttpRequest传送的数据可以是任何格式，包括可以传输Text、XML或者JSON。
其他客户端和J2EE的通讯
除了前文所描述常见的浏览器支持的技术标准，当前富客户端（RichInternetApplications，RIA）发展也很快，比较流行的有AIR、WPF、JavaFX等。
AIR（AdobeIntegratedRuntime）是Macromedia发布一个跨操作系统运行的RIA技术解决方案，利用现有的Web开发技术（Flash，Flex，HTML，JavaScript，Ajax）来构建富客户端，并部署为桌面应用程序，其本质上采用的是前述Web开发技术和后台通讯。
由于AIR可以访问客户端的资源，并可以实现离线操作，所有具有广阔的应用前景。
WPF（WindowsPresentationFoundation）是Microsoft的.Net平台的RIA技术解决方案，WPF通过扩展应用程序标记语言（eXtensibleApplicationMarkupLanguage，XAML）把界面和业务逻辑分开，以开发出界面炫丽，功能强大的应用程序。
WPF可以通过基于SOAP的Web服务或者RESTfulWeb服务跟后台J2EE服务器交互。
另外轻量级的基于浏览器的Silverlight可以采用这种技术。
JavaFX是Java的RIA技术解决方案，和早期的Applet、JavaWebStart等技术一脉相承，其使用的是领域专用语言（DomainSpecificLanguage，DSL），和后台通讯方式同Applet。
通讯方式总结
如前文所述，客户端和服务器端的通信有很多种，但是有两种是都支持的，基于SOAP的Web服务和RESTfulWeb服务。
Web服务是通过简单对象访问协议（SimpleObjectAccessProtocol，SOAP）传输的，SOAP是一种基于XML的协议，可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME），基于“通用”传输协议是SOAP的一个优点。
它还支持从消息系统到远程过程调用（RemoteProcedureCall，RPC）等大量的应用程序。
SOAP提供了一系列的标准，如WSRM（WS-ReliableMessaging）形式化契约确保可靠性与安全性，确保异步处理与调用；
WS-Security、WS-Transactions和WS-Coordination等标准提供了上下文信息与对话状态管理。
相对而言，SOAP协议属于复杂的、重量级的协议，当前随着Web2.0的兴起，表述性状态转移（RepresentationalStateTransfer，REST）逐步成为一个流行的架构风格。
REST是一种轻量级的WebService架构风格，其实现和操作比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。
REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法，这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
REST架构尤其适用于完全无状态的CRUD（Create、Read、Update、Delete，创建、读取、更新、删除）操作。
基于REST的软件体系结构风格（SoftwareArchitectureStyle）称之为面向资源体系架构（Resource-orientedArchitecture，ROA）。
按照REST原则设计的软件、体系结构，通常被称为“REST式的”（RESTful），在本文中以下称之为RESTfulWeb服务，以便于和基于SOAP的Web服务区别。
服务器端采用J2EE，客户端采用JSP、Flex、JavaFX、AIR等可以直接调用Servlet，其他的实现技术基本上不能直接调用，但是无论是那种客户端，对于基于SOAP的Web服务或者基于RESTfulWeb服务务都是支持的，如AJAX的XMLHttpRequest、Flex的HTTPService等。
如下图所示：
图2.客户端和服务器端的通讯方式
基于SOAP和REST的分层模型
结合前文所述客户端和服务器端的通讯方式比较和分析以及在《SOA和BC》一文中描述的业务组件模型，下文给出了在界面层和业务逻辑层采用轻量级的RESTfulWeb服务，不同业务组件之间采用基于SOAP的Web服务的业务组件模型。
基于ROA的业务组件界面层和业务逻辑层接口
在多层架构下，特别是当前客户端技术发展迅速，有不同的技术实现方式，将界面层和业务逻辑层分离将能更好的实现业务组件的重用，业务逻辑不受不同客户端技术技术影响，从而更好的保证了业务逻辑的重用。
为了支持各种客户端技术，需要采用各种客户端技术都能支持的标准的接口方式，在前文所述两种通用标准中，SOAP相对来讲属于重量级协议，而且基于SOAP的Web服务将会增加软件开发的难度，影响系统的性能，因此采用轻量级的RESTfulWeb服务务，来实现界面层和业务逻辑层的分离，如下图所示：
图3.界面层和业务逻辑层的通信模式
为了保持和基于SOAP的Web服务方式传输的内容一致，其传输的数据格式均采用标准的XML，比如传递一个客户信息，基于SOAP的Web服务传递的参数和RESTfulWeb服务格式分别如下：
清单1.XML样例
<
?
xmlversion="
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服务还是RESTfulWeb服务，只是通过配置输出不同的协议就可以了。
Axis2可以很好的支持这个架构，Axis2是一套崭新的WebService引擎，该版本是对Axis1.x重新设计的产物。
Axis2不仅支持SOAP1.1和SOAP1.2，还集成了RESTfulWeb服务，同时还支持Spring、JSON等技术。
清单2.生成XML代码示例
publicStringtoString（）{
StringstrXML=””;
·
·
;
if（null!
=orgCode）{
sb.append（"
"
）;
sb.append（orgCode）;
}
if（null!
=custCode）{
sb.append（custCode）;
}
returnstrXML;
这样业务组件只是提供一个标准的XML格式输出，由Axis2来管理生成基于SOAP的Web服务或者RESTfulWeb服务。
界面层和业务逻辑层的通讯全部通过RESTfulWeb服务，不管客户端采用什么实现技术，可以重用一个接口。
在业务组件内部可以进一步分层，把协议层和业务逻辑层分离开，不管是采用直接调用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标准，对外提供标准的门户程序，通过门户集成平台进行门户集成。
对外的门户程序可以以两种方式提供，一种是完全独立的门户程序，可以任意的集成到任何一个独立的门户界面，但是如果所有的界面都定制，考虑到性能和定制工作量比较大，可以采用另外的一种方式，即把多个界面定义到一个门户程序中，可以将一系列的界面在一个门户程序中完成，减少配置以及管理的工作，使得系统更加易于集成。
比如可以把客户信息展示作为一个简单的门户程序，仅仅实现客户信息展示，也可以把客户维护，客户信息展示、客户拜访管理、客户分类管理等所有客户相关的信息在一个门户程序中实现，并且在门户程序中以菜单的方式进行选择，相当于是内嵌了一个小的应用功能界面。
1.Portlet属于比较重量级的标准，但是由于Web2.0尚未统一标准，如果轻量级的Web2.0有通用标准之后，采用Widget等将会是未来的发展方向。
2.对于同一一个开发商来说，在内部可以采用自己定制的Widget标准方式，包含Widget的定义、Widget之间的数据交互、界面风格设定等。
∙服务接口：
服务接口按照类型可以分为6种，其中人交互服务和信息服务比较特殊，，分别实现人机交互和数据交换的功能，是以服务的方式提供人机交互媒介和数据接口内容。
1.人机交互服务，将人机交互内容以服务的方式提供，通过处理后在界面层次统一展示，通过这种方式，可以实现将不同的业务组件的服务混搭（Mashup）成一个门户程序，而不是通过两个门户程序进行整合。
人机交互服务和Portlet的差异是采用的标准不同，前者基于Portlet标准，后者基于基于SOA的Web服务或RESTfulWeb服务；
前者直接以界面的方式对外提供，后者主要提供数据（可以同时提供展示方式，即一段HTML代码），通过前端的定制工具实现界面展示，通过这种方式，在门户系统进行界面整合，将不同系统的数据在界面进行统一展示，比如可以将财务系统的人员工资信息、人力资源信息等分别以服务的方式对外提供，然后在门户的界面整合工具在门户中统一进行展现，而不是通过Portlet的方式实现。
如前文所述，采用RESTfulWeb服务
2.业务服务，业务组件为实现的业务组件核型功能的对外相关服务，是业务组件核心服务，主要用于本业务组件和其他的业务组件之间的业务交互，使得多个业务组件或者系统共同完成企业的业务流程。
为了保证业务组件的高内聚，松耦合，要合理的规划业务组件对外提供的服务的粒度，即能保持灵活性，又可以保证对外提供的服务不至于太多，不宜管理。
业务组件的web服务结构是企业业务组件规划中的最为重要的标准化功能，用于确定不同业务组件之间的边界。
3.主数据服务，主数据相关的服务，是共用的服务，主数据管理业务组件也是属于企业公共服务平台管理范围，是企业级的公共业务组件。
4.流程服务，涉及工作流程的服务，相关信息提供到工作流引擎，是共用的服务，流程管理业务组件也是属于企业公共服务平台管理范围，是企业级的公共业务组件。
5.系统管理服务，是由系统管理公共组件提供的服务，主要包含用户认证、权限管理等相关的服务，是共用的服务，系统管理相关业务组件属于企业公共服务平台管理范围，是企业级的公共业务组件。
主数据服务、流程服务和系统管理服务是企业架构平台提供的公共服务，是集成平台的核心内容。
6.信息服务，和数据库相关的服务，直接从数据库获取相关信息。
由于业务组件的数据是私有的，为了保证业务组件的数据能够得到更好的应用，需要将业务组件的数据公布出来，基于企业的数据模型，把业务组件的私有数据公开为企业数据中的数据。
信息服务可以采用实时、或者准实时的方式对外提供。
在某些特殊情况下，可以认为业务组件不存放数据，业务组件仅仅是获得数据，处理数据，然后将数据在放到企业数据库中。
∙数据接口：
基于视图或者表直接对数据库进行操作，即业务组件对外提供一个直接访问数据库的接口，如果数据库结构是按照这个接口设计的，这个业务组件可以直接访问数据库，而不需要通过其它的服务，需要明确每个组件对表的读写权限，并进行严格管理，通过数据接口的方式，核心是需要建立企业数据架构，建立共享的数据结构。
通过数据联邦、数据复制实现。
一般来说，不建议这样实现，特别是跨应用的数据访问，尽量通过信息服务实现。
以上通对业务组件模型对外提供的接口类型进行分析，规划了一个业务组件接口模型，所有的业务组件将对外提供以上三类对外的接口。
基于SOA和ROA的整体技术架构
结合当前流行的SOA、Web2.0、3G、三网融合等技术，在基于SOAP和REST的分层模型的基础上，开发的时候采用组件化开发，业务组件和业务组件之间的交互采用基于SOAP的Web服务作为接口模式，实现组件时间的松偶合，降低组件之间的关联关系，不同的业务组件可以由不同的厂商实现；
业务组件界面层和业务逻辑层之间的采用RESTfulWeb服务作为接口模式，实现界面层和业务逻辑层分离，客户端可以采用电脑、手机、电视、各种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的组件模型，从而给出了了业务逻辑和界面展示分离的方法以及业务组件之间的服务定义。
在界面层和业务逻辑层采用轻量级的RESTfulWeb服务，不同业务组件之间采用基于SOAP的Web服务将会是未来最有生命力的发展方向。
升级会员 