OPENi Graph API Phase II – From visualization and design to implementation

By Iosif Alvertis, Michael Petychakis, & Fenareti Lampathaki (NTUA)

It’s been a while since our last post about the API analysis, but it was a quite busy period for us to implement and test what has been designed during the first year of the project. During the last months, we have ended with a concrete definition about what a Graph API is; during our analysis on APIs Cloud Based Services and our study on existing research, no clear definition was available. Thus, combining existing research, empirical research and services modeling, we ended up with the following definition:

“A Graph API is a RESTful, user-centric, hypermedia API that organizes web resources under a unified meta-model of Objects, Aggregations of objects and Connections towards them which are created by users. It is based on a common dictionary and it includes a minimum set of properties in order to reduce time and cost of connection and integration with other APIs.”

In other words, when browsing an object, it should be clear for the developer how he should navigate through connections, through the response of the API itself, following the basic rules of how Objects, Aggregations and Connections are related.

Within the final definition and specification of the Graph API, the analysis of the Cloud Based Services (CBS) continued with a detailed, updated specification of the Generic APIs incorporating feedback from the OPENi platform implementation. In principle, the Generic APIs are categories of objects that provide similar objects and combine objects from related Cloud Based services. So far, the recognized categories are: Profiles API, Activity API, Location API, Media API, Products & Services API and Communication API. In the following figure, the CBS APIs are grouped based on how they have been mapped to objects of our Generic APIs (although there are cases in which a CBS API like Facebook spans more than 1 Generic API and in which more services and protocols have been studied, like Amazon and eBay modeling for the Product & Services API, or the XMPP protocol in order to model the Communication API, yet they have been excluded from the mapping due to the limitations put from such API methods and the need to give an object-based, RESTful API).

OPENi Graph API and Cloud-based Services 

In this direction, the Generic APIs were integrated in the broader architecture of the project. In the figure below, it is visible how each Generic API is related with the Cloudlet API, the Context API (i.e. giving additional metadata on Graph API objects), and the Service Enablers that provide advanced logic to the OPENi platform. All these APIs together compose the OPENi API Framework, which can be described as:

OPENi API Framework is the whole set of different APIs used by third party developers to build their applications over an OPENi platform.”

OPENi Graph API Framework

OPENi Graph API Framework

It’s definitely a long way towards an interoperable and clean design of modern services, even if REST as a protocol has significantly contributed in that direction. It is mainly a matter of proper design, agreed and followed by the community, to keep such services transparent and reusable. For that reason, we are planning to make available the detailed modeling performed on our Generic APIs, through the OPENi platform during the next months, in order to gather feedback and allow the community to validate, extend and reuse our work.

Finally, the Graph API is implemented in the integrated OPENi platform through the OPENi API component, which is addressed to developers and applications and constitutes the central point of reference for the OPENi API Framework at design time and runtime. The OPENi API Platform serves a two-fold purpose:

  • To ensure that developers have access to the API documentation in which they are interested and may extend it according to their needs.
  • To handle all requests from OPENi-enabled applications that utilize the OPENi API Framework.

Relative blog posts will follow, with instructions how to use the OPENi API platform and some demo applications.

More details are also available in our deliverables and, in particular, in OPENi APIs Specification – Phase 2 (D3.4) that will be soon publicly available! In the meantime, you may have a look at the draft OPENi APIs Specification – Phase 1 (D3.1).


Note: We are excited to announce that our work and research on a Graph API has been accepted in: (a) AICCSA’ 2014 and will be presented on November 10-13, 2014, in Doha, Qatar, under the title ““A Community-based, Graph API Framework to  Integrate and Orchestrate Cloud-Based Services”, and (b) PROVE-2014 and will be presented on October 6-8, 2014, in Amsterdam, under the title “Enterprise Collaboration Framework for Managing, Advancing and Unifying the Functionality of Multiple Cloud-based Services with the Help of a Graph API”.

1st OPENi Hackathon in Athens on September 12th-13th, 2014

The 1st Hackathon “Mobile Apps: From inspiration to implementation with… OPENi Cloudlets and APIs!”, organized by the OPENi Project, will be held on Saturday September 13th, 2014 in Innovathens, Peiraios Str. 100, Gazi, Athens, Greece.



OPENi Platform Overview

By Dónal McCarthy (TSSG)

OPENi isn’t all about APIs, in fact the OPENi Platform is composed of four major components, only one of which is the API framework. The three others are 1) the Cloudlet Storage framework which is responsible for storing users’ data, 2) the Security Framework which handles authentication, authorisation, and much more, and 3) the mobile client libraries which provide generic building blocks that allow the development of applications that utilise OPENi services.

As outlined in previous blogs the OPENi API framework will be capable of interoperating with a variety of cloud-based services. It will abstract the integration challenges to a single open standard without losing any service features. It is our belief that it will promote innovation by offering application developers an advanced framework that enables them to design and build complex applications involving the combinations of independent cloud-based services.

The OPENi cloudlet storage framework will provide application consumers with a single location to store and control their personal data. With control mechanisms that are inherently secure and trustworthy it empowers the consumer to remain in control of their data. As an open technology, the OPENi Platform will be validated by the open source community, therefore consumers are afforded greater confidence that the data stored in their Cloudlet is not being used without their consent when compared to closed-source alternatives.

The OPENi Security framework contributes the security and privacy mechanisms to the overall Platform. The features that it provides are authorization, authentication, fine grained sharing and access control, and data encryption.

To provide convenient access to the OPENi APIs and cloudlet storage we will provide a mobile client library. This library will abstract and simplify access to the OPENi services across multiple mobile platforms and will take the form of a lightweight developer SDK. This library will be designed to promote rapid application development and easy developer on-boarding.

The combination of these four components creates a powerful platform which is beneficial for consumers, application developers and service providers alike. The vision for OPENi is to provide a platform that could be deployed and operated by many different application hosting or service providers looking to add value to their existing offers. These ‘OPENi hosting providers’ will take advantage of various facets of the OPENi platform in ways that best suit their business model.

To accommodate hosting providers who wish to use a subset of OPENi’s full complement of components we have structured the Platform as a number of discrete services, each one capable of functioning on their own. The Cloudlet Storage framework can serve mobile applications that do not utilise the OPENi API framework; likewise the API Platform’s integration with Cloud Based Services and Graph API can function just as well with another data storage mechanism. To extend this idea further both frameworks could use a 3rd party security frameworks once they are API compliant with OPENi’s. It is important to remember that this is a logical separation, of course all components work best when used together.

OPENi API Framework (Part I): Studying the landscape of cloud-based Services

By Iosif Alvertis, Michael Petychakis, & Fenareti Lampathaki (NTUA)

Today, an emerging trend to expose functionalities through publicly available APIs (Application Programming Interfaces) has not only redefined how software and services are delivered, but also indicates how business value is moving towards a thriving high-paced mobile application ecosystem. Along these lines, the OPENi focal research contribution lies on the cloudlet concept and on an open API framework that will be capable of interoperating with any cloud-based service, abstracting the integration challenges to a single open standard without losing any service features.

During the first months of the OPENi project, we docused on an analysis of the underlying state of the art in the cloud-based services landscape in order to provide concrete recommendations and guidelines to drive the forthcoming design and implementation of the OPENi APIs Framework.


Mobile Cloud Analysis: Introducing the Cloudlet Concept

By Leigh Griffin, Lukasz Radziwonowicz, Dónal McCarthy, Robert Kleinfield and Eric Robson

Attitudes towards computing have changed dramatically in the last ten years with technology becoming affordable and more mobile, bringing about a generation of technology savvy users. The availability of technology is complemented by advances in the underlying network, with consistent connection speeds and coverage reaching saturation levels. This has ensured a smooth experience for users and consequently expectations about what technology can do for a user’s life have risen. This expectation has been facilitated by a multi-billion dollar industry, delivering applications and services for user consumption. This industry has culminated in the rise of modern social networks, instantly connecting friends and family regardless of geographic location and allowing a heretofore unseen level of interaction.  Users are therefore offered a plethora of applications and services to meet their demands. This choice can cause confusion around where their data is stored and what provider may have access to it