I would install failsafe cluster rather satisfying every client request about offline workability. You may end up implementing all the front-end and middle-end features in offline mode :)
I believe offline mode should be used with care. The email applications are by nature offline. If you are certain that what the user does is offline by nature - implement it. If you have concerns that it should be involved into transaction (I mean a bit wider meaning than DB transaction) - implement it online and think about fail-safe servers. Concerning front-end and middle-end, AFAIK, every unit of work is a transaction which is done with multi-level authorization, including business authorization. You either implement all the authorization offline (insecure at all, and impossible in some cases) or defer authorization untill online mode (non-transactional). If a request of some client was satisfied (in offline mode) and then hasn't passed online authorization (for instance it violates some limits which can be thruly calculated on the server side only), you will have to call the client and tell him your appologises (or not directly you, then the bank. but the bank will then call you and tell you something awesome). Or just tell me the name of the bank. I will never become its client :) Carlo Camerino wrote: > > it's not for the public to use. but rather for people within the banks. > internal applications. sometimes central connection is not available. > > On Fri, May 1, 2009 at 9:37 PM, James Carman > <jcar...@carmanconsulting.com>wrote: > >> Are you sure a banking application would be the right place for a >> gears-based implementation? Wouldn't it be kinda important to make >> sure the main server knows where everything is, when money is >> concerned? >> >> On Fri, May 1, 2009 at 4:04 AM, Carlo Camerino <cmcamer...@gmail.com> >> wrote: >> > Hi, >> > >> > Is there any project which has Wicket And Google Gears Integration? >> > Wicket has really done a lot of us in speeding up development time. >> Coming >> > from a struts we saw the power of Wicket in terms its reusability and >> i've >> > noticed that >> > wicket already did most of the tasks that we would have to manually do >> using >> > struts application, like session timeouts, redirects, etc.... >> > >> > One of our main concerns however are that clients >> > are asking for our applications to be available even if the network is >> down >> > or if the central server is down.. >> > Currently we implemented our applications in a distributed fashion >> wherein >> > every branch ( Remote Location) has its own server. >> > However, this has implications of cost and administration issues. >> > However, if offline mode is enabled we can just begin syncing right. >> > >> > I think that Wicket WIth Google Gears Application will make it even >> better . >> > >> > >> > I think this is really a plus when it comes to marketing it to >> customers. >> > Most of the applications that we create our banking applications and >> any >> > downtime is costing our clients. >> > >> > Hopefully we can also do this to offload the central servers and to put >> > processing into client machines. >> > >> > One large problem I see though is that most code wil have to be moved >> to >> the >> > Browser Layer. >> > I'm thinking of how to create a wicket application which is mostly run >> by >> > java classes work on the client side. >> > Looks as if there will be a lot of code changes... >> > I'm not really sure if it would be a totally different programming >> model. >> > >> > Anyone out there tried to integrate Gears And Wicket >> > >> > Carlo >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > -- View this message in context: http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23352910.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
