Glossary of Terms

You can deploy Services using a Continuous Integration/Continuous Delivery service. See Integrating with CI/CD tools for instructions.

The SDK supports Endpoint, Key Value Entity, Event Sourced Entity, Workflow, Consumer, View and Timed actions components. These components enable you to implement your business logic.

A component used to consume or produce stream of changes.

It’s utility to call Akka components without knowing where they are located.

An id to identify components. Changing component id for Stateful components should be done with caution, because the id is used for persistence.

A command comes from a sender, and a reply may be sent to the sender. A command expresses the intention to alter the state or retrieve information based on the state of an Entity or Workflow. A command is materialized by a message received by a component implementation. Commands are not persisted and might fail.

A command handler is the code that handles a command. It may validate the command using the current state, and may emit events or update the state as part of its processing. A command handler must not update the state of the entity directly, only indirectly by using Effect API.

Effects are predefined operations that align with the capabilities of each Component, except Endpoints. These operations are the Component’s Effect API. Returning an Effect from the Command handler allows the Akka runtime to execute infrastructure-related code transparently to the user. For example, event-sourced entities provide an Effect API that among other things can persist events.

Components like Key Value Entity and Event Sourced Entity are usually referred as entities. An entity is conceptually equivalent to a class, or a type of state. It will have multiple Entity instances, each of which has a unique ID and can handle commands. For example, a service may implement a chat room entity, encompassing the logic associated with chat rooms, and a particular chat room may be an instance of that entity, containing a list of the users currently in the room and a history of the messages sent to it. Entities cache their state and persist it using Effect APIs.

An instance of an Entity, which is identified by a unique ID.

An endpoint component is a way to expose a service to the outside world. They act as controllers ahead of the other components, like Entitys or Views. They don’t require Component id because URL address is enough to identify them.

An event indicates that a change has occurred to an entity and persists the current state. Events are stored in a journal, and are read and replayed each time the entity is reloaded by the Akka runtime state management system. An event emitted by one component or service might be interpreted as a command by another.

An event handler is the only piece of code that is allowed to update the state of the Event Sourced Entity. It receives events, and, according to the event, updates the state.

A type of Entity that stores its state using a journal of events, and restores its state by replaying that journal. These are discussed in more detail in Event Sourced state model.

An id used to identify instances of a Stateful components.

Persistent storage for Events from Event Sourced Entitys. Some documentation uses the terms Event Log or Event Store instead of journal. Akka handles event storage for you, relieving you of connecting to, configuring, or managing the journal.

A Key Value Entity stores state in an update-in-place model, similar to a Key-Value store that supports CRUD (Create, Read, Update, Delete) operations. In Domain Driven Design (DDD) terms, a Value Entity is an "Entity." In contrast with "Value Objects," you reference Entities by an identifier and the value associated with that identifier can change (be updated) over time. These are discussed in more detail in Key Value state model.

Akka supports user management with Single Sign-On via OpenID Connect. For details see Securing.

A project is the root of one or more Services that are meant to be deployed and run together. The project is a logical container for these services and provides common management capabilities.

When you deploy a Service, Akka wraps it with the runtime. The runtime manages entity state, and exposes the service implementation to the rest of the system. It translates incoming messages to commands and sends them to the service. The runtime also forms a cluster with other instances of the same service, allowing advanced distributed state management features such as sharding, replication and addressed communication between instances.

A service is implemented by the Akka SDK. At runtime, Akka enriches the incoming and outgoing messages with state management capabilities, such as the ability to receive and update state. You implement the business logic for the service, which includes stateful entities. You deploy your services and Akka adds a Runtime that handles incoming communication and persistence at runtime.

A snapshot records current state of an Event Sourced Entity. Akka persists snapshots periodically as an optimization. With snapshots, when the Entity is reloaded from the journal, the entire journal doesn’t need to be replayed, just the changes since the last snapshot.

The state is simply data—​the current set of values for an Entity instance. Entitys hold their state in memory.

Each entity uses one of the supported state models. The state model determines the way Akka manages data. Currently, these include Key Value Entity and Event Sourced Entity.

A component like Key Value Entity,Event Sourced Entity or Workflow

A Timed Action provides consistent scheduling and execution of a call to another Component at specified intervals or delays. They are convenient for automating repetitive work and handling timeouts within business logic implementation.

A View provides a way to retrieve state from multiple Entities based on a query. You can query non-key data items. You can create views from Key Value Entity state, Event Sourced Entity events, and by subscribing to topics.

Workflows are high-level descriptions to easily align business requirements with their implementation in code. Orchestration across multiple services with support for failure scenarios and compensating actions is simple with Akka Workflows.

A Workflow definition element which encapsulates an action to perform and a transition to the next step (or end transition to finish the Workflow execution).