Grid Computing Infrastructure Architecture Document

7 Portal View

Note: This is not our research domain but is of research interest since it is the key to GESLK's extensibility and problem definition. Thus it will be the central focal point for the future work.

The computational communities that serve as computational hubs for organizations need to weave together services and information from a variety of internal and external sources to serve the needs of their members. Individual organizations will want to further customize their own information views for personal relevance. For these reasons, a key part of the GESLK technical architecture is portal software (which is not our domain specific work but is a research interest), which enables the creation of a common entry point for delivering aggregated and integrated information and resources.

In the GESLK network, these portals will enable integration of internal and external applications, data, services and content.

Portals typically include a suite of core applications that provide valuable services for members and organizations. There is great modularity and loose coupling of applications to the portal when used with a Web services design. For non-core applications, the Web services design is optimal, taking over for what now is done in an ASP model. The portal engine makes use of services proxy clients to dynamically fetch and assemble data and content from remote service providers. Service endpoints can also be exposed externally for other portals, thus a portal can be a service provider as well as a service requester which gives it utmost scalability and compatibility with other Grids in the Global Networking environment.

7.1 Portals

Portals are channel-like Web components designed to be aggregated in the context of a composite page. Typically, to create a personal portal page (like My Yahoo), a single page request to the portal engine invokes multiple portals, each of which produces a fragments for the final page.

Recently, the major portal software vendors have begun working within OASIS to develop a standard for portals. Called Web Services for Remote Portals (WSRP), this standard will define a pluggable, user-facing, interactive Web services with a common, well-defined interface and protocol for processing user interactions and providing presentation fragments suitable for aggregation by portals. These can be the remedy for GESLK's portal problems. WSRP-compliant portals will be able to run on all WSRP-compliant portals without requiring any service specific adapters; a single, generic adapter on the portal side will be sufficient to integrate any WSRP service. WSRP will standardize the presentation layer of these Web services. The WSRP interfaces are defined in the WSDL and include a specification for metadata for self-description and publishing in WSRP registries. If the OASIS WSRP standard is successful, it could be translated to work in our problem domain and will be an enormously valuable technology for GESLK's members since it will greatly enhance the scope of the GESLK.