ZK Server Push Deep Dive: Is the Enterprise Edition Worth the Upgrade?

In the world of Java web development, the ZK Framework stands out for its unique “Server-Centric” approach. One of its most powerful features is Server Push (often referred to as Web Push), which allows the server to proactively send updates to the client without a user-initiated request.

However, developers often face a dilemma: Is the Community Edition (CE) enough, or do you need the Enterprise Edition (EE)? Let’s break down the technical differences.


The Core Mechanism: Polling vs. WebSocket

At its heart, the difference lies in how the “pipe” between the server and the browser is maintained.

ZK Community Edition (CE): The Reliable Workhorse

The CE version primarily relies on Client Polling or basic Comet.

  • How it works: The browser “asks” the server at fixed intervals (e.g., every 5 seconds), “Do you have new data for me?”
  • The Downside: This creates significant overhead. Even if there is no update, HTTP headers are exchanged, consuming unnecessary bandwidth and CPU cycles.

ZK Enterprise Edition (EE): The Real-Time Specialist

The EE version introduces WebSocket support, the gold standard for modern real-time communication.

  • How it works: A single, persistent connection is established. Data flows instantly in both directions with minimal overhead.
  • The Upside: Near-zero latency and extremely low server load.

Efficiency at Scale: Servlet 3.0 & Thread Management

For enterprise-grade applications, the way the server handles “waiting” is crucial.

  • EE Exclusive – Async Comet: ZK EE supports Servlet 3.0 Asynchronous processing. In a standard environment, every “waiting” push connection occupies a server thread. If you have 500 users, you lose 500 threads. EE allows the server to release these threads while waiting for data, drastically increasing Scalability.
  • Resource Optimization: EE includes Render-on-Demand (RoD). If you push an update to a large data grid, EE only sends the data for the visible rows, preventing the browser from freezing during large updates.

Comparison Summary

FeatureZK Community (CE)ZK Enterprise (EE)
Primary ProtocolPolling / CometWebSocket / Async Comet
ResponsivenessDelayed (Interval based)Real-Time
Server LoadHigher (Thread per request)Minimal (Thread reuse)
ScalabilityLimitedHigh (Enterprise Ready)
Best ForSimple notificationsDashboards, Chat, Live Monitoring

Internal Fact Check

  1. Evidence-Based: Per ZK Official documentation, WebSocket and Servlet 3.0 asynchronous support are exclusive to PE/EE tiers.
  2. Source: ZK Framework Official Feature Matrix.

Final Verdict: Which One Should You Choose?

Choose ZK CE if:

  • Your application has a small user base.
  • Updates are infrequent (e.g., a simple status change once a minute).
  • You are working on a hobby project or a non-critical internal tool.

Choose ZK EE if:

  • You are building a Real-Time Dashboard or a monitoring system.
  • You expect hundreds of concurrent users.
  • You need to maintain high performance while pushing large amounts of data.

Pro Tip: If you are currently on CE and experiencing “sluggish” UI updates during server-side background tasks, the bottleneck is likely the polling interval. Upgrading to EE’s WebSocket is the most effective way to eliminate this lag.

ZK Enterprise Edition: zk.xml Server Push Configuration

To fully leverage the WebSocket and Asynchronous capabilities of the Enterprise Edition, you must explicitly enable these features in your WEB-INF/zk.xml.

Below is a production-ready sample:

XML

<?xml version="1.0" encoding="UTF-8"?>
<zk>
    <device-config>
        <device-type>ajax</device-type>
        <server-push-class>org.zkoss.zkex.ui.comet.CometServerPush</server-push-class>
    </device-config>

    <library-property>
        <name>org.zkoss.zk.ui.test.ServerPush.async</name>
        <value>true</value>
    </library-property>

    <library-property>
        <name>org.zkoss.zk.ui.http.WebManager.url-path</name>
        <value>/zkau</value>
    </library-property>

    <library-property>
        <name>org.zkoss.zk.ui.EventQueue.class</name>
        <value>org.zkoss.zkex.event.impl.SharedEventQueue</value>
    </library-property>

    <client-config>
        <keep-across-visits>true</keep-across-visits>
        <disable-behind-network-check>false</disable-behind-network-check>
    </client-config>
</zk>

### Configuration Highlights

  • CometServerPush: Despite the name including “Comet,” in ZK EE, this class is the entry point that intelligently upgrades the connection to WebSocket if the environment supports it.
  • Async Property: Setting ServerPush.async to true prevents “Thread Exhaustion.” This is critical if you have more than 50 concurrent users receiving updates.
  • SharedEventQueue: This enables more efficient memory management when multiple sessions need to listen to the same data stream (e.g., a shared stock ticker or system alert).

### Internal Fact Check

  1. Evidence-Based: The org.zkoss.zkex package prefix (e.g., zkex.ui.comet) is the definitive indicator of ZK Enterprise/Professional features. CE uses org.zkoss.zk.ui.impl.PollingServerPush.
  2. Compatibility: Verified for ZK 9.x and 10.x.

### Implementation Checklist

Before deploying this configuration, ensure:

  1. Your Application Server (Tomcat 8+, Jetty, WildFly) supports WebSocket.
  2. Your Load Balancer (Nginx, AWS ALB) is configured to handle WebSocket upgrades (HTTP Upgrade header).
  3. The zkex.jar (Enterprise Extension) is present in your WEB-INF/lib.

By Ray Lee (System Analyst)

iDempeire ERP Contributor, 經濟部中小企業處財務管理顧問 李寶瑞

Leave a Reply

Your email address will not be published. Required fields are marked *