Hi Thomas, Congratulations on the new release! Got an ETA on the source and DevKit?
Cheers, Rowland On 1 Aug 2008, at 18:09, Thomas Leonard wrote: > 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-0115-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/services/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. > > > -- > Dr Thomas Leonard > IT Innovation Centre > 2 Venture Road > Southampton > Hampshire SO16 7NP > > Tel: +44 0 23 8076 0834 > Fax: +44 0 23 8076 0833 > mailto:[EMAIL PROTECTED] > http://www.it-innovation.soton.ac.uk > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > gria-general mailing list > gria-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gria-general ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gria-general mailing list gria-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gria-general
