随着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调试的时间会更久。
我们所需要的是一个轻量级的构架，能兼顾各种主流的技术，但又不依靠具体的某个实现方式，当实现方式从一种技术变更为另一种技术时，对于服务的使用者来说几乎没有影响，从而实现客户端和服务器端的松耦合，这样，我们的表现层，业务逻辑层和数据持久层都可以依据实际需求情况与偏好随意选择各种实现方式。
随着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，由于这不是本文重点，在此不再赘述。
