[geclipse-dev] GRIA 5.3 released

["Ken Meacham" <kem@xxxxxxxxxxxxxxxxxxxxxxxxx>]

GRIA 5.3 is now available for download:

  http://www.gria.org/downloads


Overview of changes in GRIA 5.3 (since 5.2)

The main goal for the 5.3 release is to improve support for client
application integration (e.g. portals) and for complex federation
scenarios.

Some client applications provide management of multiple different users.
For example, a "portal" providing a web interface to GRIA that is
accessed using a normal web-browser. When the portal invokes an
operation it does so on behalf of a particular user and needs to take on
the identity of that user. This means that we need to be able to set the
identity of the client dynamically on a per-invocation basis (rather
than statically in the crypto.properties file).

An example of a complex federation scenario would be a client creating a
new job, quoting an SLA with the provider of the job service (granting
them access to CPU time) and a second SLA with the software vendor
(granting them a license to use the software). In GRIA 5.2, the client
can only select a single SLA when invoking a service.

Another example would be access to some resources that are shared
between many organisations (e.g. access to a database). The policy rule
on the shared resources would state that anyone with a SAML token
asserting that they are in the group of permitted organisations is
allowed in. We support that already, but in addition we would like the
rule on the SAML-issuer service to state that anyone can get a token if
they have another token from their own organisation stating that they
are a member of the organisation. This scenario allows each organisation
to manage its own members. This chaining of tokens is not supported in
5.2, requiring the client to get the first token manually.

The new capabilities were requested by GRIA users to allow them to
support new business models, improve overall B2B flexibility and provide
better vertical integration with existing tooling. However, implementing
these features has required incompatible changes to the 5.2 Java API.

GRIA has always had a policy of maintaining SOAP-level interoperability
between minor releases (e.g. 5.0, 5.1 and 5.2 clients and services can
all talk to each other) and 5.3 will remain compatible here.

We have also had a policy of keeping good Java API compatibility, so
that code written for the 5.0 API can be recompiled with minimal changes
on 5.1 and 5.2. For 5.3, the required updates to client code are more
substantial than usual.

While making these changes, we have also taken the opportunity to remove
some legacy interfaces that have accumulated over the years and to make
the code more modular.


Changes affecting all GRIA services

- When services act as clients to other services, they can now be
  configured to include federation contexts and attribute tokens in the
  messages they send. This is useful for some complex deployment
  scenarios.

- To simplify renaming of services, there is a new PBAC group called
  "special:this-service", which always holds the identity of the current
  service. If you use this in PBAC rules, then you will not have to
update
  the rules manually if the service's identity changes. The default
rules
  created during installation all use this group.

- A new type of access control rule, "NECESSARY" has been added,
  allowing more complex policies to be expressed.

- All SOAP operations now return the new resource state in a SOAP
  header. This makes it easier for the client to display up-to-date
  information.


Changes to the Basic Application Services package:

- The Data Service now exposes a REST interface, allowing clients to
  manage data using plain HTTPS GET / PUT / DELETE operations. This is
  considerably more efficient than using SOAP-with-attachments, and also
  works with non-SOAP clients.

  To upload, you can use any standard HTTP client, such as Curl. e.g.

    $ curl --cert me.crt --key me-private-key.pem -T file-to-upload \
 
https://myserver/gria-basic-app-services/data-stager/ff808181-152215bf-0
115-221982b5-0002


Changes to the Service Provider Management package:

- Exporting and importing SLA templates has been improved.

- The SLA template display can now display multiple constraints on a
  single metric.


Changes to the Client Management package:

- A new Active Directory (Kerberos) single-sign-on service has been
  added to the client management package. This service issues X.509
  credentials based on users' local Kerberos or Active Directory
  credentials. For example, a user can log in to their Windows desktop
  by entering their Windows username and password as usual, and then
  automatically be issued with an X.509 certificate which they can use
  to access remote resources.

- The old Private Account Service has been removed. You can use the
  Membership and Registry services together to get a similar effect.


Changes to the GRIA client:

The bulk of the changes in 5.3 are to the client API. One exciting new
feature is built-in support for Groovy, a scripting language with a
Java-like syntax. For example, the following script will upload the
"source.jpg" file, process it with the "paint" application on griademo1
and then download the result:

def GRIADEMO1_JOB_SERVICE_WSDL =
"https://griademo1.it-innovation.soton.ac.uk/gria-basic-app-services/ser
vices/JobService?wsdl"
def JOB_TYPE = "http://it-innovation.soton.ac.uk/grid/imagemagick/paint";
def jobService =
serviceFactory.createServiceProxy(GRIADEMO1_JOB_SERVICE_WSDL)
def swirlJob = jobService.createJob(JOB_TYPE, "My swirl job")
swirlJob.input("inputImage").saveFromFile(new File("source.jpg"))
swirlJob.startJob(null)
while (swirlJob.stillActive()) {
        println "Waiting..."
        Thread.sleep(1000)
}
swirlJob.output("outputImage").read(new File("result.jpg"))
swirlJob.destroy()

To try it, save the script as "paint.groovy" and then run the client
like this (you'll need a "source.jpg" file too, of course):

$ gridcli ./paint.groovy

The above script also demonstrates the new API. "serviceFactory" takes
the URL of a service's WSDL and creates a proxy for it. Notice that,
unlike the 5.2 API, 5.3 does not require you to store the proxy in a
repository.

For a longer introduction to the new API, see:

http://www.gria.org/documentation/5.3/tutorial/java-interface-tutorial

JavaDoc for the API is available here:

http://archive.gria.org/javadocs/5.3/

Other highlights include:

- A new security configuration system gives you the option of using
  a local keystore or your Windows credentials. Settings are now stored
  using the Java preferences system, which puts them under
  ~/.java/.userPrefs by default (or in the Windows registry on Windows
  systems). Note that use of single-sign-on with Windows credentials
  requires an installation of the GRIA client management package within
  your organisation.

- A flexible new IdentityProvider API allows you to control exactly
  which identity should be used for each remote operation. This
  replaces the static crypto.properties file with a selection of
  providers (including single-sign-on with Kerberos / Windows Active
  Directory, and support for writing web portals with multiple
  concurrent identities).

- Selection of federations (such as SLAs or trade accounts) and tokens
  (e.g. SAML attributes) to be added to SOAP messages is now handled by
  the new InvocationEngine system. This can be configured to support
  very complex scenarios (such as a job service that requires an SLA,
  which in turn requires a membership token for a group, which can only
  be obtained using a membership token from another group, and so on).

- A new plugin system. There are now two separate systems: one for
  extending the proxy system (such as adding support for a new type of
  service) and one for extending the Swing user interface. This allows
  proxy plugins to be used on headless systems (where Swing cannot be
  initialised). The new GridClientPluginManager makes it easy to
  load GRIA plugins from your own applications.

  Also, there is a new AbstractConversationBrowserPlugin base
  class which plugins can extend. This avoids the need to implement
  methods which you don't care about, and ensures that your plugin will
  still work on newer versions of the client which define additional
  hooks. Note that the methods plugins must implement have changed. The
  base class defines all the methods in the old API as "final" so you
  will get compile-time errors if you forget to update anything.

- Support for running within .NET, using IKVM.


Quick API FAQ (for people used to the old API):

Q: What replaces StateRepository?

A: A StateRepository created and stored proxies to remote resources. It
   has been split into two separate systems:

   To create a proxy, use a ServiceFactory (if you have a WSDL URL) or a
   ProxyFactory (if you have an EPR). ServiceFactory uses a ProxyFactory
   internally.

   To store EPRs for later, use a PersistentRegistry. Note that this
   stores EPRs directly, not proxy objects.

Q: Where do I put an SLA so the InvocationEngine can find it?

A: The InvocationEngine has a search path of Registry objects. Ensure
   this list includes a registry with the SLA. The registry may be
   local or remote. Also ensure that you have set a
   DefaultFederationSelector object on the InvocationEngine. The
   default Groovy environment has this all configured for you.

Q: I'm writing my own GRIA client application. How do I configure all
   these objects?

A: Have a look at the client-beans.xml file inside the gria-client-cli
   jar. This is a Spring configuration file which contains the default
   configuration for the GRIA client.


Known issues:

- Storing user preferences for the client doesn't work on some older
  versions of Java 1.6 on Linux. You can either use Java 1.5 or newer
  versions of 1.6.

- On MacOS X, the platform scripts for the Job service must be modified
  slightly, as the default ones rely on some GNU extensions which are
  not present on this platform.


Ken Meacham
IT Innovation Centre
2 Venture Road
Chilworth
Southampton, SO16 7NP, UK

tel: +44 23 8076 0834
fax: +44 23 8076 0833

mailto:kem@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.it-innovation.soton.ac.uk/