MQTT 5.0 analytics platform, greenfield project build, part nine (Workflow)

As we have seen over the course of this series of posts, the MQTT protocol is optimised for low bandwidth applications and quite terse in terms of datatypes.  As you can see below, the number of messages that MQTT can send is also much smaller.  

Looking at the number of message, a better comparison is between FIXP and MQTT, since both are essentially session protocols rather than describing what is in the payload (they are not exactly functionally equivalent, but let's keep this at a high level).

So, the evolution of FIX has been a slow moving process of Working Groups, Sub-Committees and Committees which produce release candidates and eventually releases of the protocol.

The most exiting change has been the adoption of FIX Orchestra within the world of FIX and the realisation that there are two parts to any messaging workflow:

1. Messages
2. The workflow that is associated with those messages

What we see with most messaging protocols is the focus is on (1) and not (2). FIX Orchestra brings (2) front and centre - Orchestra is essentially a workflow orchestration layer that sits on top of FIX.  But - crucially, from the day that the name Orchestra was chosen (by your humble author) one of the crucial tenets of Orchestra has been that it's messaging protocol agnostic.  So you can use FIX Orchestra with ITCH/OUCH, SBE over FIXP, GPB over FIXP, ASN.1 over FIXP or, as this article describes - MQTT.

Consider the classic MQTT workflow - 

Sensor publishes observation - a temperature (within a namespace such as sensor/temperature)

Broker receives the observation

ClientA subscribes to the sensor/temperature namespace and as such receives the observation from the sensor

ClientB subscribes to the sensor/temperature namespace and as such receives the observation from the sensor 

ClientB subscribes to the sensor/temperature namespace and as such receives the observation from the sensor

This is pretty much the standard MQTT example that you find with a little use of DuckDuckGo or Bing.

But what if we want so model a more complex workflow? Now you are into the world of FIX Orchestra.

The FIX Trading Community website lists six main Use Cases for FIX Orchestra - 
Communicate    Communicating your FIX Service to others
Normalize    Normalizing inbound FIX flows into your ecosystem
Validate    Validating your counterparties compliance with their and your FIX service
Self-Validate    Validate your own FIX Service
Provisioning    Using Orchestra for Provisioning
Manage FIXatdl    Using Orchestra to manage FIXatdl

Consider a Smart City that uses FIX Orchestra - a catalogue of what the City can do. Powerful stuff...

https://www.fixtrading.org/standards/fix-orchestra/

MQTT Control Packet

CONNECT

CONNACK

PUBLISH

PUBACK

PUBREC

PUBREL

PUBCOMP

SUBSCRIBE

SUBACK

UNSUBSCRIBE

UNSUBACK

PINGREQ

PINGRESP

DISCONNECT

AUTH

FIX 5.0 Sp2 Tag 35 (MsgType) Valid Values

0 = Heartbeat

1 = TestRequest

2 = ResendRequest

3 = Reject

4 = SequenceReset

5 = Logout

6 = IOI

7 = Advertisement

8 = ExecutionReport

9 = OrderCancelReject

A = Logon

AA = DerivativeSecurityList

AB = NewOrderMultileg

AC = MultilegOrderCancelReplace

AD = TradeCaptureReportRequest

AE = TradeCaptureReport

AF = OrderMassStatusRequest

AG = QuoteRequestReject

AH = RFQRequest

AI = QuoteStatusReport

AJ = QuoteResponse

AK = Confirmation

AL = PositionMaintenanceRequest

AM = PositionMaintenanceReport

AN = RequestForPositions

AO = RequestForPositionsAck

AP = PositionReport

AQ = TradeCaptureReportRequestAck

AR = TradeCaptureReportAck

AS = AllocationReport

AT = AllocationReportAck

AU = Confirmation_Ack

AV = SettlementInstructionRequest

AW = AssignmentReport

AX = CollateralRequest

AY = CollateralAssignment

AZ = CollateralResponse

B = News

BA = CollateralReport

BB = CollateralInquiry

BC = NetworkCounterpartySystemStatusRequest

BD = NetworkCounterpartySystemStatusResponse

BE = UserRequest

BF = UserResponse

BG = CollateralInquiryAck

BH = ConfirmationRequest

BI = TradingSessionListRequest

BJ = TradingSessionList

BK = SecurityListUpdateReport

BL = AdjustedPositionReport

BM = AllocationInstructionAlert

BN = ExecutionAcknowledgement

BO = ContraryIntentionReport

BP = SecurityDefinitionUpdateReport

BQ = SettlementObligationReport

BR = DerivativeSecurityListUpdateReport

BS = TradingSessionListUpdateReport

BT = MarketDefinitionRequest

BU = MarketDefinition

BV = MarketDefinitionUpdateReport

BW = ApplicationMessageRequest

BX = ApplicationMessageRequestAck

BY = ApplicationMessageReport

BZ = OrderMassActionReport

C = Email

CA = OrderMassActionRequest

CB = UserNotification

CC = StreamAssignmentRequest

CD = StreamAssignmentReport

CE = StreamAssignmentReportACK

CF = PartyDetailsListRequest

CG = PartyDetailsListReport

D = NewOrderSingle

E = NewOrderList

F = OrderCancelRequest

G = OrderCancelReplaceRequest

H = OrderStatusRequest

J = AllocationInstruction

K = ListCancelRequest

L = ListExecute

M = ListStatusRequest

N = ListStatus

P = AllocationInstructionAck

Q = DontKnowTradeDK

R = QuoteRequest

S = Quote

T = SettlementInstructions

V = MarketDataRequest

W = MarketDataSnapshotFullRefresh

X = MarketDataIncrementalRefresh

Y = MarketDataRequestReject

Z = QuoteCancel

a = QuoteStatusRequest

b = MassQuoteAcknowledgement

c = SecurityDefinitionRequest

d = SecurityDefinition

e = SecurityStatusRequest

f = SecurityStatus

g = TradingSessionStatusRequest

h = TradingSessionStatus

i = MassQuote

j = BusinessMessageReject

k = BidRequest

l = BidResponse

m = ListStrikePrice

n = XML_non_FIX

o = RegistrationInstructions

p = RegistrationInstructionsResponse

q = OrderMassCancelRequest

r = OrderMassCancelReport

s = NewOrderCross

t = CrossOrderCancelReplaceRequest

u = CrossOrderCancelRequest

v = SecurityTypeRequest

w = SecurityTypes

x = SecurityListRequest

y = SecurityList

z = DerivativeSecurityListRequest