Today: More Case StudiesDCOMDCOM: HistoryObject ModelDCOM Object ModelType Library and RegistryEvents and MessagingClientsMonikers: Persistent ObjectsMonikers (2)Naming: Active DirectoryDistributed CoordinationIntroduction to Coordination ModelsJini Case StudyOverview of JiniArchitectureCommunication EventsProcesses (1)Processes (2)The Jini Lookup Service (1)The Jini Lookup Service (2)CS677: Distributed OSComputer ScienceLecture 24, page 1Today: More Case Studies•DCOM•JiniCS677: Distributed OSComputer ScienceLecture 24, page 2DCOM•Distributed Component Object Model–Microsoft’s object model (middleware)CS677: Distributed OSComputer ScienceLecture 24, 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 support scripting, grouping of objects.•DCOM: all of the above, but across machinesCS677: Distributed OSComputer ScienceLecture 24, page 4Object Model•The difference between language-defined and binary interfaces.CS677: Distributed OSComputer ScienceLecture 24, 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 24, page 6Type Library and Registry•The overall architecture of DCOM.–Type library == CORBA interface repository–Service control manager == CORBA implmentation repositoryCS677: Distributed OSComputer ScienceLecture 24, page 7Events and Messaging•Event processing in DCOM: publish/subscribe paradigm•Persistent asynchronous communication: MSFT Message QueuingCS677: Distributed OSComputer ScienceLecture 24, page 8Clients•Passing an object reference in DCOM with custom marshaling.CS677: Distributed OSComputer ScienceLecture 24, 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 timeStep Performer Description1 Client Calls BindMoniker at moniker2 MonikerLooks up associated CLSID and instructs SCM to create object3 SCM Loads class object4 Class objectCreates object and returns interface pointer to moniker5 Moniker Instructs object to load previously stored state6 Object Loads its state from file7 Moniker Returns interface pointer of object to clientCS677: Distributed OSComputer ScienceLecture 24, page 10Monikers (2)•DCOM-defined moniker types.Moniker type DescriptionFile moniker Reference to an object constructed from a fileURL moniker Reference to an object constructed from a URLClass moniker Reference to a class objectComposite moniker Reference to a composition of monikersItem moniker Reference to a moniker in a compositionPointer moniker Reference to an object in a remote processCS677: Distributed OSComputer ScienceLecture 24, 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 24, 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 24, 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 24, 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 24, page 15Overview of Jini•The general organization of a JavaSpace in Jini.CS677: Distributed OSComputer ScienceLecture 24, page 16Architecture•The layered architecture of a Jini System.CS677: Distributed OSComputer ScienceLecture 24, page 17Communication Events•Using events in combination with a JavaSpaceCS677: Distributed OSComputer ScienceLecture 24, page 18Processes (1)•A JavaSpace can be replicated on all machines. The dotted lines show the partitioning of the JavaSpace into subspaces.a) Tuples are broadcast on WRITEb) READs are local, but the removing of an instance when calling TAKE must be broadcastCS677: Distributed OSComputer ScienceLecture 24, page 19Processes (2)•Unreplicated JavaSpace.a) A WRITE is done locally.b) A READ or TAKE requires the template tuple to be broadcast in order to find a tuple instanceCS677: Distributed OSComputer ScienceLecture 24, page 20The Jini Lookup Service (1)•The organization of a service item.Field DescriptionServiceID The identifier of the service associated with this item.Service A (possibly remote) reference to the object implementing the service.AttributeSets A set of tuples describing the service.CS677: Distributed OSComputer ScienceLecture 24, page 21The Jini Lookup Service (2)•Examples of predefined tuples for service items.Tuple Type AttributesServiceInfo Name, manufacturer, vendor, version, model, serial numberLocation Floor, room, buildingAddressStreet, organization, organizational unit, locality, state or province, postal code,