a guide to middleware architectures and technologies by eng. mohanned m. dawoud

A Guide to Middleware Architectures and

TechnologiesBy

Eng. Mohanned M. Dawoud

Middleware is the plumbing or wiring of IT applications provides proven ways to connect the various software

components in an application. can be used to wire together numerous components in

useful, well-understood topologies. From the application user’s perspective, middleware is

completely hidden. 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.

Business Process Orchestrators

Message Brokers

Application Servers

Transport Message-Oriented Middleware, Distributed Objects Systems

J2EE, CCM, .NET

BizTalk, WebSphere Message Broker, SonicMQ

BizTalk, TIBCO StaffWare, ActiveBPEL

Common Object Request Broker Architecture (CORBA)

Message-oriented middleware J2EE Message brokers Business process orchestrators

Venerable distributed object technology Many different implementations

Network

Client

Object Referencerequest

Server

Servantreply

client ORB server ORB

Requests to servants are remote calls, and hence relatively expensive (slow).

Like any distributed application, servers may be unavailable due to network or process or machine failure.

If a servant holds state concerning an interaction with a client and the servant fails, the state is lost.

State management in server objects creates ‘interesting’ recovery issues

Basic Message Oriented Middleware (MOM) provides features like: Asynchronous communications between

processes, applications and systems Send-and-forget

Delivering messages despite failures Transactional Messaging

Deliver all messages in a transaction, or none Persistence

Messages can be logged at the server and hence survive server failure

Send (queue, message) Put message onto queue

Receive (queue, message) Get message from queue

No dependency on state of receiving application on message send

receivesend

queue

Best effortThe MOM server will do its best to deliver the message.

PersistentThe MOM layer guarantees to deliver messages despite system and network failures

Transactional Messages can be bunched into “all or nothing” units for delivery.

Receipt of message at queue implies message is written to disk log

Removal of message from queue deletes message from disk log

Trade-off performance versus reliability

Sender and receiver do *not* share a transaction Rollback on receiver does not affect the sender

(already committed) ‘Synchronous’ operations are not atomic

Request/response is 3 transactions not 1 Put to request queue Get from request queue, put to response queue Get from response queue

receivesend

Request queue

Response queuesendreceive

MOM Server

Senders Receivers

MOM Server

ApplicationQ

ApplicationQ

MOM Server

Senders Receivers

MOM Server

ReplayQ

RequestQ

Highly attractive asynchronous technology

Supports loosely-coupled, dynamic applications

Scales well, high throughput possible Many implementations, various qualities

of service

Extension of MOM to provide 1-to-N, N-to-1, and N-to-N communications

Messages are ‘published’ to logical subjects or topics Subscribers receive all messages from subjects they

subscribe to

Pub Subject

Sub

Sub

SubCreate/Publish Register/

Subscribe

rvd

rvd

Publisher

Subscriber

rvd

Subscriber

rvd

Subscriber

rvrd

rvd

Subscriber

rvd

Subscriber

rvrd

Based on TIBCO Rendezvous

0100200300

400500600700

10 20 30 40 50No. Of Subscribers

Milliseconds

MC1

MC2

QB

Sydney

DevGroup SupportGroup

InformationInformation

work gossip work gossip

SydneySydney/DevGroupSydney/DevGroup/InformationSydney/DevGroup/Information/workSydney/DevGroup/Information/gossipSydney/SupportGroupSydney/SupportGroup/InformationSydney/SupportGroup/Information/workSydney/SupportGroup/Information/gossip

Sydney/*/InformationSydney/DevGroup/*/*Sydney/DevGroup/**

Highly decoupled messaging style Publishers don’t know about subscribers Subscribers don’t know who is publishing Publishers and Subscribers can dynamically

appear and disappear Issues –

Reliability Transactions Security Performance

There are many definitions for application servers, but all pretty much agree on the core elements.

An application server is a component-based server technology that resides in the middle-tier of an N-tier architecture,.

It provides distributed communications, security, transactions and persistence.

Client Tier: In a web application, the client tier typically comprises an Internet browser that submits HTTP requests and downloads HTML pages from a web server.

Web Tier: The web tier runs a web server to handle client requests.

Business Component Tier: Receive requests from the web tier, and satisfy requests usually by accessing one or more databases, returning the results to the web tier.

Enterprise Information Systems Tier: This typically consists of one or more databases and back-end applications like mainframes and other legacy systems.

WebComponent

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

In-format

In-format In-format In-format In-format

Key:Message =

In-format

Message Transform Legacyformat

APIcall

QueueRead

the common In-format message format changes?

any legacy system API changes? any of the transformations needs

modifying?

WebComponent

Legacy System #1

Legacy System #2

Legacy System #3

Legacy System #4

In-format

L1-format L2-format L3-format L4-format

Key:Message =

MessageBroker

Transformations in broker

Simplified endpoints

Decouples Web and legacy components

Developed specifically for Enterprise Application Integration (EAI)

Add new layers of functionality to MOM Message transformation Rules engine Intelligent routing Adapters

Typically (but not necessarily) built on top of a MOM layer

Message transformation – transform between different source/target formats Graphical message format definition and mapping

tools High performance transformation engines Message format repositories

Intelligent routing Route messages based on message content

Rules Engine Scripting language, built-in functions

Transformation

Routing

Rules Processing

Input Messages Output Messages

Hub and Spoke Architecture

An adapter is a component that resides between the message broker and the source/target systems

Simplify complexity of end system interface through an abstraction layer

Thin adapters - simple wrappers Thick adapters

Programmable Abstract representation of services and meta-data

Centralized adapters co-located with broker Distributed adapters execute in own process

and may be located with source/target system

Embeds transformations/routing in broker Can get complex

Possible scaling issues Need to replicate brokers

Failure handling Lightweight, rarely designed to recover from

failure Often proprietary technology

Commonly known as workflow Aim is to automate business processes which

need to access data and business logic across disparate back-end applications

Builds on EAI to ensure business processes are executed in the defined order using the required data

Builds on middleware providing: Process execution engine Visual process definition tools Process monitoring tools

Business process automation

CustomerPurchasing

SAPCustomerReceiving

Siebel

Sales deskShipping

CreditValidation

AccountsPayable

AccountsReceivable

Oracle

Point-to-Point evolution Spaghetti architecture, hard to modify potentially (N2-

N) interfaces

1 business process = 4 interfaces

5 business processes = 20 interfaces

No free lunch … Just relocates the spaghetti

message broker

Source sends message to target with common message format as payload.

Target receives message and transforms common format into its own local data representation.

2xN transformations, no broker needed Getting agreement is the tough bit …

Enterprise Data Model

Middleware: makes building complex, distributed, concurrent

applications simpler. institutionalizes proven design practices by

supporting them in off-the-shelf middleware technologies.

Architect’s job is to ‘mix n’match’ technologies to create appropriate solutions Analyze trade-offs Open-minded (no hammer/nail thinking) No good/evil, its just technology