Server TF Survey

From MemberWiki

Jump to: navigation, search

Contents

IT Mill Toolkit

Source: Joonas Lehtinen, ...(please edit background accordingly)

IT Mill Toolkit is an upcoming commercial server-side AJAX framework that is based on Millstone UI Library, which has been in production use since 2001. Here is a quick description of it's predecessor Millstone AJAX Adapter.

Goals

  • Allow creation of user interface in plain Java
  • Hide all the complexity from programmer, but allows accessing all details, if needed
  • Stable API that supports different rendering models ("traditional" HTML, AJAX, Swing, ...)
  • Full separation of UI look and feel from user interface logic (and programming)

Architecture

Image:Millstone-Ajax-Adapter-structure.gif

UI Components

UI components are java objects that contain the logical state of user interface and which are stored in http session. Each component can receive state change requests, bind to external data sources, send events to listeners and render its current visible state. The rendering is done in user interface description language (UIDL) that is an terminal agnostic XML-based description of the logical visible UI state.

AJAX Adapter

AJAX adapter listens to events initiated by the user as well as changes in (server side) UI components. Whenever it receives events from user, it passes them to correct (server side) UI components and then submits new state of the changed UI components back to user (web browser). The changes are coded in UIDL that can include just one particular component or all the currently visible components.

AJAX Client

AJAX client acts as communication hub between AJAX Adapter and Web-page. It listens to DOM events and sends them to server and passes parts of received UIDL to component renderers implemented by the theme.

Theme

Theme is a set of component renderes implemented in JavaScript. They create HTML-DOM element from UIDL-DOM received from AJAX Client as well as register DOM event listeners. Multiple themes can be registered simultaneously to extend or override component implementations in the "default" theme implementation. It is also possible to use multiple component styles for each component (for example have DateField render as calendar or text input box).

IT Mill Toolkit: Demo and more details

For more info, contact joonas.lehtinen@itmill.com phone: +358 40 5035001

ICEfaces

Source: Ted Goddard ...(please edit background accordingly)

ICEfaces is a set of extensions for JSF providing Ajax Push functionality to standard JSF applications. ICEfaces includes a set of components for building rich web applications (Autocomplete, Drag and Drop, Tree, Calendar, etc.) as well as an enterprise server for highly scalable push deployments.

ICEfaces is open source under the Mozilla Public License and is available from http://www.icefaces.org

Architecture

ICEfaces provides a JSF RenderKit that allows the standard JSF components to be rendered to a Document Object Model (DOM) on the server. Render passes can occur in response to user events (as is typical with Web Applications) or in response to application-level events (as provided in support of Ajax Push). In either case, changes to the server side DOM are detected and the incremental changes are applied to the browser-side DOM.

To support Ajax Push, the browser makes repeated blocking HTTP requests to the server via XMLHttpRequest. When the server has DOM updates available it replies to the currently pending request (this message pattern is also used in COMET and Reverse Ajax).

ICEfaces System Architecture

Integration With 3rd Party Components

ICEfaces is a framework for building Ajax web pages with JSF components (and it includes a number of components that make use of this framework). By managing the page holistically, "interaction silos" are eliminated (often when multiple Ajax components are on a single page, interaction with and update of one component does not update the other components). Since ICEfaces takes the output from the entire JSF render pass and determines the necessary incremental update, any component can update the page as a result of the user interacting with any other component.

Therefore, to take full benefit of ICEfaces, it is desirable that 3rd party components make use of page-level incremental update. In the simplest case this is a matter of:

  • use startElement() and endElement() in the JSF ResponseWriter
  • store component state in form fields and defer to ICEfaces form submission

In other words, standard JSF components are automatically Ajax-enabled by the architecture. When individual components contain their own Ajax functionality, the interaction is more complex. For instance, because ICEfaces makes use of Ajax Push, 3rd-party components within the same page cannot also make use of Ajax Push due to browser connection limits (this is a general problem with the co-existence of Ajax Push components, it is not unique to ICEfaces). This can be resolved with a shared communication hub.

Ajax Components & Server-Side Framework at ILOG

Source: Christophe Jolif ...(please edit accordingly)

ILOG provides advanced visualization components (Gantt, Diagrams...) entirely based on standart server-side frameworks such as JavaServer Faces (JSF) or ASP.NET.

JSF

For JSF components we actually integrates Ajax features using two different techniques depending on the component, the rendering technology (DHTML or SVG) and other requirements.

The Ajax PhaseListener technique

When the client-side JavaScript component wants to issue an Ajax request to the server-side component, it takes the JSF form and submit it to the server using XmlHttpRequest and adding a parameter to the request to tag it as an Ajax request (like &ajax=true).

On the server, a PhaseListener is registered on the lifecycle. It catches the Ajax requests (the one with the ajax parameter) after any JSF actions has been executed on the JSF tree (INVOKE_APPLICATION phase), and then cut the lifecycle and render the Ajax response.

Advantages:

  • Do not require an additional Servlet in addition to the FacesServlet
  • Easy access to the JSF context & component tree
  • Automatic execution of JSF actions

Disavantages:

  • As the Ajax request is a Faces request, it will be catched by the portlet container if running in portlet mode, and the whole portal page will be re-rendered in the stream which means the client will not just receive the Ajax response but a lot of other stuff to strip down on the client.

The Ajax Servlet technique

When the client-side JavaScript component wants to issue an Ajax request to the server-side components, it calls an additional Servlet.

On the server, the additional Servlet is getting the request, his doing the actions asked by the Ajax request and sending back the Ajax response to the client. In order to get the needed information for the actions to be executed, some informations need to be shared in the HTTP session bewteen the FacesServlet and the Ajax Servlet.

Advantages:

  • Correct behavior in portlet mode

Disavantages:

  • Requires tricks to access the JSF context, requires sharing stuff in the HTTP session.


Chapter 11 of JavaServer Faces the Complete Reference

Source: Chris Schalk, Server TF Chair, JSF Book Author, Oracle Server Product Mgmt

JavaServer Faces: The Complete Reference (McGraw-Hill-Osborne) contains chapters focusing on development of custom JSF UI components. Chapter 10 provides a generic coverage of custom UI component development while chapter 11 demonstrates how to create custom AJAX enabled JSF UI components The details specified in the book on how to create AJAX JSF UI components are fairly straight forward. The approach used is primarily to use renderer code to emit AJAX JavaScript at runtime.

The details on the various approaches to rendering AJAX JavaScript presented in the book follows.

Architecture

The architecture presented in the book for creating AJAX enabled custom components is fairly straight-forward. It presents the task of creating AJAX enabled JSF UI components in the following manner: A first "AJAX only" example, referred to as DirectorySearch, is shown which consists of an HTML page with Ajax enabled JavaScript which communicates asynchronously with a backend server object using XMLHttpRequest in response to user supplied changes to the UI - such as entering text etc..

This architecture is as simple as: Basic AJAX-Only Architecture


In this simple "DirectorySearch" example, when a user enters text into a input field, JavaScript code on the client interacts with the server object (such as a Servlet) which then provides a stream of matching data corresponding to the entered text. This response stream is delivered in XML and is handled by the client which then manipulates its UI based on the data in the response.

DirectorySearch Example usage


However the chapter goes on to describe the merits of a component based architecture where the complexities of AJAX JavaScript can be encapsulated into server-side components - such as JSF UI Components thus shielding the web page author from having to do JavaScript development.

When AJAX JavaScript is instead provided by the component without encumbering the page author, it simplifies development greatly so the page author can strictly deal with JSF components instead of the underlying AJAX JavaScript. The book returns to the DirectorySearch example but then shows a JSF UI component version of it where the AJAX JavaScript code that was originally in the client HTML page, is now encapsulated into the JSF UI component. The book explains how to do this using JSF's UI component rendering capabilities which can output markup of any kind. The book then explain that the AJAX Server object can still remain independent such as the servlet used earlier, or the AJAX server object can be integrated into the JSF application and/or a specific JSF UI Component.

The following figure shows how AJAX can be integrated into a JSF UI component.

AJAX integrated into JSF Component

As you can see the AJAX Server Object (the listening agent which responds to AJAX requests) can either remain independent of the JSF application (such as with the servlet) or it can be integrated into the JSF application. When the AJAX server object, is integrated into the JSF application, it can be written as either:

  • Phaselistener - This has the advantage of being executed from with the JSF context and has easy access to the JSF application's data.
  • Decode method (of the component itself) - This can be used when you need specific AJAX responses on a component by component basis.

The book is agnostic about which approach is used in the end as each development project may have their own more specific criterias.

The book also explains various strategies for rendering JavaScript dynamically to the client. For example there are times when simply a static JavaScript library reference is all that is needed to be rendered to the client such as: <script src="http://yourSite/yourJavaScript.js" type="text/javascript"></script>

This can easily be rendered by the component, however you'll only want the component to render it once, so a method of keeping track of this is shown.

In contrast to just rendering per page static JavaScript library references, there are times when you may wish to render portions of JavaScript code dynamically into the body of the HTML client on a per component basis. This is sometimes needed when each usage instance requires a bit a custom coded JavaScript. Such as to call functions provided in the static JavaScript library but with different arguments which are passed on from the JSF UI component. Techniques for rendering per component usage JavaScript using JSF's rendering technology are shown as well.

In summary, JSF: The Complete Reference merely presents the various challenges and possible solutions to dealing with AJAX when using JSF UI component technology as there is no definitive best practice as yet to do this.

jMaki AJAX Technology (Initial placeholder)

Source: Greg Murray ...

jMaki is an Ajax framework that provides a lightweight model for reusable Ajax-enabled widgets of your own design or for those extending existing toolkits such as the Dojo toolkit. jMaki facilitates the passing parameters to your widgets and provides the means to better connect your widgets to your server-side resourcess using XML or JSON. Currently the jMaki server-side runtime is provided as a JSP tag library or a JSF component.

See:

https://ajax.dev.java.net/about.html

Presentation:

https://ajax.dev.java.net/presentations/jmaki.pdf

About JMaki:

https://ajax.dev.java.net/about.html

Architecture

TBD Further architectural details can be found at: https://ajax.dev.java.net/servlets/ProjectHome

Greg Murray to hopefully provide some more custom details on architecure...



ASP.NET

To be completed