http://tonylian.iteye.com/blog/680916
[转]用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",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 = "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")
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" />
- t;/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{
import javax.jws.WebService;
@WebService
public interface UserAccountService extends BaseService{
115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
