In Association with Amazon.com
CORBA® For Dummies® Corrections

A correction on Events (Chapter 19)
Chapter 18 Naming Service... where are the example files? 
Exception Handling and DII (Chapter 14)
Object activation with Visibroker for Java (Ch 11) 

A correction on Events (Chapter 19) 


Chapter 19 discusses the Event Service. The description of the "Pure 100-percent pull" model of communication (page 301) is not *exactly* correct. 

What's really happening is that the event channel asks pull servers for events all the time. If they don't have an event when asked, they block inside the pull () request method until they have an event, at which point they return it. The event channel will then turn right around and ask for another event. This happens to all the pull servers, regardless of how many of them there are.

To the client, the behavior is the same as described in the book... they ask for an event, and if one is available it is given to them. If one is not, they block, waiting for the next event. If they don't want to block, they can use the try_pull() method to get an event if one is available. If one isn't, then a flag is set indicating the try_pull() failed. Thanks to Michi Henning, Triodia Technologies (michi@triodia.com) for pointing this out.
 

Chapter 18 Naming Service... where are the example files? 


The source code described in Chapter 18 is actually duplicated in other chapters. I forgot to make a specific copy of it for this chapter. The files are on the CD in the following directories 

SimpleNames.h
SimpleNames.cpp -- both in Examples\Chapter6, Examples\Chapter13, or Examples\Chapter14 (all the same code, exactly)

SimpleNames.java -- in Examples\Chapter8, Examples\Chapter9\NSVersion, Examples\Chapter11, or Examples\Chapter12 (all the same code, exactly.

Sorry about that! Also, the example presented in Chapter 14, starting at page 255, shows how to search a Naming Context as outlined in Chapter 18, page 298, "General Searching"
 

Exception Handling and DII (Chapter 14)


In Chapter 14, page 250-251, I describe exception handling when using the Dynamic Invocation Interface (DII) and Deferred Synchronous Operations (DSO). This information is incomplete.

As suggested in the book, you should always wrap your invoke(), send_oneway(), send_deferred(), poll_response(), and get_response() calls in try/catch blocks so you can catch system exceptions. 

Server side system exceptions and user-defined exceptions won't ever be thrown when using the DII/DSO. Instead, you must check the environment returned with the results to see if the server raised an exception.

The C++ and Java language bindings in the CORBA 2.2 Spec show this in detail:
In C++ using invoke() this looks like:
  

// C++
Request_ptr req = anObj->_request("anOp");
req->add_in_arg() <<= anArg;
// ...
req->invoke();
if (req->env()->exception() == NULL) {
   // No Exception
   req->return_value() >>= aResult;
}


The exception() method returns an ExceptionList_ptr or NULL if there are no exceptions. 

ExceptionList_ptr is a pointer to an ExceptionList object:
  

class ExceptionList
{
  public:
  ULong count();
  void add(TypeCode_ptr tc);
  void add_consume(TypeCode_ptr tc);
  TypeCode_ptr item(ULong index);
  Status remove(ULong index);
};


If it is not NULL, you can retrieve the TypeCode of the exception by using: 

req->env()->exception()->item(0);


The Java mapping is similar, except the exception() method returns a java.lang.Exception object or NULL if there is no exception.
 

Object activation with Visibroker for Java (Ch 11) 


In Chapter 11, there is a slight error in the steps needed to set up object activation (pp 202) Step 4 must come BEFORE steps 2 and 3. In other words, the correct order for the steps are:

  1. Start the Naming Service
  2. Start the Object Activation Daemon (OAD)
  3. Run the server application
  4. Terminate the server application
  5. Register the server with the OAD


Also, you may have wondered where we got the value for the -r parameter for the oadutil command. For the Chapter 11 example it is 
  

"-r IDL:Servers/Hello:1.0"


That's the Interface Repository id of the IDL for the server. You can find it by looking at the server's generated  .java file. Our server's IDL is: 

module Servers { 
   interface Hello {
      string SayHello();
      string SayGoodbye();
   };
};


When we compile the IDL, we end up with a Servers subdirectory, and a file named Hello.java. Looking at this file, we find a line like this:
  

<li> <b>Repository Identifier</b> IDL:Servers/Hello:1.0


As you can guess, that's the Repository Id we need to use with oadutil