a guide to middleware architectures and technologies by eng. mohanned m. dawoud
TRANSCRIPT
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