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

Reply via email to