TL;DR

Microservice Domain-Specific Language (MDSL) abstracts from technology-specific interface description languages such as Swagger, WSDL and Protocol Buffers.

If the URI of this page is https://socadk.github.io/MDSL/index, you are looking at the GitHub pages of the next version (technology preview)! Please refer to https://microservice-api-patterns.github.io/MDSL-Specification/index for the latest public open source version.

Quick links:

• Documentation pages (these GitHub pages):
  • Endpoint Type, Data Types, Provider and Client, Bindings, Tutorial, Quick Reference
  • Technology preview: AsyncMDSL
• Tools: Overview, CLI, update site for editor (Eclipse plugin)
  • Generators: OpenAPI generator, Protocol buffers generator, Graphql generator, Jolie generator, Java «Modulith» generator, Arbitrary textual generation with Freemarker
• Language and tools repository (GitHub): XText grammar, examples folder

Getting Started with MDSL

MDSL supports the API Description pattern from Microservice API Patterns (MAP). It picks up MAP concepts such as API endpoint, operation, client and provider, and features patterns as decorators (a.k.a. stereotypes): <<pagination>>.

A First Example

The Hello World of MDSL models an API with a single endpoint HelloWorldEndpoint that exposes a single operation called sayHello:

API description HelloWorldAPI

data type SampleDTO {ID, D} 

endpoint type HelloWorldEndpoint
exposes 
  operation sayHello 
    expecting payload D<string>  
    delivering payload SampleDTO

API provider HelloWorldAPIProvider
  offers HelloWorldEndpoint

API client HelloWorldAPIClient
  consumes HelloWorldEndpoint

sayHello accepts a single scalar string value D<string> as input. This operation returns a Data Transfer Object (DTO) called SampleDTO as output, which is modeled explicitly so that its specification can be reused. SampleDTO is specified incompletely as an identifier-data pair {ID, D}: the names of the two “parameters” and the type of the data value D have not been specified yet. In addition to the endpoint type (a.k.a. service contract) HelloWorldEndpoint, an API client and an API provider working with this contract are defined (on an abstract level).

Take a look at Hello World in Swagger/OpenAPI Specification in comparison. You can find such contract specification example here (admittedly, this OpenAPI specification contains some more details about te HTTP binding of the abstract contract).

Design Goals

A contract language for (micro-)service API design should:

• Support agile modeling practices, for instance in API design workshops:
  • Value and promote readability over parsing efficiency (in language design)
  • Support partial specifications as first-class language concepts to be refined iteratively (see above example {ID, D})
• Promote platform independence:
  • Microservice API Patterns (MAP) as first-class language elements annotating/decorating endpoint types, operations, and representation elements
  • Not bound to HTTP (unlike Swagger and its successor OpenAPI Specification) or other protocols and message exchange formats
• Support meet-in-the-middle service design:
  • Top-down from requirements (for instance, user stories for integration scenarios), as for instance proposed as activity in the Design Practice Repository (DPR)
  • Bottom up from existing systems (represented, for instance, as DDD-style context maps)

Design Principles

To achieve the above design goals, we decided that:

• The abstract syntax of MDSL is inspired and driven by the domain model and concepts of Microservice API Patterns (MAP), featuring endpoints, operations, and data representation elements.
• The concrete syntax of service endpoint contracts is elaborate; the concrete syntax of data contracts is compact yet simple; it abstracts from data exchange formats such as XML and JSON, as well as service-centric programming languages such as Ballerina and Jolie.¹

MDSL Tools

At present, the following tools are available (see tools page for more information):

• An Eclipse-based Eclipse editor and API Linter
• Command-Line Interface (CLI) tools to validate a specification, to generate platform-specific contracts (OpenAPI, gRPC, Jolie) and reports

A Closer Look

Where and when to use MDSL

Let us visualize the usage context of MDSL specifications with two hexagons, as suggested by the microservices community:²

If you want to leverage and promote microservices tenets such as polyglot programming and use multiple integration protocols, e.g., an HTTP resource API and message queuing, then MDSL is for you. The request and response message representations in the diagram can be specified with MDSL data contracts; the provided interface supports an MDSL endpoint type.

Language specification elements

1. Service endpoint contract types follow this template: endpoint type ... exposes operation ... expecting ... delivering ...
2. Data contracts (schemas): data type SampleDTO {ID, V} in the above example
3. Optional instance-level concepts:
   • API Provider with protocol bindings and, optionally, Service Level Agreements and evolution strategies such as Two in Production
   • API Client instances consuming the contracts exposed by providers
   • API Gateways (or intermediaries) acting both in client and in provider role; note that gateways are not featured in the simple example above

See these concepts in action in the tutorial, the quick reference and on the example page.

Usage of and support for Microservice API Patterns (MAP)

MDSL supports all Microservice API Patterns one way or another:

• The basic representation elements serve as MDSL grammar rules in the data contract part, e.g., ParameterTree and AtomicParameter.
• Foundation patterns may appear as decorators/annotations for the entire API description, for instance, PUBLIC_API, FRONTEND_INTEGRATION (not shown in the above HelloWorldAPI example).
• Some responsibility patterns serve as decorators/annotations for endpoint roles and responsibilities, for example PROCESSING_RESOURCE and MASTER_DATA_HOLDER (enum/label).
• Other responsibility patterns are represented as decorators/annotations for operation responsibilities, for instance, COMPUTATION_FUNCTION and EVENT_PROCESSOR.
• Finally, the advanced structural representation patterns (for example, <<Pagination>>) and many quality patterns appear as stereotypes annotating representation elements (for example, <<Embedded_Entity>> and <<Wish_List>>).

The four types of decorators/annotations and stereotypes are optional; if present, they make the API description more expressive and can be processed by tools such as API linters/contract validators, code/configuration generators, MDSL to OpenAPI or WSDL converters (work in progress).

More Information

MDSL Git Pages (this website)

• Service endpoint contract types
• Data contracts (schemas)
• Bindings
• Optional language elements on the instance level (provider, client, gateway)
• Quick reference
• Tutorial, another example
• Tool information (CLI, editor/linter)

External links

• Public Microservice API Patterns (MAP) website, access to team-internal preview website available upon request (features more patterns than the public one, in intermediate draft form).
• Lakeside Mutual repository, featuring Domain-Driven Design (DDD) and microservices in an insurance company scenario (JavaScript frontends and Spring Boot backends)
• An end-to-end service design demo is available on Medium also featuring Context Mapper, a DSL for strategic DDD and rapid OOAD (Context Mapper can generate MDSL). The demo takes you from a user story to a walking microservice skeleton (Spring Boot, Hipster, Heroku) in seven steps (partially automated in model transformations).
• A microservices and DevOps conference report mentioning Context Mapper and MDSL.
• Olaf Zimmermann’s Blog “The Concerned Architect”, with articles on

Copyright: Olaf Zimmermann, 2018-2021. All rights reserved. See license information.

1. The service and the data contract languages can be used independently of each other; for instance, data contracts for operations in contract types can also be specified in JSON Schema (but might not be supported by MDSL tools in that case). ↩

2. Octogons, as used to denote cells in Cell-Based Architectures (CBAs), look cool too ;-) ↩