1 / 29

CORBA Case Study

CORBA Case Study. By Srinivas Narayanabhatta 21 st March 2002. What is CORBA ?. Common Object Request Broker (ORB) Architecture CORBA is OMG standard (Object Management Group) to make better use of distributed systems to use object-oriented programming

lenora
Download Presentation

CORBA Case Study

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 Case Study By Srinivas Narayanabhatta 21st March 2002

  2. What is CORBA ? • Common Object Request Broker (ORB) Architecture • CORBA is OMG standard (Object Management Group) • to make better use of distributed systems • to use object-oriented programming • to allow objects in different programming languages to communicate with one another

  3. Evolution of CORBA • CORBA 1.1 (1992) • Basic ORB, Naming, Interface Repository, C bindings, Events, Basic Object Adapter,… • CORBA 2.0 (1995) • Internet Inter-ORB Protocol (IIOP), C++ bindings, Transactions, Security,… • CORBA 3.0 (and 2.2) (1998) • Messaging (MOM), Portable Object Adapter (POA), CORBA/DCOM interoperability, Java bindings, Objects by Value, Component Model,…

  4. Object Management Architecture(OMA)

  5. Client stubs/proxies • these are in the client language. • an IDL compiler for the client language uses an IDL interface to generate one of the following: • for object-oriented languages the class of a proxy • for procedural languages a set of stub procedures. • as before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies. Dynamic invocation interface In some applications (e.g. browsers), a client without the appropriate proxy class may need to invoke a method in a remote object. CORBA does not allow classes for proxies to be downloaded at run time as in Java RMI. The dynamic invocation interface is CORBA’s alternative. (we will discuss it later with the Interface Repository) ORB core The role of the ORB core is similar to that of the communication module of Figure 5.6. In addition, an ORB core provides an interface that includes the following: - operations enabling it to be started and stopped; - operations to convert between remote object references and strings; - operations to provide argument lists for requests using dynamic invocation. Implementation repository • activates registered servers on demand and locates running servers • uses the object adapter name to register and activate servers. • more about this later Skeletons • skeleton classes (for OO languages) are generated in the language of the server by an IDL compiler. • remote method invocations are dispatched via the appropriate skeleton to a particular servant, • the skeleton unmarshals the arguments in request messages and marshals exceptions and results in reply messages. Object adapter • an object adapter bridges the gap between • CORBA objects with IDL interfaces and • the programming language interfaces of the corresponding servant classes. • it does the work of the remote reference and despatcher modules in Fig. 5.6 • more about the object adapter later. server client implementation interface repository repository skeleton object adapter Request ORB client proxy Servant ORB program for A core A core Reply or dynamic invocation or dynamic skeleton The main components of the CORBA architecture • The CORBA architecture is designed to allow clients to invoke methods in CORBA objects • clients and objects can be implemented in a variety of programming languages • it has the following additional components compared to Figure 5.6 • object adapter, implementation repository and interface repository Figure 17.6

  6. CORBA RMI • CORBA's Object Model • Clients are not necessarily objects • The CORBA Object – refers to remote object implements an IDL interface. • CORBA IDL • Specifies a name and set of methods that clients can request • CORBA objects are passed by reference and primitives and constructed types are passed by value. • The CORBA Naming Service • CORBA pseudo Objects • Implementations of CORBA provide some interfaces to the functionality of ORB. E.g.. ORB and its methods init, connect

  7. CORBA IDL Same lexical rules as C++ but has additional keywords to support distribution. E.g. interface, in, out, inout, readonly, raises • IDL Modules • Allows interfaces and other IDL type definitions to be grouped in logical units. • IDL Interfaces • Describes the methods that are available in CORBA objects that implement that interface. • IDL Methods • in parameter passed from the client to the invoked CORBA object • out parameter is passed back from the invoked CORBA object to client.

  8. CORBA IDL contd.. • inout – indicate value may be passed in both directions • oneway – indicates client invoking the method will not be blocked while the target object is carrying out a method. • raises – indicates user-defined exceptions that can be raised. • IDL Types • IDL supports fifteen primitive types. • Object – indicates values of remote objects. • Attributes • These are like public class fields in Java. • Inheritance • IDL interfaces may be extended (multiple inheritance). • All IDL interfaces inherit from type Object • No operation overloading.

  9. IDL Example struct Rectangle{ 1 long width; long height; long x; long y; } ; struct GraphicalObject { 2 string type; Rectangle enclosing; boolean isFilled; }; interface Shape { 3 long getVersion() ; GraphicalObject getAllState() ; // returns state of the GraphicalObject }; typedef sequence <Shape, 100> All; 4 interface ShapeList { 5 exception FullException{ }; 6 Shape newShape(in GraphicalObject g) raises (FullException); 7 All allShapes(); // returns sequence of remote object references 8 long getVersion() ; };

  10. From IDL to Java Stubs

  11. CORBA language Mappings • The primitive types in IDL are mapped to the corresponding primitive types in Java • Structs, enums and unions are mapped to Java classes • Sequences and arrays in IDL are mapped to arrays in java. • The mappings in C++ are similarly straight forward.

  12. a servant class extends the corresponding skeleton class (e.g. ShapeListImplBase) a servant class implements the methods in the interface (ShapeList). newShape is a factory method. It creates new CORBA objects. It uses the connect method to inform the ORB about the new CORBA object. (it has a remote reference module) The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3 This class has to create CORBA objects of type Shape. How does it do that? import org.omg.CORBA.*; class ShapeListServant extends _ShapeListImplBase { ORB theOrb; private Shape theList[]; private int version; private static int n=0; public ShapeListServant(ORB orb){ theOrb = orb; // initialize the other instance variables } public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException { version++; Shape s = new ShapeServant( g, version); if(n >=100) throw new ShapeListPackage.FullException(); theList[n++] = s; theOrb.connect(s); return s; } public Shape[] allShapes(){ ... } public int getVersion() { ... } } • A Java server has classes for its IDL interfaces (e.g. Shape and ShapeList). Here is the class ShapeListServant CORBA objects are instances of servant classes. In non-OO languages implementations of CORBA objects can’t be classes. •

  13. it creates and initialises the ORB The server class contains the main method it gets a reference to the Naming Service narrows it to NamingContext- from Object makes a NameComponent containing the name “ShapeList” makes a path uses rebind to register the name and object reference it creates an instance of ShapeListServant class - a Java object - which is made a CORBA object by using the connect method to register it with the ORB it waits for client requests Java class ShapeListServer (the server class) import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListServer { public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); ShapeListServant shapeRef = new ShapeListServant(orb); orb.connect(shapeRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path[] = {nc}; ncRef.rebind(path, shapeRef); java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait();} } catch (Exception e) { ... } } } Figure 17.4 •

  14. it contacts the NamingService for initial context Narrows it to NamingContext It makes a name component It makes a path It gets a reference to the CORBA object called “ShapeList”, using resolve and narrows it it creates and initialises an ORB it uses one of the remote references in the array to invoke the getAllState method in the corresponding CORBA object whose type is Shape the value returned is of type GraphicalObject it invokes the allShapes method in the CORBA object to get an array containing remote references to all of the GraphicalObjects currently stored by the server Java client program for CORBA interfaces Shape and ShapeList import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListClient{ public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path [] = { nc }; ShapeList shapeListRef = ShapeListHelper.narrow(ncRef.resolve(path)); Shape[] sList = shapeListRef.allShapes(); GraphicalObject g = sList[0].getAllState(); } catch(org.omg.CORBA.SystemException e) {...} } Figure 17.5 •

  15. Static and Dynamic Invocations

  16. hostname and port number of server pathname of object implementation object adapter name Interface and Implementation Repositories • Implementation repository • it activates registered servers on demand and locates running servers • it uses the object adapter name to register and activate servers. • it stores a mapping from the names of object adapters to the pathnames of files containing object implementations. • when a server program is installed it can be registered with the implementation repository. • when an object implementation is activated in a server, the hostname and port number of the server are added to the mapping. • Implementation repository entry:

  17. Interface repository • it provides information about registered IDL interfaces • for an interface of a given type it can supply the names of the methods and for each method, the names and types of the arguments and exceptions. • a facility for reflection in CORBA. • if a client has a remote reference to a CORBA object, it can ask the interface repository about its methods and their parameter types • the client can use the dynamic invocation interface to construct an invocation with suitable arguments and send it to the server. • the IDL compiler gives a type identifier to each IDL type • a type identifier is included in remote object references • this type identifier is called the repository ID • because the interface repository stoes interfaces against their IDs • applications that use static invocation with client proxies and IDL skeletons do not require an interface repository. • Not all ORBs provide an interface repository.

  18. Object Adapter • an object adapter bridges the gap between • CORBA objects with IDL interfaces and • the programming language interfaces of the corresponding servant (classes). • it does the work of the remote reference and despatcher modules in Fig. 5.6. • An object adapter has the following tasks: • it creates remote object references for CORBA objects; • it dispatches each RMI via a skeleton to the appropriate servant; • it activates objects. • An object adapter gives each CORBA object a unique object name. • the same name is used each time an object is activated. • it is specified by the application program or generated by the object adapter. • Each active CORBA object is registered with its object adapter, • which keeps a remote object table to maps names of CORBA objects to servants. • Each object adapter has its own name - specified by the application program or generated automatically.

  19. IOR format IDL interface type name Protocol and address details Object key interface repository IIOP host domain port number adapter name object name identifier name CORBA remote object references • Transient IORs: • Last only as long as the process that hosts them. • Server ORB core receives the request, extracts object adapter name from IOR, locates the servant through object name • Persistent IORs: • Last between the activations of CORBA objects. • Implementation Repository receives the request, extracts object adapter name from IOR, attempts to activate if necessary, once activated returns its address details to the client ORB.

  20. CORBA Services • CORBA specification includes a set of generic services that are useful for the distributed objects. • Naming Service • Event Service • Notification Service • Security Service • Trading Service • Transaction and Concurrency control Services • Persistent object service

  21. Naming Service • Example of Naming Graph initial naming context initial naming context initial naming context XX B ShapeList V P C T D E S R Q U

  22. Figure 17.10Part of the CORBA Naming Service NamingContext interface in IDL • struct NameComponent { string id; string kind; }; • typedef sequence <NameComponent> Name; • interface NamingContext { • void bind (in Name n, in Object obj); • binds the given name and remote object reference in my context. • void unbind (in Name n); • removes an existing binding with the given name. • void bind_new_context(in Name n); • creates a new naming context and binds it to a given name in my context. • Object resolve (in Name n); • looks up the name in my context and returns its remote object reference. • void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi); • returns the names in the bindings in my context. • };

  23. event channel supplier consumer notification notification notification proxy consumer proxy supplier Event Service • The CORBA Event service specification defines interfaces allowing objects of interest, called suppliers, to communicate notifications to subscribers, called consumers. • Event Channels are CORBA objects that my be used to allow multiple suppliers communicate with multiple consumers in an asynchronous manner. • The notification itself transmitted as an argument or result whose type is any.

  24. Event Service – Interactive Models

  25. Notification Service • The CORBA Notification Service extends the CORBA Event Service. • Notification Service provides support for filtering events. • Notifications may be defined as data structures. • Event consumers can specify exactly which events they are interested in. • Event suppliers are provided with a means of discovering the events the consumers are interested in. • Event consumers can discover the event types offered by the suppliers on a channel.

  26. Security Service • Authentication of users and servers, generating credentials. • Access control can be applied to CORBA objects when they receive remote method invocation. • Access rights may be specified using ACLs. • The security service requires cooperation on behalf of ORB to guarantee the security. • To make a secure RMI, client’s credentials are sent with the request. • The access decision made by the consulting object.

  27. Platform Support for CORBA • Visibroker Leading CORBA ORB, Client integrated in Netscape • Orbix Leading CORBA ORB, was ported to LynxOS • Arbacus Commercial ORB, free for non-commercial use • OmniORB Free from AT&T, has been ported to LynxOS2.5.1 • ILU Free from Xerox.

  28. IONA – ORBIX Architecture

  29. CORBA – Strengths and Weaknesses • CORBA strength is in interoperability: languages, platforms, public domain software. • Has a very rich and complete set of facilities and services. • One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability. • There are many services defined but their implementations are slow to appear • By its working method OMG is creating compromises.

More Related