Portals and e-Infrastructure, Requirements For Usability in

the e-HTPX Project(A Developers Perspective)

Dave Meredith, Grid Technology Group, e-Science, Daresbury

Laboratory (d.j.meredith@dl.ac.uk)

Relies heavily on a range of e-Science technologies (Portals, Web Services, XML, Databases, HPC), especially those associated with distributed / enterprise / SOA computing.

Project integrates a number of key services provided by UK e-Science, protein manufacture and synchrotron laboratories.

The usability of both client interfaces and e-infrastructure/ services are key to e-HTPX.

e-HTPX Project

A distributed computing infrastructure for protein crystallographic structure determination

Requirements to Increase The Usability of e-HTPX

Addressing these points helping to make both the e-HTPX portal and its service based infrastructure more usable and accessible.

Developer perspective centres on technologies/ standards designed to address these requirements

1) Rich portal interface. Traditionally, web applications are not as graphically rich/ interactive as desktop GUI clients (next generation web-applications and tools are increasing usability through more re-usable interface components, e.g. JSF, and dynamic interaction technologies, e.g. AJAX).

2) Application-specific portal interfaces. Customised to address different requirements of client communities (OPPF e-HTPX portal, YSBL e-HTPX portal).

3) Well defined service/ resource interface (Service Orientated Architecture, e.g. WS, WSRF). Improves access/ usability of service.

4) Frameworks for modularity + reusable software (e.g. Portal/portlets, WSRP)

WS Requests

Loosely coupled

(Clear distinction between client + service)

e-HTPX System Architecture:

OPPF e-HTPX Portal

York e-HTPX Portal

JSF Components Reusable component approach to

content presentation, e.g. tree structures, table scrollers, tabbed panes, hierarchical tree-tables.

Standardised, increasing vendor support, e.g. Apache MyFaces, Oracle ADF (100 re-usable user interface components).

Tool support becoming more widely supported (Sun Studio Creator, Netbeans 5.5, JDev).

1) Rich User Interaction Experience

AJAX (Asynchronous JavaScript and XML) Enhances dynamic user interaction (e.g. Google Maps) AJAX is a collection of open standards Should be used with care:

Changes familiar request/ response interaction model (deep linking and navigability may be lost – i.e. ‘back button’ may not work as expected).

Increase in client platforms (e.g. mobile/ PDA) is problematic

• Two e-HTPX compliant portals being developed tailored to cater for differences between working practices of client (e.g. OPPF users and YSBL users)

• Portals simplify using web-services by effectively laying a user interface ‘on-top’ of a remote web services (user is hidden from details of parsing WSDL file, generating client code libraries, writing software)

2) Application Specific (Customised) Interface

OPPF e-HTPX Portal YSBL e-HTPX Portal

1. SOA – Built on hierarchy of remote Web Services. UML shows some of the communications required between client and service.

2. XML Schema Data Model – The data model provides an open and agreed standard for communication and data-exchange between the different partners involved in the project.

3. Loosely Coupled Clients - SOA provides client flexibility, e.g. use of different clients to access services (portal or desktop). For e-HTPX, SOA allowed development of customised Portals installed at client labs (OPPF and York Portal)

SOA – Loose coupling between services and clients but with well defined service interfaces (e.g. Web Services + WSDL)

3) Easily Accessible Resources/ Services

1. Use a 100% XML Schema compliant <wsdl:types> - facilitates advanced data-modelling (far more comprehensive type system than SOAP encoded complex types and simple types – Doc/wrapped not RPC).

2. This avoids dependencies on technical implementation language (often introduced when implementing ‘code first’ RPC). Doc/wrapped is WS-I compliant and fully interoperable across different platforms (e.g. .NET, J2EE)

3. Schema data model/ messages can be abstracted/ separated from WSDL bindings and developed in isolation

• Data validation (advanced features of XSD), no dependency on SOAP engine

• Encouraged collaboration between the different partners involved in the data model design process.

4. SOA in next generation of Grid resources (WSRF). Should make Grid resources more usable/ accessible (UDDI, WSDL interface for resource invocation)

3) Easily Accessible/ Usable Resources (e.g. WS Interoperability)

4) Modular/ Reusable Interface Components

Portal/ Portlets Allows development of separate, reusable web-application components (portlets). Multiple portlets can be combined together within a portlet container to form a single, larger web-application (portal). This means portlets designed to provide a specific service or functionality can be reused/ shared in different projects. Great idea – a) encourages reuse of resources/ code (e.g. portlet registries) and, b) facilitates separate development of

components (often a necessary evil in large distributed projects where developers are geographically spread). JSR-168 requires closer integration with well established web-application frameworks (e.g. JSF, struts) for richer

interface support/ GUI component reuse.

WSRP Portlet can be hosted on remote server A portal can display the remote portlet as if it were installed locally Can consume remote portlet without having to write unique code to use the service.

Example – Portals/ Portlets in NGS Grid Portal

Job Submission Portlet

Batch Job Manager Portlet

Facilitates integration of application specific portlets

Development Issues / Challenges

Complexity; Web App programming is complex (not to be confused with Web-sites). Many

extra considerations and technical API’s (RDBS, SQL, Object-Relational mapping, XML, MVC, Security, Multi-user, Network, Multi-threaded programming, Data synchronisation, JSF, Struts, AJAX, Portal/Portlets).

Balancing the correct level of flexibility with customisation (seems to be a ‘trade-off’ - flexibility often requires interface to be generic while usability often requires customisation); This has occurred even within the same project ! (e.g. 2 e-HTPX portal

implementations). Flexibility and customisation do not have to be mutually exclusive, can

achieve both but more complicated to do so.

Rich user interfaces in next generation of web-apps/ portals Often require application specific interfaces tailored to suit users requirementsSOA increase usability of services (facilitate development of different clients)

Summary