I'm trying to write restful JSON webservices. I have implemented a few using CXF, however with CXF, JAX-RS the dependencies are bloating up the single page web application. Is there any easy way to compose restful services without any of JAX-RS and in particular without using JAXB based marshalling/unmarshalling.
If CXF is providing more capabilities than you need, look into Jersey or Restlet, both of which may provide a library that specifically suits your needs. Note that these are going to implement the JAX-RS specification.
Other guidance may depend on your environment. You very well could write a servlet and handle the JSON yourself, see here for a discussion: Reasons for not directly writing Servlets for creating a REST API
Related
I feel a bit naive for asking, but I'm trying to get a better understanding of web service frameworks.
Do you absolutely need a Jax-WS/RS reference implementation (like Axis/CXF) to run a web service application on a server like Tomcat? Is it at possible to get by with a collection of your own imports (Spring Framework libraries, Java EE libraries, JAXB, etc.), provided that you do not need things like wsdl2java auto-generation?
Are Axis/Axis2/CXF an essential part of any web service project, or just a nice to have?
I've used CXF and Axis in the past, but both were buried so deep beneath Spring and my IDE that I never got a clear picture of where the web service framework ended and the Spring framework/dependencies began.
The documentation on the web service frameworks also doesn't tell me much, as it focuses on what they frameworks can do, vs. how you might be able to get by without them.
Thanks
If you want to deploy a web application on Tomcat then the bare minimum you need to do is implement the javax.servlet.Servlet interface.
If, by web service, you mean a SOAP service, then there is more you will need to do (well, to be specific, you will need to implement a Servlet which behaves in a certain way). There are two primary features that frameworks like CXF/Axis provide (and a myriad of smaller features):
Serialization/Deserialization
Bare HTTP requests are available as streams of bytes (InputStream/OutputStream). In many applications you will want to convert those byte streams into Java objects. With JAX-WS this is done by requiring the input/output be XML and using JAX-B. Other frameworks (e.g. JAX-RS) can work with other input/output formats (like JSON).
Routing
An HTTP request consists of a URL (perhaps with query parameters), headers, an entity body, and various metadata around the call itself (e.g. IP address, session object, etc). Somehow this request has to get mapped into a method call in your service, with parameters. In JAX-WS this is done by mapping parts of the SOAP envelope with information about your service endpoint gleaned from reflection.
So...
If you want to skip using Axis/Axis2/CXF you will need to find some way to implement those two features yourself. You will almost certainly also be surprised by the amount of tiny details involved in solving those problems (e.g. SOAP RPC/encoded message format versus document/literal format, etc.)
CXF will also implement a number of SOAP extensions, the most prominent of those being ws-security (although many people end up using Spring security and bypassing formal SOAP security anyways).
Alternatives
Your question is a little vague so I'm not certain what you're after but there are some alternatives.to just using Axis/CXF...
Different JAX-WS library
There are other JAX-WS providers out there. For example, you could use the JAX-WS RI although your experience is not likely to be too much different than CXF/Axis.
Different web service technology
Rather than using SOAP you could use a RESTful framework like JAX-RS. This can be particularly helpful if you want to understand more the connection between HTTP and your calls. There are a myriad of articles discussing the benefits/drawbacks of SOAP vs. REST so I won't go into that here. In general JAX-RS is a lot more clear and customizable but requires more work to configure.
Hi I am working REST Services and I just want to know how can I provide the web descriptor for REST Services. It will be great if their is some API that can directly produce the WSDL for REST Service.
I am using Spring STS for development is their anything inbuilt in Spring STS.
I have few more questions for the same:
Is it feasible to provide the descriptor for REST Service.
Providing the descriptor is not the violation of REST or HATEOS architecture style.
What are the different ways to achieve this.
REST services shouldn't use WSDLs. WSDLs are used for SOAP Web services, not for the REST design style.
Instead of using WSDLs, REST APIs should be discoverable.
Possible duplicate of this Stackoverflow question.
Though it's possible to generate some sort of WSDL if you use WSDL 2.0, people don't seem to generally describe REST services with WSDLs. This is because REST services are usually HTTP requests with GET/PUT/POST/etc methods.
At best, people can generate something called a WADL, but generating WADLs hasn't really taken off in the general community.
There's no de facto standard for describing REST APIs. If you need to automate it, I recommend looking up how to generate WADLs.
There are also other solutions/alternatives out there used to document and describe REST APIs. It all depends on what your actual requirements are.
Some other good Stackoverflow questions to explore:
What is the reason for using WADL?
Why the slow WADL uptake?
I don't know "anything" about WebServices in Java and eventually I need to do some REST work in Java and well I want to strart learning it this weekedn d:) So my question is do I need to first learn Java web services before I can learn REST webservices? what are the prerequisites stack of knowledge I need to learn first? and your suggested resources.
Thanks
The Java Web Services stuff only have a small relationship with REST services.
Both are "remote services" for the web, so they share the same kind of problems: object representation, security, error handling, etc.
But you don't need to learn the complexities of WS-* like service definitions (WSDL), SOAP... and a large list of stuff.
The small relationship between REST and WS in Java, comes when you want to "automatically" convert objects to XML or JSON. Because Java REST frameworks based on JAX-RS can do that by using JAXB (Java XML Bindings) an object conversion framework used also in the Java WS framework. But you don't need to use that object conversion stuff either.
Some JAX-RS compatible frameworks -like Apache CXF-, can be used also to do JAX-WS (the Java standard API for WebServices). But note that general services frameworks like CXF, have to deal with other complexities (like support for different transports) that you don't need to learn.
What you need to learn first?
Java Servlets: You don't need to be an expert on servlets, but REST services are mounted over the Java servlets infrastructure and knowledge about it will help.
Dependency injection (DI): When you start doing REST resources that access to databases or other services, you'll want to pass some collaborator objects to do that. Most of the frameworks resolves that problem by using DI. For example most of the JAX-RS frameworks can be used with Spring or Guice.
TIP: I found lots of people that uses Spring or Guice because.. tutorials shows that is the correct way to do it. But they don't know what are trying to resolve, and end with complex unmaintainable stuff. My recommendation is that before using any DI framework, first learn the concepts behind them.
(Optional) A little bit of JavaScript and AJAX. If you plan to use the REST services from a web page, is good to learn how they are going to be used.
Edited: To include a mention to Apache CXF, and use the term JAX-RS instead of Jersey that is a specific implementation.
There's a good summary of the Richardson book here: http://martinfowler.com/articles/richardsonMaturityModel.html,
I've been looking into JAX-RS lately because I really like the Java platform and a RESTful style of web development. I've read a lot about using JAX-RS for creating RESTful Web Services, but is it possible to use JAX-RS to create RESTful web sites? I guess more specifically, is it possible to use JAX-RS as a controller (to retrieve required data from the server) and then forward control to a view engine to render the appropriate HTML?
I've been googling around but haven't found any resources that show you how to do this.
Thanks for any insight/help.
I think you are having difficulty with your google searches because not many people are doing this. JAX-RS was designed for web services, so developers don't think of using it as a controller for web applications. However, there is no reason it wouldn't work.
Check out this blog post: JAX-RS as the one Java web framework to rule them all?
I think it's exactly the kind of thing you are looking for.
If you truly want to rely just only JAX-RS for your web framework, Jersey might be your best bet. Keep in mind the features you get from it are going to be bare minimum and you are obviously not going to get all the bells and whistles like what's provided by JSF, Wicket, etc.
If you know your web application is going to rely on Spring, perhaps you should consider using Spring MVC 3.0. It provides restful web services-alike and it gives you better features so that you don't need to implement most of them yourself. Granted, Spring MVC 3.0 is not an implementation of JAX-RS and based on what the Spring developer said, it seems like they will never make Spring MVC as an implementation of JAX-RS since they are already quite a few stable implementations out there. However, the syntax is pretty similar in my opinion, or at least I was able to understand them rather quickly even though I have been using Jersey for quite awhile.
dbyrne is right that almost no one is doing this. It's more conventional to use JAX-RS to dump information to JSON or XML. Then you fancy up the web browser with an RIA framework (e.g. Ext JS), which handles manipulating the DOM and injecting data as its fetched in JSON/XML form. This approach is powerful. You can write multiple, possibly non-browser clients for the service, all parsing the same JSON/XML. You can write "one-page" webapps, where all information exchange happens through AJAX after the initial pageload. I urge you to investigate and consider its strengths and weaknesses in the context of your particular problem.
Returning to your question: the answer is "sort of". This functionality is not directly provided by the JAX-RS spec (as of 1.1). However, it is in the JAX-RS reference implementation, Jersey, through the Viewable response object. See this blog post if you want to investigate further: http://blogs.oracle.com/sandoz/entry/mvcj. I want to point out that I have no experience with this side of Jersey. It has been pleasant to write XML/JSON-returning web services with Jersey, but I can't speak to this server-side HTML templating business.
Edit: dbyrne's edited his answer to include a blog post which points to the one mentioned above. I think we've both converged on approximately the same answer.
Is AXIS or CXF necessary for Java web services? Can it be all done via the JDK (1.6)?
Is AXIS or CXF necessary for Java web services?
No. Although Axis2 is the most popular framework to work with Web Services is not the only way to do them.
Can it be all done via the JDK (1.6)?
Yes, but it is way much harder. You will benefit tremendously from using a framework used by others apps and from the bug fixes the development team provide. Doing all by hand is like reinventing the wheel.
If you want to have full control of what's happening underneath, probably you could go with: JAX-WS
or if the application is very simple, directly with socket.
But again, Axis2 is the canonical way to do WS ( but not the only one )
The following is based on an all to true and personal story:
So you want to consume a web service in your Java web application, and you don't want to add 10MiB of JARs to your lean 1.3 MiB .war file, and besides you are great at parsing XML (you can hand code XPath Queries, and XSLT files), you totally understand HTTP, and the client you are interfacing with has great documentation. You download the WSDL look at your endpoints and your methods and start creating a Java class that maps to the features you are going to need. You feel great already.
They you start reading up on how to send a SOAP request and you think well this looks a little verbose but what they hey it's all just a string, so you start building a utility that takes your Java request object and converts it to a SOAP request. You send your clear SOAP request to the server but it gets denied (missing a signature).
So now you start adding encryption JARs to your project and you start looking at how to calculate a signature of part of an XML document and include both it and the document in the request. This takes you a while but with enough hacking you get a message that you can send to your soap service and you are now dealing with the SOAP response. Now you are feeling great...
Until the admin at your client changes their security requirements, issues new public keys, and updates the soap interface with some custom types, and your next client who is running a similar service (but on a Windows Server) wants you to implement with them as well.
At this point I gave up trying to implement this in a pure Java way and just started using standard libraries. They deal with stuff like encryption, marshaling, deviations form the standards and they let you focus on stuff that is closer to your problem domain. I hope you can save yourself the lost month it took me to learn this lesson.
An update on the landscape of web services in 2013.
Web services used to be SOAP and XML-based. Web services were standardized into JAX-WS. Some of the more popular frameworks are (were):
Axis 1.x
Axis 2
Apache CXF - CXF also includes other protocols. It is a much broader framework
Metro Web Services which includes the JAX-WS Reference Implementation.
Java 6 and Java 7 include the JAX-WS RI by default. It means that frameworks are no longer needed except to generate client and service stubs / skeletons
There are other implementations not listed here that are vendor-specific e.g. IBM Websphere's WS implementation and Weblogic's WS implementation.
Generally though, to create web services, I would recommend Metro and the JAX-WS RI.
Note that there are many WS-* standards e.g. WS-Security which may not be part of all WS implementations.
Since web services have been around for a while, other alternatives have come up both in terms of architectural style, protocol, and encoding.
For instance, XML used to be the de-facto encoding. JSON is now more prevalent. It is worth looking into Jackson, a JSON parser, or Google GSON. The main arguments in favor of JSON are that it is easy to use, lightweight, and developer-friendly.
Along with JSON came REST. REST is an architectural style. With REST, you can still implement "web services" in the sense of remote services that can be easily consumed over a network. REST has also been standardized in the Java family of standards as JAX-RS. Some of the popular JAX-RS implementations include CXF, Jersey, and RESTLet.
Finally, there are some new kids on the block that use binary encodings. Those are Google Protocol Buffers and Apache Thrift. Their main goal is performance as well as broader support for other languages (Java, C#, Erland, Perl...).
When developing a web service today, the question should be:
- do I care about performance?
- do I want to access the service from many different languages?
- do I want mobile-friendly?
These should help you guide your choice. Also, I prefer to keep my dependencies to a minimum. This means I would rather take something that is native to the JRE or JDK e.g. the JAX-WS or JAX-RS reference implementation.
As an alternative to Axis, you can use the Spring WebServices framework to run your webservices application within a J2EE container like Tomcat or anything similar. I've found it very easy to use and setup, and if you want to integrate your webservices into another web application later, it's quite easy to do (I've done so myself on two separate occasions).
You can use the http streams provided by the webserver as you whish, but using a framework and some jars (which are proven to work) will save you a lot of headaches and a lot of time in the long run.
Normally you will want to use a programming framework for web services.
Something like AXIS, CXF, or the Java EE (GlassFish) download from Sun.