Home >Documents >Middleware - RWTH Aachen University · PDF file Examples for middleware • DCOM as...

Middleware - RWTH Aachen University · PDF file Examples for middleware • DCOM as...

Date post:20-Mar-2020
View:1 times
Download:0 times
Share this document with a friend
  • Middleware

    Why Middleware? Advantages of Distributed Systems • Easy to add new components • Integration of existing solutions • Autonomy of single components • Flexibility und adaptability

    Requirements to Distributed Systems • Openness, integration • Modularisation, federations • Security • Manageability, transparency

    Problems: • different hardware • different operating systems • different applications

    SUN Solaris

    NT HP UX


    Solution: Middleware platform as software infrastructure for handling heterogeneity


    Middleware: • Realisation of distributed accesses by suitable software infrastructure • Hiding the complexity of the distributed system from the programmer • Supporting the interaction between application components which could run on

    heterogeneous systems • Separation of interface and implementation • Is added to the operating system or build upon it to take over some of its tasks

    The middleware is build upon different operating systems, networks, and communication protocols (layer 1-4).

    The applications can be programmed in different languages.

    ... and the middleware realises the cooperation between the software components.


    Middleware supports... • The communication between application components (normally RPC- or RMI-

    based) • Constructing modular applications • Dynamic binding • Supporting services, e.g.

    ! Naming ! Synchronisation ! Replication

    Examples for Middleware implementations: • Distributed Computing Environment (DCE) • ANSAware • DCOM • GLOBE • Common Object Request Broker Architecture (CORBA)

  • Middleware - Principles

    Distributed file systems • Distribution transparencies for files • Popular because of its scalability

    Remote Procedure Call (RPC) • Early middleware approach for transparency in communication

    Distributed objects (RMI) • Enhancements of RPC to access to remote objects • Only the interface can be seen from outside, the implementation details are


    Distributed documents • Example World Wide Web • Information are seen as documents, addressed by an URL

    Examples for middleware

    • DCOM as Microsoft's solution on distributed objects

    • GLOBE as middleware designed for large distributed system

    • CORBA as a general (industry defined) way to support distribution in heterogeneous systems

    Basic Technique in Microsoft's Windows: COM (Component Object Model) • Supports the development of components that can be dynamically activated and

    interact with each other • Can be used in executables as well as in dynamic link libraries • Was developed to support compound documents

    • DCOM: 'distributed version' of COM to support activation/interaction with components located on another machine. For a programmer, the distinction between COM and DCOM is hidden behind interfaces (access transparency)

    Distributed Component Object Model (DCOM)

    ActiveX: • covers the tasks of OLE, together

    with new features like starting variants, scripting support, …

    OLE: Object Linking and Embedding. • Serves for gluing together different

    parts of compound documents

    COM: • communication infrastructure

    between different objects located on the same computer

    Object Model

    • DCOM bases on the remote object model: objects can be placed in the same process as the client, in another process on the same machine, or in a process on a remote machine

    • Basic concept: ! distinction between interface and implementation ! The developer first specifies an object by its interface in an Interface Definition

    Language (IDL; Microsoft IDL = MIDL) ! An object simply is an implementation of an interface ! Interface means binary interface: a table of pointers to methods belonging to

    an interface. In this way, interfaces are language-independent

    • Each interface is assigned with a globally unique Interface Identifier (IID)

    • DCOM object: • instance of a class object, which represents an interface • By calling a function CreateInstance on a class object (identified by a class

    ID, CLSID), a new object with this interface is build.

  • Object Model

    All objects implement a standard interface: IUnknown • A pointer to IUnknown is passed back when creating an object • Important method in this interface: QueryInterface, which returns a pointer to

    another interface implemented by the object • By this, a standard method to get access to each object's methods is given

    All objects in DCOM are transient • Reference counting is part of IUnknown • Having no more references, an object is destroyed

    An object can implement the IDispatch interface • Dynamic invocation of objects • An object does not have to know in advance all interfaces it will have to contact in

    its lifetime • When an object implements this interface, calls to it can be constructed at runtime

    Type Library and Registry Type library: storage for interface definitions • Used to figure out the signature of a method to be invoked dynamically • Used as a type library for supporting program developers

    Registry (Windows registry) • Used to provide a mapping from interface identifiers to executable code. • In case of a remote invocation, the Service Control Manager (SCM) on the target

    host is contacted by a client to access the remote registry

    Communication in DCOM Client side: • Client proxy: providing the object's interface and sending the request to the object • Proxy marshaller: translating a request into a transport format before sending

    Server side: • Object stub: receives a call from a client proxy and passes it on to the object • Proxy marshaller: extracts a request from a receives message

    Communication at the beginning only was synchronous using RPC


    • Callback interfaces

    ! The client provides an interface where the server can call back after working on a request

    • Asynchronous communication ! For each method, two methods are implemented:

    A start method the client passes its request to A finish method the client calls to read the response of the server

    Events Real asynchronous communication without the need for both, client and object, to be

    active: using events • An event is modelled as a method call • An event class groups events and can be instantiated to event objects which can

    send events of specific types • To register an implementation for a method so that events can be sent to it, a

    pointer to the corresponding interface has to be sent to the event system • The event system can store events to pass them on to the receiver later

    • Supplier: someone who creates events

    • Consumer: someone who receives events

    • m_event: method of an object

  • Clients • A client does not see distribution; the invocation of remote objects with DCOM is

    the same as an invocation of a local object with COM • Difference: in COM an object is referenced by an interface pointer, in DCOM a

    remote object is referenced by implementing an interface as a proxy • Passing on an object reference to another client is made by sending it the proxy

    which contains all connection information

    Naming in DCOM

    Returns interface pointer of object to clientMoniker7

    Loads its state from fileObject6

    Instructs object to load previously stored stateMoniker5

    Creates object and returns interface pointer to monikerClass object4

    Loads class objectSCM3

    Looks up associated CLSID and instructs SCM to create objectMoniker2

    Calls BindMoniker at monikerClient1


    • Only low-level naming • Objects are only transient. To expand an object's lifetime, additionally a persistent

    object reference is stored to an object. This reference is called moniker. • Monikers have all information available to reconstruct an object and reload its state

    Types of Monikers

    Reference to an object in a remote processPointer moniker

    Reference to a moniker in a compositionItem moniker

    Reference to a composition of monikersComposite moniker

    Reference to a class objectClass moniker

    Reference to an object constructed from a URLURL moniker

    Reference to an object constructed from a fileFile moniker

    DescriptionMoniker type

    Active Directory • Windows 2000 contains a directory service called Active Directory which can be

    used by DCOM • A distributed system based on Windows 2000 is partitioned into domains consisting

    of a number of resources and users • Each domain has a domain controller which is a local directory server • A domain controller is implemented as a LDAP directory server • LDAP servers are registered in DNS • Problem: a client has to know the target domain for its request


    GLobal Object-Based Environment

    • Experimental distributed system developed by Vrije Universiteit Amsterdam

    • Design goal: support huge number of objects and users spread across the Internet, scalability is central role

    • Fundamental concept: how are objects viewed?

    ! Objects don't only encapsulate state and operations, but additionally they encapsulate the implementation of policies that prescribe the distribution of an object's

Click here to load reader

Reader Image
Embed Size (px)