Topic2 Understanding Middleware
-
Upload
sanjoysanyal -
Category
Technology
-
view
3.775 -
download
5
Transcript of Topic2 Understanding Middleware
Middleware
Sanjoy Sanyal (Tech for NonGeek)
Middleware
Middleware facilitates and manages the interaction between applications across heterogeneous computing platforms
Three different aspects:Middleware in sub-systems that are
physically close to each other Middleware in systems that are completely
different applications Middleware in Web applications
Sanjoy Sanyal (Tech for NonGeek)
In this section we are going into detail on the first aspect
Understanding MiddlewareOffers programming abstractions that hides the complexities
of bridging between heterogeneous platforms Middleware implements the functionality of the abstraction
Sanjoy Sanyal (Tech for NonGeek)
Remote Procedure Call
Sockets
TCP/UDP
IP
A simple example
Remote Procedure Call: Hides communication details behind a procedure call
Sockets: operating system level interface to the underlying communication protocols
Underlying communication protocol
Types of MiddlewareRPC-based systems
Infrastructure to transform procedure calls to remote procedure calls
TP monitors At a basic level, RPC with transactional capability
Object brokers Platforms to support invocation of remote objects
Object monitors Convergence of TP Monitors and Object brokers in a OO
scenarioMessage-oriented middleware
Queuing systems for asynchronous interactions Message brokers
Application logic to transform and filter messages in queues
Sanjoy Sanyal (Tech for NonGeek)
Developing Distributed Applications with RPC
Sanjoy Sanyal (Tech for NonGeek)
Client Code
Client Stub
Language specific call interface
Development Environment
IDL Compiler
IDL Sources
Interface headers
IDL
Server Stub
Language specific call interface
Server Code
Client Process
Step 1: Define the interface for the procedure. This is done using an interface definition language (IDL). The IDL provides an abstract representation of the procedure in terms of input and output parameters.
Step 2: Compile the IDL description.
Client Stub is a piece of code compiled and linked to client
When a client makes a remote call the stub takes care of:-Locating the server (binding)-Formatting the data (Marshalling and serilaizing)
The stub is a proxy for the procedure implemented by the server
Server Stub implements the Server side of the invocation
-Receives the invocation from the client stub-Formats the data (unMarshalling and de- serilaizing)-Invokes the actual procedure call at the server -Forwards the results to the client stub
Binding in RPC
Client creates a local association (handle to) a server
Static Binding Client stub is hardcoded to already contain the
handle of the server where the procedure lies Dynamic binding
Uses a name and a directory server to resolve server addresses based on signature of procedures
Sanjoy Sanyal (Tech for NonGeek)
Static Binding Dynamic Binding
Simple and EfficientTightly CoupledNot possible to use dynamic load balancing
The directory server can assist in load balancing Decoupling leads to flexibilityThere is additional cost of implementation
RPC functioning with Dynamic binding
Sanjoy Sanyal (Tech for NonGeek)
ClientProcedure
Call
Client StubBind
Marshal Serialize
Client Process
Communication Module
Name and directory service (binder)
Query for server implementing the procedure
Address of server
ServerProcedure
Server Process
Server Stub
Register Un-
marshalDe-
serializeReceive Dispatch
Communication Module
Register server and procedure
Asynchronous Extension to RPC Conventional RPC uses a synchronous, procedural callAsynchronous RPC allows the client thread not to be
blockedThe communication handle returns control to the client
program immediately after sending request How this works?
The stub provides two entry points – one to invoke the procedure and one to obtain the results of the invocation
The stub extracts the input parameters from a client call and returns control to client
The stub makes a call to server and waits for a response Later the client makes a second call for the resuts
Sanjoy Sanyal (Tech for NonGeek)
RPC Middleware Extension: DCE
Distributed Computing Environment (DCE) provided by the Open Software Foundation (OSF)
Provides RPC with additional services:
Sanjoy Sanyal (Tech for NonGeek)
Additional Service Description
Cell directory server Sophisticated name and directory server used to create and manage RPC domains that can exist over the same network
Time Service Provides mechanisms for clock synchronization across all nodes
Thread service Support to thread and mutiple processors
Distributed File Service Support to sharing of data files
Security Service Support for authentication and secure communication
TP Monitors For long the dominant form of middlewareImplementations:
IBM (CICS), BEA (Tuxedo), Microsoft (MTS)Main goal is to support execution of distributed
transactionsHere there are > 1 entity and > 1 procedure calls
Conventional RPC treats the procedure calls (wrongly) as independent
TP monitors extend the RPC protocol with the ability to wrap a series of RPC invocations into a transaction so if…… group of procedure calls is committed all have been… group of procedure calls is aborted , as if is that all
have been
Sanjoy Sanyal (Tech for NonGeek)
TP Monitors: How it works?
Procedure calls enclosed within transactional brackets (BOT & EOT) are treated as one unit.
A transaction management module coordinates interaction between clients and servers
Sanjoy Sanyal (Tech for NonGeek)
Seq. 1: When it encounters a BOT, the Client Stub contacts the transaction manager to create a transactional identifier and a transactional context for the sequence of calls. Seq. 2: When the Client calls one of the Servers, the server stub extracts the transactional identifier and notifies the transaction manager that it is participating and forwards the call as a normal call. Seq. 3: The same is done when the client invokes a second serverSeq. 4: When EOT is reached, the client stub notifies that transaction managerSeq. 5: The transaction manager initiates a two-phase commit (2PC) protocol to determine the outcome of the transaction Seq. 6: The transaction manager informs the client stub once the protocol terminates
2 PC Protocol
Standard mechanism for guaranteeing atomicity in distributed information systems
First a part of CICS and then standardized by the Open Group within the X/Open Specification
Sanjoy Sanyal (Tech for NonGeek)
The transaction manager executes the commit in two phases:
Phase 1: It contacts each server involved in the transaction by sending a prepare to commit message asking whether the server is ready to execute a commitBy saying that it is ready to commit a server guarantees that it will be able to commit the procedure even if failures occur subsequentlyIf the server could not complete the transaction it replies abort Phase 2: The transaction manager examines all the replies received and if all of them are “ready to commit” it instructs each server to commit the changes performed If there is at least one abort (or a lack of responses) it instructs all servers to abort the transaction
Fault tolerance is achieved through logging (writing the state of the protocol to persistent storage)
Transactional RPC
Sanjoy Sanyal (Tech for NonGeek)
Client1.BOT4. Procedure call10. EOT
Client Stub2. Register txn and create context5. Add txn id and context to call 11. Request commit14. Confirm termination
Client ProcessServer
9. procedure
Server Process
Server Stub6. Extract context and txn id 7. Register server for txn 13. Participate in 2PC
Register server and procedure
Transaction manager
3. Create txn id Register txn Regsiter txn for client Return txn id
8. Lookup txn idRun 2PCNotify client of outcome
8. Lookup txn idRegister server for txn
TP-lite and heavy
TP-heavy systems provide rich tools and middleware functionality
TP-lite systems are implemented as a 2-tier system to provide an RPC interface to databasesDone using stored procedures where
application logic is written within the scope of the database
Sanjoy Sanyal (Tech for NonGeek)
TP Monitor FunctionalityFunctionality Description
RPC Support IDLs, name and directory servers, security and authentication, stub compilers ….
Programming abstraction deal with T-RPC
BOT, EOT, and may include additional callback and workflow mechansisms (on commit, on abort)
Transactional Manager for implementing TRPC
Transaction Manager functionality: logging, recovery, locking
Monitor Systems Scheduling threads, assigning priorities, load balancing, replication, starting and stopping components
Run-time environment Provides the resources and services applications may need (transactional services, security services, transactional file systems…)
Specialized Components
Ranging from proprietary protocols for interacting with mainframes to persistent queuing systems for asynchronous interaction
Tools For installing, managing and monitoring the performance of all components
Sanjoy Sanyal (Tech for NonGeek)
Object Brokers
Middleware infrastructure that support the development of distributed object-oriented applications
CORBA (Common Object Request Broker Architecture) is the most common example Developed in the early 1990s by the Object
Management GroupDistributed Component Object Model
(DCOM) and COM+ specific to Microsoft is another example
Sanjoy Sanyal (Tech for NonGeek)
CORBA: System Architecture
Sanjoy Sanyal (Tech for NonGeek)
Object Request Broker
financials Supply chain
distributeddocuments
information management
systemsmanagement
Vertical facilities
horizontal facilities
CORBA facilities
naming transactions events lifecycle time relationshipsproperties licensing
trader concurrency query security startupexternalizationcollection persistence
User Defined Objects
How CORBA works
Objects declare their interface so that clients are aware of the methods it provides
Mechanisms used are similar to RPC and support OO concepts such as inheritance/polymorphism
IDL compiler generates a stub and a skeleton which hide the distributionStub is a proxy object that makes method
calls in the client look like they are local Skeleton similarly shields the server object
Sanjoy Sanyal (Tech for NonGeek)
Dynamic Service Selection and Invocation
The IDL compiler statically generates a stub specific to a service interface
CORBA allows client applications to dynamically discover new objects, retrieve their interfaces and construct invocations of this object on the fly even if no stub has been generated and linked to the client
However, this is not used as the client object must understand service properties which requires a shared ontology between clients and service providers
Sanjoy Sanyal (Tech for NonGeek)
However, we will quickly learn how this is possible
Dynamic Service Selection and Invocation: How?
To dynamically construct a method invocation: interface repository & dynamic invocation interface components
To identify services needed by the client: Naming and Trader Services
Sanjoy Sanyal (Tech for NonGeek)
Interface Repository Dynamic Invocation Interface
Stores IDL definitions for all objects known to the ORBApplications can access the repository to browse, edit or delete IDL interfaces
Provides operations such as get_interface and create_request that can be used by clients to browse the repository and dynamically construct the method invocation Naming Service Trading Service
Allows for retrieval of object references based on the name of the service needed Clients are able to look for objects implementing a certain interface (Purchasing books)
Allows for retrieval of services based on their propertiesClients are able to look for objects which have specified values (selling history or IT books)
How CORBA works
Sanjoy Sanyal (Tech for NonGeek)
Object Request Broker
Dynamic Invocation Interface
Application object (client)
IDL of service provider
stub
Application object (client)
IDL compiler (client side)
IDL compiler (server side)
Application object (service provider)
skeleton
Interface repository
CORBA: Encapsulation & Advantages Client and server objects need not be implemented
in the same language or run on the same OSNeither needs to know in which
language/environment the object has been implemented
All a client needs to know is the Server’s IDL specificationAll method calls flow thru the ORB where invocation
parameters are converted into a common data format
The data parameters are converted back at the skeleton
This allows development flexibility on both client and server sides
Sanjoy Sanyal (Tech for NonGeek)
TP Monitors
Represents the convergence of TP monitors and Object Brokers
Sanjoy Sanyal (Tech for NonGeek)
Message Oriented Middleware
Supports asynchronous forms of interaction Evolved from asynchronous versions of RPC
and queuing systems of TP monitors Well known MPM platform:
IBM WebSphere, Microsoft MSMQ, WebMethods Enterprise, CORBA messaging service
Sanjoy Sanyal (Tech for NonGeek)
MOM Basics
Message is a structured data set characterized by:A Type (typically XML) A set of <name,value> pairs
Clients and service providers communicate by exchanging messages
Sanjoy Sanyal (Tech for NonGeek)
ClientService Provider
Message-Oriented Middleware (MOM)
ClientService Provider
Message-Oriented Middleware (MOM)
Client sends a message The service provider servers the request by another message
Note : to the MOM all objects are alike the distinction between clients and service providers depends on the context
Message QueuesMessages sent by the MOM clients are placed in a
queue When the recipient is ready to process a new
message it invokes the MOM to retrieve the first message in the queue
Advantages: Recipients do not have to continuously listen for new
messages and process them right away – they do so when they can
More robust to failures – if the application is down or unable to send messages these will be stored in the queue
Queues can be shared across applications – if they provide the same service they can be used for load balancing
Sanjoy Sanyal (Tech for NonGeek)
Interacting with a Message Queuing SystemQueuing Systems provide an API that can be
invoked to send messages or to wait for and receive messages
Sending message is typically not a blocking operation receiving is
Java Programmers use a standard API to interact with MOM systems: Java Message Service (JMS)
Sanjoy Sanyal (Tech for NonGeek)
In JMS each message is characterized by: A header, which includes meta data like the message type, expiration, priority Optional properties that extend the haeder metadata attributes for example to support compatibility with specific JMS implementations A body which includes the application-specific information
Senders (receivers) first bind to a queue and then start sending (receiving) messages
Transactional Queues
Transactional queuing is also called reliable queuing
The MOM ensures that once a message is sent: it will be eventually delivered once and only once
to the intended recipient (even if the MOM goes down)
Messages are stored in a persistent storageCan be used to overcome failure situations:
A set of message retrievals and notifications are bundled within an atomic unit of operation (all or nothing)
Messages within the atomic unit are maintained by MOM and made visible for delivery only on completion of the entire operation
Sanjoy Sanyal (Tech for NonGeek)
CORBA Architecture: Explained
Component Description
Object Request Broker
Provides basic object interoperability functions
CORBA Services Provide functionality commonly needed by most objects such as persistence, lifecycle management and security Accessible thru a standardized API
CORBA facilities Provide higher level services needed by applications - Horizontal facilities: document management, internationalization, support for mobile agents - Vertical facilities: services specific to a market vertical (healthcare, education….)
Sanjoy Sanyal (Tech for NonGeek)
Summary
Sanjoy Sanyal (Tech for NonGeek)
Middleware Offers programming abstractions that hides the complexities of bridging between heterogeneous platforms
Middleware implements the functionality of the abstraction RPC provides basic form of distribution TP monitors extended RPC to become the dominant form of
middleware Object brokers tried to standardize middleware platforms in a OO
environment (superseded by J2EE and .NET) Queuing systems evolved into MOM middleware to cope with the
demands of cluster architecture and enterprise integration applications
(the material in this topic is based on Web Services: Concepts, Architectures and Applications by Alonso, Casati, Kuno, Machiraju)