Grokking OCCI Syntax: OCCI ANTLR Grammar

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.


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.


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.

An Open, Interoperable Cloud

A number of OCCI members have got together and have written this piece in on how an open and interoperable can be presented to end-users using today’s contemporary cloud standards, including not only OCCI but also CDMI and OVF. The article is the result of the excellent meetings had at the DMTF APTS back in May.

OCCI HTTP Rendering Spec Released

The OCCI HTTP Rendering specification defines how to interact with the OCCI Core Model using the RESTful OCCI API. The document defines how the OCCI Core Model can be communicated with and thus serialised using the HTTP protocol via RESTful semantics.

This is the last document in the v1.1 document series and is now available on the main OGF web site as document GFD.185.

Thanks to all that contributed content and reviews!


Dortmund’s Present to OCCI’s 2nd Birthday – An OCCI-libvirt Implementation

TU Dortmund University is proud to announce the official release of “OCCI4Java“, an open-source, Java-based implementation of OCCI on top of the libvirt Hypervisor Abstraction API on the second birthday of the OCCI Working Group. The first release offers a maven-based loose coupling of all three specification documents and supports all possible actions on compute resources and several actions on network and storage resources.

“After six month of intense work, we are proud to release our implementation to the public. During my collaboration with the OCCI-WG (especially Andy Edmonds and Thijs Metsch), I have gained valuable experience and had also a lot of fun.” says Sebastian Heckmann, responsible for the first maven project organization and the Core, Infrastructure and HTTP implementations.

The packages are structured along the specification documents (Core,Infrastructure, HTTP). This, along with the provisioning via Maven, allows the independent use of one or more modules in the context of other projects: other implementors can reuse either of the implemented parts, and interdependencies are automatically resolved and managed. Using this mechanism, the “Core”,”Infrastructure” and “HTTP” parts stack properly on each other. Implementation of additional flavors (i.e. new extensions for other use cases besides IaaS) can be done easily by extending the core mechanisms (such as a comprehensive action model), using software engineering best practices. The use of Spring as base framework technology ensures dynamic loading and thus loose coupling of the specific actions on infrastructure resources – third-party implementations plugin seamlessly via configurable run-time loading.

“It was a lot of work to implement every detail of the OCCI specification, but it was also a great pleasure to see that everything works.” says Sebastian Laag, responsible for parts of the OCCI and libvirt implementation.

Alexander Papaspyrou, co-author of the OCCI family of specifications, was pleased to see a complete implementation of all parts in such a short timeframe.

“The fact that two young developers are able to do a full OCCI implementation as part of a graduate student project in six months proved OCCI’s claim of implementation ease, and the enthusiastic feedback during their pioneering work helped the group to better understand idiosyncrasies in the specification text towards further improvement for future implementors.”

The release is available via GitHub and licensed under the GNU Lesser General Public License (LGPL). Feedback on issues with and improvements of the code, its documentation, or any kind of runtime problems is highly appreciated and can be communicated via the GitHub platform. If you want to join the team, please feel more than welcome to contact Sebastian Heckmann or Sebastian Laag.

Happy Birthday OCCI!

It was two years ago when the first official mail on the then new OCCI mailing list was sent. Since than the OCCI community had a steady grow and is still going strong! This is all the more appropriate given the release of OCCI v1.1 Core and Infrastructure specification documents. As a little special for today we have a celebration version of our logo:

We want to thank the designer of our official Logo since he was so kind to create this special birthday version for us.

OCCI Core & Models and Infrastructure documents released

Dear OGF Board and WG participants:

We would like to inform you that the Open Cloud Computing Interface Core & Models and Infrastructure specification documents, GFD.183 and GFD.184, were published today as OGF Proposed Recommendations and are now available for downloading on the site.

We are very proud of all of the accomplishments of all OGF work groups and of the entire OGF document series. Thank you for all of your work, regardless of the work group or area in which you are making contributions.

OCCI represents the work of a dedicated set of participants that deserves highlighting, however, and that opens up a significant set of opportunities for new work in OGF in the area of cloud computing. Here for your information is some of the text that we have been using in announcing the release of the first two documents in the series. The next document covering the HTTP rendering just completed its public comment period and should be completed and ready for publication shortly.

OCCI is a general-purpose set of specifications for cloud-based interactions with resources in a way that is explicitly vendor-independent, platform-neutral and can be extended to solve a broad variety of problems in cloud computing. The OCCI specification set is a product of the Open Grid Forum. OGF is a leading development organization for open standards in the area of distributed networking, computing and storage with an emphasis on technologies for large-scale distributed computing. OGF develops its standards through an open process that gathers input and contributions from the community and refines them through peer review and public comment to produce standards, guidance and information of value to the community through the Grid Final Document (GFD) series.

We are very proud of OCCI and think that it provides an important and timely set of contributions to cloud computing technology that is already gathering great interest and rapid evidence of adoption by a broad range of participants in the cloud computing community.

Congratulations to the OCCI working group and its participants. More information can be found on the OGF and OCCI working group sites at and http://occi-wg.orgrespectively. Please let me know if you have any further questions.

Alan Sill
VP of Standards
Open Grid Forum


OCCI and the UK Government Cloud (G-Cloud)

The United Kingdom Cabinet Office has recommended OCCI as the interface for use in the UK G-Cloud. This was detailed in a large volume of reports released this week by the UK Cabinet Office. In the reports analysis and strategies are set out on how the UK government should and will use cloud computing. Quoting the Technical Architecture Workstrand Report:
The recommended long-term solution is the OCCi, however at the time of writing the interface specification only loosely defines a protocol and does not contain a full API. Having spoken to the steering group of the OCCi it is clear that their intent is to create a fully open, patent unencumbered API for general use, which would be ideal for G-Cloud purposes. Further, there is an opportunity for the G-Cloud programme to influence the direction of development of the OCCi, which should be exploited.
It should be noted that at the time of the report’s writing (May 5th 2010) OCCI had yet to reach v1.0, but with the imminent release of v1.1 the group believes that is has significantly tightened and improved.
Of particular interest to us in OCCI is in the area of standardisation and APIs. Naturally for any government body investigating the use of cloud computing a highly important aspect to consider tactics and strategies to avoid costly vendor lock-in. Avoidance is accomplished by consumers demanding that vendors implement standardised and patent unencumbered interfaces, like OCCI, into their products and services. These reports should also be of interest and relevance to those people that are involved in the various United States based government initiatives such as those ran out of the National Institute of Standards and Technology (NIST).

OCCI 1.1 Document Series in Public Comment

As of today, all the documents for the revised version (1.1) of the OCCI document series are now in public comment. A lot of work by the OCCI community has gone into this revision so a huge “thanks!” goes out to all who have contributed to the many discussions on the mailing list, IRC, wiki and confcalls. This version paves the way to much exciting implementation work and plugfests in the upcoming months. If you would like to make comments and have your views heard and taken on board, now is an excellent time to do so. Simply:
  1. navigate to the public comments section on the OGF website,
  2. grab a copy of any or all the specification documents
  3. read the spec
  4. submit any comments, questions or improvements back to the public comments page (this can be anonymous if you prefer)

OCCI Compliance Testing Tool

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. If you have any suggestions or comments let us know through the usual channels!

You and Us, the OCCI Community

Want to join, contact and talk to us here at OCCI? There’s quite a number of options to use. As ever, the OCCI group is always hugely enthusiastic, welcoming and very supportive to people and groups of all types wishing to get involved with OCCI, whether that is through specification contributions or new implementations of it.

To dive in and chat with us:

Already part of the OCCI community? Then it might interest to you to know that we are always keen to receive contributions to this blog. If you have something you’d like to contribute then do shout out on any of the above communication channels!