I'm not sure if the title I used is good, but hopefully my question will be better.
I have an java application that tracks data on PennyAuction sites(such as beezid.com), and will eventually upload all of the data to a database. Clients will download a java application and run it on their local machine, but this local machine application will have to be able to access the database and obtain all of the data.
All I have ever done is java applications programming, so this is all very new to me. Can anybody help me with a solution that will be able to accomplish this?
This is all I can think of:
Server that will run Backend application 24/7, and use JDBC to upload data to database.
Separate server for database alone.
I have no idea how the client application should connect to the database though.
Any help/links to tutorials on stuff like this would be appreciated.
You could actually let your clients connect to the database directly if the database is on a public IP.
An architecurally much better way of doing this is with webservices. This would make your system much more safe, robust and scalable.
Web services are client and server applications that communicate over the World Wide Web’s (WWW) HyperText Transfer Protocol (HTTP). As described by the World Wide Web Consortium (W3C), web services provide a standard means of interoperating between software applications running on a variety of platforms and frameworks. Web services are characterized by their great interoperability and extensibility, as well as their machine-processable descriptions, thanks to the use of XML. Web services can be combined in a loosely coupled way to achieve complex operations. Programs providing simple services can interact with each other to deliver sophisticated added-value services.
Related
I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
Need help in developing an Enterprise application which involves hundreds of thousands of notifications and calls to server. Client has mandated to use Java/Springs stack. It has 3 portals involving like mobile, Institutes and Admin which depends on web services from server.
Which type of Database we should prefer?(It should support Hundreds of requests and Should support Geo-Location based queries)
Which application server we should prefer?
Which type of server side scripting we should prefer?
How about should I go with this?
You really should read the answers to this: https://gis.stackexchange.com/q/9809
One you know it or have anyone in your team who knows it. Otherwise WildFly seems pretty good.
Once again you must choose one you're comfortable with... and look at Thymeleaf.
If you are really starting something from the ground, you really get known the Service-oriented architecture and build your solution around it.
I'm designing various parts of a network. My current thought on design for future software projects:
Webserver in a DMZ. This webserver has a hole punched through the firewall (On the sql port) to talk to an MSSQL database which is internal for all data management.
Question: Instead of having a hole in the firewall to talk to the database server, would it be better / more secure to have an internal web server hosting web services that applications in the DMZ can consume, with the database logic behind the web service ( a hole punched to talk to that webserver only. )
A webservices implementation would allow only one place for updating any API changes - which is why I'm considering it - though it would likely be slower than direct database and query access.
Any thoughts as to which is better?
EDIT: Realized that unless I put all application/business logic in the application layer, I would still need a hole punched into the firewall for sql. Since I want an added layer only for the API functions (those that affect all applications - such as "GetEmployeeByName"), I'd still need access to the DB from the DMZ...
Leaning toward the best answer being: Internal web service API server hosting web services - those are consumable by either all web servers in the DMZ, or via a proxy server in the DMZ. (so only one server needs an ssl port through firewall.) (And of course all internal servers would have access.)
There are many discussions about when three-tier architecture is a better model (here's one). You should be able to find more on Google.
Short answer: It's probably better to go with the app-tier service, if security and scalability are your goals. Be sure to focus on defense in depth as you develop all tiers and layers.
Long answer: It depends on your needs.
Edit in response to your edit: I would recommend putting most of your business logic in the app tier anyway, if it makes sense to do that. Your web server(s) should primarily be presentation.
Regardless of where you put the business logic, though, you should put all data access into the service - the web tier should only talk to the app tier.
Here's a beginning search to dig into the three-tier aspect. Here's a decent introduction for splitting of tiers and whatnot.
We are building an application that will have clients installed in many sites. Each client work on its own, has its own database and workflows. However, each client has to submit some data to the main application installed at a central position. The application at a central location must receive updates (e.g stock levels) from the distributed units. All applications are done in Java. Which is the best way/technology of sending the updates from the distributed units to the central application? JMS, jdbc, ...?
I'm going to assume that the servers at client sites have network access, and that you are able to configure the central server so that other clients can connect to it. This could either be over the internet or an internal WAN.
In this case, it's simply a case of finding a mechanism to submit some correctly formatted data, which is received and handled by the central server. This gives you a large number of options, I'm going to list just a few:
Create a web service with something like Apache Axis
Use an ESB - something like Mule or JBoss
Use a simple web Servlet on the server, and submit data using HTTP POST. You could use a simple embeddable Java web server like Jetty to do this.
Use a messaging protocol like Kryonet or Google's protocol buffers
Use a more general network application framework such as Netty
All of these will work, so it really depends on working out which is the best fit for your architecture. I suspect the simplest would be something like Kryonet, the most comprehensive would probably be something like a full JBoss ESB/application server stack.
Starting from scratch in terms of knowledge I have written a desktop application using WPF and NHibernate. This has helped me get up to speed with both NHibernate and WPF.
However, there is a requirement to make the application so that it can be accessed from mutliple places - these include handheld devices which have very simple web browser (no javascript capability), web services, Internet, the desktop application and potentially other user interfaces.
I believe this requires moving the application from its current NHibernate.dll deployed on the client to a web based application. The sheer choice of technology stacks is overwhelming and I am hoping I can get pointed in the right direction.
In essence, I want to be able to access the data from the server side in the desktop client, from the web service, from the handheld devices.
On the server side I guess I would have a web server(IIS?), NHibernate and a database and some way of communicating between the clients and the server.
What would be the best choice in this circumstance? Is it REST? SOAP? WCF? Something I don't know about / haven't mentioned?
Any assistance and advice from people who have implemented similar things would be very much appreciated.
Well since you have already made most of the work on the desktop, moving the actual data access part on a webservice is not going to be hard.
If i were you i would make that transition and make a SOAP/WCF service have the same signatures (or at least as close as possible) as the data layer. This will make the transition for your already written desktop application easier. You will have to add code for synchronizing or just safety code for when the service is inaccesible.
For mobile access via a thin web client as the browser is, you are looking at a web site/application that touches the DB (possibly via the same data-access webservice) and generates html...
I can't advise between rest/soap/wcf as i have minor prior experience with all, but i can tell you that i have created a similar setup with a SOAP WebService feeding a Web Application and .NET Compact Framework Application for WM6+ and it works well.