Objektorienterad middleware OO-Middleware Datakom 2 DAVC03 Stefan Alfredsson material inspirerat av Annika Wennström, Sören Torstensson) Utökad mekanism för objekt Objekt består av data tillstånd) och metoder Metoder åtkomliga via gränssnitt interface) Anropa metoder på en annan maskin remote method invocation) Fjärrobjekt distribuerat objekt): objekt och interface på olika maskiner Exempel: Java RMI, Corba, DCOM,.NET,... Några centrala begrepp Komponent vs objekt Objekt vs komponent Objektreferens IDL Statiska vs dynamiska anrop Komponent är en ofta förekommande term, men har ingen formell definition Några karaktäristiska drag finns dock Den är större än ett objekt Den är autonomt och kan göra vissa uppgifter på egen hand Den kan ha ett grafiskt gränssnitt, kan vara distribuerad jmf Java Beans) Kan innehålla applikations- eller affärslogik, men kan också vara av mer teknisk natur En komponent är binär, och oberoende av programspråk Fjärrobjekt Objektreferens Skapas när objekt skapas/instansieras Identifierar/representerar objekt Talar om vart objektet är instansierat Klienter får objektref från t.ex. namnservice Klienten vet inte vad objektref innehåller opaque) Lokala- och fjärrobjekt hanteras olika pga effektivitet 1
Exempel på objektreferens Interface Definition Language IDL) IOR:000000000000001949444c3a48656c6c 6f576f726c642f48656c6c6f3a312e300000 000000000001000000000000006800010200 0000000f3139332e31302e3232322e313432 0000b737000000000019afabcb0000000002 1a4b04520000000800000000000000000a00 000000000001000000010000002000000000 000100010000000205010001000100200001 01090000000100010100 Deklarativ språkgrupp Definierar objekts gränssnitt Klient och server kan vara skrivna i olika språk Proxy och skelett genereras av IDL kompilator Används inte av alla oo-mellanvaror, t.ex. Java RMI stödjer bara Java Anrop Exempelprodukter Statiska anrop Proxy och skelett måste vara kända vid kompiliering Ändring i interface kräver omkompilering Dynamiska anrop Generella stubbar tillhandahålls av underliggande system Proxy och skelett behövs inte vid kompilering Inte nödvändigt att interface är känt vid kompilering Java RMI Jini Corba Java RMI RMI Remote Method Invocation Klient/Serverbaserat Server skapar objekt, lämnar ut referens Klient använder referens, anropar metod på objektet via ett lokalt proxyobjekt Klient kan skicka egna objekt som argument 2
Hur implementera? Serverexempel registrering Serverobjektet använder interface java.rmi.remote, och deklarerar java.rmi.remoteexception som exception Generera server och klient stubs rmic) Starta rmiregistry, server, klient... String name = "//host/compute"; try { Compute engine = new ComputeEngine); Naming.rebindname, engine); System.out.println"ComputeEngine bound"); } catch Exception e) { Klientexempel, tjänsteanrop Jini... try { String name = "//host/compute"; Compute comp = Compute) Naming.lookupname); Pi task = new PiInteger.parseIntargs[1])); BigDecimal pi = BigDecimal)comp.executeTasktask)); System.out.printlnpi); } catch Exception e) {... Utvecklas av Sun Microsystems 1999 Nätverksarkitektur optimerad för skalbarhet och förändringar och självständighet www.jini.org Använder Java RMI i botten The purpose of the Jini architecture is to federate groups of devices and soft-ware components into a single, dynamic distributed system. The resulting federation provides the simplicity of access, ease of administration, and support for sharing that are provided by a large monolithic system while retaining the flexibility, uniform response, and control provided by a personal computer or workstation. The architecture of a single Jini system is targeted to the workgroup. Members of the federation are assumed to agree on basic notions of trust, administration, identification, and policy. It is possible to federate Jini systems themselves for larger organizations. Från The Jini Architecture Specification ) 3
Jinimotivation Mer exempel Samordnande ramverk Enkelt, sömlöst, skalbar interoperabilitet Network plug and play med minsta möjliga adminstration Nätverksansluten mjuk och hårdvara tillhandahåller tjänster Alla enheter kan hitta och använda tillgängliga tjänster Exempel Hitta alla färg-duplex skrivare i närheten Börja brygg kaffe fem minuter innan väckarklockan ringer Låt mobiltelefonen använda bilhögtalarna Digitalkamera pluggas in i nätverket Letar reda på lookup-tjänsten discovery) Registrerar sitt grässnitt på lookup-tjänsten join) Säger i princip Jag är en kamera, vill någon ha bilder? Senare: En laptop pluggas in i nätet, letar efter kamera, anropar Camera.Snapshot) Kameran upptäcker att ljuset är för mörkt, och vrider upp det med Light.increase) till det är okej Laptop ber kamera att skriva ut fotot Kamera letar reda på skrivare via lookup-tjänst, och anropar dess utskriftsmetod Bzzz, bzzz Nyckelteknologier Instant On When a jini-enabled device is plugged into the network, it works right away with no fuss Its services and resources are immediately available Impromptu Community Devices working together, creating a personal network or community Connect home appliances and control them centrally Connect to services on the road Resilient Adapts very quickly to changes The community lives on, as users comes and goes Special delivery Services are available on demand, whenever needed Tjänster Namnuppslagning lookuptjänst) Java Remote Method Invocation RMI) Leasing Transaktioner Händelser events) Jini utlovar... Imponansfaktorer Desktop PC Coffee Maker Cell Phone Lookup service Network Printer Service Alarm Clock Service Stereo Speaker Service Drivrutiner tillhandahålls av tjänsten Behöver bara känna till gränssnittet Arbete kan fördelas olika mellan klient och tjänst Leasing-modell hanterar nätverks/klient/serverfel lease förnyas så länge tjänsten används) Distribuerade transaktioner 2-PC) Flexibel sökning efter egenskaper utskriftstjänst, spela upp ljud ) 4
Lite problematik Framtiden Behöver känna till gränssnitt i förväg och vara överens om de funktioner som tillhandahålls Printer.Skrivut), Coffee.Brygg), Coffe.Print) Standardiseras på jini.org Kräver Java VM överallt Men det finns en surrogatfunktion för att koppla upp utrustning som ej klarar köra JVM Stor potential, men har trots det inte slagit igenom Konkurrenter: UPnP, Salutation Kräver väldefinierade gränssnitt till vanliga tjänster Printer, etc) Overview CORBA - Common Object Request Broker Architecture Developed by OMG Object Management Group). An architecture for distributed objects. The Object Request Broker ORB) is the middleware that establishes the client-server relationships between objects. CORBA 3.0 Commercial release at end of 1999 OMG - Object Management Group http://www.omg.org/ Founded in May 1989 by 3Com, American Airlines, Canon, Data General, HP, Philips, Sun, Unisys. Now over 800 members. Vendor independent non-profit operations. Based in Framingham, Massachusetts, USA, but has regular meetings all over the world OMG produces specifications for standardized object software in order to create a component-based software marketplace. Object Orientation Basics Objects and Classes object types) Object members: Methods CORBA: operations) Fields CORBA: attributes) Inheritance Interface abstract class ) OMG Reference Model The result of the programmers sweat Application Objects User Interface Management, Information Management, System Management, Task Management CORBA Facilities Object Request Broker ORB) CORBA Services Finance, Health Care, Telecom, Manufacturing, etc. CORBA Domains Naming, Event, Transaction, Persistence, Lifecycle, Security, Trader, Concurrency, Externalization, Query, Collection, Relationship, Time, Licensing, Properties 5
Services in CORBA CORBA Services 1) Application Objects CORBAdomains CORBA Manufacturing, CORBA Medicine), CORBA Finance, CORBA Telecoms CORBAfacilities: Common services User Interface Management, Information Management, Systems Management, Task Management CORBAservices: OS level object services Naming, Event, Transaction, Persistence, Lifecycle, Security, Trader, Concurrency, Externalization, Query, Collection, Relationship, Time, Licensing, Properties System level services. Interfaces to services defined by IDL. Several services overlap functions that are available in operating systems and programming languages. May be bundled with ORB products or sold separately. CORBA Services 2) CORBA Services 3) Life Cycle - create, copy, move, delete objects Persistence - permanent storage of objects to file / database Naming - binding of objects to names Event - event handling and event subscription Concurrency - lock services for threads and transactions Transaction - two-phase commit Relationship - dynamically created associations Externalization - convert objects to a binary stream Query - query service Licensing - registration of usage of objects Properties - dynamic information about objects Time - common time service Trader - announce and find services based on service characteristics Collection - handle collections of objects Security - protect objects against unauthorized usage CORBAfacilities User Interface Management displaying, printing, compound documents, help information, Information Management modeling, storage, retrieval, compound documents, interchange of information, encoding, translation,... Systems Management management tools, monitor and control of system resources,... Task Management workflow automation, rule based objects, intelligent agents,... CORBA ORB Architecture 6
" " " " Client Stub Interface Repository The client stub has the same interface as the server object that it represents. The client stub acts as a proxy for the server object. The client stub receives calls from the client to the server object performs marshalling of parameters receives results from the server object and forwards them to the client The Interface Repository is a run-time database that contains information about all available IDL interfaces that the ORB recognizes. It can be called to read or write descriptions of registered objects interfaces) perform type control of method calls The interfaces must be loaded into the Interface Repository when the server object is activated Dynamic Invocation Object Adapter Dynamic Invocation Interface DII) is an interface for exploring objects during execution. Meta-data about objects can be read from Interface Repository. A dynamic call from a client program does not need a client stub, the client generates the call itself. Dynamic Invocation is not used very much yet). The Object Adapter sits on top of the communication system and manages object registration, creates object-id:s, handles calls to objects, activates objects, etc. There are different types of Object Adapters: Basic Object Adapter BOA) is required by the standard but it tends to be implemented in a proprietary way) Portable Object Adapter POA) shall be more strictly standardized IDL - Interface Definition Language The language used to specify interfaces to CORBA objects It is a declarative language i.e. no programming language) IDL has become an ISO-standard and is used in other contexts than with CORBA IDL-syntax is similar to C++ syntax but only declarative parts) the same lexical rules as C++ but some new keywords are added C++ syntax for declaration of constants, types and operations C++ preprocessing features are supported future changes to ANSI standard for C++ will be adopted by IDL An IDL Example interface grid1 { long getin short n, in short m); void setin short n, in short m, in long value); }; interface grid2 { void resetin long value); }; interface grid: grid1, grid2 { }; 7
" + + + + % % ) IDL compilation Java example) Client stub _st_xxx) Implementation of Client xxxhelper xxxholder IDL-file xxx.idl) Compilation Server Skeleton _xxximplbase) inherits) Implementation of Server Interface Repository Interface xxx) Implementation of Main Example _example_xxx) IDL language mappings There are mappings from IDL to the following programming languages: C/C++ Smalltalk Cobol Ada Java Nonstd: TCL, PL/1, LISP, Python, Perl,... These languages can be used to implement clients and server objects for CORBA. Different ways to invoke a request Protocols for CORBA: GIOP A request can be invoked in three ways : Synchronous Request $ the client stops and waits for the result Deferred Synchronous Request only dynamic invocation) $ the client continue to execute and must poll for the result later One-way Request only dynamic invocation) $ the client ignores the result GIOP - General Inter-Orb Protocol is used between ORB:s in order to get interoperability The GIOP specification consists of ) The Common Data Representation CDR) definition. This is a transfer syntax mapping OMG IDL data types into a low-level representation to be used on the wire ) The GIOP Message Formats. Messages are for object requests, object location and management of communication channels. ) GIOP Transport Assumptions. This is general &' assumptions regarding the transport layer. Protocols for CORBA: IIOP CORBA Products IIOP - Internet Inter-Orb Protocol is a mapping of GIOP to be carried over TCP/IP. The IIOP specification consists of % The GIOP specification. % Internet IOP Message Transport. This part describes how TCP/IP connections are opened and used for GIOP messages. IIOP is the protocol that makes it possible to interconnect ORB:s from different vendors, as well as using CORBA over Internet. Interoperable Object References IOR) are globally unique names that has to be used between different ORB:s. Inprise VisiBroker Borland+Visigenic) world leader) IONA Orbix biggest in Sweden) OOC ORBacus formerly OmniBroker) GNOME ORBit Included in J2SE 1.4 The Free CORBA page gives a lot of information about CORBA products both commercial and free): http://adams.patriot.net/~tvalesky/freecorba.html &* &, 8