Middleware%20(contd.) - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Middleware%20(contd.)

Description:

... has been extended to Distributed COM (DCOM) using an extended version of DCE RPC ... object systems such as CORBA, DCOM, .NET, and EJB enable processes to ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 55
Provided by: sheikhiqb
Learn more at: http://www.mscs.mu.edu
Category:
Tags: contd | dcom | middleware

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Middleware%20(contd.)


1
Middleware(contd.)
2
What are the benefits of middleware?
  • Simplicity
  • In today's corporate computing environments, many
    applications have to share data.
  • Putting middleware in the middle can mean each
    application needs only one interfaceto the
    middlewareinstead of a separate interface to
    each application it needs to talk to.
  • (However, if you're connecting just two
    applications to one another, it might actually be
    more complicated to introduce middleware than
    simply coding the two apps to talk to each
    other.)
  • Persistence Middleware can capture data and hold
    on to it until it has been recorded appropriately
    by all the applications or databases that need
    the information.

3
What are the benefits of middleware? (contd.)
  • Services
  • If your data needs to be checked for integrity,
    printed out, reconciled with data from other
    applications, merged, split or reformatted,
    various kinds of middleware can handle those
    tasks efficiently.
  • This means you don't have to rewrite those
    services again and again for each application
    that uses them.
  • As middleware products evolve, the breadth of
    services they can provide grows.
  • Incidentally, vendors that sell such robust
    products often try to disassociate themselves
    with the term middleware.

4
Distributed Objects and Distributed Processing
  • Distributed objects have the biggest potential to
    solve a wide range of challenges faced by
    designers of large software systems.
  • Some of these challenges include
  • component packaging,
  • cross-language interoperability,
  • interprocess communication, and
  • intermachine communication.
  • We separate distributed object architectures into
    two categories
  • component architectures and
  • remoting architectures.
  • Component architectures focus primarily on
    component packaging and cross-language
    interoperability.
  • Remoting architectures focus primarily on support
    for remote method invocation on distributed
    objects.

5
Main Remoting Architectures
  • Open Software Foundations (OSF) Distributed
    Computing Environment (DCE)
  • which actually is a distributed processing
    environment based on the Remote Procedure Call
    (RPC) paradigm (purely procedural)
  • Object Management Groups (OMG) Common Object
    Request Broker Architecture (CORBA).
  • The notion of component packaging and deployment
    has only recently been added to CORBA 3.0.

6
DCE Architecture and Services
7
The Object Management Architecture
8
Component Architectures of distributed systems
  • Microsofts Component Object Model (COM)
  • addresses packaging and deployment of binary
    component as well as cross-language
    interoperability
  • JavaBeans and Enterprise Java Beans (EJB)
    component models introduced by SUN Microsystems.
  • Both, COM and EJB address remoting to some
    extend
  • the COM model has been extended to Distributed
    COM (DCOM) using an extended version of DCE RPC
    as transport.
  • EJB supports client/server communication based on
    Java Remote Method Invocation (RMI).
  • RMI is special as it integrates closely with the
    Java language without requiring a special
    Interface Definition Language (IDL) to describe
    component interfaces accessible for remote
    invocations.
  • In an evolutionary sense, Microsofts .NET is the
    newest and most advanced component architecture
    available in the market today.

9
Types of middleware
  • 1. Remote Procedure Call (RPC)
  • Historic interest
  • 2. Object-Oriented Middleware (OOM)
  • Java RMI
  • CORBA
  • Reflective Middleware
  • 3. Message-Oriented Middleware (MOM)
  • Java Message Service
  • IBM MQSeries
  • Web Services
  • 4. Event-Based Middleware
  • Cambridge Event Architecture

10
Remote Procedure Calls
  • Remote Procedure Calls (RPCs) enable the logic of
    an application to be distributed across the
    network.
  • Most prominent examples
  • SUN RPC, introduced with the network file system
    (SUN NFS),
  • DCE RPC, served as technical foundation of
    Microsofts COM.
  • Object Request Brokers (ORBs) enable the objects
    that comprise an object-oriented application to
    be distributed and shared across heterogeneous
    networks.
  • Extending the procedural programming model of
    RPC,
  • Distributed object systems such as CORBA, DCOM,
    .NET, and EJB enable processes to be run anywhere
    in the network.

11
Remote Procedure Call (RPC)
  • Masks remote function calls as being local
  • Client/server model
  • Request/reply paradigm usually implemented with
    message passing
  • Marshalling of function parameters and return
    value

Caller
RPC Service
RPC Service
Remote Function
1) Marshal args 2) Generate ID 3) Start timer
message
4) Unmarshal 5) Record ID
call()
fun()
6) Marshal 7) Set timer
8) Unmarshal 9) Acknowledge
12
Properties of RPC
  • Language-level pattern of function call
  • easy to understand for programmer
  • Synchronous request/reply interaction
  • natural from a programming language point-of-view
  • matches replies to requests
  • built in synchronisation
  • Distribution transparency
  • hides the complexity of a distributed system
  • Various reliability guarantees
  • deals with some distributed systems aspects of
    failure

13
Disadvantages of RPC
  • Synchronous request/reply interaction
  • tight coupling between client and server
  • may block for a long time
  • leads to multi-threaded programming
  • Distribution Transparency
  • Not possible to mask all problems
  • Lacks notion of services
  • programmer not interested in server but in
    service
  • RPC paradigm is not object-oriented
  • invoke methods on objects as opposed to functions
    on servers

fork()
remote call
join()
14
Object-Oriented Middleware (OOM)
  • Objects can be local or remote
  • Object references can be local or remote
  • Remote objects have visible remote interfaces
  • Masks remote objects as being local using proxy
    objects
  • Remote method invocation

OOM
OOM
local
remote
object request broker / object manager
object request broker / object manager
object A
skeleton object B
proxy object B
object B
15
Properties of OOM
  • Support for object-oriented programming model
  • objects, methods, interfaces, encapsulation,
  • exceptions
  • Location Transparency
  • mapping object references to locations
  • Synchronous request/reply interaction
  • same as RPC
  • Services

16
Java Remote Method Invocation (RMI)
  • Distributed objects in Java

public interface PrintServer extends Remote
int print(Vector printJob) throws
RemoteException
  • RMI compiler creates proxies and skeletons
  • RMI registry used for interface lookup

17
CORBA
  • Common Object Request Broker Architecture
  • Open standard by the OMG (Version 3.0)
  • Language- and platform independent
  • Object Request Broker (ORB)
  • General Inter-ORB Protocol (GIOP) for
    communication
  • Interoperable Object References (IOR) contain
    object location
  • CORBA Interface Definition Language (IDL)
  • Stubs (proxies) and skeletons created by IDL
    compiler
  • Dynamic remote method invocation
  • Interface Repository
  • Querying existing remote interfaces
  • Implementation Repository
  • Activating remote objects on demand

18
CORBA IDL
  • Definition of language-independent remote
    interfaces
  • Language mappings to C, Java, Smalltalk,
  • Translation by IDL compiler
  • Type system
  • basic types long (32 bit), long long (64 bit),
    short, float, char, boolean, octet, any,
  • constructed types struct, union, sequence,
    array, enum
  • objects (common super type Object)
  • Parameter passing
  • in, out, inout
  • basic constructed types passed by value
  • objects passed by reference

typedef sequenceltstringgt Files interface
PrintServer Server void print(in Files
printJob)
19
CORBA Services
  • Naming Service
  • Names ? remote object references
  • Trading Service
  • Attributes (properties) ? remote object
    references
  • Persistent Object Service
  • Implementation of persistent CORBA objects
  • Transaction Service
  • Making object invocation part of transactions
  • Event Service and Notification Service
  • Asynchronous communication based on messaging
  • (cf. MOM)

20
Disadvantages of OOM
  • Synchronous request/reply interaction
  • So CORBA oneway semantics added and -
  • Asynchronous Method Invocation (AMI)
  • But implementations may not be loosely coupled
  • Distributed garbage collection
  • Releasing memory for unused remote objects
  • OOM rather static and heavy-weight
  • Bad for ubiquitous systems and embedded devices

21
Reflective Middleware
  • Flexible middleware (OOM) for mobile and
    context-aware applications
  • Interfaces for reflection
  • Objects can inspect middleware behaviour
  • Interfaces for customizability
  • Dynamic reconfiguration depending on environment
  • Different protocols, QoS, ...
  • e.g. use different marshalling strategy over
    unreliable wireless link

22
Message-Oriented Middleware (MOM)
  • Communication using messages
  • Messages stored in message queues
  • Optional message server decouples client and
    server
  • Various assumptions about message content

Client App.
Server App.
Message Server
local message queues
local message queues
message queues
Network
Network
Network
23
Properties of MOM
  • Asynchronous interaction
  • Client and server are only loosely coupled
  • Messages are queued
  • Good for application integration
  • Support for reliable delivery service
  • Keep queues in persistent storage
  • Processing of messages by intermediate message
    server
  • Filtering, transforming, logging,
  • Networks of message servers
  • Natural for database integration

24
IBM MQSeries
  • One-to-one reliable message passing using queues
  • Persistent and non-persistent messages
  • Message priorities, message notification
  • Queue Managers
  • Responsible for queues
  • Transfer messages from input to output queues
  • Keep routing tables
  • Message Channels
  • Reliable connections between queue managers
  • Messaging API

MQopen Open a queue
MQclose Close a queue
MQput Put message into opened queue
MQget Get message from local queue
25
Java Message Service (JMS)
  • API specification to access MOM implementations
  • Two modes of operation
  • Point-to-point
  • One-to-one communication using queues
  • Publish/Subscribe
  • cf. Event-Based Middleware
  • JMS Server implements JMS API
  • JMS Clients connect to JMS servers
  • Java objects can be serialised to JMS messages

26
Disadvantages of MOM
  • Poor programming abstracting
  • Rather low-level (cf. Packets)
  • Results in multi-threaded code
  • Request/reply more difficult to achieve
  • Message formats unknown to middleware
  • No type checking
  • Queue abstraction only gives one-to-one
    communication
  • Limits scalability

27
Web Services
  • Use well-known web standards for distributed
    computing
  • Communication
  • Message content expressed in XML
  • Simple Object Access Protocol (SOAP)
  • Lightweight protocol for sync/async communication
  • Service Description
  • Web Services Description Language (WSDL)
  • Interface description for web services
  • Service Discovery
  • Universal Description Discovery and Integration
    (UDDI)
  • Directory with web service description in WSDL

28
Properties of Web Services
  • Language-independent and open standard
  • SOAP is best of both worlds
  • Synchronous request/reply like OOM
  • Asynchronous messaging like MOM
  • Supports internet transports (http, smtp, ...)
  • Uses XML Schema for marshalling types
  • WSDL says how to use a web service
  • UDDI helps to find the right web service
  • Exports SOAP API for access

http//api.google.com/GoogleSearch.wsdl
29
Event-Based Middleware
  • Publishers publish events (messages)
  • Subscribers express interest in events with
    subscriptions
  • Event Service notifies interested subscribers of
    published events
  • Events can have arbitrary content or name/value
    pairs

subscribe
publish
Subscriber
Publisher
notify
Event Service
subscribe
publish
Subscriber
Publisher
notify
subscribe
Publisher
publish
Subscriber
notify
30
Topic-Based and Content-Based Pub/Sub
  • Event Service matches events against
    subscriptions
  • What do subscriptions look like?
  • Topic-Based Publish/Subscribe
  • Publishers publish events belonging to topic or
    subject
  • Subscribers subscribe to topic
  • subscribe(PrintJobFinishedTopic, )
  • Content-Based Publish/Subscribe
  • Publishers publish arbitrary events
  • Subscribers provide a filter based on content of
    events
  • subscribe(typeprintjobfinshed, printeraspen,
    )

31
Properties of Publish/Subscribe
  • Asynchronous communication
  • Publishers and subscribers are loosely coupled
  • Many-to-many interaction between publishers and
    subscribers
  • Scalable scheme for large-scale systems
  • Publishers do not need to know subscribers
  • Content-based pub/sub very expressive
  • Information delivered to all interested parties

32
Cambridge Event Architecture (CEA)
  • Publish-Register-Notify Paradim
  • Standard middleware for building event-based
    systems
  • Direct communication between pubs and subs
  • Event Mediators decouple pubs and subs
  • Source-side filtering of events
  • Events are typed messages
  • Attributes for content-based pub/sub filtering

event PrinterJobFinished String printer
String printFile int userID
33
History and intro to CORBA
  • CORBA is a standard for object interoperability
  • Support for different languages
  • Support for different platforms
  • Communications over the network
  • Additional services (e.g., security)
  • CORBA is defined by the OMG (Object Management
    Group)
  • Begin since 1989
  • CORBA 1 was in 1991
  • Now, toward to CORBA 3
  • More information http//www.omg.org
  • CORBA is a component of OMA (Object Management
    Architecture)

34
What is the OMA?
  • Object Model and Interfaces (e.g., Domain
    Interfaces, Application Interfaces)
  • Defines what a CORBA object is
  • Common Object Request Broker Architecture (CORBA)
  • Standard for an ORB (Object Request Broker)
  • Defines the IIOP (Internet Inter-ORB Protocol) --
    the standard for communication
  • Defines the Language interfaces and tools

35
What is the OMA?
  • Object Services -- common services
  • Core services required to develop distributed
    architectures
  • Naming -- allowing clients to find objects based
    on names
  • Trading -- allowing clients to find objects based
    on their properties
  • Others Security, Transactions, event
    notification, .
  • Common Facilities -- high-level services
  • e.g., Distributed Document Component Facility
    (DDCF) -- OpenDoc
  • Allowing for the presentation and interchange of
    objects based on a document model facilitating
    the linking of a spreadsheet object into a report
    document

36
Some ORBs
  • CORBA Software (http//www.infosys.tuwien.ac.at/Re
    search/Corba/software.html)
  • Orbix (IONA)
  • VisiBroker (Inprise)
  • ObjectBroker (BEA)
  • PowerBroker (Expersoft)
  • ORB Plus (HP)
  • ORBacus (Object-Oriented Concepts, Inc.)
  • NEO/JavaIDL (SunSoft)

37
Why CORBA?
  • Need to share information and resources within
    and across diverse computing enterprises
  • CORBA is a Middleware Standard
  • CORBA is a Software Bus
  • CORBA is a Distributed Object Architecture

38
CORBA is a Middleware Standard
  • Before CORBA, middleware was dominated by
    proprietary tools
  • CORBA provides a standard that allows you to
  • Develop applications using a common basis
  • Change CORBA products with minimal rewriting of
    code
  • Make objects running on different CORBA products
    interoperate
  • Integrate third-party products that respect the
    standard
  • CORBA is evolving to standardize other types of
    middleware

39
CORBA and the Software Bus
  • A standard architecture enabling you to plug
    components into
  • Support different languages and platforms
  • Connects everything up in a single architecture
  • A basis for delivering reusable components
  • A CORBA component can be accessed from any client
    technology
  • A CORBA components has a clearly defined interface

Source Java-CORBA E. Arch., expede.com
40
CORBA and Distributed Architectures
Source Java-CORBA E. Arch., expede.com
41
How Does CORBA Work?
  • Step 1 Write a specification for each object
    using IDL (Interface Definition Language)
  • Step 2 Compile the IDL to generate client stub
    and server skeleton code
  • Step 3 Write the client application code.
  • Step 4 Write the server object code.
  • Step 5 Compile the client and server code
  • Step 6. Start the server
  • Step 7 Run the client application

Source Visibroker Progammers Guide
42
1
2
3
4
5
Source Visibroker Progammers Guide
43
Source Visibroker Progammers Guide
44
Source Visibroker Progammers Guide
45
What are considerations for using CORBA?
  • Security
  • Performance
  • Fault-Tolerance
  • Scalability

46
CORBA 3.0
  • Provides well-defined packaging for producing
    components, quality of service, messaging and
    other technologies
  • Full Java and Internet support
  • Java portability, XML integration
  • Quality of Service management
  • Messaging, Realtime, Small footprint
  • Distributed Component Model
  • Component-based development, scripting

Source Soley, OMG
47
Recent CORBA 3.0 Additions
  • CORBA Component Model (CCM)
  • introduces the notion of server-side components
    into CORBA and addresses packaging and deployment
    for CORBA components.
  • CCM provides for interoperability with EJB.
  • Objects passable by value (valuetypes)
  • valuetypes definitely improve integration with
    Java and also serve as basis for the XML/Value
    mapping (released as part of CORBA 2.3).
  • Java-to-IDL Mapping
  • this mapping allows Java RMI objects to
    interoperate over the network like CORBA objects
    using CORBA object references.
  • XML/Value mapping
  • standardizes the representation of an XML
    document as a collection of native CORBA types.
  • CORBA Firewall Specification
  • allows firewalls to be configured for CORBA using
    access rules for IIOP traffic.

48
CORBA 3.0 Additions
  • CORBA Messaging
  • encompasses both asynchronous and messaging-mode
    invocations of CORBA objects as well as Quality
    of Service Control.
  • Real-Time CORBA
  • extends the CORBA architecture with resource
    control mechanisms for real-time applications
    running on a real-time operating system in a
    controlled environment.
  • Fault-Tolerant CORBA
  • standardizes redundant software configurations
    and systems that give CORBA robust and reliable
    performance (when run on redundant hardware).
  • Minimum CORBA
  • defines a small-footprint CORBA configuration
    that is aimed at embedded and card-based systems.

49
COM Characteristics
  • COM is a very mature component architecture that
    has many strengths.
  • Thousands of third-party ActiveX controls
    (in-process COM components) are available in the
    market today.
  • Microsoft and other vendors have built many tools
    that accelerate development of COM-based
    applications.
  • Advanced services such as Microsoft Transaction
    Server (MTS) and Microsoft Message Queuing Server
    (MSMQ) support development of enterprise
    multi-tier systems.
  • Microsoft has been using the name COM to
    identify the bundling of the COM runtime with
    those services.

50
Microsoft .NET Framework
51
.NET Characteristics
  • Distributed Computing
  • .NET provides a remoting architecture that
    exploits open Internet standards, including the
    Hypertext Transfer Protocol (http), Extensible
    Markup Language (XML), and Simple Object Access
    Protocol (SOAP).
  • Componentization
  • .NET extends the previous COM component model but
    provides a significantly simpler way to build and
    deploy components.
  • Enterprise services
  • .NET supports the development of scalable
    enterprise applications without writing code to
    manage transactions, security, or pooling.
  • Web paradigm shifts
  • Over the last few years, web application
    development has shifted from connectivity
    (TCP/IP), to presentation (HTML), to
    programmability (XML and SOAP). .NET enables
    software to be sold and distributed as a service.
  • Maturity factors
  • Although .NET is a relatively new framework, it
    builds upon the mature COM technology and
    services.

52
Future Trends Resource Management and
Quality-of-Service
  • Middleware abstractions provide resource
    management in a distributed system at a high
    level.
  • OS manages communication, processing, storage
    (memory/disks).
  • Middleware abstractions also are from an
    end-to-end perspective, not just of a single
    host, which allows for a more global and complete
    view to a resource management system.
  • Distributed objects are promising, as they not
    only encapsulate but also cleanly integrate all
    three kinds of resource into a coherent package.
  • This completeness helps distributed resource
    management and makes it easier to provide for
    load balancing, mobility transparency, and
    overall system reliability.

53
New Capabilities
  • Recent middleware frameworks, like the CORBA 3.0
    Component Model (CCM), or the Microsoft .NET
    framework, allow the expression of non-functional
    component properties.
  • such as resource requirements, timing and
    security constraints, or fault-tolerance
    assumptions on the component level using language
    constructs (like C and .NET attributes) or
    component meta-data (like CCMs deployment
    descriptors).
  • Aspect-Oriented Programming (AOP) is a relatively
    new discipline that focuses on cross-cutting
    concerns
  • targeting many components of a system
    simultaneously and
  • non-functional component properties.
  • AOP investigates software engineering approaches
    towards predictable component-based systems.
  • This research opens up new venues for
    middleware-based architectures on the enterprise
    level.

54
References
  • OMG www.omg.org/middleware/
  • NSF www.nsf-middleware.org/Middleware/
  • CMU www.sei.cmu.edu/str/descriptions/middleware.h
    tml
  • Resource center www.middleware.org/
  • kbs.cs.tu-berlin.de/teaching/ ws2001/cl/middleware
    _4.pdf
  • Bernstein, Philip A. "Middleware A Model for
    Distributed Services." Communications of the ACM
    39, 2 (February 1996) 86-97.
  • "Middleware Can Mask the Complexity of your
    Distributed Environment." Client/Server Economics
    Letter 2, 6 (June 1995) 1-5.
  • courses.cs.tamu.edu/cpsc689/hohin/ fall00/notes
  • http//www.darwinmag.com/learn/curve/column.html?A
    rticleID93
  • www.ics.uci.edu/muccini/ics123
  • http//www.iona.com/hyplan/vinoski/pdfs/IEEE-Where
    _is_Middleware.pdf
  • Internet2 middleware.internet2.edu
  • dsonline.computer.org/middleware/RM.htm
  • www.cl.cam.ac.uk/Teaching/2003/ DistSys
  • Eckerson, Wayne W. "Three Tier Client/Server
    Architecture Achieving Scalability, Performance,
    and Efficiency in Client Server Applications."
    Open Information Systems 10, 1 (January 1995)
    3(20).
  • Schreiber, Richard. "Middleware Demystified."
    Datamation 41, 6 (April 1, 1995) 41-45.
  • lass.cs.umass.edu/shenoy/courses/
    spring02/lectures
About PowerShow.com