OGF 21: October 15-19 2007, Seattle, WA
Attendees: A Stephen McGough, Vesselin Novov
Main groups of focus: RUS, GSA-RG, JSDL, Joint Session on Information Modelling for
Computing Resources, RSS, GridNet2 Workshop, OGSA Workflow, OGSA f2f, HPC
Profile, SAGA, OGF tutorial on Vulnerability Assessment and Secure Coding Practices
for Middleware
The RUS group as outlined previously is re-working its specification that was published
previously based on implementation experiences. These include dealing with large
records and the ability to request sub-parts of the whole Usage Record sets along with the
rendering of RUS both in WS-I and WS-RF. As we have previously implemented the old
specification for RUS we are keen to feed-back our experiences on this work.
The Grid Scheduling Architecture group are focusing on Scheduler interoperation. In
their architecture they see BES instances as being the end points for execution and JSDL
as the language to describe the jobs sent to these resources. For this work they seek to
profile JSDL in terms of which attributes within the document are relevant for the
scheduler and how they should be interpreted. This again shows further groups within the
wider Grid community adopting JSDL and BES. The work of GSA is not to use the entire
of JSDL but to partner it with a scheduling language for those things relevant to
scheduling but not to JSDL. We were able to take an active role within this session as
both a group that was developing scheduling above BES/JSDL through GridSAM but
also as part of the JSDL group with our knowledge of what was currently in JSDL and
what would likely be there in the future.
For JSDL at this OGF we held three sessions. The first session was a general session for
outlining our work and current status. We iterated over the JSDL 1.0 errata document for
which we have now resolved 25 of the 32 issues – extra issues have been raised since the
last F2F meeting. We are also now collecting experience reports from those groups that
have implemented JSDL. At present we have four responses with more promised. We
also had a presentation from GridWay for their use of JSDL thus we now have twelve
known implementations of JSDL. The second session was focused on the XQuery
extension for JSDL. This focused on the new idea to use capabilities and requirements in
a JSDL document and how you could define the requirements as XQuery requests over
the (to be matched) resource description document. This session looked into how XQuery
could be used to achieve this goal and weather XPath, as a simpler mechanism, could be
used to achieve the same result. The conclusion arose that if all we wished to achieve was
extracting parts of the other document then XPath would be sufficient. However, if we
wanted to perform more complex operations on the other document, such as the processor
speed is twice as important as the memory, then we would need the full XQuery. The
third session was more like a BoF session. We were proposing to start some new work on
an Activity schema. This document, for which JSDL would be a part, would contain the
whole activity lifecycle of the job. Information on resource usage, scheduling, job status
would all be placed into this document. Though the contents of these sections would not
be defined by the specification, mealy refer off to the appropriate specification.
Presentations were made by GridSAM, UDAP, GLUE and NEREGI as to what they have
done already in this area. This session allowed us to illustrate GridSAM and place it in
prime light within the community.
The Joint Session on Information Modelling for Computing Resources session brought
together most of the parties that had discussed information models at the last OGSA F2F
meeting in a wider context. The discussion was on how GLUE relates to other
specifications such as BES and JSDL. This allowed the groups to fill in the details of how
we are all integrating our work together. For us the use of resource descriptions into the
JSDL document from those in GLUE.
The Resource Selection Service (RSS) is now submitted to the OGF editor. This
specification defines an interface for how to select a set of potential resources for
executing a job. As such it relies heavily on JSDL as a job description language and for
terms defining what type of resources are appropriate. Again showing uptake of JSDL
(and BES) thought the OGF.
During this OGF we had organised a GridNet2 Workshop in collaboration with Omer
Rana. This has allowed all participants funded through GridNet2 to highlight the work
they have achieved. For this we were able to present work on GridSAM, GRIDCC and
the development of the ICENI II architecture as areas which have both influenced the
development of the OGF standards, but also benefited from these emerging standards.
As much of the scope for the OGSA Workflow group has changed since the last OGF
meeting we presented an overview of its progression and metamorphism into its new
form. Out now is the plan to develop our own workflow language or to add simple
workflow constructs onto JSDL. Instead we are now focusing on surveying what is
currently being used within the wider community. As such initial results of our survey
were presented. This lead to discussion on what else we should be asking and how to
solicit responses from other groups. It was also discovered at this stage that the WFM
group are currently performing a similar survey and it was decided to combine the effort.
At the end of the OGF meeting a one day OGSA f2f meeting was held. An EMS session
was held to discuss the revising of the EMS scenarios document. The plan is now to swap
out BES for HPCP where appropriate in the document and downplay CDDLM as it is
now “resting”. Other work such as RSS needs to be reviewed. It was decided that as there
was not yet enough community support for the Service Level Terms work and as there
was not enough consensus for what to do in this area it was not a prime area for
standardisation. As such the work will be left for now until we have more knowledge on
what can be done and what people want to do. In the area of workflow it was decided that
rather than duplicating the work of the WFM group’s survey OGSA would collaborate
with them on their survey and once completed determine how best for OGSA to progress
with workflow. The Data Movement Interface is an interesting piece of work which helps
abstract the user away from how data is actually transported around the Grid. Rather than
specifying protocols and resources the user specifies known endpoints one for where the
data is currently and one for where you wish the data to end up. The DMI is then
responsible for identifying the most appropriate method for transferring the data. This has
major implications for both JSDL and GridSAM. DMI could be used to describe the data
staging endpoints and GridSAM could use DMI to source and send the files. This is
highly relevant work.
Much of the work in the HPC Profile WG session focused on the upcoming
Interoperability fest scheduled to take place at the SuperComputing convention in
November'07. In particular, much of the discussions covered the profile extensions which
were to be demonstrated as the new additions to the specification. The Data Staging
extensions was based in large part on the existing Data Staging element in the JSDL
standard but the extension document restricted the set of options otherwise acceptable
under the original spec. The text of the extension explicitly listed the type of data transfer
protocols, which support would be expected from compliant implementations - http,
ftp(both GridSAM supported) and scp. The Activity Credential element would provide a
security context to the processing of a submitted computational job. The inclusion of this
element was to account for the missing but otherwise necessary security left out of the
scope of the JSDL standard. At the session we agreed on the general framework,
sequence and logistical details of the interoperability demonstration which in the most
part would replicate the successful interop fest at the SuperComputing in the previous
year. The functionality provided by comparatively more mature GridSAM already
offered staging of input/output files as well as a particular service configuration option
allowing the user to supply security credentials necessary for data transfers and/or the
launching of the executables.
Simple API for Grid Applications (SAGA) a C++ an Java implementation of the GWDR.90 standard specification. The efforts of the SAGA group are focused on the
development of a high level framework for use in creating grid aware applications. The
interest in the activities of this group come from the fact that this API presents to the user
as a simplified way to interact with grid-middleware products, with one such being
GridSAM. In architecting and implementing the recommendations in GWE-R.90, the
group addresses the inherit difficulties and issues of heterogeneity and complexity of grid
applications. Therefore the SAGA is envisioned to provide common grid functionality at
the correct level of abstraction along with the ability to hide varying underlying
semantics. SAGA can make important contribution to interoperability at the Application
level (an abstract layer above the one where such middleware as GridSAM functions),
especially given that the SAGA software environment has matured sufficiently, thanks to
advances at several levels; the SAGA engines (C++ and Java); the adaptors for different
middleware distributions(Condor, GridSAM); and the maturity of the core SAGA
specification. During the group session the discussion revolved much around the current
status of the two programme language bindings, the road-map, deliverables as well as the
specific ways SAGA contributes to interoperability efforts among grid users, application
and middleware developers and resource provides.
The OGF tutorial on Vulnerability Assessment and Secure Coding Practices for
Middleware gave us valuable insight into the low-level requirements for a secure
software development. Secure programming would be essential for our OMII
Authorization application. The tutorial was relevant to anyone attempting to assess
software for security flaws and for developers trying to minimize security flaws in
software they write. Part of the tutorial covered a process for actively discovering
vulnerabilities – the gathering of information about a targeted system, the use of the
collected information to direct the search for vulnerabilities and the integration of these
two steps into the development cycle. The tutorial pointed out specific coding practices
for prevention of vulnerabilities, exposed many types of vulnerabilities with examples of
how they would commonly arise, and showed some simple techniques for avoiding them.
At the OMII-UK workshop we were presented of the general, overall direction of the
organization's current activities. OMII-UK's mission had been to provide the UK eScience community and their international collaborators with the software solutions and
support they needed to enable a sustained future. During the session we were given
demonstrations on some of the ways to help research communities benefit from the
increasing number of resource providers - from national grid infrastructures, such as the
NGS, to campus grids and departmental clusters. The demonstrations also included
examples of using stable APIs (e.g. SAGA) and showing how common scenarios can be
solved by integrating components and providing new access mechanisms such as portals,
virtual research environments, and desktop grids. We also discussed how projects could
build on top of efforts such as GIN and OMII-Europe to bring together Grids through
open standards and interoperable implementations. The future of the OMII-UK and new
developments in the organization's efforts are of a particular importance to our team in
London e-Science Centre. We have had a very productive relationship with OMII-UK
resulting in a number of projects, some of them that have already proved successful, in
delivering grid middleware application to the wider scientific community: GridSAM,
GridRUS, OMII-AuthZ and GridBS.