Introduction to CORBA
Short Course
By jGuru.com, (Formerly known as MageLang Institute)
[About This Course| Magercises]This short course will teach you how to use CORBA as found in the JavaTM 2 platform.
Course Outline
Distributed Applications
CORBA products provide a framework for the development and execution of distributed applications. But why would one want to develop a distributed application in the first place? As you will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is no choice; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons:
- The data used by the application are distributed
- The computation is distributed
- The users of the application are distributed
Data are Distributed
Some applications must execute on multiple computers because the data that the application must access exist on multiple computers for administrative and ownership reasons. The owner may permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-located and must exist on multiple heterogeneous systems for historical reasons.
Computation is Distributed
Some applications execute on multiple computers in order to take advantage of multiple processors computing in parallel to solve some problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications can take advantage of the scalability and heterogeneity of the distributed system.
Users are Distributed
Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed application on his or her computer, and shared objects, typically execute on one or more servers. A typical architecture for this kind of application is illustrated below.
Prior to designing a distributed application, it is essential to understand some of the fundamental realities of the distributed system on which it will execute.
Fundamental Realities of Distributed Systems
Distributed application developers must address a number of issues that can be taken for granted in a local program where all logic executes in the same operating system process. The following table summarizes some of the basic differences between objects that are co-located in the same process, and objects that interact across process or machine boundaries.
| Co-located | Distributed | |
|---|---|---|
| Communication | Fast | Slow |
| Failures | Objects fail together | Objects fail separately Network can partition |
| Concurrent access | Only with multiple threads | Yes |
| Secure | Yes | No |
The communication between objects in the same process is orders of magnitude faster than communication between objects on different machines. The implication of this is that you should avoid designing distributed applications in which two or more distributed objects have very tight interactions. If they do have tight interactions, they should be co-located.
When two objects are co-located, they fail together; if the process in which they execute fails, both objects fail. The designer of the objects need not be concerned with the behavior of the application if one of the objects is available and the other one is not. But if two objects are distributed across process boundaries, the objects can fail independently. In this case, the designer of the objects must be concerned with each of the object's behavior in the event the other object has failed. Similarly, in a distributed system the network can partition and both objects can execute independently assuming the other has failed.
The default mode for most local programs is to operate with a single thread of control. Single threaded programming is easy. Objects are accessed in a well-defined sequential order according to the program's algorithms, and you need not be concerned with concurrent access.
If you decide to introduce multiple threads of control within a local program, you must consider the possible orderings of access to objects and use synchronization mechanisms to control concurrent access to shared objects. But at least you have a choice of introducing multiple threads of control. In a distributed application, there are necessarily multiple threads of control. Each distributed object is operating in a different thread of control. A distributed object may have multiple concurrent clients. As the developer of the object and the developer of the clients, you must consider this concurrent access to objects and use the necessary synchronization mechanisms.
When two objects are co-located in the same process, you need not be concerned about security. When the objects are on different machines, you need to use security mechanisms to authenticate the identity of the other object.
Distributed Object Systems
Distributed object systems are distributed systems in which all entities are modeled as objects. Distributed object systems are a popular paradigm for object-oriented distributed applications. Since the application is modeled as a set of cooperating objects, it maps very naturally to the services of the distributed system.
In spite of the natural mapping from object-oriented modeling to distributed object systems, do not forget the realities of distributed systems described above. Process boundaries really do matter and they will impact your design.
That said, the next section of this course discusses the CORBA standard for distributed object systems.
What is CORBA?
CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate.
The OMG
The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers.
CORBA Architecture
CORBA defines an architecture for distributed objects. The basic CORBA paradigm is that of a request for services of a distributed object. Everything else defined by the OMG is in terms of this basic paradigm.
The services that an object provides are given by its interface. Interfaces are defined in OMG's Interface Definition Language (IDL). Distributed objects are identified by object references, which are typed by IDL interfaces.
The figure below graphically
depicts a request. A client holds
an object reference to a distributed object. The object reference
is typed by an interface. In the figure below the object reference
is typed by the Rabbit interface. The Object Request Broker,
or ORB, delivers the request to the object and returns any results
to the client. In the figure, a jump request returns an object reference
typed by the AnotherObject interface.
The ORB
The ORB is the distributed service that implements the request to the remote object. It locates the remote object on the network, communicates the request to the object, waits for the results and when available communicates those results back to the client.
The ORB implements location transparency. Exactly the same request mechanism is used by the client and the CORBA object regardless of where the object is located. It might be in the same process with the client, down the hall or across the planet. The client cannot tell the difference.
The ORB implements programming language independence for the request. The client issuing the request can be written in a different programming language from the implementation of the CORBA object. The ORB does the necessary translation between programming languages. Language bindings are defined for all popular programming languages.
CORBA as a Standard for Distributed Objects
One of the goals of the CORBA specification is that clients and object implementations are portable. The CORBA specification defines an application programmer's interface (API) for clients of a distributed object as well as an API for the implementation of a CORBA object. This means that code written for one vendor's CORBA product could, with a minimum of effort, be rewritten to work with a different vendor's product. However, the reality of CORBA products on the market today is that CORBA clients are portable but object implementations need some rework to port from one CORBA product to another.
CORBA 2.0 added interoperability as a goal in the specification. In particular, CORBA 2.0 defines a network protocol, called IIOP (Internet Inter-ORB Protocol), that allows clients using a CORBA product from any vendor to communicate with objects using a CORBA product from any other vendor. IIOP works across the Internet, or more precisely, across any TCP/IP implementation.
Interoperability is more important in a distributed system than portability. IIOP is used in other systems that do not even attempt to provide the CORBA API. In particular, IIOP is used as the transport protocol for a version of JavaTM RMI (so called "RMI over IIOP"). Since EJB is defined in terms of RMI, it too can use IIOP. Various application servers available on the market use IIOP but do not expose the entire CORBA API. Because they all use IIOP, programs written to these different API's can interoperate with each other and with programs written to the CORBA API.
CORBA Services
Another important part of the CORBA standard is the definition of a set of distributed services to support the integration and interoperation of distributed objects. As depicted in the graphic below, the services, known as CORBA Services or COS, are defined on top of the ORB. That is, they are defined as standard CORBA objects with IDL interfaces, sometimes referred to as "Object Services."
There are several CORBA services. The popular ones are described in detail in another module of this course. Below is a brief description of each:
| Service | Description |
|---|---|
| Object life cycle | Defines how CORBA objects are created, removed, moved, and copied |
| Naming | Defines how CORBA objects can have friendly symbolic names |
| Events | Decouples the communication between distributed objects |
| Relationships | Provides arbitrary typed n-ary relationships between CORBA objects |
| Externalization | Coordinates the transformation of CORBA objects to and from external media |
| Transactions | Coordinates atomic access to CORBA objects |
| Concurrency Control | Provides a locking service for CORBA objects in order to ensure serializable access |
| Property | Supports the association of name-value pairs with CORBA objects |
| Trader | Supports the finding of CORBA objects based on properties describing the service offered by the object |
| Query | Supports queries on objects |
CORBA Products
CORBA is a specification; it is a guide for implementing products. Several vendors provide CORBA products for various programming languages. The CORBA products that support the Java programming language include:
| ORB | Description |
|---|---|
| The Java 2 ORB | The Java 2 ORB comes with Sun's Java 2 SDK. It is missing several features. |
| VisiBroker for Java | A popular Java ORB from Inprise Corporation. VisiBroker is also embedded in other products. For example, it is the ORB that is embedded in the Netscape Communicator browser. |
| OrbixWeb | A popular Java ORB from Iona Technologies. |
| WebSphere | A popular application server with an ORB from IBM. |
| Netscape Communicator | Netscape browsers have a version of VisiBroker embedded in them. Applets can issue request on CORBA objects without downloading ORB classes into the browser. They are already there. |
| Various free or shareware ORBs | CORBA implementations for various languages are available for download on the web from various sources. |
Providing detailed information about all of these products is beyond the scope of this introductory course. This course will just use examples from both Sun's Java 2 ORB and Inprise's VisiBroker 3.x for Java products.
The Stock Application
The stock trading application is a distributed application that illustrates the Java programming language and CORBA. In this introductory module only a small simple subset of the application is used. Feel free to expand upon the application to enhance it once you are more comfortable with CORBA.
The stock application allows multiple users to watch the activity of stocks. The user is presented with a list of available stocks identified by their stock symbols. The user can select a stock and then press the "view" button.
Selecting the "view" button results in a report about the stock, indicating the name of the company, the stock symbol, the current price, the last time it was updated, the trading volume, and a graph that shows the stock price over some interval. This report is automatically updated as new stock data becomes available.
The stock report also lets the user set an alarm by pressing the "Alarm" button. The alarm can be set to activate when the price of the stock falls below a certain price or when it exceeds a certain price.
When the price of the stock satisfies the alarm's condition, it activates and the user is notified.
Later the application could be extended to allow users to buy and sell stocks.
Some Objects in the Stock Application
From the above description, you can easily identify the following distributed objects in the application.
| Stock | A distributed object that represents a particular stock. |
| StockPresentation | A distributed object in the GUI that presents the stock data to the user for a particular stock. |
| Alarm | A distributed object that represents the alarm set by the user. |
| AlarmPresentation | A distributed object in the GUI that presents the alarm going off to the user. |
The Stock object is now used to illustrate the CORBA distributed object model.
Implementing a CORBA Client
This section covers what you need to know to use CORBA objects from the Java programming language. It examines OMG IDL interfaces, the Java programming language binding for IDL interfaces, object references, and requests, how to obtain object references, and how, as a client, to create distributed objects. After reading this section and completing the exercises, you should be able to write a client using the Java programming language. Again, the stock example is used to illustrate the client's model of CORBA.
CORBA Objects are Described by IDL Interfaces
The OMG Interface Definition Language IDL supports the specification of object interfaces. An object interface indicates the operations the object supports, but not how they are implemented. That is, in IDL there is no way to declare object state and algorithms. The implementation of a CORBA object is provided in a standard programming language, such as the Java programming language or C++. An interface specifies the contract between code using the object and the code implementing the object. Clients only depend on the interface.
IDL interfaces are programming language neutral. IDL defines language bindings for many different programming languages. This allows an object implementor to choose the appropriate programming language for the object. Similarly, it allows the developer of the client to choose the appropriate and possibly different programming language for the client. Currently, the OMG has standardized on language bindings for the C, C++, Java, Ada, COBOL, Smalltalk, Objective C, and Lisp programming languages.
So by using OMG IDL, the following can be described without regards to any particular programming language:
- Modularized object interfaces
- Operations and attributes that an object supports
- Exceptions raised by an operation
- Data types of an operation return value, its parameters, and an object's attributes
The IDL data types are:
- Basic data types (
long,short,string,float...) - Constructed data types (
struct,union,enum,sequence) - Typed object references
- The
anytype, a dynamically typed value
Again, IDL says nothing about object implementations. Here's the IDL interface for the example stock objects:
module StockObjects {
struct Quote {
string symbol;
long at_time;
double price;
long volume;
};
exception Unknown{};
interface Stock {
// Returns the current stock quote.
Quote get_quote() raises(Unknown);
// Sets the current stock quote.
void set_quote(in Quote stock_quote);
// Provides the stock description,
// e.g. company name.
readonly attribute string description;
};
interface StockFactory {
Stock create_stock(
in string symbol,
in string description
);
};
};
Note that the above example defines an IDL module named StockObjects,
which contains the:
- Data structure
Quote - Exception
Unknown - Interface
Stock - Interface
StockFactory
The module defines a scope for these names. Within the module,
a data structure Quote and an exception Unknown
are defined and then used in the Stock interface. The Stock
interface is used in the definition of the StockFactory
interface. Also note that the parameters to operations are tagged
with the keywords in, out, or inout. The in
keyword indicates the data are passed from the client to the object.
The out keyword indicates that the data are returned from
the object to the client, and inout indicates that the data
are passed from the client to the object and then returned to
the client.
IDL declarations are compiled with an IDL compiler and converted to their associated representations in the target programming languages according to the standard language binding. (This course uses the Java language binding in all of the examples. Later you will see the Java binding in more depth.)
Object References and Requests
Clients issue a request on a CORBA object using an object
reference. An object reference identifies the distributed
object that will receive the request. Here's a Java programming language code
fragment that obtains a Stock object reference and then
it uses it to obtain the current price of the stock. Note that
the code fragment does not directly use CORBA types; instead it
uses the Java types that have been produced by the IDL to Java
compiler.
Stock theStock = ...
try {
Quote current_quote =
theStock.get_quote();
} catch (Throwable e) {
}
Object references can be passed around the distributed object
system, i.e. as parameters to operations and returned as results
of requests. For example, notice that the StockFactory
interface defines a create() operation that returns an instance
of a Stock. Here's a Java client code fragment that issues
a request on the factory object and receives the resulting stock
object reference.
StockFactory factory = ...
Stock theStock = ...
try {
theStock = factory.create(
"GII",
"Global Industries Inc.");
} catch (Throwable e) {
}
Note that issuing a request on a CORBA object is not all that different from issuing a request on a Java object in a local program. The main difference is that the CORBA objects can be anywhere. The CORBA system provides location transparency, which implies that the client cannot tell if the request is to an object in the same process, on the same machine, down the hall, or across the planet.
Another difference from a local Java object is that the life time of the CORBA object is not tied to the process in which the client executes, nor to the process in which the CORBA object executes. Object references persist; they can be saved as a string and recreated from a string.
The following Java code converts the Stock object reference
to a string:
String stockString =
orb.object_to_string(theStock);
The string can be stored or communicated outside of the distributed object system. Any client can convert the string back to an object reference and issue a request on the distributed object.
This Java code converts the string back to a Stock
object reference:
org.omg.CORBA.Object obj =
orb.string_to_object(stockString);
Stock theStock = StockHelper.narrow(obj);
Note that the resulting type of the string_to_object() method is
Object, not Stock. The second line narrows
the type of the object reference from Object to Stock.
IDL supports a hierarchy of interfaces; the narrow() method call
is an operation on the hierarchy.
IDL Type System
IDL interfaces can be defined in terms of other IDL interfaces.
You previously saw a Stock interface that represents the
basic behavior of a stock object.
Consider another IDL module:
module ReportingObjects {
exception EventChannelFailure{};
interface Reporting {
// Receive events in push mode
CosEventComm::PushSupplier push_events(
in CosEventComm::PushConsumer consumer)
raises(EventChannelFailure);
// Receive events in pull mode
CosEventComm::PullSupplier pull_events(
in CosEventComm::PullConsumer consumer)
raises(EventChannelFailure);
};
};
The Reporting interface supports the registration of
interest in events.
(Don't worry about the details of using the CORBA Event Service.)
Given the definition of the Stock interface and a Reporting
interface, it is now possible to define a new ReportingStock
interface in terms of Reporting and Stock.
interface ReportingStock: Reporting, Stock {
};
A ReportingStock supports all of the operations and
attributes defined by the Reporting interface as well as
all of those defined by the Stock interface. The ReportingStock
interface inherits the Stock interface and the Reporting
interface. Graphically this is represented as:
All CORBA interfaces implicitly inherit the Object interface.
They all support the operations defined for Object. Inheritance
of Object is implicit; there is no need to declare it.
Object references are typed by IDL interfaces. In a Java program
you could type an object reference to be a ReportingStock.
ReportingStock theReportingStock;
Clients can pass this object reference to an operation expecting
a supertype. For example assume there is an EventManager
interface that has a register operation that takes an object
reference typed by the Reporting interface.
interface EventManager {
:
void register(in Reporting event_supplier);
:
};
The following is a legal request because a ReportingStock
is a Reporting.
EventManager manager = ... ReportingStock theReportingStock = ... manager->register(theReportingStock); // ok
However, the following is not a legal request because a Stock
is not a Reporting:
EventManager manager = ... Stock theStock = ... manager->register(theStock); // type error
IDL Type Operations
Given that IDL interfaces can be arranged in a hierarchy, a
small number of operations are defined on that hierarchy. The
narrow() operation casts an object reference to a more specific
type:
org.omg.CORBA.Object obj = ... Stock theStock = StockHelper.narrow(obj);
The is_a() operation, determines if an object reference
supports a particular interface:
if (obj._is_a(StockHelper.id()) ...
The id() operation defined on the helper class returns
a repository id for the interface. The repository id is
a string representing the interface. For the stock example, the
repository id is:
IDL:StockObjects/Stock:1.0
Finally, it is possible to widen an object reference, that is cast it to a less specific interface:
Stock theStock = theReportingStock;
There are no special operations to widen an object reference. It is accomplished exactly as in the Java programming language.
Request Type Checking
The IDL compiler for Java programming language generates client-side stubs, which represent the CORBA object locally in the Java programming language. The generated code also represents in the Java programming language all of the IDL interfaces and data types used to issue requests. The client code thus depends on the generated Java code.
As you previously saw, passing an object reference typed by
the Stock interface to the event manager would be illegal
because the Stock interface does not inherit the Reporting
interface. The Java compiler, not the IDL compiler, would catch
this error at compile time.
IDL to Java Binding
The Java binding for IDL maps the various IDL constructs to corresponding Java constructs. The following table shows how the IDL constructs are represented in the Java programming language. For comparison, the C++ binding is also shown.
| IDL | Java | C++ |
|---|---|---|
| module | package | namespace |
| interface | interface | abstract class |
| operation | method | member function |
| attribute | pair of methods | pair of functions |
| exception | exception | exception |
Each of the IDL data types are represented in the Java programming language as follows:
| IDL Type | Java Type |
|---|---|
boolean |
boolean |
char / wchar |
char |
octet |
byte |
short / unsigned short |
short |
long / unsigned long |
int |
long long / unsigned long long |
long |
float |
float |
double |
double |
string / wstring |
String |
When discussing data type mapping, one term you run across frequently is marshaling. Marshaling is the conversion of a language-specific data structure into the CORBA IIOP streaming format. IIOP data can then be transmitted over a network to its destination, where it is then unmarshaled from IIOP back into a language-dependent data structure.
IDL to Java Compiler
CORBA products provide an IDL compiler that converts IDL into
the Java programming language. The IDL compiler available for the Java 2 SDK is
called idltojava. The IDL compiler that comes with VisiBroker for Java
is called idl2java.
For the stock example, the command "idltojava Stock.idl"
generates the files listed below. (The VisiBroker ORB generates
the same files with the exception that the stub file is called
_st_Stock.java, rather than _StockStub.java.)
Stock.java |
The IDL interface represented as a Java interface |
StockHelper.java |
Implements the type operations for the interface |
StockHolder.java |
Used for out and inout
parameters |
_StockStub.java |
Implements a local object representing the remote CORBA object. This object forwards all requests to the remote object. The client does not use this class directly. |
The developer compiles the IDL using the IDL compiler and then compiles the generated code using the Java compiler. The compiled code must be on the classpath of the running Java program.
Obtaining Object References
You may have noticed that there are three fundamental mechanisms in which a piece of code can obtain an object reference:
- It can be can be passed to it as a parameter
- It can be returned as the result of issuing a request
- It can be obtained by converting a string into an object reference
These fundamental mechanisms are supported by the ORB. Using these mechanisms, it is possible to define higher level services for locating objects in the distributed object system.
The Client's Model of Object Creation
You may decide to export the ability to create an object to the distributed object system. You can accomplish this by defining a factory for the object. Factories are simply distributed objects that create other distributed objects.
There is nothing special about a factory. It is just another distributed object: It has an IDL interface, it is implemented in some programming language, and clients issue standard CORBA requests on factory objects.
There is no standard interface for a factory. Recall in the
StockObjects example, the factory interface is:
interface StockFactory {
Stock create_stock(
in string stock_symbol,
in string stock_description);
};
To create a stock object, a client simply issues a request on the factory.
Another object implementor could define an object factory differently.
Exceptions
As you have seen in the stock example, CORBA has a concept
of exceptions that is very similar to that of the Java programming language;
naturally, CORBA exceptions are mapped to Java exceptions. When
you issue a CORBA request, you must use the Java programming language's try
and catch keywords.
There are two types of CORBA exceptions, System Exceptions
and User Exceptions. System Exceptions are thrown
when something goes wrong with the system--for instance, if
you request a method that doesn't exist on the server, if there's
a communication problem, or if the ORB hasn't been initialized
correctly. The Java class SystemException extends RuntimeException,
so the compiler won't complain if you forget to catch them. You
need to explicitly wrap your CORBA calls in try...catch
blocks in order to recover gracefully from System Exceptions.
CORBA System Exceptions can contain "minor codes" which may provide additional information about what went wrong. Unfortunately, these are vendor-specific, so you need to tailor your error recovery routines to the ORB you're using.
User Exceptions are generated if something goes wrong
inside the execution of the remote method itself. These are declared
inside the IDL definition for the object, and are automatically
generated by the idltojava compiler. In the stock example,
Unknown is a user exception.
Since User Exceptions are subclasses of java.lang.Exception,
the compiler will complain if you forget to trap them (and this
is as it should be).
Object Implementations
NOTE: the previous section discussed the client's view of CORBA, that is, how a JavaTM client issues a request on a CORBA object. The client's view is standard across most CORBA products. Basically, the standard worked and there are only minor differences. Unfortunately, the same is not the case for the implementation view of CORBA. As such, some of the details given here might not match a particular CORBA product. Notes on different CORBA products appear as appendices.
This section describes what you need to know to implement a simple CORBA object in the Java programming language. It examines the Java server-side language binding for IDL, implementing objects and servers, implementation packaging issues, and CORBA object adaptors. After completing this section, you should be able to write a simple CORBA object and server in the Java programming language. Again, the stock example is used to illustrate the implementation model of CORBA.
CORBA object implementations are completely invisible to their clients. A client can only depend on the IDL interface. In the Java programming language, or C++, this is not the case. The user of an object declares variables by a class name; doing so makes the code depend on much more than just the interface. The client depends on the object implementation programming language, the name of the class, the implementation class hierarchy, and, in C++, even the object layout.
The complete encapsulation for CORBA objects means the object implementor has much more freedom. Object implementations can be provided in a number of supported programming languages. This is not necessarily the same one the clients are written in. (Of course, here everything is in the Java programming language, but CORBA does notrequire this.)
The same interface can be implemented in multiple ways. There
is no limit. In the stock example, the following are possible
implementations of the Stock interface:
- A stock implementation class written in the Java programming language that obtains values from a commercial feed
- A stock implementation class written in C++ that accesses a database on the Internet
- A stock implementation written in Smalltalk that guesses stock prices
Providing an Implementation
Recall that given an IDL file, the IDL compiler generates various files for a CORBA client. In addition to the files generated for a client, it also generates a skeleton class for the object implementation. A skeleton is the entry point into the distributed object. It unmarshals the incoming data, calls the method implementing the operation being requested, and returns the marshaled results. The object developer need only compile the skeleton and not be concerned with the insides of it. The object developer can focus on providing the implementation of the IDL interface.
To implement a CORBA object in the Java programming language, the developer
simply implements a Java class that extends the generated skeleton
class and provides a method for each operation in the interface.
In the example, the IDL compiler generates the skeleton class
_StockImplBase for the Stock interface. A possible
implementation of the Stock interface is:
public class StockImpl extends
StockObjects._StockImplBase {
private Quote _quote=null;
private String _description=null;
public StockImpl(
String name, String description) {
super();
_description = description;
}
public Quote get_quote() throws Unknown {
if (_quote==null) throw new Unknown();
return _quote;
}
public void set_quote(Quote quote) {
_quote = quote;
}
public String description() {
return _description;
}
}
Interface versus Implementation Hierarchies
Notice that there are two separate hierarchies: an interface
hierarchy and an implementation hierarchy. Recall that the interface
hierarchy for the example of a ReportingStock is:
In IDL this is represented as:
interface ReportingStock: Reporting, Stock {
};
Now suppose there is an implementation of a ReportingStock,
named ReportingStockImpl, that inherits the IDL generated
skeletons _ReportingStockImplBase, delegates some of its
stock methods to StockImpl, and implements the Reporting
operations directly. Graphically:
In the Java programming language, this class hierarchy is represented as:
class ReportingStockImpl
implements ReportingStock
extends _ReportingStockImplBase {
...
}
Since the Java programming language only supports single inheritance of
implementation classes, implementations often create an instance
of another class and delegate to it. In the above example,
the ReportingStockImpl delegates to the StockImpl
class for the implementation of some of its methods.
Other class hierarchies implementing the same interface hierarchy are possible. Furthermore, if you need to change the class hierarchy of the implementation in some way, the clients are not affected.
Implementation Type Checking
Just as type checking is done at the client for the request to a distributed object, type checking is also done for the object implementation.
The IDL compiler for the Java programming language generates object skeletons and Java code to represent all of the IDL interfaces and data types used in the interface definition. The implementation code thus depends on the generated Java code.
If there are any type errors in the object implementation,
the Java compiler, not the IDL compiler, catches the errors at
compile time. Thus, in the example, suppose the developer erroneously
implemented the get_quote() operation to return a double
instead of the structure that is declared in the IDL:
Quote StockImpl.get_quote() {
double price = ...;
return price;
}
The Java compiler would detect this error at compile time.
Implementing a Server Using the Java 2 ORB
You previously saw how to provide an implementation of a CORBA object in the Java programming language. The remaining task is to define a server that when run makes the services of its objects available to clients. A server that will run with the Java 2 ORB needs to do the following:
- Define a main method
- Initialize the ORB
- Instantiate at least one object
- Connect each object to the orb
- Wait for requests
The server must instantiate at least one object since objects are the only way to offer services in CORBA systems.
Here's an implementation of the stock objects server. This code depends on the Java 2 ORB.
public class theServer {
public static void main(String[] args) {
try {
// Initialize the ORB.
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init(args,null);
// Create a stock object.
StockImpl theStock =
new StockImpl("GII",
"Global Industries Inc.");
// Let the ORB know about the object
orb.connect(theStock);
// Write stringified object
//reference to a file
PrintWriter out =
new PrintWriter(new BufferedWriter(
new FileWriter(args[0])));
out.println(
orb.object_to_string(theStock) );
out.close();
// wait for invocations from clients
java.lang.Object sync =
new java.lang.Object();
synchronized (sync) {
sync.wait();
}
} catch (Exception e) {
System.err.println(
"Stock server error: " + e);
e.printStackTrace(System.out);
}
}
}
Notice that the server does a new on the StockImpl
class implementing the Stock interface and then passes
it to the ORB using the connect() call, indicating that
the object is ready to accept requests. Finally, the server waits
for requests.
Implementing a Server Using VisiBroker 3.x
You previously saw how to provide a server using the Java 2 ORB. If you are using Inprise's VisiBroker 3.x for Java ORB you need to do the following:
- Define a main method
- Initialize the ORB and the BOA (basic object adapter)
- Instantiate at least one object
- Let the BOA know that the object is ready to provide service
- Let the BOA know that the server is ready
The server must instantiate at least one object since objects are the only way to offer services in CORBA systems.
Here's an implementation of the stock objects server. This code depends on VisiBroker 3.x:.
public class theServer {
public static void main(String[] args) {
try {
// Initialize the ORB.
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init(args,null);
// Initialize the BOA.
org.omg.CORBA.BOA boa =
((com.visigenic.vbroker.orb.ORB)orb)
.BOA_init();
// Create a stock object.
StockImpl theStock =
new StockImpl("
GII","Global Industries Inc.");
// Write stringified object
//reference to a file
PrintWriter out =
new PrintWriter(new BufferedWriter(
new FileWriter(args[0])));
out.println(
orb.object_to_string(theStock) );
out.close();
// Tell the BOA that the object
//is ready to
// receive requests.
boa.obj_is_ready(theStock);
// Tell the boa that the
//server is ready. This
// call blocks.
boa.impl_is_ready();
} catch (Exception e) {
System.err.println("
Stock server error: " + e);
e.printStackTrace(System.out);
}
}
}
Notice that the server does a new on the StockImpl
class implementing the Stock interface and then passes
it to the BOA, indicating that the object is ready to accept requests.
Finally, the server calls the BOA to indicate that it is ready.
At this point, the implementation will be called when requests
arrive.
Differences Between Server Implementations
The following summarizes the differences between implementing a transient CORBA server using the Java 2 ORB and implementing a transient server using Inprise's VisiBroker 3.x:
| Java 2 ORB | VisiBroker 3.x for Java | |
|---|---|---|
| Initialization | Just initialize the ORB | Initialize both the ORB and the BOA |
| Object export | orb.connect(theStock) |
boa.obj_is_ready(theStock) |
| Indicate server ready for requests | Suspend main thread doing a wait() |
boa.impl_is_ready() |
These are the only differences for transient object servers. There are further API differences of CORBA products due to persistence and automatic activation of servers.
Packaging Object Implementations
As illustrated above, you should separate the implementations of your objects from the implementation of the server. This allows you to mix and match object implementations in a server. The object implementation does not depend on the server. The server, of course depends on the object implementations that it contains.
Another advantage of carefully isolating object implementation code from server code is portability. Most of the product-specific code exists in the server, not in the object implementation.
A good strategy is to package an object implementation with its generated stubs and skeletons as a JavaBean component. This allows the implementation to be manipulated by JavaBean design tools.
Object Adapters
The CORBA specification defines the concept of an object adapter. An object adapter is a framework for implementing CORBA objects. It provides an API that object implementations use for various low level services. According to the CORBA specification, an object adapter is responsible for the following functions:
- Generation and interpretation of object references
- Method invocation
- Security of interactions
- Object and implementation activation and deactivation
- Mapping object references to the corresponding object implementations
- Registration of implementations
The architecture supports the definition of many kinds of object adapters. The specification includes the definition of the basic object adapter (BOA). In the previous section, you saw some server code that uses the services of VisiBroker's implementation of the BOA. The BOA has been implemented in various CORBA products. Unfortunately, since the specification of the BOA was not complete, the various BOA implementations differ in some significant ways. This has compromised server portability.
To address this shortcoming, an entirely new object adapter was added, the portable object adapter (POA). Unfortunately, the POA is not yet supported in many products. In any event, the BOA and the POA are described here.
Activation on Demand by the Basic Object Adapter (BOA)
One of the main tasks of the BOA is to support on-demand object activation. When a client issues a request, the BOA determines if the object is currently running and if so, it delivers the request to the object. If the object is not running, the BOA activates the object and then delivers the request.
The BOA defines four different models for object activation:
| Shared server | Multiple active objects share the same server. The server services requests from multiple clients. The server remains active until it is deactivated or exits. |
| Unshared server | Only one object is active in the server. The server exits when the client that caused its activation exits. |
| Server-per-method | Each request results in the creation of a server. The server exits when the method completes. |
| Persistent server | The server is started by an entity other than the BOA (you, operating services, etc.). Multiple active objects share the server. |
Portable Object Adapter (POA)
According to the specification, "The intent of the POA, as its name suggests, is to provide an object adapter that can be used with multiple ORB implementations with a minimum of rewriting needed to deal with different vendors' implementations." However, most CORBA products do not yet support the POA.
The POA is also intended to allow persistent objects -- at least, from the client's perspective. That is, as far as the client is concerned, these objects are always alive, and maintain data values stored in them, even though physically, the server may have been restarted many times, or the implementation may be provided by many different object implementations.
The POA allows the object implementor a lot more control. Previously, the implementation of the object was responsible only for the code that is executed in response to method requests. Now, additionally, the implementor has more control over the object's identity, state, storage, and lifecycle.
The POA has support for many other features, including the following:
- Transparent object activation
- Multiple simultaneous object identities
- Transient objects
- Object ID namespaces
- Policies including multithreading, security, and object management
- Multiple distinct POAs in a single server with different policies and namespaces
For more detail on the POA, please see the specification.
A word on multithreading. Each POA has a threading policy that determines how that particular POA instance will deal with multiple simultaneous requests. In the single thread model, all requests are processed one at a time. The underlying object implementations can therefore be lazy and thread-unsafe. Of course, this can lead to performance problems. In the alternate ORB-controlled model, the ORB is responsible for creating and allocating threads and sending requests in to the object implementations efficiently. The programmer doesn't need to worry about thread management issues; however, the programmer definitely has to make sure the objects are all thread-safe.
Resources
Web Sites
- The OMG web site: http://www.omg.org
Documentation and Specs
- The CORBA/IIOP Specification can be obtained from the OMG web site ( http://www.omg.org/library/c2indx.html )
- Objects By Value Proposal can be obtained from the OMG FTP site: ftp://ftp.omg.org/pub/docs/orbos/98-01-18.pdf
- The VisiBroker For Java Reference is available from Inprise: http://www.inprise.com
- The VisiBroker For Java Programmers Guide is available from Inprise: http://www.inprise.com
- JDK 1.2 CORBA documentation http://java.sun.com/products/jdk/1.2/docs/guide/idl/
- The Java 2 Documentation has extensive information on JavaIDL
at the
org.omg.CORBApackage documentation and the JavaIDL Guide documentation. - Java Transactions
- JavaIDL Naming Service documentation
Books
- Orfali & Harkey, Client/Server Programming with Java and CORBA (Wiley)
- Orfali, Harkey & Edwards, Instant CORBA (Wiley)
- Vogel, Andreas and Keith Duddy, Java Programming with CORBA (Wiley)
- Perdrick et al, Programming with VisiBroker (Wiley).
Miscellaneous
If you don't have the idltojava compiler, you can
find it at Sun's
JavaIDL web site.
RMI over IIOP compiler is available at http://java.sun.com/products/rmi-iiop/.
JacORB - Free Java ORB, including POA, DII, DSI, CosNaming
OrbixWeb from Iona
WebSphere Application Server from IBM
A nice list of ORBs on a nice CORBA infomation site
About The Java 2 ORB
The Java IDL ORB that ships with the JavaTM 2 platform allows applications to run either as stand-alone Java applications or as applets within Java-enabled browsers. It uses IIOP as its native protocol.
The Sun Java ORB is fairly generic. This is good, because there
are few surprises; however, there are many advanced features of
CORBA that are missing. There is no Interface Repository (though
Java IDL clients can access an Interface Repository provided by
another Java or C++ ORB), Transaction Service, or POA, for example.
For a complete list of these unimplemented features, see the CORBA
Package JavaDoc Comments -- scroll down to find the section
near the bottom of the page describing these shortcomings.
Java IDL is structured with a "pluggable ORB" architecture,
which allows you to instantiate ORBs from other vendors from within
the Java Virtual Machine. This is accomplished through setting
environment variables, or system
properties, or at run time through the use of a Properties
or String[] object. See the CORBA
Package JavaDoc Comments for more details (scroll down
past the list of classes to find the appropriate sections).
idltojava Notes
If you don't have the idltojava compiler, you can
find it at the Java
IDL web site.
By default, idltojava tries to run a C preprocessor
on the IDL files before compiling them. Unfortunately, if you
do not have a C preprocessor installed on your system, or if idltojava
cannot find it, you will see cryptic error message:
Bad command or file name Couldn't open temporary file idltojava: fatal error: cannot preprocess input; No such file or directory
If you get this message, it means you must invoke idltojava
with the -fno-cpp option, as follows:
idltojava -fno-cpp foo.idl
System Properties
The ORB.init() method can read in its configuration
parameters from a number of different sources: from the application
parameters (the first argument to ORB.init()), from an
application-specific Properties object (the second argument
to ORB.init()), or from the System Properties (defined
on the command line by -D flags).
Quoted verbatim from the Java IDL guide:
Currently, the following configuration properties are defined for all ORB implementations:
org.omg.CORBA.ORBClass
The name of a Java class that implements the org.omg.CORBA.ORB
interface. Applets and applications do not need to supply this
property unless they must have a particular ORB implementation.
The value for the Java IDL ORB is com.sun.CORBA.iiop.ORB.
org.omg.CORBA.ORBSingletonClass
The name of a Java class that implements the org.omg.CORBA.ORB
interface. This is the object returned by a call to orb.init()
with no arguments. It is used primarily to create typecode instances
than can be shared across untrusted code (such as unsigned applets)
in a secured environment. The value for the Java IDL ORB is
com.sun.CORBA.iiop.ORB.
In addition to the standard properties listed above, Java IDL also supports the following properties:
org.omg.CORBA.ORBInitialHost
The host name of a machine running a server or daemon that
provides initial bootstrap services, such as a name service.
The default value for this property is localhost for
applications. For applets it is the applet host, equivalent to
getCodeBase().getHost().
org.omg.CORBA.ORBInitialPort
The port the initial naming service listens to. The default
value is 900.
VisiBroker 3.x
Here are some additional details for the VisiBroker 3.x implementation of CORBA. See the product documentation for more details.
VisiBroker Tools
VisiBroker for Java ships with a number of tools. Some are replacements or wrappers for the standard JavaTM compiler and interpreter. Others are specific to the VisiBroker product. The important ones are:
vbjis a wrapper forjavawhich sets some properties and adds to your classpathvbjcis a wrapper forjavacwhich sets some properties and adds to your classpathidl2javais an IDL compiler that can produce proprietary or portable stubs and skeletonsosagentlaunches the proprietary Smart Agent binding service
Using VisiBroker with Java 2
To make VisiBroker for Java 3.4 work with the Java 2 platform, a number of changes are necessary, involving both code and configuration.
The Java 2 platform ships with a standard implementation of
CORBA classes in the org.omg.CORBA.* package. These classes
are somewhat different from the CORBA classes included with VisiBroker.
The VisiBroker classes have several nonstandard extensions to
CORBA; some of these nonstandard extensions are required for
successful operation. To access these functions, you must change
your source code to cast the JavaIDL ORB to a VisiBroker ORB.
For example:
org.omg.CORBA.ORB orb =
org.omg.CORBA.ORB.init(args, null);
org.omg.CORBA.BOA boa =
((com.visigenic.vbroker.orb.ORB)orb).BOA_init(
);
This example applies to the server code.
For this cast to work, you must also guarantee that the ORB
returned by the ORB.init() call is indeed a VisiBroker
ORB, and not the standard JavaIDL ORB from Sun. For that, you
need to define two Java system properties before you launch the
JVM. These properties are automatically set if you use vbj
instead of java to launch your programs. But if you use
java, you must set these properties as follows
(where each lists the property name first and value second):
org.omg.CORBA.ORBClass-com.visigenic.vbroker.orb.ORBorg.omg.CORBA.ORBSingletonClass-com.visigenic.vbroker.orb.ORB
Portable Stubs and Skeletons
By default, VisiBroker for Java creates stub and skeleton code that is interoperable but not portable. This makes sense in the VisiBroker world, since the non-portable code is more efficient and slightly smaller. However, if your code needs to run on several different ORBs, you can use the command
idl2java -portable -no_bind Foo.idl
and the stubs and skeletons will be portable.
There are a few reasons for this. One is if you're writing an applet that will run inside a remote web browser environment, such as Netscape Communicator or the Java Plug-in. The latter uses JavaIDL; the former may be running an older version of VisiBroker.
What's the difference between portable and proprietary versions? A portable stub uses DII (Dynamic Invocation Interface) to marshal the object request; a portable skeleton uses DSI (Dynamic Skeleton Interface). The proprietary versions make direct calls (to the ORB or the implementation), and hence do not have to go through the overhead of creating and parsing the various DII and DSI objects.
Note that your code doesn't need to change--this all happens
behind the scenes with idl2java. The only difference
in the portable code is that _FooImplBase extends org.omg.CORBA.DynamicImplementation
instead of com.inprise.vbroker.CORBA.portable.Skeleton,
and that the stub class is named _portable_stub_Foo.java
instead of _st_Foo.java. (Note also that if you really
want to, you can switch stubs on the fly by using FooHelper.setProxyClass(_portable_stub_Foo.class)
-- though that would be kind of weird).
Using the BOA with VisiBroker
The VisiBroker BOA uses a slightly modified version of the standard BOA initialization sequence. For VisiBroker, follow the following boilerplate code.
// create and initialize the ORB ORB orb = ORB.init(args, null);
The VisiBroker BOA is a customized, proprietary implementation of the CORBA.BOA interface. It has several methods that are not part of the standard interface. In order to use these proprietary methods, you must cast the ORB to a VisiBroker class, as follows.
// Initialize the BOA. // Must cast to VBJ ORB for //Java 2 compatibility org.omg.CORBA.BOA boa = ((com.inprise.vbroker.CORBA.ORB)orb).BOA_init();
VisiBroker objects are usually persistent. In VisiBroker terms, this means that they are initialized with a name. This is not needed with a portable, non-VisiBroker object implementation.
// create object and register it //with the ORB Stock theStock = new StockImpl(name);
The VisiBroker BOA skips the boa.create() phase and
jumps straight to obj_is_ready().
// Export the newly created object. boa.obj_is_ready(theStock);
The impl_is_ready() method waits indefinitely.
// Wait for incoming requests boa.impl_is_ready();
Using the VisiBroker Smart Agent
VisiBroker for Java ships with its own location service, called the smart agent. The smart agent is a distributed location service. It collaborates with other smart agents running on the network to locate a suitable implementation of an object. If there is more than one implementation available; the smart agent selects one. This provides a degree of fault tolerance and load balancing. If a machine goes down, the smart agent will automatically find another implementation on another machine to service the request. The client is unaware of this.
If you create a persistent object, by passing in a name when you call its constructor, then the BOA will automatically inform the smart agent. The name you passed in the constructor will become the name it is known by on the smart agent network.
On the client side, the
proprietary Helper object defines a
method bind() that fetches an object reference for you,
bypassing the need to convert a string into an object reference.
The bind() method is not part of the standard CORBA-Java
mapping.
// "bind" (actually lookup) the //object reference Stock theStock = StockHelper.bind(orb, "GII");Return to Top of Page
About This Course
Magercises
Copyright © 1998-1999 MageLang Institute. All Rights Reserved.