Download Topic 8 - Murdoch University

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
ICT337 Advanced Software Development
Murdoch University
Topic 8
Topic 8
CORBA
 What is CORBA?
 How does it work?
 Benefits of using CORBA ORBs
 Java IDL
 Writing a CORBA program (example 1)
 IDL to Java mappings
 CORBA examples 2 & 3
 Callbacks in CORBA (example 4)
 Images sent from client to server (example 5)
 SII and DII
 RMI vs CORBA
 Summary
Topic8.doc
Page 1
ICT337 Advanced Software Development
Murdoch University
Topic 8
What is CORBA?
CORBA (the Common Object Request Broker
Architecture) is a specification that enables distributed
software components to work together regardless of the
programming language used to develop them, the computer
platform they run on, or the computer networks they use.
CORBA defines an abstract, inherently distributed object
model and provides an infrastructure that enables
invocations of operations on these objects as if they were
local to the application using them.
CORBA is standardized on language bindings (or
mappings) for: C, C++, Java, Ada, COBOL, Smalltalk,
Objective C, Lisp.
The specification is written in a neutral Interface
Definition Language (IDL). The IDL is used to create
interfaces that all objects conforming to the CORBA
specification can understand. The interfaces include the
declaration of operations (equiv. to Java methods) that the
CORBA objects support.
The CORBA Object Request Brokers (ORBs) use
a protocol called the IIOP (Internet Inter-ORB
Protocol), which is based on the standard TCP/IP
protocol.
Topic8.doc
Page 2
ICT337 Advanced Software Development
Murdoch University
Topic 8
CORBA is a product of a consortium called the Object
Management Group (OMG) that includes over 800
companies – except for Microsoft, which has its own
competing object broker called the Distributed
Component Object Model (DCOM).
CORBA 1.1 was released in 1991
CORBA 2 “ “
“
“ end of 1994
CORBA 3 “ “
“
“ end of 1999
CORBA implementation: The Java 2 ORB comes with
jdk1.2.x
In this topic, we will focus only on CORBA/JAVA
ORB from JavaSoft’s Java IDL for jdk1.3 and above.
Topic8.doc
Page 3
ICT337 Advanced Software Development
Murdoch University
Topic 8
How does it work?
Distributed CORBA objects are packaged as binary
components that remote clients can access via method
invocations.
The ORB is the object bus. It lets CORBA objects
transparently make requests to, and receive responses from,
other objects located locally or remotely – clients are not
aware of the mechanisms used in the communication.
C
C++
...
Java
C
C++
IDL
IDL
Client Stubs
...
Java
IDL
Server Skeletons
CORBA IIOP ORB
CORBA IDL Language Bindings Provide Client/Server Interoperability
The concepts of stubs, skeletons, and ORBs between
CORBA and RMI are the same. The only differences are:
 the protocols used by the RMI ORB and CORBA
ORB are JRMP and IIOP respectively (so RMI ORBs
and CORBA ORBs cannot communicate).
Topic8.doc
Page 4
ICT337 Advanced Software Development
Murdoch University
Topic 8
 the interfaces of CORBA objects are defined using a
special language called IDL.
 Java RMI supports server and client codes written in
Java only.
Benefits of using CORBA ORBs
A CORBA ORB provides a wide variety of distributed
middleware services. Below is a short list of benefits that
every CORBA ORB provides:
 Static and dynamic method invocations: A CORBA
ORB lets you either statically define your method
invocations at compile time or lets you dynamically
discover them at run time.
 High-level language bindings: A CORBA ORB lets
you invoke methods on server objects using your
preferred high-level programming language.
 Built-in security and transactions: The ORB includes
context information to handle security and
transactions across machine and ORB boundaries.
Topic8.doc
Page 5
ICT337 Advanced Software Development
Murdoch University
Topic 8
 Polymorphic messaging: in contrast to other forms of
middleware, an ORB does not simply invoke a remote
function – it invokes a function on a target object.
Thus, the same function call will have different
effects, depending on the object that receives it.
client
server
code
Call foo
Data
Execute foo
RPC
Mechanism
client
Call
foo
on
object
X
Call
foo
on
object
Y
server
Object X
foo
ORB
 Local/remote transparency: in general, a CORBA
client/server programmer does not have to be
concerned with transports, server locations, byte
ordering across dissimilar platforms, or target
operating systems.
Topic8.doc
Page 6
Object Y
foo
ICT337 Advanced Software Development
Murdoch University
Topic 8
Java IDL
Java IDL is an Object Request Broker provided with the
Java 2 Platform. Together with the idlj compiler, it can
be used to define, implement, and access CORBA objects
from the Java programming language.
Java IDL is compliant with the CORBA/IIOP 2.0
Specification and the IDL-to-Java Language Mapping.
Similar to the concepts in RMI, a CORBA object puts all
its methods (including parameter types and exception
thrown, if any) available to the clients in its interface. The
interface is defined using the OMG Interface Definition
Language (IDL). An IDL compiler (eg. idlj) translates
the CORBA object definitions into a specific
programming language according to the appropriate OMG
language mapping.
The goal in CORBA object development is the creation
and registration of an object server, or simply server. A
server is a program which contains the implementation of
one or more object types and which has been registered
with the ORB.
(NOTE: idlj comes with jdk1.3. If you are using jdk1.2
then an IDL compiler called idltojava can be
downloaded separately)
Topic8.doc
Page 7
ICT337 Advanced Software Development
Murdoch University
Topic 8
Writing a CORBA program
All CORBA objects support an IDL interface; the IDL
interface defines an object type. An interface can inherit
from one or more other interfaces.
A module in IDL is equivalent to a package in Java. A
module groups interfaces together into their own
namespace. An IDL interface declares a set of client
accessible operations, exceptions, and typed attributes
(values). Each operation has a signature that defines its
name, parameters, result, and exceptions.
The CORBA IDL syntax is very similar to that of C++
and Java.
Writing a CORBA program involves the following steps:
1. specify the interfaces (the IDL file)
2. implement (Java coding) the methods declared in the
interfaces
3. write the CORBA server program (Java coding)
4. write the CORBA client program (Java coding)
Topic8.doc
Page 8
ICT337 Advanced Software Development
Murdoch University
Topic 8
Step 1: specify the IDL module. Several interfaces can be
grouped under an IDL module. Declare the methods
available to the clients under each interface.
An example of an IDL module, Hello.idl:
module HelloApp {
interface Hello {
string sayHello();
};
};
Do not forget the
semicolon character
NOTE: the letter ‘s’
in IDL string is in
lowercase
The IDL compiler, idlj, translates IDL definitions into
Java constructs according to the IDL-to-Java language
mapping. In addition, it generates a stub file and a
skeleton file for each object type.
Step 2: use idlj to create the stub, skeleton, and other
associated files:
idlj –fall Hello.idl
The above command is equivalent to
idlj –fclient -fserver Hello.idl
which creates both the client- (stub) and server-side
(skeleton) binding.
The idlj compiler creates 6 files under the subdirectory
having the same name as the module name (here, the
Topic8.doc
Page 9
ICT337 Advanced Software Development
Murdoch University
Topic 8
subdirectory is HelloApp). These files are: XXXPOA.java,
_XXXStub.java, XXXHelper.java, XXXHolder.java,
XXXOperations.java, XXX.java, where XXX is the
interface name.
In the example above, we have

HelloPOA.java:

_HelloStub.java:

HelloHelper.java:
this is an abstract Java class that
implements the CORBA server-side skeleton for
Hello. (In earlier versions of Java
_HelloImplBase.java was created instead to play a
similar role in a slightly different architecture)
this is a Java class that implements
the client-side stub for the Hello object. It is an
internal implementation of the Hello interface that
provides marshalling functions. Make sure you
include this file with your client implementation.
a helper class is a collection of
static methods for a number of type-specific
operations. These include narrowing (think about
this as casting) object references to the correct
interface type, marshalling and unmarshalling values
to and from streams.
This is a Java class that provides useful helper
functions for the Hello clients.

HelloHolder.java: to accommodate the passing of
inout and out parameters in Java (which can pass
arguments only by value), there are holder classes for
Topic8.doc
Page 10
ICT337 Advanced Software Development
Murdoch University
Topic 8
IDL predefined (see the later section on “CORBA
types”) and user-defined types. Holder classes are
user-defined types that are generated by the IDL
compiler. Holder classes for IDL predefined types
are provided in the CORBA class library (package
org.omg.CORBA).
This is a Java class that holds a public instance
member of type Hello. It is used by clients and
servers to pass objects of type Hello as out and inout
parameters (see later) inside method invocations.

Hello.java:
this is the Java version of Hello.idl.
The content of the file is:
name of the
package HelloApp;
module
/**
* HelloApp/Hello.java .
All CORBA objects
* Generated by the IDL-to-Java compiler (portable),
are derived from v
* from Hello.idl
org.omg.CORBA.
* Saturday, 18 October 2003 08:19:15 PM WST
Object to ensure
required CORBA
*/
functionality
public interface Hello extends
HelloOperations, org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity {
} // interface Hello
 HelloOperations.java:
this is the Java interface that
embodies the declaration of the methods in Hello.idl
package HelloApp;
public interface HelloOperations {
String sayHello ();
Topic8.doc
Page 11
ICT337 Advanced Software Development
Murdoch University
Topic 8
}
XXX is
the
interface
name
Now we come to the server side implementation. We
must define the methods declared in Hello.idl. The
compiler idlj has created an abstract XXXPOA class that
provides the basic functionality. What we need to do is
inherit this class and include the extra methods we desire.
Step 3: write HelloImpl.java:
import HelloApp.*;
public class HelloImpl extends HelloPOA
{
public String sayHello()
{
return "\nHello world !!\n";
}
}
Every CORBA server must have some kind of main
program that initializes the ORB environment and starts
objects, so the next step is…
Step 4: write HelloServer.java:
import
import
import
import
import
import
import
Topic8.doc
HelloApp.*;
org.omg.CosNaming.*;
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
org.omg.PortableServer.*;
org.omg.PortableServer.POA;
java.util.Properties;
Page 12
ICT337 Advanced Software Development
Murdoch University
Topic 8
public class HelloServer {
public static void main(String args[]) {
try {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
note the
two
different
types of
Object.
Here, we
have ;
org.omg
.CORBA.
Object
// get reference to rootpoa
//& activate the POAManager
POA rootpoa = POAHelper.narrow(
orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
// create servant
HelloImpl helloImpl = new HelloImpl();
helloImpl is a servant
object
// get object reference from the servant
org.omg.CORBA.Object ref = root
poa.servant_to_reference
(helloImpl);
Hello href = HelloHelper.narrow(ref);
// get the root naming context
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
Topic8.doc
Page 13
ICT337 Advanced Software Development
Murdoch University
Topic 8
String name = "Hello"; NameComponent path[] =
ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println
("HelloServer ready and waiting ...");
// wait for invocations from clients
orb.run();
} catch (Exception e)
{ System.err.println("ERROR: " + e);
e.printStackTrace(System.out); }
System.out.println("HelloServer Exiting ...");
} }
a servant object is a Java object that is an
}
instance of the server implementation class
Very often you will have to also write the client program
for your clients and then make it available for the clients
to use. Thus, the names of the objects that are bound on
the name server are known to the client program (you).
Below is HelloClient.java
Topic8.doc
Page 14
ICT337 Advanced Software Development
Murdoch University
Topic 8
Step 5: write HelloClient.java
import
import
import
import
HelloApp.Hello;
HelloApp.HelloHelper;
org.omg.CosNaming.*;
org.omg.CORBA.*;
public class HelloClient {
public static void main(String args[]) {
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
the IDL
interface
(Hello)
defines an
object type (see
Page 8, para 1)
these are the only two files you
need to import. However, at run
time, you will also need the stub
file, _HelloStub.class, and
the operations file,
HelloOperations.class.
All these files are created by
idlj and are in the subdirectory
HelloApp.
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
// call the Hello server object and print results
String hello = helloRef.sayHello();
Topic8.doc
Page 15
ICT337 Advanced Software Development
Murdoch University
Topic 8
System.out.println(hello);
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
}
}
Step 6: compile all the Java class files:
javac
javac
javac
javac
HelloApp\*.java
HelloClient.java
HelloImpl.java
HelloServer.java
Step 7: execution:
 start the name server in the first MS-DOS window using the tnameserv utility:
tnameserv –ORBInitialPort 1099
Default ORB port = 900
 start the CORBA server in the second MS-DOS window:
java HelloServer –ORBInitialPort 1099
Topic8.doc
Page 16
ICT337 Advanced Software Development
Murdoch University
Topic 8
 start the CORBA client in the third MS-DOS window:
java HelloClient –ORBInitialPort 1099
Specify IP address of server if the
client and server are not on the
same machine (often the case)
java HelloClient –ORBInitialPort 1099 –ORBInitialHost 123.4.5.6
Topic8.doc
Page 17
ICT337 Advanced Software Development
Murdoch University
Topic 8
If the client program is an applet rather than an application then the port number (and other
settings, if appropriate) must be explicitly set in the applet or in the html file. Below is
HelloApplet.java:
import
import
import
import
import
import
import
HelloApp.Hello;
HelloApp.HelloHelper;
org.omg.CosNaming.*;
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
java.awt.Graphics;
java.util.Properties;
public class HelloApplet extends java.applet.Applet {
String message = "";
public void init() {
try {
String port = "1099";
*
System.out.println("Using ORBInitialPort = " + port);
// specify the port number by including it in the property list
Properties props = new Properties();
props.put("org.omg.CORBA.ORBInitialPort", port);
Topic8.doc
Page 18
ICT337 Advanced Software Development
Murdoch University
Topic 8
ORB orb = ORB.init(this, props);
Replace all the lines
from * to ** with:
ORB orb =
ORB.init(this,
null);
if Hello2.html is
used
**
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
// call the Hello server object and print results
message = helloRef.sayHello();
} catch (Exception e) {
System.out.println("HelloApplet exception: " + e.getMessage());
e.printStackTrace(System.out);
}
}
Topic8.doc
Page 19
ICT337 Advanced Software Development
Murdoch University
Topic 8
public void paint(Graphics g)
{
g.drawString(message, 25, 50);
}
}
The corresponding HTML file is:
 Hello1.html
<html>
<head>
<title>Hello1 (CORBA client applet)</title>
</head>
<body>
<h1>Hello1.html</h1>
<applet codebase="." code=HelloApplet.class width=460 height=160>
</param>
</applet>
</body>
</html>
Topic8.doc
Page 20
ICT337 Advanced Software Development
Murdoch University
 Hello2.html
<html>
…
Topic 8
this HTML file exposes the CORBA host IP address
and port number to the client. For security reason, it
may not be preferred.
<applet codebase="." code=HelloApplet.class width=460 height=160>
<PARAM name="org.omg.CORBA.ORBInitialHost" value="123.4.5.6">
<PARAM name="org.omg.CORBA.ORBInitialPort" value=1099>
</param>
</applet>
</body>
</html>
Topic8.doc
Page 21
ICT337 Advanced Software Development
Murdoch University
Topic 8
A few notes
 Modularity in CORBA: All the 6 Java files
(including the stub and skeleton files) under the
HelloApp subdirectory are generated by the idlj
compiler using the Hello.idl file as input; out of
these 6 files only 4 are required by the client
program, HelloClient.java or HelloApplet.java.
Modifying the implementation in HelloImpl.java
does not require these 6 files to be recompiled and
reincorporated in the client code. (cf. RMI)
 Low-level details omitted in coding:
o idlj generates the stub and skeleton files for
you; you only need to code Hello.idl,
HelloImpl.java, HelloServer.java and the
client program. If C++ rather than Java is
desired then use a IDL-to-C++ compiler (eg.
idl2cpp that comes with VisiBroker for C++
3.1).
o idlj also generates the Holder and Helper
classes for each user-defined IDL interface,
allowing you to call the methods defined in
these classes without the need to study the
detailed implementation.
 See also the Hello-remote folder and the
discussions on exportation of files of the server to
the client.
Topic8.doc
Page 22
ICT337 Advanced Software Development
Murdoch University
Topic 8
CORBA types
IDL to Java mappings
CORBA IDL
Java
General Constructs
module
package
in parameters
normal Java parameters
out and inout parameters
Java Holder classes (generated by idlj
and then instantiated by client side)
attribute
pair of methods
Exception
Exception
Primitive Types
const
public static final field
boolean, TRUE, FALSE (1-bit)
boolean, true, false (1-bit)
char (8-bits)
char (16-bits)
Topic8.doc
Page 23
ICT337 Advanced Software Development
Murdoch University
Topic 8
wchar (16-bits)
char (16-bits)
octet (8-bits)
byte (8-bits)
string, wstring
java.lang.String
short, unsigned short (16)
short (16)
long, unsigned long (32)
int (32)
long long,
unsigned long long (64)
long (64)
float (32)
float (32)
double (64)
double (64)
Fixed
java.math.BigDecimal
Constructed Types
interface
interface
sequence
array
array
array
struct
Java class with same name as
struct type
enum
Java class with same name as enum
type
typedef
Java does not have a typedef
construct. Mapped to simple IDL types
or user-defined IDL types
any
Java class org.omg.CORBA.Any
Java provides 16-bits for characters so that you can use
the Unicode character standard
The 16-bit IDL wchar stands for “wide char”
Topic8.doc
Page 24
ICT337 Advanced Software Development
Murdoch University
Topic 8
IDL parameters
CORBA IDL lets you specify both object types and
non-object types as in, out, and inout parameters in
IDL-specified methods. Java only supports parameters
passing mode equivalent to the in mode of CORBA
IDL.
 return value – this is the return value of a method.
IDL return types always map directly to the
corresponding Java types.
 in – like the Java counterpart, this is the passedby-value type of parameters. Consequently, they
map to normal Java parameters. CORBA copies
the values of in parameters from the client to the
server.
 out – this is the passed-by-reference type of
parameters that is not supported by Java. So the
IDL-to-Java mapping must define some Holder
classes (eg. org.omg.CORBA.ShortHolder) , which
serve as containers for all the IDL basic and userdefined types. CORBA copies the values of out
parameters from the server to the client
 inout – similar to the out parameters, Holder
classes are used for inout parameters. CORBA
copies the values in both directions – during the
invocation and the reply.
Topic8.doc
Page 25
ICT337 Advanced Software Development
Murdoch University
Topic 8
Example 1: the IDL code
module myPackage {
module mySubPackage {
interface MyInterface {
the return
const long My_CONSTANT = 38;
value of this
void myMethod1(in long number);
method is of
long myMethod2(out long number);
type long
};
};
Here, number is an out
};
parameter of type long
number is
an in
parameter
of type
long
maps to the following Java code:
package myPackage.mySubPackage;
public interface MyInterface extends
number
org.omg.CORBA.Object {
is an input
parameter
public static final int MY_CONSTANT
= (int)(38L);
public void myMethod1(int number);
public int myMethod2(
org.omg.CORBA.IntHolder number);
}
return type of the method
myMethod2
Example 2: an attribute in IDL
module myPackage {
interface MyInterface {
attribute string name;
};
};
an
IntHolder
type for output
parameter
is mapped to:
package myPackage;
public interface MyInterface extends
Topic8.doc
Page 26
ICT337 Advanced Software Development
Murdoch University
org.omg.CORBA.Object {
String name();
void name(String arg);
}
Topic 8
cf. the get and set
methods of a
bound property in
JavaBeans
However, these accessor methods do not follow the
JavaBeans specification design patterns (ie. the get and
set methods for property XXX should have the pattern Type
getXXX() and void setXXX(Type)
Topic8.doc
Page 27
ICT337 Advanced Software Development
Murdoch University
Example 3:
IDL specification
File name: MyModule.idl
module MyModule {
interface MyInt1 {
struct MyStruct {
short age;
string name;
};
short getAge();
string getName();
Topic 8
Java mapping
File name: MyModule\MyInt1Operations.java
package MyModule;
public interface MyInt1Operations {
superclass of
short getAge ();
the class
String getName ();
MyInt1
}
File name: MyModule\MyInt1Package\MyStruct.java
package MyModule.MyInt1Package;
public final class MyStruct implements
org.omg.CORBA.portable.IDLEntity {
public short age = (short)0;
public String name = null;
public MyStruct () {
}
};
interface MyInt2 {
string sayHello();
};
};
public MyStruct (short _age, String _name) {
age = _age;
name = _name;
}
}
File name: MyModule\MyInt2Operations.java
package MyModule;
public interface MyInt2Operations {
String sayHello ();
}
Topic8.doc
Page 28
superclass of
the class
MyInt2
ICT337 Advanced Software Development
Murdoch University
Topic 8
CORBA example 2
See folder eg2.
File Counter.idl:
module Counter {
interface Count {
long increment(in long arg);
double decrement(inout double arg);
void setRandom(out double arg);
};
};
File CountImpl.java:
import Counter.*;
// import classes under the package Counter
public class CountImpl extends Counter.CountPOA {
public int increment(int arg) {
return ++arg;
}
public double decrement(org.omg.CORBA.DoubleHolder arg) {
// not that arg is declared as an "inout" parameter in
// Counter.idl
Topic8.doc
Page 29
ICT337 Advanced Software Development
Murdoch University
Topic 8
return --arg.value;
}
public void setRandom(org.omg.CORBA.DoubleHolder arg) {
// note that arg is declared as an "out" parameter in Counter.idl
arg.value = Math.random() + arg.value;
because arg is an “out” parameter,
}
}
File
always in the
range 0..1
CountServer.java:
import
import
import
import
import
import
import
arg.value is not used in the
assignment statement. However, the
client still needs to create an instance of
the argument for marshalling.
always returns a
double whose value
is between 0 and 1
Counter.*;
org.omg.CosNaming.*;
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
org.omg.PortableServer.*;
org.omg.PortableServer.POA;
java.util.Properties;
public class CountServer {
public static void main(String args[]) {
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
Topic8.doc
Page 30
ICT337 Advanced Software Development
Murdoch University
Topic 8
// get reference to rootpoa & activate the POAManager
POA rootpoa =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
CountImpl countImpl = new CountImpl();
// get object reference from the servant
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(countImpl);
Count href = CountHelper.narrow(ref);
// get the root naming context
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);
CountServer.java
// bind the Object Reference in Naming
is almost identical to
String name = "Count";
HelloServer.java
NameComponent path[] = ncRef.to_name( name );
except for the reference
ncRef.rebind(path, href);
name “Count” here
System.out.println("CountServer ready and waiting ...");
Topic8.doc
Page 31
ICT337 Advanced Software Development
Murdoch University
Topic 8
// wait for invocations from clients
orb.run();
} catch (Exception e)
{ System.err.println("ERROR: " + e); e.printStackTrace(System.out);
}
System.out.println("CountServer Exiting ...");
}
}
File
CountClient.java:
import
import
import
import
Counter.Count;
Counter.CountHelper;
org.omg.CosNaming.*;
org.omg.CORBA.*;
public class CountClient {
public static void main(String args[]) {
try {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
Topic8.doc
Page 32
ICT337 Advanced Software Development
Murdoch University
Topic 8
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("Count", "");
NameComponent path[] = {nc};
client must
know the name
“count” for
object reference
Counter.Count countRef =
Counter.CountHelper.narrow(ncRef.resolve(path));
// test the method increment, which takes an input argument
System.out.println("increment(18) = " +
countRef.increment(18));
// test the method decrement, which takes an input/output
// argument
org.omg.CORBA.DoubleHolder dh =
new org.omg.CORBA.DoubleHolder(28);
System.out.println("decrement(28) = " +
countRef.decrement(dh));
// test the method setRandom, which takes an output argument
countRef.setRandom(dh);
System.out.println("random(dh) returned " + dh.value);
Topic8.doc
Page 33
ICT337 Advanced Software Development
Murdoch University
Topic 8
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
}
}
Topic8.doc
Page 34
ICT337 Advanced Software Development
Murdoch University
The output produced by CountClient is:
Topic 8
this number is different
in every run, but is
always in the range 0..1
increment(18) = 19
decrement(28) = 27.0
random(dh) returned 0.6521868116933294
CORBA Example 3
See the SystemClock folder – modified from the example
in the textbook (Section 26.3).
In order to use the older (now deprecated) architecture
which this example is built with you need to run the idlj
thus:
idlj -fall -oldImplBase
systemclock.idl
Topic8.doc
Page 36
ICT337 Advanced Software Development
Murdoch University
Topic 8
“Callback” in CORBA (Example 4)
A callback is a call from a server to a client. A callback
reverses the role of the server and the client; it allows a
client to become a server. Any server that has an object
reference for the client’s callback object can remotely
invoke it.
The simple example below shows how the HelloServer
invokes a method implemented by the HelloClient via the
client’s callback object.
This example also uses the older ImplBase software as
there are not many new examples of callback around at
the moment. In order to use it you need to run the idlj
thus:
idlj -fall -oldImplBase Hello.idl
 The IDL file: Hello.idl
this interface will
be implemented by
the client
module HelloApp {
interface HelloCallback {
void callback(in string message);
};
interface Hello {
string sayHello(in HelloCallback objRef,
in string message);
};
};
Topic8.doc
same interface as before
except for the method
sayHello which now
takes in a callback object as
argument
Page 37
ICT337 Advanced Software Development
Murdoch University
Topic 8
 The Server: HelloServer.java
import
import
import
import
HelloApp.*;
org.omg.CosNaming.*;
org.omg.CosNaming.NamingContextPackage.*;
org.omg.CORBA.*;
we have moved the
HelloImpl class
inside
HelloServer.java
in this version
class HelloImpl extends _HelloImplBase {
public String sayHello(HelloCallback callobj, String msg) {
callobj.callback(msg);
return "\nHello world !!\n";
Before returning the string
}
“Hello world!!” to the
}
client, the server calls the
public class HelloServer {
public static void main(String args[]) {
try {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// create Impl and register it with the ORB
Hello helloRef = new HelloImpl();
orb.connect(helloRef);
// get the root naming context
Topic8.doc
Page 38
method callback
(implemented by the client)
via the callback object
callobj passed to the
server by the client
ICT337 Advanced Software Development
Murdoch University
Topic 8
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// bind the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
// wait for invocations from clients
java.lang.Object sync = new java.lang.Object();
synchronized (sync) {
sync.wait();
}
} catch (Exception e) {
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
}
}
Topic8.doc
Page 39
ICT337 Advanced Software Development
Murdoch University

Topic 8
The Client: HelloClient.java
import
import
import
import
import
HelloApp.Hello;
HelloApp.HelloHelper;
HelloApp._HelloCallbackImplBase;
org.omg.CosNaming.*;
org.omg.CORBA.*;
class HelloCallbackClient extends _HelloCallbackImplBase {
public void callback(String notification) {
System.out.println(”The callback method implemented by the client...”);
System.out.println(”The message is...”);
System.out.println(notification);
}
}
public class HelloClient {
public static void main(String args[]) {
try {
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
Topic8.doc
Page 40
ICT337 Advanced Software Development
Murdoch University
Topic 8
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// resolve the Object Reference in Naming
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
HelloCallbackClient helloCallbackRef =
new HelloCallbackClient();
orb.connect(helloCallbackRef);
connect the callback object
to the ORB
// call the Hello server object and print results
String hello = helloRef.sayHello(helloCallbackRef, "\ntesting..\n");
System.out.println(hello);
} catch (Exception e) {
System.out.println("ERROR : " + e) ;
e.printStackTrace(System.out);
}
}
}
Topic8.doc
Page 41
pass the callback
object as an argument
to the server method
ICT337 Advanced Software Development
Murdoch University
Topic 8
In general, servers invoke callbacks whenever they have
something urgent to tell the clients. Callbacks from servers
will soon magically pop up inside your applets or Java
client applications. We’re moving to a brave new world
where every client is also a server.
(extracted from Orfali & Harkey, “Client/Server
Programming with Java and CORBA, 2nd ed, Wiley 1998)
Using CORBA, one can easily implement a 2-tier fat client
system, if desired.
Images sent from client to server (CORBA Example 5)
See the ImageToServer folder.
Topic8.doc
Page 42
ICT337 Advanced Software Development
Murdoch University
Topic 8
Static Invocation Interface (SII) vs Dynamic Invocation
Interface (DII)
A client has 2 choices available to make an invocation
request on a server:
(a) use the static stubs generated by the IDL compiler,
(this is called the static invocation interface or SII)
or
(b) manually create an invocation request
programmatically (this is called dynamic invocation
interface or DII)
All the examples above use the static invocation interface
(or SII).
A client uses the DII API to create and send an execution
request directly to the server-side ORB without the
assistance of a stub. The code using the DII API looks
similar to that generated for the stub; the difference is
additional flexibility of programmatic control over the API
instead of the hard-coded instructions found in the stub.
On the other hand, a server can also process the request in
one of two ways:
(a) the static skeleton generated by the IDL compiler
can process the incoming request, or
(b) the servant (the object implementation under the
control of an object adapter) can process the request
manually (using DII)
Topic8.doc
Page 43
ICT337 Advanced Software Development
Murdoch University
Topic 8
Client and server can use DII or SII independently of each
other.
The Interface Repository (IR) contains description
information about distributed objects. Such information
includes the modules available, the interface defined within
the modules, the names of methods defined within the
interface, argument types and return types of the methods
and any exception raised.
A client can discover this information about an object by
retrieving metadata from the Interface Repository. We can
think of the Interface Repository (and the API to access it)
as a distributed version of the Java reflection mechanism.
(example: see the SystemClock client program in Fig 27.1,
pages 1512 – 1513 of textbook. Compare this program
with that in Fig 26.5, pages 1449 – 1451)
See also the servlet-CORBA-JDBC folder for an example
that combines CORBA with a servlet and the access of a
mdb database file via JDBC.
Topic8.doc
Page 44
ICT337 Advanced Software Development
Murdoch University
Topic 8
RMI vs CORBA
RMI:
 is suitable for small distributed applications in which
scalability, architecture, heterogeneity, and
extensibility are not major concerns
 is inappropriate for system architectures that require
container services, load balancing or other framework
functionality without custom development
CORBA:
 is preferred for developing full range of distributed
systems (because of its implementation concepts, e.g.
OMA – Object Management Architecture)
 has better scalability
 enables interoperability between systems written in
different languages and different operating systems
and hardware platforms.
Topic8.doc
Page 45
ICT337 Advanced Software Development
Murdoch University
Topic 8
RMI-IIOP
Sun and IBM have jointly implemented RMI-over-IIOP
(in short, RMI-IIOP) to replace RMI’s underlying
communication protocol JRMP. A few organisations
working with Suna nd IBM also specified a reverse
mapping of Java-to-IDL to allow the RMI compiler (i.e.
rmic) to output IDL, stubs and skeletons needed by a
server to accept method invocations and a client to make
method invocations.
Topic8.doc
Page 46
ICT337 Advanced Software Development
Murdoch University
Topic 8
Summary
The client/server concept in CORBA is very similar to that
in RMI. In addition, CORBA has a number of advantages
over RMI: (1) CORBA supports multilingual object
invocation; (2) the interface (specified in an IDL file) and
implementation of server code are well decoupled; (3)
CORBA supports callbacks.
CORBA can be combined with servlets/JSPs in a multitier
system. eg. a servlet can be a CORBA client requesting
methods to be invoked on a CORBA server and then
incorporate the results into an HTML document, which is
then passed back to web browser on the user (client)
machine.
A CORBA client can also request a CORBA server to
make SQL queries to a database. This can either be a 3-tier
(preferred, as database is not exposed to clients) or a 2-tier
system.
Useful web site
For complete information on CORBA, check the web site
http://www.omg.org
Advanced topics on CORBA
See Brose et al, “Java Programming with CORBA”, Wiley
2001.
Topic8.doc
Page 47
ICT337 Advanced Software Development
Murdoch University
Topic 8
Further reading:
(Textbook CD) “Advanced Java 2 Platform – How to
Program” by Deitel, Deitel, Santry, Chapter 26, sections
26.1 – 26.7.
(Textbook CD) “Advanced Java 2 Platform – How to
Program” by Deitel, Deitel, Santry, Chapter 27, sections
27.1 – 27.2 (pages 1509-1510); sections 27.6 (pages 1528 –
1530).
Topic8.doc
Page 48
ICT337 Advanced Software Development
Murdoch University
Topic 8
Objectives
At the end of this topic, you should be able to
 give a description of CORBA and list the benefits of using
CORBA ORBs
 give a description of Java IDL
 list the similarities and differences between RMI and
CORBA and the advantages of using CORBA over RMI.
 write a simple IDL module.
 list all the IDL parameter types and give a description of
each parameter type.
 explain what is meant by callbacks and illustrate your
explanation with a diagram
 incorporate your knowledge on servlets, JDBC, and CORBA
in the software development of a multitier system.
Topic8.doc
Page 49