AW: [geclipse-dev] Storage vs. Service

["Stuempert, Mathias IWR" <mathias.stuempert@xxxxxxxxxx>]

Hi All,

> > According to the discussion during our meeting today, we want to
decide > if 
> > LFC should be in Storage or Service branch of VO.
> >
> > We have gathered few ideas:
> > 1. keep as it is
> > pros:
> > - no effort required
> 
> Yes, I love to implement ostrich algorithm. :)

Well, I like the pro, too. But that's all. So definitely -1 from me.

> > 2. create a new branch in Services: Data Access Services
> > pros:
> > + all data access services are clustered in one place
> > + it's easy to find LFC endpoint
> 
> Not always easy. Try to create dteam VO. :)
> There are severals hundreds of services. Even "data services" branch
will 
> not solve the problem, as there is a lot of SRM services.

In principle I agree to Pawel. Nevertheless we could have something like
the "Data Access Services" branch and beyond that branches for the
different access "flavors", i.e. SRM, LFC, ...

> > 3. create an entry for LFC in Storage branch
> > pros:
> > + logically consistent (LFC behaves as storage element)
> > + easy integration with MountAction
> > cons:
> > - large effort changing gEclipse model (not recommended while we're 
> > introducing new middleware)
> 
> I cannot understand why it is so difficult. For me it looks that we
need 
> to have new class LFCStorage implementing IStorage. And this object 
> can be constructed from LFCService and added to "Storage" branch..

Yes, I think this approach should work.

> I vote for solutions 3 (LFCStorage) + 2 ("Data services" branch)
> And I also suggest for each service branch to group services by type.
> e.g.
> 
> -Some services branch
> |- SRM
> |- ResourceBroker
> |- VOBOX
> | |- VOBOX@node1
> | |- VOBOX@node2
> |-gridice

Two comments on that:

1) In principle I like the idea since it seems to clean up things a bit.
And as Pawel already mentioned it may be a good idea to introduce some
substructures in order to make large VOs "browseable".
2) We have to be careful to not introduce too many different branches.
If the user needs too many clicks to navigate to his service/storage or
whatever we definitely did something wrong. Currently it is 3 clicks (VO
-> Services -> Other Services). For a storage type branch it will also
be 3 clicks (VO -> Storage -> Type). For the grouped services branch it
will be 4 (VO -> Services -> Data Access -> Type).

All in all I agree with Pawels proposition. As long as we also have a
3-click feature the additional 4-click feature is also welcome :)

So, what has to be done on the model-side to implement this?! We have to
introduce something like:

class IGridDataAccessService extends IGridService {

  /**
   * Return a String identifying the type of the service.
   * (Is this really necessary or can we use IGridService#getURI()
   * to group the services?)
   */
  public String getServiceType();

  /**
   * Creates a new storage from this service.
   * (Do we need any parameters here?)
   * (Maybe this could also be applicable to GRIA since
   * we there currently have an IGridService that also implements
   * IGridStorage?!)
   */
  public IGridStorage createStorage();

}

Did I forget something?

Cheers, Mathias