企业级JavaBeans形成的商务层构件，也就是我们所熟知的Java 2 Enterprise Edition平台，相对于软件的进化为服务，尽管他们的结构没有停滞不前，在最新发布的EJBs3.0版本同早期的版本相比已经具有了一个完全不同的开发模型，这就使得在使用Web services的过程中更加简单。在接下来的段落里面，我们将会介绍在EJB3.0里面Web service的创建是怎么改变的。

　　如果你是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的最后。

　　把POJO's作为EJB来处理的能力实际上是前面所提到的注释的概念的结果，同时也是已经在核心Java5 平台和Java 5 Enterprise Edition中都进行了约束的范式转移。但是现在，让我们看看我们手边的工作，列表1.1展示的是在EJB3.0 中，一个Web servicec看起来是怎么样的。

　　列表 1.1 Web Service EJB 3.0

　 import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;

@Stateless
@WebService(serviceName="Weather", portName="WeatherPort")
public class WeatherBean  {

    @WebMethod
    public double hiTemp(String city) {
        // Perform lookup to DB or some other data source
        return temp;
    }
    @WebMethod
    public double lowTemp(String city) {
        // Perform lookup to DB or some other data source
        return temp;
    }
    @WebMethod
    public double avgTemp(String city) {
        // Perform lookup to DB or some other data source
        return temp;
    }

    // This method will not be exposed through the web service
    public double fahrenheitToCelsius(double fahrenheit) {
        // Perform conversion
        return celsius;
    }

    // This method will not be exposed through the web service
    public double celsiusToFahrenheit(double celsius) {
        // Perform conversion
        return fahrenheit;
    }

}
 
　　以前的Web service EJB最令人惊叹的地方应该就是它的简洁，但是不要让它的简短愚弄了你。在EJB2.1中所提供的相同的功能也在这个单独的文件的各个部分出现了。 你会注意到这个源文件中的很多地方都用到的@符号。这些标记表示的是Java注释，这些java注释在后来将会被底层的EJB应用服务器用来产生预定的结果。请注意到，没有这些注释，我们的这个类只是一个POJO，因为它没有利用任何特定的API或者构造。 它只是平淡而简单的商务逻辑。

　　最顶端的注释——@Stateless 和 @WebService——表示的是这个类将会被用作揖个具有Web services功能的会话bean，而在@WebService旁边的属性，表示的是特定的Web services数据，这些数据在EJB2.1中是被放置在一个部署描述符中的。剩下的@WebMethod注释是用来指定哪些方法将会作为Web service接口被提供出来，换句话说，Web service接口就是那些使用一个用来描述EJB Web service的 WSDL契约的操作。

　　这个例子解释了在EJB3.0中最基本的前提。其他的可供选择的方法可以包括同在EJB2.1中相同的方式来使用一个分隔端点接口，但是通过注释来链接它，并且，当然的，通过注释指定它的高级中间件属性——例如事务处理和安全证书——这些可能是你选择使用EJB Web services的最主要的原因。

　　通过这个，我们可以总结一下我们对在为生产Web services的EJB模型里面发生的一些改变的看法，对于那些使用需要添加EJB提供的能力的Web serivcies ，这是必将带来受到欢迎的转移的过程，并且其他的一些选择的可能仍然在试图获取最简单的可能的机制来集成Web serivces到他们的Java项目中去。