Do You Speak OCCI?

Posted March 5th, 2012 in News by admin

The doyouspeakOCCI Compliance Testing Facility is a Google App Engine (GAE)-based checking tool for the Open Cloud Computing Interface (OCCI) family of specifications. More specifically, it provides a full compliance test suite for the OCCI Core (GFD.183)OCCI Infrastructure (GFD.184), and OCCI RESTful HTTP Rendering (GFD.185)specifications.

doyouspeakOCCI is written in Python and heavily building on the GAE services, mainly Task QueueURL Fetch, and the webapp Framework.

Note that doyouspeakOCCI is not to be considered the “official” testing suite for OCCI endorsed by the Open Grid Forum, but rather than that, a third-party contribution which aims to be as close as possible. For a more thorough explanation, please take a look at the wiki pages.

How to Use

doyouspeakOCCI was hard to implement, but is simple to use. Just point your browser tohttp://doyouspeakocci.appspot.com, enter the base URL of your OCCI implementation, and press “Go!”.

Optionally, you can provide credentials for HTTP basic auth, if your service is secured. We strongly recommend to use a one-time test account; although we promise to use the credentials only for the compliance test, we cannot guarantee what others on the way (especially GAE) will do with them. In the near future, doyouspeakOCCI will support OAuth to ameliorate this issue.

Please note that doyouspeakOCCI records data on every test run in the GAE DataStore. This is done solely for the sake of displaying usage statistics. Within the limitations of applicable jurisdiction and the GAE Terms of Service, we will not disclose this data to anyone beyond what is being displayed on the doyouspeakOCCI web presence.

For other questions, please also take a look at the FAQ.

Where to Get

doyouspeakOCCI is available as a source code release only, which can be obtained by two ways:

Alternatively, you might want to pick one of the advertised downloads (click on the “Downloads” button in the upper right of the doyouspeakOCCI development home page at GitHub.

If you wish to run the service on your local system for testing purposes, please take a look at the doyouspeakOCCI Installation Guide for a detailed explanation on how to setup the environment.

Contributing

doyouspeakOCCI aims to be a community effort, and help is always welcome. Please contact us on the mailing list to learn more.

License

We think that doyouspeakOCCI should be available to everyone with the utmost amount of freedom. To make sure that contributions to doyouspeakOCCI itself remain perpetually free, the code has been developed under the GNU General Public License, Version 3. The documentation coming with doyouspeakocci is available under a Creative Commons Attribution Share-Alike 3.0 License.

Grokking OCCI Syntax: OCCI ANTLR Grammar

Posted February 29th, 2012 in News, Tools by admin

Interoperability is key belief in OCCI. The OCCI specifications set out in text how to implement the API and formats, however it is still up to our community and adopters to implement this. It is often the case when implementing a specification certain implementation decisions made can have an impact on an implementations interoperability. It is for this reason why this ANTLR grammar has been created (thanks to SLA@SOI) to aid developers in creating their parser. The ANTLR grammar specifies the text rendering format in an abstract language known as a grammar.

What?

The grammar defined, when used with the ANTLR tools, will generate a lexer and parser that will validate any valid OCCI text format. The grammar itself does not currently check whether a value associated with an attribute is valid. Rather it primarily ensures that the structure of the request is valid. It is still up to the implementer that service behaviours (e.g. correctly responding to HTTP GETs) are implemented correctly.

Why?

One of the key strengths of ANTLR, outside of its lexer/parser technology, is it has a wide range of target languages (18), so your favourite language has a good chance!  This is an important advantage as this enables multiple implementations of OCCI (client or server) to all share a the same rules that parse the OCCI text format, regardless of language.

The Goodies

There are two grammars currently defined, one based on the other:

  1. occi-antlr-grammar: this solely defines the grammar and does not contain any target language specifics. It can be used as the foundation of target language specific OCCI grammars. An example of this extension is the occi-antlr-java. This grammar can generate lexer and parsers, however they will only validate the input and not extract values from the supplied input. If extracted values are required, a very common case, then the occi-antlr-java grammar gives an example of this.
  2. occi-antlr-java: this extends occi-antlr-grammar to include target language specifics. The target language used is Java. In this grammar file there are Java-specific ANTLR actions that extract the values from a valid OCCI text request/responses.
  3. occi-antlr-ruby: this just like occi-antlr-java extends the occi-antlr-grammar to include ruby language specifics. This was contributed by GWDG.

There are a number of rules that are present within the OCCI grammar that can be reused in order to validate certain supplied values. This would describe a second pass parsing phase. In the case that an implementer would like to validate a URI value then they can do so by using this URI grammar.

The following presentation also goes through some details related to ANTLR and the OCCI grammar.

We hope you find this useful! If there are any problems, issues or suggestions open a ticket.

OCCI Compliance Testing Tool

Posted January 18th, 2011 in News by admin

The OCCI working group is happy to announce the availability of a test tool to verify OCCI implementations compliance with OCCI 1.1. Though still in development, we would really like to share this with the community and ask for help to extend the test and verify the test code.

Note: do be careful when examining the output of the tool, as a quote of Edsger W. Dijkstra (not to mention Heisenburg) states:

Program testing can be used to show the presence of bugs, but never to show their absence!

The following screenshot shows the GUI of the test tool (it also runs from the command line):

The source code can be found in the GridForge Source Code Repository: http://forge.ogf.org/. If you have any suggestions or comments let us know through the usual channels!