|
|
EventWeb allows a user to interact with a web application in the same way as a desktop application.
The key enabler for this is the creation of a bi-directional TCP/IP connection between the browser and the web server. This allows an event on the web server, such as a change in data, to cause new data to be pushed to the web page in the browser. It also allows the browser to send new data to the server in response to user actions, (which in turn can trigger a response from the server).
The channel connects a servlet running in an application server to JavaScript code running in the corresponding web page. There is a server side framework to facilitate the creation of live data enabled services. There is also a stand-alone server that allows services to be hosted without an existing application or http server.
Since the JavaScript has full access to the document in the browser, virtually any kind of dynamic behavior can be orchestrated.
EventWeb has a small footprint with regard to both system resources and network bandwidth. The only client side requirement is a browser with support for Java applets and JavaScript. No plug-in or other special features are required.
The primary goal of EventWeb is to allow a web application to provide the same user interaction as a desktop application. Additional goals are:
Basically, Because you want to update the web client when server side events occur. If you don't need to do this, you probably don't want EventWeb.
There are a number of approaches to pushing data from the server to a web page. All of them have disadvantages. Some use proprietary software; Some use polling across the network, and some use standard protocols in a quirky way.
EventWeb solves this problem in a clean and stable way, with very low network bandwidth consumption, low data latencies, open source software, and stable, reliable communications.
But, like everything else, it has it's drawbacks. Earlier versions of EventWeb had two main drawbacks: 1) It used a Java applet. This difficulty is mitigated because all EventWeb pages use the same applet class, and once the browser has the applet cached, it doesn't need to download it again. 2) It used dynamic TCP ports, which may cause problems with some firewalls. (The RangePortSrvrChan included with this release provides control over the range of ports that are used.)
EventWeb 0.7 uses WebSockets for the communication channel, eliminating those drawbacks. The main drawback now is that you can create the same kind of application with a J2EE server. However, EventWeb gives you a framework you can drop your application code into. With J2EE you have a more complex environment and you don't have a pre-built framework.
|
|