We are now going to start working on a more elaborate delegation example which uses two services:
PhysicsService: This is a new service we will program from scratch.
MathService: This is, in fact, the MathService with gridmap authorization. We won't need to make a single modification to this service.
In our example, PhysicsService will be responsible for undertaking an extremely complex calculation. For this, it will need to invoke MathService several times. However, there's a catch:
We will be invoking the PhysicsService from our user account. In my case, this account has a certificate with subject O=Globus,OU=GT3 Tutorial,CN=Borja Sotomayor
PhysicsService allows any user to access its methods. Therefore, the client application will have no trouble accessing PhysicsService.
MathService, on the other hand, only allows one user to access its methods. We'll be using the same service and gridmap as seen in the gridmap section, so this should be your user account (unless you've modified the gridmap file). In my case, my gridmap file only allows access to the user with subject O=Globus,OU=GT3 Tutorial,CN=Borja Sotomayor
This all means that, for the example to work, PhysicsService must invoke MathService using the O=Globus,OU=GT3 Tutorial,CN=Borja Sotomayor credential. Since PhysicsService is running in a container that has a different set of credentials (those of the globus user), PhysicsService will only be able to access MathService if the client application (run by the borja user account) delegates its credentials.
In fact, to show that this is all true, we will test PhysicsService without delegation and with delegation.
The following is an illustration summarizing the whole example:
As shown in the illustration, PhysicsService has a single method getAnswerToLifeTheUniverseAndEverything which will be invoked by the client application. This method, in turn, will invoke the add method in MathService several times.