SEEK

Yes, I think we should modify the level I interface. I also think we should
modify the get and query operations to take a sessionId, rather than creating
two new operations. In this case, if a client wanted to query anonomously, they
would pass a 'null' value for a sesssionId. Or I suppose they could be required
to login using a reserved username that symbolizes 'anonymous' (e.g., 'public')
and that doesn't require a password, then use the resulting sessionId. This
would be nice because it would mean a valid session is available for every
EcoGrid connection, whether anonymous or authenticated, which makes for a nice
place to store and cache things about the session (such as query results) on the
server side. I think there are arguments for having anonymous get(id) be
separate from authenticated get(id, sessionid), but I think its better to only
have one method.

An alternative approach is to pass the GSI credentials in the HTTP header or in
the SOAP envelope using e.g. WS-Security standards. This would be an
alternative to modifying the individual data access methods. However, we need
to remember that at least some of the methods will have only HTTP bindings (not
SOAP bindings) for use when transferring large data sets. I'm not sure if
WS-Security would meet our needs in this context, but a modified HTTP header
might work for all scenarios.

Bug #2276 describes the intial research into this that must eb completed before
we can decide how to pass the certificates to the services.

We've decided to make an entirely NEW service to handle the authenticated versions of the get and query operations:

AuthenticatedQueryService (http://ecoinformatics.org/authenticatedqueryservice-1.0.0)
query
get

this has been implemented and deployed as part of ecogrid-1.0.0
and is included in the kepler 1rc1 codebase

Original Bugzilla ID was 1694