Pattern Sections
Pattern: Computation
Function 
a.k.a. Stateless Computation Operation, Calculation Action, Side-Effect-Free/Stateless Operation
Context
The requirements for an application indicate that something has to be calculated. While the input is available locally and the output will be used in the same place, the calculation should not be run there for cost, efficiency, workload, security, or other reasons.
For instance, an API client might want to ask the API endpoint provider whether some data data meets certain conditions or might want to convert it from one format to another.
Problem
How can a client invoke side-effect-free remote processing on the provider side to have a result calculated from its input?
Forces
The following forces apply when introducing side-effect-free processing on the provider side:
- Reproducibility and trust
- Performance
- Workload management
Pattern forces are explained in depth in the book.
Solution
Introduce an API operation cf with
cf: in -> out to the API endpoint, which often is a
Processing
Resource. Let this Computation
Function validate the received request message, perform the desired
function cf, and return its result in the response.
This Computation Function neither accesses nor changes the server-side application state as shown in Figure 1.
Sketch
A solution sketch for this pattern from pre-book times is:
Examples
A simple, rather self-explanatory example of a Transformation Service is shown in Figure 3
A call to find out about the health of a service (a.k.a. heartbeat test message) is another example of a simple command exposed remotely within a Processing Resource endpoint (see Figure 4).
Such “I am alive” operations (a.k.a. “ping” calls) accepting test messages) are often added to mission-critical API implementations as part of a systems management strategy (here: fault and performance management). Its pre- and postconditions are simple; its API contract is sketched in the above UML snippet. Neither system transactions nor business-level compensation (undo) is required in this simple example.
Are you missing implementation hints? Our papers publications provide them (for selected patterns).
Consequences
The resolution of pattern forces and other consequences are discussed in our book.
Known Uses
Serverless computing lambdas, deployed to public clouds such as AWS or Azure, may be seen as Computation Functions as well (unless they are combined with cloud storage offerings, which makes them stateful).
Online JSON and JSON schema validators operate purely input-based and qualify as Validation Services; they do not have to take server-internal state into account (other than the schema definition and their metametamodels). The same holds for image manipulation and PDF processing tools, both of which are abundant on the Web today (Transformation Service).
A basic known use of the Validation Service variant of this
pattern can be found in the Cargo root entity and the
RouteSpecification in the Cargo
Aggregrate of the Domain-Driven
Design Sample Application. It implements several validation routines
(that are not exposed in the remote API of the application).
A major German car manufacturer offers a REST level 2 user profile
management microservice for all its clients; the analysis
endpoint of this service qualifies as a known use of the Validation
Service variant: It offers a POST operation to
validate data strictly, suggests corrections, and converts addresses and
phone numbers to country-specific standards (without storing
them); profile updates are also supported by the microservice, but at
another endpoint address. Swagger/Open API contracts are exposed in an
API
Description portal/website.
Terravis, a process integration platform Berli, Lübke, and Möckli (2014), offers an API to internal clients to calculate a valid payment date. The operation is called by specifying a desired payment date. Depending on certain rules (e.g., taking bank holidays into accounts as well as weekends), the next feasible payment date is calculated and returned to the caller. This operation does not change the provider-side application state, all required input comes from the received request message. Moreover, Terravis offers Solution-Internal APIs for generating various business documents such as contracts. Data is passed from the calling clients to the document generation API, which validates the data for completeness and conformance with certain business rules and then generates a PDF document statelessly.
More Information
Related Patterns
The pattern compares to its siblings as this:
- Just like a Retrieval Operation, a Computation Function does not change the application state (but delivers nontrivial data to the client); it receives all required data from the client, whereas a Retrieval Operation consults provider-side application state (in read-only mode).
- Both State Creation Operations instances and Computation Functions receive all required data from the client; a State Creation Operation changes the server-side application state (write access) whereas a Computation Function preserves it (no access). The client of a Computation Function usually has a higher expectation w.r.t. the response than a client that invokes an State Creation Operation to report an event (and only requires a positive confirmation).
- A State Transition Operation also returns non-trivial data (like Retrieval Operation and Computation Function, but it also changes the server-side application state. Input comes from the client but also from the server-side application state (read-write access).
The Service pattern in Domain-Driven Design (DDD) includes similar semantics (but is broader) and can help to identify Computation Function candidates during endpoint identification Vernon (2013).
Other Sources
Service types are a topic covered by SOA literature from the early 2000s, e.g., “Enterprise SOA” Krafzig, Banke, and Slama (2004) and “SOA in Practice” Josuttis (2007). While the service type taxonomies in these books are more focussed on the overall architecture, some of the basic services and utility services have responsibilities that do not require read or write access to provider/server state and therefore qualify as instance of this pattern an its variants.
The design-by-contract approach in the object-oriented programming method and language Eiffel Meyer (1997) includes validation into business commands/domain methods and automates pre- and postcondition checking. This program-internal approach can be seen as an alternative to external Validation Services (but also as a rather advanced known use of it).
A lot of online resources on serverless computing exist. One starting point is the web site and blog “Serverless” by J. Daly.