I'm developing a desktop application in JavaFX with login system and some data that must be saved in a remote database. The question is: What it's the best way to stablish a database connection with each user with the server? Should I use a RESTful API or connect to database using the remote host just like if it was a local DB?
What kind of data are you looking to manipulate? Depending on exactly how much control you may need over the information (and how secure it must be?) if you don't need an absolutely synchronized view of the information (re: the server side app having a persistent connection to the client which is informed on change events and such) it may be best to just build up a RESTful API to do all of your grunt work between the two.
If you're coming to the RESTful api and also have to design it I suggest giving this a good read. Best Practices for a Pragmatic RESTful API
Related
New to android programming and want to save basic student information in a database. What is the easiest and simplest way to store this data so it can be accessed by multiple devices remotely at any time? I know that android supports sqlite but this seems to be only locally on one device. Any ideas or suggestions?Eventually want to publish application on google play and want users to be able to see students names in their class for each class.
If you're not interested in setting up and maintaining a remote server, Firebase is fast, free to get started, and operates in realtime:
https://firebase.google.com/docs/database/
It seems you've answered your own question :) Place your relational database, such as MySQL, on a remote server. Create an API that performs CRUD operations on the database tables.
Then issue requests to the API in your android app: https://developer.android.com/training/volley/index.html
Yea you basically answered your own, I highly recommend using retrofit2 for android for http requests.You’ll use annotations to describe HTTP requests, URL parameter replacement and query parameter support is integrated by default. Additionally, it provides functionality for custom headers, multipart request body, file uploads and downloads, mocking responses and much more.
Here is great link to get started on your way to happy life:)
Ideally you would want to create your server to handle request and give responses, and android client for those request, if you are going the custom route you probably want a node.js server, or php server. You can even use socket.io to spice things up for real time communication, or maybe some notification system from firebase. Firebase is awesome, it handle all the aforementioned.
For the database portion if you decide not to use Firebase, please do not Raw SQLite you will have nightmares, use something like Realm it is NoSQL ,fast and easy to perform database transactions.
We have asked to design an application for a company which has 10 branches.
they need a distributed database app, using that they can store and retrieve data of other branches. In order to achieve that i'm planning access the database through a network using the ip address for the connection string.
But i found some articles which say that using RMI
technology is the best way to achieve this. But i can't find any detailed advantages using rmi over directly connecting the apps to the database. Is it necessary to use RMI technology?
I don't know about rmi. Please give me a detailed answer. Thanks in advance.
Is RMI the best technology for doing this? We'd have to agree on "best". But my first reaction is "no".
The answer depends on whether those branches access the data over a secure network, internal to the company, or if they do it via browser and the public Internet.
RMI might be acceptable if all the branches are inside the firewalls on the same secure network. If all of them can deal with Java clients you'll be able to make it work.
But if they're going over the public Internet the only solution that makes sense is HTTPS through port 443. Clients will be written in HTML5 and CSS3 to run in browsers.
Regardless of the answer to that question, I think you want to put an intermediary between clients and the database in every case. You don't want clients accessing data directly, because it's insecure. The intermediary will be responsible for:
Authentication and authorization of users.
Validating request data.
Binding requests to queries to avoid SQL injection attacks.
Logging and monitoring.
Transaction maintenance.
RMI makes sense only if all the servers and clients are Java-based.
A more modern approach would use HTTP web services, either SOAP or REST, instead of RMI. This has the advantage of working with non-Java clients. You'll be in a better position for mobile clients that way, too.
I have developed a Java database application that has been deployed to users via a web server. Now, all is good but it has been requested that some of our external clients would also like access to the software. Is there any way that I can make the application work for these clients? The application has been put on another web sever that is accessible for external users and also has visibility to our SQL server but the application is not working, it will load in the browser but users cannot login to the system which works by database authentication. Am I missing something simple here or is this something that can't be done. I would imagine the latter since I think the web start application downloads to users machines which would explain why you can only login when a VPN connection is active.
Any help on this matter would be greatly appreciated.
Most definitely your firewall blocks the connections to your database when they are initiated from the outside. This is a good thing because you generally don't want to expose a database to the Internet.
One hacky way to do it would be to implement some kind of JDBC over HTTP to tunnel the database requests. Basically you'd use a JDBC driver that redirects the SQL requests to a web server.
A better way would be to refactor your code (I presume that would be a lot of work though...)
If you manage to abstract the data access layer, you can replace it by something more suitable for a web access, for instance a Web Service.
Finally a drastic option is to transform your client/database application into a webapp.
I am looking for some guideance in terms of what database to use server(using servlets) side of my android application.
Further down the line i will setup a website that will need to access the information from with the database.
At the moment from what i know i can use hibernate for object mapping to RDBMS or i can use JDBC for interaction with a MySql Database.
Do you guys have any best practices for using either the above or a different system for interaction between servlet and database?
If you are looking to get started quickly, you could use AppInventor, but if you want to build a backend yourself I suggest Ruby on Rails(get ubuntu if you don't have it!). Its easy to learn, easy to install, and very user-friendly.
The server and database will be handled by the Ruby on Rails framework.
Android application just acts as a client that makes request and accepts response from a Server. Server could be written using Servelets / JSP, ASP or PHP. As far as I know it doesn't matter to android client which database server is used at the server side as far as client is getting the response from the server.
We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.