Agree, I mentioned already it depends on the nature of the application. Anyway unless the bank pays you on time-and-material basis it is risky to implement two modes application (for bank and for dev team).
Consider Java Web Start vs Gears. Carlo Camerino wrote: > > hmm, you have a point here.however, every requirement is different. > > I know that it may sound weird, but still I believe that it depends on the > nature of the application. > There are lots of types of applications that banks use. > Some I know would have to always have a central server managing it. > > There are different types of Technical Architectures that we cater for in > our applications. > There are some applicationms that always require online mode regardless > adn > there are applications that the user just > needs to be able to view customer information ,etc.... > > > actually it's hard to decide here. > on the downside, I heard that GWT consumes a lot of resources on the > client > side, it's also a consideration. > > Failsafe servers are of course an option but again, the network is still a > factor here. > For example a very slow connection to the central server makes my > productivity a lot less. > Some places suffer from low bandwidth, unreliable networks, etc... > > I saw the value of distributed or offline applications that uses > synchronization. > It will be harder for the developers of course sicne they have to cater to > two modes. > On Sun, May 3, 2009 at 1:55 PM, Vladimir K <koval...@gmail.com> wrote: > >> >> 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 >> >> > > -- View this message in context: http://www.nabble.com/Wicket-Offline-Applications-tp23329675p23353287.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
