普元SOA中间件EOS平台解决方案

　　对于一个企业应用而言：

　　1.从业务表现的角度是由不同的功能(或功能模块，如客户管理、产品管理、订单管理等等)组合而成的

　　2.从系统结构的角度则每个功能又分为页面(用户界面)、流程(界面流转控制)、业务处理、数据等不同的层次

　　3.从技术实现的角度这些层次最终能够运转起来满足功能的要求又依赖于代码、数据和运行环境等软件基本要素。

　　以下是一个企业应用典型的构成要素图：

　　实际上，一个企业应用系统的应用架构就是通过功能、层次、软件要素这三个相互影响的维度有机结合形成的。没有人怀疑架构对于企业应用的重要意义，某种意义上，架构可以说是系统的灵魂。良好的应用架构取决于对这三个维度的有效合理的切分和组合。

　　传统的J2EE应用项目，由于已经提供了JAVA程序语言和对象级接口的数据传递方式和基于JVM的java运行环境这些软件要素，应用架构需要考虑的是从软件层次上主要遵循MVC的设计模式，在功能实现上通过合理的对象设计以及模式应用来进行保证。

　　这就意味着，对一个J2EE企业应用项目组而言，既需要非常熟悉相关的业务领域知识，同时对技术环境的熟悉程度和把握能力都要求较高，这样对项目的实施造成了很大的压力。

　　所以，在Java的开源世界里，有很多技术组织在研究架构技术，我们常见的像Struts、Spring、Hibernate都是属于这种范畴，这些开源架构因良好解决了我们应用架构设计的很多问题而备受推崇，然而，我们也清醒认识到，这些架构要么只解决了部分层次的问题(如Strtus、Hibernate等)、要么就是提供了完整架构(如Spring)，但没有与之配套的完整的工具的支持，使得在项目中，整合这些架构成为项目的应用架构并为之建立与之匹配的一套开发支持环境成为了新的问题，对于项目完成后的应用可维护性更是无暇顾及。

　　面向构件的架构提供一套体系完整的应用架构：

　　1.从应用功能维度上，是通过构件包来承载业务功能的，一个应用可以由多个构件包构成，每个构件包实现了一组具有相关性的业务功能，实际上可以将构件包理解为业务功能分解后的功能模块。

　　2.从软件层次维度上，每个构件包又按照MVC的思想抽象形成了不同层次的构件元素，由上而下包括页面构件层、展现构件层、业务构件层、运算构件层、数据构件层，每个层次具有鲜明的特征，完成相应的使命，同时引入了具有很强扩展能力的XML总线技术，实现各个层次之间的数据传递，并提升各个层次数据的扩展能力。构件层次结构图如下：

针对以上构件层次结构图中的各个要素的作用和特征详细描述如下：

　　数据构件层采用X-R Mapping技术，主要实现与企业系统数据库的数据实体映射，达到数据持久层管理的目的，降低应用与数据库结构和数据库类型的耦合度，提升企业应用在数据层次的扩展能力。另外，数据层还提供了数据字典的管理能力，它使得应用层的业务配置具有强大的灵活性，基本数据属性的变化都可以通过参数配置完成。

　　运算构件层实际上是对计算机处理操作的构件化封装，因为应用的业务功能最终都是通过计算机的计算能力完成的，计算处理一定是与代码相关的，而且依赖于具体的计算机语言，正因为这个层次具有与业务无关性，是可以预先实现的，面向构件技术体系可以提供预制的构件库，使得在开发一个企业应用时，基本上业务处理所需要的计算功能都已经提供了。当然，构件可以进行扩展，在即使应用中不够的情况下，也可以使用JAVA开发出新的运算构件。总体而言，在开发一个企业应用过程中，在这个层次上花费的工作量将变得少而且简单。

　　业务构件层主要实现应用逻辑的处理过程，其实现方式是通过构件组装环境将许多运算构件通过可视化方式组合成复杂的业务处理过程(应用逻辑)，提高开发、测试、维护效率。传统方式下采用代码实现业务逻辑的过程变成了画业务流程图的过程。也使得了应用的逻辑与具体的代码实现进行了有效的分离。

　　展现构件层是连接用户界面与业务处理的中间层次，例如页面的某个处理请求(按钮或者连接)将会激活相应的展现构件，展现构件将用户提交的数据传递给相应的业务构件进行调用，根据调用的返回，再定位到另一个用户界面，并把业务处理的返回数据传递到相应页面上。

　　页面构件层主要提供对应用系统用户界面的支持。

　　XML数据总线是面向构件技术体系一个很重要的技术特性，通过XML的DOM方式，封装了应用的三大数据区：Session数据区(SessionContext)、Request数据区(RequestContext)、业务处理数据区(BizContext)，构成整个应用的数据总线区。这样，在面向构件应用中，各种数据都被规范成了XML的格式，而数据的传递则采用Xpath的寻址方式。而这种数据传递方式使得应用开发中对接口的处理与原来基于对象接口的方式有了较大差异。构件的接口相当于确定了接口数据在总线中的固定位置，运行时根据不同的实例，对应位置上的内容可能不一样，而传统的接口只确定接口的对象类型和对象的变量名，在调用具体接口时完成对象的实例化。

　　通过上面的描述，我们可以看到这个架构的2个重要特点：

　　1)应用逻辑与代码是相对分离的。应用系统中的应用逻辑是体现企业业务特点和经营管理理念的，是企业业务知识和管理流程的载体，而企业的业务内容和管理模式是动态成长的，这就需要对应用系统进行维护以适应这种变化。当应用逻辑独立于具体的代码实现后，通过图形化的方式表达的应用逻辑就变得易于进行调整以适应新的变化。

　　2)应用逻辑与数据是相对分离的。传统的方式下，代码、业务逻辑、数据是三位一体的，当数据通过XML总线方式独立于应用逻辑后，将使得应用系统在数据的扩展能力上有了较大的提升。

　　仅仅有这样一个应用架构是不够的，需要有与之配套的工具或环境的支持，这种支持，就是由EOS产品的各个部分来提供的，例如，通过EOS Studio，能够实现基于构件包的各种层次构件的可视化开发;通过EOS Server，实现对可视化构件的解释，使之成为J2EE环境的标准分布式应用，另外，实现对运行时数据总线的管理;通过EOS Manager，实现对应用的部署和管理、监控。

　　当这种面向构件的架构与一体化的配合环境结合起来后，EOS的优势就显现出来：

　　分层的构件体系和XML总线使得应用系统架构具有了良好的开放性和扩展能力

　　一体化可视化的开发运行环境屏蔽了复杂的技术细节

　　提高了开发效率

　　方便于系统的后期维护