Skip to main content

Rich Server Platform - User Interface

Proposal for

Rich Server Platform – User Interface Framework (RSP-UI)

This document declares the intent, benefits and scope of a proposed project called "Rich Server Platform – User Interface Framework" (RSP-UI). RSP-UI is in the Project Proposal Phase as defined in the Eclipse Development Process document. We propose that this project be established within the Technology Project PMC.

Current status: We are currently working on the creation review slides. Development is ongoing. New committers have recently joined the project for a PDE Launcher and a "web.xml" extension point.

In particular, we are soliciting participation and input from the Eclipse community beyond those who already support this project proposal (see Organization). The more input RSP-UI receives from you, the more cross-integration it can provide. You are invited to comment on the project and strongly encouraged to join. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology newsgroup, "RSP-UI Proposal Discussion Thread" (web access at http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology).

Introduction

Eclipse Rich Client Platform (Eclipse RCP) has been successfully established as an application platform for the client-side. With the recent acceptance of large parts of the OSGi specification as a JSR (291), widespread application of OSGi for server-side applications has become natural.

Recently, the Equinox Incubator has begun applying the Eclipse/OSGi concepts to the server-side. This opens tremendous new possibilities for Eclipse as an application platform for the server-side (refer to http://www.infonoia.com/en/content.jsp?d=inf.05.07) for a discussion of possibilities.

The Eclipse/OSGi development model, applied to the server-side, allows the creation of truly pluggable, componentized, server-side applications. Plug-ins can communicate at a logic layer with each other using established and tested methods, such as extension points and OSGi services.

What is needed for the UI layer is a UI composition framework which we propose in the form of RSP-UI.

Executive Summary

1. What: UI framework to compose integrated server-side applications Eclipse/OSGi-style, thereby enhancing developer productivity

2. Allow sets of rendering technologies to be combined for versatile applications

3. Augment the Eclipse community by bridging client- and server-side assets

This document proposes a Rich Server Platform – User Interface Framework (RSP-UI) that will allow you to compose integrated server-side applications Eclipse/OSGi-style.

RSP-UI follows a highly integrating approach:

First, RSP-UI will allow you to freely combine the most suitable rendering technologies for versatile web applications. Ideally, a web application based on RSP-UI should be able to serve the user with a page that combines content from, for example, a plug-in with XML/XSL transformation to display an RSS news feed, a plug-in that uses PHP to render content, another plug-in that uses JSF for rich interactive web components, and a plug-in that renders LZX/Laszlo for interactive components with highest layout requirements.

Second, RSP-UI will lower your entry barrier to the respective advantages of the client- and the server-side world, thereby augmenting the Eclipse community.

Furthermore, using RSP-UI, you will increase code reuse, enjoy a flexible and lean assembly of just the components and services you need, and enhance your productivity in composing a versatile web application. RSP-UI adresses core needs in the area of "service-oriented clients", where this architecture allows developers to build better applications that are more targeted to user needs, tasks, roles and workflows.

You find a demo walkthrough with sample code of a basic server-side application at http://www.infonoia.com/en/content.jsp?d=inf.05.09. It uses jsp:include tags as the lowest degree of UI composition.

Issues, solution and benefits

Current Issues

Our solution

Your benefits

1. Code reuse between client-side and server-side is limited

Server-side UI framework that renders "dual" components

You will increase code reuse

2. Modularizing server-side applications is difficult

Apply Eclipse/OSGi bundle paradigm to the server-side

You will enjoy a flexible and lean assembly of just the components and services you need

3. Integrating UI from sets of rendering technologies is cumbersome

Define (best practices) for UI interactions and composition

You will enhance developer productivity

4. Server-side world offers a large choice of rendering technologies, but no single best answer as to which set to use for web UI

Offer a large choice of rendering technologies to pick and choose from

You will meet the diverse and special requirements of your application efficiently

5. Client-side and server-side have developed in separate worlds

Leverage familiar RCP paradigms and established web technologies

You will enjoy facilitated entry to the advantages of "the other" world

1. Code reuse between client-side and server-side is limited – Many business-critical applications have both a heavy data-entry element for internal use (rich client) and a general-public web interface. Usually, the UI of these will not be the same, however, good parts of the business logic will be. By applying OSGi to the server-side, RSP-UI will provide you with a web UI framework that allows you to reuse a lot of the business logic (non-UI plug-ins) for both parts of an application. With RSP-UI, you will be able to reuse "dual" components that can be rendered both in a browser and in a rich client.

2. Modularizing server-side applications is difficult – Many web applications have numerous functional modules, such as shopping cart, news feed, or user management. This compares to RCP applications where the Eclipse IDE is also composed of numerous plug-ins. However, the WAR (Web Archive) as the smallest deployment unit of aggregation in J2EE web applications is too coarse grained to allow practical reuse of application "modules". It is not practical to package each module into its own WAR for numerous reasons, including the fact that inter-WAR dependencies are not defined. However, maintaining multiple modules inside a single WAR, with code, and URL resources usually residing in different places, does not provide the degree of isolation that makes such modules easily transferable and reusable in other projects. RSP-UI will apply the OSGi bundle paradigm to the server-side. So you will enjoy a flexible and lean assembly of just the components and services you need to compose your application.

3. Integrating UI from sets of rendering technologies is cumbersome – Eclipse/OSGi allows inter-plug-in communication at the logic level via extension points and OSGi services. Beyond the OSGi http-service as transport for http resources, however, interactions at web UI level are not defined today, making it cumbersome to "glue components together" at the UI level. RSP-UI will focus on the definition of UI interactions and UI composition in order to create a framework for easily integrating UI from sets of rendering technologies and frameworks already established in the server-side world. With RSP-UI, you will enhance developer productivity

4. The server-side world offers a large choice of rendering technologies, while there is no single best answer as to which set to use for web UI – The choice will vary with project requirements and developer skills, and may well incorporate multiple approaches. Ideally, a truly componentized web application is able to integrate and display content from plug-ins that use classic web technologies such as, but not limited to, JSP/JSTL, framework Struts/WebWork framework, Wicket, JSF/Facelets and other applicable widget libraries, Spring and PHP. It should also be able to integrate components that use rich rendering technologies such as LZX/Laszlo.

A truly componentized web application should be able to serve the user with a page that combines content from, for example, a plug-in with XML/XSL transformation to display an RSS news feed, a plug-in that uses PHP to render content, another plug-in that uses JSF for rich interactive web components, and a plug-in that renders LZX/Laszlo for interactive components with highest layout requirements. RSP-UI will help you to meet the diverse and special requirements of your application efficiently (and on a macro level serve the "long tail", Carl Zetie, Forrester Research).

5. Client-side and server-side have developed in separate worlds – RSP-UI lowers entry barriers for RCP developers to the advantages of server-side programming by using familiar paradigms such as extension points, services, and workbench API. RCP developers can thus benefit from the advantages of server-side programming but don't need to learn the complete J2EE toolsets. On the other hand, as RSP-UI offers integration facilities with established web frameworks and rendering technologies, web developers can leverage their experience with server-side applications and thus efficiently develop rich server-side applications. RSP-UI will facilitate your entry to the advantages of "the other world" and thereby augment the Eclipse community.

Scope

1. Define composition framework with API and sample implementations

2. Provide services commonly needed for web applications

3. Address needs ranging from dynamic websites to "single-url" web applications

1. Define UI composition framework with API and sample implementations

Making plug-ins run on a server involves the whole application stack; RSP-UI makes no attempt to cover the whole territory. Instead, it narrowly focuses on defining interfaces and creating sample implementations for UI integration and associated components.

The RCP workbench API will be analyzed and used as the most structured, Java-based API for composing web UI, and leveraged by templating and decoration. We also envisage markup-based composition using a tag library that can be used from JSPs.

Essentially, the same basic abstractions of Eclipse UI will be used. Therefore, PageLayouts will be defined by a combination of Parts. Different part types are EditorPart and ViewPart. Parts will have their trim window built by the workbench framework. This workbench will also provide features to manipulate (maximize, minimize, restore, close, move and dock) views and editors.

A given Part will be associated to ContentProvider. Providers will be the link to different rendering technologies, ranging from script languages such as PHP to fine-grained widgets libraries.

Perspectives are a way to group views for a particular purpose. Plug-ins can define new perspectives or change perspectives defined by other plug-ins. The API used for a plug-in to define a new perspective will be essentially the same as Eclipse’s API. The developer will define an extension to the perspectives extension point and implement the createInitialLayout() method of a new IPerspectiveFactory implementation.

Likewise, the API for defining new views are the same as Eclipse’s (through views extension point).

The RSP-UI composition framework will aim to ensure that individual rendering technologies can access a shared context (such as request, session and application scope for servlets).

The Apache Tiles framework is a very popular server-side UI composition framework. Given its age of about 5 years, Tiles has limitations in its out-of the box capacities to render non-JSP/servlet content. Some limitations are those of the content to be integrated. For example, integration of JSF is difficult given that JSF currently does not support page scope. Tiles does not use the notion of workbench contributions, perspectives, views and the like. We aim to resolve these issues in a "from-the ground-up" construction of an extensible and configurable UI composition framework which leverages the Eclipse/OSGi approaches.

We will design interfaces and sample implementations that allow integrating classic web technologies and frameworks in combined web UI. This will usually require an intricate understanding of the workings of the particular technology and framework implementation. Class-loading approaches of such frameworks that differ from the OSGi model will be investigated and resolved to meet OSGi requirements.

Taking PHP as an example, we plan to take a uniform integration approach for scripting languages, with the aim to allow the use of various scripting languages supported by JSR 223 (Scripting for the Java Platform Specification 1.1), such as, but not limited to, Groovy. Scripting integrations will pass context information through namespaces, as proposed in JSR-223.

2. Provide services commonly needed for web applications

With project members coming from a strong web applications background, part of the project effort will be spent on features and services that developers have been able to rely on in classic J2EE/J2SE web applications, and are useful to be leveraged when writing Eclipse-OSGi server-side applications. These features include, but are not limited to, runtime JSP compilation, user authentication, servlet filters and listeners.

We will also address multiple web-client specific issues, such as client state vs. server state, user session state, "bookmarkable URLs", double-submit, redirect after post, client-side validation, windowing, and converting events from such web UI components into events/commands that can be understood by RSP-UI and relayed to the applicable integrated framework/component. Further integrations with WebWork (Struts 2) and Tapestry are sought.

3. Address needs ranging from dynamic websites to "single-url" web applications

We consider leveraging time-tested principles in established web module “composition” frameworks such as Apache Tiles (Standalone) and SiteMesh to maximize layout design and composition flexibility, and thus facilitate the use of RSP-UI for any kind of dynamic web application, beyond a specific workbench-style application. Note: actual use and integration of Sitemesh would be subject to approval of modified Apache license.

Deliverables

  • Plug-ins that allow composing UI programmatically from multiple plug-ins that use any of the following: JSP/JSTL, Apache Struts, Wicket, JSF/Facelets and other applicable widget libraries, LZX/Laszlo and PHP. A choice of APIs will be proposed, to include workbench-type web applications, the most structured alternative will be closely aligned with the RCP workbench API (perspectives, views, etc.)

  • A tag library plug-in that allows doing the same declaratively

  • Sample "OSGi-fied" implementations of the interfaces (where not delivered by the original creator of the respective framework)

  • UI composition samples covering the technologies/frameworks above

  • Basic build, run and deployment support similar to and based on PDE and PDE Build

  • Basic remote bundle management tool

  • Supporting server OSGi services as needed

  • Documentation of the above

9 committers contribute to these deliverables (see Organization for details).

Relationships with other Eclipse Projects

Ajax Tools Framework – The Eclipse Ajax Tools Framework project focuses on tools to write Ajax applications. Ajax Tools can be used to build components for RSP-UI.

Corona (Tools Services Framework) – The Corona project initiated by Compuware addresses needs for remote components in a Service-Oriented Architecture (SOA) context. It has no server-side UI elements. We have discussed touching points with the Corona architects, and agree that its focus and concerns are orthogonal. However, we have agreed a close collaboration so that both projects may benefit by sharing server-side infrastructure components. Should RSP-UI require remoting capabilities (not seen today), we will attempt to avoid implementations that would conflict with those of Corona.

ECF (Eclipse Communication Framework) – Scott Lewis, ECF project lead, has expressed interest to be a supporter of and possible committer to RSP-UI, through RSP-UI usage and feedback by ECF. ECF is thus a potential consumer of RSP-UI work.

Eclipse PHP-IDE – The Eclipse PHP-IDE project focuses on tools to write PHP applications. PHP-IDE can be used to build PHP components for RSP-UI.

Eclipse Platform – We have engaged in discussions (with D. Pollock and C. Daly) with the intent to use and integrate with the new and evolving Eclipse 3.2 command framework to structure interactions and declaration of interactions with the server, as is being introduced also to trigger commands from the browser-based Eclipse help.

ECP (Enterprise Component Platform) Proposal – ECP has been initiated by Exadel and focuses on a business component framework that uses a JSF implementation for UI, including markup. RSP-UI sees ECP as fully complementary as it nicely fits with its integrating approach. Exadel and RSP-UI have agreed to collaborate to maintain the complementary alignment of both projects. RSP-UI and ECP see each other as integration points.

Equinox Incubator – There is a very close collaboration established with Simon Kaegi, who is a committer on the Equinox server-side incubator. Members of the RSP-UI project consortium have previously tested, validated and provided feedback to Equinox incubator work, notably the servlet bridge. If we happen to create components that the Equinox incubator wishes to use and feels are applicable beyond the scope of the RSP-UI project, we will be most pleased to contribute them to their project.

IDE for Laszlo - We have made contact with the IDE for Laszlo project architect aiming to ensure that LZX/Laszlo components can be rendered within RSP-UI applications. RSP-UI should support logic integration via Laszlo extension points.

OHF (Open Healthcare Framework) – We have discussed collaboration with OHF. OHF has server-side requirements and wishes to be a consumer of RSP-UI work.

RAP (Rich Ajax Platform) Proposal – RAP has been initiated by Innoopract and focuses on a non-JSF widget implementation for UI that emulates SWT/JFace, in a Java-only approach. First, RSP-UI aims to match the Java and web worlds by contributing Java web expertise to the Eclipse community, and second considers RAP to be one of multiple rendering alternatives which would fit with the integrating approach of RSP-UI. RSP-UI can be used for any kind of dynamic web application, beyond RCP workbench-type applications. We had invited RAP to cooperate with RSP-UI, but while discussing cooperation, they chose to independently submit their own proposal. We respect their wish for an independent activity. We have agreed to revisit merging activities in 6 to 9 months.

FAQ

Does RSP-UI depend on JSP or other non-Java technologies?

No. A tag library is part of the deliverables, but UI can be composed through Java code only, in an API that will essentially be the same as the Workbench API. In web applications, some URL resources, such as CSS and JavaScript always use non-Java technologies.

Will my web application that uses RSP-UI have dependencies on JSP-JSTL/Struts/WebWork/Tapestry/Wicket/JSF/Facelets/Spring/PHP?

Not unless you choose so. The RSP-UI project aims to allow you to use the rendering framework(s) of your choice; though you will want to use at least one of them to render content in Views and Editors if you want to run more than simple servlets in your web application.

How does RSP-UI relate to Tiles and SiteMesh?

Apache Tiles (Standalone) allows UI composition of modules via XML templates, while OpenSymphony SiteMesh is strong in combining and decorating arbitrary HTML streams. Both functionalities are very useful in the context of all types of web applications. Therefore, RSP-UI will build on their composition concepts for Eclipse/OSGi-based web applications. Project committer Cedric Dumoulin is the original creator of Tiles.

Will RSP-UI work with Spring?

RSP-UI invites contributions by the Spring community to enable the use of Spring within RSP-UI applications. Work is ongoing in the Spring community to provide use of Spring with OSGi by Spring Release version 3.

Does RSP-UI enable my classic web applications to run in RCP without any changes?

Running of arbitrary web applications within RCP is already supported by the Tomcat plug-in, which is also used by the Eclipse help system. RSP-UI may optionally explore embedding RSP-UI-integrated components as individual UI contributions within RCP applications. This might be done via the RCP Browser widget and a pass-through bridge in an augmented version of the Tomcat plug-in, which accesses the RCP application extension points. WSRP (Web Services for Remote Portlets) concepts would be studied for this. This item is optional since it may be too ambitious for this project.

Will RSP-UI require a J2EE-certified server or a Servlet Engine to run?

No. An initial implementation will use the Equinox ServletBridge which runs in a servlet container as a WAR-style application. This provides for maximum compatibility, as this approach allows adding Eclipse-/OSGi components to existing web applications, without having to migrate the entire web application to Eclipse/OSGi. However, RSP-UI aims to be "server-agnostic"; it should be able to run in any OSGi-compliant environment. Given that an OSGi-"server" can itself be composed with bundles, and OSGi class-loading isolation features ensure that different implementations of services can co-exist in the same OSGi environment, as a general rule, RSP-UI does not depend on particular OSGi container features beyond those specified by applicable OSGi release levels.

Is the mission of RSP-UI to bridge the gap between OSGi and all of JavaEE?

No. However, RSP certainly has the potential to go beyond web applications, and include other parts of JavaEE, such as Enterprise JavaBeans, applying the same benefits to EARs as WARs. RSP-UI is aware of interest in running relevant JavaEE features under OSGi, and time will tell in what form and by whom those interests may be addressed. As more and more of the Java development spectrum (JavaME-to-JavaEE) is brought into the modular, extensible, RCP-style of definition and architecture, the longer Java's lifespan will be. Should any questions of project scope arise during the project, RSP-UI will act in accordance with the Eclipse Development Process.

Will RSP-UI make web development simpler?

We believe so. There is pent-up demand for solutions that are simpler to implement than by playing the full JavaEE orchestra. Wicket is one rendering technology approach that helps for simplicity in UI development. The key theme of RSP-UI is easy composition of smart technologies.

Is RSP-UI too ambitious? It sounds ambitious.

Putting everything imaginable under the heading of RSP into one project would be too ambitious. This is why the RSP-UI project narrowly focuses on UI integrations, and provides a framework, with sample implementations only, whereby ContentProviders can use their technology of choice. It deals with the complexity of the server-side world by providing uniform integration approaches, in hindsight of and knowledge of existing technologies. All project deliverables are assigned to definitive committers.

RSP-UI does not intend to create a server-side component framework beyond what Eclipse/OSGi already provides. Further, RSP-UI applies existing concepts such as workbench API as well as established server-side approaches. The RSP-UI project aims to support a major strengh of the Eclipse platform: its capacity for leveraging cross-technology integration.

Creating a UI composition framework that integrates different URL resources is feasible; RSP-UI committer Cedric Dumoulin has previously done this (Tiles). Running established web frameworks under OSGi is feasible; RSP-UI committers from OPS4J and Infonoia have done this. Composing web UI using Eclipse workbench API paradigms is feasible; RSP-UI committers from Vetta Technologies are doing this. Providing PDE build, run and deployment support is feasible; RSP-UI committer Gunnar Wagenknecht has PDE experience. RSP-UI brings these kinds of expertise together in a multidisciplinary team for a successful project.

To avoid scope creep, we will be very happy to spin off new, independent projects for scoped items that may develop their own dimension, such as, but not limited to, scripting. For example, it may be useful to extend scripting integration to JavaScript, Groovy or Rails runtimes, within another project.

Does RSP-UI dilute Eclipse API?

No. By providing uniform integration approaches, we actually help avoid API dilution. Uniform integration approaches are very important when ContentProviders can use their technology of choice. At the same time, RSP-UI follows the 2006 Eclipse Roadmap, which states that "Support for compiled languages, scripting languages and "Java like" languages such as JSP, SQLJ and the like are all related areas where work needs to be done".

Organization

Project lead

Wolfgang Gehner (Infonoia, Switzerland, wgehner@infonoia.com)

Initial committers

  • Cedric Dumoulin (Université des Sciences et Technologies de Lille, France, original creator of Tiles, co-author of "Struts in Action"): Apache Tiles concepts

  • John R. Fallows (TXE Systems, USA, co-author of "Pro JSF and Ajax"): JSP integrations

  • Wilson Freitas (Vetta Technologies, Brazil): Web workbench and scripting languages (such as PHP) enablement

  • Wolfgang Gehner (Infonoia, Switzerland, co-author of "Struts Best Practices"): Java web applications and frameworks, Struts enablement

  • Ricardo Giacomin (Vetta Technologies, Brazil): Web workbench and PHP enablement

  • Niclas Hedhman (OPS4J, Malaysia, JSR 291 Expert Group member): Wicket enablement, Flash client support & various OSGi support services

  • Makas Lau (OPS4J, Malaysia): Wicket enablement

  • Peter Neubauer (OPS4J, Sweden): Wicket enablement, Remote OSGi management console

  • Gunnar Wagenknecht (Truition, Canada): Basic build, run and deployment support similar to and based on PDE and PDE Build

Code contributions

Project participants will make initial code contributions that will encompass some of the core functionality for RSP-UI:

Infonoia will make an initial code contribution as follows:

  • Integration facilities with the Apache Struts Framework

  • Command-driven program control

  • A mechanism for maintaining browser state across requests, allowing “bookmarkable URLs” and browser back-button functionality, required for common web applications and portals

OPS4J will make an initial code contribution as follows:

  • Wicket support

  • Unified Jakarta Commons Logging and Log4J support for external libraries/frameworks that will be wrapped as OSGi services

  • Remote OSGi management console

TXE Systems will make an initial code contribution as follows:

  • Integration facilities with JSP and a Servlet 2.3-compatible OSGi service and web application bridge

Vetta Technologies will make an initial code contribution as follows:

  • Web workbench UI composition modules

  • Integration facilities with scripting languages (PHP as an example)

Further support has been expressed by:

  • Alex Blewitt

  • Max Carlson (IDE for Laszlo)

  • Grahame Grieve (OHF) and Eishay Smith (OHF), OHF is potential consumer

  • Russell Hamm (Mayo Clinic via OHF subproject), potential consumer

  • Martin Lippert (it-agile), potential consumer

  • Simon Kaegi (Cognos)

  • Scott Lewis (ECF), potential consumer

  • Ed Warnicke (Cisco)

The more input the project receives, the more cross-integration it can provide. We strongly encourage you to contribute your ideas, vision, know-how and skills in an area that may fall within the scope of this project.

Timing

  • June 2006: Eclipse 3.2/Callisto release slated to already support deploying plug-ins to a servlet container

  • July 2006: Demo application integrating JSP/JSTL, Struts and Wicket

  • October 2006: Initial API draft

  • May 2007: Version 1.0 API and sample implementations

Back to the top