Re: [geclipse-dev] GRIA Information System

["Ken Meacham" <kem@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Hi Mattias, Nikos, etc,

Some comments on your emails about the GRIA Info System, VOs, etc...

> The current GRIA implementation:

> When creating a new GRIA VO you have to specify the service endpoints
in the 
> dedicated dialog. When pressing OK in this dialog the underlying GRIA
service 
> is immediately instantiated. That particularly requires the creation
of a new 
> GRIA authentication token which is definitely not the best solution. 
> Furthermore we do not yet have a concept for a GRIA based information
system. 
> Keeping these two aspects in mind I would like to propose a maybe
better 
> solution.

The current method of creating a VO (by manually pasting in the WSDL
URLs) seems to be a good approach, until we can make use of a GRIA Info
Service (I'll come back to that!). This is how the GRIA client works
now, though in this case you can simply drag-and-drop the WSDL link into
the client GUI.

When you say "the underlying GRIA service is immediately instantiated",
I think you mean that:
 1) WSDL is downloaded and parsed by the client, generating a set of
service endpoints
 2) service objects are created, in the GRIA state repository, according
to service endpoints
 3) corresponding GriaService elements are created in the g-Eclipse
model

Really, it is step (1) here that requires the GRIA keystore (or
"authentication token") to have been set up. This is not so much for the
client to authenticate with the server at this stage (since anyone can
contact a service), it is more that the client (user) needs to trust the
server. Here the dialog would normally pop up, asking if you trust the
service (the server may already be trusted by the client having the
server's certificate in their keystore).

The issue is that we must be able to trust the WSDL being published by
the service. This is done by trusting the server's CA certificate. It
does not seem appropriate to parse untrusted WSDL, creating a set of
untrusted service endpoints.

If, on the other hand, we simply want to store a link to the service
WSDL, then there are no trust issues until we form our concrete VO. Of
course we won't properly know what type of service it is in our VO until
later, i.e. if it is a Job or Data service, so how would this be
presented to the user?

You say, "That particularly requires the creation of a new GRIA
authentication token which is definitely not the best solution". I'm not
sure about this. Really, to be able to use ANY GRIA services at all, the
first thing you will need is a keystore. I would have thought that this
should be the very first thing that you set up (in a VO, or wherever).

You also say, "Furthermore we do not yet have a concept for a GRIA based
information system". The equivalent of your information system is our
GRIA Registry, which I will attempt to explain. The Registry SERVICE, is
included as part of the Client Management package of GRIA. This service
could be considered as a registry factory, since users/clients are free
to use this to set up their own registries. Each registry is treated as
a resource on the service (cf Job or Data resources in the Job/Data
services).

The GRIA Registry stores endpoints for services or resources. It can
also store other data such as Applications, SLAs, etc. These may all be
queried in many ways.

So it seems to me that what we should set up for g-Eclipse is a Registry
Service at one of the sites (e.g. where the Job/Data services are
already installed). We then need a single Registry resource to be set
up, which may be used to store the service endpoints for any services
available to the project. Once this is set up, this will effectively be
the GRIA "Information Service", to be used in the sense that you seem to
want to use it.

I believe that Ariel has been trying to set up a Registry Service? How
are you getting on?

In the GRIA client, we can browse through (or query) for available
services/resources in the registry, then we can choose to add these to
our list of services/resources, which actually instantiates the objects
as described earlier (i.e. in the state repository).

Please have a look at the following page in the GRIA 5.2 docs, which
describes the registry service quite well:
http://www.gria.org/documentation/5.2/manual/client-user-guide/contextua
lised-discovery/client-management-registry-client

One final point - if we use a GRIA Registry to obtain a list of service
endpoints, in order to define our VO, then we will need to authenticate
with this service to get the information. So there really is no way of
getting around having to authenticate in the early stages of setting up
a VO...

Hope this helps to clarify things a bit.

Best regards,

Ken.