up-l3

Application Layer (uP-L3)

Table of Contents

• 1. Architecture Patterns
• 2. Core uProtocol uEs

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF BCP14 (RFC2119 & RFC8174)

Copyright (c) 2023 General Motors GTO LLC

Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.

SPDX-FileType: DOCUMENTATION
SPDX-FileCopyrightText: 2023 General Motors GTO LLC
SPDX-License-Identifier: Apache-2.0

Application layer, also known as the business logic layer, is responsible for declaration interfaces between clients and servers for features and functions, the API layer that defines the methods and topics served by a service.

In this specification we will also define core uProtocol business logic (APIs) such as subscription management, discovery, and digital twin. These interfaces are declared once, used everywhere so that the mental model for developers is consistent across different heterogeneous systems.

1. Architecture Patterns

uProtocol supports the architecture patterns defined in the table below to implement the majority of use cases that could be required for business logic communication between clients and services.

Table 1. Architecture Patterns

Architecture Pattern	Delivery Policy	Description	Requirements
RPC	At-least-once	When uE requires acknowledgement from the receiver	If the client-side business logic requires retry policy, it MUST implement the retry policy Server-side business logic MUST implement Idempotency for remote procedural calls Dispatchers that are unable to deliver req.v1, MUST generate a delivery failure res.v1 and send it back to the Sender uE
Publication	At-most-once	When uE wishes to publish an CE to multiple consumers (a.k.a. "fire & forget")	Dispatcher MUST provide access to CEs that have failed to be delivered (DLT defined in a later section), for both the Sender and/or Receiver uE business logic
Notification	At-most-once	When a uE wishes to notify a specific uE (a.k.a a publication with a destination)

2. Core uProtocol uEs

This special purpose built uEs are required to implement uProtocol and must be present on each uDevice.

Table 2. Core uEs

uE	Ver	Description
uSubscription	v3	Subscription management service that is responsible for managing subscriptions between uEs to realize the publisher/subscriber design pattern.
uDiscovery	v3	Discovery of uThings locally, within a domain, and throughout the network. Supports URI resolution (to find where something is located)
uTwin	v1	Local cache of published events