Hello Mike,

Thank you for the compliments.

From a system-architecture point of view, Lightstreamer Server sits along with any Web Server in the DMZ:


The Web Server will serve all the pages and resources of the Web application (html, JS, css, images, etc.). The Web application can be based on any framework, toolkit or paradigm, with no constraints. For example, the Web Server could leverage a J2EE Application Server (usually beyond the second firewall) to have the HTML generated through JSP, servlets, Struts and JSF. Such HTML will include the Lightstreamer JavaScript libraries to make the pages live on the client side. This means that the integration of Lightstreamer JS libs is independent on the kind of server-side framework used to generate the pages.

The role of Lightstreamer Server is to deliver the real-time updates to the browser (though the provided JS libraries).

Lightstreamer Server needs to connect to both a data feed (to get the real-time data) and to some authentication(authorization system (to handle permissionig, entitlement, etc.). This is accomplished through custom Data and Metadata Adapters that are plugged into Lightstreamer Server. So, if the data feed and authorization logic resides in the J2EE App Server, then the Lightstreamer Adapter will be developed in order to access the App Server. This is a custom development done by the system integrator so any kind of middleware or protocol can be used to connect LS Server with the App Server. Often JMS is employed for the Data Adapter. EJB, Web Services, DB queries are frequent options for the Metadata Adapter.