This document contains information on the following topics related to the current release of TAO:
A complete list of all modifications to TAO is available in the ChangeLog.
Point of contact: Jeff Parsons
tao_idl
enables the perfect
hased lookup strategy. This strategy uses GPERF, the
GNU's Perfect Hash Function Generator written by Dr.Douglas
C. Schmidt. Right now, GPERF works only on Solaris. Any work on
porting GPERF to other platforms will be highly
appreciated.
typedef
sequence<char>CharSeq;
, we now generate a new class (and
hence a type) called "class CharSeq". Arrays are still being worked
out and will be done soon. An important difference in the generated
code is that the skeletons now use a table driven approach very
similar to the stubs.
-Wp,export_macro=MACRO_NAME-Wp,export_include=INCLUDE_NAME
.
-GI [ h | s | b | e | c ]
_TAO_ENUM_32BIT_ENFORCER = 0xFFFFFFFF
to
every enum. This appended enum value is not part of the IDL compiler's
internal representation of the enum, so unions that use the enum as a
discriminator will not have incorrect _default() code generated for them.
TAO_HAS_VALUETYPE
defined, and IDL_HAS_VALUETYPE
is also defined, then
the IDL compiler will enable OBV support with the command line option
-Gv
, and disable it with the option -Sv
(the default).
-GC
command line option is
used. The TAO library must be compiled with
TAO_HAS_CORBA_MESSAGING = 1
.
If this is done, TAO_HAS_AMI_CALLBACK
will automatically be defined to
1 as well. IDL_HAS_VALUETYPE
is defined to 1 by default.
-So
added to suppress generation of ostream
operators for exceptions.
-Sc
added to suppress generation of tie classes
and *S_T.*
files. The default is still to generate them.
-St
option to suppress generation of typecodes now also suppresses the
generation of the Any insertion and extraction operators. The extraction
operators require the associated typecode, so the generated code for those
operators would not compile when the -St option was used.
-Ge 2
added which generates 'throw' instead of
ACE_THROW_SPEC
, ACE_THROW
,
and ACE_RETHROW
. Since the expansion of
ACE_THROW_RETURN
is platform-dependent,
it was left as is. Same for TAO_INTERCEPTOR_THROW
, since it sometimes
expands to ACE_THROW_RETURN
. Of course
ACE_HAS_EXCEPTIONS
must be defined for
this option to work.
CORBA::Exception
works fine and produces the same
output.
FE : ACE
BE : FE
EXE : FE, BE
Executing the Makefile (or the TAO_IDL Compiler project in the MSVC 'tao_idl' workspace) will build whatever is required in the proper order, as before. Back end files, classes and functions required by the executable are as follows:
be.h - file containing #includes of the major BE file headers.
TAO_Codegen - class, holds output stream references for the various generated files.
TAO_CODEGEN - ACE_Singleton typedef of the above class.
tao_cg - pointer to instance of TAO_CODEGEN.
be_generator - class, inherits from AST_Generator in FE and generates AST nodes.
void BE_produce (void) - global function, starts AST traversal for code generation.
BE_GlobalData - class, holds default/command line arg settings specific to BE.
be_global - pointer to instance of above class.
All the code in the executable that may need to be modified for different back ends in contained in the file drv_args.cpp. Code in this file processes the command line arguments, outputs a usage message, and performs other miscellaneous BE initialization.
const string foo = "hel" "lo " "the" "re";
const char *foo = ......
occurs in the source code. The variable foo is sometimes not allocated or assigned properly, and if foo is part of generated code, it will then display as garbage or as an empty string (or substring). Two workarounds have been found. One is to change the declaration of foo to be
static const char *foo = ....
and this has been done in all cases we could find in the IDL compiler source code. Another way to avoid the problem is to change the Release project Optimization setting to 'Minimize Size'. Reportedly the problem has been fixed in MSVC version 7.0.
For a complete description of value type semantics, see chapter 5 in the CORBA specification.
Point of contact: Balchandran Natarajan
Last Update: $Date: 2004/06/15 14:34:01 $
TAO::CONNECTION_TIMEOUT_POLICY_TYPE
and is
proprietary to TAO. It comes as a prt of the TAO_Messaging
library. Please see
$TAO_ROOT/tests/Connection_Timeout
for an example
of how to use this feature.
Point of contact: Ossama Othman
The goal of the pluggable protocol effort is to (1) identify logical communication layers in the ORB, (2) abstract out common features, (3) define general interfaces, and (4) provide necessary mechanisms for implementing different concrete ORB and transport protocols. TAO's pluggable protocol framework will allow disparate communication mechanisms to be supported transparently, each with its own set of requirements and strategies.
For example, if the ORB is communicating over a system bus, such as PCI or VME, and not all the features of GIOP/IIOP are necessary and a simpler, optimized ORB and transport protocol can be defined and implemented. Similarly, it should be straightforward to add support for new transport protocols that use native ATM or shared memory as the underlying communication mechanism. In all cases the ORB's interface to the application will remain compliant with the OMG CORBA standard.
There will be several stages of the development process: (1) basic pluggable transport protocols framework, (2) support for multiple profiles, (4) add example transport protocols, such as ATM and VME, and refine/optimize the transport protocols framework, and (4) add support for pluggable ORB protocols, e.g., replacements for GIOP. Each of these steps is outlined below:
The common interfaces have been defined in the new abstract classes
that form the core of TAO's pluggable protocol framework, e.g.,
TAO_Connector
,
TAO_Acceptor
,
TAO_Profile
and TAO_Transport
. Two new mechanisms for keeping track of supported
transport protocols are the
TAO_Connector_Registry
and
TAO_Acceptor_Registry
,
which are essentially Abstract Factories that produce the right types of
connector, acceptors, and transports.
Other interesting transport protocols could be for ATM, Buses (VME or PCI), TP4, and GSMP. TAO users have also created their own pluggable transport protocols, such as a ScramNet pluggable protocol.
Latency
,
MT_Cubit
, Multiple_Inheritance
, CDR
and
EC_Throughput
can be used to verify performance using the new
framework.
-ORBEndpoint
options or several endpoints separated by semi-colons ';',
the user can specify what addresses the ORB should use.
Each endpoint is specified in URL format (ex:
iiop://foo.bar.com:0
), this format can be
extended to support different protocols.
No changes were made to the core TAO sources to provide to this SSL support, nor does TAO contain any security related hooks. TAO's SSLIOP implementation is completely self-contained. This ensures that the core TAO sources remains free of export restrictions.
-ORBHost
and
-ORBPort
has been removed. The new
-ORBEndpoint
option supersedes them, and provides the same
functionality in a protocol-neutral way. If the
deprecated options are used, the ORB exits with a
CORBA::BAD_PARAM
exception, indicating an
unknown -ORB
option.
-ORBPreconnect
ORB option has been
deprecated in favor of the standard
validate_connection
run-time feature.
Support for this option will be removed from future
releases.
corbaloc
uses. The BNF specification for corbaloc
is:
<corbaloc> = "corbaloc:/"[<obj_addr_list>]["/"<key_string>]
<obj_addr_list>= [<obj_addr> ","]* <obj_addr>
<obj_addr>= <prot_addr> | <future_prot_addr>
<prot_addr>= <rir_prot_addr> | <iiop_prot_addr>
<rir_prot_addr>= <rir_prot_token>":"
<iiop_prot_addr>= <iiop_id><iiop_addr>
<iiop_id>= ":" | <iiop_prot_token>":"
<iiop_prot_token> = "iiop"
<iiop_add> = [<version> <host> [":" <port>]]
<host> = DNS-style Host Name | ip_address
<version> = <major> "." <minor> "@" | empty_string
<port> = number
<major> = number
<minor> = number
<future_prot_addr> = <future_prot_id><future_prot_addr>
<future_prot_id> = <future_prot_token>":"
<future_prot_token> = possible examples: "atm" | "dce"
<future_prot_addr> = protocol specific address
<key_string> = <string> | empty_string
The uiop
URL style object references syntax
is:
<uioploc> = "uioploc://"[<addr_list>]["|"<key_string>]
<addr_list>= [<address> ","]* <address>
<address> = [<version> <rendezvous point>]
<rendezvous point> = Valid Filesystem Path
<version> = <major> "." <minor> "@" | empty_string
<major> = number
<minor> = number
<key_string> = <string> | empty_string
Note that the key string delimiter for uiop
is a vertical bar `|
' (the command line
"pipe" symbol) not a forward slash
`/
'. A delimiter other than a
forward slash is needed to prevent ambiguities of
where the rendezvous point ends and where the key
string begins since both may contain forward
slashes in them. The new corbaloc:uiop
URL
format may also be used.
It should be noted that these formats have been superseded
by the new corbaloc
Interoperable Naming Service
support.
uiop
is
any valid path and filename that the ORB has permission to
read and write to. However, UIOP rendezvous points have
the same restrictions that local IPC has. The following
are some guidelines that will help ensure successful use
TAO's UIOP pluggable transport protocol:
If an endpoint is longer than what the platform supports then it will be truncated so that it fits, and a warning will be issued.
-ORBEndpoint
uiop://foobar
. A local IPC rendezvous
point called foobar
will be created
in the current working directory. If the client
is not started in the directory where the
foobar
rendezvous point exists then
the client will not be able to communicate with
the server since its point of communication, the
rendezvous point, was not found. On the other
hand, if an absolute path was used, the client
would know exactly where to find the rendezvous
point.
It is up to the user to make sure that a given UIOP endpoint is accessible by both the server and the client.
uiop:///tmp/foo
is specified as the
server endpoint and uiop://foo
as a
preconnect for a client in /tmp
, then
the preconnection may be established but it is
likely it won't be used since the endpoint and
preconnect are interpreted as different strings,
i.e. /tmp/foo
and foo
are
not the same, lexicographically. On the other
hand, if both the endpoint and the preconnect are
the same string then a preconnection will be
established and used successfully.
The -ORBEndpoint
option uses a syntax similar to that of the URL style
object reference shown above. The only difference is that
the object key delimiter and the object key string are not
specified.
This means that server IORs will contain profiles for all of the default endpoints created on each network interface the server is listening on, if no explicit endpoints were specified.
Point of contact: Irfan Pyarali
The POA associates servants with the ORB and demultiplexes incoming requests to servants.
ACTIVE
, is the request dispatched to the
servant. Otherwise, the request is rejected. Since POA Managers start
off in HOLDING
state, make sure to
activate()
them before falling into the event loop.
The new solution is to use an active demux table, and flatten the POA hierarchy. This will help in the searching since active demuxing is fast and predictable. This will also help in the parsing since the demux key will be fixed size.
Note that for persistent ids, we have to pass the complete POA name in addition to the demux key in order to handle POA creation on demand.
Points of contact: Jeff Parsons Boris Kolpackov
Last Update: 2002/07/29
Objects-by-Value (OBV) describes the new type, valuetype
.
It is introduced in CORBA 2.3
This first implementation was contributed from
Torsten Kuepper.
Valuetype
s are similar to IDL struct
s extended with
these features:
valuetype
and
multiple inheritance from abstract
valuetype
s. Eventually support of an
interface.
valuetype
s, with the
possibility of NULL references or shared (aliased) references.
Valuetype
s will likely be used to implement
abstract datatypes (ADT)s that can be copied to another process.
All processes that use the valuetype
must have an
implementation for it since CORBA does not support code
migration, a la Java RMI.
valuetype
.
Relevant options of TAO's IDL compiler are:
libTAO
must be compiled with TAO_HAS_VALUETYPE
.
Valuetype
s can be used as arguments in CORBA invocations.
There is an example in $TAO_ROOT/TAO/examples/OBV/Typed_Events. Valuetype
s
could even reference other valuetype
objects (but without sharing).
Valuetype
s work only in conjunction with
compiled marshalling (-Gc
, currently default for
tao_idl
).
valuebox
es
valuetype
object. Hence no support for truncation or
custom marshalling.
-Wb,obv_opt_accessor
) should be
unaffected by that.
valuetype
is currently non-standard. Hashed repository ids are not
implemented.
valuetype
factories needs some
revision to provide proper locking. Currently the
registration of factories is best completed before
unmarshalling valuetype
s.
There is one map of factories for the whole process. This
will once be changed to conform to the specs, which
suggests one per ORB.
Points of contact: Marina Spivak and Vishal Kachroo
OMG defined CORBA Naming Service to provide a basic service location mechanism for CORBA systems. CosNaming manages a hierarchy of name-to-object-reference mappings. Anything, but typically the server process hosting an object, may bind an object reference with a name in the Naming Service by providing the name and object reference. Interested parties (typically clients) can then use the Naming Service to resolve a name to an object reference.
More recently, CORBA Naming Service was subsumed/extended by the CORBA Interoperable Naming Service, a.k.a. INS. INS inherits all the functionality from the original Naming Service specification in addition to addressing some its shortcomings. In particular, INS defines a standard way for clients and servers to locate the Naming Service itself. It also allows the ORB to be administratively configured for bootstrapping to services not set up with the orb at install time. This page provides a brief description of additional features INS provides, and how they are implemented in TAO.
-m1
option to turn it on.
corbaloc
format.
These features allow the ORB to be configured to return arbitrary object
references from CORBA::ORB::resolve_initial_references
for non-locality-constrained objects. Two options -ORBInitRef and
-ORBDefaultInitRef have been added to the orb for bootstrapping to
arbitrary services.
LOCATION_FORWARD/OBJECT_NOT_EXIST
status. The Naming Service can be configured through ORB options to
register arbitrary services given the URL-format IOR for the
service. The resolve_initial_references ()
resolves a service in the
following order :
-ORBInitRef
-ORBDefaultInitRef
LOCATION_FORWARD/OBJECT_NOT_EXIST
status.
Point of contact: Ossama Othman
Additional information is available here.
TAO's current Security Service support implements the core functionality of the CORBA Security Service v1.8.
In particular, it implements the most of the CORBA SecurityLevel1 API, in addition to some of SecurityLevel2. Of the transport protocols described in the above specification, only SSLIOP is supported.Documentation for TAO's SSLIOP pluggable protocol is available here.
The 1.8 specification defines the Common Secure Interoperability version 1 (CSIv1) protocol that is currently implemented in TAO.
There are basically two ways to use security in TAO:
QOPPolicy
InvocationCredentialsPolicy
EstablishTrustPolicy
IIOP over SSL integration via TAO's SSLIOP pluggable protocol.
SSLIOP::Current
implementation that can be used to obtain the SSL session state for the current execution context. This is useful for obtaining the SSL peer certificate chain associated with the current request, for example.
SecurityLevel1
for the SSLIOP security mechanism.
SecurityLevel2::QOPPolicy
policy has been implemented. This policy is used to set the desired invocation Quality-of-Protection (QoP). It can be created using ORB::create_policy()
, and used in conjunction with the standard policy manipulation CORBA features (e.g. PolicyManager
, PolicyCurrent
), meaning that this policy can be set on a per-ORB, per-thread or per-object basis.
This policy makes it possible to, for example, make both secure and insecure invocations within the same client process.
SecurityLevel2::EstablishTrustPolicy
policy
has been implemented. This policy is used to set the desired invocation
level of establishment of trust. It can be created using ORB::create_policy()
,
and used in conjunction with the standard policy manipulation CORBA
features (e.g. PolicyManager
, PolicyCurrent
),
meaning that this policy can be set on a per-ORB, per-thread or
per-object basis.
This policy makes it possible to, for example, make authenticated and non-authenticated invocations within the same client process.
SecurityLevel2::PrincipalAuthenticator
support for SSLIOP. In particular, a SSLIOP-specific SecurityReplaceable::Vault
implementation is now available. Credentials
implementation
is complete. SecurityLevel2
interfaces such as Credentials
,
SecurityManager
, and PrincipalAuthenticator
are currently under development. SecurityReplaceable
IDL module. They provide the ability to replace key security components
in the ORB with another implementation with ease. Thus, the security
components in the ORB become highly extensible. Complete integration of the Common Secure Interoperability version 2 (CSIv2) protocol defined in the CORBA 3.0.x core specification, and the Authorization Token Layer Acquisition Service (ATLAS).
CSIv2 and ATLAS address many of the shortcomings of the current CSIv1-based Security Service. Overviews of each are available on the OMG Security web page.
Note that CSIv2 as defined by the CORBA 3.0.x specification has no API so TAO's implementation will use a slightly modified API currently used by several ORBs defined by Adiron LLC.
Point of contact: Balachandran Natarajan
TAO supports the ORB level requirements to achieve Fault Tolerance for CORBA Objects. The details of the ORB level support is described in the FT chapter of the CORBA 3.0 specification. Specifically TAO implements the sections 23.2.2, 23.2.3, 23.2.6 thru 23.2.8 of the document.
Point of contact: Ossama Othman
TAO's Load Balancer currently implements the latest revision of the OMG Load Balancing and Monitoring specification.
It provides many features and advantages over the previous non-standards based prototype. Those features and advantages include:
The current Load Balancing and Monitoring specification defines three built-in load balancing strategies. They are:
RoundRobin
(non-adaptive) Random
(non-adaptive) LeastLoaded
(adaptive) TTAO implements all of these load balancing strategies.
RoundRobin
load balancing strategy LeastLoaded
load balancing strategy Point of contact: Pradeep Gore
The COS compliant Event Service implements the Event Service Specification. This implementation is based on the Real Time Event service.
Point of contact: Frank Hunleth
The final MIOP specification has recently been adopted by the OMG. TAO's MIOP support (located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to receive requests sent to multicast addresses. This is performed by creating a GroupId that identifies the multicast group and associating it with one or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable protocol is used to send and receive multicast requests. Multicast endpoints can be created dynamically at runtime.
Point of contact: Nagarajan Surendran
The TAO IDL_Cubit test application makes use of the Naming Service and the server holds a TAO_Naming_Server component.Just running server and client is enough to test the application.
The various tests in the tests/POA test the different features of the Portable Object Adapter interface like Explicit Activation, On Demand Activation, etc.
The TAO MT_Cubit test application is meant to serve as a starting point for real-time tests on the TAO system. It comprises the following parts:
Clearly, if the ORB endsystem handles the priorities of the various requests correctly, increasing the volume of lower priority requests should not affect the performance seen by the higher priority requests. The application thus serves as a tool to measure and confirm this behavior.
The TAO Pluggable test utilizes ACE Timeprobes to time the latency at various points in the ORB, especially that incurred by the Pluggable Protocols implementation. Comparisons can be made not only between different layers of the ORB, but also between different protocols as they become available.
Points of contact: Nanbor Wang and Irfan Pyrarli
inet_ntoa
and
other functions because VxWorks doesn't provide full argument prototypes
for these library functions. connect()
fails with EWOULDBLOCK
,
morph the error to -1 and clean up the request. Added the ability for a Svc_Handler to recycle itself. idle() can be called when the Svc_Handler is done serving a particular connection and can how be recycled. The Svc_Handler now also has a pointer to a recycler that is responsible for managing the connections. The recycler is usually a Cached_Connector.
Added new class ACE_Recycling_Strategy. It defines the interface (and default implementation) for specifying a recycling strategy for a Svc_Handler. This strategy acts as a consular to the Svc_Handler, preparing it for the tough times ahead when the Svc_Handler will be recycled.
Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op activation strategy in order to avoid calling open on a recycled svc_handler multiple times.
ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy when they become idle. It also allows them to purge themselves from the connection cache when the Svc_Handlers close down.
Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection cache.
Points of contact: Michael Kircher and Chris Gill.
This discussion focuses on the following goals:
The DOVE Browser uses independent visualization components (Java Beans) and the Event Channel as DOVE Agent. Connections can be established between monitored metrics and the visualization components.
We have three major components: Observables (monitored metrics), Observers (a Java Bean for displaying the metric) and a DataHandler (for demultiplexing the monitored metrics to the appropriate Observables). Each component inherits from a base class, so that a certain behavior of the components can be assured for each component. Relationships between components are based on these base classes.
The used Java Beans are required to conform to some standards, as they have to support a function called "getProperty" which allows the DOVE Browser to determine if the vizualization capabilities of a specific Java Bean are sufficient to display the metric. A JavaBean is for example a Java Panel which shows a Graph of the delivered doubles. So all metrics can be displayed by this visualization component which can be expressed by a single double.
The DataHandler is connected to the Event Push Consumer (PUSH, because we use the push concept of the Event Service). The Event Push Consumer does not know what kind of data is transported. The only component knowing all the details about the dependencies of the metrics is the DataHandler. This separation allows easy extension and change of the demo.
Event Service events are used as communication between DOVE Applications and the DOVE Browser. The DOVE MIB analyses the event data field of all events and stores this information into a file. The event data filed is of type CORBA::Any and the DOVE MIB has no notion of what is conveyed in this field. So the DOVE MIB has to discover the content via the embedded type code information. Future work includes:
For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.
Point of contact: Irfan Pyarali, Michael Kircher.
For more information see Location forwarding
Point of contact: Irfan Pyarali, Michael Kircher.
For more information see Leader-follower model
Point of contact: Irfan Pyarali, Michael Kircher.
For more information see Locate request
Points of contact: Alexander Arulanthu, Michael Kircher and Carlos O'Ryan
We've implemented the callback model of the CORBA
Messaging specification. To activate the AMI for TAO and the TAO IDL
compiler define TAO_HAS_CORBA_MESSAGING
, TAO_HAS_AMI_CALLBACK
in your config.h file. The TAO IDL compiler can generate the AMI "callback"
stubs, ReplyHandler und reply stubs using the -GC
switch.
For an example see $TAO_ROOT/tests/AMI
and $TAO_ROOT/examples/AMI
.
Point of contact: Ossama Othman.
For more information see Portable Interceptors
Point of contact: Nanbor Wang.
Local interfaces are first defined in the CORBA Component Model specification. For more information on using the local interfaces, please refers to Section 11.1.1 to 11.1.4 of the spec and our short guideline on implementing local objects.