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)
e-HTPX Project
A distributed computing infrastructure for protein
crystallographic structure determination

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 eScience, protein manufacture and synchrotron laboratories.

The usability of both client interfaces and e-infrastructure/
services are key to e-HTPX.
Requirements to Increase The Usability of e-HTPX
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)
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
e-HTPX System
Architecture:
OPPF e-HTPX
Portal
WS Requests
Loosely coupled
(Clear distinction between client + service)
York e-HTPX
Portal
1) Rich User Interaction Experience
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).
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
2) Application Specific (Customised) Interface
• 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)
OPPF e-HTPX Portal
YSBL e-HTPX Portal
3) Easily Accessible Resources/ Services
SOA – Loose coupling between services and clients but with well defined
service interfaces (e.g. Web Services + WSDL)
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 dataexchange 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)
3) Easily Accessible/ Usable Resources (e.g. WS Interoperability)
1.
Use a 100% XML Schema compliant <wsdl:types> - facilitates advanced datamodelling (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
4.
•
Data validation (advanced features of XSD), no dependency on SOAP engine
•
Encouraged collaboration between the different partners involved in the data
model design process.
SOA in next generation of Grid resources (WSRF). Should make Grid resources
more usable/ accessible (UDDI, WSDL interface for resource invocation)
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
Summary
Rich user interfaces in next generation of web-apps/ portals
Often require application specific interfaces tailored to suit users requirements
SOA increase usability of services (facilitate development of different clients)
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 ‘tradeoff’ - 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.