Portals and e-Infrastructure, Requirements For Usability in the e-HTPX Project (A Developers Perspective)

Portals and e-Infrastructure,
Requirements For Usability in the
e-HTPX Project
(A Developers Perspective)
Dave Meredith, Grid Technology Group,
e-Science, Daresbury Laboratory
([email protected])
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
e-HTPX System
WS Requests
Loosely coupled
(Clear distinction between client + service)
York e-HTPX
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)
SOA – Built on hierarchy of remote
Web Services. UML shows some of
the communications required between
client and service.
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.
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)
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).
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)
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.
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
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.
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
Example – Portals/ Portlets in NGS Grid Portal
Job Submission
Batch Job Manager
Facilitates integration
of application specific
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
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
This has occurred even within the same project ! (e.g. 2 e-HTPX portal
Flexibility and customisation do not have to be mutually exclusive, can
achieve both but more complicated to do so.