The Common Object Request Broker Architecture (CORBA)

1
The Common Object Request Broker Architecture
(CORBA)

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.

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.

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.

5
The Basic Architecture
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.

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.

8
IDL Sample Code

• module HelloApp
• interface Hello
• string sayHello()
• oneway void shutdown()
• Ref http//java.sun.com/j2se/1.5.0/docs/guide/idl
  /tutorial/GSIDL.htmlwriting

9
Cross-language/vendor CORBA application
10
ORB Core Feature Matrix

• ORB Core Feature Matrix
• http//www.jetpen.com/ben/corba/orbmatrix.html

11
Inter-ORB Protocols

• To allow ORBs (Object Request Brokers) to be
  interoperable
• OMGs 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

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.

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.

14
ORB products

• There are a large number of proprietary as well
  as experimental ORBs available
• (See CORBA Product Profiles, http//www.puder.org
  /corba/matrix/)
• Orbix from IONA
• VisiBroker from Borland
• PrismTechs OpenFusion
• Web Logic Enterprise from BEA
• Ada Broker from ENST
• Free ORBs

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.

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.

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).

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.
•  

19
Interoperable Object Reference (IOR)

• The following is an example of the string
  representation of an IOR
• IOR000000210000001f49444c3a4e53505343697263756974
  496e666f496e71756972793a332e3300010000000200000000
  0000006b0001005c000000156e6f726d657430392e6d63696c
  696e6b2e636f6d00722b83000000473a5c6e6f726d65743039
  2e6d63696c696e6b2e636f6d3a43697263756974496e666f49
  6e71756972793a303a3a49523a4e5350534369726375697449
  6e666f496e7175697279000000000001000000180001005c00
  00000100000000000000080000000049545f30
• 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.

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
CORBAOrbix.object_to_string(
(CORBAObject_ptr) CirInfoImp )
fputs(iorPtr, fp)
fputs("\n", fp) fclose(fp)
// end of try // client side
fileinIOR, is from server side CORBAObject_ptr
ref WLEInterfacestring_to_object(inIOR) lecOr
der EEIntLecOrderServer_narrow(ref) lecOrde
r-gtsetLecResponseForLecOrder()
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.

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 objectsregistration
• clients to resolve nameslook-up

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) raises (NotFound,
CannotProceed, InvalidName) void
unbind (in Name n) raises
(NotFound, CannotProceed, InvalidName)
void destroy () raises (NotEmpty)
. Ref http//www.omg.org/docs/formal/04-10-0
7.txt
24
CORBA Naming Service

• A standard naming hierarchy is defined in a
  manner similar to the naming hierarchy in a file
  directory.

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.
• ltnaming_contextgt..ltnaming_contextgt.ltobject namegt
• Naming contexts and name bindings are created
  using methods provided in the Naming Service
  interface.

26
Example of a Naming Hierarchy

• An object representing the mens clothing
  department is named store.clothing.men
• where the store and clothing are naming contexts,
  and men is an object name.

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
• corbalociiop1.2_at_ise.gmu.edu2050/swe622
• corbanameise.gmu.edu2050Personal/schedule (to
  get the root naming context, and to resolve the
  name Personal/Schedule)
• Ref http//java.sun.com/j2se/1.5.0/docs/guide/id
  l/jidlNaming.html

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.

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.

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 clients request, it
  locates the object adapter associated with the
  object and forwards the clients request to the
  adapter.
• The adapter interacts with the object
  implementations skeleton, which performs data
  marshalling and invoke the appropriate method in
  the servant object.

31
Portable Object Adapter
Object Adapter Interface
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.

33
CORBA Server

• CORBA Server consists of
• A Servant 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

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 )
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)

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("TNameServi
  ce ") // 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()

37
CORBA Client

• Create an ORB Object
• ORB orb ORB.init(args, null)
• Obtain the Initial Object Reference
• org.omg.CORBA.Object objRef orb.resolve_initia
  l_references("NameService")
• Narrow the Object Reference to get Naming
  Context
• NamingContextExt ncRef NamingContextExtHelper.na
  rrow(objRef)
• Resolve the Object Reference in Naming
• helloImpl HelloHelper.narrow(ncRef.resolve-str(
  swe622))
• Invoking the method
• helloImpl.sayHello()

38
The Java IDL (Java 1.5 version)
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.

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.

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

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
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)
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 http//www.puder.org/corba/cg/

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 http//java.sun.com/j2se/1.5.0/docs/guide/idl
  /jidlClients.html

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
  Microsofts COM), if a non-CORBA system does not
  support IIOP.
• Ref http//www.iona.com/support/docs/orbix2000/2.
  0/pguide_cpp/html/DynInterfaces3.html

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 http//java.sun.com/j2se/1.5.0/docs/guide/id
  l/jidlDSI.html

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 http//java.sun.com/j2se/1.5.0/docs/guide/id
  l/jidlDSI.html

49
Repository ID

• Each CORBA interface has a unique Repository
  ID.
• OMG formats of a Repository ID
• IDL style IDLPrefix/ModuleName/InterfaceNameVe
  rsionNumber ( e.g., IDLJavaIDL/DSIInterface1.0
  )
• RMI style RMIClassNameHashCodeSUID
• DCE-style DCEUUID
• Local defined by the local Object Request Broker
  (ORB).
• Ref http//www.bayour.com/openldap/schemas/corba.
  schema

50
Dynamic Skeleton Interface in C

• The CORBAServerRequest class, which is a
  pseudo-object that is the server-side equivalent
  to the client-side CORBARequest. 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 PortableServerDynamicImplementation
  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.

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.
• http//j-integra.intrinsyc.com/support/espresso/do
  c/Demo/Valuetype/Valuetype.html

52
IDL valuetype

• valuetype EmployeeRecord
• // note this is not a CORBAObject
• private string name
• private string email
• private string SSN
• // initializer
• factory init(in string name, in string SSN)

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 objects state
  info as a sequence of bytes.

54
A Java IDL application example
55
An IDL File--Hello.idl

• module HelloApp
• interface Hello
• string sayHello()
• oneway void shutdown()

56
Compiling the IDL File (using Java 1.5)

• Using the compiler idlj to compile an IDL file
• unixgt 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.

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.

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

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

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.

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.

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.

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.

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.

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)
• 19. orb orb_val
• 22. // implements sayHello() method
• 23. public String sayHello()
• 24. return "\nHello world !!\n"
• 25.
• 27. // implement shutdown() method
• 28. public void shutdown()
• 29. orb.shutdown(false)
• 30.

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_ini
  tial_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)

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()

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.
  http//java.sun.com/j2se/1.5.0/docs/guide/idl/jidl
  Example.html
• Java IDL using the POA, a persistent server, and
  a persistent naming service. http//java.sun.com/j
  2se/1.5.0/docs/guide/idl/jidlExample2.html
• Java IDL using the POA-Tie server-side model.
  http//java.sun.com/j2se/1.5.0/docs/guide/idl/jidl
  TieServer.html
• Ref http//java.sun.com/j2se/1.5.0/docs/guide/idl
  /INStutorial.htmlextAPI

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 objects sayHello method is invoked to
  receive a string, and the objects shutdown
  method is invoked to deactivate the service.

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()
• ...

71
Compiling and Running a Java IDL application

• Create and compile the Hello.idl file on the
  server machine
• unixgt 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

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
• unixgt orbd -ORBInitialPort 1050 -ORBInitialHost
  servermachinename
•  
• To do this on Windows
• start orbd -ORBInitialPort 1050 -ORBInitialHost
  servermachinename

73
Compiling and Running a Java IDL application

• 5. On the server machine, start the Hello
  server, as follows
• unixgt java HelloServer ORBInitialHost
  ltnameserver host namegt -ORBInitialPort 1050 
• 6. On the client machine, run the Hello
  application client. From a DOS prompt or shell,
  type
• unixgt 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.

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.

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

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.

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.