Bài giảng Kiến trúc phần mềm - Chương: Middleware - Trần Minh Triết

 Trường Đại học Khoa Học Tự Nhiên
 Khoa Công Nghệ Thông Tin
 Bộ môn Công Nghệ Phần Mềm
 CTT526 - Kiến trúc phần mềm
 Middleware
 PGS.TS. Trần Minh Triết
 tmtriet@fit.hcmus.edu.vn
Version 1.0
 Nội dung của bài giảng sử dụng:
 Session 4:
 A Guide to Middleware Architectures and Technologies
 trong bộ slide Software Architecture Essential
 của GS. Ian Gorton 
 Software Engineering Institute
 Carnegie Mellon University
 2
 Introduction
 Middleware is the plumbing or wiring of IT 
 applications
 Provides applications with fundamental services for 
 distributed computing
 Insulates applications from underlying platform 
 (OS, DBMS, etc) APIs
 Lots of middleware exists
 Different purposes
 Different vendors
 Different standards and proprietary technologies
 3
 Middleware Classification
Business Process Orchestrators BizTalk, TIBCO StaffWare, ActiveBPEL
 Message Brokers BizTalk, WebSphere Message Broker, SonicMQ
 Application Servers J2EE, CCM, .NET
 Transport Message-Oriented Middleware, Distributed Objects Systems
 4
 Outline
 CORBA
 Message-oriented middleware
 J2EE
 Message brokers
 Business process orchestrators
 5
 CORBA
 Venerable distributed object technology
 Still widely used in telecomms, defense
 Many different implementations
 Client Server
 Object Reference Servant
 request reply
 client ORB server ORB
 Network
 6
 CORBA Code Example
module ServerExample 
{ CORBA IDL
interface MyObject { string isAlive(); };
}; 
 class MyServant extends _MyObjectImplBase 
 Server { public String isAlive() { return "\nLooks like it\n"; }
 } 
 ORB orb = ORB.init(args, null);
 MyServant objRef = new MyServant();
 orb.connect(objRef); 
 ORB orb = ORB.init(args, null);
 // Lookup is a wrapper that actually access the CORBA Naming Client
 // Service directory – details omitted for simplicity
 MyServant servantRef = lookup(“Myservant”)String 
 reply = servantRef.isAlive(); 
 7
 CORBA – Some Thoughts
 Many associated services, eg
 Naming 
 Notification
 Transactions
 Synchronous technology, client-server relatively tightly 
 coupled
 Remote calls can/will fail
 State management in server objects creates 
 „interesting‟ recovery issues
 8
 Messaging - MOM
 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
 9
 Basic Messaging
 Send (queue, message)
  Put message onto queue
 Receive (queue, message)
  Get message from queue
 No dependency on state of receiving 
 application on message send
 send receive
 queue
 10
 queuePersistence
 send receive
 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
 11
 MOM Server
 Senders Receivers
 Sending Sending 
 Applications Applications
 Message 
 Handler Thread Pool
 MOM Server
Peer-to-peer MOM technologies are the alternative design
 12
 MOM Transactions
Begin transaction Begin transaction 
... ... 
update database record get message from queue 
put message on queue update database record 
... ... 
commit transaction commit transaction 
 13
 MOM Transactions
 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
 Request queue
 send receive
 receive send
 Response queue
 14
 Scaling MOM
 MOM Server
 ApplicationQ
Senders Receivers
 MOM Server
 ApplicationQ
 15
 Messaging – Some thoughts
 Highly attractive asynchronous technology
 Supports loosely-coupled, dynamic applications 
 Scales well, high throughput possible
 Many implementations, various qualities of service
 caveat emptor
 16
 Publish-Subscribe Messaging
 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
 Sub
 Create/
 Publish Register/
 Pub Subject Subscribe Sub
 Sub
 17
Publish-Subscribe with Multicast
 S u b s c r ib e r S u b s c r ib e r 
 r v d r v d r v r d 
 Based on 
 TIBCO 
 P u b lis h e r Rendezvous
 r v d r v r d 
 r v d r v d r v d 
 S u b s c r ib e r S u b s c r ib e r S u b s c r ib e r 
 18
 Performance
Milliseconds
 700
 600
 500
 M C 1
 400
 M C 2
 300
 QB
 200
 100
 0
 10 20 30 40 50
 No. Of Subscribers
 19
 Subject/Topic Naming
 Sydney
 DevGroup SupportGroup
 Information Information
 work gossip work gossip
Sydney
Sydney/DevGroup Sydney/*/Information
Sydney/DevGroup/Information Sydney/DevGroup/*/*
Sydney/DevGroup/Information/work Sydney/DevGroup/**
Sydney/DevGroup/Information/gossip
Sydney/SupportGroup
Sydney/SupportGroup/Information
Sydney/SupportGroup/Information/work
Sydney/SupportGroup/Information/gossip
 20
 Publish-Subscribe – Some 
 Thoughts
 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
 21
 J2EE Overview
 Client tier W e b T ie r Business Component tier E IS T ie r
 HTTP W e b RMI
 s e rv e r
 S e rv le ts , Application com ponents
 Browser-based client J S P s E J B s JCA
 applications
 (HTML, applets,
 DHTML/scripting)
 J a v a R M I E R P s , C R M s ,
 Mainframe TP systems
Java client applications Container Services
 C o m p o n e n ts
 eg. JTS, JMS JDBC
 RDBMS
 CAS COM Bridge, RMI over IIOP
 W indows/COM client
 applications
 22
 J2EE Application Server
 In J2EE, the application server container provides the 
 execution environment for the J2EE-specific 
 components
 EJBs
 Message-driven beans
 Connectors
 Container provides additional services for hosted 
 components
 Transactions
 Security
 Directory
 Threading
 Connection pooling
 23
 EJB Container
 Application Server
 EJB Container
 EJB Pool Transaction
 Service
 Directory
Lifecycle Management Service
 Persistence 
 Security
 Connection Pool
 Service
 Thread Pool
 24
 Beans and State
 state
 EJB Container
 Stateless bean pool state
 state
 state
 EJB
 Clients 
 state
 state
Stateful beans 
 state
 25
 Deployment Descriptors
 EntityStock.BrokerHome
 db.entitystock.BrokerHome
 db.entitystock.Broker
 db.entitystock.BrokerBean
 Stateless
 Container
 EntityStock.BrokerHome
 Remote
 *
 Required
 26
 J2EE – Some Thoughts
 Standards-based, multiple vendors, portable
 Good open source technology available
 Quality of implementations varies considerably
 Java only, wide platform support
 Performance is good, but varies between suppliers
 Scalable, fail over support through clustering
 Good integration with web technologies
 Supports various design patterns, flexible but more 
 complex (e.g. stateful beans/scalability, entity beans)
 Standards evolving, need to monitor
 27
 Message Brokers - Motivation
 Key: Web
 Message = Component
 In-format
 In-format In-format In-format In-format
 Legacy Legacy Legacy Legacy 
 System #1 System #2 System #3 System #4
 Queue API
 Read Message call
 Transform Legacyformat
In-format
 28
 What if 
 the common In-format message format changes?
 any legacy system API changes?
 any of the transformations needs modifying? 
 29
 Alternative Solution
Key: Web
Message = Component Transformations in 
 In-format broker
 Simplified 
 Message
 Broker endpoints
 Decouples Web 
 and legacy 
 components
 L1-format L2-format L3-format L4-format
Legacy Legacy Legacy Legacy 
System #1 System #2 System #3 System #4
 30
 Message Brokers
 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
 31
 Message Broker Features
 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
 Application programming environment
 32
 Message Brokers
 Hub and Spoke Architecture
Input Messages Output Messages
 Transformation
 Routing
 Rules Processing
 33
Example - WMQI
 34
BizTalk Mapping Tool
 35
 Adapters
 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
 36
 Message Brokers – Some 
 Thoughts
 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
 Good open source, standards-based like Mule now 
 available
 37
 Business Process Orchestration
 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
 38
 Typical Scenario
 Business process automation
 Credit
 Validation
 Accounts
 Customer Siebel Payable
 Purchasing
 Shipping
 Sales desk
 Accounts
 Receivable
 Oracle
 SAP
 Customer
 Receiving
 39
Example - BizTalk
 40
 BPO Architecture
 Message Broker
Adapter Adapter Adapter
 41
 BPEL
 Web Services standard for describing workflows
 Many design and execution tools
 Eg ActiveBPEL
 Version 2.0 is a significant improvement
 42
 Integration Issues – Point-to-Point
 Point-to-Point evolution 
 Spaghetti architecture, hard to modify potentially (N2-N) 
 interfaces
 1 business process = 5 business processes = 
 4 interfaces 20 interfaces
 43
 Broker Spaghetti
 No free lunch 
 Just relocates the spaghetti
 message broker
 44
 Enterprise Data Model
 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
 45
 Summary
 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
 46