1. Introduction

The GRIA 6 infrastructure is built on the Apache CXF Web Services stack. Building your Web Service using the GRIA 6 framework, rather than on CXF directly, means that your service automatically has the following features:

• A well-tested and user-friendly installation and administration interface, including:
  
• Keystore configuration and security setup.
• Database configuration (using flat files, MySQL or Postgres).
• A log viewer.
• An Atom-feed providing notification of administrative issues.
  
• A flexible access control framework (PBAC).
• Federation and management support (manage usage of your service using an SLA service).

Technologies

• Apache CXF for SOAP messaging.
  

• Spring IoC container and MVC web administration.
  

• JAX-WS annotations for services.

• JAXB annotations for data-binding.
  

• PBAC for process and role-based access control.
  

• WSS4J for message-level security.
• Hibernate for database persistence.
  

• Apache Neethi for WS-Policy support.
  

Differences between GRIA 5 and GRIA 6

In order to take advantage of newer Java and Web Service standards, we decided to transition GRIA away from the current Apache Axis 1.4 base and onto the newer Apache CXF web services framework. As the first stage of this process, we began writing the new CXF-based GRIA developer kit in 2008.

Some of the new features already available in GRIA 6 include:

• A more modular design, permitting security protection through PBAC and Federation policies to be defined and applied without changing the service code.
• Use of JAX-WS and JAX-B for annotating services and types.
• Configuration using the Spring framework.
• A more streamlined installation procedure.
• Maven archetype support, making it simpler to create new services.

A more modular architecture

GRIA 5 required services to extend the GridServiceLite class and to contain GRIA-specific code to handle SLAs and PBAC setup. The GRIA 6 framework is able to support existing services with no modifications.

The developer kit includes a simple "hello" sample service which is identical to the Apache CXF example service (it has a single "sayHi" method). It can be protected by PBAC, supports the NextGRID policy management operations, and can have a federation policy applied to it, all without any changes to the service API or implementation jars.

JAX-WS (https://jax-ws.dev.java.net/)

Sun's "Java API for XML Web Services" includes a set of Java annotations for describing services and operations (SOAP service name, namespaces, message style, etc). It builds on JAXB, an annotation-based mechanism for converting between Java objects and XML, replacing the Axis TypeMapping framework. JAX-WS and JAXB have been adopted by multiple web service frameworks, meaning that service interfaces developed for one framework can be used immediately with others.

Spring IoC (http://www.springframework.org/)

Like most modern software, GRIA's API makes heavy use of interfaces. This provides a great deal of flexibility by allowing the user to choose different concrete implementations of the interface at run-time.

GRIA 5.2 used a custom ImplementationFactory to set which concrete implementations should be used. In GRIA 5.3, we switched to the Spring IoC container for the client. Spring provides a flexible XML-based configuration syntax, while simplifying library code (which doesn't depend on Spring).

Apache CXF uses Spring extensively, so this configuration is now available for services too, and is used even more widely. In particular, the Axis .wsdd files for configuring service security have been replaced by Spring configuration files.

Service installation and administration

A robust and user-friendly installation procedure is a critical feature for web services, and GRIA 6 further streamlines the process. In particular:

• The Tomcat role "manager" is permitted to manage the application by default, saving one Tomcat restart in the common case.
• The database configuration page provides a web interface for configuring a MySQL or Postgres database, in addition to option of using a Hypersonic in-process database, as in GRIA 5.
• The service key-pair and self-signed certificate are generated automatically. If a custom keystore is required, it can be uploaded using the web interface. Also, signing the generated certificate is simpler, as you can download the Certificate Signing Request (.csr) directly, and upload the response (.crt). In GRIA 5, it was necessary to download and upload the whole keystore, using a separate client application for the import and export operations.
• No Tomcat restart is required after changing the configuration (except when enabling SSL in Tomcat the first time; this is a limitation of Tomcat).
• The log viewer can filter dynamically by threshold or thread, and entries can be expanded to show extra details (stacktraces and SOAP messages).

All the administration pages use the Spring MVC system to separate out the presentation from the business logic, and the JSP files use the newer JSTL templating language (rather than Java code).

Federation policies and SLAs

GRIA 5 expressed the federation requirements (e.g. the need for an SLA) by attaching a WS-Policy document to the service's WSDL. GRIA 6 takes this further by using WS-Policy to store the configuration too. This allows more complex policies to be expressed (e.g. "Operation Op1 requires an SLA at service S1 OR S2, Operation Op2 requires SLAs at S2 AND S3.").

Federation handling has been largely moved out of the service code and into separate CXF "interceptors" (equivalent to Axis "handlers"). This means that no changes are required to existing service code to support policies such as "An SLA is required to invoke this operation".

However, some modification to your code is required to report usage against an SLA, since the usage metrics recorded are service-specific. An interesting change here is that there is now a separate WS-Notification PullPoint for each SLA service. This makes it possible to manage one service with several SLA services. For example, you could have one SLA service managing business customers and another managing home customers, and then offer a service which allows users of either type to use it, with usage reports being sent to the appropriate SLA service. Finally, usage reports are now stored in the database until they are delivered, so they are not lost if the server crashes.

The federation security check ("is this user permitted to use this SLA?") and the WS-Notification usage reporting interfaces are compatible with the GRIA 5.3 SLA service.

PBAC security policies

Default PBAC policies for new resources are now configured using Spring. For example, if you want to create a new "auditor" role and ensure that everyone in the "auditors" group has this role on every new resource created, this can now be done without any changes to the Java code.

Testing

If you want to see what the service will look like without building one yourself, a pre-built sample war can be downloaded from our Maven repository:

http://altano.it-innovation.soton.ac.uk/maven2/release/gria/org/gria/gria-cxf-war/6-alpha1/gria-cxf-war-6-alpha1.war

Status

The GRIA 6 infrastructure should be considered as "alpha" quality. There may be changes to the APIs before the final release, and some features are not yet implemented. Known issues:

• WS-Trust token validation only considers X.509 certificates. It should also use any SAML tokens provided by the caller.
• There is no self-test to check that the service is configured correctly. There is also no test when adding a managing service that the provided end-point is correct.
• The service may complain that the "BC" security provider can't be found when installing the service. Restarting Tomcat will fix this error.
• The code does not currently compile with the new Maven 2.1.0; we have a fix for this on trunk, but it didn't make it for the alpha release. Please use Maven 2.0.10 for now.
• There is no graphical client interface at present.

If you'd like to help us test GRIA 6, please try creating a new service using the archetype feature (as described above). This will depend on the gria-cxf-6-alpha1 jars. The source code to the infrastructure is available from our public GIT repository ("gria-cxf").

Feedback can be sent to the gria-general mailing list, or (for private correspondence) to gria-support.

Next: Architecture