next up previous contents
Next: Technical Framework Up: Role of Portals in Previous: Developing a VRE   Contents

A Service Oriented Architecture

A Service Oriented Architecture (SOA) is an approach to joining up services to provide integrated capabilities. It is a relatively new approach, but is rapidly gaining popularity because of the lower costs of integration coupled with flexibility and simplified configuration. This is becoming best practice for commercial distributed software development, see recent reviews e.g. [47,48,49,50,51]. An SOA builds upon the use of web services, the emerging industry standard for building and integrating distributed systems. The rationale for using an SOA in the JISC context for MLEs/VLEs is given in [43]. Other relevant projects worldwide are considering and indeed beginning to deploy similar approaches and architectures. One worth noting is Arda, the next generation framework for distributed analysis of Large Hadron Collider data [52].

Portal deployments have, until now, typically been monolithic with a rich set of tools, customisation possiblities and a database for content management. CHEF, OCE and Sakai fall into this category and are deployed as large Java jar files. At CCLRC the Integrated e-Science environment, IeSE, comprising services from HPCPortal, InfoPortal and DataPortal has already tried to break this mould [16]. Another more recent activity at University of Indiana is taking this a stage further and now using CHEF [54]. In Section 6 we propose an architecture for presentation of services throught portlets in an SOA which extends these ideas.

The following figures highlight some basic aspects of an SOA relevant to deploying a VRE with appropriate user interfaces such as portals, online commands, drag and drop desktops and programming libraries. A key aspect of the architecture is to maximise the re-use of common services and middleware including portlets.

Figure 3: The Grid of Services
\includegraphics[width=6.5in]{portal_grid.eps}

Figure 3 shows how an SOA approach would be of benefit in exposing a common set of services and middleware through a variety of user interfaces including Web portals employing the WSRP standard. It indicates how this architecture can be used to facilitate the horizontal aggregation that can occur for specific groups, e.g. the National Centre for e-Social Science (NCeSS) which is working alongside the Lancaster node for Quantitative e-Social Science (CQeSS) and the JISC/ ESRC training and awareness programme ReDRESS, see http://redress.lancs.ac.uk.

An SOA clearly does not preclude also using portals or data warehouses, and is in fact agnostic about how the rest of the enterprise is configured, which is why it makes a good approach for a framework. In addition, because integration occurs in this fashion, it becomes a simpler task to replace the systems that provide services within the architecture or to look up new ones via a registry such as UDDI [56]. Because service consumers are configured to access a service without any knowledge of the system that provides the service, we can replace the underlying system without affecting systems dependent on its capabilities.

Figure 4 shows how services are used in a typical 4-layer architecture for portals and other client tools.

Figure 4: 4-layer Portal Architecture employing Web Services
\includegraphics[width=6.5in]{4-layers.eps}

Notes:

  1. Presentation layer, e.g. uPortal, Jetspeed or similar integration and rendering framework. Tools such as Sakai/CHEF add value to this by providing a content management system and additional service interfaces.
  2. Front end services, logic layer interfacing with (1) through the JSR-168 portlet API.
  3. Back end services, accessed via web service or other well-known protocols: could be distributed, and/or could interact with other web services forming a Service Grid.
  4. Remote resources on a Grid infrastructure, e.g. computers and data bases, such as the JCSR clusters.

Figure 5: Portlets using Web Services
\includegraphics[width=6.5in]{portlet_implementation.eps}

This is further discussed in Appendix D.


next up previous contents
Next: Technical Framework Up: Role of Portals in Previous: Developing a VRE   Contents
Rob Allan 2005-05-09