OGSA 19: January 9-11 2008, London, UK
Attendees: A Stephen McGough, Vesselin Novov
Main groups of focus: OGSA-DMI, OGSA EMS, OGSA Strategy, Info/data modelling
architecture, Basic Security Profile, Service Level Terms
Imperial acted as host for this OGSA face to face meeting. We were able to provide a
venue suitable for the meeting along with refreshments thanks to the support from
GridNet2.
The OGSA-DMI session focused on the use of Data EPRs (DEPRs). These would not fit
within the current URI elements for source and target within a JSDL document. Though
as a JSDL source and target has a xsd:any it could be placed within that. There is also a
problem with EPRs in general that if you modify them you loose all security – due to the
hashing of the EPR becoming invalid. However, there is space within a DEPR to put
security credentials. This is currently an xsd:any and although it might be better to just
place a security attribute it was probably better to leave this as such. The consensus was
to submit the document now for public comment. This work is both significant for JSDL
as it provides a new and more appropriate way to transfer files – and again shows how
pervasive JSDL has become in the wider community. This is also significant for
GridSAM as it is something we are likely to require.
For OGSA EMS scenarios the focus now is on what to focus on beyond the basic
scenarios. Some possible contenders for extension are file transfer, advanced filtering,
Kerberos security, Info Modeling and accounting. It was proposed to scope down to just
things that could be done with HPCB profile, though this was felt to be too constraining.
There was discussion about file staging and using OGSA-DMI, though concern still
about DEPRs (see above). Security is also a problem. As the people running CDDLM are
no longer active within OGF and all that have evaluated CDDLM feel that it is too
complex to implement it will now be dropped fro the next version of the document.
Again the EMS work is highly relevant for our work on GridSAM and the future
development of JSDL.
Due to internal reviews held within OGF there is much refocusing within the OGSA
group this lead to an OGSA Strategy session. The feeling within the community (from a
yet to be published survey for OGF) is that most people in OGF are developers (eScientists) and not users, security is becoming a key problem – though at present no real
progress has been made, over the last four years OGF/OGSA have focused on low level
specifications. We need to move on from this and move development up through the
stack and add in security. There was much discussion as to providing higher level API’s
that programmers could use (is this SAGA?). Move towards access layers and service
layers and how we can use our existing standards together. There was also discussion of
the emerging cloud technologies and how these relate to OGF/OGSA. There was a
proposal to focus more on the clients – Browser (Web 2.0), traditional OS, APIs, APIs
for clouds?, and mashup technologies. This discussion was highly interesting and
something that we could contribute towards as our group here has moved already towards
internet (client) types of technologies.
The Info/data modeling architecture document is now almost complete. The new section
within the document is provided by the JSDL group to define how requirement matching
will be provided through future versions of JSDL. This is to be done through the use of
XQuery, though it was asked if XPath would be sufficient. This will be evaluated. The
need for optionality, weighting and preference were also discussed and will feed into the
next version of JSDL. It was also noted that hierarchies would be needed as, for example
a system responding as a “RedHat” OS should be able to match a job requesting OS of
“Unix”. This work is highly relevant for our work on JSDL as it will feed into the JSDL
requirements extension / JSDL 2.0.
The Basic Security Profile is now finished and will obsolete the OGSA Security profile
1.0. There was discussion on who would implement this work. GridSAM would be one
contender.
For the Service Level Terms work it was decided that there was not enough consensus to
standardise anything as yet and this design team has been left to rest.