Shaycock

OPENi Service Enablers

Authors: CGI
Date: 30/07/2013
Archive:

The definition of this set of Service Enablers has been based on D2.5 document and the decisions made in the last London meeting.
After changes in the architecture, some of these SE's will not be SE anymore, as they are considered now as platform components.
When we say that a Service Enabler defines an API we mean that this SE is accesible by a developer in order to make applications.
When we say that a Service Enabler is a core component we mean that this SE works internally within OPENi platform, performing mechanisms that helps the platform to function properly. Some other SEs are extra component that provide an added-value to the entire platform based on potential use cases.

Service Enabler Name Description Defines API for developers Is core component Comments
[Authenticator] The authentication component is responsible for confirming provided credentials of an individual as well as providing the individual with a digital identity and its associated rights. [Authentication SE API] Yes As per new architecture, Authenticator is not a SE anymore. Now it is part of the Cloudlet platform (Cloudlet Management Componets) as well as the API platform.
[Authoriser] The authorization component is responsible for verifying that the current identity of an individual has the required rights to access a resource (or object). If this is the case, it grants access to the resource. Policy based authorization component may gather an individual’s attributes (claims) and provide them to the policy engine for evaluation. It may then enforce the decisions of the policy engine (policy decision point). [Authorization SE API] Yes As per new architecture, Authoriser is not a SE anymore. Now it is part of the Cloudlet platform (Cloudlet Management Componets)as well as the API platform.
[Policy Engine] SE in charge of evaluating the policies that OPENi uses for making decisions regarding authorisation. No Yes If the Authorization component makes use of Policy Engine for making decisions, and given that the Authorization component is not a SE anymore as per new architecture, this element should not be a SE neither, accordingly.
[Context] (NTUA & Velti) SE in charge of referencing the context of each individual. This would help OPENi, beside to the policy engine, to make its decisions. Yes Yes This is included in Graph component within API platform and could be moved to Cloudlet [Context API]
[Cloudlet] This is the SE representing de cloudlet No Yes According to latest changes, this is now a component of the architecture, the Cloudlet platform. So this is not a SE anymore. I'm not sure if this component defines an API or not... [Cloudlet API]
[Monitor] (know as Logging, as well) SE in charge of monitoring the OPENi platform and OPENi applications. The monitoring process implies to have a log of the applications and platform activity. [Monitor SE API] Yes As per new architecture, this is not a SE anymore. Now it is part of the Graph API component within API platform, as well as part of the Cloudlet platform (Platform Management Components).
[Synchroniser] The synchronizer synchronizes content between cloud-based services and the OPENi platform. When a cloud-based service has new data the synchronizer updates the OPENi platform and vice versa. No Yes Potential SE for use case.
[Pusher] Similar to Synchronizer SE but this is front-end service and can be used by developers. [Pusher SE API] Yes Potential SE for use case.
[Scheduler] The scheduler can be used to register a call-back for certain events or pre-defined conditions. When the condition is met, a call is initiated to inform applications (and process or push data). Yes No Potential SE for use case
[Announcer] The announcer is a multi-channel information platform that informs individuals about changes or recommendations. The information may be presented via Mail, SMS, the OPENi website or other channels. Yes No Potential SE for use case
[Mediator] The mediator is responsible for connecting users and developers. It provides a data centric discovery and analysis platform for users and developers. For example, it is able to inform developers about the number of users who are currently exposing a set of personal data (e.g. age, sex and family status) so that they can optimize their requirements. It also shows applications to users based on their currently exposed data and data they may be willing to expose. Yes No Potential SE for use case.
[Recommender] The recommender recommends a variety of things. It recommends applications to users or advertisers to developers. It also exposes recommendation features to developers. Yes No See Recommendation SE (NTUA) below.
[Market] A market is a generic component used to sell and buy goods, advertisement space or virtual items. Yes No Additional SE
[Data Processor] The data processor transforms data. It is responsible to convert data from one format to another. Transformations could be registered based on mime types and other attributes of the data. Yes No As per new architecture, this wouldn't be a SE anymore. This is part of the Graph API, the API Mapping component, within OPENi API platform. It could be also moved to Cloudlet component.
[Analyser] The analyser is responsible for analysing Yes No See Analytics SE (Betapond) below.
[Health SE (CGI)] The Health SE will offer to an OPENi user the chance of getting information about his/her visits at different Healthcare Organizations Yes No Potential SE for use case. Legal restrictions
[Biometric Comparison (CGI)] The Biometric Comparison SE for user identity management is intended to provide a comfortable and safe way to perform identification onto de system. The main advantage consist of avoiding passwords' handling. However, the major constraint stems from the dependency on the HW and the possibility to embed it on the devices. Yes No Potential SE for identification management. HW restrictions
[Cryptography SE (CGI)] This SE is intended to provide an extra functionality capable of encrypt properly data transactions as well as the data stored in the cloudlet. Yes No Based in Open Source existing implementations.
[Compliance SE (Velti)] One of the key issues with APP development is ensuring that the data retrieval doesn't break any policy laws as they may change during the lifetime of the app. It has been hightlighted at FIA the cost involved in maintaining this. Yes No
[Recommendation SE (NTUA)] APP developers would benefit from having a common Recommendation Service Enabler that allows them to plug in into their application. This SE will capture data on the performance or utility of their APP by the user. It makes this data available for further recommendation techniques. Yes No
[Timeline SE (Ambisense)] The Timeline SE aggregates the cloudlet data and the Cloud-Based Services data to summarise the user's identity (e.g. activities, data and metadata) over all connected channels into a temporal view. It is exposed to the app developer and enables him the data and events without the need to access the actual data in real time. A timeline can provide different granularity levels (e.g. only metadata) to further the user's privacy. Yes No
[Loyalty Rewards SE (Ambisense)] APPS will look to take personal user's data for use in a campaign or for data mining purposes. This SE allows apps to sign up to a common rewards scheme such as StarAlliance or the One4All card, that are used in Ireland. Yes No
[Analytics SE (Betapond)] APP developers would benefit from having a common Analytics Service Enabler that allows them to plug into their application. This SE will capture data on the performance or utility of their APP by the user. It makes this data available for further analytic techniques. [Statistics] No

Related

Wiki: Statistics
Wiki: Pusher SE API
Wiki: Monitor SE API
Wiki: Cloudlet API
Wiki: Context API
Wiki: Policy Engine
Wiki: Authentication SE API
Wiki: OPENi Service Enablers as per architecture changes and decisions made in London meeting
Wiki: Home