| Optional Technical Classifiers | Permitted Choices | Definitions |
| State Behaviour | Stateful | Behaviour of a service implementation invocation is related to another invocation through recording and communications of state information between the invocations. |
| Stateless | Individual service implementation invocations are stateless and not correlated with other invocations. |
| Transactional Behaviour | Transactional/ACID* | The service implementation processes data as transactions and the transactions SHOULD BE (are designed to be) ACID safe. |
| Transactional / Non ACID* | The service implementation processes data as transactions and the transactions are not ACID safe. |
| Non-transactional | The service implementation has no transactional behaviour. |
| * ACID – Atomic, Consistent, Isolated, and Durable;
NB: Transactional behaviour implies stateful processing |
| Batch Behaviour(s) (select one or more) | Individual | The SERVICE processes a single data resource per invocation. Results or errors are returned pertaining to the operation or data resource as a whole. |
| Batch | The SERVICE processes a collection of documents or batch of data per invocation. Results or errors are returned both for the overall operation and for each element in the batch. |
| Time-Constraint Behaviour | Hard Real Time** | The SERVICE implementation must meet hard real time constraints. |
| Soft Real Time** | The SERVICE implementation must meet soft real time constraints. |
| None | There are no real time constraints on the service implementation.
|
| ** Real Time - Correctness of an operation depends on both logical correctness of the operation AND the time when the operation is performed.
Hard Real Time - Operation must be completed within a specific time window to be successful (e.g., making on online share purchase).
Soft Real Time -Operation can be completed outside of a specific time window, but with degradation of service (e.g., losing frames in a real time video application). |
| Service End Point | Provider | SUM is primarily a data/document provider, accessed by other components. |
| Requestor | SUM is primarily a data/document requestor, accessing other components. |
| Transcoder | SUM transcodes data (it both requests and provides). |
| Authentication or Authorization Dependency | Auth-Dependent | SUM includes or relies upon internal authentication or authorization controls. |
| Auth-Independent | SUM does not include or rely upon internal authentication or authorization controls. |
| Protocol Binding(s) (select one or more for SUMs that are based on Service Expressions) | Web Service | The SERVICE implementation is implemented using web services standards, e.g., WSDL and SOAP. |
| SOAP | The SERVICE implementation uses SOAP, but not other web services standards; there is no WSDL definition. |
| REST | The SERVICE implementation formally follows the REST model. |
| HTTP | The SERVICE implementation uses only HTTP protocols. |
| Other | The SERVICE implementation uses some other protocol (e.g., TCP, UDP). |