Challenge Overview
Project Overview
The Hercules Player University apps are a suite of applications (web, iOS, and Android) that allow students on various Universities to get their content delivered over the IP network. This content includes linear (live TV) and “on demand” content from various providers.
Right now, the data for On Demand videos comes from a service called Columbus. The client has asked that we replace this Columbus service with a new service that we build and control that uses a client system called NGB and another client system called Rex.
Tips for success
• Asking questions early and getting the copilot's feedback is very important for the success of this architecture competition. This is a complex architecture. NGB and Rex contain a ton of functionality, so make sure to start on this architecture early.
Competition Task Overview
This architecture will define the following:
A new service for pulling On Demand data for the clients that uses NGB and Rex.
This new service will include REST endpoints for:
Retrieving the root folder of On Demand
Search all On Demand
Retrieving a specific folder path (either a branch or a leaf node) of On Demand resources
Retrieving a single On Demand resource
Services
The native device application will access the data directly through these new services. The client applications will call TomCat REST endpoints on our bridge server. This server will then make the requests to the client services, aggregate the results, and send the data back to the client as JSON, for easy parsing.
This architecture must formally define:
1) The REST endpoints that will be created
3) The data format of the return data from the bridge server to the clients
4) The calls from the bridge server to the backend services
Note that we already have a bunch of bridge services developed and working, including services that access the existing Columbus service. If we can keep the same request and response values and just swap out Columbus for NGB and Rex, that would be preferable and allow us to not have to touch client code, but that is not a strict requirement.
Please make sure to clearly document if the clients will have to change and what those changes will have to be. We don’t need formal documentation on the client changes at a low level, but a description of the differences between the existing REST services and the new REST services would be useful.
Existing implementation
In the forum is a link and login details for the existing, working site. Once logged in, click the On Demand tab at the top and you’ll see the list of resources. Note that this is the “root” level of the On Demand data
Each individual row is a sub-folder (Movies, TV, News, Sports & Fitness, etc…). Each shows the top 5 “trending” videos and a “View All” link.
When the user clicks one of the trending videos, they are brought to a page just for that single video where they can see video details and choose to watch the video.
When the user clicks “View All”, they are brought to a new “folder” underneath the On Demand root.
In the forum is sample URLs for Columbus so you can see the root data and how folders are retrieved.
The forum also contains the existing Quantum Bridge codebase. The current Columbus integration happens in the SamsungHelper, SamsungRecordingService, SamsungRecordingsService and SamsungSearchService classes in the code.
Pagination
Pagination is an important aspect of the services, especially as we get to the leaf nodes of the folder structure. Once you hit a leaf, the data returned is just the full list of videos, which can be hundreds and hundreds of records. To make the display easier on the client and faster to retrieve, the data coming back is paginated - see the per_page and page values send into the SamsungRecordingService servlet. The search results from SamsungSearchService can also be paginated.
Caching
The existing implementation will cache data as it is retrieved, making things quicker for the client. The new implementation should do the same. We can use Redis and the MerlinDataCache - you are free to change the MerlinDataCache as necessary. Just make sure to add new functionality, but don’t take away or edit anything that is used outside of the On Demand data.
Data returned
One of the data points returned is a “locator”. This locator is a URL passed to the client player to actually stream the video and display it on the client platform. There are two separate locators - HDS and HLS. HDS is used on the web and HLS is used on the iOS and Android platforms. We need to ensure that the locators are retrieved and sent to the client as appropriate. Right now, we use two separate endpoints on Columbus - /roku for HLS and /samsung for HDS. The servlet calls the appropriate endpoint based on the user agent of the request sent. If the user agent is a mobile platform, it builds the Columbus call using the /roku endpoint and if the user agent is a desktop browser, it builds the Columbus call using the /samsung endpoint configured in the build.properties file. You don’t have to use this same pattern, but we need to ensure that the correct locators are properly sent down to the client.
Location ID
The different Universities receive different content depending on a lot of different contracting and licensing factors that we don’t control. We currently pass in a locator ID to the Columbus endpoints and Columbus uses the location ID given to filter the data down to only the data that should be seen on a particular campus. We will use the LocationID in calls to NGB and Rex to do the filtering. We shouldn’t have to do much more than just pass it along as we get it, but we must ensure that it’s required on every call and if we don’t get the location ID we should just return an error.
Errors from the client backend services
All errors from the client backend services must be passed down to the client for display. This is currently implemented in the other servlets - we should follow the same pattern. Look at ChannelShowingService and how it creates the resultObject using ServletHelper.createFailureResponse if the backend service call fails. When we do this and send it to the client, the client brings up an informative popup to the user that helps us track down the failing service. We need to properly differentiate between Rex failures and NGB failures.
NGB
NGB is laid out in a tree structure, with a root, branches, and leaves. The root and branches are pulled from MWS and the leaves are pulled from REX. The root element does not have any leaf nodes, thus no REX urls. NGB is comprised of 2 client-facing services (there are multiple backend services the client does not need to interact with):
1. Menu Web Service (MWS)
2. REX Browse Service
Much more details are available in the forums.
Submission Deliverables
• Application Design Specification
• Sequence Diagrams
• Interface Diagrams
• Assembly specification(s)
Technology
An overview of the environment requirements are listed below:
Tomcat 7
Apache
Redis
JSON
REST APIs
Support
Standard support applies.
Final Submission Guidelines
Standard 30 day support applies