Topic2 Understanding Middleware
Upcoming SlideShare
Loading in...5
×
 

Topic2 Understanding Middleware

on

  • 4,707 views

 

Statistics

Views

Total Views
4,707
Views on SlideShare
4,700
Embed Views
7

Actions

Likes
1
Downloads
278
Comments
0

1 Embed 7

http://www.slideshare.net 7

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Topic2 Understanding Middleware Topic2 Understanding Middleware Presentation Transcript

  • 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 Middleware
    • Offers 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 Middleware
    • RPC-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 scenario
    • Message-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 Efficient Tightly Coupled Not possible to use dynamic load balancing The directory server can assist in load balancing Decoupling leads to flexibility There is additional cost of implementation
  • RPC functioning with Dynamic binding Sanjoy Sanyal (Tech for NonGeek) Client Procedure Call Client Stub Bind Marshal Serialize Client Process Communication Module Name and directory service (binder) Query for server implementing the procedure Address of server Server Procedure Server Process Server Stub Register Un-marshal De-serialize Receive Dispatch Communication Module Register server and procedure
  • Asynchronous Extension to RPC
    • Conventional RPC uses a synchronous, procedural call
    • Asynchronous RPC allows the client thread not to be blocked
      • The 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 middleware
    • Implementations:
      • IBM (CICS), BEA (Tuxedo), Microsoft (MTS)
    • Main goal is to support execution of distributed transactions
      • Here 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 server
      • Seq. 4: When EOT is reached, the client stub notifies that transaction manager
      • Seq. 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 commit
      • By saying that it is ready to commit a server guarantees that it will be able to commit the procedure even if failures occur subsequently
      • If 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) Client 1.BOT 4. Procedure call 10. EOT Client Stub 2. Register txn and create context 5. Add txn id and context to call 11. Request commit 14. Confirm termination Client Process Server 9. procedure Server Process Server Stub 6. 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 id Run 2PC Notify client of outcome 8. Lookup txn id Register 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 databases
      • Done using stored procedures where application logic is written within the scope of the database
    Sanjoy Sanyal (Tech for NonGeek)
  • TP Monitor Functionality Sanjoy Sanyal (Tech for NonGeek) Functionality 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
  • 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 Group
    • Distributed 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 distributed documents information management systems management Vertical facilities horizontal facilities CORBA facilities naming transactions events lifecycle time relationships properties licensing trader concurrency query security startup externalization collection 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 distribution
      • Stub 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 ORB Applications 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 properties Clients 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 OS
    • Neither needs to know in which language/environment the object has been implemented
    • All a client needs to know is the Server’s IDL specification
      • All 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) Client Service Provider Message-Oriented Middleware (MOM) Client Service 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 Queues
    • Messages 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 System
    • Queuing 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 storage
    • Can 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 Sanjoy Sanyal (Tech for NonGeek) 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….)
  • Summary
    • 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)
    Sanjoy Sanyal (Tech for NonGeek)