Jetty vs CXF / Which one to choose? - java

I am fairly new to the Java world and pretty overwhelmed by the beauty of choice between dozens of libraries doing more or less the same thing, or not.
So with Jetty and CXF. I am looking for a web services stack that has built-in support for a wide range of transports and protocols.
I was under the impression that CXF is the more recent project and would be the preferred choice for new software projects. Especially when it comes to applications that have to talk a variety of different protocols and standards like WS-*.
Can you give your opinion on how those frameworks differ from each other?
Which one has broader support for different protocols and standards?
Which one would you prefer regarding its design e.g. how well they hide transport, authentication, authorization, serialization aspects from application logic?
Any kind of answer very welcome!
Cheers,
Alex

Jetty is a web server and servlet container. CXF is a library for web services. If you want to serve out content like is done with a web server, choose Jetty. If you need to connect to or provide web services, choose CXF. I'm not sure there's any blurred area between the two.

There is a misunderstanding here, Jetty and CXF are like apples and oranges, it doesn't make sense to compare them. One is a light servlet engine, the other one is a web services stack.
If you're looking for a web services stack (which is my understanding), consider JAX-WS RI or CXF if you are looking for a JAX-WS compliant stack (both support contract-first or java-first), or SpringWS ("only" contract-first), or maybe Axis2 (I don't like it personally it because of its development and deployment model and its performances).
If you don't need fancy WS-* stuff, I'd suggest to use JAX-WS RI which is included in Java 6 and is compliant with the WS-I Basic Profile 1.1 (so it covers a decent bunch of WS-* standards). If you need more advanced things (like WS-SecureConversation, WS-SecurityPolicy, WS-ReliableMessaging, WS-Trust, WS-AtomicTransactions/Coordination, WS-MetadataExchange, SOAP over TCP which are provided by WSIT/Tango), consider using Metro (Metro = JAX-WS RI + WSIT/Tango).
(EDIT: Answering a comment from the OP about WS-SecureConversation support.
Actually, I think that the stack that supports the most WS-* standards is Metro. You might want to check Apache Axis2, CXF and Sun JAX-WS RI in comparison for more details. But, it is very unlikely that you'll need all of them and things might have slightly changed since the article has been published. So CXF might indeed be an alternative. For example, regarding WS-SecureConversation, CXF does support it too according to its documentation but only with "wsdl-first" projects. Without more details about what you're going to do, it's hard to give you a more accurate answer about which one is the best for you.)

Jetty is a server(a servlet container), so is Tomcat and few others. Jetty is decent, Tomcat has been around for a while and has more documentation and tutorials.
CXF looks like an interesting choice. I've only use directly implementations and CXF was fairly new, I think it's the continuation of XFire project.
CXF looks like a wise choice. When in doubt, I would say go with standards and frameworks built upon them. I would say go through the documentation and for complicated matters, you might want to subscribe to some mailing lists.

Related

What approach for java web service to use?

I'm developing a web application with multiple frameworks (spring, hibernate, spring-security, ZK for GUI), and using Tomcat as app server. I must say I have absolutely no experience with java web services technologies. Thing is, I will almost certainly have to expose number of services for some external applications in the near future, and I was wondering what would be the way to go (considering the frameworks I'm using)...
I saw and read various tutorials and some questions (link) regarding Axis, Axis2, JAX-WS... Thing that confuses me a little bit is that I don't know what is the common practice (if any) to integrate services within existing web application (mainly in the terms of project organization). As I see it now, these services that I need to implement will rely partially on the existing source code, so I don't know whether I should use completely separate project, or I can put it inside my existing web app folder (which I tried with Axis2, but don't know if it's a good practice).
Thanks.
How to organize the projects?
In general I agree with #ericacm, but there is one thing you should keep in mind... You said you're going to develop a number of services in the near future. You may come to a point at which you want to host the services on a separate server, e.g. for performance, availability or maintainability reasons. This may influence your decision of separating the projects. Furthermore, separation "enforces" loose coupling, but therefore introduces other challenges like session sharing across multiple WARs. It's a case-by-case decision.
If I were in your situation I'd first ask myself whether the service(s) logically belongs to the web application or not.
Implementation
When in comes to WS-* implementations you have to make 2 decisions:
Decide for an API to use; today, I can't see any reason for not going with JAX-WS together with JAXB as API, they work well and they are standardized.
Decide for a Framework; I've experience using Axis2 as well as METRO (keep in mind that JSE 1.6+ provides basic JAX-WS support). Both work well. It's fairly easy to change the frameworks if you use the JAX-WS APIs.
I have good experience with Spring-WS 2+ and manual Castor mapping . Is is easy but powerful combination.
Spring-ws 2:
provides contract-first development (specially good for the web app with number of services).
provides WS annotation
supports XML mapping (Castor, JaxB, etc)
Castor:
mapping based on xml configuration
allows map multiple messages (requests/responses) to one java object (based on xml configuration)
If you are using some Java EE 6 server, consider also JAXB for manual mapping:
mapping based on annotation
should be faster than Castor
allows map multiple messages (requests/response) to one java object (when you use java inheritance)
You can go ahead and put them into the same project. Each web service will be an additional interface and implementation class along with some configuration.
Since you are using Spring CXF is a good choice as a for JAX-WS as it integrates well with Spring. See this page as a starter.
Spring-WS is complex framework for simple web services. If you want to understand web services completely and to know the nuts and bolts of web services, learn Spring-WS. It is extremely flexible and provides lot of options.
Else, if you want simpler alternative use JAX-WS. Spring supports JAX-WS annotations. Refer to the section 17.5.7. Exporting web services using the JAX-WS RI's Spring support.
http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html
Is it possible to create WS Server and WS Client manually (without generators) by JAX-WS? Specially if you are developing a big application you want to re-use objects but generators are generating a lot of classes that can be in 99% the same (for example if your app is WS Client and you have to connect to badly designed external WS Server). Is there some tutorial how co create ws manually?
There is a lot of reasons why I don't like generators and completely agree with http://ogrigas.eu/spring/2010/04/spring-ws-and-jaxb-without-a-code-generator

Exposing Spring services as SOAP webservice

I have a quite extensive Spring 3.0 service architecture (the typical architecture; a bunch of model objects and a bunch of services that do stuff with these objects). I would like expose some of these services as SOAP web services.
We have developed SOAP web services before, but these have always been relatively simple and dedicated, and we have always used Axis 2. I found Axis 2 a bit heavy on the dependency and implementation side, and I'm a bit worried that this will bloat my current project something awful.
I have looked around and apparently using Apache CXF this would seem quite easy. So I'm looking for some advice on this. Does anyone have any practical experience with this? Pros and cons?
We are using spring with CXF for soap services and it goes very smooth. Following the CXF tutorial makes it straightforward to use by simply using the jaxws xml namespace.
I haven't really tested any other webservice frameworks - always been going with CXF and am quite happy with that.
If you're using Netbeans (even if not, it's still useful I'd say), check out this tutorial: http://sites.google.com/site/apachecxfnetbeans/loanproc
Just skip the first few paragraphs (Database integration, testing etc. etc. .. all of which you should already have knowledge about).
The CXF integration in Netbeans is useful for writing fast clients using the built-in netbeans functionalities.
cheers

How to get started with java web-services?

I am intermediate in java now I am planning to move to java web-services...
How can i get started with web-services?
What are the prerequisites?
Thanks...
To get started with web services in Java, I would recommend to use the Java API for XML Web Services A.K.A. JAX-WS. The reference implementation of this API (JAX-WS RI) is included in Java 6 (since Java 6 update 4) so you don't have anything to install if you are using Java 6u4+. Like the other APIs of Java EE, JAX-WS uses annotations to simplify the development and deployment of web service clients and endpoints. This API supports both Java-first and contract-first approaches (the former begin debatable but, well, this is the easiest way to get started).
You'll find many good tutorials on the NetBeans website, see Getting Started with JAX-WS Web Services or Developing JAX-WS Web Service Clients for example. When it comes to web services, I must say that NetBeans has actually far more better support than Eclipse and would be my recommend IDE. I do not want to go to much into the details (because things will become confusing) so I'd just recommend to use GlassFish for the deployment of your JAX-WS web services, it has everything required included 1.
But please, forget Axis 2 and its horrible deployment model (to be honest, I don't understand why people keep mentioning Axis 2, maybe only because it has been promoted by IBM with its Eclipse support).
You'll find plenty of other resources on Glen Mazza's Weblog, for example the "famous" DoubleIt tutorial.
If you want to go further, have a loot at this great online Web Services Course from JavaPassion (great resources, as always).
1 If really you want to know, the web services stack in GlassFish is called Metro. Metro includes JAX-WS RI (the reference implementation of JAX-WS) and WSIT (that provides an implementation of others WS-* standards for Secure, Reliable, Transactional and Interoperable Web services). Another implementation of JAX-WS is Apache CXF. You may find all these terms in the literature. For now, I'd stick with JAX-WS RI with GlassFish as container and NetBeans as IDE.
This is a must if you plan to provide (SOAP based) webservices or want to get a feeling on how to consume services: soapUI
And I am quite happy with eclipse's web tools platform when it comes to designing xml schemas and wsdl files.
One of the most common java libraries is apache axis2. Pretty sure, they have a lot of documentation and tutorials on their pages.
Just start with apache tomcat and run a web-application in it with a small servlet or JSP, and then once you master a bit how to create web applications for tomcat, go and check axis2, this is a web application that gets installed in tomcat, then you will be able to run your own web services in axis2.
If you one something more advanced you could go and check EJB3 and create a stateless session bean that will work as a web service... but this is more advanced and is much more difficult to set up an EJB3 project, I advise starting with tomcat/axis2.
good luck.

Making a Service Layer call from Presentation layer

I have to choose a technology to connect my Application/Presentation Layer (Java Based) with the Service Layer (Java Based). Basically looking up appropriate Spring Service from the Business Delegate Object.
There are so many options out there that it is confusing me. Here are the options I've narrowed down to but not sure..
Spring RMI
Apache Camel
Apache ServiceMix (ESB)
Iona FUSE (ESB)
Here is what I want to know
If you have worked on (or evaluated) any of these, which choice do You think is more appropriate? (and it wouldn't hurt to tell me why :)
Are there other technologies that I should be looking at as well?
As of now I do not see Application and Service layer being distributed but I do not want to rule out this possibility in future. Is this a good idea to design to provide this flexibility?
Any help would be useful. Thanks!
Spring Remoting would seem like the simplest approach. It also would leave you open to more complex approaches in the future if that is the direction you want to take.
From the limited view of your requirements, I would stick with a simple solution with a lower learning curve, and leave the ESB till you determine you actually need it.
The KISS principle is a wonderful thing.
It mostly boils down to do you want to use Spring Remoting (which Spring RMI and Apache Camel are implementations of) - or do you want to use JAX-WS for web services (which CXF or Metro implement). i.e. do you want automatic remoting for your POJOs - or do you want WS with WSDL contracts and so forth.
Once you've decided on the remoting technology; your next decision is do you want to bundle it inside your application as a library (e.g. Spring RMI or Camel) - or do you want to deploy it in an ESB container like ServiceMix to be able to hot-redeploy modules and so forth.
If the latter is your choice then use Apache ServiceMix - or use the FUSE ESB if you want a commercial distribution with more documentation, frequent releases, commercial support and so forth.
Here you can find a simple solution to integrate Metro and Camel together: http://www.everit.biz/web/guest/everit-blog/-/blogs/calling-a-camel-route-from-web-service-using-metro-and-tomcat?_33_redirect=/web/guest/everit-blog

Spring-ws or Axis2 or Something else for "Contract-First" approach to WS

Everyone's saying "Contract-First" approach to design WS is more inclined to SOA style design. Now, if we take the available open-source frameworks available to achieve that we have Spring-ws and also Axis2(which supports both styles). I have a task to design SOA based e-commerce app. where loose coupling, quick response, security and scalability are the key points. So it is very important to choose the right framework from the start.
Based on past experiences, which of them or something else do you guys think to be a more appropriate option for my requirements.
For contract first I'd recommend using JAX-WS. Either CXF, JAX-WS RI or Metro (Metro = JAX-WS RI + WSIT) seem to be the best implementations around that can take any WSDL contract and generate the POJOs (or vice versa).
That is a tough question.
I have used Axis2 in the past but am relatively new to Spring WS. What I do like about spring WS is the options I get with respect to what API's I use to handle my incoming and outgoing requests (XmlBeans, JDOM, Castor etc.) and the excellent integration with a Spring based stack.
You mentioned the Contract First approach. I am not sure if Axis 2 has something like this but Spring WS has a schema to wsdl generator. You can see an example of this here:
http://static.springsource.org/spring-ws/sites/1.5/reference/html/tutorial.html
Both the frameworks offer all that you ask for in terms of features such as loose coupling, response, scalability etc. Spring-ws may also offer good integration with Acegi as far as I think but I have really not dived deep into that topic.
If you're going to create spring based application then use spring-ws. If not, you can look at jax-ws referense implementation and metro service stack. And here is another good web-service stack you may want to look at - CXF.
Axis2 is what I work with and is pretty solid solution. Also, I'm kind of allergic to Spring.

Categories