Introducing RMS Architectures: RMS stands for REST (Representational State Transfer) Mediated Services. A RMS reference meta-model describes architectures with a number of distinctive features:

  • Functions of the architecture are defined in terms of services
  • Communication is performed through exchanges of events
  • Events are represented in terms of REST-ful payloads (header and body).
  • Services are glued together by a mediation engine, in which data sources, endpoints and the chain of actions for an event are defined by configuration and bound in real-time

This 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: these petri-like declarative constructs define a standard language for the definition of event flow across services

Going a bit further, 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 external systems.
  • Orchestration 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.)

Architectures following this reference meta-model have many positive attributes in addition to extensibility and scalability. State is restricted to a few core services (usually related to persistence or caching functions) what increases resiliency and robustness.

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 hours if not minutes.

I wonder where all the fun will be…