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:

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: ACE+TAO can be configured to build on a variety of 32
    and 64 bit processors (Intel, AMD)
  - Memory: 512 MB (more memory improves compile speed)
  - Hard Drive Space: 256MB swap + 500 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++ 7.1 or 8.0

Other Software Requirements

  - OCI's Distribution of TAO version 1.5a 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 release of OCI TAO 1.5a from:

     http://download.ociweb.com/TAO-1.5a/

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

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

  2. Extract the 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_DISABLE_WIN32_INCREASE_PRIORITY
     #include "ace/config-win32.h"

  5. Build the Debug or Release configuration of ACE+TAO using
     the following solution file:

     %TAO_ROOT%\TAO_ACE.sln

     The projects in the 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 directories and solutions 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.

  6. If you don't want to build all of the libraries and
     executables from the 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.

  7. 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:

     cd %TAO_ROOT%
     %ACE_ROOT%\bin\mwc.pl -type vc71 TAO_ACE.mwc

     More information on MPC is available here:

     http://www.ociweb.com/products/mpc

Q:

A:

Hardware Requirements

  - CPU: ACE+TAO can be configured to build on a variety of 32
    and 64 bit processors (Intel, AMD, PowerPC)
  - Memory: 512 MB (more memory improves compile speed)
  - Hard Drive Space: 256MB swap + 500 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.5a 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 release of OCI TAO 1.5a from:

     http://download.ociweb.com/TAO-1.5a/

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

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

  2. Extract the 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:

     cd $TAO_ROOT
     $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc

     More information on MPC is available here:

     http://www.ociweb.com/products/mpc

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 TAO_ACE.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:

The AccessDecision interface gives the ability to weaken the security requirements for designated object references. Show here, its single operation is intended to be called from an interceptor, or perhaps from within a servant.

module SecurityLevel2 {
  local interface AccessDecision {

#   pragma version AccessDecision 1.8

    boolean access_allowed (
      in   SecurityLevel2::CredentialsList     cred_list,
      in   Object                              target,
      in   CORBA::Identifier                   operation_name,
      in   CORBA::Identifier                   target_interface_name
    );
  };
};

TAO also extends this interface in order to allow for runtime configuration of the supplied AccessDecision object, for adding or removing objects for consideration.

module TAO {
  module SL2 {
    local interface AccessDecision : SecurityLevel2::AccessDecision
    {
      /* TAO-specific access_allowed that works around deficiencies in
         the SecurityLevel2::AccessDecision::access_allowed() operation. */
      // Parameter object_id should be PortableInterceptor::ObjectId, but
      // using that type would require including the PI_Forward.pidl file.
      // By using the real type, we can avoid that dependency.
      boolean access_allowed_ex (in ::CORBA::ORBid orb_id,
                                 in ::CORBA::OctetSeq adapter_id,
                                 in ::CORBA::OctetSeq object_id,
                                 in ::SecurityLevel2::CredentialsList cred_list,
                                 in ::CORBA::Identifier operation_name);

      /*! Default value returned when a reference is not in the list. */
      // Can't come up with a good name for this.
      attribute boolean default_decision;

      /*! Establish whether a particular object can be accessed via insecure
        means. */
      void add_object (in ::CORBA::ORBid orb_id,
                       in ::CORBA::OctetSeq adapter_id,
                       in ::CORBA::OctetSeq object_id,
                       in boolean allow_insecure_access);
      void remove_object (in ::CORBA::ORBid orb_id,
                          in ::CORBA::OctetSeq adapter_id,
                          in ::CORBA::OctetSeq object_id);
    };
  };
};

In addition to adding operations for adding or removing object references for consideration by the AccessDecision object, an extended access allowed operation is also provided, to work around a deficiency in comparing object references. For TAO, serialized object references cannot be used for comparison because they are produced using CDR encoding. This encoding uses padding bytes for alignment of multibyte values, and the padding bytes are uninitialized, meaning they will contain random data, and thus cannot be used when comparing two serialized object references.

Typically, your application will initialize the AccessDecision object by supplying it with information used to unambiguously identify the object reference, and rely on the built-in interceptor to make the call to access_allowed. TAO's security interceptor, supplied as part of the TAO_Security library, will first check with the AccessDecision object to see if unrestricted access is allowed, and if not will then evaluate the request based on the regular secure access rules.

It is possible to implement your own AccessDecision object to provide even greater control, such as restriction based on the content of the supplied credentials, and even on a per-operation level.

To use the AccessDecision interface, you must first obtain a reference to the Level 2 Security Manager from the ORB. From that you get the AccessDecision, and finally narrow that to a TAO::SL2::AccessDecision reference.

#include 

int main (int argc, char *argv[])
{
  CORBA::ORB_var orb = ORB_init(argc,argv);
  CORBA::Object_var obj =
     orb->resolve_initial_references("SecurityLevel2:SecurityManager");

  SecurityLevel2::SecurityManager_var secmgr =
     SecurityLevel2::SecurityManager::_narrow (obj.in());

  SecurityLevel2::AccessDecision_var ad = sl2sm->access_decision ();
  TAO::SL2::AccessDecision_var tao_ad =
      TAO::SL2::AccessDecision::_narrow (ad.in ());
  //...

At this point, you supply object references for consideration. It is best to do this when you are creating the references so that you don't have to keep track of the required information.

      PortableServer::ObjectId_var oid = rootpoa->servant_to_id (server2);
      CORBA::OctetSeq_var poaid = rootpoa->id();
      CORBA::String_var orbid = orb->id();
      sl2ad->add_object (orbid.in(), poaid.in(), oid.in(), true);

At this point, you are ready to go, the AccessDecision::access_allowed operation effectively adds a -SSLNoProtection SSLIOP attribute only on those object references you added to the AccessDecision object.

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:

The two ORB approach works by passing separate endpoint collections defined with "-ORBEndpoint " to the different ORB_init calls used to initialize each ORB. This way, each ORB will listen their own endpoints and their POAs will only produce object references containing the endpoints associated with the ORB. The trade-off is that each ORB must run its own event loop, and each ORB must create its own root POA along with other resources.

The endpoint policy approach allows you to have a process with a single ORB, and thus a single event loop and a single POA hierarchy, and still be able to have some POAs create object references containing a subset of the endpoints owned by the ORB. To see an example of the endpoint policy in action, look at TAO/tests/POA/EndpointPolicy.

The endpoint policy implementation is stored in libTAO_EndpointPolicy. If you are using MPC to manage your build environment, have your server project inherit the "endpointpolicy" base project. Somewhere in your application code, you must #include "tao/EndpointPolicy/EndpointPolicy.h". The endpoint policy is initialized using protocol-specific valuetype containers. For each protocol you use in your application, you must also include the definition for the endpoint value. For example, use #include "tao/EndpointPolicy/IIOPEndpointValue_i.h" to include the IIOP-specific endpoint valuetype definition.

The policy value for the endpoint policy is a list of endpoints. This way you may supply more than one endpoint value, even for different protocols, to the same endpoint policy. The constructor for IIOP-specific endpoint values takes a hostname and a port number.

  EndpointPolicy::EndpointList list;
  list.length (1);
  list[0] = new IIOPEndpointValue_i("localhost", endpoint_port);

  CORBA::Any policy_value;
  policy_value <<= list;

Endpoint policy instances are created the way any other custom policy might be, using the ORB's create_policy() operation.

  CORBA::PolicyList policies;
  policies.length (1);
  policies[0] = orb->create_policy (EndpointPolicy::ENDPOINT_POLICY_TYPE,
                                    policy_value);

Unlike other POA related policies, this policy is applied to a POA manager. This is done via the POAManagerFactory interface.

  PortableServer::POAManagerFactory_var poa_manager_factory;
  poa_manager_factory = root_poa->the_POAManagerFactory ();

  PortableServer::POAManager_var good_pm;
  good_pm = poa_manager_factory->create_POAManager ("goodPOAManager",
                                                     policies);

You then use this POAManager when you create POA instances. This POA manager is also the one on which you call activate to set all the related POAs to the active state.

  policies.length(0);
  PortableServer::POA_var good_poa =
    root_poa->create_POA ("goodPOA",
                          good_pm.in (),
                          policies);
  good_pm->activate ();

At this point any object references created by the "goodPOA" will contain only the endpoints specified on the list given to the "goodPOAManager".

Important Note: The endpoint policy works to select endpoints that were previously passed to the ORB with the -ORBEndpoint or -ORBListenPoints ORB_init options. If you supply any endpoint values to the policy that do not match any of the ORB's endpoints, this by itself will not cause a failure, but that endpoint will be included in any object references. If none of the endpoint values given to the policy match the endpoints known to the ORB, the POA will throw an exception when attempting to create an object reference.

Q:

A:

The error in question is reported when ACE cannot find the Codeset library in the LD_LIBRARY_PATH, or the runtime PATH on Windows. While most error or warning reports such as the one in question are guarded by a log-level test, this one is not, because the code in question is often used in static initializers, which are called before a log-level determination can be made.

Q:

A:

Q:

A:

TAO may also be built with codeset negotiation off by default. This is done by editing ACE_wrappers/ace/config.h and adding
#define TAO_NEGOTIATE_CODESETS 0

This will set the internal default to not load the codeset library, but this can be overridden by supplying -ORBNegotiateCodesets 1 to ORB_init.

Q:

A:

This will explicitly add TAO_Codeset to the link line of your application. Somewhere within the body of your code, you must also add #include "tao/Codeset/Codeset_Factory.h"

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 ();
  
  //