[geclipse-dev] New GRIA AAI committed

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

Hi All,

 

I just committed the new GRIA AAI stuff and hope that this is not only working for me now :) So any feedback is of course appreciated.

 

One comment at the very beginning. I do not expect that things are stable from the beginning and it may be a lot of work to really get this stable. Nevertheless I decided to let this go into the final GRIA release since it comes with really a lot of improvements (some mature and bunches of minor). But since this is a quite new and rather complicated functionalities it of course has to be extensively tested!

 

So here is some information that should be read carefully by everybody:

 

With the new AAI it is possible to maintain and access multiple GRIA infrastructures at the same time. Therefore the GRIA VO has to be defined with an additional field which is the key store to be used when working with this VO. This means that old GRIA VOs will not work any more. So be sure to test with a fresh workspace or at least with fresh GRIA VOs! AND be sure to TEST THIS at all!!!

 

Since GRIA uses a dedicated (non-singleton) class in a singleton pattern to access GRIA sites with axis and this class (AxisTransport) “manages” the GRIA authentication, this class was replaced by an own implementation and access to this class is now synchronized. That means that only one GRIA operation can run at the same time. That means that if you are just fetching the applications of a project a job submission or any other operation has to wait until the former operation has finished. There is still some room for improvement here but in any case operations belonging to different project with different key stores will block each other, no way to get rid of this behaviour.

 

Furthermore the old Swing stuff asking for certificate validation was replaced in hopefully all places. If you find this dialog still somewhere please let me know.

 

I did not integrate the new AAI for the largest parts of the GRIA operations, this is left to the corresponding developers. So things will not work properly as long as these parts did not switch to the new AAI. See following information for more detail:

 

The following information should be read carefully by all GRIA developers:

 

In order to make use of the new GRIA AAI you have to ensure that EVERY “atomic” GRIA operation that needs authentication is running in a synchronized authenticated context. This is achieved with the GriaOperation and GriaRunnable classes (both in eu.geclipse.gria). The nice thing is that you do not have to take care about the authentication by yourself, the underlying implementation does that for you. As soon as you suspect an operation to need authentication you should handle this operation within a GriaRunnable. The general design pattern here looks like this (example taken from eu.geclipse.gria.info.GriaUtility which serves as an exemplary implementation):

 

final RemoteJobService jobService = ( RemoteJobService )griaJobService.getSlave();

String[] applicationList = null;

GriaVirtualOrganization vo = ( GriaVirtualOrganization ) parent.getAdapter( GriaVirtualOrganization.class );      

if ( vo != null ) {

  GriaRunnable runnable = new GriaRunnable() {

    @Override

    public void run() throws RemoteException {

      String[] applications = jobService.getApplications();

      setData( "apps", applications );

    }

  };

  GriaOperation op = new GriaOperation( vo, runnable );

  op.setAuthTokenRequester( "GRIA info service" );

  op.setAuthTokenPurpose( String.format( "No appropriate GRIA key store was found for fetching the applications from %s for the %s VO. Should a new one be created?", griaJobService.getName(), vo.getName() ) );

  op.syncExec();

  applicationList = ( String[] ) runnable.getData( "apps" );

}

 

The atomic operation here is jobService.getApplications(). It is executed in the run method of a GriaRunnable. The GriaOperation has to be created with the VO as parameter for which this operation should be executed. Furthermore the requester and purpose strings are set that will be used if the operations indeed needs authentication and no appropriate authentication token was created yet. In order to pass parameters to the GriaRunnable or to get back return values from it you may use the setData(…) and getData(…) methods (or use the final pattern for input parameters as shown here for the jobService).

 

The new AAI was exemplarily implemented for the fetch application stuff. What is missing (at least what comes to my mind) is:

 

-          EFS

-          Job submission

-          Job status retrieval

-          Other info service queries

 

Check carefully if your operation needs to have authentication. It turns out that many operations don’t. Nevertheless you should check this with various infrastructures and especially the BAE one since this is the most secured infrastructure we have access to.

 

If there are any questions or remarks feel free to shout.

 

Cheers, Mathias