0

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.

  • What exactly do you mean by a "web-based application"? – Darius X. Mar 7 '13 at 22:14
  • +1with above comment...but if you can't get internet? Why not use a local store that you sync when you have internet... – Rig Mar 7 '13 at 22:19
  • if your requirement is that you should use two dbs for the two apps. Then so called local application db should keep track of failed sync records along with timestamp in a table and a background process continuously (for a particular time period may be 1 mins) checks for network availability and sync the data that is there in the data change tracking table. This table should have what kind of change occurred like record deletion, addition, modification so that at the other end modifications can be done appropriately. – kumar Mar 8 '13 at 13:00
  • To Darius X and Rig, when i say web-based, i mean applications that runs on the browser and a web server. – bobby Mar 8 '13 at 16:06
  • To Kumar: these two applications are sharing the same database, most likely on Amazon EC2 – bobby Mar 8 '13 at 16:08
1

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
  • These two applications will be used everyday by our clients, about 10-12 hours per day, so the application has to be on all day but does not mean its necessary used every single minute. think of it as a call center application where the application will get used when customers calls in. When customers call, the application will need to be able to retrieve info from the database and updating the info as necessary. what i'm worried about is what happens if the server/db is down. what i've been calling application2, has to still be usable even if applicaition1 is down or the server/db is down... – bobby Mar 8 '13 at 21:00
  • standalone sol is better because user might have no/weak internet connection & still can continue there work. How they can continue well think, user can still search,create,update,delete data already downloaded on his/her machine and in background you can try to re-connect and once the user is connected back to internet you can perform data-synchronization. In case of online, he/she need to wait because web browser will display them Cannot connect to internet . In a nutshell, something is better then nothing – sol4me Mar 8 '13 at 22:27
0

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.

  • Yes, i agree to not having seperate codebase. pretty much application1 and application2 will use very similiar code, especially in the business layer and data layer. the presentation layer will change since application2 would be "stripped down" version of application1. my issue is, if this is web based and application1 goes down due to a blackout or lost of internet, application2 should still be able to do its job such as storing data until the internet(EC2) is back up. if application2 is webbased, this can't happen right? – bobby Mar 8 '13 at 16:05
  • Outages are an edge case from the point of EC2. In this day and age, there's no reason to develop a desktop application unless you're dealing with laptop users in the field that will often have no internet connection. – Adrian J. Moreno Mar 11 '13 at 15:45
  • thanks for the response! i still have one more question. if i make these as web-based and i have my web server running in EC2, if the internet goes down or some reason(lets say there was an issue with my internet provider), is there a way to still run a web-based application or other way? – bobby Mar 11 '13 at 18:12
  • The web application will run so long as EC2 is running. Consider building a mobile UI for the application so you can easily interface via your phone or tablet. Finally, consider a native mobile app. If your personal internet connection fails, you can fall back to a 3G connection on your phone (tethered to your laptop?) or find a Stackbucks and hop onto their free wi-fi connection. – Adrian J. Moreno Mar 11 '13 at 18:38
  • this application will actually be more of a desktop application, not a mobile app. it is more of an enterprise application. i was from someone that if this is a web-based application, and the web-server goes down, there is a way for the web application to keep running. the person who mentioned this was a java/j2ee developer if that helps. – bobby Mar 11 '13 at 19:13
0

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.

0

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.

0

... 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:

  1. 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?
  2. 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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.