DOC PREVIEW
UMass Amherst CS 677 - Distributed Component Object Model

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS677: Distributed OSComputer ScienceLecture 25, page 1Today: More Case Studies• DCOM• JiniCS677: Distributed OSComputer ScienceLecture 25, page 2DCOM• Distributed Component Object Model– Microsoft’s object model (middleware)CS677: Distributed OSComputer ScienceLecture 25, page 3DCOM: History• Successor to COM– Developed to support compound documents• Word document with excel spreadsheets and images• Object linking and embedding (OLE)– Initial version: message passing to pass information between parts– Soon replaced by a more flexible layer: COM• ActiveX: OLE plus new features– No good consensus on what exactly does ActiveX contain– Loosely: groups capabilities within applications to supportscripting, grouping of objects.• DCOM: all of the above, but across machinesCS677: Distributed OSComputer ScienceLecture 25, page 4Object Model• The difference between language-defined and binary interfaces.CS677: Distributed OSComputer ScienceLecture 25, page 5DCOM Object Model• DCOM: uses remote object model• Supports only binary interfaces– Table of pointers to methods– Uses Microsoft IDL• Unlike CORBA, all objects are transient– Delete an object with refcount == 0• Like CORBA, DCOM supports dynamic object invocationCS677: Distributed OSComputer ScienceLecture 25, page 6Type Library and Registry• The overall architecture of DCOM.– Type library == CORBA interface repository– Service control manager == CORBA implmentation repositoryCS677: Distributed OSComputer ScienceLecture 25, page 7Events and Messaging• Event processing in DCOM: publish/subscribe paradigm• Persistent asynchronous communication: MSFT Message QueuingCS677: Distributed OSComputer ScienceLecture 25, page 8Clients• Passing an object reference in DCOM with custom marshaling.CS677: Distributed OSComputer ScienceLecture 25, page 9Monikers: Persistent Objects• By default, DCOM objects are transient• Persistent objects implemented using monikers (reference stored on disk)– Has all information to recreate the object at a later timeReturns interface pointer of object to clientMoniker7Loads its state from fileObject6Instructs object to load previously stored stateMoniker5Creates object and returns interface pointer tomonikerClass object4Loads class objectSCM3Looks up associated CLSID and instructs SCM tocreate objectMoniker2Calls BindMoniker at monikerClient1DescriptionPerformerStepCS677: Distributed OSComputer ScienceLecture 25, page 10Monikers (2)• DCOM-defined moniker types.Reference to an object in a remote processPointer monikerReference to a moniker in a compositionItem monikerReference to a composition of monikersComposite monikerReference to a class objectClass monikerReference to an object constructed from a URLURL monikerReference to an object constructed from a fileFile monikerDescriptionMoniker typeCS677: Distributed OSComputer ScienceLecture 25, page 11Naming: Active Directory• The general organization of Active Directory– Implemented using LDAP– Distr. System partitioned into domains (uses domain controllers)– Each domain controller has a DNS name– DC registered as LDAP services in DNSCS677: Distributed OSComputer ScienceLecture 25, page 12Distributed Coordination• Motivation– Next generation of systems will be inherently distributed– Main problem: techniques to coordinate various components• Emphasis on coordination of activities between componentsCS677: Distributed OSComputer ScienceLecture 25, page 13Introduction to Coordination Models• Key idea: separation of computation from coordination• A taxonomy of coordination models– Direct coordination– Mailbox coordination– Meeting-oriented coordination (publish/subscribe)– Generative (shared tuple space)CS677: Distributed OSComputer ScienceLecture 25, page 14Jini Case Study• Coordination system based on Java– Clients can discover new services as they become available– Example: “intelligent toaster”– Distributed event and notification system• Coordination model– Uses JavaSpaces: a shared dataspace that stores tuples• Each tuple points to a Java objectCS677: Distributed OSComputer ScienceLecture 25, page 15Overview of Jini• The general organization of a JavaSpace in Jini.CS677: Distributed OSComputer ScienceLecture 25, page 16Architecture• The layered architecture of a Jini System.CS677: Distributed OSComputer ScienceLecture 25, page 17Communication Events• Using events in combination with a JavaSpaceCS677: Distributed OSComputer ScienceLecture 25, page 18Processes (1)• A JavaSpace can be replicated on all machines. The dotted lines show thepartitioning of the JavaSpace into subspaces.a) Tuples are broadcast on WRITEb) READs are local, but the removing of an instance when calling TAKE mustbe broadcastCS677: Distributed OSComputer ScienceLecture 25, page 19Processes (2)• Unreplicated JavaSpace.a) A WRITE is done locally.b) A READ or TAKE requires the template tuple to be broadcast inorder to find a tuple instanceCS677: Distributed OSComputer ScienceLecture 25, page 20The Jini Lookup Service (1)• The organization of a service item.A set of tuples describing the service.AttributeSetsA (possibly remote) reference to the object implementing the service.ServiceThe identifier of the service associated with this item.ServiceIDDescriptionFieldCS677: Distributed OSComputer ScienceLecture 25, page 21The Jini Lookup Service (2)• Examples of predefined tuples for service items.Street, organization, organizational unit, locality, state or province,postal code, countryAddressFloor, room, buildingLocationName, manufacturer, vendor, version, model, serial numberServiceInfoAttributesTuple


View Full Document

UMass Amherst CS 677 - Distributed Component Object Model

Download Distributed Component Object Model
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Distributed Component Object Model and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Distributed Component Object Model 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?