Platform Core

The ComUnity Platform Core contains a set of shared components which serve as the “central nervous system” of the digital operating platform. While some of these components perform centralised tasks within the core, others are responsible for providing a common set of services across all platform service layers.

At a high level, the Platform Core responds to requests from the Client Runtime and hosted applications.

The Platform Core will make sure the interacting entity is who it says it is by calling the authentication component, that the entity has the appropriate permissions by calling the authorisation component and that it is possible to satisfy the request. The core will then call on the necessary services to assemble the response.

If the request is for data only, then the request will be routed through the components of the Platform Core to the Data Services. If the request is for metadata, then the request will be routed to the Application Content Manager.

The Platform Core components are:

Secure Channel
Secure Channel is the first component of the Platform Core, and provides message privacy, tamper protection, and server authentication. All devices that support secure channel communications will use this component.

Compression
The compression component detects user agent support for compression and compresses the response. This applies to both media and data although many content types like JPEG are delivered as-is since the format is inherently incompressible.

Authentication
Whenever the incoming message asserts an identity, the identity is authenticated against the authentication service. The authentication service allows authenticating with an e-mail address, telephone number or a ComUnity account name.

Logging
The logging component records the request’s metadata in file storage. When the response comes back its metadata is also logged. Sensitive data like authorisation data is removed before persisting. When an error occurs, the request and response bodies are also stored. All log operations are asynchronous to minimise the effect on responsiveness.

Routing
The routing component examines the incoming request and passes it to the appropriate handler. Media and data requests are first passed on to authorisation while tracking and metadata are passed to their respective handlers.

Authorisation
The responsibility of this component is to authorise the request and then return the user’s profile including security roles. The authentication and authorisation layers ensure that any operation on any resource happens with permission. When the incoming request does not satisfy these requirements, an error is returned to the client. The client applications handle such errors by presenting the user with a choice to sign in to continue. This reactive authorisation also caters for the scenario where the client application needs user profile information to render UI elements or the client application detects that the user’s security roles are not sufficient for the targeted resource. In these cases, the login service can authorise new credentials and return a user profile with possibly elevated security roles.

Tracking
The tracking component records metadata about the request and then passes control to the authorisation component after setting the request URL to the URL of a resource configured in the tracking record identified by the original request URL.

Live Connect
The live connection component is responsible for delivering changes to a resource as quickly as possible to clients that are interested in them. Each request, and its response is assigned a unique id to enable tracking of the request as it moves through the request pipeline.

Caching
Based on cache control metadata the caching component may decide to invalidate current cache entries or deliver a response from cache storage. When a request is passed on, the resulting response is evaluated for cache control instructions to determine whether the response may be recorded in the cache. The caching component supports expiration and validation.

Slipstream
The slipstream component makes sure that there is only one idempotent request in- flight for the same resource on the same processor. When a request comes in while another is in progress for the same resource, the requests are added to the queue of requests waiting on the response. When the response comes back, the same response is delivered to all the requests at once. The slipstream component can greatly increase scalability during peak times.

Get started