[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [geclipse-dev] GRIA Information System
|
Mathias I read your mail and I have some observations/questions.
I think the service endpoints should be saved in the VO. The user will
write them when he vreates a GRIA VO.
We need to decide what the info system should provide for a GRIA
middleware. You say in your mail that "the information service should
create the CEs, SEs and services on demand". I am not sure I understand
what you think as a CE, SE and a service. Do you mean the dataservice
and the jobservice or the applications that the GRIA provides for the
end user and the data stagers? If you mean the dataservice and the
jobservice and these are saved in the VO, I don't see what the info
system can provide. I think that the information system should be
involved in providing information and not activating the GRIA services.
If on the other hand you mean that the info system should provide the
applications and the data staggers we can elaborate on how to do it, but
as fas as I know you don't want this from the info system.
I agree with your point that there should not be a GRIA authentication
dialog untill it is really needed, like when we submit a job. However, I
don't know how we submit a job. Are we submiting a jsdl or will we use
the GRIA api to run a job?
As a first step we should have a clear idea of what the info system
should provide. Then we can discuss on the way to implement it.
Thanks,
Nikos.
Stuempert, Mathias IWR wrote:
Hi All,
This mail mainly addresses Nick and IT Innovation but may also trigger
a general discussion about the GRIA information system. Its purpose is
to give you a short insight into the current implementation of the
GRIA VO and the services and a proposal for a new and maybe better
implementation that I would like to give before leaving for my vacation J
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 alternative:
When creating a new GRIA VO the services should not be created
immediately. Instead a GRIA information service should be created that
holds the service endpoints of all other services. This information
service has no direct counterpart in the GRIA architecture but may be
seen as a helper for g-Eclipse. Now if the user creates a new Grid
project with the GRIA VO the corresponding VO node and the underlying
computing, storage and service nodes will be created. Now the
information service should create the CEs, SEs and services on demand,
i.e. if the user expands the corresponding node in the VO tree or if a
service is needed for a dedicated user action (e.g. job submission).
At this point the user may be asked to authenticate which is the much
better approach in my eyes than letting him authenticate at the point
he creates his VO.
Obviously the implementation of such an information service would be
on your side Nick. Furthermore it would be interesting in what extend
the content of the WSDLs of a GRIA service can be fed in to our GLUE
schema. So what is your impression on such a solution? What are the
opinions out there? Any comment from Ken or Mike? If we decide to go
for such a solution we should NOW start the corresponding
implementation since this is the base of everything else concerning GRIA.
So hope this mail starts an interesting and fruitful discussion J
Cheers, Mathias
------------------------------------------------------------------------
_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
