There are two main types of middleware on the market

• RPC

• MOM

Open

01 Communications Mode

Components can communicate in one of two ways

• Synchronous

• Asynchronous

Open

02 Communications Styles

• Point Casting

• Broadcasting

• Multicasting

03 ReST

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)

Clientside configuration (endpoints.js)

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

04 MOM

05 Middleware Architectural Styles

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

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

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

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

09 Typical MOM Architecture

10 What does the Code look like?

10-01 Bootstrapping

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

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

10-02 Consumer Perspective

Typically the consumer will look like this

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

10-03 Producer Perspective

Typically the producer will look like this

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

2. Send the event to the channel

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.  

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

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.

13 Interaction Patterns

14 Message Flows