<tr>
  <td>Counters</td>
  <td>
    A data object used to store the measurements of a performance counter, such as the number of times a function is called.
  </td>
</tr>	

Term	Definition	Helpful article
Application	A software package that performs a specific function
Backend	The part of an application that is not directly accessed by the user. In general, backends are used to perform business logic and calculations.
Beacon	A hardware device that enables data transmission to mobile devices within a specific range of the device.	Data microservice
Benchmark	TA standard or point of reference.
BFF	BFF or Backend For Frontend is a design pattern that considers a dedicated backend for each frontend application interface. It is a variant of the API Gateway pattern, where instead of having a single point of entry that manages all the logic, there are several ones that consider specialized cases.
Boundary Microservice	A microservice used to expose the functionality of a system to external entities such as consumers, users, and systems. These microservices can be divided into two categories: facades and connectors.
Build factory	A creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created.
Business Process Microservice	A microservice used to implement business transactions. These microservices can be classified as background workers and sagas.
Caching	The process of storing and accessing data from a cache, where a cache is a high-speed data storage. Typically, the storage is transient and is used to speed up the retrieval of data. Within Pip.Services, the user can create components for caching. Also, there are two components that offer caching: the MemoryCaching class, which caches in memory, and the NullCache, which is a dummy cache with no real effect. And, Pip.Services includes modules for Redis and Memcached.	Caching
Circuit Breaker pattern	A pattern used to detect failure and encapsulate the logic of preventing it from cascading between services. It can also detect when a problem has been resolved. By isolating the failure, this pattern provides fault and latency tolerance.
Client	A hardware device or software program that requests access to a service provided by a server. Clients are typically used in the client-server architecture.
Collection	A class representing a set of similar items as a single unit. Within Pip.Services, there are several useful collections, such as AnyValueMap, StringsValueMap and Arrays.
Command	An instruction given by a user to a computer to perform a specific task. It can be initiated from a command line or a user interface. Within Pip.Services, commands are defined by the Command class, which can be used to call a method or a function.
Commandable pattern	A behavioral design pattern in which an object is used to contain the information needed to perform certain actions or trigger events. Within Pip.Services, this pattern is implemented via the CommandSet class, which contains a group of commands that are defined via the Command class. The collection of commands available from the command set is then called by the controller, who uses them according to the implemented business logic. The toolkit also provides some ready-to-use components that implement this pattern like the CommandableHttpController and CommandableGrpcController, which are abstract controllers that receive commands via the HTTP and gRPC protocols respectively.	Command Set
Communication protocol	A system of rules that allows two or more entities of a communication system to transmit information via any kind of variation of a physical quantity. Pip.Services offers components for communication for the HTTP and gRPC protocols.
Component	Within Pip.Services, a component is a class with a lifecycle implemented using interfaces (Code augmentation). Usually, within a microservice, components are organized according to a three-layer architecture.	Creating a Component
Component references / Component linking	The way components communicate with each other. Within Pip.Services, components relate to each other via the Locator pattern. To be able to link to dependencies, a component must implement the IReferenceable interface and register its dependencies defined via a References object.
Component types	Components can be classified according to their functionality into data, persistence, logic, controllers, containers, etc. Pip.Services uses this classification to organize the different components in modules, which are in turn internally arranged in packages.
Componentized design	A design approach focused on the decomposition of the system into functional or logical components. Its primary goal is component reusability. The Pip.Services toolkit follows this approach, which allows for creating microservices from loosely coupled components.
Config file	A file containing information about components. This information is used by containers to locate references (See Locator pattern).
Config params	Config params stands for configuration parameters. Pip.Services offers the ConfigParams component, which contains a key-value map for configuration parameters. This component can be used, for example, to store access control credentials.
Configure	The act of selecting programmable options that make an application function according to the user's needs. Configurations allow to change microservice behavior, adjust to deployment environments, and set parameters to connect to infrastructure services and other microservices. For this, the Pip.Services toolkit provides a set of patterns that support design-time, deployment-time, and runtime configurations
Connection params	Connection params stand for connection parameters. Pip.Services has the ConnectionParams class, which is used to store connection parameters necessary to connect to external services.
Container	A package of software that contains all of the necessary components to run an application in an environment. Pip.Services offers the Containers module, which has the ProcessContainer component. This component is an inversion of control container that runs the packaged code as a system process. Additionally, the toolkit provides a variety of other containers, which are used to assemble microservices from components and deploy them on different platforms. They include containers for AWS Lambda, Azure Functions, and Google Cloud Functions among others. Within Pip.Services, containers manage the lifecycle of the packaged components, from creation to destruction. They use the Locator pattern and obtain information about dependencies from a configuration file.	Containers
Controller	Within Pip.Services, a controller is the component in the first layer of the three-layer design model. It is used to communicate with clients by using protocols such as HTTP and gRPC.	Three tier architecture
Credential params	Credential params stands for credential parameters. Pip.Services contains the CredentialParams component that can be used to hold the credentials required to connect to external services.
Data Microservice	A microservice used to read and store data. These microservices can be classified as CRUD or CQRS microservices.	Data microservice
Descriptor	A descriptor is a Pip.Services component that works as a component locator based on the following fields: group, type, kind, name and version of a component. As matching can be done by using one or more of the fields, many scenarios with various degrees of specificity can be considered. For example: locate all loggers (type) or locate a specific component (name and version).	Descriptors
Direct Client	A client that calls a service directly in the same memory space. It is used when multiple microservices are deployed in a single container (monolith) and communication between them can be done by direct calls rather than through the network.
Discovery	Service discovery refers to the automatic detection of components. For this functionality, Pip.Services provides the MemoryDiscovery class, which works by keeping connections in memory.	Discovery services
Endpoint	An endpoint represents a connection point for an API. Typically, it is a uniform resource locator (URL) that provides the location of a resource on a server. Endpoints are used by controllers and clients to locate each other. Pip.Services contains an HTTP endpoint component, which is used by those components that communicate via this protocol including REST services, Swagger, Prometheus, and health services. Similarly, it has a gRPC endpoint that allows for components to communicate via the gRPC protocol.
Environment	A collection of programs, libraries, and utilities that allows users to perform specific tasks.
Facade	A component that serves as a front-facing interface connecting clients to different components. Thus, all requests made by external clients first arrive at the facade from where are then forwarded to the appropriate microservices. This extra layer that facades provides allows for microservices to be changed, without those changes affecting the clients. Facades can provide some additional functionality such as routing, data aggregation, authentication and authorization, caching, analytics and logging. Large systems can include several facades, each of them representing a logical isolated API. Moreover, specialized facades can be used for clients that present specific needs (See BFF pattern).
Factory	A factory is an object used to create other objects. The Pip.Services toolkit provides the IComponentFactory abstraction, which can be used to create factories for different components. Additionally, the toolkit supplies specific factories for standard components.
File Persistence	Persistence that stores data in files. Within Pip.Services, this functionality is supported by the FilePersistence component, which stores the data in files and caches them in memory.
Frontend	The part of an application with which the user interacts directly. From a user's point of view, it is synonymous with the user interface. From a developer's point of view, it includes the interface design and the related coding. Within Pip.Services, frontends are usually components that represent clients.
gRPC	An open-source, high-performance Remote Procedure Call (RPC) framework that can run in any environment. Originally developed by Google, Pip.Services implements it via the gRPC module.	gRPC
Health monitoring	A set of activities undertaken to maintain a system in operable condition. Within Pip.Services, this is done via tracing, logging and performance metrics. Once the information has been created, it can be sent to an external tool, such as Prometheus or Elasticsearch, for analysis. The toolkit provides several components such as HeartbeatController for heartbeat operations, InstrumentTiming to create logs, counters and timings, and the Count library that includes several useful components to create performance counters.	Prometheus Elasticsearch
Inversion of Control pattern	Inversion of Control is a principle in software design where the control of components is transferred to a container that handles their lifecycles. This pattern helps create loosely coupled classes that are testable, maintainable and extensible. This pattern is at the core of Pip.Services approach to containerization, which allows for microservice deployment in different environments. The toolkit provides the ProcessContainer, which runs the packaged code as a system process, and several specialized containers for common platforms such as AWS Lambda, Azure Functions, and Google Cloud Functions among others.
Library	A collection of software resources used by computer programs.
Locator pattern	A pattern that uses a central registry (the "service locator"), which on request returns information about a specific resource, acting as a run-time linker.	Component references
Locks	A mechanism for controlling access to something. Pip.Services provides the MemoryLock component, which is used to synchronize the execution of a process using shared memory. It also has the NullLock, which is a dummy lock with no real effect.	Locks
Log	A file that records either events happening in an operating system or software executions.
Logging	The action of keeping a log. PIP.Services provides two important logging components namely, the CachedLogger and the ConsoleLogger. The first class stores log messages in memory, whereas the second class displays them on a console. The toolkit also has the CompositeLogger component, which allows for message aggregation and thus, the creation of a centralized logging point. Additionally, PIP.Services provides implementations of loggers for CloudWatch, ElasticSearch, and DataDog.	Logging
Long-living code	Code that can last long because it is easily updatable and scalable.
Memory persistence	Persistence that stores data in memory. Within Pip.Services, this functionality is supported by the MemoryPersistence component.
Metrics	A measure of software characteristics that are quantifiable or countable.
Microapplication	A super-specialized application designed to perform one task or use case.
Microservice	Microservices are an architectural and organizational approach to software development in which software consists of small independent services that communicate via APIs. Their main characteristics are: 1. Each microservice uses its own technology stack independently of other microservices. 2. They are independently deployable. 3. They communicate with each other through REST APIs and messages. 4. They are organized around business capabilities by following the "one service–one function" principle. 5. Their development is usually managed by a small team of people.
Mock Client	A dummy client that simulates the work of a controller in memory. It is used for testing or demonstration purposes.
Module	A collection of components with similar functionalities. Modules allow for the organization of components within the toolkit. The core of the toolkit consists of two modules namely, Commons and Components. Other modules, such as RPC, gRPC, AWS, MySQL, Cassandra etc, extend the functionality of the toolkit. Each module is implemented in six different languages according to the symmetric implementation principle.
MQTT	MQTT is a lightweight, publish-subscribe, machine-to-machine network protocol. It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth. This protocol is implemented in Pip.Services in the MQTT module, which contains components for sending and receiving messages via an MQTT broker.	MQTT
Mustache templates	Mustache is a web template system with implementations available in several languages. PIP.Services offers an implementation of Mustache in its Expressions module. This implementation is enhanced with the addition of some helpers.	Mustache templates
Null Client	A dummy client with no real effect. It is used for testing
Pattern	A solution to a problem in a specific context.
Performance Counters	A performance monitoring and debugging tool that consists of counting the number of actions that both the application and the operating system perform. Examples include the number of exceptions thrown, loading time, and the number of threads. Performance counters are considered in the Pip.Services toolkit through the Count package available from the Observability module. This package contains a set of interfaces and classes used to create these tools.	Observability
Persistence	Data stored in a non-volatile resource, so that it survives after the process with which it was created has ended.	Designing persistence
Pipeline (CI/CD)	A sequence of steps that must be performed to build, test, package and deliver a new version of an application. These processes can vary depending on the type of application, language, environment, etc.
Ported	A computer program that has been reworked to run in a new environment.
Property	In object-oriented programming, a property is a special type of variable that is used to define the characteristics of an object.
Reference	A value that specifies the location of a component. To store and locate references to a component, Pip.Services has the References class.
Saga	A sequence of transactions that updates each service and triggers the next transaction step. If a step fails, the saga executes the necessary compensating transactions that undo the ones previously executed.
Service	Within Pip.Services' three-tier architecture, the service is the class where the business logic of the microservice is implemented. From this component, methods can call other components.
Swagger	A suite of tools for API development. Pip.Services offers access to these tools via the Swagger module, which has the functionality to document an API via a Swagger interface.	Swagger
Symmetric implementation	The architectural principle that says that for every programming language the toolkit implements, there is a common set of classes, methods, and method signatures that applies to all implemented languages.
Toolkit	A set of software utilities used to develop or maintain a software system.
Trace ID	A transaction id used to trace execution through a call chain. It can be a number, a string, or a combination of both. Trace ids are important for tracing errors, debugging, and logging.
Validation	The process used to determine whether a program or entity satisfies a specified requirement.	Data validation
Validation schema	An object-based way of defining validations on requests. Within the Commons module, Pip.Services offers several classes that can be used as validation schemas, such as ObjectsSchema to validate user defined objects, FilterParamsSchema to validate FilterParams, and MapSchema to validate maps.
Validity	The extent to which a concept, conclusion or measurement satisfies a specified requirement. Within the Commons module, Pip.Services offers the Validate package, which contains interfaces and classes that can be used to create custom validation rules.	Data validation