The first application (web-based) will be located at site1 and once the information is processed, it will be sent to the second application(web-based) located at site2. Application2 needs to be able to do the same thing as application1. Because of this, there has to be a way to share the database to keep data in sync. I wanted to go web-based for these two applications, but the issue arises, what if the internet is down? If application1 goes down due to a blackout or lost of internet, application2 should still be able to do what it needs to. I was thinking the database/server will be on Amazon EC2.
Even if I go with a standalone application for site1 and site2, it still needs some sort of internet connection to talk to a shared database/server right, possiblity through tcp connection? Because of this, I dont see why it shouldn’t just be a web-based applicatin then. This the disagreement I’m having with my team.
I want to know the pros and cons of making these two application either being a stand-alone or web-based.
6
Before going web or standalone, figure out your business domain.
- How often app talks to server(synchronizing user-workspace, fetch data, updating data, etc.)
- How frequently user will be accessing the app (1 or 100 times a day).
- How much time user will spend on the app (5 mins or 2 hrs).
pros and cons of making these two application…
There can be a huge list, but here are just few points for standalone:
pros:
- work-offline(big plus).
- No need to conside issues like cross-browser compatability.
- No need to get into one more JEE Layer(KISS principle)
- Simpler security model(e.g. no need to bother about xss attack, etc.).
cons:
- accessbility(have to install on seperate machines e.g. home, office).
- availability(not avilable on other devices, like tablets, smartphones).
- upgrading
2
It sounds like it should be one web application with multiple modules based on functionality. Users would enter under different domains and access certain data based on roles and privileges. If you create separate code bases, you’ll likely have a lot of wasted time and effort (and therefore wasted money) from creating redundant code.
7
Unless you’re running some kind of proxy server which can fail, the internet going down is pretty much going to mean a network partition. Since HTTP is over TCP, “internet is down” probably means you aren’t able to establish TCP connections between the two nodes. I would favor web-based because port 80 and 443 are generally open through firewalls, whereas oddball ports can be a problem in some environments.
Either way you will probably need to handle a partition by figuring out how to represent your changes (i.e. each message is a serialized method invocation to be executed on the destination node). When you detect a partition (because you can’t establish a network connection) you queue up messages. The tricky part is detecting the partition has been cured and you can now flush your backlog of message to the destination.
However, and this is where CAP comes in, once you have a network partition you have to choose between availability and consistency. http://en.wikipedia.org/wiki/CAP_theorem . That, IMHO, is a larger, thornier problem than the transport layer.
Can have a web based (runs on browser) but is hosted on your LAN (very fast and does not depend on net)
If you have enough servers for today and usage 2 years down the line at both locations and a good IT team to support the servers then this is the way to go. Both apps can sync up at pre defined intervals with error checking to retry every 15 or so minutes when net is down.
Stand alone means the app code is on the local computer of the client. This means java needs to be installed on all clients. Such apps are sometimes called thick clients if they talk to a central server. I do not think this is the way to do unless people work on the field on laptops without good connectivity. Can be applet or web start or stand alone app.
… there has to be a way to share the database to keep data in sync. I wanted to go web-based for these two applications, but the issue arises, what if the internet is down? If application1 goes down due to a blackout or lost of internet, application2 should still be able to do what it needs to.
This seems contradictory:
If the data is to be kept in sync then you would particularly want AppB to halt when it cannot connect to the same data store as AppA. Otherwise the data would likely be out of sync, at some point. Would it not?
You have to ask yourself:
- Will the data be Read-only? If not, you’ll need to devise a way to keep two databases in sync, even if the connection is lost. Would using a single Database server or cluster solve this and meet requirements?
- Do I want to utilize web-frameworks to accomplish any portion of my project? Is it necessary, or appealing?
To be clear and in my opinion: making your project ‘web based’ has nothing to do with solving any of this, unless of course you require web-based interaction with your software or data. I think this question is too generalized and needs more information.
Due to security, Java delivered via a browser is Not a Good Idea (TM). Sun has had a bad string of serious security holes that have resulted in a lot of patches. I’m concerned enough of about these security issues that I have VM setup just for browser the two sites I need to use Java for. When I wear my IT hat, I recommend that users totally uninstall Java. Most people don’t actually browse sites that require it, but they are vulnerable to other sites that contain a malevolent Java payload.
http://www.techlicious.com/blog/critical-java-security-risk-requires-immediate-action/
Something else to consider is that both iPad and Windows 8 RT do not support Java in the browser at all.
If you do need to go with something delivered via the browser, I strongly recommend that you consider going with another technology.