Software Design and

Architecture

Middleware Architecture and

Technologies
What is Middleware?

 Middleware provides proven ways to connect the various software

components in an application so they can exchange information using
relatively easy-to-use mechanisms. Middleware provides the pipes for
shipping data between components, and can be used in a wide range of
different application domains.
 Middleware can be used to wire together numerous components in useful,
well-understood topologies. Connections can be one-to-one, one to many
or many-to-many.
 From the application user’s perspective, middleware is completely hidden.
Users interact with the application, and don’t care how information is
exchanged internally. As long as it works, and works well, middleware is
invisible infrastructure.
 The only time application users are ever aware of the role middleware
plays is when it fails. This is of course very like real plumbing and wiring
systems!
What is Middleware?
 Layer between OS and distributed applications
 Hides complexity and heterogeneity of distributed system
 Bridges gap between low-level OS communications and programming
language abstractions
 Provides common programming abstraction and infrastructure for
distributed applications

DistributedApplications
Distributed Applications
Distributed Applications

Middleware (remote calls, object invocation,

messages, …)
OperatingSystem
Operating SystemComms
Comms
Operating System Comms (sockets, IP, TCP, UDP, …)
Network
Network
Network (packets, bits…)
What is Middleware?
 Middleware provides support for:
 Location, Service discovery

 Protocol handling, Communication faults, QoS

 Synchronisation, Concurrency, Transactions

 Access control, Authentication

 Middleware dimensions:
 Request/Reply vs. Asynchronous Messaging
 Language-specific vs. Language-independent
 Proprietary vs. Standards-based
 Small-scale vs. Large-scale
 Tightly-coupled vs. Loosely-coupled
components
Why Middleware
Why Middleware
Remote Procedure Calls (RPC)
RPC
Distributed Objects: CORBA
 Common Object Request Broker Architecture
 Open standard by the OMG

 Language and platform independent

• Object Request Broker (ORB)

– General Inter-ORB Protocol (GIOP) for communication
– Interoperable Object References (IOR) contain object location
– CORBA Interface Definition Language (IDL)
• Stubs (proxies) and skeletons created by IDL compiler
– Dynamic remote method invocation
Distributed Objects: CORBA
CORBA IDL

IDL interface defines a CORBA object that supports a single

method, which returns a string and takes no parameters.
An IDL compiler is used to process interface definitions. The
compiler generates an object skeleton in a target programming
languages (typically, but not necessarily, C++ or Java).
The object skeleton provides the mechanisms to call the servant
implementation’s methods. The programmer must then write the
code to implement each servant method in a native programming
language.
Distributed Objects: CORBA
Client ORB: Services Selection

A client process initialize a client ORB and get a reference to the

servant.
Servants typically store a reference to themselves in a directory.

Clients query the directory using a simple logical name, and it

returns a reference to a servant that includes its network location
and process identity.
the ORB transmit, or marshal, the request and associated
parameters across the network to the servant. The method code
executes, and the result is marshaled back to the waiting client.
Distributed Objects: CORBA
Additional Concerns

Requests to servants are remote calls, and hence relatively expensive

(slow) as they traverse the ORB and network. This has a performance
impact. It’s always wise to design interfaces so that remote calls can
be minimized, and performance is enhanced.
Like any distributed application, servers may occasionally or
permanently be unavailable due to network or process or machine
failure. Applications need strategies to cope with failure and
mechanisms to restart failed servers.
If a servant holds state concerning an interaction with a client (e.g. a
customer object stores the name/address), and the servant fails, the
state is lost. Mechanisms for state recovery must consequently be
designed.
Message-Oriented Middleware
(MOM)
• MOM is one of the key technologies for building large-scale enterprise
systems.
• It is the glue that binds together otherwise independent and autonomous
applications and turns them into a single, integrated system. These
applications can be built using diverse technologies and run on different
platforms.
• Users are not required to rewrite their existing applications or make
substantial changes just to have them play a part in an enterprise-wide
application.
• This is achieved by placing a queue between senders and receivers,
providing a level of indirection during communications.
Message-Oriented Middleware
(MOM)
 Communication using messages
 Messages stored in message queues
 Message servers decouple client and server

Client App. Server App.

Message Servers

local message message local message

queues queues queues

Network Network Network

Properties of MOM
Asynchronous interaction
 Client and server are only loosely coupled

 Messages are queued

 Good for application integration

Support for reliable delivery service

 Keep queues in persistent storage

Processing of messages by intermediate message server(s)

 May do filtering, transforming, route, …
MOM Features
MOM Server
 MOM is often implemented as a server that can handle messages
from multiple concurrent clients.
 In order to decouple senders and receivers, the MOM provides
message queues that senders place messages on and receivers
remove messages from.
 A MOM server can create and manage multiple messages queues,
and can handle multiple messages being sent from queues
simultaneously using threads organized in a thread pool.
 One or more processes can send messages to a message queue, and
each queue can have one or many receivers.
 Each queue has a name which senders and receivers specify when
they perform send and receive operations.
MOM Features
MOM Server
 MOM server must accept a message from the sending application,
and send an acknowledgement that the message has been received.
 It must place the message at the end of the queue that was specified
by the sender. A sender may send many messages to a queue before
any receivers remove them. Hence the MOM must be prepared to
hold messages in a queue for an extended period of time.
 Messages are delivered to receivers in a First-In-First-Out (FIFO)
manner, namely the order they arrive at the queue. When a receiver
requests a message, the message at the head of the queue is
delivered to the receiver, and upon successful receipt, the message
is deleted from the queue.
MOM Features
MOM Message Delivery
Reliable message delivery comes at the expense of performance. MOM
servers offer a range of quality of service (QoS) options to balance
performance.
 Best effort: Undelivered messages are only kept in memory on the
server and can be lost if a system fails before a message is delivered,
network outages, unavailable receiving applications, messages time
out.
 Persistent: The MOM layer guarantees to deliver messages despite
system and network failures. Undelivered messages are logged to
disk as well as being kept in memory and so can be recovered and
subsequently delivered after a system failure.
 Transactional: Messages can be bunched into “all or nothing” units
for delivery. Also, message delivery can be coordinated with an
external resource manager such as a database.
Persistent Message Delivery
Transactional Message Delivery
MOM Features
MOM Clustering

 MOM servers are the primary message exchange mechanism in

many enterprise applications.
 If a MOM server becomes unavailable due to server or machine
failure, then applications can’t communicate.
 MOM technologies provide cluster MOM servers, running instances
of the server on multiple machines
 Multiple instances of MOM servers are configured in a logical
cluster. The distribution of these queues across servers is transparent
to the MOM clients.
 MOM clients behave exactly the same as if there was one physical
server and queue instance. When a client sends a message, one of the
queue instances is selected and the message stored on the queue.
A cluster has two benefits.
•First, if one MOM server fails, the other queue instances are still available
for clients to use. Applications can consequently keep communicating.
•Second, the request load from the clients can be spread across the
individual servers. Each server only sees a fraction of the overall traffic.
This distributes the messaging load and thus provide much higher
application performance and scalability.
Publish/Subscribe

 Publishers (advertise and) publish events (messages)

 Subscribers express interest in events with subscriptions
 Event Service notifies interested subscribers of published events

subscribe
publish
Publisher notify Subscriber
Event Service
(event-broker subscribe
Publisher publish notify Subscriber
network)
subscribe
Publisher publish notify Subscriber
Topic-Based and Content-
Based Pub/Sub
 Event Service matches events against subscriptions
 What do subscriptions look like?

Topic-Based Publish/Subscribe
– Publishers publish events belonging to a topic or subject
– Subscribers subscribe to a topic
subscribe(PrintJobFinishedTopic, …)

(Topic and) Content-Based Publish/Subscribe

– Publishers publish events belonging to topics and
– Subscribers provide a filter based on content of events
subscribe(type=printjobfinished, printer=‘aspen’, …)
Properties of
Publish/Subscribe
Asynchronous communication
• Publishers and subscribers are loosely coupled

Many-to-many interaction between pubs. and subs.

• Scalable scheme for large-scale systems
• Publishers do not need to know subscribers, and vice-versa
• Dynamic join and leave of pubs, subs

(Topic and) Content-based pub/sub very expressive

• Filtered information delivered only to interested parties
• Efficient content-based routing through a broker network
Application Servers

 An application server is a component based server technology that resides in the

middle-tier (business component tier) of an N-tier architecture
 It provides distributed communications and security
 They are widely used to build internet based applications
 The business components comprise the core business logic for the application.
 The business components receive requests from the web tier, and respond to
requests usually by accessing one or more databases, returning the results to the
web tier.
 The container supplies a number of services to the components.
 These varying depending on the container type (e.g. EJB, .NET, CORBA), but
include component lifecycle management, state management; security,and
multithreading.
 The components rely on the container to provide the services. This frees the
application programmer from cluttering the business logic with code to handle
system and environmental issues.
Java Application Servers

 A Java application server provides an execution environment for server-side Java

application components.
 It delivers a high-performance, highly scalable, robust execution environment
specifically suited to support Internet enabled application systems.
 The Enterprise JavaBeans architecture defines a standard model for Java
application servers to support “Write Once, Run Anywhere” portability
 EJB completely portable across any different vendor’s application server. The EJB
environment automatically maps the component to the underlying vendor-specific
infrastructure services.

Java Application Servers

The EJB architecture specifies the responsibilities and interactions among

EJB entities

 EJB Servers  EJB Containers

 Enterprise Beans  EJB Clients

Enterprise Enterprise
Bean Bean

EJB Container
Clients
EJB Server
Java Application Servers

 EJB Server
 The EJB Server provides system services and manages resources
 Process and thread management

 System resources management

 Database connection pooling and caching

Java Application Servers

 EJB Container
 Hosts the Enterprise JavaBeans
 Provides services to Enterprise JavaBeans
 Naming

 Life cycle management

 Persistence (state management)

 Transaction Management

 Security

Likely provided by server vendor

Java Application Servers

 Enterprise JavaBeans
 A specialized Java class where the real business logic lives
 Distributed over a network
 Transactional
 Secure
 Server vendors provide tools that automatically generate
distribution, transaction and security behavior
Java Application Servers

Enterprise Clients
Client access is controlled by the container in which the enterprise

Bean is deployed
Clients locates an Enterprise JavaBean through Java Naming and

Directory Interface (JNDI)

Java Application Servers

EJB Application
Clients Web Server
Server
CICS Programs

Browser EJB Container

Credit Card

Servlet Shopping
Databases
Cart

Inventory
Application

SAP Modules
EJB Server
Message Broker

 MOM deployments start to get a little more complex though

when message formats are not totally agreed amongst the
various applications that communicate using the MOM.
 This problem occurs commonly in the domain of enterprise
integration, where the basic problem is building business
applications from large, complex legacy business systems that
were never designed to work together and exchange
information.
Message Broker
Message Broker

 Each legacy system has a queue interface component that can read
messages from the queue, and using the data in the message, create
a call to the customer data update API that the legacy system
supports.
Message Broker
 If the common In-format message format changes, then the web
component and every legacy system component that executes the
transformation must be modified and tested.