对于企业级JavaBeans形成的商务层构件，也就是我们所熟知的Java 2 Enterprise Edition平台，相对于软件的进化为服务，在结构方面并没有停滞不前，在EJBs3.0版本同早期的版本比较中，我们已经可以看到一个具有了完全不同的开发模型，这就使得在使用Web services的过程更加简单。
如果你是EJB的早期采用者，那么你对这个技术自从最初以来的复杂性应该比较了解。复杂性让很多人已开始就放弃了使用EJB的想法，更不要说根据这个Java规范来实现Web services的可能性了。就这样，很多项目都使用了单独的API，如JAX-RPC或者类似Apache Axis的框架来在Java环境中部署Web services。尽管这种方式提供了一种新对较低的入口门槛，但是它缺少内在的中间件服务——例如事务处理和安全服务——很多的都是使用EJB架构的主要原因，使得开发者不得不去在一个不是最好的情况下来处理Java Web services，以使得能够以高级的中间件性能来运作或者带来一个十分复杂的开发生命周期。
最先的，应该指出的是EJB不是一个本质上的EJB，而是为大家更为广泛的指导的Session EJB的扩展。那也就是说，一个Web services使能的EJB开始是以一个改进过的会话EJB运行的。在EJB版本2.1中，规范设计者看到了需要提供一个通过SOAP消息访问机制，但是在哪个时候不是构建一个现有EJB的分支的实现——会话，实体和消息——这个决定是使用扩展了的会话bean来适应Web services。
前面所说到的在EJB2.1种的问题是以一个传统的接口方式来解决的——是以一种Web 服务终端的形式来服务的——和一个额外的部署描述符来定义具体的服务行为。尽管如此，在这个过程中的大部分的苦差事并不是仅仅由于底层EJB的会话bean的实际上的创建，而也同你想把它转变成一个Web services EJB的念头有关。
简短的来说，我们只是列举在一些特别的过程中的缺点，后面我们会转移到一段实际的EJB3.0代码来看看是如何改变的。在EJB2.1中部署一个Web service最为显著的问题如下：
Web service需要从一个会话EJB采用它的行为，而这个会话EJB本身是和一个遗产层次——例如在EJB3.0之前的版本——是紧密联系在一起的，同时也具有一系列的为EJB环境所需要的伴随接口。
你需要定义一个传统的Java接口，这个传统接口将会用于提供服务端点，服务端点就是类似于在一个会话EJB中已经包含的远程接口。
还需要另外一个配置文件——部署描述符——进一步的来指明EJB的服务行为。
对这些Web services EJB的问题的减轻分为两种主要的形式：注释和简单的旧Java对象(POJO's)。注释是可以被放置在Java源代码文件中的元数据，为的是能够提供进一步的配置属性或者处理指令来执行Java环境。在另外一个方面，POJO's被拆分成java类，这些java类没有遗传依赖关系。
通过注释，所有在部署描述符中已经定义了的数据可以被替代的放置在一个当读的文件当中，也就是那个包含了商务逻辑的源文件。这不是说外在的部署描述符在Web services EJB 3.0中废除了。相反的，他们仍然是非常有效的，尽管他们现在将会提供一种后退机制，来形成一种更加自然并且简单的过程，以配置商务逻辑的内嵌信息。
另一方面，商务逻辑的设计和编码阶段是可以达到的，正如Web services可以通过使用POJO's来获得极大的简化。在EJB2.1种，创建一个能提供Web services的EJB的过程强迫你去处理会话EJB强加的遗传条件。因此对于这些情况，如果你以一个简单和容易理解的Web service操作集合开始，创建一个简单的Java对象只是EJB的过程中的开始，因为你需要作许多其他的工作来达到Web services设计的EJB的最后。
