Presentation is loading. Please wait.

Presentation is loading. Please wait.

© City University London, Dept. of Computing Distributed Systems / 5 - 1 Distributed Systems Session 5: Common Object Request Broker, (CORBA) Christos.

Similar presentations


Presentation on theme: "© City University London, Dept. of Computing Distributed Systems / 5 - 1 Distributed Systems Session 5: Common Object Request Broker, (CORBA) Christos."— Presentation transcript:

1 © City University London, Dept. of Computing Distributed Systems / Distributed Systems Session 5: Common Object Request Broker, (CORBA) Christos Kloukinas Dept. of Computing City University London

2 © City University London, Dept. of Computing Distributed Systems / Review: RMI l RMI – Remote Method Invocation »RPC in Java Technology and more »Concrete programming technology »Designed to solve the problems of writing and organizing executable code »Native to Java, an extension of core language »Benefits from specific features of Java –Object serialization –Portable, downloadable object implementations –Java interface definitions

3 © City University London, Dept. of Computing Distributed Systems / RMI: Benefits l Invoke object methods, and have them execute on remote Java Virtual Machines (JVMs) l Entire objects can be passed and returned as parameters »Unlike many other remote procedure call based mechanisms requiring either primitive data types as parameters, or structures composed of primitive data types l New Java objects can be passed as a parameter »Can move behavior (class implementations) from client to server and server to client

4 © City University London, Dept. of Computing Distributed Systems / RMI: Benefits l Enables use of Design Patterns »Use the full power of object oriented technology in distributed computing, such as two- and three-tier systems (pass behavior and use OO design patterns) l Safe and Secure »RMI uses built-in Java security mechanisms l Easy to Write/Easy to Use »A remote interface is an actual Java interface l Distributed Garbage Collection »Collects remote server objects that are no longer referenced by any client in the network

5 © City University London, Dept. of Computing Distributed Systems / RMI: Implementation

6 © City University London, Dept. of Computing Distributed Systems / Developing RMI l Define a remote interface »define a remote interface that specifies the signatures of the methods to be provided by the server and invoked by clients »It must be declared public, in order for clients to be able to load remote objects which implement the remote interface. »It must extend the Remote interface, to fulfill the requirement for making the object a remote one. »Each method in the interface must throw a java.rmi.RemoteException.

7 © City University London, Dept. of Computing Distributed Systems / Developing RMI l Implement the remote interface l Develop the server Create an instance of the RMISecurityManager and install it Create an instance of the remote object Register the object created with the RMI registry l Develop the client –First obtain a reference to the remote object from the RMI registry

8 © City University London, Dept. of Computing Distributed Systems / Developing RMI l Running the application »Generate stubs and skeletons - rmic »Compile the server and the client - javac »Start the RMI registry - rmiregistry »Start the server and the client

9 © City University London, Dept. of Computing Distributed Systems / Outline l 1.0 The Object Management Group and Introduction l 2.0 Object Management Architecture l 3.0 CORBA Communication l 4.0 Implementation, “Hello World” Example l 5.0 RMI vs CORBA Comparison

10 © City University London, Dept. of Computing Distributed Systems / Remember: Conceptual Framework l Architecture. l Accessing components from programming languages. l Interfaces to lower layers. l Component identification. l Service invocation styles. l Handling of failures.

11 © City University London, Dept. of Computing Distributed Systems / CORBA l Object management architecture. l Accessing remote objects. l ORB interface. l Object identification l Activation strategies. l Request vs. notification. l Handling of failures.

12 © City University London, Dept. of Computing Distributed Systems / The Object Management Group l The OMG is a non-profit consortium created in 1989 with the purpose of promoting theory and practice of object technology in distributed computing systems to reduce the complexity, lower the costs, and hasten the introduction of new software applications. l Originally formed by 13 companies, OMG membership grew to over 500 software vendors, developers and users. l OMG realizes its goals through creating standards which allow interoperability and portability of distributed object oriented applications. They do not produce software or implementation guidelines.

13 © City University London, Dept. of Computing Distributed Systems / CORBA ( C ommon Object R equest B roker A rchitecture ) l Specification by OMG of an OO infrastructure for Distributed Computing. l Defines Object Request Broker and IDL l Enables Software interoperability across languages and platforms l Applicable to legacy, commercial-off-the-shelf(COTS) integration and new software development l CORBA is just a specification for creating and using distributed Objects, it is an integration technology NOT a programming language

14 © City University London, Dept. of Computing Distributed Systems / CORBA: A Specification l Takes care of cross-language issues automatically l Uses OMG IDL (Interface Definition Language l Runs over IIOP (Internet Inter-Orb Protocol) Java Client Cobol Client Java Object C++ Object CORBA/IIOP

15 © City University London, Dept. of Computing Distributed Systems / CORBA Concepts l CORBA’s theoretical underpinnings are based on three important concepts; »An Object-Oriented Model »Open Distributed Computing Environment »Component Integration and Reuse l CORBA Provides »Uniform access to services »Uniform discovery of resources and object names »Uniform error handling methods »Uniform security policies

16 © City University London, Dept. of Computing Distributed Systems / The OMG Object Model l The OMG Object Model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. l In this model clients request services from objects (which will also be called servers) through a well-defined interface. l This interface is specified in OMG IDL (Interface Definition Language). A client accesses an object by issuing a request to the object. The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters (if any).

17 © City University London, Dept. of Computing Distributed Systems /

18 © City University London, Dept. of Computing Distributed Systems /

19 © City University London, Dept. of Computing Distributed Systems / About CORBA Objects l CORBA objects differ from typical objects in 3 ways »CORBA objects can run on any platform. »CORBA objects can be located anywhere »CORBA Objects can be written in any language that has an IDL mapping l A CORBA object is a virtual programming entity that consists of an identity, an interface, and an implementation which is known as a Servant. »It is virtual in the sense that it does not really exist unless it is made concrete by an implementation written in a programming language

20 © City University London, Dept. of Computing Distributed Systems / Objects and Applications l CORBA applications are composed of objects. l Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. l For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance.

21 © City University London, Dept. of Computing Distributed Systems / Object Management Architecture (OMA) Application Objects CORBA facilities CORBA services Object Request Broker

22 © City University London, Dept. of Computing Distributed Systems / OMA Model l CORBA is based on the object model, derived from the abstract core object model of OMG’s OMA (Object Management Architecture) l OMA groups objects into four categories »CORBAservices »CORBAfacilities »CORBAdomain »Application object OMAOMA CORBACORBA

23 © City University London, Dept. of Computing Distributed Systems / CORBAservices l CORBAservices »Provide basic functionality, that almost every object needs –Naming Service-name binding,associating names and references –Event Service- asynchronous event notification –Concurrency Control Service-mediates simultaneous access l CORBAfacilities (sometimes called Horizontal CORBAfacilities) »Between CORBAservices and Application Objects »Potentially useful across business domains –Printing, Secure Time Facility, Internationalization Facility, Mobile Agent Facility.

24 © City University London, Dept. of Computing Distributed Systems / OMA model l Domain (Vertical) CORBAfacilities »Domain-based and provide functionality for specific domains such as telecommunications, electronic commerce, or health care. l Application Objects »Topmost part of the OMA hierarchy »Customized for an Individual application, so do not need standardization

25 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture DynamicInvocationClientStubsORBInterfaceServerSkeletonObjectAdapter ORB Core Client Object Implementation

26 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture Client Dynamic Invocation ORB Interface Dynamic Skeleton Static Skeleton Stub Object Adapter Object Implementation (Servant) Object Request Broker (ORB) Interface identical for all ORB implementations There maybe multiple object adapters There are stubs and skeletons for each object type Up-call interface Normal call interface ORB-dependent interface

27 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture l A general CORBA request structure IIOP Request from a client to an object implementation Request A request consists of Target object (identified by unique object reference ) Operation. Parameters (the input, output, and in-out parameters defined for the operation; maybe specified individually or as a list Optional request context Results (the results values returned by operation )

28 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture l CORBA is composed of five major components; »ORB, »IDL, »Dynamic Invocation Interface (DII), »Interface Repositories (IR), »Object Adapters (OA), »Inter-Orb Protocol (IIOP) l CORBA provides both static and dynamic interfaces to its services l Happened because two strong proposals from HyperDesk and Digital based on a Dynamic API & from SUN and HP based on a static API. “Common” stands for a two-API proposal

29 © City University London, Dept. of Computing Distributed Systems / Object Request Broker, ORB l Core of CORBA, middleware that establishes the client/server relationship between objects l This is the object manager in CORBA, the software that implements the CORBA specification, (implements the session, transport and network layers), provides object location transparency, communication and activation, i.e »Find object implementation for requests (provide location transparency) »Prepare the object implementation to receive request »Communicate the data making up request. (Vendors & Products: ORBIX from IONA, VisiBroker from Inprise, JavaIDL from javasoft )

30 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: ORB l On the client side the ORB is responsible for »accepting requests for a remote object »finding the implementation of the object »accepting a client-side reference to the remote object (converted to a language specific form, e.g. a java stub object) »Routing client method calls through the object reference to the object implementation l On the Server side »lets object servers register new objects »receives requests from the client ORB »uses object’s skeleton interface to invoke the object activation method »Creates reference for new object and sends it back to client.

31 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: Stubs,Skeletons l Client Stub »provides the static interfaces to object services. These precompiled stubs define how clients invoke corresponding services on the server. From a client’s perspective, the stub acts like a local call- it’s a local proxy for a remote server object. Generated by the IDL compiler (there are as many stubs as there are interfaces!) l Server Skeleton »provides static interfaces to each service exported by the server. Performance unmarshalling, and the actual method invocation on the server object l ORB Interface »Interface to few ORB operations common to all objects, e.g. operation which returns an object’s interface type.

32 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: Servant &Clients l Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. l Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada. l 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. The remaining components help to support this level of transparency.

33 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: DII l Dynamic Invocation Interface (DII) »Static invocation interfaces are determined at compile time, and they are presented to the client using stubs »The DII allows client applications to use server objects without knowing the type of objects at compile time –Client obtains an instance of a CORBA object and makes invocations on that object by dynamically creating requests. »DII uses the interface repository to validate and retrieve the signature of the operation on which a request is made

34 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: DSI l Dynamic Skeleton Interface (DSI) »Server-side dynamic skeleton interface »Allows servers to be written without having skeletons, or compile time knowledge for which objects will be called remotely »Provides a runtime binding mechanism for servers that need to handle incoming method calls for components that do not have IDL-based compiled skeletons »Useful for implementing generic bridges between ORBs »Also used for interactive software tools based on interpreters and distributed debuggers

35 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: IR l Interface Repository »allows YOU to obtain and modify the descriptions of all registered component interfaces(method supported, parameters i.e method signatures) »It is a run-time distributed database that contains machine readable versions of the IDL interfaces »Interfaces can be added to the interface repository »Enable Clients to; –locate an object that is unknown at compile time –find information about its interface –build a request to be forwarded through the ORB

36 © City University London, Dept. of Computing Distributed Systems / CORBA Architecture: OA l Object Adapter (OA) e.g (Basic-BOA or Portable-POA) »Purpose:interface an object’s implementation with its ORB »Primary way that an object implementation accesses services provided by the ORB. »Sits on top of the ORB’s core communication services and accepts requests for service on behalf of server objects, passing requests to them and assigning them IDs (object references) »Registers classes it supports and their run-time instances with the implementation repository »In summary, its duties are: –Object reference generation, and interpretation, method invocation, security of interactions, and implementation of object activation and de-activation

37 © City University London, Dept. of Computing Distributed Systems / Implementation Repository l Provides a run-time repository of information about classes a server supports, the objects that are instantiated and their IDs l Also serves as a common place to store additional information associated with implementations of ORBS »e.g. trace information, audit trails and other administrative data

38 © City University London, Dept. of Computing Distributed Systems / Summary of CORBA Interfaces l Interface and Implementation Repositories Accesses includes Decsribes All objects are defined in IDL by specifying their interfaces Object definitions (interfaces) are manifested as objects in the interface repository, compiled to stubs and skeletons Descriptions of object implementations are maintained as objects in the implementation repository

39 © City University London, Dept. of Computing Distributed Systems / DynamicInvocationClientStubsORBInterfaceServerSkeletonObjectAdapter ORB Core 2.16 Accessing Remote Objects Client Object Implementation

40 © City University London, Dept. of Computing Distributed Systems / Client Side DynamicInvocationClientStubsORBInterface Client Clients perform requests using object references Clients May issue requests through object interface stubs (static) or dynamic invocation interface (Dynamic) Clients may access general ORB services: Interface Repository Context management List Management Request Management

41 © City University London, Dept. of Computing Distributed Systems / Implementation Side (Server side) l Implementations receive requests through skeletons (without knowledge of invocation approach) ORBInterfaceServerSkeletonObjectAdapter Object Implementation The object Adapter provides for: Management of references; Method invocation; authentication implementation registration activation/deactivation

42 © City University London, Dept. of Computing Distributed Systems / CORBA Communication l CORBA Spec Neutral w.r.t network protocols »CORBA specifies GIOP, a high level standard protocol for communication between ORBs l Generalized Inter-ORB Protocol (GIOP) is a collection of message requests an ORB can make over a network l GIOP maps ORB requests to different transports »Internet Inter-ORB Protocol (IIOP) uses TCP/IP to carry the messages, hence fits well into Internet world »Environment Specific Inter-ORB Protocol (ESIOP) complements GIOP enabling interoperability with environments not having CORBA support

43 © City University London, Dept. of Computing Distributed Systems / CORBA Communication l GIOP contains specifications for »Common Data Representation (CDR) »Message formats (Reply, Request, LocateReply, LocateRequest, CancelRequest, etc) »Message transport assumptions –Connection-Oriented –Reliable –A Byte Stream Protocol

44 © City University London, Dept. of Computing Distributed Systems / Communication: Inter-Orb Architecture CORBA IDL General Inter-ORB Protocol (GIOP) Internet Inter-ORB Protocol (IIOP) TCP/IP Internet Others for example OSI and IPX/SPX Object Request Semantics Transfer and Message Syntax Transports

45 © City University London, Dept. of Computing Distributed Systems /

46 © City University London, Dept. of Computing Distributed Systems / Other Features l CORBA Messaging »CORBA 2.0 provides three different techniques for operation invocations: –Synchronous The client invokes an operation, then pauses, waiting for a response –Deferred synchronous The client invokes an operation then continues processing. It can go back later to either poll or block waiting for a response –One-way The client invokes an operation, and the ORB provides a guarantee that the request will be delivered. In one-way operation invocations, there is no response

47 © City University London, Dept. of Computing Distributed Systems / New Features »Two newer, enhanced mechanisms are introduced –Callback The client supplies an additional object reference with each request invocation. When the response arrives, the ORB uses that object reference to deliver the response back to the client –Polling The client invokes an operation that immediately returns a valuetype that can be used to either poll or wait for the response »The callback and polling techniques are available for clients using statically typed stubs generated from IDL interfaces (not for DII)

48 © City University London, Dept. of Computing Distributed Systems / Implementation Implementation

49 © City University London, Dept. of Computing Distributed Systems / How to Write CORBA Applications Create IDL definition Server Skeleton Example Servant Client IDL Stub Implement Client javac Implementation repository Start server Interface repository ServerClient idl Implement Servant javac Start client Object Adapter load is used by instantiates

50 © City University London, Dept. of Computing Distributed Systems / Example: Hello world ID module HelloApp { interface Hello { string sayHello(); };

51 © City University London, Dept. of Computing Distributed Systems / Example: Hello World Server import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; class HelloServant extends _HelloImplBase { public String sayHello() { return "\nHello world !!\n"; } public class HelloServer { public static void main(String args[]) { try{ // create and initialize the ORB ORB orb = ORB.init(args, null); // create servant and register it with the ORB HelloServant helloRef = new HelloServant(); orb.connect(helloRef); // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // bind the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; ncRef.rebind(path, helloRef); // wait for invocations from clients java.lang.Object sync = new java.lang.Object(); synchronized (sync) { sync.wait(); } } catch (Exception e) {…} } Server Skeleton Servant ORB interface Binding

52 © City University London, Dept. of Computing Distributed Systems / Example: Hello World Client import HelloApp.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; public class HelloClient { public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); // create and initialize the ORB // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // resolve the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello helloRef = HelloHelper.narrow(ncRef.resolve(path)); // call the Hello server object and print results String hello = helloRef.sayHello(); System.out.println(hello); } catch (Exception e) {…} }} Casting Service Request

53 © City University London, Dept. of Computing Distributed Systems / Static vs. Dynamic Invocation l Static invocation: IDL operations must have been defined before client can be developed. l Does not suit every application (Example?) l Dynamic invocation interface enables clients to define operation invocations at run-time. l Interface repository can be used to ensure that calls are type safe.

54 © City University London, Dept. of Computing Distributed Systems / ORB Interface Object type Object. l Initialisation of object request broker. l Initialisation of client / server applications. l Programming interface to interface repository.

55 © City University London, Dept. of Computing Distributed Systems / Object Identification l Objects are uniquely identified by object identifiers. l Object identifiers are persistent. l Identifiers can be externalised (converted into string) and internalised. l Identifiers can be obtained »from a naming or a trading service, »by reading attributes, »from an operation result or »by internalising an externalised reference.

56 © City University London, Dept. of Computing Distributed Systems /

57 © City University London, Dept. of Computing Distributed Systems /

58 © City University London, Dept. of Computing Distributed Systems / C 4.7 Activation Strategies Basic Object Adapter Process Object A B D AShared Server BUnshared Server CServer per method DPersistent server Registration Activation

59 © City University London, Dept. of Computing Distributed Systems / Request vs. Notification l IDL operations are handled synchronously. l For notifications, it may not be necessary to await the server, if operation does not »have a return value, »have out or inout parameters and »raise specific exceptions. Notification can be implemented as oneway operations in IDL. l Client continues after notification is delivered.

60 © City University London, Dept. of Computing Distributed Systems / Notification (Example) /* person.idl */ enum sex_type { FEMALE, MALE }; struct Person { string first_name; string last_name; sex_type sex; string city; }; interface PersonManager { oneway void print(in Person); long store(in Person pers); Person load(in long pers_id); };

61 © City University London, Dept. of Computing Distributed Systems / Failures l CORBA operation invocations may fail for the same reasons as RMIs. l Exceptions give detailed account why an operation has failed. l System vs. application specific exceptions.

62 © City University London, Dept. of Computing Distributed Systems / CORBA AND JAVA l 1997: RMI Introduced with JDK1.1 l 1998: JavaIDL with JDK1.2 – Java ORB supporting IIOP. ORB also supports RMI over IIOP  remote objects written in the Java programming language accessible from any language via IIOP l CORBA provides the network transparency, Java provides the implementation transparency

63 © City University London, Dept. of Computing Distributed Systems / Comparison l RMI architecture lacks interface repository (but has reflection). l IDL and RMI allow for: »inheritance, »attributes and »exceptions. (These three are missing in RPC) l IDL has multiple standardised language bindings. RMI is part of JAVA, RPC goes with C and C++

64 © City University London, Dept. of Computing Distributed Systems / Comparison (cont´d) l RMIs are lightweight. l Component identification is reflexive in IDL and RMI, as opposed to RPC. l Basic object adapter provides more flexible activation strategies. l Oneway operations can be used for asynchronous notifications.

65 © City University London, Dept. of Computing Distributed Systems / Comparison (cont´d) l RMIs may be more efficient than CORBA operation invocations. l RMI comes with JAVA, whilst you would have to obtain a CORBA product (open-source ones exist).

66 © City University London, Dept. of Computing Distributed Systems / RMI vs CORBA l RMI is a Java-centric distributed object system. The only way currently to integrate code written in other languages into a RMI system is to use the Java native-code interface to link a remote object implementation in Java to C or C++ code. This is a possibility, but complicated. CORBA, on the other hand, is designed to be language- independent. Object interfaces are specified in a language that is independent of the actual implementation language. This interface description can then be compiled into whatever implementation language suits the job and the environment.

67 © City University London, Dept. of Computing Distributed Systems / RMI vs CORBA (ctd.) l Relatively speaking, RMI can be easier to master, especially for experienced Java programmers, than CORBA. CORBA is a rich, extensive family of standards and interfaces, and delving into the details of these interfaces is sometimes overkill for the task at hand.

68 © City University London, Dept. of Computing Distributed Systems / RMI vs CORBA (ctd.) CORBA is a more mature standard than RMI, and has had time to gain richer implementations. The CORBA standard is a fairly comprehensive one in terms of distributed objects, and there are CORBA implementations out there that provide many more services and distribution options than RMI or Java. The CORBA Services specifications, for example, include comprehensive high-level interfaces for naming, security, and transaction services.

69 © City University London, Dept. of Computing Distributed Systems / The Bottom Line l So which is better, CORBA or RMI? Basically, it depends. If you're looking at a system that you're building from scratch, with no hooks to legacy systems and fairly mainstream requirements in terms of performance and other language features, then RMI may be the most effective and efficient tool for you to use. l On the other hand, if you're linking your distributed system to legacy services implemented in other languages, or if there is the possibility that subsystems of your application will need to migrate to other languages in the future, or if your system depends strongly on services that are available in CORBA and not in RMI, or if critical subsystems have highly-specialized requirements that Java can't meet, then CORBA may be your best bet.


Download ppt "© City University London, Dept. of Computing Distributed Systems / 5 - 1 Distributed Systems Session 5: Common Object Request Broker, (CORBA) Christos."

Similar presentations


Ads by Google