Summary of portal activity for Edikt2
During visits to research groups (over 30 at this date), as part of the requirements gathering process for the ECDF, researchers have been asked how they wish to access the ECDF. All except two groups wish to access the ECDF via a command line interface, as this is how they have been accessing resources in the past (local machines and clusters, or the NGS) and they are comfortable with this method. These groups also see CLI access as being more flexible than a portal.
Of the two other groups, GridQTL is using their own portal, which is very much focussed on their needs, and is application specific to their tasks. GridQTL uses the NGS and Condor as a processing back-end to their portal, and by providing a compatible middleware stack on the ECDF, they will be able to access ECDF resources without needing to make and changes to their existing front-end.
The final group use Taverna for designing workflows as their front-end, and require access to the ECDF via web-services, which the Middleware team will provide.
Portals were discussed at a Campus Grids meeting I attended at the Oxford e-research centre. The concensus amongst the other research computing people attending from various UK universities was that a general purpose portal for job submission was not seen as useful (as soon as it becomes general enough to meet everyone’s needs it becomes over-complicated and lacks focus for any specific group of users). Portals that are highly focussed on completing tasks for a specific group of users had been seen to succeed.
The Middleware team are trialling a simple web-based front-end for job submission/monitoring on the ECDF using Sun Grid Engine Portal. The attraction of this solution is that it is an out-of-the-box open source product (so requires little time to configure and has good support from the user community). This product would allow users to submit and monitor jobs from anywhere with web browser capabilities, while retaining much of the flexibility a CLI would give them.
One requirement that came out of the user visits was the desire to use resources across and outwith the University in a consistent manner. For example, a researcher might want to submit a job that needed to be completed within two hours, but not care on which resource it is run (local cluster, ECDF, NGS, a Condor pool, etc). Some form of resource broker could make a decision based on the researchers criteria (“complete job in less than two hours”), and submit the job to that resource, producing the necessary job description language and relieving the researcher of having to know how to submit jobs to many different systems.
A further requirement is to expose data and services via web services, to enable the use of the ECDF from workflow packages.
The above two requirements are being investigated further by the Middleware team.
MikeBaker June 2007.