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 )
Related
I have been doing research for days and am so lost because everyone implements this differently or these tutorials are unclear.
I will be writing a web application that uses API's from sites like AWS, CROWD, etc. to create a single-sign on portal to manage many different things.
I have never worked in web development before, so this is all new. How should I get started in this project? What exact files will I need to create? Any advice would be helpful.
The only constraints that I have been given is that this will run in Tomcat, so I need to use java.
You need to understand the basics of client - server architecture and develop a
web service to standardize the REST based actions such as RPC.
I have a j2ee web application that is typically accessed over the intranet.
I have a requirement to have only a small set of webpages in the application exposed over the internet. There isn't a large set of users who need the internet access. I dont really want to expose the whole application as is over the internet, since it has some other sensitive data. I'd like to add an extra layer of access restriction/security on top (even though the application has role based access). What would be a good way to achieve that?
Some options that come to mind are below (not given too much thought to it yet)
Figure out something in Apache (our web server) to restrict access to only certain set of URLs in the application. Not sure if something like that is supported out of the box or with some modules.
Mark internet based request with some attribute in Apache, and in the application layer use Spring security to restrict access.
Use something like a citrix server to allow indirect access to the application through a virtual desktop. I wonder if this is easier said than done and if its really buying me anything.
Build another web application that acts as a proxy to my large application for those limited web pages. Initial thought, this sounds like too much work.
Your thoughts? Any Better options, different products?
I would recommend to use Spring MVC.
As you already have role based access in your application, it should be quite easy to develop controllers which will render jsp that are relevant to that logged in user.
Though Spring MVC being a proven and robust framework, compare the effort that you need put in for Spring MVC integration with other solutions.
I want to create a websocket Java API for these requirements:
"When the user logs into my application, if he enters a page which has constant updates from the server, then the Java API should identify the user and keep pushing the contents on a regular interval"
So for this I want to get started in creating a generic Java API so that for other pages, which requires push from server, I can use the APIs instead of reinventing the wheel everytime
What are the things I should take into consideration and how should I approach this problem
Please key in your thoughts
Thanks in advance
GitHub has a number of libraries which deal with Java and WebSocket. You can build your application on top of one of them. Examples are vert.x, SockJS, Atmosphere etc.
At the SockJS page you can see a list of clients/servers for working with it.
IMHO It is better to re-use one of the existing libraries/frameworks than building your own, because yours is a common usecase and working with web sockets, providing corss browser compatibility etc are not trivial as of now.
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.
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.