mwt

Middleware Technologies 1

CSCI 477 April 8, 2003

What is Middleware?Infrastructure that supports (distributed) component-based application development

a.k.a. distributed component platformsmechanisms to enable component communicationmechanisms to hide distribution information(large) set of predefined components

Standard for constructing and interconnecting components

interchangeupgradeadaptationaggregation



Middleware RequirementsNetwork communication

marshalling/unmarshallingCoordination

activation/termination, threading, group requests, synchronicity

Reliabilitydelivery guarantees, total/partial ordering, atomicity, replication

Scalabilitytransparency of access/location/migration/replication, load balancing

Heterogeneityplatform, operating system, network OS, programming language



Middleware CategoriesTransactional

two-phase commit for distributed transactionse.g., IBM’s CICS

Message-oriented (MOM)communication via message exchangee.g., Sun’s JMS

Proceduralremote procedure calls as the foundatione.g., DCE RPC

Object-basedcommunication among and via distributed objectse.g., CORBA, COM

Component-basedsupport for distributed componentse.g., EJB



Elements of MiddlewareSoftware components

component interfacesproperties

methods

events

Containersshared context of interaction with other componentsprovide access to system-level services

Metadataself-descriptive information used by a component to flexibly communicate with others

Integrated development environmente.g., VisualCafe for Java



Distribution Support in MiddlewareHidden from application programmersFive distributed services required

remote communication protocolse.g., RPC, message passing

directory servicesfor accessing shared, globally-available services

security servicesprotection of shared resources via authentication

transaction servicesfor concurrent data access/update

system management servicesservice monitoring, management, and administration



CORBAA middleware platform that supports a standardized OO architecture for software applications

Common Object Request Broker ArchitectureOpen standard - developed by the Object Management GroupCORBA is a component of OMG’s Object Management Architecture

CORBA supports distributed object computingCORBA uses a broker

an intermediary handling requests in a systemfacilitates communication between clients and server objectsseparates a component’s interface from its implementation



CORBA’s Enhancements to Client/ServerExtends distributed computing paradigms, such as DCE RPC, to distributed object computingMutable client-server relationships

clients and servers not hard-wired to one anotherdynamic discovery of component interfaces

Interaction intermediaryORBobject adaptersgateways for other object systems

Both synchronous and deferred synchronous communication

deferred synchronous asynchronous~~



Main CORBA FeaturesObject request broker (ORB)OMG interface definition language (IDL)Language mappingsStubs and skeletonsInterface repositoryDynamic invocation and dispatchObject adaptersInter-ORB protocols



CORBA Architecture

ORB Core

DynamicInvocation

Client IDLStubs

ORBInterface

(Basic)ObjectAdapter

StaticSkeletons

DynamicSkeleton

invocation

ClientObject

Implementation

InterfaceRepository

ImplementationRepository

ORB Core

DynamicInvocation

Client IDLStubs

ORBInterface

(Basic)ObjectAdapter

StaticSkeletons

DynamicSkeleton

invocation

ClientObject

Implementation

InterfaceRepository

ImplementationRepository



Object Request BrokerDelivers client requests and server responses

provides a layer of indirection between clients and serversThe ORB hides object

locationimplementationexecution statecommunication mechanisms

Requests on an object are made using its referenceClients can obtain references in three ways

create an object to get its referenceuses factory objects

invoke a lookup service (naming, trading)use persistent references to objects



OMG IDLSpecifies (implementation-independent) object interfaceBasic types

short, long, long long, float, double, long double, char, wchar, boolean, octet, enum, string, wstringAny

Constructed typesstruct, union, array, sequence

IDL is language-independentStandardized language mappings for C, C++, Ada95, COBOL, Smalltalk, Java, ...MarshallingUnmarshalling



Stubs and SkeletonsUsed in CORBA’s static invocationProgramming language-specific counterparts to IDL definitions

Stubs and skeletons are generated using the IDL definitionsStubs create and issue requests on the client side

a.k.a. surrogates or proxiesperform marshalling of requests

Skeletons receive and forward requests to objects on the server side

perform unmarshalling of requestsreturn results via the server and client ORBs to the stub



Example of Stubs and Skeletons

Interface Definitioninterface Employee {

void promote(in char new_job_class);void dismiss(in DismissalCode reason,

in String description);};

Client Application

Object Reference

Operationpromote

Operationdismiss

Server Application

Object Implementation

MethodEmp_promote

MethodEmp_dismiss



Static Method InvocationDefine object classes using IDLRun IDL file through language precompilerAdd implementation code to skeletonsCompile codeBind class definitions to Interface RepositoryRegister the run-time objects with Implementation RepositoryInstantiate the objects on the server



Interface RepositoryUsed for performing operations on objects whose interface is not known at compile timeKnowing interfaces of all objects a priori may be impractical

independently developed componentsfast changing parts of the systemdynamic manipulation

IR allows access to the IDL type system at runtimeIR is a CORBA object whose functionality is invoked like any other objectallows CORBA’s dynamic invocation

Not to confuse with Implementation Repository thatcontains information for locating and activating objects



Dynamic Method InvocationObtain interface name from Interface RepositoryObtain method description from Interface RepositoryCreate argument listCreate requestInvoke requestDynamic vs. static invocation

harder to programless robust type checkingslower (factor of 40)harder to understand/document



CORBA ServicesNamingLife Cycle

create, copy, move, delete objectsEvents

register for interest in specific events (e.g., push, pull)Object Trader

yellow pages for objects based on services they provideTransactions

flat, nestedinvolving heterogeneous ORBs and non-ORBs

Concurrency Controlcoordinate access to shared resources using locks



CORBA Services (cont.)Object Security

authentication, audits, encryptionPersistenceQuery

find objects of matching attributesCollections

manipulate objects in a groupRelationships

dynamically create and keep track of relationshipsTimeLicensing

license managerProperties



Inter-ORB ProtocolsCORBA standard does not cover all of CORBA

e.g., different protocols and object references are possibleGeneral ORB interoperability architecture

based on the General Inter-ORB Protocol (GIOP)one instance of GIOP is the IIOP (built on top of TCP/IP)Environment-Specific Inter-ORB Protocols (ESIOP)

allow CORBA and non-CORBA components to interactone instance is the Distributed Computing Environment Common Inter-ORB Protocol (DCE-CIOP)

Standard object reference formatInteroperable Object Reference (IOR)

Portable Object Adapters (POA)



COM/DCOMMicrosoft’s middleware infrastructure in many ways similar to CORBADefines a binary standard for component interoperability

programming language independencePlatform independent

Windows (95, 98, NT)MacUnix

Distribution transparencydoes exploit operational characteristics

Dynamic component loading and unloading



Basic COM FeaturesBinary standard for component interactionsSupport for interfaces

defined in an IDL different from CORBA’sBase interface with introspection support

dynamic discovery of other components’ interfacesgarbage collection via reference counting

Unique component ID mechanismCommunication is synchronous by default

asynchronous communication supportable by callbacks and connection points



Binary StandardComponent operation invocation via virtual tables — vtables

works for languages that support function pointerse.g., C, C++, Smalltalk

the client contains a pointer to the vtablethe vtable contains a pointer to the server functionone layer of indirection over standard function calls

Client

Server-iVTable

Server-j



COM ComponentsCompiled code that provides some service to a systemA component may support a number of interfaces

an interface is a collection of semantically related functionsCOM interfaces begin with “I” by convention

All access to component services is via interface pointersallows service reimplementation

Each component supports base interface IUnknownTransparent remote access via proxy-stub pairs

similar to CORBAEvery component has a globally unique identifier (GUID)

128 bit integerused to refer to component’s TypeLibrary(metadata repository)



Notes on COM InterfacesInterface class

they contain no implementationmultiple implementations of an interface possible

Interface componentinterfaces are the (binary) component interaction standard

Heterogeneous COM clients and servers interact via interface pointersA single COM component can implement multiple interfacesInterfaces are strongly typed

every interface has a GUIDInterfaces are immutable

e.g., no subtyping, subclassing, inheritance

≠

≠



Interface IUnknownMust be implemented by all COM componentsHas three methods

QueryInterfaceprovides introspection capabilities

allows runtime discovery of component interface

delivers interface pointer to a clientAddRef

called when another component is using the interface

increments reference countRelease

called when another component stops using the interface

decrements reference count

Supports garbage collectiona component can be unloaded when its reference count is 0



Distributed COMDCOM = COM binary standard

+runtime infrastructure for communicating acrossdistributed address spaces

initially only on Windowsrecently adding Mac and Unix

Uses OSF’s DCE RPC as a basis for remote interactionproxy/stub mechanism

Attempts to address challenges of distributed computinginteracting components should be “close” to one anothersome components’ locations are fixedinverse relationship between component size and flexibilitydirect relationship between component size and network traffic



Distribution in COM/DCOM — In-Process

Distribution in COM/DCOM — Inter-Process

Client Server

Client ServerStubProxy

Security RPC

LPC

Security RPC

LPC



Distribution in COM/DCOM — Cross-Network

Client ServerStubProxy

Security RPC

Network Protocol

Security RPC

StackNetwork Protocol

Stack

DCOMNetworkProtocol



Distribution in DCOMFull distribution transparency

component location is hidden from clients (and client developers)method invocation is identicalunderlying communication mechanisms change

Comp1 Comp2

Comp3 Comp4Comp2



Garbage Collection in COM/DCOMNetworks are fragile

connections may break for many reasonsif a connection to a client is broken, a server component should not needlessly consume resources

COM/DCOM uses a pinging protocol to detect (in)active clients

a ping message is sent every two minutes from client to serverdistributed garbage collectiontransparent to the application (developer)reference count is decremented if multiple (>3) ping periods pass without receiving a message

The protocol is efficientping messages are piggybacked onto existing COM calls

mwt

Documents