Yes, but not directly from WebObjects [sort of]. For server push to work,
the WebServer must generally maintain a persistent connection to the
client. In this scenario, you would probably want to create a simple
server push mechanism on the server that simply fires an URL through the
server (usually can be done without having to form an external TCP/IP
connection) and then push the results to the client.
Alternatively, you could have the clients connect directly to the WOApp
instances by having them connect to a certain port on the server machine
and have the WOApps listen on that port. The WOApps could then push the
content as needed. This would be a direct to WebObjects connection and
would eliminate the WebServer as a go between.
However, server push generally sucks for a number of reasons.
(1) it requires a persistent TCP/IP connection per client because you
cannot reliably connect from the server to a client due to proxy and
firewall issues. Most servers really don't deal well with thousands or
tens of thousands open TCP/IP connections.
(2) in the web world, it is extremely common for client/server connections
to be torn down in a very unfriendly to the server manner. I.e. the
client simply closes the connection in mid stream without notifying the
server. Generally, the server must enter some kind of a wait state on
that particular connection until a timeout occurs. This tends to be
resource intensive and requires lots of careful design to work around.
On solaris (2.5.... sun claims it was fixed in 2.6, but the network
community disagrees and says the problem was merely reduced), there is a
small chance that the process maintaining the connection will spin-lock.
That is, it will use 100% of the CPU blocking on a system call that was
attempting to manipulate the connection. This is the reason why the
Apache/NCSA source and just about every nntpd source forks a group of
child servers that do the work while the parent monitors the children and
kills off any that become unresponsive (use the source, luke:-).
If you have a look at the archives for this mailing list, there were some
rather detailed discussions of server push and real time client updating
in the 1997 timeframe.
Since it appears that you are doing some fairly intense research, I'd
suggest downloading the 1997 and 1998 mailboxes and having a scan through
'em. While a lot of the material will be obsolete with the release of
WebObjects 4.0 (take any "limitation of WebObjects" type message with a
serious grain of salt-- Apple did a great job of listening to the customer
base and eliminating various problems that were perceived as being
limitations of WO. The 4.0 release is a truly major step forward.), there
are lots of generic discussions about the limitations of HTML, HTTP, and
web related technologies that are highly pertinent.
In general, WebObjects can be made to do anything web related and it can
be done faster and easier than any of the competitors we have tested so
far (we are always evaluating other packages).
The real problem is that the Web is a really bad system for deploying
applications. Sure, the protocol itself is convenient-- but that is the
only "nice" aspect of it when building interactive applications to be
deployed on the net. Now that there have been billiions of dollars
invested in firewalls, proxies and other web specific technologies, there
really isn't an alternative to HTTP for deploying applications on the
Internet.
Unfortunately:
- you never know when the client has quit or disconnected
- (see above) a user interface must be entirely based on passive
acknowledgement... active acknowledgement requires technology that isn't
ready for prime time (see below)
- Java isn't ready yet. Try building a complex app that:
- works on all browsers
- isn't slow
- doesn't take forever to download to clients on slow connections
Java is now to the point where two of the three of these are feasible...
but until all three can be done, you either have to limit the client base,
tell everyone to get monstrously fast computers (which still may not solve
the problem if you have to push lots of data back and forth), or tell the
user to go get a cup of coffee and lunch while the app downloads.
- The web is not designed for persistent connections. The clients really
want to be passive/pull. Moving away from that causes problems. Remember
when Wired magazine invested loads of money in Push and said it would kill
the web as we know it (which was about the time I stopped reading wired--
it was clear they turned themsleves into a marketing magazine for their
own technologies)? It never happened and it wasn't entirely because the
user base wasn't interested in having commercials pushed at 'em-- the web
does not like that kind of technology.
- The web was designed to be inherently stateless... As such, any state
you wish to maintain you have to do so yourself. Now, packages like
WebObjects do a brilliant job of maintaining per-user state in a passive
manner... but the interface to that state is still traditional, passive,
HTTP connections. Moving away from that causes problems.
b.bum
On Thu, 25 Feb 1999, Robert Fischer wrote:
> Hi,
>
> it's me, once more.
>
> Is it possible to trigger a server push without a java client, i.e. can I push a
> response to the user without getting a request before?
>
>
> Thanks in advance,
>
> Robert
>
> --
> --- - .-. -- --
> --- / \ ---- Robert Fischer
> .-. / \ --- .-. __o .-. @
> / \ / \ / \ _`\<,_ / \ GMD-Fokus
> / \ / \ / \ (*)/ (*) / `--------------
> / `---' `-' `-----------'
>
>
