1 / 34

CORBA

CORBA. Distributed Computing in Action. A NDREW T . C AMPBELL Dept. of Electrical Engineering Columbia University http://comet.columbia.edu/campbell campbell@comet.columbia.edu. LECTURE 4. 29 September, 1998. Review of the “Middleware” Lecture.

urania
Download Presentation

CORBA

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. CORBA Distributed Computing in Action ANDREW T. CAMPBELL Dept. of Electrical Engineering Columbia University http://comet.columbia.edu/campbell campbell@comet.columbia.edu LECTURE 4 29 September, 1998

  2. Review of the “Middleware” Lecture • Defined object and discussed the notion of “middleware” • Discussed what distrbuted systems are • problem space they address • characteristics • notion of centralized vs distributed computing • Historical background and research at Columbia U. • We also introduced one middleware engine • CORBA

  3. Earn an extra 10% • Project WEB pages • the 3 top web pages will get 10% added to their final grade • what to include • interesting cool links to sites that are related to the project, e.g., • active networks • middleware research • products • course work • assignments, course project page, survey, etc. • open issue in the area • commentaries on the field by you • short notes expressing your understanding

  4. Why we need a “Software Bus” • We have “hardware bus” right? • Pluggin hardware using off-the-shelf equipment: uP, memory, “device bus” (e.g., PCI) • We have “communications bus” right? • The Internet • So what about a “software bus” • Do we need one? • Software and hardware are getting more complex • Comon language for clients talk to servers over the bus • key characteristic of the “bus” is “openess” • using standard mechanisms and “open” interfaces for and effective integration (“to bundle” ) to occur • So how do we realize a software bus? • CORBA’s ORB on example of a “software/obejct bus”

  5. “Programming” Students • Over the course of the next few lectures we will • Look at CORBA closely • What is the OMA? • Why do we need IDL • What is an ORB • let’s take a “peek” under the “hood” • CORBA programming tutorial and assignment • you will write a CORBA client • How does CORBA relate to telecommunications • new CORBA Telecoms book • http://www.omg.org/corba/ctfull.htm • two case studies using CORBA in the net • xbind: comet.columbia.edu/ • mobiware: comet.columbia.edu/mobiware

  6. Is CORBA middleware? • CORBA • Common Object Request Broker Architecture (CORBA) • Standardized by the Object Management Group (OMG) • checkout www.omg.org/corba for CORBA 2.2 • CORBA offers an “open” distributed object computing infrastructure for a variety of apps • real-time avionics, telecomms, medical imaging • take a look at the new CORBA Telecoms book • http://www.omg.org/corba/ctfull.htm • OMG is looking at “open” wireless platforms too

  7. CORBA in a nutshell • What does CORBA provide us with? • CORBA provides abstractions for distributed object-oriented programming that “you” to seamlessly integrate diverse applications into heterogeneous systems • What does Andrew mean? • simplifies application interworking • CORBA provides higher level integration that traditional untyped TCP bytestreams • provides a foundation for higher-level distributed collaboration • benefits for distributed programming similar to OO languages • encapsulation, interface inheritence, polymorphism and exception handling

  8. CORBA: as a Software Bus for Object Interaction • Software bus • CORBA provides a communications infrastructure for a heterogeneous collection of collaborating objects • analogy to hardware bus • What is the bus in reality? • The ORB (Object Request Broker) realizes the object bus • at the core on any CORBA-based systems • What does the ORB facilitate? • It hides the low-level details of platform-specific networking details allowing application developers to focus on solving the problems specific to their application domains rather than having to build their own distributed computing infrastructure

  9. Features • CORBA supports reliable, unicast synchronous and asynchronous communications • oneway, twoway, deferred sync and async • little support for QOS at the moment • CORBA objects may collaborate in client/server, peer-to-peer models • client/server and peer-to-peer are built into shared library

  10. Design principles • Separation of interface from implementation • Location transparency • Access transparency • Typed Interfaces • Inheritance of Interfaces

  11. CORBA Specification • Current “standard” • CORBA 2.0 • http://www.omg.org/corba/c2indx.htm • COBRA 3.0 • Under construction • New features

  12. Simple View • Client and object implementation • IDL thin layer “common language • ORB • Interface depositories (IR) • General Inter-ORB Protocol (GIOP) • Specifies a small set of standard messages that ORBs send to each other, so that clients and objects “see” object-oriented invocation and responses • Common Data Representation (CDR) for IDL datatypes • IIOP is important • TCP/IP transport • Network:

  13. CORBA for Beginners • Checkout the OMG page • http://www.omg.org/news/begin.htm • In particular for Thursday read • OMA Overview • Overview of CORBA by Doug Schmidt • A Brief Tutorial by Kate Keahey

  14. OMA • Object Request Broker • Object Services • Common Facilities • Domain Interfaces • Application Objects

  15. Object Model • Objects • virtualSwitch • Operations • Objects are created as instances of Types • set() and get() • Types • virtual switch type • One can view a type as a template for object creation. • A type characterizes the behavior of its instances by describing the operations that can be applied to those objects • Subtyping • the relationships between types are known as supertypes/subtypes.

  16. CORBA Architecture • Object implementation • Client • Object request broker (ORB) • ORB interface • CORBA IDL stubs and skeletons • Dynamic Invocation Interfaces (DII) • Dynamic Skeleton Interfaces • Object Adapter (BOA, POA)

  17. Object and Client • Object Implementation, e.g., server • This defines operations that implement a CORBA IDL interface. Object implementations can be written in a variety of language including C, C++, Java • Client • This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args).

  18. ORB • Object Request Broker (ORB) • The ORB provides a mechanism for transparently communicating client requests to target object implementations. • The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. • When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary delivering the request to the object, and returning any response to the caller

  19. ORB Interface • ORB Interface • An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). • To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. • This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface.

  20. CORBA IDL stubs and skeletons • CORBA IDL stubs and skeletons • CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. • The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. • The use of compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.

  21. Dynamic Invocation Interface (DII) • Dynamic Invocation Interface (DII) • This interface allows a client to directly access the underlying request mechanisms provided by an ORB. • Application use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. • Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.

  22. Dynamic Skeleton Interface (DSI) • Dynamic Skeleton Interface (DSI) • This is the server side's analogue to the client side's DII. • The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. • The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

  23. Object Adapter • Object Adapter • This assists the ORB with delivering requests to the object and with activating the object. • More importantly, an object adapter associates object implementations with the ORB. • Object adapters can be specialized to provide support for certain object implementation styles.

  24. ORB: Keeping the Core functions simple • Streamlining operations of the ORB • the key theme of the ORB is to keep it simple. More complex services (e.g., built in service directory) is pushed into other OMA components (e.g., object services) • to provide the communications and activation infrastructure for distributed objects

  25. ORB Core: transparency of operation • ORB delivers any responses from target objects to clients making requests • key feature is its transparency in facilitating client-object communications • object location • client does not know where the target objects reside • process, machine, etc. • object implementation • client does not know how the target object is implemented • language, OS or HW, etc. • object execution state • client does not need to know whether the target object os currently activated

  26. ORB Core: transparency of communications • Object communication mechanisms • client does not need to know the communicatons mechanism (e.g., TCP/IP, local call) • object reference is use to make a request. It is allocated when a CORBA object is created • the object ref. only ever refers to a single object • clients can obtain object references in several ways

  27. ORB Core: Obtaining Object References • Object creation • a creation request returns an object ref for the newly created object • creation requests are ordinary operation invocations on other objects called factory objects • Directory services • Clients can obtain ref by properties or name using the name and trader services • unlike factory objects these services do not create objects • they store object references and associated information for existing objects and supply them on request • Others: Convert to string and back • an application can have the ORB convert a object ref into a string and string to object ref

  28. OMG IDL // OMG IDL interface Factory { Object create(); }; • An object interface specifies the operations and types that the object supports and thus defines the request that can be made on the object • the definition specifies an interface named Factory that supports one operation: create • the create operation takes no parameters and returns object reference of type ‘Object’ • given an object ref for an object of type Factory, a client could invoke it to create a new CORBA object

  29. OMG IDL • An important feature of IDL is that it is language independent • it is a declarative language and not a programming language • because of this it enforces that interfaces to be defined separately from object implementation • this allows target objects to be constructed from different ‘programming languages’ • Types similar to other languages • basic: long, double, boolean • constructs: struct, unions and template types such as sequence and string • to define an exceptional condition that may occur during the course of an operation it provides ‘exception’ defintions

  30. Object Reference Types // OMG IDL interface FactoryFinder { // define a sequence of Fcatory // obejct refences typedef sequence<factory> FactorySeq; FactorySeq find_factories( in string interface_name); }; • FactoryFinder contains definition of a type names FactorySeq • FactorySeq type is defined as an unbounded sequence of Factory object refereneces • find factory operation takes an unbounded string type as an inout argument and returns an unbounded sequence of factory object reference • It is a directory service object for factories that helps application control the location at which they create objects

  31. Interface Inheritance // OMG IDL interface Factory { Object create(); }; // forward declaration of spreadsheet // interface (full definition not shown) interface Spreadsheet; // SpreadsheetFactory derives from Factory interface SpreadsheetFactory: Factory { Spreadsheet create_factory()

  32. Language mappings • IDL does not implement control or directly used to implement distributed applications • language mappings define how IDL features are mapped to the facilities of a given programming langauage • C, Java, C++ • C++ mappings, e.g., • IDL interfaces map to C++ classes with operations mapping to member functions of those classes • object reef map to objects that support the operator-> function (i.e., either a a normal C++ pointer to an interface class, or an object instance with an overloaded operator->)

  33. Interface repository • Applications must know the types of interfaces supported by objects being used • every CORBA-based application requires access to the OMG IDL type system • problems with static definitions and builds • IR allows the OMG IDL type system to be accessed and written programmatically at run time so that apps can dynamically discover and utilise type information (e.g., create changes to create_obejct)

  34. Other forms of “middleware” • Active network research • http://www.darpa.mil/ito/research/anets/index.html • Guest lecture • Lecture: John Vicente (Intel Corp) • Part 1: Tutorial on Active Network Research • Part 2: The Genesis Project • Middleware for dynamically programming and building virtual networks on-the-fly • Date: Tuesday October 13

More Related