Architectural Principles

As you may have seen in the Showcases section of this blog, NoTube foresees the implementation of three different use cases, each one leveraging on a subset of the platform features in order to highlight different aspects of project capabilities.

  • The integration of the three prototypes has been implemented following a top-down approach basing on the following main actors:
  • The NoTube user profile, seamlessly connected to personal social aspects;
  • The available platform services providing: metadata conversions, recommendations, enrichment, content ingestion, processing and streaming capabilities;
  • Specific requirements coming from the individual application scenarios focusing on different topics (News, Ads, social activities);
  • The availability of a semantic middleware capable of developing and providing services orchestration for specific goals.

How NoTube supported these contexts

Each technical workpackage involved in the project worked towards the creation of a unified platform by providing a set of flexible solutions enabling different integration possibilities. In particular:

  • Providing REST-based endpoints for the available services for direct invocation
  • Annotating services using RDF in order to make them available to the semantic broker
  • Defining a commonly agreed format for the input and output parameters with respect to a particular service category (i.e.: the recommenders, the enrichers, etc.)
  • Designing metadata conversion services on top of the elaborated models tailored to the broadcaster’s environments and needs
  • Quickly developing custom functionalities to enable the prototyping of new ideas and features

How the Architecture supported the work

Figure 1 – NoTube General Architecture

To allow agile development and prototyping and due to the sometimes specific requirements of the three use cases, the final technical choice for the services integration has been left to the prototypes’ developers by always providing two options:

  1. Leverage on the Business Process Choreography layer
  2. Directly invocating the NoTube’s platform services

The first solution is the most transparent for the application developer perspective since it provides a single entry point for accessing the NoTube services without having to know them all in detail, giving at the same time the possibility to quickly achieve the final goal. The drawback from a user perspective could be the slower performance produced by the semantic engine overhead, although this heavily depends on the orchestration workflow required by the application.

The second solution envisages the direct invocation of the requested services from the application logic. The developer must have a clear understanding of the specific service input and output parameters and formats as well as the communication protocol adopted (REST-based, as a commonly agreed architecture choice). There’s no orchestration here although there could be some contexts where the overhead introduced by the semantic layer is not justified.

As a final consideration it’s worth noticing that despite the level of freedom provided to the application developers for low level integration choices, in every application scenario (present and future) it’s envisaged:

  • To have a unique entry point for the user profile management, properly implementing the privacy protection mechanisms, and giving access to user details, preferences, interests, etc.
  • To leverage on a set of platform services in the preferred way (directly or through the broker)
  • To get recommendations, enriched contents, etc. transparently taking care of external repositories and different data formats via metadata conversion services
  • To ingest, process and stream contents regardless of the final output channel

But, at the same time, it’s also supposed to internally implement the business logic specific for the considered application, including the data exchanges with potentially existing CMS and repositories, even though the latter are fully enabled to be extended and empowered with NoTube capabilities. In the same way it’s left to the individual application developers to implement and customise the front-end for the considered scenario, including the support of different output devices, even though they are enabled by the platform itself to access streamed multimedia contents.

Challenges during final stage

The initial main goal of Workpackage 6 has been to design the platform general architecture in light of the R&D plans and achievements as well as the three use cases requirements focusing on the provider/home ambient vision and the interface with legacy CMS (already existing in the Broadcaster’s environments). As the project progressed year by year acquiring a concrete shape more details have been provided for the architecture allowing grouping services by categories semantically annotating them – supporting Workpackage 5, presenting a more mature integration approach description basing on lessons learned and technical feedback retrieved through the evaluation process and mapping such guidelines to the three integrated prototypes status.

The last year’s focus moved to:

  • The evolution towards use-case independency
  • Provide support for development and integration of new services
  • Analyse the NoTube adoption impact
  • Finalise the complete development of common modules

Sustainability of the platform after the project end has been the key factor here.

In parallel to that a set of dissemination activities have been performed advertising NoTube jointly with the project Consortium in well renowed conferences like IBC, NEM, etc.

The NoTube User Portal

In order to strengthen the above bullets even more, as a WP internal initiative neither promised nor mentioned in the Description of Work, the NoTube User Portal has been designed and developed.

Figure 2 – NoTube User Portal Homepage

This Web-based tool centralizes user profile management for both the end-users and the developers, thanks to a revamped Web 2.0 front-end and back-end, integrating modules from Workpackage 3 (for social activities connection)

Figure 3 – NoTube Portal Connections

The concept of “NoTube Application” together with the management of application-specific preferences has been introduced.

The privacy protection has been implemented through the adoption of explicit access consensus/denial to the user profile details by the end-user and the integration of widely supported Web standards like OAUTH.

Applications showcasing is supported and integration guidelines has been provided giving developers the possibility to either deeply integrate the portal back-end services into the application logic or just add a new application to the NoTube’s repository by simply providing a Web-based entry point.

Who’s involved? Polymedia (now part of KIT digital) together with The Open University, Vrije Universiteit Amsterdam, Institut fuer Rundfunktechnik, RAI Radiotelevisione Italiana, Pronetics, Ontotext and collaboration with other project partners.

Interested in collaborating with NoTube? Drop us a line and sign-up to our public mailing list (public-notube@few.vu.nl).

Click here for further information on architectural principles

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s