Portals and e-Infrastructure, Requirements For Usability in the e-HTPX Project

1. 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)

2. 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 e-Science, protein manufacture and synchrotron laboratories. • The usability of both client interfaces and e-infrastructure/ services are key to e-HTPX.

3. 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 + reusablesoftware (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

4. WS Requests e-HTPX System Architecture: York e-HTPX Portal OPPF e-HTPX Portal Loosely coupled (Clear distinction between client + service)

5. 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

6. 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) YSBL e-HTPX Portal OPPF e-HTPX Portal

7. 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 data-exchange 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)

8. 3) Easily Accessible/ Usable Resources (e.g. WS Interoperability) • 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). • 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)

9. 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.

10. Example – Portals/ Portlets in NGS Grid Portal Job Submission Portlet Batch Job Manager Portlet Facilitates integration of application specific portlets

11. 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) • 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. Development Issues / Challenges