J2EE架构是当前主流的架构之一，目前大多数企业采用J2EE技术的结构设计与解决方案。J2EE体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台，J2EE降低了开发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持，完全支持Enterprise JavaBeans，有良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能。
高效的开发: J2EE允许公司把一些通用的、很繁琐的服务端任务交给中间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上，相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件服务:
状态管理服务 -- 让开发人员写更少的代码，不用关心如何管理状态，这样能够更快地完成程序开发。
持续性服务 -- 让开发人员不用对数据访问逻辑进行编码就能编写应用程序，能生成更轻巧，与数据库无关的应用程序，这种应用程序更易于开发与维护。
分布式共享数据对象CACHE服务 -- 让开发人员编制高性能的系统，极大提高整体部署的伸缩性。
支持异构环境: J2EE能够开发部署在异构环境中的可移植程序。基于J2EE的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合理的基于J2EE的程序只需开发一次就可部署到各种平台。这在典型的异构企业计算环境中是十分关键的。J2EE标准也允许客户订购与J2EE兼容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制订整个方案所需的费用。
可伸缩性: 企业必须要选择一种服务器端平台，这种平台应能提供极佳的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于J2EE平台的应用程序可被部署到各种操作系统上。例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器。J2EE领域的供应商提供了更为广泛的负载平衡策略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。
J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。传统的J2EE多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是 J2EE 典型的四层结构:
Ø 运行在客户端机器上的客户层组件
Ø 运行在J2EE服务器上的Web层组件
Ø 运行在J2EE服务器上的业务逻辑层组件
Ø 运行在EIS服务器上的企业信息系统(Enterprise information system)层软件
通常认为，J2EE平台就广泛的认为是这个架构，运行在J2EE服务器上的EJB容器可以认为是此结构的核心，EJB容器管理着所有EJB的执行，以及EJB的生命周期，并且为EJB提供所有系统级的服务。EJB组件则负责接受，处理WEB容器的客户请求和连接提供整个企业使用的数据，服务的EIS层。
此“经典”架构中，所有的数据访问都要通过entity bean，业务对象都是带远程接口的无状态session bean，运行在EJB容器中。EJB中包含了各种服务（比如声明式的事务管理），而且提供了一个共享的中间层，可支持可支持各种类型的J2EE客户端。但结构中应用性能和开发开销的负担很重，一些负载来在于EJB，而很大还是与分布式架构的特性有关。此外为了分布化，牺牲了OO原则，并且难以测试，因为业务逻辑通常编写在EJB的实现类中，而这些类完全依赖于EJB容器的。
此“经典”架构的一种改进，便是把远程EJB替换为本地EJB，实现了架构的重用，解决了分布化的种种问题。但架构还是相当的复杂。EJB的很多负担还是存在，从EJB中获得益处反而不多。
所以随着企业级应用开发的不断复杂，对架构设计的要求也会提出新的要求:
ü 架构简单，但功能强大。
ü 架构可以通过配置WEB容器集群来达到横向扩展。
ü 在不同的应用服务器之间具有高移植性。
ü 便于在应用服务器之外进行业务对象的单元测试，而且，一些集成测试甚至可以让一些轻量级容器（如Junit）来完成。
为了解决经典架构中有EJB引起的一系列问题以及满足不断发展的企业应用，提出了非EJB架构的“轻量级容器”。轻量级容器与EJB架构都是有容器管理业务服务对象，然后再围绕着这个服务层组织整个架构。但是业务对象不是运行在EJB容器中，而是运行在“轻量级容器”中。轻量级容器并没有和J2EE绑定，所以它既可以运行在WEB容器里，也可以在一个标准应用程序中运行，如必要也可以运行在EJB容器中。这个容器也没有和servlet API绑定?D?D这一点与MVC结构的WEB框架不同。轻量级容器的启动开销很小，而且无需EJB的部署。
轻量级容器提供了一种管理、定位业务对象的办法。用不着JNDI寻址、定制服务器之类的额外辅助；轻量级容器为应用对象提供注册服务。其较之EJB容器而言，不仅功能强大，而且避免了容器强制业务对象采用特定的接口，最低程度的降低了侵入性，实现了效果极佳的架构重用。
轻量级容器中所有的Java类都运行在同一个虚拟机中。
WEB层是由MVC框架提供的（Struts或WebWork，或Spring架构的MVC结构）
业务对象是POJO，运行在轻量级容器里。AOP的拦截机制能够增强业务对象，从而实现企业级服务。与EJB容器不同，业务对象不依赖于容器的API，所以这些对象在容器外也可以使用，更利于单元测试。业务对象仅仅通过接口来访问，当更改具体业务对象的实现类后，业务对象无需修改。实现了面向接口编程。
数据访问机制可以通过轻量级的O/R Mapping，该层能提供透明的持久化，该持久层实现了对数据访问方式JDBC的轻量级封装。
MVC Framework
POJO 通过AOP实现业务服务
O/R Mapping 层
RDBMS
其他资源
WEB 层
中间层
EIS层
典型的轻量级架构如下图所示:
此轻量级架构通过AOP为POJO提供声明式的企业级服务，具备了EJB的主要特性，同时避免了EJB的复杂性。
轻量级架构（如Spring）不但提供“扩展”的能力，也提供“收缩”的能力，当一个结构功能相对简单的系统可以直接使用容器提供的声明式事务管理，无需使用JTA。而需要使用JTA管理事务时，无需修改代码，只需要在XML文件中配置即可。
轻量级架构WEB设计
从J2EE应用程序自身的特点看，很多的系统都是基于WEB的应用，所以架构应提供完善且易于扩展的WEB层接口，与下面的控制，业务逻辑结构形成明确的逻辑分层。
WEB层的发展从最初的JSP/Servlet到现在业界流行的基于MVC框架的WEB表示层设计。轻量级架构的表示层同样是基于MVC框架的表示方法。
一个清晰的WEB层，将流程控制和业务对象的调用与数据的展示分开。WEB层启动用户动作的业务处理以及显示结果之外，不应该包含其他的Java代码，应该只包含WEB专用的控制逻辑，较少的涉及业务逻辑。
基于MVC的框架将WEB层分成三类对象：
1. 模型 (Model) 对象，提供要显示的数据，提供控制器和视图之间交互的规则。
2. 视图(View)对象，显示由控制器提供的模型对象。通常由JSP建立，包含扩展自定义标签库，可以简化创建完全国际化用户界面。
3. 控制器(Controller)对象，接受用户输入的信息，并调用业务逻辑去创建和更新模型对象。
当前流行的WEB框架：Struts，WebWork2，以及Spring的WEB MVC框架。
l Struts框架：
Struts有一组相互协作的类、Serlvet以及Jsp TagLib组成。基于Struts构架的web应用程序基本上符合JSP Model2的设计标准，可以说是MVC设计模式的一种变化类型。Struts是一个web framwork，而不仅仅是一些标记库的组合。但 Struts 也包含了丰富的标记库和独立于该框架工作的实用程序类。
Struts有自己的控制器，同时整合了其他的一些技术去实现模型层和视图层。在模型层，Struts可以很容易的与数据访问技术相结合，包括EJB,JDBC和Object Relation Bridge。在视图层，Struts能够与JSP, Velocity Templates,XSL等等这些表示层组件想结合。
Struts的体系结构
struts framework是MVC 模式的体现，下面是各个部分工作的原理。
从视图角度（View）
首先，Struts提供了Java类org. apache.struts.action.ActionForm，开发者将该类细分来创建表单bean。在运行时，该bean有两种用法：
1. 当JSP准备相关的HTML，表单以进行显示时，JSP将访问该bean(它保存要放入表单中的值)。那些值是从业务逻辑或者是从先前的用户输入来提供的。
2. 当从Web浏览器中返回用户输入时，该bean将验证并保存该输入以供业务逻辑或(如果验证失败的话)后续重新显示使用。
其次，Struts提供了许多定制JSP标记，它们的使用简单，但是它们在隐藏信息方面功能强大。例如，除了bean名称和给定bean中每个段的名称之外，页面设计者不需要知道有关表单bean的更多信息。
从模型角度（Model）
Struts虽然不直接有助于模型开发。在Struts中，系统模型的状态主要由ActiomForm Bean和值对象体现。
从控制器角度（Controller）
在Struts framework中， Controller主要是ActionServlet，但是对于业务逻辑的操作则主要由Action、ActionMapping、ActionForward这几个组件协调完成（也许这几个组件，应该划分到模型中的业务逻辑一块）。其中，Action扮演了真正的控制逻辑的实现者，而ActionMapping和ActionForward则指定了不同业务逻辑或流程的运行方向。
下面是Struts中各组件的关系：
Struts的基本组件关系图
l Spring MVC框架
Spring WEB MVC，同Struts类似，是基于MVC的WEB框架。在Spring WEB MVC使能应用中，能够直接使用Spring的IoC和AOP的功能。借助于它提供的DispatcherServlet 控制器（类似于Struts中的org. apache.struts.action.ActionServlet控制器），能够统一分发Web请求。在整个Spring Web MVC中，DispatcherServlet是最为重要的组件之一。直接在Web.xml中配置使用。
HttpServlet
HttpServletBean
ResourceServlet
FrameworkServlet
DispatcherServlet
Spring工作过程：
l 一旦客户Http请求到来，DispatcherServlet将负责分发它。DispatcherServlet可以认为是Spring提供的前端控制器。所有的客户请求都需要经过它的统一分发。
l 在DispatcherServlet将请求分发给Spring Controller之前，需要借助于Spring提供的HandlerMapping定位到具体的Controller。
l Spring Controller 将处理来自DispatcherServlet的请求。Controller相当于Struts中的Action。可以接受HttpServletResquest和HttpServletResponse。Spring Controller需要为用户处理请求，同时实现线程安全和重用性。
l 一旦Controller处理完用户的请求，则返回ModelAndView对象给DispatcherServlet前端控制器。ModelAndView包含了模型和视图。
l DispatcherServlet返回的视图可以是视图的逻辑名，此时需要借助于Spring的视图解析器（ViewResolver）在Web应用中查找View对象。从而将结果返回给用户。
轻量级架构业务O/R Mapping设计
在分层的软件结构中，业务逻辑层代表了业务数据和业务逻辑。域对象位于业务逻辑层，实体域对象代表应用运行时的业务数据，它存在于内存中，过程域对象代表应用的业务逻辑。数据库用于存放永久性的业务数据。业务数据在内存中表现为实体域对象形式，而在关系数据库中表现为关系数据形式。数据访问代码负责把实体域对象持久化到关系数据库中。
表示层
业务逻辑层
实体域对象
（业务数据）
过程域对象
（业务逻辑）
持久化层（O/R Mapping中间件，负责封装数据访问细节）
数据库层
O/RM模式：在单独的持久化层由ORM中间件封装数据访问细节，ORM中间件提供对象-关系映射服务，当向数据库保存一个域对象时，把业务数据由对象形式映射为关系数据形式；当从数据库加载一个域对象时，把业务数据由关系数据形式映射为对象形式。
持久化层封装了数据访问细节，如事务管理，执行SQL语句，关闭数据库连接，设置数据缓存等功能，可以从JDBC编码中解脱出来。
目前的持久层框架，大多建立在面向对象的设计思想之上，为业务逻辑层提供了面向对象的API。
基于Java的跨平台特性，系统可以在不同的操作系统之间切换。但由于数据库的差异，使系统的移植变得复杂，难于实现。但设计良好的持久层框架，很好的隔离性，提供了跨越不同数据库的支持，只需修改代码的配置文件，即可实现数据库的切换。
目前开源的的持久化中间件Hibernate，充分体现了上面持久层的设计理念，并在实际应用中提供了大量的补充。
Hibernate提供了强大，高性能的对象到关系数据库的持久化服务。利用Hibernate，可以按照java的语义进行持久层开发。Hibernate提供的HQL是面向对象的查询语言，它在对象型关系数据库之间构建了一条快速，高效，便捷的沟通渠道。
Hibernate中间件特性可以用下图显示：
上层业务逻辑
持久化层（Hibernate）
网上购物
数据库系统
网上银行
数据库系统
电子邮件系统
数据库
下图是Hibernate系统结构图：
以下是图中一些对象的定义：
SessionFactory (net.sf.hibernate.SessionFactory)
对编译过的映射文件的一个线程安全的，不可变的缓存快照。它是Session 的工厂。
会话，Session (net.sf.hibernate.Session)
单线程，生命期短促的对象，代表应用程序和持久化层之间的一次对话。封装了一个JDBC 连接。也是Transaction 的工厂。持有持久化对象的缓存。
持久化对象（Persistent Object)及其集合(Collection)
生命期短促的单线程的对象，包含了持久化状态和商业功能。它们可能是普通的JavaBeans，唯一特别的是他们现在从属于且仅从属于一个Session。
临时对象(Transient Object)及其集合（Collection）
目前没有从属于一个Session 的持久化类的实例。他们可能是刚刚被程序实例化，还没有来得及被持久化，或者是被一个已经关闭的Session 所实例化的。
事务，Transaction (net.sf.hibernate.Transaction)
单线程，生命期短促的对象，应用程序用它来表示一批工作的原子操作。是底层的JDBC,JTA 或者CORBA 事务的抽象。一个Session 可能跨越多个Transaction事务。
ConnectionProvider (net.sf.hibernate.connection.ConnectionProvider)
JDBC 连接的工厂和池。从底层的Datasource 或者 DriverManager 抽象而来。对应用程序不可见。
TransactionFactory (net.sf.hibernate.TransactionFactory)
事务实例的工厂。对应用程序不可见。
完善的J2EE架构Spring
1. Spring－AOP
传统的编程技术，采用分解的方式将一个软件系统划分为相对较小的、易于分析、理解的模块，如果这些模块仍难以分析、理解，则迭代的将其分解为更小的模块，直到这些模块可以容易的分析、理解、设计与编码。通过对这些模块进行分析，设计，然后使用相应的编程语言实现这些模块，再以编程语言所定义的方式将这些模块组装起来，形成最终的软件系统。面向对象编程中，通过分析，抽象出一系列具有一定属性与行为的对象，并通过这些对象之间的协作完成系统的功能。
传统的编程技术倾向于按照功能或行为对软件系统进行分割，这个分割的结果是实现某一功能的模块。但在编程实践中，人们认识到，软件系统中有些行为无法封装在单个的模块中，例如日志记录、事物处理、对上下文敏感的错误处理、性能优化等等。通常这些功能与行为不实现系统的业务功能，但辅助这些功能的实现，并散布在实现系统功能的诸多模块中，从而造成代码的纠结，这使得实现系统功能的模块的代码难于阅读、理解、调试、维护和扩展等，并使得纠结的代码难于复用。如果将实现系统业务功能的模块看作系统的纵向分解单元，那么上述分散在功能模块中的功能与行为就形成了一种横向的方面（Aspect），方面与模块形成了横切（Crosscutting），从而造成传统的编程技术无法将方面模块化，造成两种代码纠结（Tangling）在一起。
因此，需要一种新的编程思想，对系统中的横切方面进行处理，解决由此造成的代码纠结问题，并使方面可模块化，促进功能模块与方面彼此的复用。
面向方面编程（Aspect-Oriented Programming，AOP）就是这样一种区别于传统编程技术的新的编程思想， AOP正是基于方面与模块形成横切，造成代码纠结这一观察提出的，并提出了一种新的编程思路来解决这一问题。
AOP的基本思想
如前所述，造成代码纠结的原因在于传统编程技术中，软件系统中非业务功能实现的代码无法模块化，散布在实现业务功能的代码中造成的。这里，引入关注点（Concern）的概念，关注点就是软件系统中需要解决的问题。软件系统的业务功能组成了核心关注点（Core Concerns），也就是软件系统要解决的问题，而诸如日志记录，事物处理等关注点就形成了横切关注点（Crosscutting Concerns），因为，这些关注点散布在核心关注点中，相互形成了横切的关系，横切关注点也就是前面提到的方面这一概念。
鉴于此，AOP提出的解决方法是对这两种相互横切的关注点分别进行编码，使用传统的编程语言对核心关注点编程，使用面向方面的编程语言对横切关注点，也就是方面进行编程。然后使用一种机制将这两种代码自动混合起来，形成最终的代码。在这里，面向方面的编程语言可以是已有编程语言的扩展或是一种新的语言，设计用于编写方面的代码。而将两种代码混合的机制称为织入（Weaving），实现这一机制的工具称为织入器（Weaver）。因此，对方面单独编码，并通过适当的织入机制使两种代码混合，构成了AOP解决代码纠结问题的基石。
如前所述，织入是实现AOP的一个重要机制，织入的实现机制有多种，基本上可以分为两类，静态织入与动态织入。静态织入是指在业务功能代码中的适当位置，比如某段代码执行前，或执行后，将方面中的编码插入，从而形成混合的编码。方面中的编码在程序运行前，已被内联至业务功能代码中，因此，代码可以被优化，从而使织入产生的开销最小化，最终产生的混合代码，其执行速度接近为使用AOP方式编写的代码。但是，静态织入无法做到在程序运行时，根据运行上下文动态的决定插入的方面代码，动态织入则可以做到这一点。动态织入可以在程序运行时，根据上下文决定调用的方面，它们的先后顺序，增加或删除一个方面等。
而根据织入的时间，又可以分为三类，编译时，载入时，运行时。编译时织入可以在编译前进行预处理，将两种代码自动混合，将方面中的代码自动插入到功能模块代码的合适位置处，也可在编译后，对编译后的代码进行操作。载入时织入是在代码载入时，实现代码的织入。运行时织入则在运行时，根据对方法的调用执行适当的方面代码以实现织入。
以AOP的Java实现为例，包括使用反射（Reflection），基于动态代理（Dynamic Proxy）或其它机制的拦截框架，基于元数据（Metadata）的操作，以及类载入时对字节码的操作等。
2. Spring－IOC
Inversion of Control 容器
Spring设计的核心是 org.springframework.beans 包, 它是为与JavaBeans一起工作而设计的。 这个包一般不直接被用户使用，而是作为许多其他功能的基础。下一个层面高一些的抽象是"Bean Factory"。一个Spring bean factory 是一个通用的Factory，它使对象能够按名称获取，并且能管理对象之间的关系。
Bean factories 支持两种模式的对象：
Singleton：在此模式中，有一个具有特定名称的共享对象实例，它在查找时被获取。这是默认的，而且是最为经常使用的。它对于无状态对象是一种理想的模式。
Prototype：在此模式中，每次获取将创建一个独立的对象。例如，这可以被用于让用户拥有他们自己的对象。
由于 org.springframwork.beans.factory.BeanFactory是一个简单的接口，它能被大量底层存储方法实现。你能够方便地实现你自己的BeanFactory，尽管很少用户需要这么做。最为常用的BeanFactory定义是：
XmlBeanFactory： 可解析简单直观的定义类和命名对象属性的XML结构。 我们提供了一个DTD来使编写更容易。
ListableBeanFactoryImpl：提供了解析存放在属性文件中的bean定义的能力，并且可通过编程创建BeanFactories。
每个bean定义可能是一个POJO（通过类名和JavaBean初始属性定义），或是一个FactoryBean。FactoryBean接口添加了一个间接层。通常，这用于创建使用AOP或其他方法的代理对象：例如，添加声明性事务管理的代理。
BeanFactories能在一个层次结构中选择性地参与，继承ancestor（祖先）的定义。这使得在整个应用中公共配置的共享成为可能，虽然个别资源，如controller servlets，还拥有他们自己的独立的对象集合。通过BeanFactory概念，Spring成为一个Inversion of Control的容器。
Inversion of Control背后的概念经常表述为Hollywood原则的：“Don’t call me， I’ll call you。” IoC将控制创建的职责搬进了框架中，并把它从应用代码脱离开来。使用IoC容器则只需指出组件需要X对象，在运行时容器会提供给它。容器是通过查看方法的参数表（例如JavaBean的属性）做到的，也可能根据配置数据如XML。
IoC有几个重要的好处：
因为组件不需要在运行时间寻找合作者，所以他们可以更简单的编写和维护。在Spring版的IoC里，组件通过暴露JavaBean的setter方法表达他们依赖的其他组件。这相当于EJB通过JNDI来查找，EJB查找需要开发人员编写代码。
同样原因，应用代码更容易测试。JavaBean属性是简单的，属于Java核心的，并且是容易测试的：仅编写一个自包含的Junit测试方法用来创建对象和设置相关属性即可。
一个好的IoC实现保留了强类型。如果需要使用一个通用的factory来寻找合作者，就必须通过类型转换将返回结果转变为想要的类型。使用IoC，在代码中表达了强类型依赖，框架将负责类型转换。这意味着在框架配置应用时，类型不匹配将导致错误；在代码中，无需担心类型转换异常。大部分业务对象不依赖于IoC容器的APIs。这使得很容易使用遗留下来的代码，且很容易的使用对象无论在容器内或不在容器内。例如，Spring用户经常配置Jakarta Commons DBCP数据源为一个Spring bean：不需要些任何定制代码去做这件事。一个IoC容器不是侵入性的：使用它并不会使代码依赖于它的APIs。任何JavaBean在Spring bean factory中都能成为一个组件。
最后是，IoC 不同于传统的容器的体系结构，如EJB，应用代码最小程度地依靠于容器。这意味着你的业务对象可以潜在的被运行在不同的IoC 框架上??或者在任何框架之外??不需要任何代码的改动。
SpringFramework是一个采用了反转控制（Inversion of Control, IoC）策略的基于J2EE的轻量级应用框架。SpringFramework的核心是IoC容器，对于其它应用，如数据库访问，日志等，SpringFramework多使用现有的、成熟的框架。SpringFramework采用了模块化的方式，各模块可以共同使用，也可以单独使用其中的一个模块， SpringFramework的一个模块提供了对动态AOP的支持，SpringFramework中提供的声明式事务管理就是基于动态AOP的。
SpringFramework中AOP的实现基于动态代理（Dynamic Proxy）， 动态代理源于代理模式，即通过接口实现对业务对象的访问，但动态代理无需为每一个需代理的业务对象静态的生成代理对象，只需提供需要代理的接口与代理实现，就可以在运行时动态的生成代理对象，代理对上述接口的访问，同样的机制也使用于对类的代理，使用类似于修饰者的模式，通过子类化实现。SpringFramework默认使用JDK提供的动态代理机制，此时，业务对象通过接口编程，若需要代理对类的访问，则需要使用CGLIB，这是一个开源的动态代理实现。
SpringFramework的AOP实现不同于AspectJ与AspectWerkz，它不是完全的AOP实现，而是设计用于在应用服务器环境下实现AOP，与SpringFramework的IoC容器配合使用。SpringFramework中参考，切入点与方面均由普通Java对象实现，其中连接点模型与AspectJ相同，目前只提供对方法调用的拦截。有4种类型的参考，分别为方法调用时，之前，返回时与抛出异常时，通过实现SpringFramework的参考接口可以自定义参考类型。在SpringFramework中，方面称为Advisor，是一个包含参考与切入点的Java类。像其它由IoC容器管理的组件一样，参考，切入点与方面也由IoC容器管理 ，由XML配置文件定义。配置的内容包括业务对象的接口与实现，自定义的或由SpringFramework提供的切入点与参考类，或使用Adviser类取代单独的切入点与参考类。在运行时，通过IoC容器进行名称查找，就可以由容器使用代理机制自动产生代理对象，并在符合切入点定义的连接点处执行参考。SpringFramework除自身实现的AOP框架外，还在寻求与其它AOP实现机制的整合，目前已经实现了与AspectJ的整合，以利用AspectJ丰富的切入点语法，并利用AspectJ的方面实现。
Spring架构的远程服务
Spring架构提供对经典的J2EE架构的RMI方式的分布式远程方法调用的支持，同时也可以兼容EJB的分布式的解决方案session bean。
每个基于WSDL的Web Service 都是由一个服务构成，其中定义了一个或多个端口。每个端口对应服务器上的一个服务端点。同样Spring通过JAX－RPC提供的服务，实现基于J2EE的远程客户端的访问。
Spring还有另外的一种选择－使用轻量的级的远程方案：Hessionhe和Burlap。这两种协议都不是绑定在Java之上的，它们有自己的序列化语义，并且支持集合类型。他们最主要的目标还是提供Java应用之间的通信。并且也确实能够满足语义丰富的Java远程调用要求的最简单的通信协议。它们的配置比RMI简单，并且比基于WEB服务的SOAP协议简约的多。