技术方案之一：实现技术

1.Mashup（糅合）

将多种使用公共或者私有数据库的web应用，通过调用内容提供者的API，将信息糅合在一起，形成一个整合应用。

2.WebAPI

以HTTP为基础，在Web架构之上，将提供的服务内容以标准的界面来定义，以便进行点对点之间的服务整合。常见的技术如HTTP中的GET/POST、SOAP/HTTP、XML/RPC等。

3.JSF

一种Web框架，用于展现层，提供近似于C/S模式的方式开发B/S模式。

4.Hibernate

常用的持久化框架，用语对象关系映射。

5.Spring

常用的配置与装配组件的框架，主要提供两方面的功能，一是依赖注入（IOC），另一方面是面向方面的编程（AOP）。

6.Backing bean（辅助bean）

用于JSF中，主要处理页面逻辑，页面事件及与显示相关的数据。

7.Component（组件）

JSF标签对应的后台类。

8.Pojo（持久化类）

数据表在Hibernate中的表现方式。

9.Service（业务逻辑类）

定义用于处理业务操作的类、接口等。

10.DAO（数据访问类）

定义用于对数据表或持久化对象操作的方法。

11.RSS（Really Simple Syndication）

一种描述和同步Web站点内容的格式，是目前使用最广泛的XML应用。RSS搭建了信息迅速传播的一个技术平台，这些发布的数据都是标准的XML格式，能在其他的终端和服务中使用。

12.AOP

面向方面的编程设计思想、方法。

13.UDDI （Universal Description, Discovery, and Integration，UDDI）

统一描述、发现和集成。

14.RMI

Java远程方法调用，实现Java对象间的远程通信。

技术方案之二：设计策略

一、糅合技术（Mashup）

Mashup是糅合，即一种交互式Web应用程序，它利用了从外部数据源检索到的内容来创建全新的创新服务。Mashup实质是将多种使用公共或者私有数据库的web应用，通过调用内容提供者的Web API，将信息糅合在一起，形成一个整合应用。Mashup一般使用源应用的API接口，或者是一些RSS输出（含atom）作为内容源；区别于Portal门户，Mashup不需要Portal容器就可以进行页面和内容的整合。

Mashup Web站点的特点就表现为它利用了从组织边界之外的数据源获取的内容和功能，并在客户端或者服务端进行糅合组装。Mashup机制降低了系统的耦合性，提供了从底层数据到上层页面的业务共享方式。

二、排队论（Queue Theory）

运用排队论对工作项池、实例池等系统进行性能预测、性能分析和性能评价，通过对系统定量评测结果，可以计算出具体的参数配置，进一步提高系统工作效率。

通过对统计分析以及流程的建模分析，找出影响系统运行的关键因素，从而指导设计，优化系统。

三、流水线技术（Pipe Line）

流水线技术运用在系统建模上，目的在于提供对系统性能、吞吐率、效率等指标进行评价分析的理论依据。

四、组件化设计（Component Based Design）

组件化设计大大加强了系统的鲁棒形和可维护性，各组件之间相对比较独立，组件间调用基于公布的接口约定，系统的局部改动将不会影响整体，由此企业可以根据发展的需要，随时替换旧有的组件以满足工作的需要。

五、服务注册与发现（Service Registery/Discovery）

在SOA体系中，服务生产者创建服务，通过编码或者配置来执行某种业务流程，并且对服务注册发布这些服务的目录信息。在SOA中进行重用意味着很多服务消费者共享同样的服务实例。因为当共享的服务停止或者移植到其他的地方，使用它的应用系统就会终止，这样在服务提供者的实现和位置修改时，确保服务消费者不会终止就非常重要。

服务注册是基于UDDI标准的。UDDI服务注册是开放的，基于XML的，平台无关的，允许将业务展示在Internet上，并且为与其它业务交互定义参数；或者企业内部的一个团体对其他的团体开发它的服务。UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型等。

六、对接口编程（Programming to Interface）

对接口编程主要是一种把功能与实现分离以降低耦合度，保持组件之间的相对独立性的设计思想。通过提供不同的子类实现，使系统有较好的可扩展性，同时增加代码稳定和健壮性，降低耦合性等。

七、单向依赖（n-Tier Architecture Model）

多层设计通常会增加一些系统的复杂度，但其有助于提高系统的可伸缩性和系统的可管理/维护性。其目的是为了使系统更容易被理解，不同的部分相对独立，能够被较容易的替换和改进。应注意降低层与层的耦合性，这里我们使用单向依赖来降低层间耦合，同时使用IoC 容器来管理这些依赖关系。

八、设计模式（GoF经典模式, J2EE 核心模式, EJB设计模式）

在面向对象的编程中，软件编程人员更加注重以前的代码的重用性和可维护性。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。可以有效的提高开发效率和质量，提高系统的稳定性和灵活性。

九、反转控制IoC（依赖注入Dependency Injection）

采用IoC，由容器控制程序之间的依赖关系，而非传统实践中，由程序代码主动直接控制。控制权由应用代码中转到了外部容器。调用者不必了解被调用者的创建过程甚至自己创建被调用者，从而实现调用者和被调用者解耦。同时也为容器提供其它横切服务（如事务控制）提供了便利。

十、AOP（Aspect Orient Programming）

有一些问题(方面/关注点)，如取得/关闭数据库连接、事务管理、安全控制等，一般在多个模块或组件中存在，AOP提供了横切的思想，跨越不同组件，对问题提供了集中统一的解决方案，简化开发，降低耦合性，是OOP的有益补充。

十一、基于UML 的OOA/OOD

UML是工业标准，广泛用于系统分析与设计中。OOA/OOD基于面向对象的思想，符合OOP开发人员的习惯，为OOP提供良好的基础。OOA/OOD结合UML有助于提高沟通的效率和效果，提高分析与设计的质量。

十二、序列化（Serialization）

对象与字节流的互相转换机制。通过序列化操作可以完成内存对象的网络传输、二进制存储、关系型数据库管理等功能。

技术方案之三：标准规范

一、Java EE

Java EE（Java Platform，Enterprise Edition）是SUN公司定义的一个开发分布式企业级应用的规范。它提供了一个多层次的分布式应用模型和一系列开发技术规范。多层次分布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行（如Servlet组件在Servlet容器上运行，EJB组件在EJB容器上运行），容器间通过相关的协议进行通讯，实现组件间的相互调用。遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。

为实现企业级分布式应用，Java EE定义了丰富的技术标准，符合这些标准的开发工具和API为开发企业级应用提供支持。这些技术涵盖数据库访问、分布式通信、安全等。为分布式应用提供多方面的支持。

1.组件技术

Java EE的核心思想是基于组件/容器的应用。每个组件提供了方法、属性、事件的接口。组件可以由多种语言开发。组件是可以重用的、共享的、分布的。

2.Servlets和JSP

Servlets用来生成动态页面或接收用户请求产生相应操作（调用EJB）。JSP基于文本。通过容器产生相应的Servlets，使内容和显示分开。Java EE中提供了Servlet API，用于创建Servlet。

3.EJB技术

EJB规范提供了一种开发和部署服务器端组件的方法。每个EJB是按功能逻辑划分的，开发时不必关注系统底层细节问题，只关注具体的事务分析。EJB开发完毕后，按规范部署在EJB容器，完成相应的事务功能。EJB支持分布式计算。真正体现了企业级的应用。

4.数据库访问

无论是传统的企业信息系统还是将来的企业信息系统，数据库都占有重要的地位。开发分布式系统要求数据库访问具有良好的灵活性和扩展性。JDBC（JavaDatabase Connectivity）是一个独立于特定的数据库管理系统的开发接口。它提供一个通用的访问SQL数据库和存储结构的机制，支持基本SQL功能的一个通用底层的应用程序编程接口。它在不同的数据库界面上提供了一个统一的用户界面。提供了多种多样的数据库连接方式。Java EE中提供了JDBC API使多种数据库操作简单、可行。

5.分布式通信技术

分布式通信技术是分布式企业系统的核心技术。Java EE框架为Web应用和EJB应用提供多种通信模式。

为了使运行于某一台机器上的对象能够调用另一台机器上的对象，Java EE实现了如下通信方式：

Java RMI（Remote Method Invoke）：远程方法调用。Java RMI实现Java对象间的远程通信。服务器用注册器把一个名字和远程对象绑在一起，客户机通过名字从服务器注册器上查找远程对象，找到后下载远程对象的本地代理，调用远程对象的方法。

Java IDL（Java Interface Defilation Language）：接口定义语言。可以实现Java对象的符合CORBA规范的远程对象通信。

JNDI（Java Naming and Directory Interface）：Java命名和目录接口。JNDI为分布式系统访问远程对象提供了一个标准的命名接口。EJB主接口对象、数据源、消息服务器等都可以用JDNI树的形式注册到名称服务器中，调用它们的对象通过符合JDNI的程序接口在JNDI名称服务器中查找指定名称的远程对象。

JMS（Java Message Service）：Java消息服务。为开发消息中间件应用程序定义了一套规范。Java客户端和Java中间层访问消息系统只要实现JMS定义的简单的接口，就可以实现复杂的应用，而不必去关注低级的技术细节。

二、SOA

面向服务指的是通过基于定义信息交换结构所用的公共语义或词汇表，集成应用程序和信息源。面向服务使服务提供者和服务使用者实现松散耦合，因为二者之间最初不共享任何信息。

面向服务的体系结构（Service-oriented architecture, SOA）是应用程序开发和集成的体系结构方式、设计风格或设计原则。SOA采用由不同机构系统、客户系统、供应商系统和合作伙伴系统构成的分布式模型，实现企业级业务服务的业务流程协调。

SOA由服务提供者、服务请求者（或服务使用者）和任选服务目录构成，采用应用程序之间的消息进行信息交换，从而提供服务。服务提供者创建服务，并在服务目录里发布有关该服务的描述信息。服务请求者查询服务目录里的描述信息来找到服务，同时收集有关该服务和服务提供者的信息。服务请求者访问位于服务提供者基础设施里的服务，实现利用该服务的企业价值。

SOA的目标在于让IT系统变得更有弹性，以便更灵活、更快地响应不断改变的企业业务需求。SOA是一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。SOA具有以下特性：

1.粗粒度性：粗粒度服务提供一项特定的业务功能，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够了。

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

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

4.协议无关性：协议无关性要求每一个服务都可以通过不同的协议来调用。
SOA架构为系统架构提供了更加灵活的构建方式，从底层架构级别保证了整个系统的松耦合性以及灵活性，为未来的扩展打好了坚实的基础。

技术方案之四：系统架构之逻辑架构

某大型银行深化系统的整体逻辑架构是依据平台的建设目标进行设计的，按照主流技术标准采用分层的技术架构，在Java EE、SOA等标准规范体系下，将最基本的以及共性的信息处理、流程调度、优先级、权限、路由等相关的功能作为平台运维的核心层，以“工厂化”、“流水线”的指导思想建立起数据录入、凭证登记、影像扫描、传输、验印、OCR识别、安全加密、监控等等可共享的业务服务模块，并最终仅仅通过业务流程定义、客户化模块定制等简单的工序，就可以实现业务服务模块的合理调度和灵活组装，支撑起各类前后台分离业务。同时，该架构能够支撑起海量内容的处理要求，并且能够满足以下特性：

一、松耦合（Loosely-Coupled）

系统设计将应用程序定义为不同组件（或称为服务），通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以松耦合的整合方式，并采用一种统一和通用的方法进行交互。

二、适应性（Flexibility）

由于需要整合的系统相当多并且复杂，系统设计必须能够方便地适应当前相关系统的不同情况以及未来变化。包括支撑技术、系统接口以及业务需求等方面的变化。同时也能通过流程描述的方式适应面临的需求变更。本系统应尽可能减少对原有系统的改变。

三、扩展性（Scalability）

能够通过增加系统的资源，如CPU、内存、网络、和存储等显著地提升系统的吞吐率。包括深度扩展（在一台服务器中增加更多的资源）和广度扩展（使用多台服务器）。

四、可用性（Availability）

系统通过冗余的方法避免单点故障。同时，系统应尽量减少计划内的停机。

五、安全性（Security）

系统的安全性涉及多个方面。在这里我们主要关注安全管理。包括认证（Authentication）、授权（Authorization）、审计（Audit）和管理（Administration）等方面。

六、成熟性（Maturity）

该架构中使用的产品都是经过了市场的考验，并且在全球范围内有广泛基于SOA思想的应用平台架构设计的用户。应该尽量避免采用一些小的厂商开发的、或者自己开发的中间件产品。

七、先进性

设计方案中采用市场领先并业内成熟的技术，使系统具备国内同业领先的地位。便于系统的升级和今后的维护。

八、标准性和开放性

在本系统建议书中建议的产品，从网络协议到操作系统，全部遵循通用的国际或行业标准。系统整体架构充分利用现有资源，统筹考虑，长远规划。

综上所述，该平台架构的分层从基础技术模块到业务共享处理模块，都充分考虑了平台各个部分的共有特性和任意组装性，体现了平台的稳定性和灵活性；由里而外分层设计，能够更加合理地找到不同粒度下各个问题解决方案的落足点；以核心功能共性化、业务服务工厂化、各类应用流水线化来实现平台的扩充性和先进性，从而适应各类前后台分离的业务处理需求。

技术方案之五：系统架构之功能结构

系统功能结构自底向上分为三个层次：核心层、业务（服务）层、应用层。整个系统的核心层主要实现了流程的调度和控制，通过状态机流程管理完成整个业务从系统输入到结果输出的作业流程控制，同时提供了SSO登录授权管理；业务层提供了在每个业务流程中的各类处理功能服务和对外记账等接口服务；应用层通过Mashup糅合不同的服务和界面模块，是用户和操作者的UI界面。

核心层通过任务分配器负责流程实例的产生、工作项池管理，以组内互备、组件均衡的方式保证系统可靠性和稳定性，对外提供了在业务类型（岗位）、权限、待完成时间、重要级别、系统负载等不同维度可调整的任务队列；任务抓取器以RMI调用方式对外提供了接口调用管理；队列中使用了PID优先级调度器来实时控制流程的每一个环节。登录授权管理通过验证体系来实现整个系统SSO（单点登录）。

服务层主要体现了SOA体系下的组件复用和业务复用机制，由核心层流程来调度，包括录入、验印、扫描、数据核对、OCR、影像切分等业务共享服务，同时把与CCBS、交换、汇划等记账及其他系统接口做成可由流程调度的自动服务，其中影像处理服务集合包含了扫描、切片、安全、压缩、传输、缓存和归档等服务。每种类型的服务都是闭包内聚组件，通过以数据库为存储介质，以UDDI规范描述服务接口定义。服务可独立运行在不同的环境下，保证了系统的横向扩展能力。

应用层通过服务层的界面模块，能够通过简单的流程定义和优先级等参数配置，就可以构成票据提入提出、批量代收入等不同应用系统。
系统包括了两类结构化和非结构化数据存储格式，结构化数据以关系型数据库存储了流程数据库、业务数据库、报表数据库三种，非结构化数据以ECM存储管理。其中，因为各自服务是闭包的，因此不同的业务系统可以通过增加业务数据库来扩容。

技术方案之六：系统架构之运作流程

系统的运作流程中，用户登陆、各服务组件之间都是在单点登录（SSO）认证体系下，用户只需登录一次系统就可访问每个SSO认证信息共享下的服务。下面是用户从登陆到工作项获取的流程：

首先用户登陆，经过SSO统一认证后，将会话Session共享认证信息在各服务中进行共享；登陆成功后，任务抓取器调用权限服务以确定该用户拥有的岗位；从岗位信息中获取权限列表后，确定抓取哪个模块的任务队列；取得任务后，从任务类型返回该任务的工作页面；用户开始对任务进行处理，同时事务处理开始；用户提交给应用服务后，应用服务处理后将结果写回流程数据库，同时将业务数据写回业务数据库，此时完成了一个任务的事务处理。

在一人多个岗位情况下，任务抓取器在取得权限时会确定两个及以上岗位的权限，对拥有的权限去不同的任务队列中获取任务，优先级调度器针对任务的优先级进行设置，使任务按照一定的顺序展现给用户，再若拥有的是同模块的不同岗位时，任务抓取器则会在该模块下抓取各个岗位所能获取的任务，当然对在业务上需要互斥的任务则不予抓取。

针对人工服务，还有对于不需要人工参与的自动服务，流程控制引擎会在流程数据库中提取需要自动服务处理的任务，并提交给相应模块的自动服务，自动服务完成后将结果写回流程数据库，同时将业务数据写回业务数据库。

技术方案之七：核心层之流程控制引擎

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

流程控制引擎

流程控制引擎作为流程管理系统的核心部分，主要提供了对于流程定义的解析以及流程流转的支持。流程定义文件描述了业务的交互逻辑，流程控制引擎通过解析此流程定义文件按照业务的交互逻辑进行业务的流转，流程控制引擎通过参考某种模型来进行设计，通过调度算法来进行流程的流转（流程的启动、终止、挂起、恢复等），通过各种环节调度算法（SPLIT、AND、OR等）来实现对于环节的流转（环节的合并、分叉、选择、条件性的选择等）。

为了实现系统的可扩展性，设计流程控制引擎的集群模式是必要的环节。在设计图中，不同的流程引擎分别部署在不同的物理机器上，主要负责业务流程状态的改变（状态机）、工作项的产生等计算环节；以共享流程数据库、独立计算为运行模式来实现集群模式。流程集群设计如下图所示，其中包括了几个功能：

一、组间负载均衡

通过任务分配器来实现每个流程引擎组的实例分配，不同的业务可以分配到相同的引擎组中。具体实现过程如下：每当业务产生一个实例时，任务分配器将都将该实例分配到一个引擎组中，即将对应的引擎组信息存入实例的上下文环境中，每次该流程实例化、工作项产生、流转都是由该组负责。系统将采用1-n组工作组，每一组是逻辑并行的关系。

二、组内多点备份

流程引擎组至少包含两个；组内的引擎通过共享流程数据库，解决单点失效问题。对于流程实例而言，引擎之间是竞争关系，他们之间的互斥主要体现在流程实例是否被引擎加载的标志位上。对于流程实例化来说，采用数据库的操作Select_for_Update来实现同步。组内的竞争通过Timeout机制和提交前检查机制来实现。

三、包含模块

1.状态机：存储了流程实例的状态信息。

2.线程池：实现对多个实例的并发处理。

3.实例池：对流程的实例保存在内存中，实现流程实例的二级Cache，减少对数据库的IO操作；

四、任务分配器

主要完成流程的组分配，原则有两种：

1.按业务优先级配置分配，即根据每个业务产生的业务量统计、优先级、最大业务流程实例数等估算信息，预分配把引擎组分配给该业务。

2.按照运行状态动态分配，即通过流程监控信息，实现实例的动态分配。

技术方案之八：核心层之异步流程控制机制

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

异步流程控制机制

把当前工作项的提交动作和下一个工作项的生成动作分开，成为两个原子操作；当用户提交一个工作项时，只返回当前该工作项数据提交成功与否的结果，而不继续实时计算生成下一个工作项，下一个工作项的生成由后台引擎异步处理，这样避免了两个操作的串行，以获得更高的吞吐量、效率。

当用户提交给流程引擎一个工作项时，将不需要经过流程引擎计算经历长时间的等待，而是立即返回给用户提交成功与否的结果；流程引擎将通过后台的引擎来处理提交，从而产生新的工作项。异步流程引擎方式是典型的流水线、工厂化模式，他通过释放系统等待资源，获取了高吞吐量、高效率。

流程引擎支持异步处理。异步处理中，当用户提交给一个工作项时，立即返回给用户提交的成功与否结果而不是引擎的处理结果，也就是说提交后并不马上交给引擎处理，而是放入一个待解析队列中，由引擎自动检查该队列，一旦发现有待解析流程后，取出该流程解析。异步申请的好处是，在服务器压力较大时，异步处理的用户体验较好。在用户提交后马上离开该页面，以避免在等待引擎解析时，页面长时间无反应，这样对用户来说，他可以马上进行其他操作，在数秒之后，即可以追寻表单，查看流程行进状况；其次，异步机制提供了用来提出负载平衡请求的简单方式、提供了容错能力、支持断续连接的系统等，其中的每个优点都是通过异步模式对应用程序中不同部分进行去耦处理的结果。要让某个处理具有异步特点，就必须建立某种形式的队列来保存挂起的请求，该处理中的每一个步骤都只能与这些中间队列进行通信，而不能直接与其上一步或下一步进行通信。

一、响应时间更快

在同步系统中，用户在整个操作结束之后才得到响应。在异步系统中，提交节点之后，客户的延迟时间仅仅是将该工作项传递给处理中的下一步所花费的时间。在某种程度上，这样的更快响应时间只是一种假象，因为客户收到响应时该处理并未真正完成，但客户不需要再等待了，这是重要的优点。

二、负载均衡

异步处理所要求的基础体系结构能够在不增加额外软件的情况下轻松地提供灵活的负载平衡能力。在异步系统中，需要某种形式的中间存储或队列来存储步骤之间的请求。当一份工作项完成了某步骤中的处理工作时，它就被放到队列中等待进行下一步处理。当下一个步骤准备好处理另一份工作项时，它就从这种挂起请求列表中抓取一份工作项。要完成这样的系统中负载平衡的实施，只需要增加计算机的数量，由它们处理挂起列表中对步骤B的请求。

采用中间队列之后，在负载平衡和可伸缩性方面都获得了很大的灵活性。在该系统的前端或后端都可以放置任意数量的计算机，而且这种灵活性适应于任何一个处理步骤。可以在每一个步骤中使用适当数量的硬件对系统的性能进行微调，也可以在一台计算机上将多个步骤结合在一起进行处理。

三、容错能力

对灵活的负载平衡提供支持的功能同时也就是对容错能力提供支持的功能。如果某个软件或硬件故障删除了某个处理步骤，请求执行该步骤的那些挂起请求就在队列中等候直至该服务被恢复。这对处理中先前的步骤并不产生什么实际的影响，尽管总体处理时间可能由于故障而延长。如果遵循了上一节关于负载平衡所讨论的技术，很可能仅仅减缓某一步骤的处理，但并不会停止。同样的功能也 可以通过使用群集方式来提供；群集可以在不进行任何负载平衡工作的情况下提供故障转移能力。

在负载平衡的系统中，处理同一步骤的其他服务器可以继续从队列中截获请求；如果各服务器都已经以接近峰值的状态运行，整个系统的性能将下降。

四、通知或轮训状态

在同步系统中，调用处理要等待调用返回之后才继续向下执行，即将完成工作项提交给流程引擎时，同时引擎将计算下一个节点，产生新的工作项，并插入数据库生成的新工作项ID。如果对流程引擎进行同步调用，可以立即返回处理结果，也可以表明该工作项是否已经成功地添加到数据库中。但在异步系统中，虽然发出了提交完成工作项的请求，但是实际的计算和插入动作却未同时发生，此时无法返回实际的计算结果，系统也不知道流程是否成功。在这种情况下，将在对请求的提交进行处理时同步生成 ID，由此获得 ID 并在随后以异步方式将该请求传递给处理的其余部分，这个ID可以使由引擎产生也可以根据UUID由客户端产生，只要保证提交时拥有唯一的ID即可。调用者可以使用某种形式的轮询机制使自己负责查询状态。

五、超时处理

异步处理方式让您不必等待每一步都完成；但仍需要考虑整个处理需要多长时间才能结束的问题。为了保证工作项或者正在处理的任何形式的请求最终不会等待过长时间才能处理完毕，需要一种方法来指定每个异步请求允许花费的最长时间。实施超时机制是防止订单在系统中耽搁好几天的唯一办法。

六、补偿逻辑

补偿逻辑与数据库中的事务回滚概念相关，它在处理彻底失败时撤销任何已经完成的操作。在同步系统中已经提供了一些技术来处理此问题，例如数据库事务处理及分布式事务处理中间件。根据这些事务处理技术的任一种，程序员可以明确地声明某处理的所有步骤都是某项事务的一部分；如果出现错误，数据库或事务中间件提供的服务将撤销错误出现前已完成的所有工作。但在异步系统中，不可能采用这些事务处理技术来管理处理中的所有步骤，因为这些步骤被不确定的时间所分割。因此异步流程控制需要单独的处理机制才能撤销处理失败时已经完成的任何工作，即采取开发补偿逻辑来完成。

技术方案之九：核心层之流程数据管理

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

流程数据管理

流程数据的管理包括两大类数据的管理，一是定义时，配置信息，流程定义的管理；二是运行时，流程实例数据（状态、上下文数据），流程工作项数据，流程控制引擎监控数据。

一、配置信息

流程管理系统的全部配置信息，如流程控制引擎的调用地址，任务队列配置等，存放于关系型数据库配置信息表中

二、流程定义

通过可视化的流程定义设计器，可以设计出不同流程模型对象，对设计出来的流程模型对象进行系列化（Serialize）处理，按二进制格式输出，就是流程定义数据；流程定义的存储是存放在关系型数据库中的流程定义表中，一个流程定义是一条记录，对于流程定义数据小于4000字节的，采用base64编码后存放于记录的CHAR型存储字段中，而大于4000字节的，直接存放于记录的BLOB型存储字段中，通过“对象存储类型”字段来进行标识，如下表描述：

.

三、流程实例数据（状态、上下文数据）

当需要启动一个流程时，流程控制引擎从关系型数据库的流程定义表中检索出要启动的流程相应的流程定义，读取其流程定义数据，进行反序列化(Deserialize)处理，得到流程模型对象，对流程模型对象进行克隆（Clone）得到一个新的对象，就是一个流程实例对象，将该对象进行系列化（Serialize）处理后，再存放于关系型数据库的流程实例表中，存放的方式参考前面流程定义对象的储存；在流程的流转过程中，流程实例的各种状态改变和上下文数据的修改实际上是对流程实例对象的各个定义属性的修改，操作步骤为：读取流程实例对象数据--反序列化--修改对象属性--序列化--存回关系型数据库。

四、流程工作项数据

流程工作项数据主要包括该工作项的ID，所属流程实例ID，动作路径（描述该工作项是流程中的哪个环节），工作项类型（描述工作项的所属任务队列）等，所有的工作项数据按记录方式存储在关系数据库的流程工作项表中，一个工作项占一条记录，如图描述：

五、流程控制引擎监控数据

流程控制引擎监控数据主要是流程控制引擎的各类监控性的属性，如空闲时间，引擎当前流转流程实例数等。

技术方案之十：核心层之任务调度

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

任务调度

系统通过闭环PID控制器，实现对工作项的优先级调度。工作项优先级动态调整包括流程实例和工作项两个层次，在模态维度方面包括静态参数和动态参数，其次还应该包括仲裁参数、噪音参数等，优先级应该是以上几种参数的综合。

随着时间的迁移，在无序控制下，完成的时间是无法预测的，对于稳定的系统而言，取决节点的个数和平均处理量。在时间优先级控制中，根据最大吞吐率原则，优先级将随着时间加速递增，对于一个系统而言，虽然大部分节点在处理后期才发现并及时的修正优先级，但由于没有考虑到流程的处理估算以及无法预知当前处理占整个流程的比重，节点的时间浪费在前提比较严重，就会产生负载不均匀现象。因此我们提出了PID闭关控制方式，目的是把每次处理的节点结合流程的关键路径以及系统的当前负载情况，通过这种参数控制来实现系统的均衡负载，同时保证业务流程的处理时间。

PID控制器就是根据系统的误差，利用比例、 积分、微分计算出控制量进行控制的。通过对系统的建模可以得到如下公式：

其中APK(0)表示初始值，APK(t)表示当前时刻下该流程的优先级，取决于上一次的计算结果、剩余时间差值和当前噪音;K1,K2,K3 ,K4是该类流程的比例控制参数。该算法的目的是保证：

1.∑APK<=AMKT，即要流程能在估算的时间内尽早的完成。

2.∑∑APK<=∑AMKT，即对于批量任务，总时间不能超过任务的预期完成时间。

其中WPK(0)表示初始值，WPK(t)表示当前时刻下该流程的优先级，取决于上一次的计算结果、剩余时间差值和当前噪音。K1,K2,K3 ,K4是该类工作项的比例控制参数。期望值是∑WPK<WKT，即要保证工作项能在估算的时间内尽早的完成。

PID控制：利用PID控制可以实现工作项的合理调度，迭代公式：

Output[下次] = Kp*P分量＋Ki*I分量+Kd*D分量

= Kp*Err+Ki*Σ(Err*Δt)+Kd*ΔErr/Δt

其中，Err=Destination-Output。

采用队列方式和基于B树的查找方式来实现基于PID控制的优先级动态调整，关键在于把公用的参数提取出来，实现预排序和B树搜索功能。预排序将当前时间参数t、当前系统运行统计G等与当前相关的信息需要从公式中剥离考虑，因此在优先级表中不会体现。

因此，不难得到任务队列的计算模型如下：

1.定义Hash队列长度为HL，消耗一个工作项时间为WET，那么一个Hash队列完全消耗掉的时间为HET=HL*WET。

2.定义B+树最大容积为BL，完全消耗掉B+树内容的时间为BET=BL*WET

3.定义Buffer更新时间为CHT，长度为BUL，则存在：

当BET+HET>CHT并且BUL<BL+HL时，系统才能保证队列的正常运作，即每次刷新队列池，从数据库查找和jms更新队列时间间隔要远小于队列的消耗时间。

任务队列的更新效率为：CHT/(BET+HET)，即队列每隔一段时间才更新的效率。

任务队列的使用效率为：(BL+HL)/CHT，即系统能够提供的每秒消耗的工作量。

技术方案之十一：核心层之业务活动监控

核心层

核心层主要提供后台业务集中处理中最基本、共性的信息处理、流程调度和相关的管理功能，如任务调度、路由确定、事务一致性管理、任务拆解合并、优先级管理等。核心层对业务处理中的各项工作进行高度的抽象，只管理共性的属性和操作，功能相对简单，具有较高稳定性和处理效率，并对外部服务提供基础调用接口。

业务活动监控

业务活动监控是对系统中的所有核心业务流程进行分级，分类的管理。使用图形化的业务流程管理界面，对业务流程的动态执行过程实时跟踪，对业务流程执行情况进行统计。使用流程监控分析工具，通过易操作的监控界面，实时跟踪流程，监控部门和员工的工作效率；进行实时的负载均衡；对比分析实际流程状况和预定义的性能指标。

基于界面的业务流程的监控，查看流程当前的运行状态，包括：流程是否被激活，流程被执行到哪一个任务环节，某一任务是否已经被处理或正被处理等。

技术方案之十二：服务层之服务分类

服务层

服务层主要体现了SOA体系下的组件复用和业务复用机制。服务的边界定义决定于粒度和耦合度。

粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了变动，势必牵一发而动全身。

耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。

服务分类

SOA提倡服务要粗粒度，即应该具有更大的闭包集合。因此按照粒度来分，可以把服务分解为四种类型：基本服务、组合服务、合成服务和流程服务。

一、基本服务

例如核心层中的SSO验证模块等等。基本服务即是系统提供的最小粒度的服务，或者说是原子服务。这类服务考虑的是利用它们的可重用性，它们是组成一些较大粒度的服务的基础。基本服务可以说是原有系统跟业务需求细分的中间结合点，它既是原有系统能够提供的最细粒度的服务，同时也是要设计的系统最细粒度的服务。

二、合成服务

是基本服务简单的组合，只是为了把具有相同功能但操作不同的业务对象的基本服务组合到一起，形成一个对外提供相同功能的服务。它类似设计模式里面的工厂模式，只要告诉服务接口传进来的是哪一个业务对象，那么服务就能自动识别应该调用哪一个基本服务。

三、组合服务

组合服务是系统里面最复杂的部分，它不是基本服务的简单堆积到一块，它是最大粒度的服务，里面各个基本服务的关系受到工作流程的控制。它是基本服务与工作流程的结合。

四、流程服务

流程服务是业务流程的技术实现载体，根据业务和管理领域划分流程服务域，不同的服务域实现不同的业务和管理流程。流程服务调用基础服务获得业务功能和数据，流程服务之间也可以通过互相调用以实现不同流程的串接。根据业务负载的大小规划每个服务域内流程服务的数量，比如业务推动服务域通常负载较重，则构建多个处理不同类流程的流程服务以分担业务负载。原则上业务流程应独立于应用系统，但在部署一体化套装软件的情况下，应优先使用套装软件提供的业务流程功能，此时对应的服务域内不需部署同类功能的流程服务。

基于上面的理解，我们的服务设计遵循这样的设计思路：先从功能模块分离出基本服务，各个功能模块可以看成是合成服务，由功能模块分离出来的就是基本服务；然后在基本服务的基础上设计组件和业务对象；设计完组件和业务对象之后再来设计组合服务；与提供核心数据和业务功能的基础服务不同，流程服务实现的是有人机交互的长时处理流程，对于短时的全自动不需人工参与的处理流程，一般由基础服务域内基于服务编排成的合成服务来实现。这样不管组合服务需要多少，组合服务多复杂，都可以通过基本服务和工作流程进行各种形式组合起来。而且组合服务经常需要变动，这样的设计能够保证这些变动不会引起太大的改动。因此我们根据功能分主要分为两类：包括录入、验印、扫描、数据核对、版面分类等人工处理服务，以及记账、影像切分、OCR等自动服务。

技术方案之十三：服务层之服务接口模式

服务层

服务层主要体现了SOA体系下的组件复用和业务复用机制。服务的边界定义决定于粒度和耦合度。

粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了变动，势必牵一发而动全身。

耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。

服务接口模式

服务接口主要包括WebAPI、WebService、EJB、RMI等。

一、WebAPI

Web API简单来说，便是透过开放的因特网传输协议，将提供的服务内容以标准的界面来定义，以便进行点对点之间的服务整合。由于运行的平台是在Web架构之上，故常见的技术像是HTTP中的GET/POST、SOAP/HTTP, XML/RPC等，都是主要的组成架构，所定义的数据交换大都是属应用层以上。由于HTTP为企业对外及对内均会开放的传输协议，业已发展成熟，故以HTTP为基础的Web API也降低了应用服务在整合上的门坎。

系统中，Mashup技术机制下，调用每个录入、扫描等业务服务组件时，访问内容都包括了服务提供的页面，因此，在这种情况下采用的糅合技术调用。主要形式为REST，即建立创建、读取、更新和删除（create, read, update, and delete，CRUD）操作,对于HTTP的POST、GET、PUT、DELETE方式，主要用于影像传输、录入等服务接口上。

二、WebService

Web Service主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。 Web Service所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，所以Web Service可以在任何支持这些标准的环境（Windows,Linux）中使用。 SOAP协议（Simple Object Access Protocal,简单对象访问协议）,它是一个用于分散和分布式环境下网络信息交换的基于XML的通讯协议。在此协议下，软件组件或应用程序能够通过标准的HTTP协议进行通讯。它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够被广泛的用户访问。

系统中，对于外记账等接口将采用WebService的方式来调用。

三、EJB

EJB提供了一个标准的分布的、基于 OO 的组件架构屏蔽复杂的系统级功能。EJB的上层的分布式应用程序是基于对象组件模型的，低层的事务服务用了API技术。EJB技术定义了一组可重用的组件：Enterprise Beans，从而简化了用JAVA语言编写的企业应用系统的开发，配置，和执行。你可以利用这些组件，象搭积木一样的建立你的分布式应用程序。

系统中，流程引擎调度在监控等方面将提供EJB的调用方式。

四、RMI

RMI是J2EE的网络机制，允许你编写分布式对象，使得对象的通信范围能够在内存中，跨Java虚拟机，跨物理设备。RMI应用程序通常包括两个独立的程序：服务器程序和客户机程序。服务器应用程序将创建多个远程对象，使这些远程对象能够被引用，然后等待客户机调用这些远程对象的方法。而客户机程序则从服务器中得到一个或多个远程对象的引用，然后调用远程对象的方法。RMI为服务器和客户机进行通信和信息传递提供了一种机制。

系统中，为保证实时性和并发性等性能需求，在队列抓取器服务中将采用RMI的调用机制。

技术方案之十四：服务层之服务调度机制

服务层

服务层主要体现了SOA体系下的组件复用和业务复用机制。服务的边界定义决定于粒度和耦合度。

粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了变动，势必牵一发而动全身。

耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。
服务调度机制

在SOA体系中，实现服务层的调度机制主要包括：服务注册与发现、服务调用、服务监控等。

一、服务注册与发现——UDDI

UDDI 提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。UDDI 构建于网络传输层和基于 SOAP 的 XML 消息传输层之上。诸如 Web 服务描述语言（Web Services Description Language，WSDL）之类的服务描述语言提供了统一的 XML 词汇（与交互式数据语言（Interactive Data Language，IDL）类似）供描述 Web 服务及其接口使用。

系统通过添加分层的功能搭起整个基础，比如使用 Web 服务流程语言（Web Services Flow Language，WSFL）的 Web 服务业务流程描述、安全性、管理和服务质量功能，从而解决系统可靠性和可用性问题。

下图说明了 UDDI 消息的传输，通过 HTTP 从客户机的 SOAP 请求传到注册中心节点，然后再反向传输。注册中心服务器的 SOAP 服务器接收 UDDI SOAP 消息、进行处理，然后把 SOAP 响应返回给客户机。就注册中心条例而言，客户机发出的要修改数据的请求必须确保是安全的、经过验证的事务。

二、服务调用过程

针对不同的服务模型，可以有下列两类调度方式：

1.Mashup--Ajax

Ajax（Asynchronous JavaScript and XML）是一个Web应用模型。它包括几种关注内容的异步加载和呈现的技术：XHTML和用于确定呈现风格的CSS；浏览器为动态显示和交互所提供的文档对象模型（DOM）API；

异步数据交换，通常是XML数据；浏览器端的脚本，主要是JavaScript。

将这些技术结合在一起使用时，它们的目标是通过与内容服务器交换少量的数据为用户创造平滑、良好的Web体验，而不用在用户执行某些操作之后重新加载并重新呈现整个页面。我们可以使用各种Ajax工具包和库为mashup构建Ajax引擎。

2.UUDI查询API与发布API

查询API包含两类调用，使程序能快速地定位候选Web服务及其调用规范，然后在最初调用获得的初始信息的基础上，获得进一步的相关信息的细节。这类以find_xx命名的API提供了多种搜索标准，从而能对注册中心中的数据进行广泛地搜索。另一方面，如果事先已经知道所需数据的关键字，则可以通过直接调用get_xx API得到相应的结构数据(如：businessEntity、businessService、bindingTemplate、tModel)。
发布API包括四个save_xx 函数和四个delete_xx 函数，每个对应于一个UDDI主要结构(businessEntity，binsinessService，bindingTemplate，tModel)。一旦得到授权，一个独立的机构可以注册任意数量的businessEntity 或tModel信息，也可以修改原先发布的信息。API 设计模型很简单：可以更改特定的相关信息，也可以使用save功能来保存新信息。要删除整个结构则可以调用delete功能。详细信息请参见程序员API 规范(Programmer's API Specification)。

三、服务监控

UDDI注册服务中，利用WEB服务管理和安全来监控各项服务：

Web服务管理为Web服务提供了可见性和管理。监控服务可用性，以确保服务质量、执行SLA(服务级别协议)。还负责处理负载均衡、故障替换及Web服务可靠消息传送。

Web服务安全为外部用户或者应用程序访问的Web服务提供了安全环境。包括加密、数字签名、验证、授权、机密性、数据完整性和不可否认性。

技术方案之十五：服务层之服务调用

服务层

服务层主要体现了SOA体系下的组件复用和业务复用机制。服务的边界定义决定于粒度和耦合度。

粒度表示的是一个服务的大小，它可以理解为服务操作的范围，粗粒度的服务，操作的内容广而且杂；细粒度的服务，操作的内容细而且简单。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，服务过细过多，这样必然有一些服务需要组合才能实现一定的功能，那样就增加了服务之间的耦合度，只要其中一个服务发生了变动，势必牵一发而动全身。

耦合代表的是服务与服务之间的关系。SOA的初衷就是为了降低系统各个部分之间的耦合性，使得服务可以重用。但很显然，耦合性是受到服务粒度很大的影响，而且从某种程度上讲，粒度的选择就决定了系统内部的耦合性。

服务调用

服务调用分为同步调用、异步消息、批量文件、批量数据四种形式：

1.同步调用

在通信连接中，同步通信需要一个发送器和一个接收器来协同内部处理过程，这种协同表明同步通信要求高度耦合，通信由发送器和接收器协同完成，发送器和接收器的操作都依赖于请求过程。发送器发送下一个通信请求首先需要拿到接收器发回的应答结果或确认接收信息。

2.异步消息

异步通信并不需要发送器与接收器协同操作来完成通信，其耦合程度比同步通信的低。异步通信主要的实现方式为消息队列，通过这个队列实现这一对系统之间点对点的通信连接。这是异步通信中最简单的一种方式。发送器发送请求至消息队列，请求发出后，发送器就不再关心请求，而是继续操作；消息队列负责将一端进来的入队请求在另一端出队发送至接收器，进而进行处理。

3.批量文件

与上两种实时方式不同的是，批量方式为非实时处理。批量文件方式以批量的方式进行数据导出、生成文件、传输文件与数据装载。

4.批量数据

通过批量数据处理的方式进行数据的导出、传输与装载。

技术方案之十六：业务应用层

面向完整的业务应用处理。对于不同类型的业务应用，定制其特有的处理流程和不同基础服务的组合，对基础服务进行封装，对特有应用功能在继承基础服务的前提下进行定制开发。

如图所示，体现了应用层与服务层的调用关系，新业务首先通过初始化优先级定义、流程定义（业务编码），通过核心层的流程调度及状态机，对服务层进行模块组合，最终把整合的结果数据返回给每个应用系统。

技术方案之十七：技术架构

在上述功能架构中，除了核心层外，应用层及服务层都包括了用户UI界面，因此服务中包括了Mashup所需的WebAPI，需要采用MVC的WebApp框架来实现。整套系统的技术架构如下图所示，根据总体架构的设计思想，自定而下包括了客户端、服务层、核心层、系统软件平台、基础设施。整套技术架构建设在B/S架构模式下。

一、客户端

用户入口，完成UI界面的功能，包括在Windows下的浏览器界面、XPE嵌入式系统的扫描终端、流程定义工具、监控、报表展现等等，通过ActiveX嵌入方式提供浏览器的通用环境，支持B/S和C/S两种方式。

二、服务层

每个服务都包含了业务处理界面，采用典型的MVC框架构成自治系统。服务包括了展现层、控制层、业务层、持久层。服务层框架大部分采用JSF+Spring+Hibernate的WebApp框架，通过OR-Mapping等工具自动生成大部分的代码和框架，规范服务的编制。横向扩展通过Hiberate的二级分布式Cache在WebLogic容器中完成分布式复制和备份。

三、核心层

包括了以流程管理为中心的工作项池、流程定义、流程监控、优先级管理、统计报表，以及统一日志管理，SSO单点登录系统，以及ECM等。

四、系统软件平台

包括了支持各类服务的Weblogic容器及中间件、Documentum 内容管理ECM、Oracle关系型数据库，包括了支撑各类平台所需的RedHat AS4(Linux)、Windows Server 2003、IBM AIX等操作系统。

五、基础设施

包括了以扫描补录中心为代表的高速内部局域网，各类服务运行时的主机服务器、数据库服务器，提供影像存储的SAN等网络存储介质，同时为达到系统的稳定性和提高系统响应性和扩展性而引入的LVS负载均衡器。

技术架构中，层次之间的连接主要包括了Mashup技术及WebAPP框架。

技术方案之十八：Mashup架构

Mashup架构由3个不同的部分组成，它们在逻辑上和物理上都是相互脱离的（可能由网络和组织边界分隔）：API/内容提供者、Mashup站点和客户机的Web浏览器。

一、API/内容提供者

它们是正在进行融合的内容的提供者。为了方便数据的检索，提供者将自己的内容通过Web协议对外提供（例如REST、Web服务和RSS/Atom）。

二、Mashup站点

即mashup所在的地方，是mashup 逻辑所在的地方，而不是执行这些逻辑的地方。从一方面来说，mashup可以直接使用服务器端动态内容生成技术（例如Java servlets、CGI、PHP或ASP）实现为类似传统Web应用程序。另外，合并内容可以直接在客户机的浏览器中通过客户机端脚本（即JavaScript）或applet生成。客户机端的逻辑是直接在mashup的Web页面中嵌入的代码与这些Web页面引用的脚本API库或applet（由内容提供者提供）的组合。mashup使用的这种方法可以称为胖Internet应用程序（RIA），这意味着它们是以交互式用户体验为导向的。客户机端进行数据集成的优点包括：对mashup服务器的所产生的负载较轻（数据可以直接从内容提供者那里传送过来）、具有更好无缝用户体验（页面可以请求对内容的一部分进行更新，而不用刷新整个页面）。

通常，mashup都使用服务器和客户机端逻辑的组合来实现自己的数据集成。mashup应用程序都使用了直接由用户提供的数据，（至少）使一个数据集是本地的。另外，对多数据源的数据执行复杂查询所需要的计算是不可能在客户机的Web浏览器中执行的。

三、客户机的Web浏览器

是以图形化的方式呈现应用程序的地方，也是用户交互发生的地方。正如上面介绍的一样，mashup通常都使用客户机端的逻辑来构建合成内容。

技术方案之十九：WebApp框架

WebApp应用框架主要负责各类服务组件以及业务系统的构建，即内容提供者。WebApp框架主要由展现层，业务层，控制层，数据持久层组成。

整套设计思想中，从数据建模出发采用的是Top-Down设计思路；页面构建采用的是Bottom-Up组装方法；两部分工作最终汇集点在业务层（Services）。通过这种分工的方法，可以最大化地实现从业务建模到页面组件的复用。

WebApp框架包括了表现层的一套组件，框架主要着重的是支持数据库操作，管理数据库连接以及规范架构。

目前框架主要采用的技术为 JSF、Spring、Hibernate。在表现层是JSF，在持久层是Hibernate，框架使用Spring来管理bean之间的依赖关系。WebApp框架是一个全新的软件产品，基于JSF组件模型，可以大量重用JSF的组件；基于Spring的技术进行事务管理；基于Hibernate的数据库持久策略，提供了完整的数据库操作过程。

该框架也具有“自动生成框架”的功能。可以通过Bottom-Up设计理念，从数据模型生成的代码工程。输出是一个搭好的骨架式代码，这个“骨架”分成三层：表示层，业务层，数据持久层。项目开发人员需要进行的是“填充骨架”的程序开发。

WebApp框架最上层是页面部分，它使用JSF技术实现，主要负责页面呈现。

接下来是Backing Bean，Backing Bean也属于表现层，主要进行的是页面组件绑定，页面呈现后台处理，页面动作处理，页面跳转控制。同时负责调用Service层。

Service层，也就是业务层。它负责处理业务逻辑，同时负责调用下层DAO进行数据库操作。本层主要编写相应的业务逻辑，开发人员在本层增加业务逻辑处理代码，已有的代码只是对本表的增、删、改、查，在编写代码时可以调用其他dao中的方法，取对应的数据。

DAO层，属于数据持久层。DAO层主要进行的是针对一个数据库表的CRUD(增删查改)操作。POJO层是数据持久层的一部分。POJO也是数据持久层的一部分，是对数据库表进行ORM映射的。

该框架的优势较为明显：较好的使用技术框架，可以大大提高项目开发速度，提高组件的可充用性，降低开发成本，降低程序员进入门坎。各层次的职能非常明确，确保了程序的可维护性，对于团队分层协作开发提供了牢固的基础，能极大的提高项目开发速度以及应对需求变化的能力。