MetaModel

Let’s enhance the standard ISO 20022 meta model to support interfaces. (the shaded area in the diagram).

An interface may have several of the following:

  • Property – requests to read or write item(s). A list may have information about the collection of items in the list.
  • Operation – a request for action to the interface, which responds with the result.
    For asynchronous message oriented communication:
    • Emission – to send a signal. Operation which is out only.
    • Reception – to receive a signal. Operation which is in only.

Resource oriented interfaces comprise Properties.
Operation oriented interfaces comprise Operations.
Message oriented interfaces comprise Emissions and Receptions.
Object oriented interfaces may comprise any combination.

Interfaces are provides or required by Ports, which realise the role of Participants.
A Protocol is a Choreography which defines Ports and their Interfaces.

Intro to the ISO 20022 meta model

The metamodel comprises of several levels.

  • The Scope level models Business Processes which may extend or include one another. They define Business Roles in the context of the process.
  • The Conceptual level models Business Transactions as an arrangement of Message Transmissions that Participants Send and Receive. Each Business Transaction has a Message Transport Mode, such as quick, reliable or bulk. The type of data exchanged is modeled by Business Components which have Business Elements. Business Elements may be: Attributes of either simple Data Types or complex Business Components; or references by Business Association Ends to instances of Business Components. Business Associations model binary relations between components.
  • The Logical level models Message Choreographies as an arrangement of Message Definitions (sent and received by interfaces). Each Message Definition belongs to only one Business Area, and may be part of several Message Sets.
    Each Message Definition comprises one Identifier and one or more Building Blocks. Each Building Block is either of a simple Data Type or a Message Component Type. A Component Type is either a kind of External Schema which we do not model further, a
    Message Component of several Message Elements, or a Choice Component of one of several Message Elements. Message Elements
    may be: Attributes of either simple Data Types or complex Component Types; or references by Association Ends to instances of Component Types.
  • The Physical level is instances of the Logical Level models in a specified syntax. Each Syntax Message Scheme (ie. a schema definition) is traced from a Message Definition. Each API Specification is traced from an Interface.

Modelling starts at the Scope level to describe Business Processes and their Roles. It is refined at the Conceptual level by considering the Transactions which realise the Processes, and the Participants which realise the Roles, and the Transmissions between them. We also model the data concepts. In the Logical level, we describe the Choreographies that realise the Transactions, at which point we decide on the style of Transmission and Define Messages to be used in Interfaces for Participants.

It is thus possible for Business Processes to be modeled in a variety of communication styles, whilst achieving the same business result.

Message Transport

ISO 20022-1:2013 models the instances of communication, though it appears to be incomplete. Only SyntaxMessageScheme has a place in the BusinessProcessCatalogue of a Repository. Conversation has no properties nor associations. Metaclass Conversation is described as an “Exchange of one or more MessageInstances among MessagingEndpoints.” Yet it has no features.

We extend Conversation as a TopLevelCatalogueEntry with an attribute “message” aggregating TransportMessage; and a trace to Message Choreography. This enables our Conversation+ class to hold TransportMessages, and specify constraints on the messages in the conversation, in order to implement a Choreography. Constraints can already be applied at MessagingEndpoint to implement an Interface.

Note that just as a instance of a message could exist that is invalid according to its syntax message scheme, an instance of a conversation could exist that is invalid according to its constraints. The constraints can be implemented to prevent this from happening, or to detect it has happened.