Personal tools
Document Actions

7. Upgrading from 5.2

Up one level
This guide is for people who developed services using the 5.2 developer kit and who wish to update their services to use the 5.3 framework.

GRIA 5.2 to 5.3 developer kit migration guide

This guide is for people who developed services using the 5.2 developer kit and who wish to update their services to use the 5.3 framework.

Note that GRIA is compatible at the SOAP layer between these versions, so there is no need to upgrade just to interoperate with the newer services. However, upgrading may simplify your code or give access to new features.

If your service was developed using the 5.1 developer kit, then please first follow the 5.1 to 5.2 migration guide first.

Update to new client API

REQUIRED

The 5.3 GRIA client API has changed considerably. Whenever your service acts as a client to another service (for example, when contacting an SLA service) it will need to use the new API. See the 5.3 client's release notes for information about these changes.

Web service annotations

REQUIRED

The @WebServiceWSDL annotation has been replaced by the very similar @WebService annotation. This is for consistency with JAX-WS.

PBAC interface

REQUIRED

The PBAC interface has been updated slightly to use PolicyRule instead of MatchRule objects. The service was already using the newer types internally, so this should simplify the code.

Your implementationfactory.properties file must be updated to use the new method for instantiating the PDP. See the example provided.

Client plugins

REQUIRED

The client plugin system has been split into two parts: SampleClientPlugin (for low-level SOAP code) and SampleClientPluginSwing (for extending the client GUI). You will need an extra .Provider file for this. The interface for the Swing plugin has also changed; see the client documentation for details.

The way additional helper methods are defined has also changed. See HelperProxyFactory for details of the new system.

Security handlers

REQUIRED

PBAC now includes the new resource state in each SOAP response. Add ResourceState to the list of elements to sign (see the example server-config.wsdd).

Also, set the additionalSignedHeaders parameter; this is no longer hard coded (again, see the example).

Finally, add this to your web.xml to ensure the SSL handlers are configured:
    <listener-class>uk.ac.soton.itinnovation.grid.service.utils.HTTPSSocketListener</listener-class>

New SOAP operations

OPTIONAL

The new getServiceMatchPattern operation should be added to the PBAC policies for SampleService and SampleResource. This is for the new IdentifiableResource interface.

Powered by Plone CMS, the Open Source Content Management System