RMS Architectures

Think a system built as an interconnection of abstract functions (services) in which those connections are described by routing (mediation) rules, and and communication between those services is performed by the exchange of self-described events.

Pretending we do not have enough random acronyms out there already, we are calling the reference conceptual framework for those systems “RMS architectures”. RMS stands for REST (Representational State Transfer) Mediated Services, and presents five distinctive features:

• Shared Information Model: Every ‘thing’ on this architecture carries an universal identifier. ‘Things’ can be linked together through those identifiers according to a predefined, shared meta-model
• Events carry all the information necessary for services to act on that event.
• Services are stateless in relation to caller’s state, and provide a very simplified interface. On larger systems services may be aggregated on tiers (e.g. functions and macro-functions)
• Mediation Function: Routing of events (i.e. which services it touches, in which conditions, and in which sequence) and synchronicity of a call are defined by descriptive routing rules in a mediation engine. Data sources and destinations are described as abstract resources, or endpoints.
• Binding Facility: Event representation are bound to an endpoint representation based on binding (conversion, transformation, mapping) rules. Endpoints (user interfaces, relational databases, message destinations) react and generate events based on a set of normalized binding rules.

Shared Information Model

The shared meta data, or information model, defines constraints in which ‘things’ can be linked to one another, and what type of complex constructors (sets, bags, list, etc) you can use to aggregate them together.

The scope of the meta-model can vary. On large scale systems, you can think about one global meta-data defining shared constraints, and each macro-function define its own meta-model. For example, on a trading system you can think about one shared meta-model for shared entities and attributes (like orders, trades, quotes and external entities) and each of the macro functions (pricing, booking, risk) expressing its own relationships, specific attributes and extensions.

Events

One event carry all the information (or state) that is necessary for the service provider to act on when receiving that event. The preferred representation for events in a RMS architecture is by a structure composed of a header and a payload.

The header is a dictionary (or map) of parameters used for routing or generic classification. Generic classification properties allow the recipient to define what to do with the payload (such as a verb or request type).

The payload is a fragment of the information model, in a normalized representation. A normalized representation is a format that is internal to your domain, and cannot be related to either endpoints or external domains.

Services

Services define functions of a domain, organized hierarchically, in which fine grained functions are called ‘handlers’. Services on a RMS architecture fall in one of four categories:

• Core services: responsible for shared or fundamental functions (e.g. replication, caching, persistence, management)
• Adapter services: related to the exchange of content to and from non-RMS systems.
• Mediation services: for interfacing with service consumers, and additionally responsible for the activation of services according to a predetermined set of mediation rules
• Specialized services: provide high-level functions in a specific domain (pricing service, risk exposure service, matching service, etc.)

Services are defined in two variations of control: as ‘interceptors’, in which the service controls the call to the next on a chain, or ‘handlers’, in which the control is handled by a ‘coordinator’ or ‘manager’

Service should be stateless, and therefore should not be aware of any specifics in terms of thread safety or concurrency controls. All the state should be stored and retrieved from the context (event payload)

Mediation Function

The mediation function in a RMS reference model is responsible to tie abstract endpoints to a sequence of services based on descriptive routing rules. A mediation function should be able to provide the following features.

• Define data sources and data destinations as abstract entities (endpoints).
• Route events from endpoints, through services, and to endpoints based on routing rules and content of the header of an event
• The association between services and events should be able to also define the synchronicity of the request, i.e. if the service has to respond to the activation synchronously (as a request call) or asynchronously (as a notification call)
• Endpoints are bound to routing rules at run-time, based on a URI representation of this endpoint. Internal logic should not be aware of specifics of the endpoint state. Endpoints are anything we take data from, or send data to:  user interfaces, databases, caches, message destinations and so forth.

Binding Facility

Binding allows the normalized representation to be mapped to and from external systems and endpoints based on binding (transformation) rules. On that sense, different endpoints have to also offer different binding schema and rules, such as:

• An user interface is seen as an endpoint:
  • A screen has to bind the state of an incoming event to attributes only the user interface has (e.g. panels, fields, formatting rules).
  • A screen should be able to generate an event based on an user action (a button click for example), binding rules and its own state
• A relational data base is seen as an endpoint.
  • It has to be able to produce one or more relational operations based on an incoming event, and a set of binding rules
  • A trigger, or an associated message system, should be able to generate an event based on the nature a change to the database, and a set of binding rules.

A few other similar examples would be message destinations, caches, flat files — in essence anything that can function as either a source or a destination of events.

RMS and other acronyms: EDA, Service-Orientation, EIP, and (fill-your-favorite-fashionable-acronym-here)

A similar type of architecture was mentioned before in a previous article. It is a association of three highly complementary concepts:

• Event-Driven Architectures:  functions are triggered by events, and the relationships between functions (or actions) are stated in a declarative form (e.g. EQL, routing-DSL, 2nd order logic)
• Service-Orientation: functions are aggregated on into abstractions of high level  functions called services.
• Integration Patterns: petri-like declarative constructs define a standard language for the definition of event flow across services

Conclusion

Architectures following this reference meta-model have many positive attributes in addition to extensibility and scalability.

• State is restricted to the caller and a few core services (usually related to persistence or caching functions) what increases resiliency and robustness
• One common way of seeing the ‘universe’ – the meta-model, defining a set of relationships and constraints that can be easily enforced.
• Services have a very simple interface, and easily bound to patterns like Command and Chain of Responsibility.
• Endpoints and transformation services isolate state and functions that are core to your domain, from what is related to external systems and endpoint implementations (like presentation screens, or data sinks like databases, or message destinations)

The aim is simplicity and time to market. Considering these minimum templates for RMS architectures, the right tools for automation of system development and agile processes like SCRUM, new systems can be cut out, configured and be ready for evolutionary development in a matter of days if not hours.

I wonder where all the fun will be…