Distributed Objects and Remote Invocation Source: George Colouris, Jean Dollimore, Tim Kinderberg & Gordon Blair (2012). Distributed Systems: Concepts & Design (5 th Ed.). Essex: Addison-Wesley Chapter 8 & Chapter 5 Power point presentation was adapted from: (i) (ii) (iii) liver.ppt

Introduction Distributed Objects Remote Invocation Case Study: CORBA Introduction Distributed Objects Remote Invocation Case Study: CORBA  Content

Introduction Distributed Objects Remote Invocation Case Study: CORBA Introduction Distributed Objects Remote Invocation Case Study: CORBA  Content

Introduction This Chapter

allows programmers to adopt an object-oriented programming model that hide the underlying complexity of distributed programming communicating entities are represented by objects objects communicate using remote method invocation and other alternative communication paradigm allows programmers to adopt an object-oriented programming model that hide the underlying complexity of distributed programming communicating entities are represented by objects objects communicate using remote method invocation and other alternative communication paradigm Introduction  Distributed object middleware

Advantages: Encapsulate programming complexity. Allows programmers to focus on interface rather than the implementation such as the programming language and operating system used. Encourage development of dynamic and extensible solutions, for example by enabling the introduction of new objects or the replacement of one object with another (compatible) object. Middleware solutions based on distributed objects including Java RMI and CORBA Advantages: Encapsulate programming complexity. Allows programmers to focus on interface rather than the implementation such as the programming language and operating system used. Encourage development of dynamic and extensible solutions, for example by enabling the introduction of new objects or the replacement of one object with another (compatible) object. Middleware solutions based on distributed objects including Java RMI and CORBA Introduction  Distributed Object Middleware

To overcome limitations in distributed object middleware Limitations of distributed object middleware: Implicit dependencies: Object interfaces do not describe what the implementation of an object depends on, making object-based systems difficult to develop (especially for third-party developers) and subsequently manage. To overcome limitations in distributed object middleware Limitations of distributed object middleware: Implicit dependencies: Object interfaces do not describe what the implementation of an object depends on, making object-based systems difficult to develop (especially for third-party developers) and subsequently manage. Introduction  Component-based middleware

Limitations of distributed object middleware: Programming complexity: Programming distributed object middleware leads to a need to master many low-level details associated with middleware implementations. Lack of separation of distribution concerns: Application developers are obliged to consider details of concerns such as security, failure handling and concurrency, which are largely similar from one application to another. Limitations of distributed object middleware: Programming complexity: Programming distributed object middleware leads to a need to master many low-level details associated with middleware implementations. Lack of separation of distribution concerns: Application developers are obliged to consider details of concerns such as security, failure handling and concurrency, which are largely similar from one application to another. Introduction  Component-based middleware

Limitation of distributed object middleware: No support for deployment: Object-based middleware provides little or no support for the deployment of (potentially complex) configurations of objects. Examples: Enterprise JavaBeans and Fractal Limitation of distributed object middleware: No support for deployment: Object-based middleware provides little or no support for the deployment of (potentially complex) configurations of objects. Examples: Enterprise JavaBeans and Fractal Introduction  Component-based middleware

Introduction Distributed Objects Remote Invocation Case Study: CORBA Introduction Distributed Objects Remote Invocation Case Study: CORBA  Content

Distributed object middleware to provide a programming model based on object- oriented principles to bring the benefits of the object oriented approach to distributed programming. Benefit to distributed system developers: More programming abstractions (using familiar programming languages such as C++ and Java) use object-oriented design principles, tools and techniques (including UML) in the development of distributed systems software. Distributed object middleware to provide a programming model based on object- oriented principles to bring the benefits of the object oriented approach to distributed programming. Benefit to distributed system developers: More programming abstractions (using familiar programming languages such as C++ and Java) use object-oriented design principles, tools and techniques (including UML) in the development of distributed systems software. Distributed Objects

 Types of Distributed Objects

Inter-object communication - mechanisms for objects to communicate in the distributed environment Lifecycle management - the creation, migration and deletion of objects Activation and deactivation - the process of making an object active in the distributed environment by providing the necessary resources for it to process incoming invocations Inter-object communication - mechanisms for objects to communicate in the distributed environment Lifecycle management - the creation, migration and deletion of objects Activation and deactivation - the process of making an object active in the distributed environment by providing the necessary resources for it to process incoming invocations Distributed Objects  The Functionalities of Distributed Objects

Persistence – maintenance of state across possible cycles of activation and deactivation and system failures. Additional services - provide support for the range of distributed system services including naming, security and transaction services Persistence – maintenance of state across possible cycles of activation and deactivation and system failures. Additional services - provide support for the range of distributed system services including naming, security and transaction services Distributed Objects  The Functionalities of Distributed Objects

The logical partition of object-based programs into objects is naturally extended by the physical distribution of objects into different processes or computers in a distributed system. Distributed object systems adopt the client-server architecture: Objects are managed by servers and their clients invoke their methods using remote method invocation. The client’s RMI request is sent in a message to the server managing the invoked method object. The method of the object at the server is executed and its result is returned to the client in another message. Objects in servers are allowed to become clients of objects in other servers. The logical partition of object-based programs into objects is naturally extended by the physical distribution of objects into different processes or computers in a distributed system. Distributed object systems adopt the client-server architecture: Objects are managed by servers and their clients invoke their methods using remote method invocation. The client’s RMI request is sent in a message to the server managing the invoked method object. The method of the object at the server is executed and its result is returned to the client in another message. Objects in servers are allowed to become clients of objects in other servers. Distributed Objects  Distributed Object Model

Distributed objects can be replicated and migrated to obtain the benefits of fault tolerance, enhanced performance and availability. Having client and server objects in different processes enforces encapsulation due to concurrency and heterogeneity of RMI calls. Distributed objects can be replicated and migrated to obtain the benefits of fault tolerance, enhanced performance and availability. Having client and server objects in different processes enforces encapsulation due to concurrency and heterogeneity of RMI calls. Distributed Objects  Distributed Object Model

Distributed Objects  Distributed Object Model invocation remote invocation remote local invocation A B C D E F Remote and local method invocations

Each process contains a collection of objects, some of which can receive both local and remote invocations and others can receive only local invocations. Objects that can receive remote invocations are called remote objects. Other objects need to know the remote object reference in another process in order to invoke its methods. A remote object reference is an identifier that can be used through a distributed system to refer to a particular unique remote object. Each process contains a collection of objects, some of which can receive both local and remote invocations and others can receive only local invocations. Objects that can receive remote invocations are called remote objects. Other objects need to know the remote object reference in another process in order to invoke its methods. A remote object reference is an identifier that can be used through a distributed system to refer to a particular unique remote object. Distributed Objects  Distributed Object Model

Every remote object has a remote interface to specify which of its methods can be invoked remotely. Objects in other processes can invoke only the methods that belong to the remote interface of the remote object. Local objects can invoke the methods in the remote interface as well as other methods of the remote object. Every remote object has a remote interface to specify which of its methods can be invoked remotely. Objects in other processes can invoke only the methods that belong to the remote interface of the remote object. Local objects can invoke the methods in the remote interface as well as other methods of the remote object. Distributed Objects  Distributed Object Model

Distributed Objects  Distributed Object Model interface remote m1 m2 m3 m4 m5 m6 Data implementation remote object { of methods A remote object and its remote interface

Introduction Distributed Objects Remote Invocation Case Study: CORBA Introduction Distributed Objects Remote Invocation Case Study: CORBA  Content

how processes (or entities at a higher level of abstraction such as objects or services) communicate in a distributed system Remote Invocation  Introduction

support the roles and message exchanges in typical client-server interactions A synchronous communication - the client process blocks until the reply arrives from the server A reliable communication protocol - the reply from the server is an acknowledgement to the client that message has been received support the roles and message exchanges in typical client-server interactions A synchronous communication - the client process blocks until the reply arrives from the server A reliable communication protocol - the reply from the server is an acknowledgement to the client that message has been received Remote Invocation  Request-reply protocols

Based on 3 communication primitives - doOperation, getRequest and sendReply Remote Invocation  Request-reply protocols

doOperation method Is used by clients to invoke remote operations Its arguments specify the remote server, the operation to invoke Its result is a byte array containing the reply getRequest is used by a server process to acquire service requests sendReply Is used by the server to send the reply message to the client doOperation method Is used by clients to invoke remote operations Its arguments specify the remote server, the operation to invoke Its result is a byte array containing the reply getRequest is used by a server process to acquire service requests sendReply Is used by the server to send the reply message to the client Remote Invocation  Request-reply protocols

requestId Message identifier A unique identifier to the sender, and the distributed system requestId Message identifier A unique identifier to the sender, and the distributed system Remote Invocation  Request-reply protocols

Handling issues in the Request-reply protocols Timeout - return the doOperation to the client indicating that it has failed or send multiple doOperation until response is received Duplicate request messages – filter and discard the same doOperation with same requestId. Lost reply messages – send the copy of results, re- execute the request Handling issues in the Request-reply protocols Timeout - return the doOperation to the client indicating that it has failed or send multiple doOperation until response is received Duplicate request messages – filter and discard the same doOperation with same requestId. Lost reply messages – send the copy of results, re- execute the request Remote Invocation  Request-reply protocols

3 types of request behaviors using UDP: the request (R) protocol the request-reply (RR) protocol the request-reply-acknowledge reply (RRA) protocol. 3 types of request behaviors using UDP: the request (R) protocol the request-reply (RR) protocol the request-reply-acknowledge reply (RRA) protocol. Remote Invocation  Request-reply protocols

Request-reply protocols using TCP allows arguments and results of any size to be transmitted arguments and results are sent in streams between the client and server It is a reliable protocol, hence, retransmission of messages and filtering of duplicates are not necessary Request-reply protocols using TCP allows arguments and results of any size to be transmitted arguments and results are sent in streams between the client and server It is a reliable protocol, hence, retransmission of messages and filtering of duplicates are not necessary Remote Invocation  Request-reply protocols

Request-reply protocols using HTTP Implemented over TCP uses persistent connections connections that remain open over a series of request- reply exchanges between client and server. A persistent connection can be closed by the client or server at any time by sending an indication to the other participant Request-reply protocols using HTTP Implemented over TCP uses persistent connections connections that remain open over a series of request- reply exchanges between client and server. A persistent connection can be closed by the client or server at any time by sending an indication to the other participant Remote Invocation  Request-reply protocols

HTTP methods: resource- Remote Invocation  Request-reply protocols

Source and further reading : Remote Invocation  Request-reply protocols

Examples of other http status codes: Remote Invocation CodeDescription 200OK 201Created 400Bad request 401Unauthorized 403Forbidden …… …….  Request-reply protocols

Design issues for RPC Programming with interfaces RPC call semantics Transparency Design issues for RPC Programming with interfaces RPC call semantics Transparency Remote Invocation  Remote Procedure Call

Programming with interfaces Control the interactions between modules in a programming languages interface of a module specifies the procedures and the variables that can be accessed from other modules modules can run in separate processes in distributed systems service interface - the specification of the procedures offered by a server, defining the types of the arguments of each of the procedures Programming with interfaces Control the interactions between modules in a programming languages interface of a module specifies the procedures and the variables that can be accessed from other modules modules can run in separate processes in distributed systems service interface - the specification of the procedures offered by a server, defining the types of the arguments of each of the procedures Remote Invocation  Remote Procedure Call

Programming with interfaces An RPC mechanism can be integrated with a particular programming language if it includes an adequate notation for defining interfaces that is allowing input and output parameters to be mapped onto the language’s normal use of parameters many existing useful services are written in C++ and other languages Interface definition languages (IDLs) are designed to allow procedures implemented in different languages to invoke one another Programming with interfaces An RPC mechanism can be integrated with a particular programming language if it includes an adequate notation for defining interfaces that is allowing input and output parameters to be mapped onto the language’s normal use of parameters many existing useful services are written in C++ and other languages Interface definition languages (IDLs) are designed to allow procedures implemented in different languages to invoke one another Remote Invocation  Remote Procedure Call

Programming with interfaces Remote Invocation  Remote Procedure Call

RPC call semantics Possible implementation of sending request to remote host RPC call semantics Possible implementation of sending request to remote host Remote Invocation  Remote Procedure Call

Transparency RPC was designed to make remote procedure calls as much like local procedure calls as possible, with no distinction in syntax between a local and a remote procedure call RPCs are more vulnerable to failure than local ones – as in involve with network. Network or server failure? Transparency RPC was designed to make remote procedure calls as much like local procedure calls as possible, with no distinction in syntax between a local and a remote procedure call RPCs are more vulnerable to failure than local ones – as in involve with network. Network or server failure? Remote Invocation  Remote Procedure Call

Implementation of RPC RPC is generally implemented over a request-reply protocol The client that accesses a service includes one stub procedure for each procedure in the service interface stub procedure –a procedure behaves like a local procedure to the client, but instead of executing the call, it marshals the procedure identifier and the arguments into a request message, which it sends via its communication module to the server Implementation of RPC RPC is generally implemented over a request-reply protocol The client that accesses a service includes one stub procedure for each procedure in the service interface stub procedure –a procedure behaves like a local procedure to the client, but instead of executing the call, it marshals the procedure identifier and the arguments into a request message, which it sends via its communication module to the server Remote Invocation  Remote Procedure Call

Remote Invocation  Remote Procedure Call

Remote method invocation (RMI) is an improved version of RPC a calling object can invoke a method in a potentially remote object The similarities in RPC and RMI both support programming with interfaces both typically constructed on top of request-reply protocols and can offer a range of call semantics such as at-least-once and at-most-once both offer a similar level of transparency – that is, local and remote calls employ the same syntax Remote method invocation (RMI) is an improved version of RPC a calling object can invoke a method in a potentially remote object The similarities in RPC and RMI both support programming with interfaces both typically constructed on top of request-reply protocols and can offer a range of call semantics such as at-least-once and at-most-once both offer a similar level of transparency – that is, local and remote calls employ the same syntax Remote Invocation  Remote Method Invocation

The differences between RMI and RPC RMI allows the programmer to pass parameters not only by value, as input or output parameters, but also by object reference The differences between RMI and RPC RMI allows the programmer to pass parameters not only by value, as input or output parameters, but also by object reference Remote Invocation  Remote Method Invocation

Design issues for RMI Programming with interfaces, call semantics and level of transparency (please refer to RPC) Object model Distributed objects Distributed object models Design issues for RMI Programming with interfaces, call semantics and level of transparency (please refer to RPC) Object model Distributed objects Distributed object models Remote Invocation  Remote Method Invocation

The object model Object references - can be accessed via object references Interfaces - provides a definition of the signatures of a set of methods (the types of their arguments, return values and exceptions) without specifying their implementation Actions - is initiated by an object invoking a method in another object Exceptions - provide a clean way to deal with error conditions without complicating the code Garbage Collection – detect an object automatically when it is no longer accessible. It recovers the space and makes it available for allocation to other objects The object model Object references - can be accessed via object references Interfaces - provides a definition of the signatures of a set of methods (the types of their arguments, return values and exceptions) without specifying their implementation Actions - is initiated by an object invoking a method in another object Exceptions - provide a clean way to deal with error conditions without complicating the code Garbage Collection – detect an object automatically when it is no longer accessible. It recovers the space and makes it available for allocation to other objects Remote Invocation  Remote Method Invocation

Distributed Objects Distributed object systems may adopt the client- server architecture Objects are managed by servers and their clients invoke their methods using remote method invocation Distributed Objects Distributed object systems may adopt the client- server architecture Objects are managed by servers and their clients invoke their methods using remote method invocation Remote Invocation  Remote Method Invocation

The distributed object model Each process contains a collection of objects, some of which can receive both local and remote invocations, whereas the other objects can receive only local invocations The distributed object model Each process contains a collection of objects, some of which can receive both local and remote invocations, whereas the other objects can receive only local invocations Remote Invocation  Remote Method Invocation

The distributed object model Two components of distributed object model Remote object references - an identifier that can be used throughout a distributed system to refer to a particular unique remote object Remote interfaces - The class of a remote object implements the methods of its remote interface. Objects in other processes can invoke only the methods that belong to its remote interface The distributed object model Two components of distributed object model Remote object references - an identifier that can be used throughout a distributed system to refer to a particular unique remote object Remote interfaces - The class of a remote object implements the methods of its remote interface. Objects in other processes can invoke only the methods that belong to its remote interface Remote Invocation  Remote Method Invocation

Remote Invocation  Remote Method Invocation

RMI Implementation Several separate objects and modules are involved to achieve a remote method invocation RMI Implementation Several separate objects and modules are involved to achieve a remote method invocation Remote Invocation  Remote Method Invocation

RMI Implementation Communication modules: Responsible for providing a specified invocation semantics. Carry out the request-reply protocol to transmit request and reply messages between the cooperating server and client. Use only the first three items of the request and reply messages: message type, request id, and the invoked remote object reference. Select the dispatcher software for the invoked object class in the server. RMI Implementation Communication modules: Responsible for providing a specified invocation semantics. Carry out the request-reply protocol to transmit request and reply messages between the cooperating server and client. Use only the first three items of the request and reply messages: message type, request id, and the invoked remote object reference. Select the dispatcher software for the invoked object class in the server. Remote Invocation  Remote Method Invocation

RMI Implementation Remote reference modules: Translate between local and remote object references and create remote object references. Have a remote object table in each process to support the translation. An entry for all the remote objects held by the server in its table. An entry for each local proxy held by the client in its table. Create a remote object reference and add it to the table when a remote object is passed in a request or a replay message for the first time. Translate the remote object reference to the corresponding local object reference which refer either to a remote object (in the server) or to a proxy (in the client). RMI Implementation Remote reference modules: Translate between local and remote object references and create remote object references. Have a remote object table in each process to support the translation. An entry for all the remote objects held by the server in its table. An entry for each local proxy held by the client in its table. Create a remote object reference and add it to the table when a remote object is passed in a request or a replay message for the first time. Translate the remote object reference to the corresponding local object reference which refer either to a remote object (in the server) or to a proxy (in the client). Remote Invocation  Remote Method Invocation

RMI Implementation RMI Software: Proxy: Make remote method invocation transparent to clients by behaving like a local object to the invoker. Forward the call in a message to the remote object and hiding all in-between operations (send, receive, marshalling, and unmarshalling) from the client. A client has one proxy for each remote object to hold its remote reference and implement the methods in its remote interface. Marshal a reference to the target object, its own methodId and its arguments into a request message and send it to the target then await the reply message to unmarshal it and return the result to the invoker. RMI Implementation RMI Software: Proxy: Make remote method invocation transparent to clients by behaving like a local object to the invoker. Forward the call in a message to the remote object and hiding all in-between operations (send, receive, marshalling, and unmarshalling) from the client. A client has one proxy for each remote object to hold its remote reference and implement the methods in its remote interface. Marshal a reference to the target object, its own methodId and its arguments into a request message and send it to the target then await the reply message to unmarshal it and return the result to the invoker. Remote Invocation  Remote Method Invocation

RMI Implementation RMI Software: Dispatcher: A server has one dispatcher for each class representing a remote object. Receive the request message from the communication module and use the methodId to select the appropriate method in the skeleton and passing on the request message. Skeleton: Each class representing a remote object has a skeleton in the server to implement each method in the remote interface. Unmarshal the argument in the request message and invoke the corresponding method in the remote object. Await the invocation to complete to marshal the result in the reply message to the client proxy’s method. RMI Implementation RMI Software: Dispatcher: A server has one dispatcher for each class representing a remote object. Receive the request message from the communication module and use the methodId to select the appropriate method in the skeleton and passing on the request message. Skeleton: Each class representing a remote object has a skeleton in the server to implement each method in the remote interface. Unmarshal the argument in the request message and invoke the corresponding method in the remote object. Await the invocation to complete to marshal the result in the reply message to the client proxy’s method. Remote Invocation  Remote Method Invocation

RMI Implementation RMI Software: The classes of the proxy, skeleton, and dispatcher used in RMI are generated automatically by an interface complier. The server program contains the classes for the dispatchers and skeletons together with the implementations of the classes of all remote objects that it supports – servant classes. The client program contains the classes of the proxies for all the remote objects that it will invoke and use a binder to look up remote object references. RMI Implementation RMI Software: The classes of the proxy, skeleton, and dispatcher used in RMI are generated automatically by an interface complier. The server program contains the classes for the dispatchers and skeletons together with the implementations of the classes of all remote objects that it supports – servant classes. The client program contains the classes of the proxies for all the remote objects that it will invoke and use a binder to look up remote object references. Remote Invocation  Remote Method Invocation

Introduction Distributed Objects Remote Invocation Case Study: CORBA Introduction Distributed Objects Remote Invocation Case Study: CORBA  Content

In 1991, the CORBA (Common Object Request Broker Architecture) specification was developed by the Object Management Group (OMG). CORBA was developed based on the object request broker (ORB), that intended to help a client to invoke a method on an object (following the RMI style) CORBA is a language-independent RMI In 1991, the CORBA (Common Object Request Broker Architecture) specification was developed by the Object Management Group (OMG). CORBA was developed based on the object request broker (ORB), that intended to help a client to invoke a method on an object (following the RMI style) CORBA is a language-independent RMI Case Study: CORBA  CORBA

4 components of CORBA An interface definition language (IDL) An architecture The General Inter-ORB Protocol (GIOP) The Internet Inter-ORB Protocol (IIOP) 4 components of CORBA An interface definition language (IDL) An architecture The General Inter-ORB Protocol (GIOP) The Internet Inter-ORB Protocol (IIOP) Case Study: CORBA  The Components of CORBA

An interface definition language (IDL) Provides an interface consisting of a name and a set of methods that a client can request. IDL supports fifteen primitive types, constructed types and a special type called Object. Primitive types: short, long, unsigned short, unsigned long, float, double, char, boolean, octet, and any. Constructed types such as arrays and sequences must be defined using typedefs and passed by value. Interfaces and other IDL type definitions can be grouped into logical units called modules. An interface definition language (IDL) Provides an interface consisting of a name and a set of methods that a client can request. IDL supports fifteen primitive types, constructed types and a special type called Object. Primitive types: short, long, unsigned short, unsigned long, float, double, char, boolean, octet, and any. Constructed types such as arrays and sequences must be defined using typedefs and passed by value. Interfaces and other IDL type definitions can be grouped into logical units called modules. Case Study: CORBA  The Components of CORBA

GIOP: General Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it. IIOP: Internet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet. GIOP: General Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it. IIOP: Internet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet. Case Study: CORBA  The Components of CORBA

ORB core Object Adapter (server) Skeletons (server) Client Proxies / Stubs ORB core Object Adapter (server) Skeletons (server) Client Proxies / Stubs Case Study: CORBA  The Components of CORBA

The architecture ORB core Carries out the request-reply protocol between client and server. Provide operations that enable process to be started and stopped. Provide operations to convert between remote object references and strings. The architecture ORB core Carries out the request-reply protocol between client and server. Provide operations that enable process to be started and stopped. Provide operations to convert between remote object references and strings. Case Study: CORBA  The Components of CORBA

The architecture Skeletons (server) An IDL compiler generates skeleton classes in the server’s language. Dispatch RMI’s to the appropriate servant class. Client Proxies / Stubs Generated by an IDL compiler in the client language. A proxy class is created for object oriented languages Stub procedures are created for procedural languages. Both are responsible for marshalling and unmarshalling arguments, results and exceptions The architecture Skeletons (server) An IDL compiler generates skeleton classes in the server’s language. Dispatch RMI’s to the appropriate servant class. Client Proxies / Stubs Generated by an IDL compiler in the client language. A proxy class is created for object oriented languages Stub procedures are created for procedural languages. Both are responsible for marshalling and unmarshalling arguments, results and exceptions Case Study: CORBA  The Components of CORBA

The architecture Implementation Repository Activates registered servers on demand and locates servers that are currently running. Interface Repository Provides information about registered IDL interfaces to the clients and servers that require it. Optional for static invocation; required for dynamic invocation. The architecture Implementation Repository Activates registered servers on demand and locates servers that are currently running. Interface Repository Provides information about registered IDL interfaces to the clients and servers that require it. Optional for static invocation; required for dynamic invocation. Case Study: CORBA  The Components of CORBA

GIOP General Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it. IIOP Internet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet. GIOP General Inter-ORB Protocol are the standards (included in CORBA 2.0), which enable implementations to communicate with each other regardless of who developed it. IIOP Internet Inter-ORB Protocol is an implementation of GIOP that uses the TCP/IP protocol for the Internet. Case Study: CORBA  The Components of CORBA

Server must include IDL interfaces in the form of servant classes. An interface compiler generates: the program(Java or C++) interfaces server skeletons for each IDL interface proxy classes (or client stubs) for each IDL interface A Java / C++ class for IDL defined struct helper classes for each IDL defined type Server must include IDL interfaces in the form of servant classes. An interface compiler generates: the program(Java or C++) interfaces server skeletons for each IDL interface proxy classes (or client stubs) for each IDL interface A Java / C++ class for IDL defined struct helper classes for each IDL defined type Case Study: CORBA  How to Use CORBA

Server Creates and initializes the ORB Creates an instance of servant class, which is registered with the ORB. Servant class extends the corresponding skeleton class and implementation methods of an IDL interface. Makes a CORBA object Client Creates and initializes the ORB Contacts Naming service to get reference to the server Invokes methods on the server Server Creates and initializes the ORB Creates an instance of servant class, which is registered with the ORB. Servant class extends the corresponding skeleton class and implementation methods of an IDL interface. Makes a CORBA object Client Creates and initializes the ORB Contacts Naming service to get reference to the server Invokes methods on the server Case Study: CORBA  How to Use CORBA

Used primarily as a remote method invocation of a distributed client – server system. Can communicate between clients and servers on different operating systems and implemented by different programming languages (Java cannot do this). Has many standards and services useful in implementing distributed applications. Process can be both server and client to another server Ideal for a heterogeneous distributed system like the Internet. Used primarily as a remote method invocation of a distributed client – server system. Can communicate between clients and servers on different operating systems and implemented by different programming languages (Java cannot do this). Has many standards and services useful in implementing distributed applications. Process can be both server and client to another server Ideal for a heterogeneous distributed system like the Internet. Case Study: CORBA  Application of CORBA

Please refer to the following websites: examples_CORBA_in_java.htm examples_CORBA_in_java.htm rba.pdf rba.pdf hapter4.html hapter4.html Please refer to the following websites: examples_CORBA_in_java.htm examples_CORBA_in_java.htm rba.pdf rba.pdf hapter4.html hapter4.html Case Study: CORBA  Examples of CORBA Implementation

End of the chapter… Thank you