Designing presentation-tier for occasionally connected applications.

java-programmer, Designing presentation-tier for occasionally connected applications. Folks

We are in the process of developing a web-based app that needs to be
functional when the user is on the road where the Internet connection
to the server is not available. There are 3 basic requirements:

1. Must be web-based, not a fat client app.
2. The UI for the offline mode and on-line should be identical.
3. In the off-line mode some basic functionality to enter data (fill
forms) should be available, that do not need to be reentered when the
connectivity is available.

Can some one think of a solution on how one would design this app. To
me disconnect from the network mean no web application, but some one
here insisted that we can put a web-server/appserver on each client
machine (about 200 of these).

Swing based solutions are ruled out because that is not a web-based
architecture.

Any ideas?

Thanks in advance.

Vijay

java-programmer >> Designing presentation-tier for occasionally connected applications. Folks

We are in the process of developing a web-based app that needs to be
functional when the user is on the road where the Internet connection
to the server is not available. There are 3 basic requirements:

1. Must be web-based, not a fat client app.
2. The UI for the offline mode and on-line should be identical.
3. In the off-line mode some basic functionality to enter data (fill
forms) should be available, that do not need to be reentered when the
connectivity is available.

Can some one think of a solution on how one would design this app. To
me disconnect from the network mean no web application, but some one
here insisted that we can put a web-server/appserver on each client
machine (about 200 of these).

Swing based solutions are ruled out because that is not a web-based
architecture.

Any ideas?

Thanks in advance.

Vijay

java-programmer >> Designing presentation-tier for occasionally connected applications. Architects,

We are in the process of developing a web-based app that needs to be
functional when the user is on the road where the Internet connection
to the server is not available. There are 3 basic requirements:

1. Must be web-based, not a fat client app.
2. The UI for the offline mode and on-line should be identical.
3. In the off-line mode some basic functionality to enter data (fill
forms) should be available, that do not need to be reentered when the
connectivity is available.

Can some one think of a solution on how one would design this app. To
me disconnect from the network mean no web application, but some one
here insisted that we can put a web-server/appserver on each client
machine (about 200 of these).

Swing based solutions are ruled out because that is not a web-based
architecture.

Any ideas?

Thanks in advance.

Vijay

java-programmer >> Designing presentation-tier for occasionally connected applications. Vijay Kumar wrote:
> Folks
>
> We are in the process of developing a web-based app that needs to be
> functional when the user is on the road where the Internet connection
> to the server is not available. There are 3 basic requirements:
>
> 1. Must be web-based, not a fat client app.
> 2. The UI for the offline mode and on-line should be identical.
> 3. In the off-line mode some basic functionality to enter data (fill
> forms) should be available, that do not need to be reentered when the
> connectivity is available.
>
> Can some one think of a solution on how one would design this app. To
> me disconnect from the network mean no web application, but some one
> here insisted that we can put a web-server/appserver on each client
> machine (about 200 of these).

Putting an entire server on the client machine
would seem to lose almost the entire benefit
of doing it as a thin-client.

> Swing based solutions are ruled out because that is not a web-based
> architecture.

What do you mean? Of course a Swing
based GUI can be both web-based (hint -
JApplet) and self updating (Java Web Start)
which would, AFAIU, retain most of the
benefits of the thin-client concept.

Of course, if you are force to deal with
that horribly broken 'OS component'
made by MS, it complicates things slightly.

java-programmer >> Designing presentation-tier for occasionally connected applications. Vijay Kumar wrote:
> Architects,

Oh I see, on c.l.j.gui it was 'folks' but
here it is 'architects' is it?

Please do not multi-post Vijay,
you are not _that_ important.
Take my word for it.

java-programmer >> Designing presentation-tier for occasionally connected applications. Vijay Kumar wrote:
>
> Architects,
>
> We are in the process of developing a web-based app that needs to be
> functional when the user is on the road where the Internet connection
> to the server is not available. There are 3 basic requirements:
>
> 1. Must be web-based, not a fat client app.
> 2. The UI for the offline mode and on-line should be identical.
> 3. In the off-line mode some basic functionality to enter data (fill
> forms) should be available, that do not need to be reentered when the
> connectivity is available.
>
> Can some one think of a solution on how one would design this app. To
> me disconnect from the network mean no web application, but some one
> here insisted that we can put a web-server/appserver on each client
> machine (about 200 of these).
>
> Swing based solutions are ruled out because that is not a web-based
> architecture.

1: If the application must be web-based and must operate
when the system is not connected to the web, the system
must include its own web server. That much seems clear.

2: If the on-line and off-line UIs are to be identical
(except for some missing functionality when off-line), the
most straightforward approach is to use the same browser
and the same client-side applets (or other gadgetry) in
both modes. The only difference would be in which web
server one connects to: the real on-line server, or the
substitute localhost server.

3: This requires a little more work. You don't say what
sort of work the application does, but it seems that the off-
line localhost web server must be able to store user input
somewhere (no problem) and then to transmit that input to the
on-line server when it becomes available. One way to do this
would be to write a web client that would "replay" the off-line
data to the on-line server, possibly after the user first goes
through a login sequence of some kind. Another way might be to
use a different channel altogether -- for example, you might
"store" the off-line work as a bunch of E-mail messages to an
address on the server machine, essentially letting the E-mail
client take care of the data synchronization task.

Finally, you're quite right that Swing is not a web-based
architecture. But Unicode is also not web-based, pixels on
the screen are not web-based, the local file system is not
web-based, and my grandmother's fruitcake is not web-based.
Swing is a set of classes to help you implement GUIs; it makes
no difference whether the GUIs have or do not have any web
association. Swing-ness and Web-ness are orthogonal, so
what's the objection?

--
email***@***.com

java-programmer >> Designing presentation-tier for occasionally connected applications. On 4 Feb 2004 09:44:56 -0800, email***@***.com (Vijay Kumar)
wrote:

>Architects,
>
>We are in the process of developing a web-based app that needs to be
>functional when the user is on the road where the Internet connection
>to the server is not available. There are 3 basic requirements:
>
>1. Must be web-based, not a fat client app.
>2. The UI for the offline mode and on-line should be identical.
>3. In the off-line mode some basic functionality to enter data (fill
>forms) should be available, that do not need to be reentered when the
>connectivity is available.

>Can some one think of a solution on how one would design this app. To
>me disconnect from the network mean no web application, but some one
>here insisted that we can put a web-server/appserver on each client
>machine (about 200 of these).

No wonder they insisted :-) If you are on the road, how do yo expect
to run a web-aplication without a web server?

It's really pretty simple:

Put a web server on every laptop. Have a single web application that
should :
1. handle UI (presentation layer)
2. be aware of connection status
5. support routing of online operations if connection is available
3. support offline operations
4. support data synchronization on connection

Then put any other business logic (i.e., "online" operations) and
legacy database on the main server on the network.

>Swing based solutions are ruled out because that is not a web-based
>architecture.

JApplet is pretty Swing based and pretty web-based ;-) But ... weren't
you asking about design?

You could implement this same "design" with anythig from JApplets,
satndalone Swing, JSP, on the laptop, to Servlets, EJB or RMI, both
on the laptop and on the main server, just to name a few. The only
limitations come, I'm afraid, from the requirement for the UI to be a
web app.

regards
zn魊t

java-programmer >> Designing presentation-tier for occasionally connected applications. Am Wed, 04 Feb 2004 09:43:42 -0800 schrieb Vijay Kumar:

> Folks
>
> We are in the process of developing a web-based app that needs to be
> functional when the user is on the road where the Internet connection
> to the server is not available. There are 3 basic requirements:
>
> 1. Must be web-based, not a fat client app.
> 2. The UI for the offline mode and on-line should be identical.
> 3. In the off-line mode some basic functionality to enter data (fill
> forms) should be available, that do not need to be reentered when the
> connectivity is available.
>

I just started something like this for timereporting. The solution for us
is a webstart application which will synchronize project description and
entered time data if the server is available. But this is of course more
or less a fat client app. Installing a simple http server will give you
IHMO the same, only with additional headache of a splitted client app
(server + browser).

Bye, Carsten

java-programmer >> Designing presentation-tier for occasionally connected applications. Vijay Kumar wrote:
> We are in the process of developing a web-based app that needs to be
> functional when the user is on the road where the Internet connection
> to the server is not available.

Well, this is a contradiction. Without a web server anything beyond
simple file viewing will become difficult or impossible when just using
a browser. In fact, since the web server is responsible for delivering
the web-based application to the thin-client, there is nothing left that
can deliver the application.

> 1. Must be web-based, not a fat client app.
> 2. The UI for the offline mode and on-line should be identical.
> 3. In the off-line mode some basic functionality to enter data (fill
> forms) should be available, that do not need to be reentered when the
> connectivity is available.

No server, no form processing. You either throw in some local web
server, you give them a real application or a local applet, hack tons of
JavaScrip (this is a Java, not a JavaScript group :-)) or you just give
them a text editor :-). In any case, you will not have a thin client. Or
at least not a thin client without some additional fat pieces of
software on the same machine.

> Can some one think of a solution on how one would design this app.

In a totally different way. Instead of first selecting the technology
(web-based thin-cilent), and then trying to work around the limitations,
I would start with some real requirements, and then select a matching
technology.

[Note: What you call requirements are not requirements, but technically
constraints. A requirement defines what should happen, a constraint
defines how it should happen (e.g. choice of technology). A constraint
reduces a developer's ability to find a solution for the problem at
hand, while at the same time it takes the responsibility out of the
hands of the developer. The one insiting on the constraint (the choice
of technology) is responsible now. There is nothing wrong with
constraints in a software project. You usually have a lot of them. But
when they reduce your alternatives to close to zero, you should get rid
of them, and do a fresh start.]

> To
> me disconnect from the network mean no web application, but some one
> here insisted that we can put a web-server/appserver on each client
> machine (about 200 of these).

Sure you can. I would hesitate to call that a thin client, but hey it is
your software. If you do so, your problem will be deployment. Exactly
the problem people try to avoid when going for a web-based thin-client
solution. Since this is a Java group, you could think about using Java
web start for software distribution and updates.

> Swing based solutions are ruled out because that is not a web-based
> architecture.

"Web-based architecture" is a buzzword and meaningless here. Swing is a
GUI toolkit. If you have a decent Java version in your browser (usually
using a plug-in), you can of course have Java Applets who use Swing. If
that qualifies as "web-based architecture" or not is up to you.

/Thomas