I have whole business logic along with its integration to database written in Java. Now I have two options: either I can write a Restful webservice to access it or I can follow the standard servlet approach to access it from UI... What are the advantages and disadvantages of both?
In fact, you try to compare things that are different.
REST is a style of architecture targetted distributed systems in the context of the Web technologies. Whereas it doesnt depend on the HTTP protocol, the latter is particularly suitable to implement these concepts. Implementing a RESTful service with HTTP means that we will leverage all its features and use them for the right thing. Those principles can be implemented with different technologies and in Java with different frameworks.
This link could provide you some insights about the REST concepts: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
Servlets correspond to an API and a container to handle Web applications. The container is responsible of the transport layer and let you focus on the way to handle HTTP requests and create responses. But you are free to them to build you application and use HTTP like you want. Most of time a framework is used on the top of them to implement applications. You can even implement RESTful applications with raw servlets if you want with a bit of additional work.
There are several frameworks like that:
Restlet (http://restlet.com/projects/restlet-framework/) that allows to create and / or consume RESTful services in Java. They can be executed in a standalone application or within a servlet container.
Spring MVC that provides a support to configure Web applications within lightweight container with dependency injection. The framework also provides REST support.
Hope it helps you,
Thierry
Webservice going to help you to communicate between two application which may be having different platform(for example communication between java and .NET possible using this).
But servlet can bind u to talk within one application which is bind with java platform. you can able to talk with two java application using servlet also but for that u have change server configuration. So please understand your requirement and use it
As Thierry said, they are diferent things, and its up to you define the need of REST implementation. I would suggest an article: http://martinfowler.com/articles/microservices.html
Its a very reusable way to isolate and expose your business logic.
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.
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,
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
Most Java web application frameworks use server-side session objects to store session state. Because this complicates scaling, I'm looking at frameworks that implement a shared-nothing architecture, e.g. the Play! Framework and Apache Click. What other frameworks should I add to this list?
GWT framework - you write full AJAX application, so you can store everything you need on client side and to server send only authorization tokens (which could be stored in memory singleton or in database for verification).
Any javascript solution for client side, where you can do the same. On client side you can use Spring MVC just for implementing business methods and allowing them via REST channels (JSON as data transfer protocol is the preferred option).
Take any of MVC frameworks, just don't use sessions. It's dead simple: most of them do not use session by themselves, it is you who decide whether to put anything into a session.
Play framework should provide everything you need as it was designed with stateless principles. As mentioned other framework could do the trick but play is a full stack and geared for rapid development (probably the equivalent of ruby on rails for java).
You can easily and quickly develop fully fledged web application with user authentication and authorisation. I would strongly advice to go through the tutorial. Java development has never been so productive and fun!
Restlet (2.1) has a CookieAuthenticator that handles authentication without reliance on server-side sessions, so that's another framework that can be added to the list.
Does anyone know of any tool that can facilitate/ease porting of an app to both Java Swing and GWT?
I've got a few "screens" that makes complete sense to have both in a desktop app and in a browser and I was wondering if there was some kind of common API that could be targeted that would facilitate creating these two different "views" (see my comment)?
I think it's entirely possible, but it would mean a different take on the server side of things.
If you do interface-based POJO development of the server-side components that the UI communicates with to do the work, you leave yourself the option of either an in-memory implementation or one that acts as a proxy to a remote component. The Swing desktop UI might use the in-memory version of the server-side, while the GWT version talks to the distributed version.
If you use Spring, it's easy to inject the appropriate implementation for each UI. Both only know about the interface and are oblivious to the implementation details.
I imagine a single code base that might be packaged in different ways. The Swing desktop app would be packaged and delivered as a JAR file. It wouldn't include the GWT or web tier controller classes. The GWT code base would include web configuration and controllers, because controllers are really part of the web tier.
The service interface and everything behind it would remain the same for both. The only difference would be that the Swing desktop configuration would inject the in-memory service layer implementations of the service interface. The web configuration would inject the web-based implementations of the service interface.
Whether my attempt to read your mind for requirements is correct or not, this approach has value regardless of how you decide to implement the service and client tiers.
I'm a Spring fan, so I'd recommend the use of Spring.