用Sping发布WebService

【原创】用Sping发布WebService


    我的需求是这样的：系统已经成型，仅仅通过基础架构的很小变化，达到将服务开放为WebService的目的。

1、不用或几乎不用修改已有代码

2、简单的xml配置

3、通用性强，各种开发环境皆可访问

4、参数与返回型都要支持DTO（POJO）


    以上四点需求，看起来很简单，可想而知各种Java的WebService方案应该都能够满足。但是，在实际借助网络搜索答案的时候却发现，能搜到的帖子，基本都是相互转帖的，所有的例子几乎一样，就那么2、3篇。


    虽然看了几种实现Webservice方法的比较的帖子，笔者认为与Spring整合的话，CXF比较好，而且似乎有后来居上，掀翻Axis/Axis2的趋势。但我还是分别实践了一下Axis/Axis2/CXF（[size=x-small;]Celtix、XFire只看了看帖子，既然已经合并为CXF了，就没有再去实践[/size]），也亲身体验了一把。最终还是初步选定了CXF，下面谈一点体会：


1、其实Axis和Axis2都是可以与Spring很简单的整合的，网上的帖子说不能，这一点我有些质疑。

2、速度我没有比较，网上说CXF比Axis1快4-5倍

3、既然有了Axis2，而且是重新设计的，完全替代Axis，所以Axis就没有仔细琢磨，仅仅调通了一次，就不多说了

4、Axis2的略势（仅仅从开发方便性来说，性能、通用性等尚未关注）是：

4.1、配置文件方式复杂，要求在WEB-INF下建立servers目录，里面是每个WebService各一个目录，各WebService的目录里再有META-INF目录，最后在里面放services.xml。一个WebService就要一个xml配置文件不说，还要复杂的目录结构

4.2、jar包超多。Axis1都打到一个jar包里了，足足15M，Axis2为了让jar包变小，分工明晰，分解了jar包，但是也太多了，足足62个，这还不算axiom的。为他瘦身就要花一番功夫（我不喜欢把所有的jar都一股脑的扔到lib里，能少一个就少一个）

4.3、用.Net做Client访问返回的DTO中的DTO类型出现错误。比如，返回一个department（部门），此对象除id、name等String型属性外，还有List employees属性。我的服务返回的department.employees明明只有一个对象，而Client端得到的却显示List有3个内容，因为Employee有3个属性（id、name、age），分别为string、string、int


5、CXF的略势（仅仅是我认为的）：

5.1、CXF要求注释语法，而修改现有代码是我不愿意看到的

5.2、作为妥协，仅仅在接口中使用最简单的注释@WebService，其他非必须的地方都不写注释。导致生成的WebService的名称、命名空间、DTO的类型都由CXF自行命名，尤其是DTO的类名，都是小写开头的，非常别扭。

5.3、从暴露出来的wsdl看，只有SOAP1.1协议，而Axis2还有SOAP1.2和普通Http


以上就是我初步实践的比较结论，综合看，CXF还是有优势的。尤其是Axis2的4.2是个致命问题，不知道是不是我没有调试好，但似乎也看到一篇帖子说Axis2在DTO（自定义类型）的传递上不如CXF。

5.1、5.2问题习惯就好了，5.3也不是大问题，用1.1反而是稳妥的，兼容性更好的。


以下就详细分析一下CXF，例子代码我就尽量不大段的贴了，搜索一下有的是。


接口定义：

@WebService(name = "UserService",targetNamespace = Constants.WS_NAMESPACE) 
public interface UserWebService { 
    @WebResult(name = "user") 
    public UserDTO getUser(@WebParam(name = "userId") Integer userId) throws FaultException; 
} 

 

• @WebService 必须，(name="UserService")可选，配置Service的名称，默认为类名。targetNamespace可选，默认为http:// package的倒序，可在一个自己的Constants里定义统一的namespace.
• 默认接口的所有方法均输出为WebService。
• @WebResult 可选，配置方法的返回值在WSDL的名称,CXF默认为result。
• @WebParam 可选，配置参数在WSDL的名称，CX比较笨，不会反射，默认为arg0,arg1....
• @WebMethod 可选，有一个方法有此注释，则其他无注释的方法非WebService。

接口实现：

@WebService(endpointInterface = "xxx.xxx.service.UserWebService",targetNamespace = Constants.WS_NAMESPACE) 
public class UserWebServiceImpl {
    //...
}

 

@WebService(endpointInterface="")  可选，指定实现的接口。接口是对外的，必须通过注释来声明，而Impl是内部的，声明是可选的。


DTO：

@XmlType(name = "User") 
public class UserDTO { 
    //属性及setter/getter方法... 
} 

• @XmlType(name = "User")  可选的 
• JAXB的智能化较高，基本上不需要手工映射。 
• 默认的@XmlAccessorType(XmlAccessType.PUBLIC_MEMBER )根据公共getter/setter与公共属性反射(XmlAccessType.PROPERTY根据getter/setter反射，XmlAccessType.FIELD 根据成员变量反射)
• 如果有需要注释@XMLElement，@XMLAttribute，需配合XmlAccessorType定义，默认的PUBLIC_MEMBER，需要在getter/setter上定义，如果要写在成员变量上定义，则XmlAccessType改为FIELD。
• @XmlType(name = "User") 指定WSDL上的类型名称，否则CXF奇怪，DTO的类名是小写开头的。
• @XmlTransient 可以注释某个字段，取消该字段的反射。

 

总结一下：

    1.统一：每一个接口函数，每一个DTO类都需要定义NameSpace，否则CXF会以类的pacage名倒序作为namespace，大幅提高引发命名空间的复杂度。最好在Constants类里统一定义。

    2.接口： CXF比较笨，所以还需要注释每个方法的参数名。否则会以arg0,arg1命名，用SoapUI 等工具看SOAP包时比较痛苦。（Axis2也是arg0,arg1）
        在ServiceImpl中，最好命名serviceName，否则默认会议类名+Service来命名，如UserManagerServiceImplService，比较难看
    3.DTO：用@XmlType定义 DTO名，否则名称默认小写，在.Net下生成的代码，类名都是小写的，超奇怪。



最后要着重指出一点，在网上能搜索到的N多帖子都是如出一辙，但是估计第一个人犯了错误，而后来者都是不负责任的粘贴！！估计他们都是没有经过自己测试的！太误人子弟了！！


这就是 Server端 作为Spring和CXF桥梁的那个xml配置文件中的写法，引用一段网上的帖子：

在spring-cxf.xml配置发布的web service

<!-- 上半段省略 -->
    <bean id="hello" class="test.HelloWorldImpl" />  
    <jaxws:endpoint id="helloWorld" implementor="#hello"  
        address="/HelloWorld" />  
</beans>
注意： id：指在spring配置的bean的ID.

Implementor:指明具体的实现类.

Address:指明这个web service的相对地址

 
 

请注意这里一共犯了两个错误：

1、id，作为标签的id，它当然是这个endpoint的id，不可能是“指在spring配置的bean的ID”

2、implementor用#引用了上面声明的一个bean，其实implementor=的引用才应该指向在spring配置的bean的ID，spring-cxf.xml中不用也不该再定义一个bean了


正确的写法是：

假设Spring的配置文件applicationContext.xml中定义了一个bean

<bean id="helloWorld" class="test.HelloWorldImpl">
        <property name="userDao">
            <ref bean="userDao" />  <!-- 这里注入一个DAO -->
        </property>
</bean>

 

spring-cxf.xml应该这样写：

    <jaxws:endpoint id="helloWorldEndpoint"
    	implementor="#helloWorld"  <!-- 这里是与spring定义的bean呼应的 -->
        address="/HelloWorldService" />    
  </beans> 

 
试想，如果在implementor参数里指定具体实现类，那spring注入时的“接口指向用具体实现类”还有什么意义呢？
最初的作者仅仅调试了一个HelloWorld就草草落笔，他们并没有仔细观察，当客户端来访时，服务器是新实例化了一个服务呢？还是从spring已经注入好的bean中get一个呢？
显然我们要的是后者的效果，而错误的写法确实前者的效果，虽然HelloWorld能通，但是稍复杂一点，比如sping的bean中又注入了其他bean，那么一下就能发现错误了，因为错误的写法是另外实例化了一个bean，由于他是在错误的spring-cxf.xml中定义的，自然没有写property。


所以写博客、发帖子，都应该本着负责和科学的态度，不能人云亦云，尤其是技术贴，自己没有验证的，请不要Ctrl-C / Ctrl-V ！

 

 

 

----------------------一条4年半后的分割线-----------------------------------------------------------------------------

 

今天，大约此贴发帖后4年半的一天，看到一位网友的回复，我又看了一遍这篇文章。

于是想补充一点，后来经过进一步实践，我早已达到了帖子首部提出的4点要求，尤其是第一点，

已经可以做到丝毫不修改原有代码既可以发布WebService。

就是说不需要使用注释的方式了修改代码了。

 

只需要在配置文件中加入

<?xml version="1.0" encoding="UTF-8"?>   
<beans xmlns="http://www.springframework.org/schema/beans"  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
    xmlns:simple="http://cxf.apache.org/simple"
    xmlns:soap="http://cxf.apache.org/bindings/soap"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
    	http://www.springframework.org/schema/beans/spring-beans.xsd
    	http://cxf.apache.org/core
		http://cxf.apache.org/schemas/core.xsd  
		http://cxf.apache.org/simple    
		http://cxf.apache.org/schemas/simple.xsd">  
    <import resource="classpath:META-INF/cxf/cxf.xml" />    
    <import resource="classpath:META-INF/cxf/cxf-extension-soap.xml" />    
    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />  

    <bean id="aegisBean" class="org.apache.cxf.aegis.databinding.AegisDatabinding" />  
  
    <simple:server id="webServiceUserAccountService" serviceClass="com.xxxx.service.UserAccountService"  
        address="/UserAccountService">  
        <simple:serviceBean>  
            <ref bean="userAccountService" />  
        </simple:serviceBean>  
        <simple:dataBinding>  
            <ref bean="aegisBean" />  
        </simple:dataBinding>  
    </simple:server>  

</beans> 

 这样就把原来一个普通的【userAccountService】开放为WebService了。

每增加一个WebService，在这个配置文件里增加一段<simple></simple>就可以了。

记着在applicationContext.xml中引用这个xml哦。

 

最后别忘了在web.xml中加上CXF的监听

    <servlet>  
        <servlet-name>CXFServlet</servlet-name>  
        <servlet-class>  
            org.apache.cxf.transport.servlet.CXFServlet  
        </servlet-class>  
    </servlet>  
    <servlet-mapping>  
        <servlet-name>CXFServlet</servlet-name>  
        <url-pattern>/webservice/*</url-pattern>  
    </servlet-mapping>

 

 ----------------------一条又过了半年多的分割线-----------------------------------------------------------------------------

 

今天又看到了这个帖子，这半年间，我又优化了一下，这个WebService的发布方法。

 

两条分割线之间的方法其实已经很好了，最大的优点就是配置简单，且对代码零污染。

 

但是，我也发现它的一点问题，就是被开放为WebService的原Service的所有方法都会被开放出来。

那位说了，不就是为了都开放出来吗？不想开放的方法改到另外一个服务中不就行了。

其实，问题可能不出在业务方法上，而是我们的Service的父类中的一些系统级方法，

比如 commit, rollback 之类的。

这些方法开放出去，显得那么不让人放心。

 

那么我们就需要改一下配置文件，把<simple:Server>标签改为<jaxws:endpoint>标签。

这样做后，需要一点点的对代码的污染，就是在想要开放为WebService的Service的接口中，

（主意只是接口中，实现类不需要）

给接口定义加一个 @WebService 的注解

（如果业务方法也有一些想开放的，一些不想开放的，又不愿意应为开不开放而破坏原有的

逻辑把这些方法重新分到不同的Service中，那么还可以使用方法级的注解）

 

这样，因为父类中定义的方法（commit, rollback等）没有注解，就不会开放到WebService中了。

 

 

	<jaxws:endpoint id="webUserAccountService" implementorClass="cn.xxxxx.service.UserAccountMasterDataService"  
        address="/UserAccountService">  
		<jaxws:implementor>  
			<ref bean="userAccountService" />  
		</jaxws:implementor>  
		<jaxws:dataBinding>  
			<ref bean="aegisBean" />  
		</jaxws:dataBinding>  
	</jaxws:endpoint>

 

 

import javax.jws.WebService;
@WebService
public interface UserAccountService extends BaseService{

 

这样，我们就保护了BaseService中声明的方法不被一同开放为WebService了。

 

评论

2 楼 LoveStart 2014-10-17  

写博客、发帖子，都应该本着负责和科学的态度，不能人云亦云，尤其是技术贴，自己没有验证的，请不要Ctrl-C / Ctrl-V ！

1 楼 LoveStart 2014-10-17  

强烈支持最后一句话，技术贴 烂拷贝 烂粘贴 真是害了不好人的时间啊。