Maybe we need multiple simultanous testbed projects pulled together under a single testbed umbrella. I don't see any need to follow one path as long as there are enough interested participants to make multiple investigations useful.
My personal interest and where I had hoped to do some work is in the higher levels of abstraction - what I would view as one or two levels above grid services - i.e. move up to the domain presentation level instead of just launching jobs and moving files. I don't know if anybody else is interested in this or not or even if its a viable long term path to follow but I think playing with it some would help us decide.
My background is working with chemists. So when Mary was mentioning
SDSC's GAMESS portal, I thought an interesting demonstration of interoperabilty
would be to set up a service here at PNNL that can take the necessary GAMESS
output, run it through a Molecular Orbital algorithm and generate either
a gif or preferably a VR file. This output would be sent back to
the service invoker and included in their portal. I'm sure there
are lots of other scenarios that a person could come up with that are similar.
The power I think is that people can create better portals faster
by using others domain specific services. Of course this
isn't something you'd necessarily want to do on huge data sets.
The other thing that I like about this idea is that it could be done without
too much concern for security. To some extent this is just a follow
up on the ideas in JINI and .NET.
One could also think of furthering this concept and applying it in a larger workflow sense. An xml description could be generated by a portal that includes the job running, and data moving etc but also automatically invoking these other services as part of the workflow. It seems to me that there is a ton of interesting work at this level.
Tomasz wrote
I am interested in portal interoperability. In particularly because I couldMy answer is that currently we do not use GSI at all. I think its a reasonable thing to use but we just haven't had the requirement (and right kind of money) to move to it. Until GSI is ubiquitious (if ever) we have at least some portion of our software that must work without it. Having said that, I'm not opposed to standardizing on it for any testbed work that we do. In fact with anticipated scidac funding, I believe we will be starting to apply GSI later this year. I could potentially move forward sooner at PNNL depending on what path we decide to pursue.
use "service portals" such as HotPage as my Grid Interface. And such a
project would validate our ideas about portal information services.But the first things first. Before doing anything we have to agree upon the
security model.
I know how HotPage works in this respect. In my portal, you must be an
authorized portal user, which also means you need an account at MSU
machines. But we are going to adopt myProxy/GPDK approach. What about you
Karen?
I'll just assume you all read Ian's comments.
I agree with Ian in the sense that I'd like to explore interoperability
at higher levels as I previsously mentioned. But I also think that
investigating interoperability is interesting from the standpoint that
Grid services are not ubiquitous at this time. Every
organization will be changing their infrastructure at different rates
(perhaps some not at all) so interoperability could be interesting for
some time yet. An I agree that the commercial world will be providing
lots of tools for us. Afterall by definition
they must make the smallest possible assumptions about common infrastructure.
So perhaps the question is where do we want to put our efforts? What problems are we most interested in investigating within this particular group.
Ian provided some possible testbed scenarios. These do look like
interesting topics that need to be addressed by Grid participants but are
these things that the GCE testbed is interested in? I was not
intending to propose an overall Grid testbed but one focused
more on end user services. So although these topics affect us
in the end, I was not anticipating a testbed on a scheduler. This
seems like work for the scheduler group.
So in summary what I'm interested in:
. application level services
. discovery of services and interfaces to perhaps dynamically construct
portals or PSEs (or at least build them faster)
. workflows at a high level (more than just jobs and data)
. moving forward. So if everybody else agrees on other topics
that aren't on my favorites list, I'd support going in that direction just
so we are moving forward.
Karen
Chip Watson wrote:
Karen et al,I'd be interested in some testbed / interoperability studies. I'm curious about
what capabilities you would propose to be distributed. Our efforts are
targetted toward distribution of data, and then later distribution of batch
jobs. For a single site, we are working towards having the portal provide
a lot of information to a web browser to view and manipulate storage and
batch jobs, ultimately providing for configuring and launching science
applications w/o logging in to the site, just using secure web.So, what might a testbed look like? Here's a few, based upon our near
term goals of basic infrastructure capability:1) demonstrate security interoperability (accepting each others
certificates, even if signed by different CA's)
2) demo displaying status of a remote site, with info retrieved via web services
i.e. PNL testbed portal showing status of machines at Jlab (which is not
running globus)
3) demonstrate requesting file staging or transfer using web services
4) demonstrate launching remote batch job (against system with foreign
or unknown infrastructure implementation) using web servicesWhat is on your list?
Regards,
Chip
--
Chip Watson
High Performance Computing Group
Thomas Jefferson National Accelerator Facility
Tel: (757) 269-7101
http://www.jlab.org/~watson