Our customer has a client/server application based on mdb database (microsoft access) and he'd like to expose part of data via his web site (deployed in java).
What is the best way to achieve it?
I need a place to start (for example web service, spring integration, mule, service mix).
If the web server is currently located on your office LAN, and the access front end applications can use/see the folder where the back end mdb file resides (we're talking windows networking here), then in theory you could expose some of this data to the web server if web server loads and usage rates are not going to be too high.
In the case that the server is not going to be on the same Office Network, then an often used an reasonable solution is to simply move the back end data out of access and move it into some database server such as SQL server, or mySQL. When you do this, then both the access application (front end part) thus continue to run and function as before. And now also the web site can also share that data. This so called upsizing process of access data is not hard to do, but you want a competent access developer that knows both SQL server and access, and has done upsize many times. If the developer done this many times then it not a lot of work in most cases to move the data out to a server and keep the existing code investment.
So your choices are to keep the access code and database as is, but simply move the data out of access to a server based system. As noted the other alternative is in the case that if your web server is attached to the same network where access data resides, then in theory would be a simple matter to place the access backend data on the same server as the web server. This setup would allow both the locally users on the Office Network, and the web server to share and utilize the data in the access backend file.
Another alternative is of course is to have access to connect to a database server your utilizing on the web system, such as MySQL of SQL server. Since access can connect to the database server in this fashion, then again it is theory possible to shuffle data at predetermined times, or even during use to pull data down that's been gathered from the web site into the access application. So you keep Access as is, but connect it to the web part that gathers needed data.
Which of the alternative above choices above makes sense will depend on your particular set of circumstances.
To really throw a wrench into this mix, access for 2010 can build scalable cloud computing systems where the data is based either on Azure SQL or even 100% web based if you have SharePoint. In fact when you publish an access database to sharepoint now the result is .net XAML (zammel) forms and a scalable system in terms of users. In the following video you'll say that the halfway point I switch to running the access application entirely in a browser:
http://www.youtube.com/watch?v=AU4mH0jPntI
To do the above access web development, you'll be using SharePoint. However, if your organization does have SharePoint now then this could be a reasonable possibility for you.
You can connect to your ACCESS database with Java through JDBC-ODBC Bridge.
The steps to do this would be:
In your server (the one hosting your Java Web Application) create an ODBC entry pointing to your ACCESS file. Name it mdbodbcaccess.
Then connect to that ODBC entry from Java using JDBC.
Something like this:
//
// points to the entry you've just created
//
Connection conn = DriverManager.getConnection("jdbc:odbc:mdbodbcaccess");
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("select f1, f2 from table");
while (rs.next()) {
// iterate your resultset and do something with it
System.out.println(rs.getString("f1"));
}
rs.close();
st.close();
conn.close();
Alternatively, you might want to use pooled connections from your Application Server.
I believe that you are a little bit disappointed.
MDB is Message Driven Bean. It is not database. It is a way to listen to JMS destination and perform some action driven by JMS messages. The data already must be saved somewhere in DB. If they use MDB it is a Java EE application.
Now about the site. Which technologies are used for site? If it is java based technologies your life is easier because the site is a Java EE application too. In this case you actually have 2 Java EE applications. If all these correct you can
merge them. In this case you can just call the "mdb based application" from the back end of the web site.
Alternatively you can call one application from another. Perform remote EJB call or expose some of the API as a web service and call it. Or even connect to the queue of "mdb application" from site and send messages.
If site is not written in Java use web services or connect to queue.
Generally you have a lot of possibilities. But it is hard to recommend something specific without additional details. I hope that this answer helped you a little bit. If you need more help please provided details.
Related
I have a central SQL server which can be INSERTED INTO and SELECTED from via PHP. However I have built a Java application which I hope to be able to Insert and select stuff in the SQL table with that I have hosted on a web server.
How would I go about doing this? I don't really want to have the root password with JDBC in the source code as even if it is obfuscating it can easily be deobfuscated and then the user has direct access to the database.
Someone said to me that I should use an API but I don't see how I will be able to interact with the database by doing this.
If you already have a PHP application running server side that handles database interaction; I recommend letting that handle if for you.
Write an API in PHP that handles all of the database interactions and send requests to that API from your java application. (I'd probably have the users create an authorization token to pass along to the API as well so you can track who is using your API and limit access).
Your application can then send HTTP(s) POST/GET/etc requests to your PHP that will then handle the database interactions and return the results. Your database username and password will be kept on your server and your application will not need to know them.
If you don't want to rely on a backend service and want your client application to interact directly with the database... You'll probably have to include a username and password in the code. BUT I'd create a separate user in the database with limited accessibility that could be removed anytime you suspect abuse.
I need to secure the connection between my primary java app and my MYSQL server. Right now I have a class in my primary java app with the info about my SQL server (login details; user, password, schema etc).
I tried obfuscating that class but it didn't succeed. Then I heard something about calling an external java app with the connection info, and retrieve that info securely.
How can I execute such a thing?
Runtime run;
Process pr = null;
run = Runtime.getRuntime();
pr = run.exec("your program.jar");
pr.getInputStream().close();
InputStream eos = pr.getErrorStream();
and you can use a file to pass your info to the jar application
When dealing with a client/server style application, all the business logic, including the persistence layer, should be maintained on the server side.
That is, the client connects to some server process and makes requests. It should never care about how the data is managed or stored. It just cares about getting and manipulating the data. This also means that you centralise the business associated with that data, which means that should it change, you are less likely to need to change the client.
This also means that all the access information for the database never leaves the domain of the server.
Now the question is, how do you achieve. This answer will come down to exactly what it is you want to achieve an the means by which you want to achieve it, but, I would also add, the client should be authenticating with the server first, meaning that the user must be made to enter and user name and password in order to be able access the data (unless it's a public accessible API, then you probably don't care).
You could use
RMI. This would allow you to expose server objects that the client could interact with. This is good if you wish to send objects from the server to the client. It allows the client to interact with Java objects as if they were local objects.
From a coding point of view, this is a (relatively) simple solution, as you are dealing with Java Objects. The problem is though, only Java clients (with the right libraries) will be able to access the server.
You could use
Plain Sockets. This will allow you to connect to a service on the server and communicate with it.
You can even serialize objects between the client and server, allow the application to deal with Java Objects as well.
This is also a much more difficult approach, as you become responsible for dealing with the low level protocol and error handling (which RMI takes care of for you).
This approach does, however, provide you with the opportunity for other clients to connect to your server (so long as you are using just a plain sockets and serializing objects ;)).
This is a lot of work...
You could use
Some kind of web service (Servlet's under Tomcat for example or event a J2EE server), that would use simple HTTP requests to list of available services/functions that would return either something like JSON or XML response which the client would then need to parse.
This is, by far, the most open and probably the most common solution. It would take some work to get running, but is far less involved then using something like sockets and is also the most flexible, as you wouldn't need release no libraries each time you want to change or update a service.
Now all these allow you to provide secure connections over the wire, through SSL, you just need to establish the correct connection from the client to the server, so you've got an added level of security.
Each hides the database access behind a server layer, adding additional protection to the database.
I have a desktop application and it makes use of JDBC. I have no problem with JDBC whenever I use localhost. Now, I am to connect to a server that does not allow remote connection. I was advised to provide a web service to serve as a gateway between my application and the database.
An alternative solution I can think of is, to look for a mysql server that allows remote connection. I find it difficult to look for tutorials where I can clearly understand web services in java. I've done some research and I was told I could use PHP to write a web service and generate JSON file, then I could parse it in java. But If I do that, all my JDBC codes have to be recoded/removed.
Is it possible to connect to the database remotely without having my JDBC codes removed? Or can I incorporate Tomcat with JDBC? Thank you!
Here's what I get..
Exception in thread "main" com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
Caused by: java.net.ConnectException: Connection timed out: connect
Your questions seems to be leading to an architecture similar to this:
But unlike what your question suggests - the Server Side Module doesn't relay DB queries from the desk-top application to the database - it acts as a server to your desktop application which becomes a client application.
This means re-architecturing (not a real word I think) of your application - but a common best practice. The server side module is responsible for authenticating and authorizing your users to ensure that no one can perform malicious activities on the database.
There is no short answer here - you need to consider if this is the direction you want to go with.
An alternative as others suggested is to allow direct access from the desktop application to the database via a firewall. I assume you are posting here since the people responsible for the database's integrity told you you shouldn't do that.
I think you don't need web service here. To address your issue, you can enable remote access in your MySQL server. Please follow the instruction which is available in this blog. If your MySQL server hosted in Windows environment please refer this document also.
After that update your JDBC URL with remote MySQL server domain or IP address.
To connect Database with web services is higly not recomandable.
Think this way web services is having input/output pattern.
so you want fetch data from table1, with method1.
table2 with method2 etc...
so provide remote access for that database server this could be fine.
You can allow remote connections in MySQL. You're going to have to search for a guide for the specifics depending on the server it's running on (here's one for debian). Although if you don't trust the people running the application or the DB contains sensitive data I would strongly advise you not to do that and use the PHP instead as it introduces a lot of security issues. If it's only IP address that needs to connect at any one time you should only allow that IP address to connect, that will make the security vulnerabilities smaller.
There is nothing stopping you from accessing a remote database using JDBC apart from firewall rules. It is generally considered a bad practice to expose your db credentials over to client side - even if hardcoded in code. This is architecturally flawed approach and should not consider for more than school homework.
However, if you need the solution, you will have following options to look at:
1) Check for the ip address on which Mysql runs. It must not be localhost but a IP like 192.168.1.2, etc..
2) Check if the JDBC error is Authentication related, then you will need to add right permission to the user account. MySQL security model ties the username and the IP from where the user can login. You may need to correct those.
If both are correct, please post the exact exception which you are getting while using JDBC.
You don't have to use a web service. You can implement any form of client/server communication e.g. web services, REST, RMI, native sockets etc. It would be worthwhile to investigate these and determine which is most appropriate. However....
This strikes me as an architectural issue rather than an issue surrounding specific technologies. It sounds to me like you're being guided down the path of implementing some service that allows you not only to access the database, but provide a richer API. e.g. you don't want your client to insert into a table. You should provide an API to add to a shopping basket. i.e. you're working at a different level of abstraction (in the future you may implement your database in a completely different fashion and you don't want to change your clients).
The above is a standard pattern in the Java EE world and wider.
I have an SQLite Database on a webserver. I would like to access the database from a typical Java Desktop Application. Presently, I'm doing this thing...
Download the Database file to a local directory, perform the queries as necessary.
But, I'm unable to perform any update queries on this. How can I do this. [ On the actual database]
Another question is, to directly access the database from web in java (is this possible), make direct queries, updates anything etc,.
How can I achieve this type?
I've written code for connection of Java to SQLite and is working pretty fine, if the db file is in local directory. What changes or anything I have to do to establish a link to the file on webserver without having to download the database file.?
Thanks in advance...
CL. is right saying that if you need to access from desktop applications to a web database, SQLite is not an appropriate choice.
Using SQLite is fine in small web sites, applications where your data have to be accessed from and only from the web site itself; but if you need to access your data from - say - your desktop, without downloading the data file, you can't achieve that with SQLite and HTTP.
An appropriate choice for your web application would be MySQL or other client/server database, so that you could be able to connect to the database service from any place other than your web application, provided server access rules set permit that (e.g. firewalls, granted authentication, etc.).
In your usage scenario, you would be facing several orders of problems.
1) Security
You would be forced to violate the safety principle saying that database files must be protected from direct web exposure; in fact, to access your web SQLite database file from your desktop you would be forced to expose it directly, and this is wrong, as anyone would be able to download it and access your data, which by definition must be accessible just by you.
2) Updatability without downloading
Using HTTP to gain access to the database file can only lead to the requested resource download, because HTTP is a stateless protocol, so when you request GET or even POST access to the database, the web server would provide it to you in one solution, full stop.
In extreme synthesis, no chance to directly write back changes to the database file.
3) Updatability with downloading
You could download your file with a HTTP GET request, read data, make changes and the rest, but what if your online database changes in the meanwhile? Data consistency would be easily compromised.
There could be a way
If you give up using HTTP for your desktop application access to the database, then you could pick FTP (provided you have access credentials to the resource).
FTP lets you read data from and write data to files, so - on Linux - you could use FUSE to mount a remote FTP sharing and access it just like if it was connected to your local file system (see this article, for example).
In synthesis, you:
Create a mount point (i.e. a local directory) for FTP sharing
Use curlftpfs to link the remote FTP resource to your mount point
Access to this directory from your application as if it was a conventional directory
This way you could preserve security, keeping the database file from being exposed on the web, and you would be able to access it from your desktop application.
That said, please consider that concurrent access by several processes (desktop app + webserver instance) to a single database file could lead to problems (see this SO post to have an idea). Keep that in mind before architecting your solution.
Finally, in your usage scenario my suggestion is to program some server-side web service or REST interface that, under authentication, let you interact with the database file performing the key operations you need.
It is safe, reliable and "plastic" enough to let you do whatever you want.
EDIT:
MySQL is widely used for web sites or web applications, as it is fast, quite scalable and reasonably reliable. Activating MySQL server is a little bit OT on StackOverflow and quite long-winded to report, but in that case you could google around to find plenty of articles discussing such topic for your operating system of choice.
Then use MySQL JDBC driver to access the database from your Java desktop application.
If your idea is to stick with SQLite, though, you could basically prepare four web endpoints:
http://yourwebsite.com/select
http://yourwebsite.com/insert
http://yourwebsite.com/update
http://yourwebsite.com/delete
(Notice I specified "http", but you could consider moving to SSL encrypted http connection, a.k.a. "https", find details here and here. I don't know which webserver are you running, but still googling a little bit should point you to a good resource to properly configure https.)
Obviously you could add any endpoint you like for any kind of operation, even a more generic execute, but play my game just for a while.
Requests towards those endpoints are POST, and every endpoint receives proper parameters such as:
table name
fields
where clause
... and the like, but most important is security, so you have to remember 2 things:
1. Sign every request. You could achieve this defining a secret operation key (a string which is known to your client and you server but never travels in clear text), and using it in a hashing function to produce a digest which is sent together with other parameters as an incontrovertible proof for the server that that request it's receiving comes from a genuine source. This avoids you to send username and password in every request, which would introduce the problem of password encryption if you don't use https, and involves that the server has to be able to reconstruct the same signature for the same request using the same algorithm. (I flew over this thing at 400Mph, but the topic is too large to be correctly treated here. Anyways I hope this could point you in the right direction.)
2. Properly escape request parameters. "Sanitize" parameters someone calls it, and I think the metaphor is correct. Generally speaking this process involves some filtering operations performed by the server's endpoint, but it basically could be written as "use prepared statements for your queries". If you don't it could be likely that some malicious attacker injects SQL code in requests to exploit your server in some manner.
SQLite is an embedded database and assumes that the database file is directly accessible.
Your application is not an appropriate use of SQLite.
You should use a client/server database.
In any case, you should never make a database directly accessible on the internet;
the data should go through a web service.
I am making an Android application. Since it is so simple, I first thought I could simply eliminate the need for Java application on the server which acts as a middleware. I tried directly connecting to the database using the JDBC driver for MySQL but my program is crashing so I'm not sure if Android "supports" the JDBC driver for MySQL.
So I am thinking of how to implement the application. Basically the application writes some data from a remote MySQL database and retrieves some data from a remote MySQL database.
Do I connect to a Java server program using sockets (or some other method of communication)? Or could I implement a direct connection to the MySQL database from the client application?
I tried directly connecting to the
database using the JDBC driver for
MySQL but my program is crashing so
I'm not sure if Android "supports" the
JDBC driver for MySQL.
Never never never use a database driver across an Internet connection, for any database, for any platform, for any client, anywhere. That goes double for mobile. Database drivers are designed for LAN operations and are not designed for flaky/intermittent connections or high latency.
Do I connect to a Java server program
using sockets (or some other method of
communication)?
It doesn't have to be Java. It just has to be something designed for use over the Internet. As Mr. King's comment suggests, Web services have been used for this for much of the past decade. For Android, REST Web services are probably the easiest to consume, since there is no built-in support for SOAP or XML-RPC. But whether the Web service is implemented in Java, or PHP, or Perl, or SNOBOL, is up to you.
Well, OK, perhaps SNOBOL won't be a viable option. :-)
I know this might be a little late but as I ran into the same problem with a project at school I wanted to share my solution with you as you might profit out of my experiences.
Android is bad for Database-Operations so creating a normal Database-Controller wasn't a thing. Instead I created a Server in Java which handles all Database-related stuff and can also be extended (in my case I used a Feedback-function, too).
The Github-REPO is: https://github.com/Cedced-Bro/Public-Server You can check it out and this is open-source so you can use and contribute to it if you have more ideas to it.
To answer your question more properly: I would strongly suggest to NOT grant all users direct access to your DB as you can run into security issues with malicious users. This was the reason why I created this controller in the first place instead of just a PHP "forwarding"-server.