群组首页 → 企业架构 → SOA应用平台EOS → 知识库 → EOS系统概述 → EOS产品功能与原理

阅读:6581次评论:0条更新时间:2011-05-26

eos 功能原理

EOS产品功能与原理

本部分包括的内容

基本概念
应用层次架构
服务构件架构
服务数据对象
数据处理过程

基本概念

本部分介绍EOS系统的基本概念。

EOS

Primeton EOS^TM是SOA应用平台，提供了基于Web的企业应用的开发、调试、部署、管理和维护的一体化开发、运行、管理监控环境。

在EOS中用户可以通过拖、拉、拽方式将与业务无关的通用构件进行图形化的组装，实现快速构建基于Web的企业级应用。使用EOS Governor（EOS治理工具）可以实时部署、管理与维护EOS应用。

基于EOS平台开发出的应用是符合SCA/SDO标准的。基于SCA/SDO标准，用户可开发出开放、可扩展、易集成、易管理、符合SOA设计原则的应用和方案。

逻辑流

逻辑流用于完成后端业务功能，它是由开始节点、结束节点、运算逻辑节点、事务处理节点和连线等组成的图形。

逻辑流通过调用运算逻辑（如查询数据），将处理后的数据返回给页面流。子逻辑流是指被逻辑流所嵌套调用的逻辑流。

页面流

页面流是用于描述用户界面元素流转关系的图形化流程，它是由开始节点、结束节点、逻辑流节点、服务节点（可选节点）、返回页面节点和连线等组成的。

数据模型

EOS提供了数据建模工具，支持数据实体和数据库表的映射，支持从数据库表生成持久化数据实体，从持久化数据实体生成数据模型。

运算逻辑

运算逻辑又称BL（BizLet）方法，基于Java代码实现，用于完成特定的计算处理任务。在EOS 6.0中，运算逻辑可以为静态Java方法也可以为非静态的Java方法。

构件包

构件包是EOS系统发布和复用的基本单位，它由逻辑流、页面流、服务构件、Java代码、页面资源等组成。一个构件包通常能够完成一个相对独立、完整的业务功能。

EOS构件包相当于一组资源的容器或命名空间；
同一个EOS构件包中的EOS构件不能重名；
EOS平台对构件的调用是通过包名来定位EOS构件所在的包。

业务流程

业务流程是用于完成包含人工和自动的业务活动流程的构件，它是通过BPS for EOS开发环境来开发的流程管理的图形化描述。

应用层次架构

2007年3月，IBM、普元、Oracle、SAP等国内外著名企业联合发布了SCA 1.0规范和SDO 2.1规范。SCA是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的软件模块通过服务构件的标准化而统一地封装起来并被调用访问。这种面向服务构件的编程模型可以大大简化客户的编程，提高应用的灵活性。

EOS 6扩展了EOS 5的功能，在技术架构上支持了国际标准SCA和SDO规范，这样基于Primeton EOS^TM开发出的应用，具备了如下特性：

符合国际标准
易于扩展
易于集成

基于普元开发的应用架构分为五个层次，包括资源层、构件层、服务层、业务流程层和协同层，参见下图：

本部分包括的内容

资源层
构件层
服务层
流程层
协同层

资源层

资源层的核心功能是访问数据资源，为了在各个层次采用统一的方式访问这些资源，EOS采用数据定义的方式描述了系统中的数据结构，这些数据结构用于接口的定义、数据的持久化、数据的显示格式以及数据的转换格式等等。

下图是数据定义的核心概念模型：

一组数据定义组成了一个数据集，数据定义由数据实体和显示模型组成。其中数据实体分为以下几种：

持久化实体
持久化实体是可以保存到持久化介质中的数据实体，它除了用一个xml schema描述数据结构的名称、类型等内容外，还包括一个mapping文件，描述数据结构和持久化实体之间的对应关系。
非持久化实体
非持久化实体类似DTO对象，是不需要持久化的。
SQL定义查询实体
查询实体也是一种持久化实体，类似数据库视图，只能用于查询。

显示模型定义了数据实体的显示方式，包括编辑方式、效验规则、显示名称、显示样式等内容。每个数据实体可以有多个显示模型，每个页面控件可以使用显示模型控制显示的样式。

构件层

构件层的构件用于实现领域相关的业务逻辑，构件层提供了三种类型的构件实现方式：Java构件、逻辑构件和工作流。通过三种构件组装、调用运算逻辑，或者相互调用来实现业务操作。下图是EOS构件层对象的概念模型：

逻辑构件是EOS多年以来发展的一种基于图形化编程的构件实现模式。EOS逻辑构件采用图形化的方式将运算逻辑、逻辑流和服务组装成更大粒度的构件。一个逻辑构件定义了一套业务操作的接口，每个业务操作由一个逻辑流来实现。逻辑流是采用图形化的方式来实现业务逻辑，这样可以大大降低开发人员的学习成本，提升组织级别的构件复用度、增强了应用的可维护性。

Java构件需要符合SCA_JavaAnnotationsAndAPIs_V100的规范，EOS提供了编写SCA Java构件实现工具级别的支持。在EOS中开发人员可以快速方便的开发基于SCA对Java构件实现。

工作流也是一种构件，我们可以把一个工作流程暴露成一个服务，由其他模块来调用。这样其他模块看到的只是一个业务操作接口，而不必关心这个业务对应的是一个业务流程，还是一个逻辑流或者一个Java构件。

服务层

服务层用来将构件层编写的构件装配成服务的方式，暴露给其他模块或者其他系统。服务层的服务含义不仅仅是指Web Service，在SOA体系中服务是构件暴露出来的业务操作，在技术上可以体现为WebService，也可以体现为Java Interface、EJB、JMS等多种调用方式。

在EOS Studio中我们可以将Java构件，或者逻辑构件实现装配为服务构件，也可以将这些构件装配成更大粒度的组合构件。

上图是服务层对象的概念模型，服务层的核心思想是将构件实现装配为对外的服务，将小构件装配为大构件，将大构件装配为更大粒度的具有业务语义的构件。服务层采用OSOAI定制的标准，服务构件架构（SCA 1.0）来实现。

流程层

普元在流程层提供了BPS，帮助客户实现人与人之间的工作协调，人工任务与自动任务间的协调。BPS，完全支持SCA服务构件的调用，是一个面向服务的流程管理产品。

协同层

基于EOS开发的应用支持HTTP接入、EJB接入、Web-Service接入、Ajax等多种方式接入EOS系统。

EOS提供了客户端接入接口，允许GUI程序，或者第三方应用通过客户端接口访问EOS应用提供的服务。EOS客户端接入支持EJB和WebService两种调用模式。

EOS在接入层最核心的功能是提供了页面流功能，EOS页面流引擎负责页面的跳转、页面间的状态流转、调用服务层提供的服务，或者直接调用构件层构件的接口。

服务构件架构

服务构件架构SCA（Service Component Architecture）是业界主要的软件厂商，包括IBM、BEA、Oracle、SAP等厂商共同推动制定的，普元作为亚洲唯一的核心厂商也参与了这个标准的制定过程。通过SCA，可以大大简化用户构造面向服务架构SOAs（Service-Oriented Architectures）应用的过程。

SCA为构建于SOA的应用和解决方案提供了一套编程模型。它的基本理念是：业务功能都是用服务来描述的，通过将这些服务进行组装就可以提供新的业务；在组装的过程中，可能需要新开发一些服务，也可能从企业已有的业务功能重抽取出服务，而进行重用。SCA提供了开发新服务的模型，也提供了重用已有应用业务功能的模型。

SCA给开发人员提供了一个统一的编程模型，在一个组织内，所有的开发人员可以一种统一的模式来实现面向服务架构的应用。随着SOA体系变得越来越复杂，您需要灵活、简单的SCA技术，使用SCA技术可以帮助您完成如下目标：

节省开发成本------简单的API，平滑的学习曲线；
提供重用机制------使用SCA装配模型，非常容易实现构件和服务的重用。

本部分包括的内容

服务构件定义模型
服务构件装配模型

服务构件定义模型

服务构件定义模型，定义了SCA组装的基本单元"构件"，一个构件由服务、属性、引用和实现组成，如下图所示：

下表定义了服务构件定义模型中的基本术语：

术语解释

Service	SCA Service是外部访问SCA实现的途径。服务可以用多种形式提供，比如Web Service、RMI、Stateless SessionBean等。在SOA中Service是一个粗粒度的概念，一个Service可以是一个业务构件，也可以是一个业务流程等等。
Reference	SCA实现的一些服务是由其他实现提供的，SCA容器在运行期会自动的找到这些引用对应的构件实现。相当于依赖注入的概念。
Property	对实现的特定属性进行配置。
Wire	连接Reference到Service。
Interface	接口定义了一个或多个业务功能。Service提供了这些业务功能，SCA Component通过Reference来使用这些业务功能。SCA容器支持两种接口描述形式，Java Interfaces和WSDL PortTypes。
Binding	服务和引用会使用绑定。引用使用绑定来描述采用什么机制来调用引用对应的服务。服务使用绑定来描述客户端可以使用什么样的机制来调用服务。
Implementation	Implementation用来描述具体的软件技术，比如Java class、EOS构件、BPEL Process等的一个概念。实现定义了可以配置的变量，比如可以配置哪些属性，哪些引用需要配置。实现的配置通过componentType来定义。
Component	SCA Component是SCA Implementation的配置实例。EOS的SCA容器支持多种SCA实现，包括Java实现、EOS实现。一个Component会指向一个实现实例、一个属性集、一个引用集合。在运行期，SCA容器会自动找到Component对应的实现实例，从Composite文件中装载属性的值，并且找到Component依赖的应用构件，并且将这些构件注入到Component中。
Composite	Component的组装单元，组装Component Service暴露的Service以及Service对外引用需要的Rerference。Compnent之间的Service，Reference之间的Wire和Properties的定义。在更高层次上作为component的实现。
Contribution	SCA的一个部署单元，在EOS中Contribution是一个部署单元，这个部署单元包含了Component、Implementation以及一些额外需要的资源，比如JSP、Jar包等。

服务构件装配模型

SCA装配模型定义了如何将一个构件包装成服务，如何将小粒度的构件组装成大粒度的构件，如何将一组小粒度的构件协同起来执行一个任务。通过SCA装配模型，用户可以提升构件的可重用性，从而在组织级提升开发效率，降低开发成本。

使用SCA装配模型，我们可以方便的将构件的服务，暴露为不同的调用协议，比如将服务暴露为Web Service、JMS、RMI、EJB等，服务构件的应用也可以使用不同的协议，比如Web Service、JMS、RMI、EJB等调用其他构件提供的服务。

服务构件绑定模型如下图所示。

服务数据对象

虽然Java平台和J2EE提供了大量的数据编程模型和API，但是这些技术都是分散的，而且通常不能服从于工具和框架。此外，其中的一些技术可能难以使用，而且可能功能不够丰富，无法支持常见的应用需求。服务数据对象SDO（Service Data Object）旨在创建一个统一的数据访问层，以一种可以服从工具和框架的易用方式为不同的数据源提供一种数据访问解决方案。

EOS 5版本中数据上下文中的数据采用XML来描述，在EOS 6中采用SDO作为数据载体，SDO对象比XML更容易编程，占用内存更小，访问数据的效率更高。

数据处理过程

数据处理过程主要涉及到接入引擎、页面流引擎、逻辑流引擎和SCA容器。

EOS数据核心处理过程如下图所示：

本部分包括的内容

接入引擎
数据上下文
数据流转过程
页面流数据处理
逻辑流数据处理
工作流数据处理

接入引擎

EOS提供了多种接入方式，用户可以用Http、Web Service、EJB等方式访问基于EOS开发的服务或者逻辑。EOS的核心模式还是采用"浏览器+服务器"模式。

随着Ajax以及RIA技术的发展，浏览器和服务器交互的方式也发生了很大变化。

在传统的浏览器，服务器模式下，浏览器采用Http的GET/POST方式向服务器提交键/值对，而在Ajax模式下，浏览器会向服务器提交XML数据或者JSON（JavaScript Object Notation）等类型的数据。

接入引擎主要完成三部分功能：

提供拦截过滤器的功能。此功能类似于J2EE的Servelt Filter的功能，使用此功能，开发人员可以不修改J2EE的配置文件，注册请求拦截器；
将从浏览器传入的各种类型的数据，比如键值对、XML、JSON对象，转换成SDO或者JavaBean对象；
将从浏览器传来的请求分发给不同的处理引擎，比如页面流引擎。

数据上下文

页面流、逻辑流和工作流在运行期都是以数据上下文为中心。

数据上下文是一个有固定分区的数据容器，不同的模块可以从数据容器的不同区域中获取数据。

数据上下文中数据区的生命周期控制，由EOS Server统一管理。

数据上下文分为多种数据区，其中包括：

请求上下文数据区
页面流上下文数据区
会话上下文数据区
逻辑流上下文数据区
业务流程上下文数据区

每一种数据区的生命周期是不同的，详细描述，参见下面的表格。

数据区名称使用模块描述

请求上下文	页面流	请求上下文数据区中放置的是一个完整的Http Request/Response过程中页面流产生的数据。当一个页面流实例接收到一个Http请求后，引擎创建一个请求上下文数据区，当引擎响应这个Http Request后，引擎销毁这个请求上下文数据区。
页面流上下文	页面流	只有有状态的页面流实例才有页面流上下文数据区，这个数据区和一个页面流实例的生命周期是一致的。
会话上下文	页面流逻辑流	会话上下文的生命周期与Http Session的生命周期是一致的，会话上下文数据区的数据来自Http Session中的数据。（用户可以配置只将某些Session中的数据放入到会话上下文数据区中）
MUO上下文	逻辑流运算逻辑	MUO上下文是受管用户对象上下文，是为了在逻辑流、运算逻辑中防止用户随意使用Http会话中的数据，而构造的一个受管数据上下文区，用户需要通过Governor配置出MUO中需要存放的数据对象，这些对象才能在逻辑流和运算逻辑中使用。
逻辑流上下文	逻辑流	逻辑流上下文数据区的生命周期与逻辑流的生命周期是一致的。当一个逻辑流实例结束时，引擎会销毁这个逻辑流对应的逻辑流上下文数据区
流程上下文	工作流	流程上下文数据区的生命周期与工作流流程上下文是一致的。流程上下文数据区保存的是工作流的流程相关数据，这个数据区是可序列化的，工作流流程引擎在某些场景会将这个数据区存储到数据库中。数据上下文的其他数据区都是保存到内存中的。

数据流转过程

如上图所示，EOS的核心数据流程为：客户端浏览器发起Http请求，通过Key/Value对的形式将数据传输到服务器端；页面流引擎接到Http引擎后将Key/Value对象转换为SDO对象，传递给页面流实例，然后再传递给逻辑流实例。

EOS数据传输过程，缺省的对象类型是SDO对象，但是用户也可以采用自定义类型，比如POJO、W3C DOM等。

页面流数据处理

页面流使用到的数据上下文分为三个数据区，包括会话上下文数据区、页面流上下文数据区、请求上下文数据区。

会话上下文数据区存储的数据是当前用户所在的Http会话数据的一个映射。
开发人员开发页面流的时候可以使用s:XPATH_EXPRESSION来访问会话数据区中的数据，访问会话数据区中表达式的前缀为s:，XPATH_EXPRESSION的编写规范，参见《EOS基础参考手册》中的"Xpath"部分。
访问页面流上下文数据区的表达式为f:XPATH_EXPRESSION。
页面流上下文数据区的数据生命周期相当于页面流流程级别的变量，在一个页面流实例中的不同的页面、业务逻辑、赋值操作都可以使用页面流上下文中的数据。
请求上下文数据区中放置的是一个完整的Http Request/Response过程中产生的数据。
当EOS的页面引擎接受到一个Http Request的请求后，它会将这个请求的Key/Value参数按照规则，转换成一个或者多个Java对象放入到请求上下文数据区中；也可以使用复制图元访问或创建请求上下文数据区中的数据；调用业务逻辑或者服务的返回值也可以设置到请求上下文的数据区中。
访问请求上下文数据区中的数据可以采用r:XPATH_EXPRESSION或者不带前缀，直接使用XPATH_EXPRESSION访问请求上下文数据区中的数据。