1 / 45

Common Object Request Broker Architecture

Common Object Request Broker Architecture. Ali Ghodsi aligh@imit.kth.se. Goal of lecture. Go a bit more into depth on the core architecture of CORBA Less breadth Read van Steen’s book. Reading suggestions. Tanenbaum & van Steen CORBA Section 2.3 page page 85-98

apu
Download Presentation

Common Object Request Broker Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Object Request Broker Architecture Ali Ghodsi aligh@imit.kth.se A. Ghodsi aligh@imit.kth.se

  2. Goal of lecture • Go a bit more into depth on the core architecture of CORBA • Less breadth • Read van Steen’s book A. Ghodsi aligh@imit.kth.se

  3. Reading suggestions • Tanenbaum & van Steen • CORBA • Section 2.3 page page 85-98 • Section 3.2.2 page 152-158 • Section 9.1 • Read chapter 9 and compare other systems with CORBA • Compare RPC and DCE Remote Objects with CORBA • Links • Nice CORBA tutorial: • http://www.omg.org/gettingstarted/ A. Ghodsi aligh@imit.kth.se

  4. Outlook • General Overview • General Information • Applications • Quick Architectural Overview • OOP plus Distribution Transparency • CORBA main overview • Interface Definition Language (IDL) • Types • Examples • Mappings • ORB • DII (and DSI) • ORB interface • Object Reference • POA • Persistent and Transient Objects • Conclusions A. Ghodsi aligh@imit.kth.se

  5. General CORBA Information • Distributed Object Model (more later) • It is a middleware • Difference between Network OS  Middleware? • Only a standard (v 2.7, 3.0) • No reference implementation! • Many independent implementations • OMG - Non-profit organization • 800 members! • Standardized UML and more… A. Ghodsi aligh@imit.kth.se

  6. Real World Applications? • Support ”dinosaurs” • Companies have invested years of development in projects done in ADA, C, Smalltalk… • CORBA enables interoperability with new languages • Languages with small user-base • Eg Erlang, again interoperability • Big ERM, ERP, IS • Many different architectures, languages, platforms… A. Ghodsi aligh@imit.kth.se

  7. Outlook • General Overview • Quick Architectural Overview • OOP with Distribution Transparency • CORBA overview • Interface Definition Language (IDL) • Types • Examples • Mappings • ORB • Conclusions A. Ghodsi aligh@imit.kth.se

  8. CORBA builds on the DOM • Provides a nice model • Encapsulation • Inheritance • Polymorphism A. Ghodsi aligh@imit.kth.se

  9. Exploiting Encapsulation • Encapsulation enables: • Distribution Transparency • Have stubs and skeletons that together with ORBs enable distribution*. • Inter-operability** • Define interfaces in a standardised way • Interface Definition Language (IDL) A. Ghodsi aligh@imit.kth.se

  10. public interface MathBox { int add(int x, int y); } publicclass MathBoxCL implements MathBox { MathBoxCL() {} int add(int x, int y) { return x+y; } } Transparently distribute … MathBox obj = new MathBoxCL(); System.out.println(obj.add(10,20)); … Goal 1: Distribution Transparency • Encapsulation: black-box principle • Has an interface • Implementation details hidden A. Ghodsi aligh@imit.kth.se

  11. Missing parts: • Marshalling • Unmarshalling • References • Binding client to server MathBoxCL (SKELETON) int invoke(msg msg) { int x, y; x=msg.Unmarshall(INT); y=msg.Unmarshall(INT); res=serverImpl.add(x,y); Msg msg=new Msg(); msg.marshall(res); SendRespMsg(HOST,IP,msg); } MathBoxCL (PROXY) int add(int x, int y) { Msg msg=new Msg(); msg.Marshall(x); msg.Marshall(y); SendReqMsg(HOST,IP,msg); } Distribution Transparency Client … MathBox obj = new MathBoxCL(); Integer result = obj.add(10,20); … Server Implementation int add(int x, int y) { return x+y; } MathBoxCL (SKELETON) int invoke(msg msg) { int x, y; x=msg.Unmarshal(INT); y=msg.Unmarshal(INT); res=serverImpl.add(x,y); Msg msg=new Msg(); msg.marshal(res); SendRespMsg(HOST, IP, msg); } MathBoxCL (PROXY) int add(int x, int y) { Msg msg=new Msg(); msg.Marshal(x); msg.Marshal(y); SendReqMsg(HOST,IP,msg); } A. Ghodsi aligh@imit.kth.se

  12. C++ JAVA Goal 2: Inter-operability • Use a language with standardized syntax to define the interface • Generate the stub and the skeleton • Programming Language Independent MathBoxCL (SKELETON) int invoke(Msg msg) { int x, y; msg=GetMsg(); x=msg.Unmarshal(INT); y=msg.Unmarshal(INT); res=serverImpl.add(x,y); Msg msg=new Msg(); msg.marshal(res); SendRespMsg(HOST, IP, msg); } MathBoxCL (STUB) int add(int x, int y) { Msg msg=new Msg(); msg.Marshal(x); msg.Marshal(y); SendReqMsg(HOST,IP,msg); } A. Ghodsi aligh@imit.kth.se

  13. operation() Client Object Implementation args + return value Object Adapter STUB SKELETON Network ORB Core ORB Core ORB-dependent implementation Application specific Stub and Skeleton Same inteface. ORB-independent Overview A. Ghodsi aligh@imit.kth.se

  14. Outlook • General Overview • Architecture Overview • Interface Definition Language (IDL) • Types • Example • Language Mappings • ORB • Conclusions A. Ghodsi aligh@imit.kth.se

  15. Interface Definition Language • Builds on OOP principle of encapsulation • Clear boundary between implementation and interface • Independent • Programming Language (Only OO?) • OS • Platform • Network Connection • etc • Can be converted to a binary format and stored in a database (i.e. well-defined schema, iterators) • InterfaceRepository (IR) • A Repository ID for each interface A. Ghodsi aligh@imit.kth.se

  16. IDL’s Type System • Two levels: • Interfacesfor CORBA objects! • One interface per CORBA object • Official types for variables • integers, floats • struct, enum • array • string • binary values • …and more! • Scoped types • modules • exceptions • Interfaces • structs A. Ghodsi aligh@imit.kth.se

  17. Examples DSLABS.IDL: typedef string GroupMembers[4]; interface DS_project { long register_project(inlong groupId, in string status, inoutstring date); long get_status(inlong groupId, out string state, out string date, out GroupMembers gm); }; A. Ghodsi aligh@imit.kth.se

  18. IDL language mappings • OMG defines mappings to different languages • C, C++, Java, Smalltalk, COBOL, Ada, Lisp, PL/1, Python, and IDLscript • Proprietary mappings exist for obscure languages, though not standardized! • Every ORB has an IDL compiler • Creates • A STUB and • A SKELETON A. Ghodsi aligh@imit.kth.se

  19. Outlook • General Overview • Architecture Overview • Interface Definition Language (IDL) • ORB • DII (and DSI) • ORB interface • Object References • POA • Persistent and Transient Objects • Conclusions A. Ghodsi aligh@imit.kth.se

  20. Compile time vs Runtime? • What if interfaces change? • Recompile everything? Unfeasable • Dynamic interface definitions required: • IS (Information Systems) • ERM (Enterprise Resource Management systems) • Batch Service • etcetera A. Ghodsi aligh@imit.kth.se

  21. Dynamic Invocation Interface (DII) • Generic run-time invocation • No compile-time knowledge of CORBA object interfaces • No stub and skeleton needed a-priori • Instead, a generic interface is used • Of course defined in IDL A. Ghodsi aligh@imit.kth.se

  22. Dynamic Invocation Interface (DII) cont. • In essence: • Search and fetch an IDL from an Interface Repository. (remember binary presentation of IDL) • Construct a request • Specify target object, operation, and parameters • Invoke the request • C++ (not entirely true) • invoke(remoteObj, ”getStatus”, paramters) • Java uses reflection/introspection (transparent): • remoteObj.getStatus(paramters); A. Ghodsi aligh@imit.kth.se

  23. operation() Client Object Implementation args + return value Object Adapter Static Stub Dynamic Skeleton Interface Static Skeleton Dynamic Invocation Network ORB Core ORB Core ORB-dependent implementation Application specific Stub and Skeleton Same inteface. ORB-independent Complete picture A. Ghodsi aligh@imit.kth.se

  24. Object References • Remote object references • Enable clients to invoke CORBA objects • Three incarnations • Language specific implementation • E.g. pointer to a stub in C++ implementing the IDL • Not valid outside local computation space • Language independent ORB representation • IOR, Inter-operable Object Referenece • Supported by all ORBs • Textual representation • Send by e-mail, store in DB, textfiles and so on. A. Ghodsi aligh@imit.kth.se

  25. Remote Object Reference Type Name (Repository ID) Object Key (Adapter & Object Name) Protocol Hostname & Port *GIOP, address, portex:”IIOP v1.0”,”ripper.it.kth.se”, 8765 *Which object adapter, which object? ex:”OA5”, ”_DSD” Repository ID ex:”IDL:KTH/imit/DSD:1.0” Inter-operable Object References (IOR) ”Reference to an object on a server A. Ghodsi aligh@imit.kth.se

  26. Dynamic Skeleton Interface Static Skeleton Dynamic Invocation Static Stub Object Adapter Network ORB Core ORB Core ORB-dependent implementation Application specific Stub and Skeleton Same inteface. ORB-independent ORB Interface operation() Client Object Implementation args + return value ORB Interface A. Ghodsi aligh@imit.kth.se

  27. ORB Interface • Standard interface (defined in IDL) • All ORBs implement this interface • Important services provided: • Bootstrapping, getting initial references • Converting Object References to Strings and vice versa • Object Reference Counting • Distributed garbage collection A. Ghodsi aligh@imit.kth.se

  28. How do I get an IOR? • All ORBs implement: • string_to_object() file, e-mail, phone :) • resolve_initial_references() Returns an IOR for naming service, interface repository • Continue to search for IOR’s in a naming service A. Ghodsi aligh@imit.kth.se

  29. ORB Interface Dynamic Skeleton Interface Static Skeleton Dynamic Invocation Static Stub ORB-dependent implementation Application specific Stub and Skeleton Same inteface. ORB-independent Portable Object Adapter (POA) operation() Client Object Implementation args + return value Object Adapter Network ORB Core ORB Core A. Ghodsi aligh@imit.kth.se

  30. Why Object Adapters? • Several clients call the same object, what to do? • Demultiplex requests Server DsObject::calculate() { ... } Client 1 dsObject.calculate(); Client 2 dsObject.calculate(); A. Ghodsi aligh@imit.kth.se

  31. Why Object Adapters? (2) • Queue requests or run in separate threads? • Serialize all requests • One thread per object • One thread per invocation • Pool of threads Server DsObject::calculate() { ... } Client 1 dsObject.calculate(); Client 2 dsObject.calculate(); A. Ghodsi aligh@imit.kth.se

  32. Why Object Adapters? (2) • Security between the objects? • Sandboxing? • Share methods, separate data? Server DsObject::calculate() { ... } Client 1 dsObject.calculate(); Client 2 dsObject.calculate(); A. Ghodsi aligh@imit.kth.se

  33. Why Object Adapters? (2) • Lifespan policy: • Transient objects • Persistent Objects • Continues to exist even if activated/deactivated? Server DsObject::calculate() { ... } Client 1 dsObject.calculate(); Client 2 dsObject.calculate(); A. Ghodsi aligh@imit.kth.se

  34. Portable Object Adapter – PL meets ORB! • POA is generic and CORBA object independent and implements different activation policies • POA keeps pointers to skeletons* • An Object Identifier is associated with object. • A table called Active Object Map maps between Object Identifers => Skeletons A. Ghodsi aligh@imit.kth.se

  35. Portable Object Adapter OBJ 3 OBJ 1 OBJ 2 skel3 skel1 skel2 POA2(policy2) Invoke the right skeleton POA1 (policy1) Invoke right skeleton Active Object Map OBJ3 -> skel3 Active Object Map OBJ2 -> skel2 OBJ1 -> skel1 Server Demultiplexer Dispatch requests to the right POA POA1 POA2 A. Ghodsi aligh@imit.kth.se

  36. STUB: Object Reference Reply message return variables, out parameters Request message IDL:Institution/IT/DSD:1.0 ”IIOP v1.0”,”ripper”, 8765 ”OA5”, ”_DSD” Unique ID : ”13FABCDA” Unique ID : ”13FABCDA” ”OA5”, ”_DSD” student_operation() + *par Active Object Maps OA4: _InfoSec OA5: _DSC _DSD Transient Object Illustration Client _dsd->student_operation() Object Implementation Stub Skeleton Object Adapter ORB Core ORB Core A. Ghodsi aligh@imit.kth.se

  37. Persistent Objects • A IOR to a Persistent Object always points to the same object • Migration Transparency • Location Transparency • Ceases to exist only if the CORBA object is logically destroyed • Might move • Might change IP, Port, Machine • Might change POA • etc A. Ghodsi aligh@imit.kth.se

  38. Persistent Objects continued • Its life cycle is independent of the objects • I.e. its existence is independent of whether the object is in the local address-space. • ORBs can automatically startup objects implementing persistent CORBA objects A. Ghodsi aligh@imit.kth.se

  39. How is this possible? • Implementation repository (IMR) is used • Keeps information about • Object Adapter • Startup Command • Current Server A. Ghodsi aligh@imit.kth.se

  40. Reply message return variables, out parameters Request message Unique ID : ”13FABCDA” Unique ID : ”13FABCDA” ”OA5”, ”_DSD” Location Forward student_operation() + par Active Object Maps OA4: _InfoSec OA5: _DSC _DSD STUB: Object Reference IDL:KTH/imit/DSD:1.0 ”IIOP v1.0”,”IMR”, 8765 ”OA5”, ”_DSD” ”IIOP v1.0”,”ripper”, 313 Persistent Objects Illustrated Client _dsd->student_operation() Implem. Repository Object Implementation IMR Table ORB Core Stub ORB Core Skeleton ORB Core A. Ghodsi aligh@imit.kth.se

  41. Type Name (Repository ID) Object1 Key (Adapter1 & Object1 Name) Object2 Key (Adapter2 & Object2 Name) Failure and replication (IOR cont) Multiple locations in one reference. If an invocation fails, go to next location Protocol1 Hostname1 & Port1 ”Reference to an object on a server Protocol2 Hostname2 & Port2 Remote Object Reference *GIOP, address, portex:”IIOP v1.0”,”ripper.it.kth.se”, 8765 Repository ID ex:”IDL:KTH/imit/DSD:1.0” HOST1/PORT2/ADAPTER2/OBJECT2ex: ripper1/1234/oa1/obj1 HOST2/PORT2/ADAPTER2/OBJECT2ex: ripper2/3233/oa3/obj6 … A. Ghodsi aligh@imit.kth.se

  42. Summary-1 • CORBA is a standardization effort • Based on the the Distributed Object Model • Provides inter-operability • Uses proprietary interface language: IDL • All CORBA objects have an interface in IDL • Most of the services offered by CORBA have an interface in IDL A. Ghodsi aligh@imit.kth.se

  43. Summary-2 • Provides both Dynamic and Static invocations • DII/DSI and STUBS/SKELETONS • Stubs/Skeletons talk to an ORB • The ORB uses a standardized protocol to exchange • Messages(Req/Resp), IORs (persistent/transient) • ORB uses a POA to implement different activation policies • Threading policy • Lifespan policy (Persistent vs. Transient Objects) • Security (sandboxing of object implementations) A. Ghodsi aligh@imit.kth.se

  44. What did I miss? • A whole lot!  • CORBA facilities/services • Synchronization • Caching • Replication • Fault-tolerance • Security • Comparison of CORBA against • .NET • DCOM • Java RMI • etcetera • Please read chapter 9! A. Ghodsi aligh@imit.kth.se

  45. The End THANK YOU VERY MUCH! A. Ghodsi aligh@imit.kth.se

More Related