Collaborative Environments Group

[Home] [About] [People] [Projects] [Collaborations]
[Employment] [Quickstart] [Links] [Contact]

Portals:

[1]Portlets are Java-based Web components, managed by a portlet container, that process requests and generate dynamic content. Portals use portlets as pluggable user interface components that provide a presentation layer to information systems. The next step, after servlets in Web application programming, portlets enable modular and user-centric Web applications.

As mentioned above, a portlet is a Java-based Web component that processes requests and generates dynamic content. The content generated by a portlet is called a fragment, a piece of markup (e.g., HTML, XHTML, or WML (Wireless Markup Language)) adhering to certain rules. A portlet's content normally aggregates with the content of other portlets to form the portal page. A portlet container manages a portlet's life cycle. Web clients interact with portlets via a request/response paradigm implemented by the portal. Usually, users interact with content produced by portlets by, for example, following links or submitting forms, resulting in portlet actions being received by the portal, which then forward to the portlets targeted by the user's interactions. The content generated by a portlet may vary from one user to another depending on the portlet's user configuration.

A portlet container runs portlets and provides them with the required runtime environment. A portlet container contains portlets and manages their life cycles. It also provides persistent storage mechanisms for the portlet preferences. A portlet container receives requests from the portal to execute requests on the portlets hosted by it. A portlet container is not responsible for aggregating the content produced by the portlets; the portal itself handles aggregation.

A portal and a portlet container can be built together as a single component of an application suite or as two separate components of a portal application.

Grid Portals:

[2]The Computational Grid (or Grid for short) promises to be a powerful platform for computationally-intensive and data-intensive applications. Such applications come from biology, chemistry, and physics communities or virtual organizations. Grid-enabling these applications oftentimes becomes a herculean effort, utilizing several Grid software packages to leverage the power and achieve performance on the Grid. Furthermore, these applications are already fairly large and complex with hundreds to thousands of input parameters; Grid-enabling these applications only increases this size and complexity due to additional setup/configuration procedures. This is a challenge for Grid application developers because they often have to expend significant additional programming effort in order to make their applications "user-friendly" for other members of their community. Oftentimes, this amounts to achieving a fine balance of constructing an user interface that reveals enough detail so that users can see the Grid "at work" but not too much detail that users get discouraged and walk away.

The three main services that an user interface provides to end-users to facilitate running their Grid-enabled applications on a particular set of resources are launching, monitoring, and archiving. The steps involved in launching an application are 1) collect all of the data/information needed to execute an application, 2) format the data/information into a request that be sent to Grid resources and/or a scheduler, 3) send the request(s). Monitoring the launched Grid application or job involves checking generic job status information such as what resources are being used and how the job is distributed among them. Monitoring information can also be application-specific (e.g., summary graphs) to relate more intuitive progress information and can also relate quality of the job results. Finally, archiving involves storing a record of the job and its results so that it can be discovered by other collaborators.

In practice, user interfaces that perform the above functions are most often implemented as web portals or Grid portals. The advantage of Grid portals is that only the server running the Grid portal needs to have access to Grid tools and services (which are often not easy to deploy). Users of the Grid portal can then access the portal through any machine with just a web browser.

Gridsphere and Grid Portlets:

[3]GridSphere is both an implementation of the Portlet JSR and an architecture for supporting the development of re-usable portlets and portlet services. It includes a set of core portlets and portlet services that provide the basic infrastructure required for developing and administering Web portals. A key feature of the design of GridSphere is that it builds upon the web application repository (WAR) deployment model to support third-party portlet web applications. GridSphere itself is deployed as a WAR and serves as a portlet container for other portlet WARS that conform to the Portlet JSR and to the Gridsphere deployment model. In this way, portlet developers can easily distribute and share their work with other portal projects that use GridSphere to support their portal development.

Another key goal of our project is to develop a Grid portlet web application to allow end-users to make use of Grid technologies. The GridPortlets web application will enable users to upload their Grid credentials and use them to gain access to a variety of Grid services. Furthermore, in collaboration with other work packages with GridLab, we're developing portlets for administering virtual organizations and managing Grid resources. Moreover,the GridPortlet web application will contain reusable portlet service interfaces that can support different implementations depending on the Grid technologies developers require to support their project requirements.