近六个月来，有关web services生命周期，安全，协作，事务方面的许多标准纷纷出现。jsr已经开始用一种标准的方式来定义web services的各个方面如何从j2ee应用服务器中得到支持。
　　
　　jsr 109专门讨论本地客户端如何访问web services，服务器生命周期和web services的部署。jsr 104,105和106联合在一起来描速web服务安全，包括信任服务的api，数字签名和加密。jsr 156 和157定义支持web services的事务和合作的基础，包括支持2pc (jta) 和商业事务。本文将介绍jsr 109 的内容并考察它对web services在j2ee环境中实现的影响。
　　
　　jsr 109: web'>http://jcp.org/en/jsr/detail?id=109">web services 在j2ee上的实现。当前规格说明书状态：版本0.3(正式发布版本 1.0) 15-april-2002
　　
　　jsr 109介绍
　　在过去的这些年里，j2ee成为提供web服务的主流标准。同时也出现了许多把应用端功能移植至web前端之后的标准, 其中web services是最新的。j2ee一开始使用的是servlets，jsp和无状态会话企业java
　　bean, 然后ejb规范发生了调整开始支持有状态的企业java bean, 在后来是实体bean, 最后开始支持基于消息的java bean。
　　
　　毫无疑问j2ee将会继续的发展和进步。jsr 109是最新的描述扩展j2ee的规格文档之一。jsr 109 定义了j2ee应用服务器应该如何以一种标准的方式提供对web services的部署，管理和访问的本地支持。 明确的说，jsr 109覆盖以下重要的领域：
　　
　　客户端的编程模式?d?dj2ee如何把web services作为传统的远程对象来访问服务器端的编程模式?d?d怎样用servlets和无状态会话ejb来实现web services并使web services具有和他们一样的生存周期web services部署和部署描述器?d?d如何在应用服务器上部署web services
　　
　　在这篇文章里，我们要考察jsr 109的许多领域来理解每个领域到底带来了什么样的好处。但是在读这篇文章的时候，你要记住规格说明文档是描述解决问题的结论。我们在研究一种技术的时候常常只是注意它能做什么而忘记它要解决的问题是什么。在我们读这篇规格说明文档的时候，我们要一直问自己“它究竟要解决什么问题？”　规格说明文档描述解决问题的结论，它描述的范围不应该宽于也不应该窄于问题的范围。
　　
　　首先，jsr 109 尝试定义一种实现web services的编程模式，在这种模式下无论web services是如何实现的，对调用端来说看起来都是一样的。因为web　services同时被其他很多的规范所控制和定义，jsr 109不可以要求web services在实现和部署范围以外有任何的改变。我们来简单的看看部署和部署模式。
　　
　　jsr 109 尝试定义一种模拟其它j2ee编程模式的客户端编程模式；熟悉“传统”远程方法调用的开发人员会很容易的理解jsr 109。所谓的“传统”，我们指jsr　109定义了一种和其他j2ee应用一致的客户端编程模式，使用jndi等方式来获取远程接口然后调用引用的对象。
　　
　　注意：一些支持web services的公司，比如说sun 和 bea，他们表示对jsr109持有保留意见。需要查看完全的描述，参考http://jcp.org/en/jsr/results?j=109&t=1&c=1">投票内容。
　　
　　客户端编程模型
　　jsr 109客户端编程模式的目的是清楚的定义java应用如何能够像访问ejb那样访问web service。这个问题只是许多复杂情形中的一种。其它的jsr定义和应用服务器不在一起的web　services的访问；然而，这种方式给客户端应用带来了一定的编程复杂度。在部署web service的应用服务器内部访问web service我们定义为直接访问。jsr
　　109的客户端编程模式定义了一种简单易懂的访问本地部署的web service的方式。
　　
　　三种模式
　　jsr 109定义了三种客户端编程模式?d?d用户管理端口访问模式，容器管理端口访问模式，动态端口访问模式。我们将侧重于用户管理访问模式，这种模式基于原来的wsdl为web　service定义了一个接口。使用用户管理访问模式的时候，应用系统需要为一个特定的接口提供一个端口。容器管理端口访问模式和用户自管理模式类似，但是容器直接管理对实例的调用，而用户只是申请一个普通的可以访问不同接口的端口。
　　
　　端口　在了解web service之前，我们必需先理解端口的概念。一个端口是web service的一个实例。一个客户应用访问web service必需通过服务接口访问服务，这时应用服务器可能启动一个已经存在的实例或者创建一个新实例来实现这个请求。熟悉ejb编程模式的读者会发现jsr　109的客户端编程模式非常熟悉。
　　
　　动态端口访问模式不需要事先了解wsdl的定义，调用会在端口不工作的时候发生。虽然明显看来动态端口访问模式更加强壮，但是在现实应用中动态端口访问模式并没有多大用处。在将来?d?d当动态编程变得更加普遍的时候?d?d这种方式也许会是非常有用的。本文的余下篇章中，我们将使用更加传统的容器管理端口访问模式，在这种模式里用户事先知道web　service接口的定义。我们待会再解析用户管理端口访问模式和容器管理端口访问模式。
　　
　　第一步：首先我们得到一个在任何jndi客户系统中都要用到的initialcontext。（对jndi的描速已经超出了本文的范围，有兴趣的读者可以直接访问jndi培训）当我们考察web　services部署的时候，我们将了解访问web service实际名称的细节；直到这个时候，我们才需要使用web services的名称。当然，应用服务器应当保证实际的web services已经被绑定到jndi树上了。
　　
　　例1.用户管理端口访问模式
　　
　　00 initialcontent ic = new initialcontext();
　　
　　01 somespecificserviceinterface srv = (somespecificserviceinterface)ic.lookup (java:comp/env/service/somespecificserviceinterface);
　　
　　02 serviceinstance si = (somespecificservice)srv.getserviceinstanceport();
　　
　　让我们来逐行研究这个程序片断，行00是传统的jndi查找。行01，我们得到接口serviceinterface的一个特定实例。所有的服务都需要实现services接口，这个接口定义了访问服务的一些公用方法，例如返回特定实例。如果你熟悉ejb规范，你将发现services接口和ejb本地接口有类似之处。行02，我们得到了定义了实际使用的方法的远程对象的一个实例。
　　
　　当web service的定义在开发的时候已经完全已知的情况下我们一般使用用户管理端口访问模式。如果因为某种原因应用服务器不能返回支持行01 cast操作的实例，异常将会被抛出。
　　
　　例2.容器管理端口访问模式
　　
　　00 initialcontent ic = new initialcontext();
　　
　　01 service srv = (service)ic.lookup
　　
　　(java:comp/env/service/somespecificserviceinterface);
　　
　　02 serviceinstance si = (somespecificservice)srv.getport();
　　
　　例2和例1仅有很小的差别。在01我们只需要对象的一个公用接口。没有指定返回的接口名称，所以容器可以自由的返回任意的匹配被请求的jndi名称的实例。行02也有一些差别：我们使用一个普通的getport()调用方法而不是像我们在例1中使用的那种特定名称的get　port>port调用方法。
　　
　　规格说明书中声明当用户仅仅访问对象的服务定义时可以使用容器管理端口访问。行02假定客户端知道服务可能不支持的一个特定接口。如果容器不知道所需求的cast操作，异常将被抛出。更可能的是，客户端在build的时候没有一个完全的wsdl定义，因此他们不能用the　getport()方法，但是他们会指定合适的实例类型?d?d这种方式看起来更可行。
　　
　　服务器编程模型
　　服务器编程模式可能是jsr109最重要的部分。理解web service在不同的生命周期的工作方式将帮助web service开发人员创建在不同条件下都可以按预定方式工作的web
　　service。ejb规格说明书定义了不同类型ejb的生命周期。jsr 109更进了一步，它扩展了ejb模式，定义了web services如何在web　services容器里工作。jsr 109 关于服务器编程的定义是一个解决行为一致性的尝试。
　　
　　快速背景贴士　web 应用和ejb 一般在“容器”内执行。容器提供ejb或者web 应用运行时需要需要的所有服务。事务，jndi,jdbc,所有类似的服务都由容可提供。一般来说，一个应用服务器里有两种容器?d?dweb 应用容器和ejb容器。它们都提供相似的服务，比如生命周期管理，但也会有微小的差异，这个要看提供的是何种服务。web应用容器知道如何加载servlets；ejb容器知道如何加载ejb。
　　
　　在我们了解jsr 109规范内容之前，让我们先了解我们需要什么来支持web services顺应j2ee的工作方式。首先，web service的实现应该对客户透明。web　service在应用服务器内实现这个事实不应该改变客户端对服务行为的认识。况且我们需要在很多的应用服务器里使用web service。因此，编程模式应该是轻便强壮的，不仅支持现在的实现也要支持将来的实现。
　　
　　另一点比较重要的是和现存j2ee服务的无缝整合，例如 jdbc。我们希望我们的web services能够方便的利用j2ee现存的优势而不危及到服务自身的完整性。
　　
　　有了这些目标，jsr 109定义了对web services两个领域的支持：无状态会话bean和servlets。jsr 109一个让人失望的地方是它在没有解释的情况下忽略了消息驱动bean的定义。消息bean支持可扩展的同步消息，这是web　services的一个重要部分。由于消息bean的行为可以被无状态bean和servlets所模拟，所以我们需要编写额外的代码。
　　
　　在web services里端口的定义十分重要，jsr 109 定义了在j2ee应用服务器里如何将端口和服务进行映射。web service的端口在概念上类似于jvm里的实例。
　　
　　wsdl: web service的接口定义，wsdl并不是web service的一部分，