1. The Common Object Request Broker Architecture (CORBA)
11/11/2018

2. CORBA
The Common Object Request Broker Architecture (CORBA) is a standard architecture for a distributed objects system.
CORBA is designed to allow distributed objects to interoperate in a heterogeneous environment, where objects can be implemented in different programming languages and/or deployed on different platforms.
11/11/2018

3. CORBA vs. Java RMI
CORBA differs from the architecture of Java RMI in one significant aspect:
RMI is a proprietary facility developed by Sun MicroSystems, Inc., and supports objects written in the Java programming langugage only.
CORBA is an architecture that was developed by the Object Management Group (OMG), an industrial consortium.
11/11/2018

4. CORBA
CORBA is not a distributed objects facility; instead, it is a set of protocol standards.
A distributed object facility (e.g., Orbix and VisiBroker) that adheres to these standard protocols is said to be CORBA-compliant,
CORBA is a very rich set of protocols. We will focus on the key concepts of CORBA related to the distributed objects paradigm. We will also study a facility based on CORBA: the Java IDL.
11/11/2018

5. The Basic Architecture
11/11/2018

6. CORBA Object Interface
Since CORBA is language independent, the CORBA object interface is defined using a universal language with a distinct syntax, known as the CORBA Interface Definition Language (IDL). (like WSDL--Web Services Description Language, to Web services)
A distributed object in CORBA is defined using an IDL file similar to the remote interface file in Java RMI.
11/11/2018

7. CORBA IDL The syntax of CORBA IDL is similar to Java and C++.
Objects defined in a CORBA IDL file can be implemented in a large number of diverse programming languages, including C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLScript.
For each of these languages, OMG has a standardized mapping from CORBA IDL to the programming language, so that an IDL compiler can be used to process a CORBA IDL interface file to generate the proxy files needed to interface with an object implementation in server side or an object in client side written in any of the CORBA-compatible languages.
11/11/2018

8. IDL Sample Code module HelloApp { interface Hello { string sayHello();
oneway void shutdown(); };
Ref:
11/11/2018

9. Cross-language/vendor CORBA application
11/11/2018

10. ORB Core Feature Matrix
11/11/2018

11. Inter-ORB Protocols
To allow ORBs (Object Request Brokers) to be interoperable
OMG’s General Inter-ORB Protocol (GIOP) provides a general framework for protocols to be built on top of specific transport layers
Internet Inter-ORB Protocol (IIOP): GIOP applied to the TCP/IP transport layer
11/11/2018

12. Internet Inter-ORB Protocols (IIOP)
Transport management requirements: specifies the connection and disconnection requirements, and the roles for the object client and object server in making and unmaking connections.
Definition of common data representation: a coding scheme for marshalling and unmarshalling data of each IDL data type.
Message formats: different types of message format are defined. The messages allow clients to send requests to object servers and receive replies.
A client invokes a method declared in a CORBA IDL interface for an object and receives a reply message from the server.
11/11/2018

13. Object Bus
An IIOP-compliant ORB may interoperate with any other IIOP-compliant ORBs over the Internet.
Object Bus: the Internet is seen as a bus that interconnects CORBA objects.
11/11/2018

14. ORB products
There are a large number of proprietary as well as experimental ORBs available:
(See CORBA Product Profiles,
Orbix from IONA
VisiBroker from Borland
PrismTech’s OpenFusion
Web Logic Enterprise from BEA
Ada Broker from ENST
Free ORBs
11/11/2018

15. Server Objects and Clients
As in Java RMI, a CORBA distributed object is exported/registered by a server, similar to the server in RMI.
A client looks up a reference to a distributed object (server object) from a naming or directory service, and invokes the methods of the distributed object.
11/11/2018

16. CORBA Object References
As in Java RMI, a CORBA distributed object is located using an object reference.
CORBA is language-independent, a CORBA object reference is an abstract entity mapped to a language/vendor-specific object reference.
For interoperability, OMG specifies a protocol for the abstract CORBA object reference, known as the Interoperable Object Reference (IOR) protocol.
11/11/2018

17. Interoperable Object Reference (IOR)
An ORB compatible with the IOR protocol will allow an object reference to be registered with and retrieved from any IOR-compliant directory service.
An CORBA object reference represented in this protocol is called Interoperable Object Reference (IOR).
11/11/2018

18. Interoperable Object Reference (IOR)
An IOR is a string that contains encoding for the following information:
The type of an object.
The host where the object can be found.
The port number of the server for that object.
An object key, a string of bytes identifying the object.
The object key is used by an object server to locate the object.
11/11/2018

19. Interoperable Object Reference (IOR)
The following is an example of the string representation of an IOR:
IOR: f49444c3a4e e666f496e a332e b c e6f726d e6d63696c696e6b2e636f6d00722b a5c6e6f726d e6d63696c696e6b2e636f6d3a e666f496e a303a3a49523a4e e666f496e c f30
The representation consists of the character prefix “IOR:” or “IOR2:” followed by a series of hexadecimal numeric characters, each character representing 4 bits of binary data in the IOR.
11/11/2018

20. Generating An IOR File // server side (in C++)
NSPSCircuitInfoInquiry_imp* CirInfoImp = new NSPSCircuitInfoInquiry_imp(argc,argv);
try
{ FILE *fp = fopen("./NSPS_ckt_info.ior","w");
if(fp)
{ char *iorPtr = CORBA::Orbix.object_to_string(
(CORBA::Object_ptr) CirInfoImp );
fputs(iorPtr, fp);
fputs("\n", fp); fclose(fp);
} } // end of try
// client side: file—inIOR, is from server side
CORBA::Object_ptr ref = WLEInterface::string_to_object(inIOR);
lecOrder = EEInt::LecOrderServer::_narrow(ref);
lecOrder->setLecResponseForLecOrder(…);
11/11/2018

21. CORBA Naming Service - 1
The CORBA Naming Service serves as a directory for CORBA objects
The CORBA Naming service is platform independent and programming language independent.
The Naming Service permits ORB-based clients to obtain references to objects they wish to use. It allows names to be associated with object references.
Clients may query a naming service using a predetermined name (e.g. SWE622_HW5) to obtain the associated object reference.
11/11/2018

22. CORBA Naming Service - 2
To export a distributed object, a CORBA object server contacts a Naming Service to bind a symbolic name to the object
The Naming Service maintains a database of names and the objects associated with them.
To obtain a reference to an object, an object client requests the Naming Service to look up the object associated with the name--resolving the object name
The Naming Service API is specified in interfaces defined in Naming Service IDL file
servers to bind names to objects—registration
clients to resolve names—look-up
11/11/2018

23. CORBA Naming Service IDL file
#pragma prefix "omg.org“ // preprocessor directive
module CosNaming { ….
void bind (in Name n, in Object obj)
raises (NotFound, CannotProceed, InvalidName, AlreadyBound);
void rebind (in Name n, in Object obj)
raises (NotFound, CannotProceed, InvalidName);
Object resolve (in Name n)
void unbind (in Name n)
void destroy () raises (NotEmpty); };
Ref:
11/11/2018

24. CORBA Naming Service
A standard naming hierarchy is defined in a manner similar to the naming hierarchy in a file directory.
11/11/2018

25. A Naming Context
A naming context corresponds to a folder or directory in a file hierarchy, while object names corresponds to a file.
The full name of an object, including all the associated naming contexts, is known as a compound name.
<naming_context>.….<naming_context>.<object name>
Naming contexts and name bindings are created using methods provided in the Naming Service interface.
11/11/2018

26. Example of a Naming Hierarchy
An object representing the men’s clothing department is named store.clothing.men
where the store and clothing are naming contexts, and men is an object name.
11/11/2018

27. Interoperable Naming Service
The Interoperable Naming Service (INS) is a URL-based Naming System based on the CORBA Naming Service.
INS is an extension to the CORBA CosNaming service--a tree-like directory for object references.
URL Formats for CORBA Object References
corbaname::ise.gmu.edu:2050#Personal/schedule (to get the root naming context, and to resolve the name Personal/Schedule)
Ref:
11/11/2018

28. CORBA Object Services CORBA Services defined in a standard IDL file
Naming Service
Concurrency Service:
Event Service: for event synchronization;
Logging Service: for event logging;
Scheduling Service: for event scheduling;
Security Service: for security management;
Trading Service: for locating a service by the type (instead of by name);
Time Service: a service for time-related events;
Notification Service: for events notification;
Object Transaction Service: for transactional processing.
11/11/2018

29. Object Adapters
In the basic architecture of CORBA, a distributed object interfaces with the skeleton to interact with the stub on the object client side.
As the architecture evolved, a software component in addition to the skeleton is needed on the server side: an object adapter.
11/11/2018

30. Object Adapters
An object adapter simplifies the responsibilities of an ORB by assisting an ORB in delivering a client request to an object implementation.
When an ORB receives a client’s request, it locates the object adapter associated with the object and forwards the client’s request to the adapter.
The adapter interacts with the object implementation’s skeleton, which performs data marshalling and invoke the appropriate method in the servant object.
11/11/2018

31. Portable Object Adapter
Interface
11/11/2018

32. Portable Object Adapter
There are different types of CORBA object adapters, such as real-time object adapters (in TAO) and portable object adapters.
The Portable Object Adapter (POA) is a particular type of object adapter that is defined by the CORBA standard specification.
A POA object adapter allows an object implementation to function with other different ORBs.
11/11/2018

33. CORBA Server CORBA Server consists of: A Servant class A Server class
implements methods defined an IDL interface
A Server class
contains main() method
instantiates a servant object
binds/registers the servant object to an object name
11/11/2018

34. CORBA Servant Class public class HelloServant extends HelloPOA {
private ORB orb;
public HelloServant( ORB orb ) {
this.orb = orb; }
public String sayHello( ) {
return "Hello From CORBA Server..."; }
public void shutdown( ) {
orb.shutdown( false ); } }
11/11/2018

35. CORBA Server Class - 1 Create and initializes an ORB instance
ORB orb = ORB.init(args, null);
Get a reference to the root POA and activates the POAManager
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
Create a servant instance
org.omg.CORBA.Object ref =
rootpoa.servant_to_reference(helloImpl);
Hello href = HelloHelper.narrow(ref);
11/11/2018

36. CORBA Server Class - 2 Obtain the Initial Object Reference
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService"); // persistent NS
// orb.resolve_initial_references("TNameService "); // transient NS
// Java IDL Transient Naming Service
Narrow the Naming Context
NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef);
Register the new object in the naming context
NameComponent path[] = ncRef.to_name( “swe622” );
ncRef.rebind(path, href);
Wait for invocations of the object from a client
orb.run();
11/11/2018

37. CORBA Client Create an ORB Object Obtain the Initial Object Reference
ORB orb = ORB.init(args, null);
Obtain the Initial Object Reference
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
Narrow the Object Reference to get Naming Context
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
Resolve the Object Reference in Naming
helloImpl = HelloHelper.narrow(ncRef.resolve-str(“swe622”));
Invoking the method
helloImpl.sayHello();
11/11/2018

38. The Java IDL (Java 1.5 version)
11/11/2018

39. Java IDL – J2SE CORBA Facility
Java IDL is part of the Java 2 Platform, Standard Edition (J2SE).
The Java IDL facility includes
a CORBA Object Request Broker (ORB),
an IDL-to-Java compiler, and
a subset of CORBA standard services.
In addition to the Java IDL, J2SE provides a number of CORBA-compliant facilities, including RMI over IIOP, which allows a CORBA application to be written using the RMI syntax and semantics.
11/11/2018

40. Key Java IDL Packages
package org.omg.CORBA – contains interfaces and classes which provides the mapping of the OMG CORBA APIs to the Java programming language
package org.omg.CosNaming - contains interfaces and classes which provides the naming service for Java IDL
class org.omg.CORBA.ORB - provides APIs for the Object Request Broker.
11/11/2018

41. Java IDL Tools
Java IDL provides a set of tools needed for developing a CORBA application:
idlj - the IDL-to-Java compiler (called idl2java in Java 1.2 and before)
orbd - a server process which provides Naming Services and other services
servertool – provides a command-line interface for application programmers to register/unregister a server (appl), and startup/shutdown a server.
tnameserv – an old Transient Java IDL Naming Service
11/11/2018

42. IDL Keywords abstract double long readonly unsigned any enum module
sequence
union
attribute
exception
native
short
ValueBase
boolean
factory
Object
string
valuetype
case
FALSE
octet
struct
void
char
fixed
oneway
supports
wchar
const
float
out
switch
wstring
context in
private
TRUE
custom
inout
public
truncatable
default
interface
raises
typedef
11/11/2018

43. An IDL File module Persistent { interface Hello {
enum NotFoundReason {
missing_node, not_context, not_object};
exception NotFound {
NotFoundReason why;
string name; };
string sayHello( );
void shutdown() raises (NotFound);
// oneway void shutdown() raises (NotFound); };
11/11/2018

44. Dynamic Invocation Interface (DII) - 1
The stub serves as a proxy to access a remote object. Stubs are generated at compile-time and are static.
But what if the interface type of an object is not known at compile time?
CORBA's Dynamic Invocation Interface (DII) offers the possibility of invoking operation calls whose signature is not known at compile time.
Ref:
11/11/2018

45. Dynamic Invocation Interface (DII) - 2
DII uses an object of class org.omg.CORBA.Request to hold everything required to a method invocation:
the object reference
the name of the operation
its parameters
space for the result.
The client builds a Request object describing an operation, then calls the request's invoke method.
The key to dynamic invocation is the ability of requests to hold self-describing data. This facility enables a Request object to represent any invocation of any operation, regardless of its parameters.
Ref:
11/11/2018

46. Dynamic Skeleton Interface (DSI)
A server uses the dynamic skeleton interface (DSI) to receive operations or attribute invocations on an object whose IDL interface is unknown to it at compile-time.
The server defines a function that determines the identity of the requested object; the name of the operation and the types and values of each argument. Clients are unaware that a server is implemented with the DSI.
The DSI is designed to help writing gateways that accept operation or attribute invocations on any specified set of interfaces and pass them to another system.
A gateway can be written to interface between CORBA and some non-CORBA system (such as Microsoft’s COM), if a non-CORBA system does not support IIOP.
Ref:
11/11/2018

47. Dynamic Skeleton Interface in Java - 1
Declare the servant class to extend
org.omg.CORBA.DynamicImplementation.
Implement the invoke (ServerRequest request) method to:
- Extract the operation name via a call on op_name().
- Build an NVList of the operation parameters
- Extract the parameter values via a call on params()
- Perform the operation, assigning new values to out/inout parameters
- Call either result() and/or except()
Implement the _ids() method. This method is inherited from org.omg.CORBA.portable.ObjectImpl, the superclass of DynamicImplementation. It returns the repository IDs of the interfaces implemented by this dynamic server.
Ref:
11/11/2018

48. Dynamic Skeleton Interface in Java - 2
The Server Class:
Create an instance of the DSI Servant object using new(). (at the run time)
Register it with the ORB via a call to org.omg.CORBA.ORB.connect()
Wait for requests from clients
Ref:
11/11/2018

49. Repository ID Each CORBA interface has a unique “Repository ID“.
OMG formats of a Repository ID:
IDL style: IDL:Prefix/ModuleName/InterfaceName:VersionNumber ( e.g., IDL:JavaIDL/DSIInterface:1.0 )
RMI style: RMI:ClassName:HashCode[:SUID]
DCE-style: DCE:UUID
Local: defined by the local Object Request Broker (ORB).
Ref:
11/11/2018

50. Dynamic Skeleton Interface in C++
The CORBA::ServerRequest class, which is a pseudo-object that is the server-side equivalent to the client-side CORBA::Request. When the POA dispatches a request to a DSI servant, it passes an instance of ServerRequest to communicate all information about the request needed to allow the servant to fulfill it.
The PortableServer::DynamicImplementation servant base class, from which concrete DSI servant classes inherit. This base class provides the following pure virtual methods that DSI servant classes are expected to override:
- void invoke (ServerRequest_ptr server_request), which is upcalled by the POA to allow the servant to handle requests. The POA passes the ServerRequest representing the request being processed to this method.
RepositoryId _primary_interface (const ObjectId& id, POA_ptr poa), which is called by the ORB/POA run time when it needs the repository ID string identifying the most-derived interface of the object that the servant is incarnating.
The _primary_interface method is called when the application calls POA methods, such as servant_to_reference and id_to_reference, so that the run time can create object references containing the appropriate repository ID.
11/11/2018

51. Passed-By-Value in CORBA
CORBA 2.3 offers the feature of objects by value by using IDL valuetype. This mechanism allows CORBA objects to be passed by value in an IDL operation instead of passing objects by reference (by default).
Passing by value means passing the internal state of an object as an operation parameter or returned value, and constructing a copy of the object on the far side.
To pass a CORBA object by-value, you must first define an IDL type using a valuetype to represent the state of the object. This type is passed as an operation parameter and used to create a new instance of the object on the other side.
11/11/2018

52. IDL valuetype valuetype EmployeeRecord {
// note this is not a CORBA::Object
private string name;
private string ;
private string SSN;
// initializer
factory init(in string name, in string SSN); };
11/11/2018

53. Object Passing within RMI
Primitive types: passed by value
Remote objects: passed by reference
Non-remote object: passed by value
Java Object Serialization: save object’s state info as a sequence of bytes.
11/11/2018

54. A Java IDL application example
11/11/2018

55. An IDL File--Hello.idl module HelloApp { interface Hello
string sayHello();
oneway void shutdown(); };
11/11/2018

56. Compiling the IDL File (using Java 1.5)
Using the compiler idlj to compile an IDL file:
unix> idlj -fall Hello.idl
The –fall command option is necessary for the compiler to generate all the files needed for both client and server.
If succeeded, the following files can be found in a HelloApp (module name) subdirectory:
HelloOperations.java Hello.java
HelloHelper.java HelloHolder.java
_HelloStub.java HelloPOA.java
These files require no modifications.
11/11/2018

57. The *Operations.java file
HelloOperations.java is known as a Java operations interface in general.
It is a Java interface file that is equivalent to the CORBA IDL interface file--Hello.idl.
11/11/2018

58. HelloApp/HelloOperations.java
The file contains the methods specified in the original IDL file: in this case the methods sayHello( ) and shutdown().  
package HelloApp;
01. package HelloApp;
04. /**
05. * HelloApp/HelloOperations.java
06. * Generated by the IDL-to-Java compiler (portable),
07. * version "3.1" from Hello.idl
08. */
09.
10. public interface HelloOperations
11. {
12. String sayHello ();
13. void shutdown ();
14. } // interface HelloOperations
11/11/2018

59. HelloApp/Hello.java
The signature interface file combines the characteristics of the Java operations interface (HelloOperations.java) with the characteristics of the CORBA classes that it extends.
01. package HelloApp;
03. /**
04. * HelloApp/Hello.java
05. * Generated by the IDL-to-Java compiler (portable),
06. * version "3.1" from Hello.idl
07. */
09. public interface Hello extends HelloOperations,
10. org.omg.CORBA.Object,
11. org.omg.CORBA.portable.IDLEntity
12. {
13. } // interface Hello
11/11/2018

60. HelloHelper.java, the Helper class
The Java class HelloHelper provides auxiliary functionality needed to support a CORBA object in the context of the Java language.
In particular, a method, narrow, allows a CORBA object reference to be cast to its corresponding object type in Java, so that a CORBA object may be operated on using syntax for Java object.
11/11/2018

61. HelloHolder.java, the Holder class
The Java class called HelloHolder holds (contains) a reference to an object that implements the Hello interface.
The class is used to handle an out and/or an inout parameters in IDL in Java syntax
In IDL, a parameter may be declared to be out if it is an output argument, and inout if the parameter contains an input value as well as carries an output value.
11/11/2018

62. _HelloStub.java
The Java class _HelloStub is the stub file, the client-side proxy, which interfaces with the client object.
It extends org.omg.CORBA.portable.ObjectImpl and implements the Hello.java interface.
11/11/2018

63. HelloPOA.java, the server skeleton
The Java class HelloPOA is the skeleton, the server-side proxy, combined with the portable object adapter.
It extends org.omg.PortableServer.Servant, and implements the InvokeHandler interface and the HelloOperations interface.
11/11/2018

64. The application Server-side Classes
On the server side, two classes need to be provided: a servant class and a server class.
The servant, HelloServant, implements the Hello IDL interface; each Hello object is an instantiation of this class.
11/11/2018

65. The Servant - HelloApp/HelloServant.java
// The servant -- object implementation -- for the Hello
// example. Note that this is a subclass of HelloPOA,
// whose source file is generated from the
// compilation of Hello.idl using j2idl.
06. import HelloApp.*;
07. import org.omg.CosNaming.*;
08. import java.util.Properties; …
15. class HelloServant extends HelloPOA {
16. private ORB orb;
18. public void setORB(ORB orb_val) {
orb = orb_val; }
22. // implements sayHello() method
23. public String sayHello() {
return "\nHello world !!\n";
25. }
27. // implement shutdown() method
28. public void shutdown() {
orb.shutdown(false);
30. }
31. } //end class
11/11/2018

66. The server - HelloApp/HelloServer.java
public class HelloServer {
public static void main(String args[]) {
try{ // create and initialize the ORB
ORB orb = ORB.init(args, null);
// get reference to rootpoa & activate the POAManager
POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
HelloServant helloServant = new HelloServant();
helloServant.setORB(orb);
// get object reference from the servant
org.omg.CORBA.Object ref =
rootpoa.servant_to_reference(helloServant);
// and cast the reference to a CORBA reference
Hello href = HelloHelper.narrow(ref);
11/11/2018

67. HelloApp/HelloServer.java - continued
// get the root naming context
// NameService invokes the permanent name service
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
// Use NamingContextExt, which is part of the
// Interoperable Naming Service (INS) specification.
NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef);
// bind the Object Reference in Naming
String name = "Hello";
NameComponent path[] = ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println("HelloServer is ready ...");
// wait for invocations from clients
orb.run();
11/11/2018

68. NamingContextExt API
The NamingContextExt interface, derived from NamingContext provides the operations required to use URLs and stringified names.
Examples:
Java IDL: using the POA and a transient server.
Java IDL: using the POA, a persistent server, and a persistent naming service.
Java IDL: using the POA-Tie server-side model.
Ref:
11/11/2018

69. A CORBA Client Application
A client program can be a Java application, an applet, or a servlet.
The client code is responsible for
creating and initializing the ORB
looking up the object using the INS
invoking the narrow method to cast the object reference to a reference to a Hello object implementation
invoking remote methods using the reference
The object’s sayHello method is invoked to receive a string, and the object’s shutdown method is invoked to deactivate the service.
11/11/2018

70. Sample Client public class HelloClient{ static Hello hello;
public static void main (String args[]){
try{ ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references
("NameService");
NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef);
hello = HelloHelper.narrow(ncRef.resolve_str
(“Hello”));
System.out.println(hello.sayHello());
hello.shutdown();
...
11/11/2018

71. Compiling and Running a Java IDL application
Create and compile the Hello.idl file on the server machine:
unix> idlj -fall Hello.idl
2. Copy the directory containing Hello.idl (including the subdirectory generated by idlj) to the client machine.
3. In the HelloApp directory on the client machine: create HelloClient.java. Compile the *.java files, including the stubs and skeletons (which are in the directory HelloApp):
javac *.java HelloApp/*.java
11/11/2018

72. Compiling and Running a Java IDL application
4. In the HelloApp directory on the server machine:
Create HelloServer.java. Compile the .java files:
javac *.java HelloApp/*.java
On the server machine: Start the Java Object Request Broker Daemon, orbd, which includes a Naming Service.
To do this on Unix:
unix> orbd -ORBInitialPort ORBInitialHost servermachinename&
To do this on Windows:
start orbd -ORBInitialPort ORBInitialHost servermachinename
11/11/2018

73. Compiling and Running a Java IDL application
5. On the server machine, start the Hello server, as follows:
unix> java HelloServer –ORBInitialHost <nameserver host name> -ORBInitialPort 1050 
6. On the client machine, run the Hello application client. From a DOS prompt or shell, type:
unix> java HelloClient -ORBInitialHost
nameserverhost -ORBInitialPort 1050
all on one line.
Note that nameserverhost is the host name (e.g., mason.gmu.edu) on that the IDL name server is running.
11/11/2018

74. Compiling and Running a Java IDL application
7. Kill or stop orbd when finished. The name server will continue to wait for invocations until it is explicitly stopped.
8. Stop the object server.
11/11/2018

75. Summary-1 You have been introduced to
the Common Object Request Broker Architecture (CORBA), and
a specific CORBA facility based on the architecture: Java IDL
11/11/2018

76. Summary-2 The key topics introduced with CORBA are:
The basic CORBA architecture and its emphasis on object interoperability and platform independence
Object Request Broker (ORB) and its functionalities
The Inter-ORB Protocol (IIOP) and its significance
CORBA object reference and the Interoperable Object Reference (IOR) protocol
CORBA Naming Service and the Interoperable Naming Service (INS)
Standard CORBA object services and how they are provided.
Object adapters, portable object Adapters (POA) and their significance.
11/11/2018

77. Summary-3 The key topics introduced with Java IDL are:
It is part of the Java TM 2 Platform, Standard Edition (J2SE)
Java packages are provided which contain interfaces and classes for CORBA support
Tools provided for developing a CORBA application include idlj (the IDL compiler) and orbd (the ORB and name server)
An example application Hello
Steps for compiling and running an application.
Client callback is achievable.
CORBA toolkits and Java RMI are comparable and alternative technologies that provide distributed objects. An application may be implemented using either technology. However, there are tradeoffs between the two.
11/11/2018