530 likes | 717 Views
Distributed Objects Using CORBA. CMSC 432 Shon Vick. Talk Outline. Introduction Technical Overview An example - Client and Server The anatomy of an ORB Concluding remarks References for future study. Introduction to CORBA. CORBA stands for Common Object Request Brokering Architecture
E N D
Distributed Objects Using CORBA CMSC 432 Shon Vick
Talk Outline • Introduction • Technical Overview • An example - Client and Server • The anatomy of an ORB • Concluding remarks • References for future study
Introduction to CORBA • CORBA stands for Common Object Request Brokering Architecture • So what is an object (class, interface)? • Collection of data items usually called attributes or slots • Collection of behavioral attachments usually called methods
What Is Distributed Computing All About • Goal is to break up a monolithic application into smaller components • Client - user of a resource • Server - provider of a resource Request Client Server Response
What Is CORBA All About? • CORBA allows methods to be invoked in a distributed fashion • Distributed objects: The next client/server revolution • CORBA is perhaps the most important but certainly the largest middleware project ever undertaken
CORBA Overview • CORBA is the product of a consortium called the Object Management Group (OMG) • OMG includes over 500 major companies • Microsoft is absent from this coalition • Microsoft has its own competing object bus called component object model (COM)
Object Management Group (OMG) General Background • Not-for-profit company based in US with representatives in UK, Japan and Germany • Founded in April 1989 • Small staff - they do no development • Create and maintain standards for object-oriented application integration
Central OMG Mission • The central motivation of OMG is to solve application integration problems • Develop a single architecture for distributed applications that • Is based on reusable components • Has interoperability as central concern • Biased towards commercially available software
Technical Goal • Improve systems interoperability and portability based on commercially available software • Single terminology for object-orientation • Common abstract framework • Common interfaces and protocols
Application Integration and Distributed Processing • OMG view - application integration and distributed processing are essentially the same problem • CORBA allows information sharing across distributed systems from diverse sources • Heterogeneous • Networked • Physically removed • Multi-vendor
Technical Overview of Architecture • The client and object implementation are isolated from the ORB by an IDL interface • CORBA requires that objects be defined by OMG IDL • A method request does not pass directly from client to server but rather is mediated by the ORB • Method invocation is the same whether the object is local or remote
C++ Java IDL IDL Server Client CORBA Interfaces • IDL - interface definition language • CORBA is language independent • Can provide a standard notation for software components • IDL supports library function interfaces just as well as distributed objects across a network ORB
IDL - Separating Interface From Implementation • A standard notation language for defining interfaces to objects • OMG IDL is a simple subset of C++ • IDL is like a contract for defining an API • Designed to be efficient across networks
All Interfaces Are in IDL • Many language bindings are available • Ada • C++ • C • Java … • Creation of IDL is essential part of the design process
C C++ ORB Ada Role of OMG IDL Client Side Object Implementation Side COBOL C I D L I D L I D L I D L COBOL Ada I D L I D L ORB I D L I D L Small talk I D L I D L I D L I D L Small talk C++ C++ JAVA JAVA
How the IDL is Used IDL IDL Compiler Object Impl Code Client Code Skeleton Code Stub Code Language Compiler and Linker Client Object Stub Skel ORB
Programming Steps • Define the IDL interfaces • Implement these interfaces with C++ classes • Write a client mainline to bind to server • Write a server mainline which creates instances of the classes • Register the server
A Simple Sample of the Process • A simple IDL definition // IDL definition // In file grid.idl interface Grid { readonly attribute short height; readonly attribute short width; void set(in short , in short m , in long value); long get (in short , in short m ); };
Compiling the Simple IDL idl -B-h .h -c _client.cc -s _server.cc -R grid.idl • Creates a header file grid.h with the definition of an implementation base classes called Grid and GridBOAImpl • Creates a source file grid_client.cc to be compiled and included into the clients of the grid • Creates a source file grid_server.cc to be compiled and included into the implementation of the grid server
The C++ Produced class Grid: public virtual CORBA::Object { public: // ... virtual CORBA::Short height (CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException); virtual CORBA::Short width (CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException); virtual void set (CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException); virtual CORBA::Long get (CORBA::Short n, CORBA::Short m, CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException); // ... }; class GridBOAImpl : public virtual Grid { // … };
Notes on the C++ Produced • The IDL compiler also produces other members for the class that we will ignore • The mapping to C++ member functions is straightforward • Each IDL attribute becomes a member function (pair if not readonly) • Each method becomes a member function
A Look at the BOA Impl Class class GridBOAImpl : public virtual Grid { public: // ... virtual CORBA::Short height (CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException) = 0; virtual CORBA::Short width (CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException) = 0; virtual void set (CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException) =0; virtual CORBA::Long get (CORBA::Short n, CORBA::Short m, CORBA::Environment &IT_env=CORBA::IT_chooseDefaultEnv ()) throw (CORBA::SystemException) =0; // ... };
Regarding the BOA Class that is Constructed • BOA stands for Basic Object Adapter • The BOA class has C++ member functions for attributes and IDL methods • Each of these member functions is declared as a C++ pure virtual member function • A pure virtual member function in C++ specifies an interface only • A class that inherits from the BOA Impl class must define these methods
Implementing the Interface • The programmer must write a C++ class which provides the functions that implement the member functions specified in the IDL • In order to do this we build atop another class from grid.h called GridBOAImpl
A Look at the Implementation class GridImpl : public GridBOAImpl { CORBA::Short m_height; // store the height CORBA::Short m_width; // store the width CORBA::Long **m_a; // a 2-D array to store the GridImpl data itself public: // constuctor GridImpl(CORBA::Short h, CORBA::Short w); // destructortor virtual ~GridImpl(); // functions corresponding to the two IDL readonly attributes. // The CORBA::Environment parameter is for error handling // in the client. virtual CORBA::Short width(CORBA::Environment &env); virtual CORBA::Short height(CORBA::Environment &env); // functions corresponding to the two IDL operations // The CORBA::Environment parameter is for error handling // in the client. virtual void set(CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment &env); virtual CORBA::Long get(CORBA::Short n, CORBA::Short m, CORBA::Environment &env); };
Client/Server Interaction • Client creates an object • Object bound to remote server • Method invocation request made
The Client/Server Request Using the ORB Server Client Corba Object Adapter Corba API Object Request Broker Request
Remote Invocation of Methods Server Grid Object Implementation Client gVar->set(2,4,123) Skeleton Stub Object Request Broker Request
About the Client • The object reference gVar must be bound to an object of type Grid, running in a GridSrv server. • This is done by calling _bind() (which is a static member function of class Grid). More elaborate • binding can be done, and C++ exception handling can be included. • // C++ In file Client.C. • ... • try { • gVar = Grid::_bind(":GridSrv", hostname); • h = gVar->height(); • w = gVar->width(); • } catch(CORBA::SystemException& se) { • cerr << "Call "unexpected exception: " << &se; • exit(1); • } • ... • The call to _bind() or to any of the member functions could fail, especially if the call is to a • remote machine. Such calls should be enclosed within C++ try blocks which will allow any • exceptions thrown by function calls within the block to be handled by the subsequent catch • clauses.
A More Detailed Client int main (int argc, char **argv) { Grid_var GridVar; // pointer the Grid object that will be used. CORBA::Short h, w; CORBA::Long v; if (argc < 2) { cout << "usage: " << argv[0] << " <hostname>" << endl; exit (-1); } try { // First bind to the Grid object. // argv[1] has the hostname (if any) of the target Grid object; // The default is the local host: GridVar = Grid::_bind(":GridSrv", argv[1]); } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl; cerr << &sysEx; exit(1); } catch(...) { // an error occurred while trying to bind to the Grid object. cerr << "Bind to object failed" << endl; cerr << "Unexpected exception " << endl; exit(1); }
The Client Continued • Invoke the height and width methods • Catch exceptions if there are problems try { // try to read the height and width of the Grid: h = GridVar->height(); w = GridVar->width(); } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl; cerr << &sysEx; exit(1); } catch(...) { // an error occurred while trying to read the height and width: cerr << "call to height or width failed" << endl; cerr << "Unexpected exception " << endl; exit(1); }
The Simple Server • The role of the server mainline in this simple example is to create an object • The starting point is a call to impl_is_ready • passes the name of the server • signals that object initialization is complete • The server stays up until no more requests are received within a timeout period
Providing a Server int main() { // create a grid object - using the implementation class grid_i GridImpl myGrid(100,100); try { // tell Orbix that we have completed the server's initialisation: CORBA::Orbix.impl_is_ready("GridSrv"); } catch (CORBA::SystemException &sysEx) { cerr << "Unexpected system exception" << endl; cerr << &sysEx; exit(1); } catch (...) { // an error occured calling impl_is_ready() - output the error. cout << "Unexpected exception" << endl; exit(1); } // impl_is_ready() returns only when Orbix times-out an idle server // (or an error occurs). cout << "server exiting" << endl; return 0; }
A Few Points about the Server • This server program creates a GridImpl object, giving it an initial size. • It then indicates to Orbix that the server's initialization has completed, by calling impl_is_ready(). • The parameter to impl_is_ready() is the name of the server as registered in the Implementation Repository. • CORBA::Orbix is an object which is used to communicate directly with Orbix. • As used here,impl_is_ready() is a blocking call that returns only when Orbix times-out the idle server.
Registering the Server • The server has to be registered so that it will be run automatically when a client uses the Grid object • Registration is done with the putit command • putit GridSrv full-name-of-server-executable
Some Comments on the Simple Example • Actual interfaces tend to be a good deal more complicated • The IDL interface mechanism has many of the components of a C++ class definition • includes • typedefs • inheritance • compiler directives • templates • modules
The Essential Role of the IDL • Client IDL stubs provide the static interface to object services • As we’ve seen these pre complied stubs define how clients invoke corresponding services on the servers • The IDL stubs perform marshalling • encoding and decoding of request and args to flattened form for shipment across net to/from server
Dynamic Queries • Suppose you want to do a dynamic query - scripting • The Dynamic Invocation Interface (DII) lets you construct a method invocation at run-time • The Interface Repository (IR) allows one to obtain and modify the descriptions of all registered component interfaces • The IR is a run-time database for the IDL defined interfaces
The DII • The DII enables a client to • discover object interfaces • retrieve their interface definitions • construct and dispatch invocations • receive the resulting resulting response or exception information • Does this remind you of something?
DII Invocations • Use of the IDL compiler static IDL stubs requires a client to have available (possibly by dynamic link loading) the marshalling stub code used to access any of the remote objects which its uses. • For some applications, this constraint may be too restrictive.
Dynamic Invocations • DII is awkward • lookup • create_request • create_list • add_arg • IONA Orbix CORBA implementation provides a stream based interface to the DII that while is not CORBA compliant is a good deal easier to use
DII Invocations in Orbix // Building the request dynamically in Client.C ... CORBA::Long result; CORBA::Short x = 2; CORBA::Short y = 4; // Initialize an object reference and a request CORBA::Object_var target = CORBA::Object::_bind (":GridSvr",hostname); CORBA::Request_var r = target->_request("get"); // stream in the arguments, and make call *(r->arguments()->add(CORBA::ARG_IN)->value()) <<= x; *(r->arguments()->add(CORBA::ARG_IN)->value()) <<= y; // invoke try { r->invoke(); // obtain result *(r->result()->value())) >>= result; } catch(CORBA::SystemException &ex) { cerr << "Unexpected Exception: " << endl << &se; // further error processing } }
The Structure of An ORB Implementation Repository Object Implementation Client Interface Repository Static Skeletons Dynamic Skeleton Invocation Object Adapter Dynamic Invocation Client IDL Stubs Object Request Broker Core
Corba Elements on the Server Side • The IDL server stubs • called skeletons in the OMG parlance • provide static interfaces to each service supported by an interface on the server • created by the IDL compiler
Server Side Corba Elements • The Object Adapter • sits atop the ORB’s core communication services • provides the run-time environment for instantiating server objects, passing requests to them and assigning them object Ids (Ccalled object references in OMG parlance) • registers run-time instances with the Implementation Repository • BOA is just one type - must be supported
Server Side Corba Elements (cont) • The Dynamic Skeleton Interface (DSI) • Introduced in CORBA 2.0 provides a run-time binding mechanism for servers that need to handle incoming method calls for which there is no IDL based skeleton • The DSI is the server side equivalent to the DII
The Purpose of the ORB • The ORB mediates between applications • The client and server may or may not be on the same machine • The client and server may even be a WAN • CORBA 2.0 introduces the IIOP • Internet Inter-ORB Protocol • ORBs must inter operate • Client and Server vendors may not be the same
CORBA Application Level Integration • CORBA is a great accomplishment but it connects only objects not applications • The OMG provides enterprise integration in the Object Management Architecture (OMA) • The OMA specifies a lower level set of CORBA services as well as an intermediate level of CORBA facilities
OMA CORBA Services • The CORBA Services provide basic functionality to support • object lifecycle services like move, copy • object persistence • object naming and directory services • object trader/advertising services (yellow pages for objects) • object security
CORBA Facilities • Provide services for applications not objects • Example • CompoundDocumentManagment facility gives applications a standard way to access components of a compound document • CORBA facilities have a horizontal and vertical components • horizontal component - general components like above • vertical - industry specific components - like banking, healthcare ...