A peek into the middle of the enterprise software architecture stack. A curtain raiser into the middleware of the software technology stack. Showcases Types of middleware, configuration possibilities, high level components, features, messaging models, deployment,

1. Message
Oriented
Middleware
A peek into the middle
of the enterprise
software architecture
stack.

2. AGENDA
This is what we will peek into
Architecture Fundamentals

3. AGENDA
This is what we will peek into

4. Different Kinds of
Architecture
Let us traverse through
the way computer and
software architecture has
moved through the
decades.

5. ARCHITECTURE:

6. ARCHITECTURE:

7. ARCHITECTURE:

8. ARCHITECTURE:
Monolithic
RPC
EAI
SOA
IOT
Rise of the Web
Rise of the Frameworks
Rise of the Middleware
Rise of the Services
Rise of the Machines

9. Revisiting the
fundamentals………
• Synchronous Communication.
• Asynchronous Communication.
• State Handling and Finite states.
• Multi-threading.
• Publisher-Subscriber.

10. Synchronous - Asynchronous Communication

11. State handling and finite states

12. Multi threading

13. Publisher Subscriber

14. WORKFLOWS

17. Tech Stack
• A peek into a software technical
stack of a company.

18. SLACK
Tech Stack of Slack

19. Applications in
the Enterprise
• A peek into how
applications in the
enterprise are stationed
and interact with each
other

20. MIDDLEWARE
 Introduction
 Messages and Queues
 Message Queues
 Configuring message
queues

21. Block
Representation of
middleware Application Layer
Middleware
Server/Platform/
OS side
Application Layer
Middleware
Server/Platform/
OS side
• Middleware is a link between two or
more objects:
Different parts of the application
Different local applications
Different distributed applications
• Is computer software that provides
services to software applications
beyond those available from the
operating system. Essentially,
middleware is a software glue.
• Assists applications to interact or
communicate with other applications,
networks, hardware, and/or
operating systems.

22. Objectives
• Hide heterogeneity.
• Location independence.
• Common functionality needed by many
applications.
• Software portability and mobile code.
• Help integrate legacy facilities.
• Aid application interoperability.
• Aid scalability.
• Reliability and Availability.
• Reduce application development and
maintenance.

23. Middleware
• Middleware supports and simplifies
complex distributed applications.
• It includes web servers, application
servers, messaging and similar tools
that support application development
and delivery.
• Middleware is especially integral to
modern information technology based
on XML, SOAP, Web services, and
service-oriented architecture.

24. Types of Middleware
• Database Middleware.
Enables applications to communicate with one or more
local or remote database.
• Application Server Middleware
Used as middleware between browser and legacy systems
• Messaging Middleware:
Transactional – X/Open XA
Procedural – XML-RPC...
Object oriented – CORBA...
• Message oriented Middleware
Message QueuesBrokersBus
ESB
• Transaction Processing Middleware

25. MESSAGE
QUEUES
&
MESSAGE
ORIENTED
MIDDLEWARE

26. Messages:
 Messages:
Communication
conveyed from one
person or group to
another.
 Example: email, chat,
notifications, etc,

27. Queues:
 Queue: Queue is a
form of arrangement,
where items are
processed in
sequential order.
 Example: Queues in
ATM, bill payment,
etc.

28. Message Queues:
 Is a design pattern used in system
architecture which is used to achieve fail
safe and high availability. It follows store
and forward communication.
 Advantages:
 Allows application to connect in
asynchronous way.
 Allows to handle multiple request at
same time.
 Decoupling design in achieved in the
application using MQ
 Uses:
 Email service
 Web chat
 Notication and Alerting service
 Order Processing in e-commerce
sites

29. Configuration:
A message queue can be configured in the following different ways:
 Private Queue
 Sending to a private queue requires sender
authentication.
 Defines different access rights.
 Public Queue
 All senders may send messages without
access control.
 Journal Queue
 Keeps a copy of every received message
for logging or monitoring purposes.
 Dead Letter Queue
 Queue that holds undeliverable messages
(messages that time out due to time-to-
live (TTL) expiry or whose queue address
could not be resolved).
 Bridge / connector queue:
 Connects different queue systems, e.g.
MSMQ and JMS based messaging systems.

30. MESSAGE ORIENTED
MIDDLEWARE
(MOM)
Message Oriented Middleware is
a specific class of middleware
that supports the exchange of
general-purpose messages in a
distributed application
environment.

31. Message
Oriented
Middleware
• Messages are
exchanged
asynchronously
between distributed
applications (senders
and receivers).
• Solves problem of
client having to know
where the server is
and what needs to be
done.
• The message queue
serves as a central
exchange of messages
(hub and spoke
architecture, queue routes
messages to the
destination queue).
• A message queue provides
additional decoupling
between senders and
receivers.
• The queue may perform
additional functions such
as filtering, message
transformations (e.g.
enrich messages with data
from a DB) and load
balancing and is also
referred to as message
broker.

32. Key Components of a MOM
Message
Receiver
Message Router Message Delivery
Network

33. BLOCK DIAGRAM:

34. FEATURES:
 Asynchronous operation:
 Sending of messages is unblocking. The
sender application may continue its work,
the sender queue tries to deliver the
message on behalf of the sender
application (until successful).
 Transaction support:
 Sending and receiving a series of messages
may be „packed“ into a transaction. Either
all messages are successfully sent and
received or none.
 In-order delivery:
 Messages are queued in the order
they are sent. However, messages
may „overtake“ messages other
based on priorities.
 Priority-based delivery:
 Messages are queued according to
a priority scheme (the receiver
queue passes messages with
highest priority first to the receiving
application).

35. FEATURES:
 Message formatting:
 Possibility to “wrap“messages into formats
such as SOAP over HTTP, XML or plain text.
 Notification services (triggers):
 Receiver: MOM sends notifications of new
enqueued messages to the receiver.
 Sender: MOM sends notifications of the
successful delivery of sent messages to the
sender.
 Message filtering: The queue performs
filtering based on different criteria:
 Message properties (message header
fields), e.g. priority.
 Message body (e.g. SQL expression).
 Message routing:
 Message forwarding through intermediate
message queues (= brokers).
 Message routing may be based on different
criteria (e.g. current workload on
destination queues for load balancing).
 Message security:
 Apply security functions like message
authentication, encryption and message
integrity.

36. FEATURES:
 Supported message transport
protocols:
 TCP or UDP (simplest transport protocol)
 HTTP or HTTPs (good for sending
messages over the Internet)
 SMTP
 FTP
 Messaging system proprietary transport
protocol
 Message peek and receive:
 Peeking allows a receiving application to
receive a copy of a message from a queue.
The message is left in queue. Only a
receive operation actually removes the
message from the queue ("pop" a
message).
 Delivery mode, Quality of Service
(QoS):
 Guaranteed delivery, highest QoS
 Persistent mode, messages survive queue
crashes.

37. Different Kinds of Messaging Models
• Let us go thorough a few models of
Asynchronous interaction where the
Client and server are loosely
coupled Messages are queued and
applications are integrated, support
is provided for reliable delivery and
messages that could be processed
by intermediate messaging servers.

38. P2P: Point to Point
 1 queue per receiver (application)
 1-to-1 (1 sender, 1 receiver) or N-to-
1 messaging (many senders, 1
receiver)

39. Publish-Subscribe
 1-to-N or N-to-N distribution of
messages (same message may be
received by multiple receivers if
these are subscribed).
 Similar to a message board. Rather
than distributing messages to
queues, the message broker routes
messages to subscribers. Thus
messages may be sent to multiple
receivers (multicast).

40. FIFO Queues
 First In First out Queues
 All messages have the same priority
level.
 Messages are delivered in the order
they are sent.

41. Priority Queues
• Messages are buffered in FIFO
queues and ordered based on
priority.
• N.B.: The ordering applies to the
set of messages that are in the
queue at a specific point in time
(= messages that are not yet
received by an application).

42. • .
Different Kinds of Messages and
Acknowledgements

43. Types of Messages
• Persistent Messages
Message that can be stored in disk/database.
Messages that can be retrieved upon startup.
Messages that guarantee delivery.
• Non-Persistent Messages
Message is kept in volatile memory.
Offers high performance compared to persistent message
Once the queue goes down the messages in the message
queue is lost.

44. Types of Message
Acknowledgements
• Automatic Acknowledgements.
• Explicit Acknowledgements.
• JMS Transaction based
acknowledgements.

45. • At most once  Messages may be lost but are
never redelivered.
• At least once  Messages are never lost but
may be redelivered. The sending queue keeps
the message in persistent store until it receives a
positive acknowledge of the correct reception of
the message by the target application. After a
crash, the sending queue does not query the
receiving queue if it already has received the
message, but just re-sends the message.
• Exactly once  Each message is delivered once
and only once. Guaranteed delivery, The sending
queue keeps the message in persistent store (like
exactly-once).
• Non-persistent mode. (no delivery guarantee,
lowest QoS):
Message Delivery
Semantics

46. Applications in
the Enterprise
• A peek into how
applications Look after
Message oriented
middleware enters the
fray.

47. Utilization:

48. Utilization:

49. • .
Different Kinds of Deployment of Message
Queues

50. Deployment:

51. Scaled Deployment:

52. ALTERNATIVES IN
THE MARKET
TODAY.

53. Alternatives:
There are many COTS message brokers and queuing servers that are available today.
However, there are certain alternatives terminologytechnology that can be used.
 Custom built Enterprise messaging
system using varieties of technology.
 Enterprise service bus architecture.
 Http server that support SSE.
 Data pipeline systems

54. ESB:
Enterprise Service Bus is a shared messaging layer for connecting applications and other
services throughout an enterprise infrastructure. It supplements its core asynchronous
messaging backbone with intelligent transformation and routing to ensure messages are
passed reliably. Services participate in the ESB using either web services messaging standards
or the Java Message System
 An ESB is software infrastructure that
simplifies the integration and flexible
reuse of business components using
a SOA. An ESB makes it easy to
dynamically connect, mediate, control
services and their interactions.
 ESB is not a Web Server or an
Application Server
 The ESB check list
 Standard compliance
 WS-* standards compliance (beware
of Vendor’s bias!)
 Interoperability
 WS Stack standard compliance
 Flexibility : REST | SOAP

55. Block Diagram:
A very high level block diagram of an ESB could be depicted as follows:
Web Service
Stack
Adapters and Connectors
Routing and Mediation
Messaging Backbone
Legacy
Systems

56. HTTP SSE:
HTTP based Server Sent Events achieves One Way Messaging where a web page
automatically gets updates from a server.
 The EventSource object is used to
receive server-sent event notifications
 We will need a server capable of
sending data updates (like PHP or
ASP or Glassfish(Jersey), ).
 We can consider using Server Sent
Events when we have some rapidly
updating data to display.
 Examples might include displaying
the status of a long running business
process, tracking stock price updates,
or showing the current number of
likes on a post on a social media
network.

57. Block Diagram:
A very high level block diagram of an SSE Server could be depicted as follows:

58. Data Pipelines:
Data pipeline are a system which allows to move data from one sub system to another sub
system within system or sometimes across system
 Helps to transform data from one
format to another
 Removes un necessary columns or
data points
 Mask sensitive information
 Insert Record
 Ability to speak with different
consumer and producer data.
 Data Pipeline system can also mimic
as message queue.

59. Block Diagram:
A very high level block diagram of an Data pipeline system could be depicted as follows:

60. HANDS-ON
Simple interaction using HTTP-
SSE

61. WORKFLOW:
A simple workflow that describes what will be happening

62. COTS tools
A very small brief of the various
tools that are used in the
industry for MOM kind of use.

63. ActiveMQ:
 Apache ActiveMQ is a JMS compliant
message broker
 Written in Java but support API for other
language to extend the functionality.
 Open Sourced and suitable for business
modesl.
 Provides reliability, performance, high
availability and security for messaging
 It offers extra set of features compared to
JMS standard specification.
 Supported Protocols
 Open-Wire (default in ActiveMQ; a binary
protocol)
 Clients for C++, Java and .NET
 STOMP Simple Text Oriented Messaging
Protocol; a text based protocol
 Clients for C, JavaScript, Perl, PHP, Python,
Ruby
 XMPP Used extensively in chat applications
 REST
 HTTP POST and GET

64. IBM WS MQ:
 Multiplatform MOM from IBM. Available on
IBM platforms, .Net, Linux etc.
 •Various APIs such as JMS, XMS (JMS API for
.Net, C/C++), MQI (MQ native interface).
 Main elements of WebSphere MQ:
 Queue manager: is the container for a
message queue, is responsible for
transferring messages to other queue
managers over a message channel. The
QM may reside on the same host as the
application or on a separate host.
 The main supported topologies are:
 Hub and spoke topology (P2P queues):
 Applications subscribe to "their" queue
manager.
 Routes to hub QM are manually defined in
spoke QMs.
 Distributed Pub-Sub:
 Applications subscribe to topics and send
messages to multiple receivers (publish).
 2 Topologies:
 Clusters and trees. Cluster of queue
manager connected by channels between
QMs. Published messages are sent to all
connected queue managers of the
published topic. Trees allow reducing the
number of channels between the QMS

65. MS MSMQ:
 Message infrastructure and a
development platform for creating
distributed, loosely coupled system
 It offers guaranteed message
delivery, efficient routing, security
and transaction support
 Guaranteed message delivery
(message delivered even when queue
is temporarily down).
 Message routing.
 Security (optional authentication and
encryption).
 Priority-based messaging.
 Different message transport
protocols.
 MSMQ can be run in 2 modes
 Workgroup Mode: Private Queues in
workgroup mode.
 Domain Mode: allows sending messages
between multiple domains, both private
and public queues are possible here
 Message size can not be more than 4
MB. 2GB Queue size limit

66. KAFKA:
 Open source streaming platform developed
at LinkedIn. A distributed publish-subscribe
messaging system that maintains feeds of
messages called topics
 Publishers write data to topics and
subscribers read from topics
 Kafka topics are partitioned and replicated
across multiple nodes in your Hadoop
cluster
 Enables “source to sink” data pipelines. Kafka
messages are simple, byte-long arrays that
can store objects in virtually any format with
a key attached to each message; often in
JSON
 E&L in ETL through Kafka Connect API
 T in ETL through Kafka Streams API
 Fault-tolerant
 Kafka is high throughput distributed message
system . Used to build data pipeline, real
time streaming and messaging system. Acts
as data collector: Collects data from various
source and aggregates to common format.
Built on top of Scala and Java. Kafka allows
to have separation of concern in application
level.

67. RabbitMQ:
 Open source message broker platform.
Receives messages from brokers and pushes
them to the registered consumers.
 The broker pushes messages—which are
queued in random order—toward the
consumers. Brokers are persistently
connected to consumer, and they know
which ones are subscribed to which queues.
Consumers cannot fetch specific messages,
but can receive them unordered unaware of
the queue state
 Messages, queues, and exchanges do not
persist unless otherwise instructed.
 If a broker is restarted or fails, the messages
are lost
 Has settings to make both queues and
messages durable. Moreover, non-critical
messages can be tagged by the producer to not
be sent to a durable queue
 Allows producers’ and consumers’ code to
declare new queues and exchanges. Several
replication and load balancing alternatives
 Message Patterns:
 Direct: Routes message to the queues which
matches the binding key
 Fanout: Broadcast messages to all queues that
are bound to it.
 Topic : Broadcast message to all queues that
are bound to it using binding keys

68. Thanks