1) Does your middleware support the concept of
virtual organizations?
Actually we don't have a clear
"virtual organizations"
conception, while I hava asked the developer, and
they told me it maybe corresponds to the "Agora" conception in GOS.
So agora is a group sponsored by some one, then the sponsor can add users and
resources to it, and then the users
in this agora can get use of
resources. These users can be totally
end users with nothing known about what grid are and
how our resources operates. We can
take a professor from the Department of Biology or Physics as an example. The resources can
be softwares on a cluster, such as Blast on our cluster at 166.111.131.47,
or our cluster infomation query service or the cluster queues query service. So
there is no other information service site. However, I found some
difference between these two concept. In GOS, a user has to belong to a default
agora, which would always be a blank
one with no resources and only some
resources-greedy users. After log in to the default agora, the user would query
the agoras he blongs, then he can
get access to other agora which is rich in resources. So, this is a little
different from the current g-Eclipse architecture, and
I am considering how to fix it.
So for me it seems that
your agora is some mixture of our virtual organization
and our information service. I will
come back to that a bit later in this mail.
2) Does your middleware have something like a
central information service, something like a central repository of available
computing and
storage resources?
We do have this component, but
this component is so weak in our middleware. Actually these infomations are
gotten by read the file filled by the site administrators. So these infomations
are possibly wrong. I hava communicated with the developer. They promised me
that they would feign to warn the administrators to force them provide
infomation correctly. However these infomation would be static and roughly corresponding to the dynamical immediate
circumstance.
As you said above the
(set of) agora(s) is a container of resources that are available to a user that
is part of the agora(s). So in this sense the agora is the info service,
right?!
3) How are the resources accessed remotely? Are they
enclosed by web services?
We have API to access
the resources with "open", "excute", "close"
operations, and actually they are
wrapped web services.
Regarding this API you
mentioned, is it written in Java? If it is not we will have some problems with
wrapping the functionalities with the g-Eclipse model since you then would have
dependencies to OS specific code, right?! If everything is in Java you can just straight ahead wrap your API with our model
elements.
4) What about authentication and authorization? Which concepts
do you use there? Key-pairs? X509? Something else?
We use X509 files, also we can log in to the grid with a username-password pair.
We need a proxy file (X509) or a username-password pair and
a namingurl, then we can get
accessed to the default agora of the user.
Sounds very promising
since we already have X509 proxy authentication as part of our Globus
implementation (See eu.geclipse.globus.auth). So either you may make use of
this directly or may provide your own implementation by following the Globus
implementation.
5) Is it possible to get access to an exemplary installation of your
middleware? Just to get a feeling how it looks like?!
Well, this middleware is
still in developing, and we
have some unstable copies on our sites. However, some of them can not be accessed by the foreign ends, and the only accessible one is down several days
before. So I would inform you as soon as it get up.
Would be great, so
waiting for your input here …
6) Concerning your client code for g-Eclipse, is it
available? Can
we have a look at it? Would be good to see concrete implementations when going
into technical details.
Sure these code would be
available. Currently we don't have too much code, and
our SVN server is in our local network which is a NAT network. So I think maybe
we need some SVN server. Can we
share our projects to the CVS server of the g-Eclipse projects?
Ok, let me give you some
information about the g-Eclipse project structure. We are an official Eclipse project. That does not only mean that our source code is free for everybody but
that everybody can contribute to our
project. Here is your entry point. Of course we would be happy to have a
further middleware implementation as part of our project. So yes, you can have access to our CVS repository (Ariel, could
you please provide the necessary information for Zou?!). For the moment I would
suggest just using this repository as development repository for you. As a
second step if your project gets to a state where it contains useable
functionality we may even think about including your plug-ins in our nightly
builds and even as feature in our
official releases. But this is of course a decision that has to be made by the
whole team rather than only by me. But
for me it seems that this would be a great benefit for both of us.
One more thing to mention
about the repositories. Actually we have two of them, one SVN at Eclipse.org and one CVS at fzk.de. The first one contains our
core codes, the second one our middleware-specific codes (the reason for having
two repositories are IPR issues). So your code should go to the CVS one to
which we have full access. For getting write access to the SVN you would have
to be a committer on the project which would not be that easy. Nevertheless if
you want to contribute to the core
parts you can send patches to us via
Bugzilla and we can commit these patches for you after we reviewed
them.
Ok, let me come back to
the technical side and give you some
first hints about your upcoming implementations. The first thing you have to
implement is the eu.geclipse.core.model.IVirtualOrganization
interface. Apart from the general VO concept the g-Eclipse VO is the central
point of access to a grid infrastructure. Therefore this interface provides
methods for accessing resources and
services. The most important thing
here is the IGridInfoService that is returned by the IVirtualOrganization#getInfoService() method. This info service
is used to build the users personalized grid. As soon as you have both things
implemented you should be able to create a Grid Project within your workspace and you should furthermore be able to query the
resources for your infrastructure in the project’s VO node.
Instead of fully
implementing the model’s interfaces you should rather extend the abstract
implementations we have for these interfaces. In the case of the IVirtualOrganization please have a look at eu.geclipse.core.model.impl.AbstractVirtualOrganization and
extend this class. In the case of the info service you may rather implement
eu.geclipse.core.model.impl.AbstractGridElement. By implementing these classes
you get some pre-defined implementations for some methods and you ensure the proper integration of your
implementations into the g-Eclipse model tree.
Furthermore you should be
aware of the fact, that model elements like VOs and
services are never created directly but are created by so called element
creators (see eu.geclipse.core.model.IGridElementCreator). So both for your VO and info service implementations you have to provide
corresponding creators and register
them to the g-Eclipse core with the help of the
eu.geclipse.core.gridElementCreator extension point.
So hopefully this will
help you to set up a first grid project for your middleware. The next step
would then be the authentication stuff, but first you should have a look at the
VO and the info service (Of course
if the above need authentication you have to start with that). For a more
detailed description of our model, the elements and
the creators please have a look at http://www.geclipse.eu/fileadmin/Documents/Important/gEclipse_TechAnnex_Final-public.pdf.
Cheers, Mathias
