6. Other modifications

Create additional PBAC states

So far, our resource only has a ready state (besides the special UNINITIALISED-STATE and DESTROYED-STATE states). Create a locked state in the policy in which it is possible to unlock the resource and check its status, but in which the resource cannot be destroyed. You'll need transitions between the states (see the existing examples in the file).

You could then add lock and unlock SOAP operations (as above), which send the signals that cause the transitions; see the destroy operation for an example. However, an easier method is to make your resource (SampleResource) implement the Signallable interface. No other code changes are needed in this case, for either the client plug-in or for the service. You will, however, need to add signal:lock, signal:unlock and getAvailableSignals operations to the policy (sample-policy.xml).

Create additional process roles

To create a new role, simply use a different string in place of owner in the policy for some operation. Create a monitor role that can check the resource's counter but not do anything else. As the service administrator, you can control who gets the new role by clicking on one of the sample resources in the web interface and adding a new rule. See the PBAC administrator's guide for more information.

Add access control operations

Edit sample-policy.xml to grant the owner permission to use the actions getPolicyRules:monitor, addPolicyRule:monitor, and removePolicyRule:monitor. After redeploying the new policy using the web interface, you'll be able to manage access to your new monitor process role using the client.

Note: These operations are unusual in that the access control decision depends on the arguments, not just the method name. For example, we could allow a monitor to manage rules only for other monitors, but allow an owner to manage both types of rule. Therefore, these methods (implemented in the GridServiceLite super-class) have an @AccessControl(disableCheck = true) annotation and do their own access control checks using PDP.check(), appending the process rule to the end of the action (:monitor, etc).

Give the service administrator access to all resources using a group

After createSampleResource's addAccessControlRule call to give the owner access to the resource, add another rule giving the service administrator the service-admin process role, and update the policy to let the admin perform additional operations. Including the admin's details in every resource makes updating them all difficult if new admins need to be added later, so create a PBAC service-admins group and just add a match rule requiring membership of that group. See the documentation on the GroupUtils class in PBAC for details.

Add a new service

You can supply a collection of services in the same webapp, so that they share the configuration and database. To do this, create a new interface and implementation (corresponding to SampleService and SampleServiceImpl), add the mapping between them to src/webapp/WEB-INF/classes/implementationfactory.properties, and list the new interface in src/webapp/WEB-INF/server-config.wsdd. You should also copy sample-service-policy.xml for your new service, and give its initial version number ("1") in WEB-INF/classes/pbacpolicyversions.properties.

Extend or override the client stub operations

When we added the check operation to the interface we didn't need to write any code to actually invoke it in the client. If we want this method to do something more complex than simply invoking the SOAP operation then we can give a custom implementation in a new class, and give the name of this class using an annotation on the interface, e.g.:

@InterfaceWithWSDL(SampleResource.class)
@AdditionalMethods(SampleHelpers.class)
public interface SampleConversation {

Any method defined in SampleHelpers will be used instead of the automatically generated one. If you wish to add extra methods (not just override existing ones), then add their prototypes to the SampleConversation interface.

Finally, note that you only need to do this if you must add or override methods on SampleConversation objects (e.g. to maintain backwards compatibility). It is often better to invoke the helper class's methods directly, e.g. SampleHelpers.myHelperMethod(sampleResource) rather than sampleResource.myHelperMethod().

On the web-site you will find extensive JavaDocs for the sample service and the libraries it uses.

If you have any questions, please email GRIA Support.

Next: Upgrading from 5.1 Previous: Managing use of the service