Borland Visibroker
Borland Visibroker
==================
LM
- Borland Visibroker for C++
TechRx
- Borland Visibroker
Training
========
** http://java.sun.com/developer/onlineTraining/corba/corba.html
Imp Points :
1. Interfaces
2. Orb functions
3. Corba services
4. Object References and Requests
5. Exceptions
6.
7. Server Side
8. Object Adapters
* CORBA -- Common Object Request Broker Architecture
* It allows a distributed, heterogeneous collection of objects to interoperate.
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.
A client holds an object reference to a distributed object. The object
reference is typed by an interface. The Object Request Broker, or ORB, delivers
the request to the object and returns any results to the client.
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
=====
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
Java 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."
1. Object life cycle: Defines how CORBA objects are created, removed, moved, and copied
2. Naming: Defines how CORBA objects can have friendly symbolic names
3. Events: Decouples the communication between distributed objects
4. Relationships: Provides arbitrary typed n-ary relationships between CORBA objects
5. Externalization: Coordinates the transformation of CORBA objects to and from external media
6. Transactions: Coordinates atomic access to CORBA objects
7. Concurrency Control: Provides a locking service for CORBA objects in order to ensure serializable access
8. Property: Supports the association of name-value pairs with CORBA objects
9. Trader: Supports the finding of CORBA objects based on properties describing the service offered by the object
10. Query: Supports queries on objects
IDL
===
* Module
* Interface
* Exceptions
* Methods: Method params are marked in, out or inout
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.
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.
// Client Code
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 Interfaces can build on top of each other.
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.
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.
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.
IDL Java C++
---- ----- -----
module package namespace
interface interface abstract class
operation method member function
attribute pair of methods pair of functions
exception exception exception
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.
Exceptions
----------
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).
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;
}
}
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.
Server Side
============
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.
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:
1. 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.
2. Unshared server: Only one object is active in the server. The server exits
when the client that caused its activation exits.
3. Server-per-method: Each request results in the creation of a server. The
server exits when the method completes.
4. 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
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.
==================
LM
- Borland Visibroker for C++
TechRx
- Borland Visibroker
Training
========
** http://java.sun.com/developer/onlineTraining/corba/corba.html
Imp Points :
1. Interfaces
2. Orb functions
3. Corba services
4. Object References and Requests
5. Exceptions
6.
7. Server Side
8. Object Adapters
* CORBA -- Common Object Request Broker Architecture
* It allows a distributed, heterogeneous collection of objects to interoperate.
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.
A client holds an object reference to a distributed object. The object
reference is typed by an interface. The Object Request Broker, or ORB, delivers
the request to the object and returns any results to the client.
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
=====
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
Java 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."
1. Object life cycle: Defines how CORBA objects are created, removed, moved, and copied
2. Naming: Defines how CORBA objects can have friendly symbolic names
3. Events: Decouples the communication between distributed objects
4. Relationships: Provides arbitrary typed n-ary relationships between CORBA objects
5. Externalization: Coordinates the transformation of CORBA objects to and from external media
6. Transactions: Coordinates atomic access to CORBA objects
7. Concurrency Control: Provides a locking service for CORBA objects in order to ensure serializable access
8. Property: Supports the association of name-value pairs with CORBA objects
9. Trader: Supports the finding of CORBA objects based on properties describing the service offered by the object
10. Query: Supports queries on objects
IDL
===
* Module
* Interface
* Exceptions
* Methods: Method params are marked in, out or inout
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.
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.
// Client Code
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 Interfaces can build on top of each other.
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.
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.
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.
IDL Java C++
---- ----- -----
module package namespace
interface interface abstract class
operation method member function
attribute pair of methods pair of functions
exception exception exception
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.
Exceptions
----------
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).
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;
}
}
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.
Server Side
============
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.
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:
1. 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.
2. Unshared server: Only one object is active in the server. The server exits
when the client that caused its activation exits.
3. Server-per-method: Each request results in the creation of a server. The
server exits when the method completes.
4. 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
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.
