Glossary
July 2002
ACID transaction
A transaction is a sequence of operations that acts as a single logical unit of work. An ACID transaction has four properties, known as ACID properties, to qualify as a transaction:
- Atomicity. Indivisible unit of work; either all or none of the data modifications are performed.
- Consistency. When completed, a transaction must leave all data in a consistent state.
- Isolation. No one outside of the transaction can see data in an intermediate state.
- Durability. After a transaction has completed, its effects are permanently in place in the system.
atomic transaction
See ACID transaction.
business document
Also document.
Technically, an object that defines the parameters and/or return values of the functions exposed by a service.
Logically, a logical unit of information used in a business transaction, such as a purchase order.
business entity
A business entity is an object that implements the business rules in a system.
business entity layer
The business entity layer consists of business entities that carry out the steps of work defined in a process.
business process
Also process.
A related set of activities that when correctly performed satisfy some business goal.
A process orchestrates or coordinates a series of activities needed to satisfy some business goal.
A business process controls the step-by-step actions of executing some work, moving the system from one state to another. At each step it may perform a business operation.
business process layer
Defines the business processes inside a business service; it uses the business entity layer to execute the operations.
business process service
A service whose primary function is to orchestrate or coordinate the actions provided by other services.
business service
A service whose primary function is to execute requests; usually managed by a process service.
component
A unit of functionality that may be amortized across multiple implementations. A software object that exposes one or more interfaces and that implements logic.
contract
A binding agreement that describes all the constraints that govern any conversation between two services; this includes all of the design-time constraints as well as the run-time constraints.
conversation
Communication between two services about a specific topic or business entity.
An instance of a contract, where two services are engaged in sending and receiving messages to each other.
coupling
Coupling means that things are linked—that they have dependencies and that there are consequences if they are changed.
A sliding scale of how tightly two services are bound together.
data accessor
Data accessors use stored procedures to access data from the database and store this data for use by the business services.
data representation layer
The data representation layer contains the data accessors.
durable state
State that is stored on a durable medium such as a file system or a database.
emissary
A design pattern by Pat Helland for a service whose primary functions are to help prepare a request to be submitted to other services and to help interpret a service's response to the request.
fiefdom
A design pattern by Pat Helland for a collection of loosely coupled services that encapsulate shared durable state and are deployed together.
idempotency
A pattern for an implementation in which a message will have the same effect whether received once or multiple times.
long running transaction
Also saga.
An implementation of a business process or part of a business process that contains the logic to compensate for the activities that have already been executed in case of cancellation.
message
A unit of information transmitted electronically from one service to another.
policy
A policy defines the run-time rules that govern communication and service behavior.
port
The end point or address Uniform Resource Locator (URL) of a message.
port type
See service interface.
process
See business process.
reference data
A composition of snapshot data used by clients of a service.
saga
See long running transaction.
service
A software component whose behaviors with respect to its clients are message driven.
service agent
A service whose primary functions are to help prepare a request to be submitted to other services and to help interpret a service's response to the request.
service façade
A service façade exposes the functionality of a system to the outside world.
service interface
Definition of a particular role in a process agreement.
snapshot state
A snapshot exposes a restricted view on the state of a service at a point in time. A snapshot needs not be current.
stable data
A snapshot whose meaning and interpretation does not change across space and time.
stateful conversation
Communication between parties in which information relating to aspects of previously exchanged data must be recorded to allow meaningful exchanges subsequently.
stateless conversation
Communication between parties, where all messages can be interpreted independently; the service does not need to remember previous requests and responses.
transaction
A single unit of work in which all parties must agree that the work should and can be done.
trust
The confidence a service has in the reliability of other services and the information that they provide.
user interface process
A service whose primary function is to orchestrate or coordinate the actions provided by user interface services.
user interface service
A service handling the interaction with one or more humans.