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.
Related
Can I use Java backend for a browser game with Javascript frontend?
Since I already have knowledge in Java aswell as Javascript I was confused if I should forget Java for this purpose and skip to NodeJS for the backend, although I want to focus on Java in my future.
Would I need to learn Java Servlets and JSP or would a book aboout Java Networking be enough to deal with communication, or are both required since Servlet are part of a webapplication running on a web container, and Java Networking is not standalone.
You can! The choice of your technology stack for the frontend does not necessarily need to influence the choice of your backend technology (and vice versa).
Architecture
You can serve your game view directly from your java application. You could use JSP (or other templating solutions) for visual representation and/or include more logic via javascript.
You could also go for a more distributed approach, where your frontend would only be responsible for fetching and displaying the game state, while your backend would be responsible for serving and maintaining the game state. Your frontend could then inquire about and ask to modify the game state via http, and the backend might answer with the current game state represented as, for example, JSON.
Technologies
While reading about Servlets and JSP or basic networking can be of some value in itself; For this specific purpose, I'd rather look into some options to get you started more quickly. You might find using an established, modern framework easier - Since you're familiar with Java and want to focus that, I'd point you towards Spring Boot 2. Getting a web application running that accepts and serves JSON via an http endpoint can be done quite quickly. In my experience, it's well adopted in the industry as well, so you might benefit from that, too.
You are, however, free to chose in what language or framework to implement your backend: A server written in NodeJS any other language can be used for the same purpose, as long as you know how frontend and backend are going to communicate.
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.
First am not sure if this question fits here well. However couldn't think of a better place to get help. I've been tasked to list the Pros and Cons of each of these {JAX-RS, Playframework scala, MS Web Api}. I've done some research but couldn't conclude as I've not used all three to great extent. Have used playframework to create simple REST app. Have read the Web Api tutorials but have not implemented anything. Did research on JAX-RS but haven't implemented anything either. Also most of our developers are familiar with C# and introductory Java. I am more inclined towards playframework due to Scala,Akka,no server restart and scalability etc but not clear about the cons. One thing am sure is JAX-RS is standard Java EE and Web Api is standard MS stuff. Below are some of the app requirements:
Purely REST backend.
Proper authentication and authorization.
Online secure payment {Paypal etc}
Single front-end for both mobile and desktop
{angular/backbone/knockout..}
Allow users to subscribe as companies or part of companies.
Be able to connect to different databases without App restart.
Code maintenance and readability. Other members should be able to pickup without hassle.
Scalability
This is a partial answer because I worked only with playframwork 2.0 and JAX-RS.
Playframework is a MVC framework, you can use it to create some REST services but it's not focused on this kind of applications, so at least in version 2.0 it wasn't easy to add complex behavior like interceptors, etc. and you should manage authentication by yourself, I don't know if this has been improved in most recent versions of play framework.
JAX-RS is a specification to create REST services, there are several implementations like
Jersey, RESTeasy, Restlet between others. So JAX-RS implementations are built specifically to provide REST services in java. Most implementations have support to several authentications mechanism like OAuth, etc.
In my experience, JAX-RS is better to provide RESTful web services, and the code generated is in general more maintainable than the code generated in playframework, also playframework has a lot of things that maybe you don't need to use, but it will be loaded in memory when you start the server anyway. Akka it's a cool technology, but you can use it if you want it in any JAX-RS implementation.
If you want to build REST services using Scala, you could try Scalatra http://www.scalatra.org/
If you prefer java, take a look at http://dropwizard.io/, it's an embedded server that has Jersey (An implementation of JAX-RS) and a lot of cool things to provide RESTful web services, like metrics, etc, also it's easy to learn. If your team doesn't have an advanced java knowledge, this is a good option.
Playframework is great if you want an easy to learn MVC, specially for non java programmers but definitively it's not the right tool to build RESTful webservices based applications in my experience.
This is a very beginner question. I have tried to search for advice but am overwhelmed by the amount of information and would like some help with ideas on approaches to server design or what to search for!
What I would like to set up is a backend server that provides search capabilities and business logic and validation across some fairly basic data. It wont get too large.
I would then like to be able to plug in a website as a front end or a mobile app or a facebook app or even a desktop app..
My question is what is the best way for front ends to hook into the backend? I would like to have various user accounts with permission levels so authorisation would be important.
I generally only code as a hobby so whilst technically I have built a spring based website before the exact semantics of the client server relationship weren't clear to me. Now I want to separate the backend so that is is agnostic of how the data is displayed or entered completely and can run on a separate machine.
Thanks,
Rob
There is a ton on options. I had good expirience with apache CXF rest services (logic encapsulated in java beans, spring configuration) and pico web remoting ( more exotic,
but also rest service and plain java objects providing business logic)
if you ar already using spring, I would recommend to stick with CXF - it integtrates seamlesly ( and is spring configured itself )
I'm currently working on implementing the public API of our web application. The application is written in Java.
This is a financial application deployed on Tomcat. My users can manage their sales, customers, purchases, inventory, etc. It's a pretty huge application. The font-end is written in Java/GWT. The backend is written in Java s well. We use the GWT-RPC mechanism between.
What we want is to provide a way to access the financial data (read + write) via a public API. This way, developers will be able to better integrate their application (like a payroll application).
We don't use any framework. No Spring, grails, whatever. Also, no Hibernate, JPA, etc. It's a pretty old app, with lot of proprietary code for the ORM, XML-> javabean. authentication, etc. Cannot change all of that as the application is already in production and it just works that way.
The API infrastructure will be on a different sub-domain and on a different server.
The API should use Oauth to authenticate the users.
I looked into Grails, Play!Framework and Restlet to achieve my goals
Does anyone have some thought on them? Am I going in the wrong way with those frameworks? Is there another framework to look at?
Thank you all
I'd recommend following the example of Amazon and such and expose that API as web services, without regard for UI. Your have a further choice about SOAP versus REST. I think you'll find that REST will be simpler for your clients, because they only need to know about HTTP.
This doesn't mandate the use of any frameworks if you choose not to. The back end will work regardless of whether or not you use Spring, Hibernate, Grails, etc.
You'd have to rework the application you have to call the services if you wanted true reuse, but it might be worth it in the long run. Both your UI and clients would be using a common back end API that way.
I have some thoughts yes. Financial applications tend not to use OAuth. To be clear: nobody with vulnerable data uses OAuth. That includes privacy, medical and financial data.
What kinds of deployment environments do you expect to use this API. That might narrow it down, the standard answer if you have absolutely no idea who your client is, is still supposedly SOAP (since so many people know and accept the buzzword).
If you're going to expose read/write to a Java-based financial services application over the public internet, I would look at SOAP-based web services with JAX-WS as there is a pretty mature security spec in WSS and the API is relatively easy to use and may not require much in the way of changes to your existing app.
REST is perceived as easier in general but for this type of application you might find your target audience is more familiar with SOAP anyway. All depends who your target audience is and exactly what you're trying to achieve, but worth considering.