Airavata provides capabilities for an integrated workflow and data management system. The information and data has to be persisted into a registry service. To adhere to the philosophies of Airavata for layering over existing stable third party components, Airavata usage is consolidated into a thick-client API. This API allows the pluggability of the infrastructure and avoids locks in into any specific registry architectures. This following figure summarizes the use of the registry.
The Content Repository for Java Technology specification, developed under the Java Community Process JSR-170, aims to standardize Java API to repositories. The specification provides a unified API under the javax.jcr namespace that allows you to access any specification-compliant repository implementation in a vendor-neutral manner. A major advantage of JSR-170 is that it is not tied to any particular underlying architecture. The back-end data storage for a JSR-170 implementation, for instance, may be a filesystem, a WebDAV repository, an XML-backed system, or even an SQL database. Furthermore, the export and import facilities of JSR-170 allow an integrator to switch seamlessly between content back ends and JCR implementations. Finally, the JCR provides a straightforward interface that can be layered on top of a wide variety of existing content repositories, while simultaneously standardizing complex functionality such as versioning, access control, and searching. There are open source implementations of JSR-170 such as Apache Jackrabbit, Alfresco and WSO2 Registry.
Airavata Registry API
When implementing registry functionality to store data and retrieve data we did not want to have locking for any custom API's to content repository implementations. Airavata tried to integrate with existing repositories without having to re-invent the wheel. JCR-2.0 specification and the JSR-170 implementation is plugged in to Apache Airavata system. The Airavata specific API layers over the generic JCR API and is integrated with Apache Jackrabbit implementation. The API is modularized as a common component reused by XBaya and GFac components to store and retrieve data. In addition to the service information, the registry is used to catalog workflow consumed inputs and generated output data. The registry is also used to advertise and retrieve persistent service information. The use of the registry for GFac service registration allows for late service binding and supporting large number of applications provided by the inherent load balance capabilities. For more up to date information and samples on Airavata API, refer Client API Overview.