创建灵活易扩展的J2EE企业应用程序框架

      随着J2EE的飞速发展，已经有越来越多的企业应用程序以J2EE技术为其构建的基石，J2EE本身并不是产品，它只是制定了一套创建企业应用程序的规范，不同厂商根据J2EE规范，创建了符合J2EE规范的产品，这给予了我们更多的选择创建企业应用的平台。
　　
　　一个典型的J2EE的应用，至少应该包括以下三部分：表现层，业务逻辑层和数据持久层，为了更加容易地创建企业应用程序，许许多多的Framework涌现出来，表现层我们可以选择Struts, JSF, Tapestry, WebWork, Velocity等，数据持久层我们可以选择原始的JDBC, ORMapping tools(Hibernate,toplink等),SQLMapper tools(Ibatis),JDO, EJB(Entity Bean)等，业务逻辑层我们可以用普通的JAVA Beans,也可以用EJB(Session Bean)。
　　
　　每种技术都有它的优点与缺点，各自有各自的适用范畴，例如EJB可以很好地进行分布式处理和Object Cache等，但EJB的运行需要EJB容器，开发调试起来很不方便，特别在需求不确定性很大、模型不稳定的情况下，实在是一种重量级别的开发；而JAVA BEAN则是一种很轻量级的方式，开发调试容易，但又很难实现分布式处理。
　　
　　在各种技术纷争的今天，暂时还没有一种技术处于绝对的霸主地位，在这种条件下，我们不能把“赌注“押在任何一种技术上，如何使我们的应用程序有很高的灵活性和易扩展性是我们要仔细研究的课题。
　　
　　在实际的项目中，关于应用程序开发时所用技术的问题，大致存在两种情况，一种是构架师或技术经理没有严格限定用什么技术来实现具体的业务逻辑或者只有简单的开发规范，程序员在开发时，只是依据自己的技术背景，选择自己熟悉的实现方式，这种情况一般属于横向开发，在小的项目中，每个人只做自己负责的一个模块，从表现层，业务逻辑层，一直到数据层，都由同一个人来负责，这种方式给了技术人员更多的自我发挥能力的空间，但不便于后期维护，特别是人员流动频繁的情况下，问题更是严重。
　　
　　第二种情况是构架师或技术经理在项目初期从开发成本，项目需求等等各个方面做出评估，经过几番取舍，确定项目各个层面使用什么样的技术实现方式，按不同层面进行分工，不同的工作人员负责不同层面的技术实现，这种方式比第一种方式要好得多，适合校大项目的开发，但也存在很多问题。
　　
　　在目前各种实现技术纷争的情况下，没有一种技术是万能的，在做取舍时，难免和某一技术或实现方式依赖性过强，同时限定了技术人员个人技术特长的很好发挥，当由于某些原因要更改实现方式时，经常是牵一发而动全身，造成资源的极大浪费和开发成本的提高。
　　
　　所以，在构建企业应用时，应该有个好的技术框架，这个框架应该考虑到各种主流的实现技术，我们既可以根据实际情况进行取舍，同时在从一种实现方式变更为另一种实现方式时，又可以进行平滑过度，让多种技术实现并存，发挥技术人员的最大优势，降低项目成本，提高开发效率。
　　
　　基于SOA的构架
　　
　　 图一
　　
　　SOA(Service Oriented Architecture)，对这一术语我们并不陌生，因为Web service是基于SOA的一种技术，服务的提供者将提供的服务注册到UDDI，其使用者从UDDI上获得服务的描述（WSDL），然后根据服务接口使用服务。
　　
　　Web Service用XML进行消息的传递,通过SOAP绑定在现有的轻量级协议，如HTTP之上，可以透过防火墙，不依赖服务端和客户端具体地实现技术，进行分布式远程调用，它是现有的应用向Internet的延伸。
　　
　　Web service在EAI,B2B,应用到应用的集成等方面体现了巨大的优势，有很多文献介绍Web service，由于这不是本文重点，在此不再赘述。
　　
　　SOA的优势在于降低了服务的提供者与使用者之间的耦合性，服务的提供者将自己提供的服务注册在中介那里，服务使用者先通过中介查找自己所需服务，使用者获得的是服务接口，但并不知道服务的具体实现，它根据调用接口调用服务，这样即使服务的实现方式发生了变化，只要供使用者调用接口没有改变，服务使用者就不会受到任何影响，这种思想正是我们应该学习和借鉴的地方。
　　
　　那么既然Web service是基于SOA的，我们的企业应用是不是就可以完全构架在Web service上呢？我们并不建议这么做，Web service对于企业内部的应用并不太适合，在一个应用内部使用Web service，系统大量的资源花费在进行XML消息的解析和进行远程调用上，造成系统运转缓慢。
　　
　　当然，从某种意义上讲，EJB也是SOA的一种实现，服务的提供者把服务注册在JNDI上，使用者通过JNDI找到自己想要的服务，通过远程接口使用服务，但EJB的运行需要EJB容器，开发调试起来不方便，特别对于需求经常变化的系统，进行EJB调试的时间会更久。
　　
　　我们所需要的是一个轻量级的构架，能兼顾各种主流的技术，但又不依赖具体的某个实现方式，当实现方式从一种技术变更为另一种技术时，对于服务的使用者来说几乎没有影响，从而实现客户端和服务器端的松耦合，这样，我们的表现层，业务逻辑层和数据持久层都可以依据实际需求情况与偏好随意选择各种实现方式。
　　
　　MiniSOA构架介绍
　　
　　MiniSOA设计思想
　　
　　MiniSOA是以SOA思想为指导的一个极其轻量级的构架，其主旨是降低服务使用者和提供者之间的耦合度，使现在流行的多种技术能够很好的并存，并充分发挥各自的优势，技术人员能够发挥自己的特长，用自己熟悉的技术来实现业务逻辑，同时应用程序某些层面能够方便的在不同的实现技术之间进行切换，而不会对其他层面造成影响。
　　
　　MiniSOA没有创建一个新的编程模式，没有Web service,EJB那么工业化的庞大，它只是通过XML配置把应用组件装配在一起，通过必要的缓存，提高组件的运行效率，自动管理组件运行时的事务、环境参数等信息，使其能更有效的运行，同时，提供多小组的团队开发的支持，并方便进行单元测试，使开发人员集中精力开发业务逻辑，提高劳动生产率。
　　
　　MiniSOA概述
　　
　　为了降低表现层，业务层和数据持久层等各个层面之间的耦合性，各个层面使用其他层面提供的服务时，不是直接去使用服务对象，而是通过服务中介，查找定位服务接口，通过接口来访问服务，服务提供者可以通过各种方式来实现服务接口，然后把提供的服务注册到服务中介，服务中介是服务使用者和服务提供者之间进行通讯的桥梁，可以在服务中介上做一些其他方面的控制，如事务，安全等。
　　
　　表现层作为业务层的使用者，在使用业务层提供的服务时，通过Business Service Manager这个中介来查找和使用服务接口；业务层是表现层的服务提供者，它把通过各种方式实现的服务对象注册到Business Service Manager,供表现层对象使用，同时业务层也是数据持久层服务的使用者，它通过Data Access Object Manager这个中介来使用数据持久层提供的服务；同样数据持久层把对数据库，文件等资源的存取进行封装，把以各种方式提供的服务对象以接口的形式注册到Data Access Object Manager,供业务层对象使用。
　　
　　MiniSOA包括业务层和数据持久层两部分组件，业务层的核心组件是ServiceManager, 它是表现层和业务层进行交互的桥梁；数据持久层的核心组件是DaoManager,它是业务层和数据持久层进行交互的桥梁。
　　
　　根据数据模型和业务需求，定义提供的服务接口后，开发人员用自己熟悉的技术开发接口的实现组件，经过单元测试后，把服务接口、实现组件和相应的事务，环境参数等信息配置到dao-conf.xml,service-conf.xml文件，服务使用者就可以通过ServiceManager,DaoManager来查找所需的服务接口，调用服务方法。
　　
　　MiniSOA 业务层核心组件简介：
　　
　　ServiceFacotry：作为表现层调用业务层的Facade,它读取service-factory-conf.xml配置文件，创建用于各个模块的ServiceManager，便于多个开发小组的分工合作。 Service-factory-conf.xml 实例：
　　
　　module1
　　module1-service-conf.xml
　　module2
　　module2-service-conf.xml
　　
　　通过service-factory-conf.xml配置文件，每个模块可以使用和本模块相关的service配置，适合多个开发小组共同开发，有效避免了资源冲突。
　　
　　ServiceManager, ServiceManagerBuilder：ServiceManagerBuilder用于读取serivice-conf.xml配置信息，创建每个service对象使用的环境对象ServiceContext，返回用于服务使用者查找具体服务的ServiceManager接口。
　　
　　Service-conf.xml实例：
　　
　　cglib-enabled="true"
　　dao-config="dao-hibernate-conf.xml"
　　/>
　　demo.Order
　　demo.OrderImpl
　　smtphost
　　<value>mail.mycom.com
　　mailfrom
　　<value>from@mycom.com
　　sendMail
　　false
　　*
　　true
　　...
　　
　　供使用者使用的每个service分别配置在标签中，cglib-enable属性用于配置本模块的services是否要用cglib来增强Proxy功能，dao-config属性指定service使用的dao配置信息，runas属性设置service的实现方式：(java-bean,remote-ejb,local-ejb),singleton属性用于配置service是否是单一实例的，如果singleton为true,则此service在第一次创建和使用后，被ServiceManager缓存起来,其他Client再请求此service时，则使用被缓存的对象，而不会再被创建，singleton为true的service是无状态的，不能保持每个Client的状态信息，相反，singleton为false的service是有状态的，每个Client都使用自己的service对象，它们之间互不影响。

查看本文来源