Java Web Service 框架/库,哪个更好,为什么?
目前我正在评估 Java 中的 Web 服务框架的数量.我需要 Web 服务框架来帮助我公开在 JBoss 上运行的现有应用程序的一些功能,该应用程序主要使用 Spring 和 POJO(无 EJB)开发.
Currently I am evaluating number of web service frameworks in Java. I need web service framework that will help me to expose some functionality of existent application running on JBoss, The application is mostly developed using Spring and POJOs (no EJBs).
我需要的是一个具有以下属性的框架:
What I need is a framework having following properties:
- 它应该提供自动生成样板代码的工具,并通过消除重复性任务来节省时间,例如从 Java (java2wsdl) 生成 WSDL 的工具、生成端点的工具等.
- 应用程序应该很容易部署在现有的J2EE平台(JBoss)上,这意味着它应该包含尽可能少的配置文件(如axis2框架中的axis2.xml).
- 此外,最好能够在现有应用程序的 .war 存档中部署 Web 服务.(似乎 Axis2 需要一个单独的 Web 服务应用存档.)
- 结合使用 POJO 和 Spring 会很酷.
- 一般来说,框架应该具有简洁的结构和设计(例如 Spring-WS 缺少它)、良好的文档以及任何其他可以作为一款优秀软件的特征.
- 框架最好包含一些标准功能,如 JAX-WS 等,而不是供应商特定的方法.
- It should provide tools for automatic generation of boilerplate code and save time by eliminating repetitive tasks, for example tools generating WSDL from Java (java2wsdl), tools generating endpoints etc.
- Applications should be easily deployed on existent J2EE platform (JBoss), this means that it should contain as less as possible configuration files (like axis2.xml in axis2 framework).
- Also it is preferred to be able to deploy web service within .war archive of existent application. (it seems that Axis2 need a separate archive for web service app.)
- It will be very cool to use a combination of POJOs and Spring.
- Generally, the framework should have clean structure and design (for example Spring-WS lacks it), good documentation and whatever else characterizes a good piece of software.
- It is preferred that framework incorporates some standard features like JAX-WS etc. instead of vendor specific methods.
我已经简单检查了
- 轴 2
- Apache CXF
- 和 Sun 的地铁
- 春季 WS
但仍然很难决定在我的情况下使用什么:
But still it is difficult to decide what to use in my case:
- Axis2 似乎太低级了,它需要单独的应用程序存档和大量配置
- Spring WS 似乎太不透明,而且对于印象目的来说太复杂了 (?)"
- Apache CXF 和 Metro 可能是我更喜欢选择的两个框架,但仍然是
我需要您对其中一些在实际应用程序中的使用提出意见和经验.
I need your opinion and experience about usage of some of them in a real-world applications.
推荐答案
我已经使用 CXF 的前身 XFire 有一段时间了,感觉还不错.当时,我们从 Axis 迁移的主要原因有两个:性能和易于开发.在当时(不知道现在是不是这样),XFire 的性能比市面上的任何东西都要好得多,并且通过注释驱动的开发,不必运行存根生成,添加新的真的很容易网络服务.
I've used CXF's forerunner, XFire, for a while now and it's not been too bad. At the time, we migrated from Axis for two major reasons: performance and ease of development. At the time (don't know if this is true now), the performance of XFire was much better than anything out there, and with annotation-driven development, instead of having to run stub generation, it was really really easy to add new web services.
CXF 似乎更加相同但更好 - 由于开发时间的限制以及没有迫切的理由这样做(加上 6-12 个月前相对缺乏文档是不太令人鼓舞).此外,我最近还没有真正评估过市场,所以我无法告诉你 CXF 如何与当代竞争对手抗衡.
CXF seems to be more of the same but better - we haven't migrated yet due to constraints on development time as well as not having a pressing reason to do so (plus the relative lack of documentation 6-12 months ago wasn't too encouraging). Additionally I haven't really evaluated the market of late, so I can't tell you how CXF stands up to its contemporary competitors.
关于你的观点:
- 无需生成样板代码,WSDL 由服务类的注释自动创建并由服务器发布.
- 在 Tomcat 中的部署相对简单.只需在 web.xml 中定义另一个 servlet 并将 URL 模式映射到该 servlet.
- 我们的 Web 服务部署在 WAR 文件中,我不确定实际上有哪些替代方案,但这似乎是默认且显而易见的方式.
- POJO 最初运行良好;我们现在已经将大部分 Web 服务对象的创建移到 Spring 中,以便在其中连接更复杂的条件依赖项,并且没有遇到任何问题.
- 文档最初是 CXF 的一个弱点,尽管刚刚看过它现在似乎更好.总体设计和架构似乎相对健全.插入自己的过滤器来修改传输细节并不是很痛苦,并且通常考虑扩展现有类(例如,明智的方法被标记为受保护而不是私有).
- CXF 完全支持 JAX-WS.
所以我可能有点不偏不倚,因为我没有尝试过其他的,但我会竖起大拇指看看 CXF.如果您需要调整它,它非常快、相对简单并且相当强大.
So I'm probably a little impartial as I haven't tried the other ones, but I'll give a thumbs up to having a look at CXF. It's pretty fast, relatively simple to get going with and fairly powerful if you need to tweak it.
相关文章