TAO FAQ

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

Q:

A:

• http://www4.informatik.uni-erlangen.de/~geier/corba-faq/index.html is a general CORBA FAQ
• http://groups.yahoo.com/group/tao-users is an archive of the DOC Group tao-users mailing list

We at OCI provide commercial-grade support for this ORB, along with documentation and consulting services (see our web page at http://www.ociweb.com for more details), and provide the site and content of this FAQ as a free service to the TAO community.

If you have questions, and especially if you have answers to them, please send them to support@ociweb.com for inclusion in this FAQ! Let us know whether you'd like to be credited with the answer and, if so, how.

Q:

A:

Q:

A:

Books

Advanced CORBA Programming with C++ book by Henning and Vinoski. It's the equivalent of the ACE tutorial (except it's much more complete). This is a general C++ CORBA book and covers the standard way of doing things.

The OCI TAO Developer's Guide, which you can purchase via http://www.theaceorb.com/purchase/index.html . This book picks up where the Henning and Vinoski book stops, covering TAO specific topics as well as CORBA standard features omitted from the Henning and Vinoski book.

Online

The C++ Report and CUJ columns that Vinoski and Schmidt wrote over the past 4 years. They are all online at http://www.cs.wustl.edu/~schmidt/report-doc.html.

You may surf and search the tao-users mailing list archives.

Training

Doug Schmidt teaches a course at UCLA Extension. See http://www.cs.wustl.edu/~schmidt/UCLA.html for more details.

OCI offers courses on CORBA programming with C++, CORBA programming with Java, Advanced CORBA programming using TAO, and programming with ACE. See http://www.ociweb.com/education/services/descrip/dist for more details on these and related courses.

Tutorials

You can build TAO and work through the online tutorials in $TAO_ROOT/docs.

Q:

A:

Each OCI release is derived from a DOC Group version (for example, TAO 1.4a was derived from TAO 1.4.3), but an OCI release does not correspond exactly to any DOC Group release.

OCI seeks to maintain extremely stable, fully-tested, open source products backed by commercial support, training, consulting, and accompanied by extensive documentation and binaries on CD-ROM available for purchase. Many organizations desire a commercially-supported release of TAO as a basis for their mission critical applications.

The DOC Group's primary focus is research and development rather than commercial support. Support is provided on a "best effort" basis through the public tao-users mailing list, and is often excellent. However, more "predictable" support is availble from OCI and other organizations.

OCI selects a reasonably stable DOC Group release as the basis for each OCI distribution. OCI then builds and tests across over 50 combinations of hardware, operating systems, C++ compilers, and build flags. As bugs are encountered, they are fixed directly (and the fix is contributed back to DOC), fixed by integrating an existing DOC fix (depending on the severity and the degree of entanglement), or documented (if a fix is too involved to be accomplished without sponsorship).

In addition, OCI applies various enhancements, sponsored by our customers. We also integrate these back into the DOC group repository.

OCI also packages select binaries (custom builds are also available -- see http://www.theaceorb.com/product/index.html) and makes them available for purchase on CD-ROM. Since OCI's distribution of TAO is still open source, OCI also distributes the source code and all patches free of charge (see http://www.theaceorb.com/downloads).

In OCI distributions, the original DOC Group ChangeLogs are preserved; OCI changes are documented in OCIChangeLog and OCIReleaseNotes.html files, included in the source code distribution. See, for example, the latest OCI TAO 1.4a Release Notes.

Q:

A:

The odds of getting questions answered, bugs fixed, etc., goes up significantly when you report problems using the PRF because it insures that developers and support personnel get the most commonly required information right away. Failure to use the PRF means that those folks have to spend valuable time (yours and theirs) having a conversation to get that information just to start debugging. Unless you've got a paid support contract, there's even a chance that nobody will answer!

So, always use the PRF!

Q:

A:

Q:

A:

Each version of the TAO Developer's Guide includes an appendix that discusses compliance of that version of TAO in detail. These appendices are available via http://www.theaceorb.com/downloads/index.html.

Q:

A:

OCI can also provide consulting and software engineering resources to help you add new functionality into TAO or to span additional platforms. We can also manage the inclusion of such code into the supported releases of new open source versions of TAO. We can provide anonymity if you wish to avoid exposing your technical strategies in public forums, where your competition may be watching. Contact sales@ociweb.com to discuss your project.

Open source software can add immeasurably to the development of a rich infrastructure, and the provision of a high degree of application interoperability, from which we all may derive benefit. Read more about the benefits of open source at http://theaceorb.com/product/benefit.html.

Q:

A:

Q:

A:

You can find the tao-users archives on the web at http://groups.yahoo.com/group/tao-users/.

The ace-users archive is available at http://groups.yahoo.com/group/ace-users/.

ACE+TAO Mailing list info can be found at http://www.cs.wustl.edu/~schmidt/TAO-mail.html, which includes information about subscribing to the various mailing lists, including tao-users.

Thanks to Irfan Pyarali for providing this information!

Q:

A:

Q:

A:

Hardware Requirements

  - CPU Speed: Intel x86 P3 500 MHz or faster
  - Memory: 512 MB (more memory improves compile speed)
  - Hard Drive Space: 256MB swap + 250 MB up to several GB
    free (depending upon how much you build)

Operating System Requirements

  - Windows 2000, 2003, or XP

C++ Compiler Requirements

  - Microsoft Visual C++ 6.0 SP5 (no longer supported for
    latest ACE+TAO beta releases)
  - Microsoft Visual C++ 7.1
  - Microsoft Visual C++ 8.0 (Visual Studio 2005) support is
    still somewhat experimental

Other Software Requirements

  - OCI's Distribution of TAO version 1.4a latest patch
    release or the latest beta release of ACE+TAO (see
    instructions below for obtaining and installing ACE+TAO)
  - WinZIP or similar tool for extracting software archives
  - ActiveState Perl v5.6.1 or newer (recommended, but not required)

Obtaining and Installing ACE+TAO

  1. Download the latest patch release of OCI TAO 1.4a from:

     http://download.ociweb.com/TAO-1.4a/ACE+TAO-1.4a_with_latest_patches.zip

     or download the latest beta release of ACE+TAO from:

     http://download.dre.vanderbilt.edu/

  2. Extract the above archive into a path with no spaces in the path
     name (e.g., C:\ACE_wrappers).

  3. Set ACE_ROOT, TAO_ROOT, and PATH environment variables.

     For example, if ACE+TAO are installed in C:\ACE_wrappers, the
     variables will look like this:

    * ACE_ROOT=C:\ACE_wrappers
    * TAO_ROOT=%ACE_ROOT%\TAO
    * The PATH variable should contain these directories: %ACE_ROOT%\bin;%ACE_ROOT%\lib

  4. Create a file named config.h in %ACE_ROOT%\ace with the following
     contents:

     #define ACE_DISABLE_WIN32_ERROR_WINDOWS
     #define ACE_HAS_STANDARD_CPP_LIBRARY 1
     #define ACE_DISABLE_WIN32_INCREASE_PRIORITY
     #include "ace/config-win32.h"

  5. (OCI's Distribution of TAO version 1.4a) If you are using
     Visual C++ 6.0 (no longer supported for the latest beta
     releases), build the Win32 Debug or Release configuration
     of ACE+TAO using the following workspace file:

     %TAO_ROOT%\TAOACE.dsw   

     The projects in the TAOACE workspace build the ACE and
     TAO libraries, TAO IDL compiler, gperf, ORB services
     libraries and executables, and some common utilities.
     They do not include any examples, tests, or performance
     tests.  (Separate workspaces exist for them.)  Libraries
     will be installed in %ACE_ROOT%\lib.  Some executables
     will be installed in %ACE_ROOT%\bin, others (the ORB
     services executables) will be installed in their source
     directories.

     If you don't want to build all of the libraries and
     executables from the TAOACE workspace, we recommend just
     building the Naming_Service project.
     It, and the projects on which it depends includes most of
     the common ACE+TAO libraries that you need for developing
     your applications.

     If the above workspace file does not exist, you will need
     to generate it using MakeProjectCreator (MPC) (requires
     Perl as listed above) with the following commands:

     cd %TAO_ROOT%
     %ACE_ROOT%\bin\mwc.pl -type vc6 TAOACE.mwc

  6. (Either OCI's Distribution of TAO or the latest beta release)
     If you are using Visual C++ 7.1, build the Debug or Release
     configuration of ACE+TAO using the following solution file:

     %TAO_ROOT%\TAOACE.sln  (OCI's Distribution of TAO version 1.4a)
     %TAO_ROOT%\TAO_ACE.sln (latest beta release)

     The projects in the TAOACE or TAO_ACE solution build the
     ACE and TAO libraries, TAO IDL compiler, gperf, ORB
     services libraries and executables, and some common
     utilities.  They do not include any examples, tests, or
     performance tests.  (Separate workspaces exist for them.)
     Libraries will be installed in %ACE_ROOT%\lib.  Some
     executables will be installed in %ACE_ROOT%\bin, others
     (the ORB services executables) will be installed in their
     source directories.

     If you don't want to build all of the libraries and
     executables from the TAOACE or TAO_ACE solution, we
     recommend just building the Naming_Service project.
     It, and the projects on which it depends, includes most of
     the common ACE+TAO libraries that you need for developing
     your applications.

     If the above solution file does not exist, you will need to
     generate it using MakeProjectCreator (MPC) (requires Perl as
     listed above) with the following commands:

     (OCI's Distribution of TAO version 1.4a)
     cd %TAO_ROOT%
     %ACE_ROOT%\bin\mwc.pl -type vc71 TAOACE.mwc

     or

     (Latest beta release of ACE+TAO)
     cd %TAO_ROOT%
     %ACE_ROOT%\bin\mwc.pl -type vc71 TAO_ACE.mwc

Q:

A:

Hardware Requirements

  - CPU Speed: Intel x86 P3 500 MHz or faster
  - Memory: 512 MB (more memory improves compile speed)
  - Hard Drive Space: 256MB swap + 250 MB up to several GB
    free (depending upon how much you build)

Operating System Requirements

  - Linux 2.2 (or later) kernel

C++ Compiler Requirements

  - gcc 3.2.x (or later)

Other Software Requirements

  - OCI's Distribution of TAO version 1.4a latest patch
    release or the latest beta release of ACE+TAO (see
    instructions below for obtaining and installing ACE+TAO)
  - GNU gunzip and GNU tar for extracting software archives
  - GNU make
  - Perl v5.6.1 or newer (recommended, but not required)

Obtaining and Installing OCI TAO

  1. Download the latest patch release of OCI TAO 1.4a from:

     http://download.ociweb.com/TAO-1.4a/ACE+TAO-1.4a_with_latest_patches.tar.gz

     or download the latest beta release of ACE+TAO from:

     http://download.dre.vanderbilt.edu/

  2. Extract the above archive into a path with no spaces in the path
     name (e.g., /opt/ACE_wrappers)

  3. Set ACE_ROOT, TAO_ROOT, PATH, and LD_LIBRARY_PATH environment
     variables.

     For example, if ACE+TAO are installed in /opt/ACE_wrappers,
     the variables will look like this:

    * ACE_ROOT=/opt/ACE_wrappers
    * TAO_ROOT=$ACE_ROOT/TAO
    * PATH will include the directory $ACE_ROOT/bin
    * LD_LIBRARY_PATH will include the directory $ACE_ROOT/lib

  4. Create a file named config.h in $ACE_ROOT/ace with the following
     contents:

     #include "ace/config-linux.h"

  5. Create a file named platform_macros.GNU in
     $ACE_ROOT/include/makeinclude with the following contents:

     exceptions=1
     inline=1
     ami=1
     rt_corba=1
     interceptors=1
     interface_repo=1
     corba_messaging=1
     probe=0
     profile=0
     fakesvcconf=0
     shared_libs_only=1
     debug=1     # (or debug=0)
     optimize=0  # (or optimize=1)
     include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU

  6. Build ACE+TAO using the following commands:

     cd $TAO_ROOT
     make

     The above commands will build the ACE and TAO libraries,
     TAO IDL compiler, gperf, ORB services libraries and
     executables, and some common utilities.  They will not
     build any examples, tests, or performance tests.
     (Separate directories and GNUmakefiles exist for them.)
     Libraries will be installed in $ACE_ROOT/lib.  Some
     executables will be installed in $ACE_ROOT/bin, others
     (the ORB services executables) will be installed in their
     source directories.

  7. If there are no GNUmakefiles, you will need to generate them
     using MakeProjectCreator (MPC) (requires Perl as listed above)
     with the following commands:

     (OCI's Distribution of TAO version 1.4a)
     cd $TAO_ROOT
     $ACE_ROOT/bin/mwc.pl -type gnuace TAOACE.mwc

     or

     (Latest beta release of ACE+TAO)
     cd $TAO_ROOT
     $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc

Q:

A:

1. Set the MPC_ROOT environment variable to point to the MPC package location. OCI's TAO release contains the MPC package at $ACE_ROOT/MPC.
   
   % export MPC_ROOT=<complete path to MPC package>
   
   
2. Set the ACE_ROOT environment variable to the root of your ACE+TAO code base and execute the following commands to generate static project files:
   
   % cd $ACE_ROOT/TAO
% $ACE_ROOT/bin/mwc.pl -type gnuace -static -name_modifier *_Static TAOACE.mwc
   
   Substitute your build tool's type for gnuace (e.g., use -type vc71 for Visual C++ 7.1).

Q:

A:

make debug=1

$ACE_ROOT/bin/mwc.pl -type vc71 -value_template lib_modifier=

#if defined(_DEBUG)
#undef __ACE_INLINE__
#endif 

Q:

A:

• Stability: OCI's Distribution of TAO is based on a stable, tested, and supported release of TAO. If you need a solid, consistent version of TAO on which to base your product or project, this is the one for you. If you need to stay abreast of new research directions or want to try out the latest features, you can still obtain TAO beta kits in source code form by visiting http://download.dre.vanderbilt.edu/.
  
• Time Savings: Buying and installing a prebuilt binary distribution of TAO, rather than downloading source code and building it yourself, can save you hours of work. In addition, you can be sure that it has been built correctly and tested across several platforms, operating systems, and compilers, and in several different configurations.
  
• Installation Support: OCI provides 90 days of installation support for registered purchasers of prebuilt binary distributions of TAO. We want to make sure you are up and running with TAO as quickly as possible.
  
• Documentation: Using OCI's Distribution of TAO is easy with OCI's TAO Developer's Guide (available for purchase at http://www.theaceorb.com/purchase/index.html). In addition to the documentation set, you can view the latest TAO release notes at http://www.theaceorb.com/releasenotes/index.html.
  
• Frequently Asked Questions: OCI maintains a list of frequently asked questions about TAO. This list is updated regularly by our staff of distributed object computing technology engineers to provide answers to common questions about using TAO. Anyone in the TAO user community can contribute questions (and answers) to the FAQ. Check it first to see if your question has been asked before. The FAQ is located at http://www.theaceorb.com/faq/
  
• Professional Support: If you need further support, beyond installation issues or frequently asked questions, such as object technology training, consulting, mentoring, or application development, OCI has several service offerings for you. Visit http://www.ociweb.com for more information.

Q:

A:

Q:

A:

The CD set contains these pre-built components for many popular platforms, operating systems, and C++ compilers.

In addition, the builds on the CD set include more than one build configuration (i.e., debug on or off, native C++ exception support on or off).

Note that the CD set does not include pre-built binaries of the various tests, performance tests, and examples that come with ACE and TAO, but the full source code for them is there.

So, if you install TAO from the OCI CD set for one of the existing platform / operating system / compiler combinations, you can get started writing, building, and running your own applications that use TAO right away.

Of course, since you have the full source code, you can custom build it yourself (e.g., for a particular platform, operating system, compiler, or configuration which is not present on the CD).

Q:

A:

The Table of Contents and Index for OCI's TAO Developer's Guide are available in PDF form via:

http://www.theaceorb.com/downloads/index.html

Just follow the appropriate links to download the files you want.

Q:

A:

Q:

A:

If you desire a smaller set of libraries, either install the release versions of the CD or rebuild the debug libraries with the default debug configuration.

Q:

A:

• If you have a technical support contract with OCI, someone will begin addressing the issue and will follow up with you according to the provisions outlined in your support contract.
• If you do not have a technical support contract with OCI, someone will still review the support request and may get back to you, but we cannot guarantee that we will have time to work on the problem without a support contract.

Q:

A:

Q:

A:

So, before you do anything, try it all again, but this time turn off multicast discovery. See How do I locate the Naming Service without resorting to multicast discovery? .

Q:

A:

# Store the IOR of the Naming Service's root Naming Context in a file:

   Naming_Service -m 0 -o /tmp/ns.ior
   client -ORBInitRef NameService=file:///tmp/ns.ior

   Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809
   client -ORBInitRef NameService=corbaloc:iiop:bart:2809/NameService

You can also use the NameServiceIOR environment variable to achieve the same effect. Here, we show what it might look like on a UNIX or UNIX-like system using the bash shell:

  Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809
  export NameServiceIOR=corbaloc:iiop:bart:2809/NameService

Q:

A:

If you're using Windows, check out Why doesn't using the Naming Service with Multicast work? and see if it applies.

Q:

A:

Use the -ORBListenEndpoints option to specify that the server should start on a specific endpoint, e.g.,

  Naming_Service -ORBListenEndpoints iiop://bart:2809

  Naming_Service -ORBListenEndpoints iiop://name_server_host:name_server_port

For more information on direct binding of persistent object references, see Henning's and Vinoski's Advanced CORBA Programming with C++, 14.3.2.

Q:

A:

   static CEC_Factory "-CECDispatching mt"

   CosEvent_Service_Native -ORBSvcConf ec.conf

Q:

A:

You can modify this behavior via the -ECSupplierControl and -ECConsumerControl options. The consumer control option sets the strategy used to deal with ill-behaved consumers. Put the following in a service configurator option file (ec.conf):

   static EC_Factory "-ECConsumerControl reactive"

This sets the control strategy for the consumers to reactive. Now start the event channel process with this configuration:

   $TAO_ROOT/orbsvcs/Event_Service -ORBSvcConf ec.conf

Any failed attempts to communicate with a consumer result in the disconnection of that consumer (and its proxy) from the event channel. The reactive strategy also polls all the consumers periodically and disconnects them if they fail to respond. The default polling period is 5 seconds and can be set via the -ECConsumerControlPeriod option.

The supplier control strategy (and associated polling period) works the same way with suppliers.

The native Cos Event Channel has analogous options (-CECConsumerControl, -CECSupplierControl, -CECConsumerControlPeriod, and -CECSupplierControlPeriod).

Q:

A:

Q:

A:

The Real-Time Event Service is TAO specific. It was developed prior to the adoption of the OMG Notification Service specification. The RT Event Service was designed to meet the real-time and quality of service needs of certain sponsors of the DOC group, but has applicability in a wide variety of domains.

On the surface, the two services provide several similar features, though the specifics of their interfaces and implementations are quite different:

• similar communications model
• support for structured events
• filtering of events
• support for subscriptions
• mechanisms for specifying QoS requirements
• support for delivery of sequences of events

In addition, the RT Event Service provides some features that are not part of the Notification Service, such as event channel federations, event correlation, suspension and resumption of consumer connections, and integration with a scheduling service.

The RT Event Service is older and perhaps more "mature" in that it has been through multiple iterations of development and is in active use by many real world applications. However, the Notification Service is also quite good and since the Notification Service is based on an OMG specification, it may be a better choice for your application, depending upon your needs.

Q:

A:

Q:

A:

In addition, you might need a way of getting good random numbers.

Q:

A:

See also the "TAO Security" chapter of the TAO Developer's Guide

Q:

A:

That said, you might look at http://www.bis.doc.gov/Encryption/ for current information from the U.S. Government if you're under its jurisdiction.

Q:

A:

        SSL_CTX *ctx = ACE_SSL_Context::instance ()->context ();

        // SSL_CTX_set_default_passwd_cb() is from OpenSSL.
        SSL_CTX_set_default_passwd_cb (ctx, your_callback);

Q:

A:

  openssl tool: [Command Line]
       openssl gendh 512 >>cert.pem

  #include "orbsvcs/SSLIOPC.h"
  #include "openssl/pem.h"

  // Open the file with the DH parameters
  FILE * fp = fopen ( "cert.pem", "r" );

  // Read in the DH parameters from the open file
  DH * dh_params = PEM_read_DHparams ( fp , NULL, NULL, NULL );

  // Obtain the SSL Context so we can set the DH parameters for it
  SSL_CTX * ssl_ctx = ACE_SSL_Context::instance()->context();

  // Set the DH Parameters for the SSL Context
  SSL_CTX_set_tmp_dh ( ssl_ctx , dh_params );

Q:

A:

  // Disable protection on Naming Service invocations.

  Security::QOP qop = Security::SecQOPNoProtection;

  CORBA::Any no_protection;
  no_protection <<= qop;

  // Create the Security::QOPPolicy.
  CORBA::Policy_var policy =
    orb->create_policy (Security::SecQOPPolicy,
                        no_protection);

  CORBA::PolicyList policy_list (1);
  policy_list.length (1);
  policy_list[0] = CORBA::Policy::_duplicate (policy.in ());

  // Get a reference to Naming Context
  CORBA::Object_var obj =
  orb->resolve_initial_references ("NameService");

  // Create an object reference that uses plain IIOP (i.e. no
  // protection).
  CORBA::Object_var unprotected_obj =
    naming_context_object->_set_policy_overrides (policy_list,
                                                  CORBA::SET_OVERRIDE);

  // Narrow to a CosNaming::NamingContext
  CosNaming::NamingContext_var naming_context =
    CosNaming::NamingContext::_narrow (unprotected_obj.in ());

Q:

A:

For example, suppose you have a server that provides a Bank object (let's call it "CORBABank"). Rather than binding this object by name in a naming context in the Naming Service, you would like clients to access it directly by simply calling

  orb->resolve_initial_references("CORBABank");

There are several ways to accomplish this.

1. Directly bind the object reference into the client ORB's list of references using an ORB initializer and the ORBInitInfo::register_initial_references() function.
2. Use the client ORB's register_initial_reference() member function.
3. Use the -ORBInitRef ORB initialization option on the client ORB

The following steps describe one way to use the 3rd method described above.

1. In the server, generate an IOR for the target object as usual.
   
2. Give the CORBA Object a simple object key by registering its IOR in the server ORB's IOR Table (See How do I use a "corbaloc" object reference with a TAO server? for details)
3. Start the server listening on a particular endpoint using the -ORBListenEndpoints option.
4. Start the client with the -ORBInitRef option and assign the service name to the simple corbaloc-style reference of the CORBA Object.
5. In the client, call resolve_initial_references() and pass it the service name.

The combination of the simple object key and the fixed endpoint allows us to reference the object via a corbaloc-style reference in the -ORBInitRef option.

For example, we can start our processes as follows:

  server -ORBListenEndpoints iiop://bart:10200
  client -ORBInitRef CORBABank=corbaloc:iiop:bart:10200/BankObject

Where BankObject is the simple object key assigned to the CORBA object in the server.

Now, on the client side, we can use resolve_initial_references("CORBABank") to directly bind to the Bank object living inside the Bank server. For example:

  // Initialize the ORB.
  CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

  // Get a reference to the Bank using resolve_initial_references().
  CORBA::Object_var obj = orb->resolve_initial_references("CORBABank");
  Bank_var bank = Bank::_narrow(object.in());
  if (CORBA::is_nil(bank.in())) {
    cerr << "Bank::_narrow() failed!" << endl;
    return 1;
  }

  // Use the Bank's object reference like you normally would...

Note that on older versions of TAO (before 1.1.10) the object reference format is slightly different:

  client -ORBInitRef CORBABank=iioploc://bart:10200/BankObject

Q:

A:

TAO added support for corbaloc references in version 1.1.10. Prior to that, TAO supported an earlier version of the specification that used the iioploc format. You can use corbaloc references to contact servers built with any version of TAO (assuming the client ORB supports them).

To simplify use if corbaloc object references, you can register your CORBA object in the server ORB's IOR table so it can be located via a simple object key. To bind an object reference to this table in current versions of TAO (1.1.10 and later):

  // Turn your object reference into an IOR string 
  CORBA::String_var ior_string = orb->object_to_string(obj.in());

  // Get a reference to the IOR Table 
  CORBA::Object_var tobj = orb->resolve_initial_references("IORTable");
  IORTable::Table_var table = IORTable::Table::_narrow(tobj.in());

  // Bind your stringified IOR in the IOR Table 
  table->bind("CORBABank", ior_string.in());

In older versions of TAO (1.1.9 and prior) this binding is accomplished via the following code:

  // Add our Bank object to the ORB's IOR table (TAO specific).
  orb->_tao_add_to_IOR_table( "CORBABank", obj.in() );

Both of these techniques make it possible for corbaloc-style object references to locate the specified CORBA object via a simple object key ("CORBABank"). The Bank's object reference doesn't necessarily have to be a persistent object reference, but it can be. For more information on persistent object references, see How do I make my object references persistent? .

When we run the TAO server, we must ensure that it listens on a host and port that are known to the client. We use TAO's -ORBListenEndpoints command-line option to do this. The format of -ORBListenEndpoints is

  -ORBListenEndpoints iiop://host:port

  server -ORBListenEndpoints iiop://myhost:11019

  corbaloc:protocol:host:port/ObjectKey

  corbaloc:iiop:myhost:11019/CORBABank

Q:

A:

1. Create a child POA with the PERSISTENT and USER_ID policies.
   
2. Create an ObjectId for each servant using PortableServer::string_to_ObjectId().
   
3. Activate the object in the child POA using activate_object_with_id().
   
4. Start the server listening on a particular endpoint using the -ORBListenEndpoints option.
   

  // Initialize the ORB.
  CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

  // Obtain an object reference for the root POA.
  CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
  PortableServer::POA_var rpoa = PortableServer::POA::_narrow(obj);

  // Create a policy list for our child POA.
  CORBA::PolicyList bankPolicies;

  // Create the policies for our child POA:
  //   LifespanPolicy: PERSISTENT
  //   IdAssignmentPolicy: USER_ID
  pols.length(2);
  pols[0] = rpoa->create_lifespan_policy(PortableServer::PERSISTENT);
  pols[1] = rpoa->create_id_assignment_policy(PortableServer::USER_ID);

  // Get the Root POA's POA Manager so it can manage our child POA
  PortableServer::POAManager_var poa_mgr = rpoa->the_POAManager();

  // Create the child POA.
  PortableServer::POA_var bank_poa =
    rpoa->create_POA("BankPOA", poa_mgr, pols);

  // Destroy the POA policies (create_POA() makes a copy).
  pols[0]->destroy();
  pols[1]->destroy();

  // Create a Bank servant object and activate it with the POA.
  Bank_i* bankServant = new Bank_i();

  // Explicitly activate the Bank servant.  We will use the string
  // "CORBABank" to generate an ObjectId for the bank.
  CORBA::String_var bankIdString = CORBA::string_dup("CORBABank");
  PortableServer::ObjectId_var bankId =
    PortableServer::string_to_ObjectId(bankIdString.in());
  bank_poa->activate_object_with_id(bankId, bankServant);
  obj = bank_poa->id_to_reference(bankId.in());

  // Activate the POAs.
  poa_mgr->activate();

  // Handle requests from clients.
  orb->run();

Since the Bank's object reference is a persistent IOR, when we invoke the Bank's server, we need to specify a particular endpoint for the ORB. For example:

  BankServer -ORBListenEndpoints iiop://bart:10200

Now, any clients that receive these object references can use them between different runs of the server. Note, that you still need to manually restart the server, unless you use the Implementation Repository.

Q:

A:

Q:

A:

The short answer is:

-ORBListenEndpoints iiop://V.v@[hostname:[port]]

The V.v@ portion of this syntax informs the server to use a specific major and minor version of the specified protocol. For example, to force a server to use IIOP v1.1 (instead of the default v1.2) on a host named "barney" at port 22000:

-ORBListenEndpoints iiop://1.1@barney:22000

If you always want to force use of IIOP 1.0 or 1.1, you can set the following macro values and rebuild TAO (and your application):

#define TAO_DEF_GIOP_MAJOR 1
#define TAO_DEF_GIOP_MINOR 0 [or 1]

These macros are typically set in $TAO_ROOT/tao/orbconf.h or $ACE_ROOT/ace/config.h.
Correction to the "-ORBListenEndpoints" syntax. It should be:
-ORBListenEndpoints iiop://1.0@[host][:port]
The hostname is not always required.

Q:

A:

This has a couple of side effects that surpise many people. First, it is possible for even a single threaded server to process more than one request at the same time. Second, if you try to allocate threads exclusively as "server" threads and "client" threads, the ORB will pay no attention to your idea of what these threads are and dispatch requests on both.

Why is this the default behavior of TAO? Mainly because nested upcalls avoid many potential deadlock situations. One example is a simple callback operation with a single threaded client. When the client sends a request to the server, the server sends a callback request back to the client. If the client's only thread is waiting for the reply and not dispatching incoming requests, then a deadlock is now in place. The default behavior allows the client ORB to process the callback request and send a reply to the server which frees the server ORB to send its reply back to the client.

There however are situations where you may wish to prevent nested upcalls in your application. Some common reasons are:

• Real-time applications which impose strict response times.
• Resource limitations which impose concurrency limitations.
• Short response time. The response will be buffered until the nested upcall unwinds.
• Recursive nested upcalls may lead to unbounded stack growth, which will eventually crash the application.

Q:

A:

• Use the Receive-Wait(RW) wait strategy.
• Employ the Two-ORB solution.

static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive
			        -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1"

static Resource_Factory "-ORBFlushingStrategy blocking"

// Assume the callback's IOR is in a Callback_var called cb.

// First, "remarshal" the callback IOR using the "server" ORB.
CORBA::String_var cbstr =
    server_orb->object_to_string(cb.in());

// Then, demarshal it using the "client" ORB.
CORBA::Object_var new_ior =
    client_orb->string_to_object(cbstr.in());

// Finally, narrow it to the derived interface type
// (can reuse cb).
cb = Callback::_narrow(new_ior.in());

Q:

A:

static Server_Strategy_Factory "-ORBConcurrency thread-per-connection"
static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1"
static Resource_Factory "-ORBFlushingStrategy blocking"

Q:

A:

• Unix Inter-ORB Protocol (UIOP), which is based on Unix Domain Sockets (or local IPC)
• Shared Memory Inter-ORB Protocol (SHMIOP), which uses shared memory as a transport.
• Datagram Inter-ORB Protocol (DIOP), which uses UDP for efficient message transfer in limited circumstances.
• Secure Sockets Layer Inter-ORB Protocol (SSLIOP), which is based on SSL.
• Multicast Inter-ORB Protocol (MIOP), implemented atop Unreliable IP Multicast (UIPMC).
• Hypertext Inter-ORB Protocol (HTIOP), which uses HTTP tunneling.
• Stream Control Transmission Protocol Inter-ORB Protocol (SCIOP), which is based on SCTP (IETF RFC 2960).

Currently, the UIOP, SHMIOP, DIOP, and SCIOP implementations are all found in $TAO_ROOT/tao/Strategies/ and the TAO_Strategies library. SSLIOP is implemented in the TAO_SSLIOP library in $TAO_ROOT/orbsvcs/orbsvcs/SSLIOP/, MIOP/UIPMC in the TAO_PortableGroup library in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup/, and HTIOP in the TAO_HTIOP library in $TAO_ROOT/orbsvcs/orbsvcs/HTIOP/.

The use of the underlying transport protocol is completely transparent to the application. In fact, the ORB can actually be configured to use more than one transport protocol simultaneously.

If one of the above built-in transport protocols does not meet your needs, you may need to implement one yourself. If done correctly, it should require no changes to the TAO core. Use one of the existing pluggable transport protocol implementations as guidance.

Using and developing pluggable protocols is documented in detail in the TAO Developer's Guide.

Q:

A:

• If the client is collocated with the servant and collocation is enabled, then the request is serviced on the client's thread. Collocation can be disabled via the option: -ORBCollocation no
  
• If the client is not in the same process as the servant (or collocation is disabled), then the concurrency strategy of the servant's ORB determines the servicing thread. By default, this is the same thread where orb->run() or orb->perform_work() is called. You can also specify a thread-per-connection model via the -ORBConcurrency option and a threadpool model by using the thread pool reactor.

See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/Options.html?view=co for more details on these options.

See http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col18.pdf for a discussion of TAO's collocation optimizations.

Q:

A:

You cannot directly detect when this happens. You could write a pluggable protocol that informs your application when a connection dies, but that's about it.

Typically behind this question is the issue: how can I detect if my client died. Using connections for that is a very bad idea: the client or server ORBs may close the connection just because it is idle for too long or there may not be a physical connection between two ORBs (they may be collocated or using shared memory to communicate). There can also be multiple connections between a given client-server pair. In CORBA, connections are hidden, and can come and go as needed. Trying to rely on them to establish if the client is still there does not work.

In general you are better off using some application-level session object that gets destroyed by the client when it terminates gracefully, and that gets destroyed by an Evictor if it has been idle or unable to contact the client for too long.

Q:

A:

If you build TAO to use native C++ exceptions, the IDL compiler, by default, does not include the CORBA::Environment parameters. If you build with the alternate mapping, the IDL compiler includes the CORBA::Environment parameter by default. You can explicitly tell the IDL compiler what to do with the -Ge option (-Ge 1 includes the extra parameter, -Ge 0 omits it). You need to generate the skeleton classes in a manner that is compatible with your servant classes or you will receive compiler errors about abstract classes or pure virtual functions.

For more information about Exceptions and TAO, see the Error Handling chapter of the TAO Developer's Guide.

Q:

A:

• ACE_HAS_STANDARD_CPP_LIBRARY -- Causes ACE to #include the standard libraries where appropriate instead of older style runtime libraries, or defining its own equivalent. (ie <cstdio> instead of <stdio.h> or <memory> instead of creating its own auto_ptr)
  
• ACE_USES_STD_NAMESPACE_FOR_STDCPP_LIB -- This causes ACE to define "using std::xxx" for all the std classes it uses. I've never messed with this one, so I'm not sure of all the ramifications. I notice that it is defined by default for most (all?) windows compilers.
  
• ACE_HAS_STDCPP_STL_INCLUDES -- This seems to be used only in ace/IOStream.h. It causes ACE to use <string> instead of <String.h>. It's not defined for VC++, but is for some other win32 compilers. I've never used this one either.

Q:

A:

You are only supposed to use the first "argc" number of arguments after call CORBA::ORB_init(). In your case, you had:

  argc = 3    and argv = { "ex", "-ORBDebugLevel", "5" }

  argc = 1    and argv = { "ex", "5", "-ORBDebugLevel" }

Q:

A:

By default ACE uses the ACE_Select reactor, which works with signals. TAO defaults to use the thread pool (TP) reactor, which does not currently work with signals. See DOC Bug 1031:

http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1031

The call ACE_Reactor::instance() returns an ACE_Select_Reactor. The call TAO_ORB_Core_instance()->reactor() returns an ACE_TP_Reactor.

Another possible approach for handling signals in a TAO application that uses the default TP reactor would be to spawn a separate thread and use ACE_OS::sigwait() to handle the signals.

Q:

A:

Please see $TAO_ROOT/docs/transport_current/index.html for description of the Transport Current feature.

Q:

A:

Here is an example to obtain endpoint information via TAO::Transport::IIOP::Current interface.

  
  // Get the IIOP Current object.
  CORBA::Object_var tcobject =
    orb->resolve_initial_references (ACE_TEXT_ALWAYS_CHAR
("TAO::Transport::IIOP::Current"));

  Transport::IIOP::Current_var tc =
    Transport::IIOP::Current::_narrow (tcobject.in ());

  if (CORBA::is_nil (tc.in ()))
    {
      ACE_ERROR ((LM_ERROR,
                  ACE_TEXT ("Tester (%P|%t) ERROR: Could not resolve ")
                  ACE_TEXT ("TAO::Transport::IIOP::Current object.\n")));

      throw CORBA::INTERNAL ();
    }

  // Access the host and the port of the remote endpoint.
  ::CORBA::String_var rhost (tc->remote_host ());
  ::CORBA::Long rport = tc->remote_port ();
  
  // Access the host and the port of the local endpoint.
  ::CORBA::String_var lhost (tc->local_host ());
  ::CORBA::Long lport = tc->local_port ();
  

To use the Transport Current features, the TransportCurrent library must be loaded via Service Configurator, or be statically linked . Here is an example of the Service Configuration file.

  dynamic TAO_Transport_Current_Loader Service_Object * TAO_TC:_make_TAO_Transport_Current_Loader() ""

One could achieve the same, by using -ORBSvcConfDirective with the above as a parameter.

Q:

A:

Q:

A:

If you do have an out-dated version of one of the ACE, TAO, or CIAO libraries (e.g., ACE.dll), and its path appears in the library search path before $ACE_ROOT/lib from your build tree, you will have run-time link errors. The run-time linker tries to link your program against the first occurrence of the library that it finds in the library search path.

You can confirm that this is the problem you are having by moving the problematic library in your build tree to a backup file and re-running your application. If you still experience the run-time link error, then you probably have another (stale) version of the problematic library on your system. (The ldd command on Linux and Unix can be very helpful in tracking down where the out-dated library is located.) To correct the problem, ensure that $ACE_ROOT/lib comes first in the library search path. On Windows, you will need to restart your terminal windows and development environment.

Thanks to Stoyan Paunov for contributing this question and answer.

Q:

A:

  -ORBListenEndpoints iiop://< hostname or ip address >:< port >

Q:

A:

When you include ACE/TAO headers from the file containing the main() function, the ACE::init() function is called automatically for you at the start of main(). ACE::init() initializes the ACE Object Manager, and must be called before initializing or using any ACE/TAO objects. When you only use ACE/TAO from libraries that are dynamically linked, you may need to explicitly call ACE::init() beforehand. Also, you will need to call ACE::fini() to close down the ACE Object Manager at the end of your application's use of ACE/TAO (e.g., at an exit point from the code in your library).

Q:

A:

The solution to your memory leak may be as simple as inheriting from TAO_Local_RefCounted_Object instead of CORBA::LocalObject.

Q:

A:

Another way to test this (and even make it work) is to tell TAO to use decimal addresses (i.e. 128.252.120.1) instead of host names. You can do this by passing -ORBDottedDecimalAddresses 1 via argv[] to CORBA::ORB_init() in each process of your application. Note that you need to do this for every CORBA server in your system. Because many client applications are also CORBA servers, it is best to use this option for all processes. Assuming your code passes command line options to CORBA::ORB_init(), you can do this from the command line:

  server -ORBDottedDecimalAddresses 1
  client -ORBDottedDecimalAddresses 1

  #define TAO_USE_DOTTED_DECIMAL_ADDRESSES 1

Note: In recent versions of TAO, on Windows, the default is to use dotted decimal addresses rather than hostnames.

You may also run into the problem described in this question if your server happens to be listening on the address associated with the loopback device. The IP address for this "host" is 127.0.0.1 and often (especially on Linux-based hosts), the hostname is set to localhost.localdomain. Thus, when your client tries to resolve the hostname, it resolves it correctly but connects to itself rather than the host on which the server is actually running.

Use catior (in $TAO_ROOT/utils/catior) to "peek inside" your TAO-generated IORs; if you see localhost.localdomain (or something similar) in the output, then you might have this problem! Use the -ORBListenEndpoints option (also called the -ORBEndpoint option) to specify the hostname on which the server should listen for requests (and, thus, the hostname that it encodes in the IORs it generates).

The -ORBListenEndpoints option takes many arguments and modifiers. See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/ORBEndpoint.html?view=co and the TAO Developer's Guide for more details on the the -ORBListenEndpoints option.

Thanks to Tim Fry <tfry at imoney dot com> for posting to the tao-users mailing list the raw material from which this entry was created.

Q:

A:

(Answer): By default, the ORB uses a Leader Follower (LF) for receiving requests and processing replies from remote targets. It uses a simple protocol that keeps track of the server threads that are ready to process invocations and the client threads that are waiting to process replies.

When you register your own event handlers with the reactor, the reactor makes an upcall directly into your application code. If your event handler code then makes a remote call and waits for a reply, the LF protocol breaks down since a thread marked as a server thread becomes a client thread without the LF's knowledge. The signature of the problem is a blocked server with stack traces showing none of the threads in the select() system call.

To fix this problem, you have to abide by the LF protocol. Do the following within your event handler code (e.g., in handle_timeout() or the other handle_* methods):

   TAO_ORB_Core *oc = my_orb->orb_core ();
   oc->lf_strategy ().set_upcall_thread (this->orb_core_->leader_follower ());

You may have to include the header files "tao/ORB_Core.h" and "tao/LF_Strategy.h" in your code to get the above code to compile cleanly. Also, when you make the above calls, remember to use the ORB within whose reactor you registered your event handler.

Thanks to Milan Cvetkovic <mcvetkovic@mpathix.com> for reporting the problem and to Balachandran Natarajan <bala@dre.vanderbilt.edu> for providing the answer.

Note: You could also solve the problem by configuring the ORB to use a different wait strategy other than the default Leader Follower.
See Why is my "client" thread dispatching requests? for more information.

Or, you could use a different ORB (other than the server ORB) in your event handler for making the outbound invocation.

Q:

A:

TAO.lib(TAO.dll) : error LNK2005: "public: void __thiscall TAO::unbounded_value_sequence::length(unsigned int)" ([mangled name removed]) already defined in fooC.obj

typedef sequence<unsigned long> MyULongList;

• Instead of typedef'ing your own MyULongList, use CORBA::ULongSeq or similar.
• Add #include <tao/orb.idl> (which includes tao/ULongSeq.pidl) to the top of your IDL file, or just the include statement for the sequence type(s) that you are using (such as tao/ULongSeq.pidl).

Q:

A:

By default, Orbix 2000 will reject any message larger than 512 KB.

Orbix 2000 users can get around this by setting a run time policy in their configuration file. The policy is

  policies:iiop:buffer_sizes_policy:max_buffer_size = "-1";

Q:

A:

There is no definitive list of ORBs that a particular version of TAO works with. Here are some ORBs that users have reported successfully using with TAO in the past:

• Orbix (3.x, 2000)
• Visibroker
• JacORB
• OpenORB
• Sun JDK ORB
• ORBExpress
• INTERSTAGE
• CorbaScript
• Orbacus
• ZEN
• MICO
• OmniORB
  

Q:

A: