AWS Open Source TAMS API

The AWS Open Source implementation of the TAMS API was developed as a mechanism to help customers and partners get started with their adoption of the TAMS specification. AWS recognized that without an initial implementation of the API, it is difficult to get started.

The long term expectation is that the TAMS API capabilities will get built directly into products and, therefore, these will not be the need for the separate API implementation.

Architecture

The AWS open source implementation of the TAMS API is deployed using the Serverless Application Model Command Line Interface (SAM CLI). This is an extension of the AWS CLI that adds functionality for building and testing serverless applications. It uses Docker to build your functions in an environment that matches AWS Lambda. It can also emulate your application’s build environment and API.

The API is designed around Amazon API Gateway, with the different API functions performed by a set of Lambda functions. The segment and webhook data is currently persisted in Amazon DynamoDB, which was selected for the single-digit millisecond response times. This capability is key for an API which is responsible for providing the details of the media segments in time to support real time video playback. All other data is persisted in Amazon Neptune, which was selected for the Graph database relationships it specializes in storing. This makes the most sense when you consider the relationships that exist between Flows and Sources.

Figure 16: Architecture of the AWS Open Source implementation of the TAMS API

The TAMS specification provides for event notifications using webhooks. To generate these, Amazon Eventbridge is used internally to aggregate the event notifications before being triggered by a separate Lambda function. The configuration of the webhooks is held in a separate DynamoDB table.

The segment delete process has a number of steps to it. Initially, a Delete Request is created and returned to the client through the API response. This delete request is stored both in the Neptune database, to allow users to query the status, and in an Amazon Simple Queue Service (Amazon SQS) queue, to allow for the async processing of it. A separate Lambda function pulls from this SQS queue and performs the delete on the Segments records in the DynamoDB. The affected object_id of each deleted segment is posted to a second SQS queue. The Delete Request is processed until all segments requested have been deleted. This may mean that for large deletest, the Flow Segments API could take time to be consistent with the requested delete.

A second separate Lambda pulls from the Cleanup SQS queue. This is the queue where the object_ids mentioned above are posted. This Lambda checks to see if the affected object_id is in use by any other Flow Segments. If it is, then the object remains in place. However, if the object is no longer referenced by any other flow, then the object is deleted from Amazon S3.

Amazon Cognito is used as the default mechanism for providing authentication within the TAMS API.

Deployment instructions can be found in the TAMS API repository.