/
02 - Middleware

02 - Middleware

Owned by Selvyn Wright
Last updated: Jul 10, 2024
6 min read

Middleware is the software we use to glue systems together, to make them interoperable

We will not delve into the internal details but focus on the approach of each style

There are two main types of middleware on the market

  • RPC

  • MOM

image-20240701-175639.png

01 Communications Mode

Components can communicate in one of two ways

  • Synchronous

  • Asynchronous

image-20240701-180335.png

02 Communications Styles

  • Point Casting

  • Broadcasting

  • Multicasting

image-20240701-180844.png

03 ReST

Representational State Transfer – an architectural style invented by Dr. Roy Thomas Fielding

image-20240701-181450.png

03-01 ReST in Application

For any form of RPC to work, the service layer must expose endpoints, these are well-defined and must also detail the payload

Serverside configuration (VATServceController.java)

image-20240707-194706.png

Clientside configuration (endpoints.js)

The client needs to know what the exposed endpoints are on the server side

image-20240707-195745.png

What problems do you see with this approach?

04 MOM

Message Oriented Middleware

image-20240701-182406.png

05 Middleware Architectural Styles

image-20240701-182917.png

As you can see when we wire the services together using an RPC approach, the coupling would increase at an exponential rate. With the MOM approach, the coupling is decreased and the architecture is cleaner. But what’s the cost? We will need to move to an event model. Domains will need to communicate with each other using messages. These messages can carry whatever we want.

06 How do MOMs Work

Consider the following scenario

You have several machines on a network, each running a HTTP server

The implication being that any process on one of those machines can send a HTTP request to any other machine in that network

image-20240708-202419.png

What you have created is a software bus where the wire-level protocol is <<HTTP>>

Remember, a protocol defines how systems communicate with each other, it creates a common language between the systems

You can now add and remove nodes from the bus at your leisure…

07 Software Buses and Brokers

What if you wanted to route <<http>> messages to a specific process on any particular node?

You would modify the HTTP server so it can identify within the <<http>> message the particular process and then route it onto that process using some kind of IPC

image-20240708-203231.png

The HTTP server has now become a Broker

08 Location Transprency

All services, whether they are RPC or MOM based need to be discoverable. If we address a service or a MOM administrator directly, we introduce brittleness to the system architecture. Also, any changes to the service or MOM administrator IP address will mean all users of that service must be updated. This means the architecture is not scalable.

To avoid these pitfalls we need to introduce into the architecture some kind of Name Resolution Service. There are two types of Name Resolution Services

  • White Pages Lookup

    • DNS, or Naming Server

  • Yellow Pages Lookup

    • X.500, or LDAP

image-20240708-202150.png

09 Typical MOM Architecture

Because this week is all about decoupled systems, and event-based architectures we will present a typical architectural layout that will be used

image-20240702-100032.png

10 What does the Code look like?

Typically MOM-based architectures require both consumer and provider to have knowledge of where the MOM channels are. This is usually done by first attaching to a MOM administrator and asking it for the channel. This administrator acts as a kind of factory object. Once the consumer/producer has the channel it can start to transmit into or receive from the channel.

10-01 Bootstrapping

The defaults for the admin, consumers, and producers would look like this

image-20240708-164000.png

As you can see the host details are hard-wired into the application, you would not normally do this because the MOM is not location transparent and this leads to brittle code and none scalable code

image-20240708-164334.png

10-02 Consumer Perspective

Typically the consumer will look like this

image-20240708-164738.png

  1. You first need to subscribe to a channel

  2. Test for any changes in the channel

  3. Iterate over the changes in the channel

Notice that the consumer is not aware of where the data has come from

10-03 Producer Perspective

Typically the producer will look like this

image-20240708-165302.png

  1. You need to create object that has the channel details, and the payload

  2. Send the event to the channel

Notice that the producer is not aware of where the data is being sent

11 Understanding How MOMs Work

  1. Ensure that Docker is running (can be found on the Windows Start)

  2. Navigate to c:\work

  3. Clone down the project https://bitbucket.org/stream2stream/kafka_prods_cons/src/main/

  4. Navigate into the folder kafka_prods_cons

  5. Build the application with the command mvn package

  6. Consult the Kafka Setup and Cheat Sheet, and get kafka up and running

Here are some scenarios for you to run

11-01 Single Consumer and Single Producer

  1. Run a single consumer listening for message on a channel called ddat-topic_1

  2. Run a single producer that sends a message (can be any string even a JSON string) to the ddat-topic_1 channel

  3. Observe the messages received by the consumer, these are in the kafka log

  4. image-20240707-203539.png

     

  5. Send more messages using the producer, observe the results

  6. Stop the consumer and send messages, then restart the consumer, the sent messages should come through including all previous messages

  7. Try running multiple consumers, and send a new message from the producer, observe what happens with the consumers and the kafka UI

11-02 Consumer, Bridge, and Producer

  1. Run a single consumer listening for message on a channel called ddat-topic_2

  2. Run a single consumer listening for message on a channel called bridge

  3. Create a bridge using the -f switch that reads messages from the ddat-topic_2 channel, (-t switch) and forwards them to a channel called bridge (-f switch)

  4. Create a producer that sends messages to the ddat-topic_2 channel

  5. Observe the results on all the consumers and the kafka UI log

These two scenarios highlighted two very important building blocks when working with MOMs

  • The Consumer-Producer pattern, is used to connect disconnected and very different systems to each other

  • The Bridge pattern is used to connect disconnected and very different systems to each other, some processing may take in the bridge

  • The Adapter pattern is used to connect different systems together by creating an interface that a consumer can work with

  • The Pipe pattern is used to chain a series of services together, each performing one step in a sequence of steps required to complete a process

12 So what did you see?

On examination, you should realise that this was the architecture used in kafka demo application that you previously ran.

image-20240702-100806.png

13 Interaction Patterns

Normally one channel is used per interaction mode

image-20240702-101226.png

14 Message Flows

MOMs offer incredible capabilities that can be replicated using OPRC means, but it would take time and effort to implement

image-20240702-101454.png

 

Related content