diff options
Diffstat (limited to 'TAO/docs/releasenotes/index.html')
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 1664 |
1 files changed, 0 insertions, 1664 deletions
diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index 60507237a98..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,1664 +0,0 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -<html> -<head> - - <title>TAO Release Information and TODO List</title> -</head> -<body text="#000000" bgcolor="#FFFFFF"> -<!-- $Id$ --> -<center> -<hr></center> - -<center> -<h3> -Release Information for The ACE ORB (TAO)</h3></center> -This document contains information on the following topics related to the <a href="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/VERSION">current -release</a> of <a href="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>: - -<TABLE cellpadding=10 cellspacing=0 border=0> - -<TD> -<ul> -<li> -<a href="#idl">IDL Compiler</a></li> - -<li> -<a href="orbcore.html">ORB Core</a></li> - -<li> -<a href="#pp">Pluggable Protocols</a></li> - -<li> -<a href="#rtcorba">Real-Time CORBA</a></li> - -<li> -<a href="#poa">Portable Object Adapter (POA)</a></li> - -<li> -<a HREF="../poa_migration.html">POA Migration Notes</a></li> - -<li> -<a href="#ami">Asynchronous Method Invocation (AMI)</a></li> - -<li> -<a href="#interceptor">Portable Interceptors</a></li> - -<li> -<a href="../Smart_Proxies.html">Smart Proxies</a></li> - -<li> -<a href="../implrepo/index.html">Implementation Repository</a></li> - -<li> -<a href="#interfrepo">Interface Repository</a></li> - -<li> -<a href="OBV.html">Object-by-Value</a></li> - -</UL> -</TD> -<TD> -<UL> - -<li> -<a href="#nservices">CORBA Naming Service </a> -<LI> <a href="../INS.html">Interoperable Naming Service</a></li> - -<li> -<a href="#tservices">CORBA Trading Service</a></li> - -<li> -<a href="#pservices">CORBA Property Service</a></li> - -<li> -<a href="#cservices">CORBA Concurrency Service</a></li> - -<li> -<a href="#av">CORBA Audio/Video Streaming Service</a></li> - -<li> -<a href="#ts">CORBA Time Service</a></li> - -<a href="#ec">CORBA Event Service</a></li> - -<li> -<a href="#log">CORBA Telecom Log Service</a></li> - -<li> -<a href="ec.html">TAO's Real-time Event Service</a></li> - - -<li> -<a href="#scheduling">TAO's Scheduling Service</a></li> - -<li> -<a href="#logging">TAO's Logging Service</a></li> - -</UL> -</TD> -<TD> -<UL> - -<li> -<a href="#apps">Regression Tests</a></li> - -<li> -<a href="#ace">ORB-related ACE Changes</a></li> - -<li> -<a href="#dove">The DOVE Demo</a></li> - -<li> -<a href="#forwarding">Location Forwarding</a></li> - -<li> -<a href="#leader">Global Resources and Leader-Follower Model</a></li> - -<li> -<a href="#locate">Locate requests</a></li> - -<li> -<a href="TODO.html">Our TODO list</a></li> - -</TABLE> - -</ul> -A complete list of all modifications to TAO is available in the <a href="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/ChangeLog">ChangeLog</a>. -<p> -<hr> - -<h3> -<a NAME="idl"></a>IDL Compiler</h3> -Point of contact: <a href="mailto:parsons@cs.wustl.edu"> -Jeff Parsons</a> -<p>Current status: (As of August 2, 1999.) -<ul> -<li> -Generated code closely follows the C++ Mapping specified in the latest -C++ mapping for CORBA 2.3 (Document ptc/98-09-03).</li> - -<li> -IDL compiler is now able to generate code that support native C++ -exceptions on the stubs and skeletons. With this strict mapping, the -CORBA::Environment parameter is no longer generated. -The default behavior is to generate code without the extra parameter - on plaforms with native exceptions and with the extra - parameter in platforms without native exceptions. - Use the -Ge flag to override the defaults. -</li> - -<li> -We are now able to handle shared case labels and default label in -unions. In addition, whenever appropriate, we are also able to -generate the "default ()" operation. -</li> - -<li> -We are now able to handle recursive types. We are also able to -generate optimized typecodes. -</li> - -<li> -Struct members of type strings and arrays of strings now use the managed -type instead of the _var type. This change was necessary to conform to -the IDL->C++ mapping.</li> - -<li> -Fixed a large number of problems with anonymous arrays and sequences inside -structs and unions. The name of anonymous sequence needs to be fixed as -per latest C++ mapping spec.</li> - -<li> -Compile problems with sequence of forward declared interfaces is fixed. -In addition, problems with sequence of CORBA::Objects is fixed. In this -specific case, we were not generating the _downcast and _upcast methods.</li> - -<li> -Some more problems with the front-end have been fixed. In particular, oneway -operations with a "raises" clause or having an "inout", "out", or "return" -mode is flagged as an error.</li> - -<li> -For platforms that support namespaces, we now allow reopening modules.</li> - -<li> -Support for generating compiled marshaling code is added. Use the -Gc option. -However, this needs thorough testing before we can claim success. Unions -are still a problme with compiled marshaling.</li> - -<li> -The problem of "#include"ing the relative path of the header files rather -than the paths of their corresponding IDL files has been fixed. tao_idl -now generates #include path names that are derived from the IDL files that -are #include'd in the main idl file.</li> - -<li> -Added options to IDL compiler to specify file name endings for the IDL-generated -stubs, skeletons and the various header files. Please refer to the <a href="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/compiler.html">IDL -compiler options</a> for details.</li> - -<li> -Verified support for the "long long" and "unsigned long long" datatypes. -On platforms that do not support 64 bit longs we provided <i>partial</i> -emulation through ACE_U_LongLong.</li> - -<li> Perfect Hashed Operation Lookup Strategy has been added to the -IDL Compiler. -P flag to <code>tao_idl</code> enables the perfect -hased lookup strategy. This strategy uses <a -href="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</a>, 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.</L1></li> - -<li> -The <<= and >>= operators for user-defined types are now generated.</li> - -<li> Completely redesigned the IDL compiler using the Visitor -patterns. Many incomplete issues have been resolved. These include -support for "sequence of typecodes", passing object references as in, -inout, and out parameters. Code generation for sequences is also -properly handled i.e., for a named sequence such as <CODE>typedef -sequence<char>CharSeq;</CODE>, 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.</li> - -<li> -Support for the "native" keyword added.</li> - -<li> -The problem of incorrect code generation for typedefs defined in an imported -file is resolved.</li> - -<li> -Problems when interfaces use single or multiple inheritance solved. The -problem was with the demultiplexing code, the generated operation tables, -and the dispatching mechanism. We are currently testing this with the Event -Channel code.</li> - -<li> -The problems arising due to public virtual inheritance when casting from -an interface class to CORBA::Object_ptr has been solved. We do this casting -inside the stubs/skeletons rather than first converting an interface class -pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr -in the encode/decode methods. The casting inside the stubs/skeletons work -because the compiler has knowledge of both types.</li> - -<li> -Include files are handled properly. So are the definitions used inside -the include files that are used in the currently parsed files.</li> - -<li> -Generates C++ stubs and skeletons that use TAO's <a href="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz">interpretive -IIOP protocol engine</a>.</li> - -<li> -Support dynamic libraries on NT, i.e., marking classes for DLL export was -added. Two backend options control the name of the export macro, and the -name of an extra include file were the macro is defined; the options are -<tt>-Wp,export_macro=MACRO_NAME-Wp,export_include=INCLUDE_NAME</tt>.</li> - -<li> -The IDL compiler generates now source code for sequences. The user has -now the option to use these generated sequence classes or to use, as up -to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION -is defined, then template instantiation will be used, else not. The reason -for this was, that some C++ compilers did not support template instantiation -properly and sequences were based on templates. The generated source code -is mainly contained in the generated header file directly in the class -declaration.</li> - -<li> -The IDL Compiler generates templates for servant implementations. The options -are -GI [ h | s | b | e | c ]</li> - -<li> -The IDL compiler generates source code for the management and (de)marshaling -of wide characters and wide strings, enabling the sending and receiving of -Unicode over the wire. However, wide character and wide string literals are -not yet portable to Unix platforms (see entry under Future Work below).</li> - -<li> -Since the CORBA spec requires that all enums be 32 bits, and some compilers -will try to use less space if the enum values are small enough, the IDL -compiler now appends <enum name>_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.</li> - -<li> -The IDL compiler generates a C++ ostream operator for IDL exceptions. So -far only the repository ID is output, but this may be enhanced when -requirements and/or desires become clearer.</li> - -<li> -The IDL compiler now has limited support for valuetypes (see release notes -for valuetypes for details). If the TAO library is built with -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).</li> - -<li> -As part of the implementation of interceptors, the TAO IDL compiler -now generates interception points in the client and server, as well -as the prepare_header method in the stubs.</li> - -<li> -Scoping and name resolution rules have changed in CORBA with version -2.3. The IDL compiler now conforms to these new rules. </li> - -<li> -IDL compiler now supports the CORBA AMI callback model, generating code -for reply handlers and reply stubs if the -GC command line option is -used. The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING, -TAO_HAS_AMI_CALLBACK, TAO_HAS_VALUETYPE and IDL_HAS_VALURTYPE defined. -</ul> - -<p><br>Known bugs/unimplemented constructs: -<ul> -<LI>At this point there are no known problems with the IDL compiler -</LI> -</ul> -Future work: -<ul> - -<p>Goal is to measure the code size of the interpretive stubs generated -by TAO IDL compiler <i>vs</i> code size of compiled stubs. Then compare -the performance of each. We want to prove the thesis that TAO IDL compiler -generated interpretive stubs have a small code size, yet are comparable -in performance (or slightly less) than compiled stubs. Hence, it will be -useful for small distributed equipment such as handsets, PDAs, etc. -<p>In doing the above, improvements to the IIOP protocol engine in terms -of size/performance/determinism will be made. -<li> -Tweak the IDL compiler to generate code that's more easily integrated back -into the ORB Core, e.g., POA, etc. This will depend largely on our ability -to generalize the changes necessary to generated code.</li> - -<li> -The generated sequence classes should not be generated per sequence, but -per type and parent scope. Which means, that the overhead of having the -source code generated serveral times should be reduced. To do this, an -extra pass over the internal representation of the IDL file has to be done.</li> - -<li> -Unix's native wchar_t type is not compatible with Unicode. CORBA wide string -implementations are required to support Unicode, but are not restricted to -it, so the IDL compiler should ultimately support Unix's wchar_t as well. -</ul> - - - -<br><!--#include virtual="orbcore.html" --> -<hr> - -<h3> -<a NAME="pp"></a>Pluggable Protocols</h3> -Point of contact: <a href="mailto:fredk@cs.wustl.edu">Fred Kuhns</a> -<p>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. -<p>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. -<p>There will be several stages of the development proccess: (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: -<ul> -<li> -<b>Basic pluggable transport protocols framework</b>: We have added -several Bridge classes that decouple the transport-specific details from -the rest of TAO's ORB Core. This allows us to isolate the details of how -messages are communicated at the transport layer in a few classes. This -design resulted in the restructuring of the ORB Core and how requests are -handled. For instance, there is now the concept of communication layers: -Objects (e.g., references, method invocations, etc.), ORB Messaging, Transport, -and Network. The Object layer is just the usual stubs and skeletons.</li> - -<p>The common interfaces have been defined in the new abstract classes -that form the core of TAO's pluggable protocol framework, e.g., -<tt>TAO_Connector</tt>, -<tt>TAO_Acceptor</tt>, -<tt>TAO_Profile</tt> -and <tt>TAO_Transport</tt>. Two new mechanisms for keeping track of supported -transport protocols are the -<tt>TAO_Connector_Registry</tt> and -<tt>TAO_Acceptor_Registry</tt>, -which are essentially Abstract Factories that produce the right types of -connector, acceptors, and transports. <p> -<li> -<b>Multiple Profile</b> - Support for more than one profile per object. -This is important since there may be several different ways to access an -object. Each profile for an object may encode information pertaining to -QoS, network and transport protocols, addresses or routes.<p> - -<li> -<b>Example Transport protocols</b>- The first example, aside from IIOP, that -has been implemented, UIOP, uses local IPC. Other interesting transport -protocols would be for ATM, Buses (VME or PCI), shared memory, TP4, GSMP, and -UDP/IP.</li> <p> - -<li> -<b>Pluggable ORB protocols</b> - This step will add support for ORB protocols -besides GIOP. In particular, we will explore lightweight protocols using -shared memory and system buses like PCI or VME.</li> -</ul> -Current Status: -<ul> -<li> - -The basic framework to support pluggable transport protocols has been -completed. The standard TAO regression tests <tt>MT_Cubit</tt>, -<tt>Multiple_Inheritance</tt>, <tt>CDR</tt> and <tt>EC_Throughput</tt> -can be used to verify performance using the new framework.</li><P> - -<li> - Multiple endpoint support in the ORB has been added. A - list of TAO_Acceptors is kept in the Acceptor - Registry. When the ORB needs to create an IOR it iterates - over all the acceptors to do so. Using either multiple - <code>-ORBEndpoint</code> 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: <code>iiop://foo.bar.com:0</code>), - this format can be extended to support different - protocols. -</li><P> - -<li> - If the user does not specify a list of endpoints then the - ORB creates a default endpoint for each protocol - configured. -</li><P> - -<li> - Added support for multiple Connectors in the ORB, the ORB - finds the correct connector based on the tag for the - profile. -</li><P> - -<li> - Added support for multiple profiles in the IORs, when the - ORB demarshals an IOR it queries the Connector Registry to - create the right kind of profile for the known protocols. - If one of the protocols is unknown we create a special - profile class that can only be used for marshaling and - demarshaling, not communication. -</li><P> - -<li> - Enabled the UIOP protocol, this protocol uses local IPC - (aka UNIX domain sockets) as the transport mechanism. The - protocol is loaded by default. If no explicit - <code>-ORBEndpoint</code> option is used (ex: - <code>-ORBEndpoint uiop:///tmp/my_rendezvous</code>). - -</li><P> - -<li> - Protocols can be dynamically loaded into the ORB: The - default resource factory reads the protocol "names" from - its list of arguments. These protocol names are used to - load an abstract factory via the service configurator. - This factory can create acceptors or connectors on demand. - By default only IIOP and UIOP (if supported by the - platform) are loaded. -</li><P> - -<li> - -The service configurator is now used to load protocol factories. - -</li><P> - -<li> - The <code>-ORBHost</code> and <code>-ORBPort</code> - options are deprecated. The new <code>-ORBEndpoint</code> - option supercedes them. If the deprecated options are - used, the ORB issues a warning. The user should not - depend on the existence of these options in the future. -</li><P> - -<li> - The <code>-ORBPreconnect</code> option supports multiple - protocols using the same URL formats that - <code>-ORBEndpoint</code> does. Note that the old - <em><code>host:port</code></em> format is supported for - backwards compatibility, but the user should not depend on - the existence of this old format since it is now deprecated. -</li><P> - -<li> - The URL style object reference format has been updated to - conform with the format that <code>iioploc</code> - uses. The BNF specification for <code>iioploc</code> is: - -<blockquote><code> -<iioploc> = "iioploc://"[<addr_list>]["/"<key_string>]<br> -<addr_list>= [<address> ","]* <address><br> -<address> = [<version> <host> [":" <port>]]<br> -<host> = DNS-style Host Name | ip_address<br> -<version> = <major> "." <minor> "@" | empty_string<br> -<port> = number<br> -<major> = number<br> -<minor> = number<br> -<key_string> = <string> | empty_string<br> -</code></blockquote> - - In TAO, <code>iiop</code> URL style object references are - equivalent to <code>iioploc</code> URL style object - references. <code>uiop</code> URL style object references - have a similar syntax: - -<blockquote><code> -<uioploc> = "uioploc://"[<addr_list>]["|"<key_string>]<br> -<addr_list>= [<address> ","]* <address><br> -<address> = [<version> <rendezvous point>]<br> -<rendezvous point> = Valid Filesystem Path<br> -<version> = <major> "." <minor> "@" | - empty_string<br> -<major> = number<br> -<minor> = number<br> -<key_string> = <string> | empty_string<br> -</code></blockquote> - - Note that the key string delimiter for <b><code>uiop</code></b> - is a vertical bar `<b><code>|</code></b>' (the command line - "pipe" symbol) not a forward slash - `<code>/</code>'. 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. -</li> -<P><li> - The <i>rendezvous point</i> for <code>uiop</code> 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: - <blockquote><li> - To guarantee portability, local IPC rendezvous - points (including the path and filename) should not - be longer than 99 characters long. Some platforms - may support longer rendezvous points, usually 108 - characters including the null terminator, but - Posix.1g only requires that local IPC rendezvous - point arrays contain a maximum of <b>at least</b> - 100 characters, including the null terminator.<P> - - 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. - </li> - <P><li> - Avoid using <em>relative</em> paths in your UIOP endpoints. - If possible, use <b><em>absolute</em></b> paths - instead. Imagine that the server is given an - endpoint to create using <code>-ORBEndpoint - uiop://foobar</code>. A local IPC rendezvous - point called <code>foobar</code> will be created - in the current working directory. If the client - is not started in the directory where the - <code>foobar</code> 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. - <P> - It is up to the user to make sure that a given UIOP - endpoint is accessible by both the server and - the client. - </li> - <P><li> - It is important to be consistent in the use of - absolute paths and relative paths for rendezvous - points. The two types of paths should not be used - for the same endpoint. For example, if - <code>uiop:///tmp/foo</code> is specified as the - server endpoint and <code>uiop://foo</code> as a - preconnect for a client in <code>/tmp</code>, 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. <code>/tmp/foo</code> and <code>foo</code> 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.<P> - </li></blockquote> - - The <code>-ORBEndpoint</code> 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.<P> -</li> - -<p> -</ul> - -Known Issues: - -<ul> -<li> -</ul> -Critical Work: - -<ul> -<li> -None. -</li><p> - -<p> -</ul> -Future Work: -<ul> -<li> -Complete support for multiple ORB messaging protocols. - -<li> -Long term work will include adding support for pluggable ORB protocols, -as well as transport protocols. This way we can develop optimal messaging -and transport protocols for a given platform.</li> - -<p> -</ul> - -<hr> - -<h3> <a NAME="rtcorba"></a>Real-Time CORBA </h3> - -Point of contact: <a href="mailto:fredk@cs.wustl.edu">Fred Kuhns</a> - -<P> -The Real-Time CORBA specification (RT-CORBA) defines a framework for -supporting end-to-end deterministic behavior for a fixed priority CORBA -system. This specification builds on the CORBA Architecture -Specification version 2.2 and the CORBA Messaging Specification. -Primarily, RT-CORBA adds to the Policy framework defined in the -Messaging specification and adds to GIOP/IIOP version 1.1 to support -these extensions. <P> - -This effort will implement the RT-CORBA specification and required -parts of the Messaging specification. Our implementation of RT-CORBA -in TAO will occur in stages. Our initial focus will be the support of -statically configured, real-time embedded systems where it is possible -to eliminate many sources of unbounded priority inversion. This will -be followed by a more general implementation which supports more -dynamic environments and scheduling mechanisms. <P> - -Support for statically configured applications requires a framework -which allows for explicit mappings between CORBA priorities, -connections (client side), endpoints (server side), threads, objects -and invocations. By supporting such mappings, applications will -realize a greater degree of control over end-to-end priority mappings. -Essentially, applications are able to assign priorities to connections -between server and client, then using the existing Policy framework -along with new Policy objects, requests are routed to the appropriate -connections. By assigning equivalent thread and object priorities, -applications are able to ensure end-to-end priority preservation. <P> - -As a part of this initial effort we are also adding support for both -reliable and buffered oneway operations. Reliable oneway operations -are specified in the messaging specification. Reliable oneways is a -method for providing different levels of support for reliable message -delivery. Traditional oneway semantics are unacceptable in many -environments. For example, there is no guarantee that a particular -invocation will actually be delivered. Additionally, location -forwarding will not occur with traditional oneway invocations. <P> - -<P> -The Messaging specification has defined four alternative -interpretations of the oneway interface. Two of these cases do provide -for both location forwarding and positive acknowledgment from the -server that a message was received. The <CODE>SyncScopePolicy</CODE> -Policy from the Messaging Specification is used to specify the level of -reliability required. The policy is set on the client side and uses a -new flags field in the GIOP 1.2 header. The server checks this flag to -determine if a reply is required for the oneway invocation. Four -different levels synchronization are defined in the RT specification: - - <p> - <ul> - <li> - <CODE>SYNC_NONE</CODE><BR> - The ORB returns control to the client before passing the - request to the transport layer. Client is guaranteed not - to block. No location forward is done. - </li> - <li> - <CODE>SYNC_WITH_TRANSPORT</CODE><BR> - The ORB returns control to the client only after the - transport layer (e.g. TCP) has accepted the request. - Client can block. No location forwarding is done. - </li> - <li> - <CODE>SYNC_WITH_SERVER</CODE><BR> - The server sends a reply before invoking the target - implementation. A reply of NO_EXCEPTION implies that all - location forwarding has been performed and the ORB shall - return control to the client. Thus the client will block - for remote invocations. Server send reply after invoking - any ServantManager but before delivering request to - servant. - </li> - <li> - <CODE>SYNC_WITH_TARGET</CODE><BR> - Equivalent to a synchronous twoway operation in CORBA 2.2. - Server sends a reply only after the target has completed - the invoked operation. Any location forwarding will have - occurred and a SYSTEM_EXCEPTION reply may be sent. The - client is assured that the target has acted upon the - request. - </li> - </ul> - -<P> - -The underlying transport object will be enhanced to support different -oneway buffering strategies. This feature can be used to optimize -message throughput, possibly at the expense of latency. The One-Way -Buffer will be flushed under 5 conditions as specified by the -Buffering Constraint Policy: - - <ul> - <li> Timeout value expires. </li> - <li> Max byte count is exceeded. </li> - <li> Explicit flush by the user. </li> - <li> Max message count is exceeded, or </li> - <li> ORB shutdown.</li> - </ul> - - -<p>Current Status: -<ul> - -<li> SyncScopePolicy has been partially implemented. The options -currently supported are <CODE>SYNC_NONE</CODE> and -<CODE>SYNC_WITH_TRANSPORT</CODE>. </li> - -<li> Buffering Constraint Policy is completely supported by TAO -providing flexible levels of flushing and queueing in the ORB. </li> - -<li> ClientPriorityPolicy has been implemented. This TAO-specific -policy allows clients to specify priority to be used as a -selection criteria in choosing server endpoints for carrying out -consequent corba requests on objects. This client-side feature -together with the server-side capability to create multiple endpoints with -different priorities directly contributes to maintaining end-to-end -priority in a distributed system. Please see TAO/tao/TAO.idl for -ClientPriorityPolicy interface, and TAO/tests/Endpoint_Per_Priority for -its use. Current implementation does not work properly in presence of -location forward messages. <P> - -</ul> -Known issues: -<ul> -<li> -</ul> - -Critial Work: -<ul> -<li> -</ul> - -Future work: -<ul> -<li> -</ul> - -<hr> - - -<h3> -<a NAME="poa"></a>Portable Object Adapter (POA)</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a> - -The POA associates servants with the ORB and demultiplexes incoming -requests to servants. <P> - -<p>Current Status: -<ul> -<li> -TAO supports the POA spec. This section will carry updates as available.</li> -</ul> -Known issues: - -<ul> - -</UL> - -Future work: -<ul> - -</ul> - -Recently completed work:<P> - -<ul> - -<li> ORB::shutdown now properly deactives all the POA -Managers. </li><P> - -<li> - -POA Managers in TAO were previously ignored in the request processing -path on the server. This is now fixed such that their state is checked -before dispatching the client request to the servant. Only if the -state is <CODE>ACTIVE</CODE>, is the request dispatched to the -servant. Otherwise, the request is rejected. Since POA Managers start -off in <CODE>HOLDING</CODE> state, make sure to -<CODE>activate()</CODE> them before falling into the event loop. - -</li><P> - -<li> TAO's POA now properly supports both the threading policies: -SINGLE_THREAD_MODEL and ORB_CTRL_MODEL. </li><P> - -<li>The synchronization in the POA is now very optimal. For example, -the locks are not held across the invocation on the servant. The locks -are also not held across the invocation on the AdapterActivator and -ServantManagers. This allows us to use regular locks instead of -recursive locks inside the POA. This also allows multiple threads to -dispatch requests on the same POA simultaneous.</li><P> - -<li>TAO now supports reference counting between POA and servants, -including the new RefCountServantBase and ServantBase_var -classes. RefCountServantBase is a reference counted base class that -was added to the CORBA specification to avoid race conditions for -servant deletion in threaded servers. <a -href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf</a> -contains the relevant text. Check <a -href="../poa_migration.html#Reference counting Servants">here</a> on -some hints to avoid trouble.</li><P> - -<li> The POA now supports active demultiplexing of servants in the -SYSTEM_ID and the USER_ID policy. This should make the POA faster and -more predictable since there is no hashing involved and the index of -the slot where the servant is registered is in the Object Key.</li> -<P> - -<li> Previously, the complete POA name was used as the POA -identity. This scheme was inefficient in many ways including: (a) the -complete POA name can be significantly large in size, and therefore, -ineffient to pass with every method call from the client to the -server; (b) it is varible in size, and therefore, does not lend itself -to smart and effective parsing; (c) the searching based on the -complete POA name is very ineffient.</li> - -<p> 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. - -<p> 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.<P> - -<li> There were some POA objects in a typical server that are not -freed up properly, resulting in a memory leak. This has now been -fixed.</li> <P> - -<li> Timestamps in persistent IORs were not required and have been -removed.</li> <P> - -<li> POA exceptions are not not system exceptions and have been -removed from the list of system exceptions.</li> <P> - -<li> Vastly improved the ability of the POA to deal with user -exceptions, memory allocation failures, and constructor failures.</li> -<P> - -<li> We now support a minimal POA for the minimal CORBA -specification.</li> <P> - -<li> We have decided not to support active demuxing for method name -lookup. The benefit of this optimization was questionable since the -current perfect hashing scheme provide very good and predictable -behavior.</li> <P> - -Also, note that this optimization will require many changes. We would -have to use the help of the IDL compiler to modify the object key that -is passed for every method call differently. Note that this scheme -doesn't work in the case of multiple inheritance or when the client -stubs are not TAO.<P> - -<li> Improved the parsing of object keys belonging to the -RootPOA. Since this is the default POA and is commonly used, we have -given it a reserved byte in the object key in order to quickly -identify it. With the reserved bit, the active demux key for the -RootPOA is not used, and no map lookups are required.</li> <P> - -<li> POA name separator was changed from '/' to '\0'. Since POA names -are strings, this makes a better choice since there is no chance of a -conflict with the string specified by the user. </li> <P> - -<li> We have support for reactivating servants with system generated -ids. </li> <P> - -<li> The TAO specific synchronization POA policy has been -removed. </li> <P> - -<li> New examples have been added to show how servants can be -dynamically loaded from DLLs on demand. </li> <P> - -<li> Support for collocation should be much better now because the POA -can tell if we created the object reference.</li><P> - -<li> After Nanbor's recent changes for collocation, we support the -full semantics of remote objects on a collocated object. The spec -mandates that collocated object should behave <i>exactly</i> like -remote objects, which includes going through the POA, running the -Servant Managers, running the interceptors, and expecting the -reference counting behavior provided by the POA. Note that the old -scheme of direct call through to the servant is also still -available. </li><P> - -</UL> -<hr> - -<h3> -<a NAME="interfrepo"></a>Interface Repository</h3> -Point of contact: <a href="mailto:parsons@cs.wustl.edu">Jeff Parsons</a><P> - -The Interface Repository provides run-time information about IDL -interfaces. Using this information, it is possible for a program to -encounter an object whose interface was not known when the program was -compiled, yet, be able to determine what operations are valid on the -object and make invocations on it using the DII. - -<p>Current Status: TDB -<p>Known Issues: TDB -<p>Recent Work: TDB -<p>Future Work: TDB -<p> - -<hr> - -<br><!--#include virtual="OBV.html" --> -<hr> - -<h3> -<a NAME="nservices"></a>CORBA Naming Service and Interoperable Naming Service</h3> -Points of contact: <a href="mailto:marina@cs.wustl.edu">Marina -Spivak</a> and <a href="mailto:vishal@cs.wustl.edu">Vishal Kachroo</a> -<p> - -The CORBA <a href="ftp://www.omg.org/pub/docs/formal/97-07-12.pdf"> -Naming Service</a> supports a hierarchical mapping between sequences -of strings and object references. The CORBA <A -HREF="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">Interoperable -Naming Service</A> defines a standard way for clients and servers to -locate the Naming Service. It allows the ORB to be administratively -configured for bootstrapping to services not set up with the orb at -install time. <P> - -<p>Current status (as of 7th Apr 1999): -<ul> -<li> -Implementation of the CORBA Naming Service spec is complete. TAO's -Naming Service provides an optional persistence capability.</li> -<li> -Implementation of the CORBA InterOperable Naming Service is in -progress. </li> -</ul> -Recently completed work: -<ul> -<li> -Added support for Persistence (using memory-mapped files). Persistence -feature is optional, and is controlled by the command line argument.</li> - -<li> -Updated the implementation of the Naming Service to use new ACE -exception macros.</li> -<li> -Added support for the InterOperable Naming Service, which enables the -ORB to support IORs in user-friendly <CODE>iioploc</CODE> format. -These features allow the ORB to be configured to return arbitrary object -references from <CODE>CORBA::ORB::resolve_initial_references</CODE> -for non-locality-constrained objects. Two options -ORBInitRef and --ORBDefaultInitRef have been added to the orb for bootstrapping to -arbitrary services. -</li> - -<li>Added support for the Naming service to act like an agent: to understand IIOP -request messages from clients and respond with reply messages with a -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 : -<br>1. -ORBInitRef -<br>2. -ORBDefaultInitRef -<br>3. Multicast to service. -</li> - -<li> -Added a test for the InterOperable Naming Service that works in -conjunction with the current TAO examples. -</li> - -</ul> - -Work in progress: -<ul> - -<LI> Support for the iiopname format and conversions -to and from URL-style IORs. -</LI> - -<LI> -A detailed InterOperable Naming Service test. -</LI> - -</ul> -Future work: -<ul> -<li> -Support for a load balancing feature similar to the one present in ORBIX. -It will be possible to bind a group of objects under a single name, and when a client attempts to resolve the name in question, a preset policy (e.g., random, round robin, etc.) will determine which one of the object references from the group will be returned. -</li> -<li> -Support for the Naming Service to handle the IIOP -LocateRequest messages and respond with LocateReply messages with a -LOCATION_FORWARD/OBJECT_NOT_EXIST status. -</ul> - -<p> -<hr> - -<h3> -<a NAME="tservices"></a>CORBA Trading Service</h3> -Point of contact: <a href="mailto:sbw1@cs.wustl.edu">Seth Widoff</a> - -<p>The <a href="http://www.omg.org/corba/sectrans.htm#trader"> Trading -Service</a> is an implementation of the COS Trading Service -speficiation that meets the Linked Trader conformance criteria --- it -implements the <tt>Lookup</tt>, <tt>Register</tt>, <tt>Admin</tt>, and -<tt>Link</tt> interfaces, but not the <tt>Proxy</tt> -interface. Notably, the TAO trader supports the following features:<P> -<ul> <li> Multithreaded operation;</li> - -<li> -Trader federations and distributed queries;</li> - -<li> -Dynamic properties;</li> - -<li> -Modifiable properties;</li> - -<li> -All policies described in the specification;</li> - -<li> -Preference sorting;</li> - -<li> -Service type inheritance hierarchies and subtype searching.</li> -</ul> -<a href="trader.html">Trading Service documentation</a> is also available. -<p>Future Work: -<ul> -<li> -The Proxy Interface.</li> - -<li> -Persistent storage of service types and offers.</li> -</ul> -<p> -<hr> - -<h3> -<a NAME="pservices"></a>CORBA Property Service</h3> -Point of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Babu -Arulanthu</a> - -<p>Current status (as of Mar 9th, 1999): All the interfaces of this -service have been implemented. Please -go through the test examples at $TAO/orbsvcs/tests/CosPropertyService. -Property Service is has been used by the TAO's <a href="#av">Audio Video Streaming -Service</a>developed for TAO. For general documentation of the -Property Service, please read <a -href="http://www.omg.org/corba/sectrans.html#prop">The Property Service -Specification.</a> - -<P>Recent Work: -<ul> - <li> - Changed the PropertyException from Exception to struct, according - to the OMG's changes. - </li> - <li> - Changed the implementation to allocate storage for the Sequence - out parameters, eventhough their length is 0. This is according - to the CORBA specification. - </li> -</ul> - -<p> -<hr> - -<h3> -<a NAME="cservices"></a>CORBA Concurrency Service</h3> -Point of contact: <a href="mailto:tworm@cs.wustl.edu">Torben Worm</a> -<p>Current status (as of May 3rd): - -The <a href="http://www.omg.org/corba/sectrans.htm#concur"> -Concurrency Service</a> provides a mechanism that allows clients to -acquire and release various types of locks in a distributed system.<P> - -<ul> -<li> -A simple version of the Concurrency Service has been implemented, i.e. -a version without transactions. It is currently being tested.</li> -</ul> -Future Work: -<ul> -<li> -Implementation of the Concurrency Service with transactions</li> -</ul><P> -<hr WIDTH="100%"> -<h3><a NAME="av"></a>CORBA Audio/Video Streaming Service</h3> -Point of contact: <a href="mailto:naga@cs.wustl.edu">Nagarajan -Surendran</a> and <a href="mailto:yamuna@cs.wustl.edu">Yamuna Krishnamurthy</a> -<p>This is an implementation of the OMG spec addressing the <a href="http://www.cs.wustl.edu/~sumedh/research/corbaav.pdf">Control -and Management of Audio/Video Streams</a>.For more documentation on -TAO's A/V Service please have a look <A HREF="http://www.cs.wustl.edu/~naga/av.html">here</A>. - -<p><h4>Current Status:</h4> (as of Sep 1st 1999) -<p> -<ul> - <li> - The audio/video streaming service has been implemented in the full - profile. The current implementation support all the flow related - components like flowEndpoint,FDev,FlowConnection,..,etc. - </li> - <li> - Point-to_Point and Point-to-MultiPoint streams have been - implemented. - </li> - <li> - A Pluggable protocols framework has been implemented to flexibly - add new flow protocols like SFP, RTP and new transports like - ATM. The current implementation has protoocol implementations - for SFP, RTP over UDP and Multicast UDP. Please look at this<A - HREF="http://www.cs.wustl.edu/~naga/pluggable_av.ps.gz"> paper - </A> for more documentation about the implementation. - </li> - <li> - A Videoconferencing application based on Vic, a MBONE tool, has - been implemented using the AV components. Please contact <A - HREF="mailto:yamuna@cs.wustl.edu"> yamuna or <A - HREF="mailto:naga@cs.wustl.edu"> Naga </A> if you're interested. - </li> - <li> - An MPEG-1 application which streams mpeg-1 video and mpeg-1 audio - separately has been developed using the service. The client side - of the mpeg player requires X windows support.Its available in - the release at $TAO_ROOT/orbsvcs/tests/AVStreams/mpeg/source. - </li> - <li> - An Integrated Video-on-demand application has been developed - using the Trading Service and the A/V Service. The demo uses a - Java FrontEnd and JNI to talk to the TAO C++ trader client. The - demo is available in the release at - $TAO_ROOT/orbsvcs/tests/AVStreams/server_discovery. - </li> -</ul> -<p>Work in progress: -<ul> - <li> - Adding more features to the VideoConferencing application - eg. porting vat, the audio counterpart of vic to use AV components. - </li> - <li> - Adding ATM AAL5 protocol support. - </li> - <li> - Adding QoS implementation. - </li> -</ul> - -<hr> - -<p><a NAME="ts"></a><b>CORBA Time Service</b> -<p>Point of contact: <a href="mailto:vishal@cs.wustl.edu">Vishal Kachroo</a> - -<p> The <a href="ftp://ftp.omg.org/pub/docs/formal/97-02-22.pdf">Time Service</a> - allows clients to connect to Time Service Clerks and obtain globally -synchronized time. This time is calculated from the time obtained from -one or more Time Servers running on multiple machines in the -network. The service uses the TAO Implementation Repository to -activate the time servers on demand. - -<p>Current status (as of 10th Jan 1999): -<ul> -<li> -Implementation of a Distributed CORBA Time Service is complete.</li> -</ul> -Future work: -<ul> -<li> -Currently the average of the time obtained from the various servers is -considered the global notion of time. A better distributed time synchronization -algorithm can be used in the future.</li> - -<li> -Implementation of the Timer Event Service.</li> -</ul> -<p> - -<hr WIDTH="100%"> -<h3> -<a NAME="ec"></a>CORBA Event Service</h3> - -<h4> -Last updated: Fri Mar 5 20:38:26 CST 1999</h4> -Point of contact: <a href="mailto:pradeep@cs.wustl.edu">Pradeep Gore</a> -<p>The COS compliant Event Service implements the Event Service Specification: -<a href="http://www.omg.org/docs/formal/97-12-11.pdf">(.pdf)</a>, -<a href="http://www.omg.org/docs/formal/97-12-11.ps">(.ps)</a> -<br>This implementation is based on the Real Time Event service. -<h3> -Features in this release:</h3> - -<ul> -<li> -The Event Channel (<tt>$TAO_ROOT/orbsvcs/orbsvcs/CosEvent</tt>) supports -the <tt>push </tt>style event communication.</li> - -<li> -A simple test (<tt>$TAO_ROOT/orbsvcs/tests/CosEC_Basic</tt>) demonstrates -how to create and use the event channel.</li> - -<li> -Event Service (<tt>$TAO_ROOT/orbsvcs/CosEvent_Service</tt>)The Event Service -creates a COS compliant event channel and registers it with the naming -service with the default name "CosEventChannel".</li> - -<br>Please read the associated README for more details. - -<li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: -This test demonstrates how multiple CosEC's connect to one RtEC and how -multiple consumers and producers exchange events in this configuration.</li> -</ul> -<h3> -Known bugs:</h3> -<ul> -<li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: -Once the tests are done, the control doesn't return to the shell, -you have to say CTRL-C to get back to the prompt. -</li> -</ul> - -<hr WIDTH="100%"> -<h3><a NAME="log"></a>CORBA Telecom Log Service </h3> - -<h4> Last updated: Sun Oct 17 14:35:11 CDT 1999 </h4> -Point of contact: <a href="mailto:pradeep@cs.wustl.edu">Pradeep Gore</a> -<p>The CORBA <a href="http://www.omg.org/cgi-bin/doc?telecom/98-12-04"> Telecom Log Service </a> prototype was released in TAO version 1.0.6. - -<br> -<h3> Features supported in the first version:</h3> - -<ul> - <li> - The Log Service implementation under <tt>$TAO_ROOT/orbsvcs/orbsvcs/Log</tt> - implements the <tt>DsLogAdmin </tt>module. - <br> - </li> - - <li> - The Logging_Service (<tt>$TAO_ROOT/orbsvcs/Logging_Service</tt>) starts the Log - Service and registers the Log Service Factory with the Naming Service - as "BasicLogFactory". - <br> - </li> - <li> - The test <tt>$TAO_ROOT/orbsvcs/examples/Log/Client</tt> demonstrates - a simple use of the Log Service. - <br> - </li> - <li> - The Query Language supported at present is "TCL". - The Log record id and Log record time are treated as properties - of the log and can be referenced in a query as "id" and "time" - respectively. - <br> - </li> -</ul> - -<h3> Things to be done: </h3> -<ul> - <li> - Write a more complete test to thoroughly check all features of the Log Service. - <br> - </li> - <li> - Implement a few remaining methods - <br> - For the <tt>Log</tt> interface: - setting the max. record life, log duration, weekly scheduling and copy.<br> - For the <tt>LogMgr</tt> interface:list_logs_by_id - <br> - </li> -</ul> - -<h3> Future work and enhancements: </h3> -<ul> - <li> - Support the <tt>DsEventLogAdmin </tt> module, which uses - the <a href= "#ec">COS Event Service </a> - <br> - </li> - <li> - Support the <tt>DsLogNotification </tt> module after the - <tt>CORBA Notification Service</tt> is complete. - <br> - </li> - <li> - Currently all Log records are stored in memory, later we could add - support for persistant storage. - <br> - </li> - <li> - Support "Extended TCL" as the Query Language. - <br> - Support the record attributes as name-value pair properties. - <br> - </li> - <li> - Use Red-Black trees to optimize lookup on frequently used query keys - - namely record id's and time. - <br> - </li> -</ul> - -<!--#include virtual="ec.html" --> -<p> -<hr> - -<h3> -<a NAME="scheduling"></a>TAO's Scheduling Service</h3> -Point of contact: <a href="mailto:cdgill@cs.wustl.edu">Chris Gill</a> -and <a href="mailto:levine@cs.wustl.edu">David Levine</a> -<p>Currently Implemented Features: -<ul> -<li> -The scheduling service can be built to use either a null implementation -or a strategized implementation of the configuration scheduler.</li> - -<li> -The null scheduler implementation, which is built by default, allows the -configuration scheduler to be used with applications that require a scheduling -service interface, but do not (at least in the current stage of their development, -in certain configurations, etc.) make use of the real-time scheduling features -it provides.</li> - -<li> -The strategized scheduler implementation can be built by #defining TAO_USES_STRATEGY_SCHEDULER, -and the appropriate scheduling strategy macro (TAO_USES_RMS_SCHEDULING, -TAO_USES_EDF_SCHEDULING, TAO_USES_MUF_SCHEDULING, or TAO_USES_MUF_SCHEDULING) -in $ACE_ROOT/ace/config.h. This allows the configuration scheduler to be -used with applications that require a specific scheduling strategy. Each -scheduling strategy will produce a set of static scheduling priorities, -which it will assign to operations based on their RT_Infos. For each static -priority, a strategy will also determine the run-time (dynamic) scheduling -strategy to use for that priority level.</li> -</ul> -Future work: -<ul> -<li> -Implement heap-based dispatching queues.</li> - -<li> -Add support for additional configurability, especially in the type -of dispatching strategy (list vs. heap) that will be used to dispatch operations -at a given static priority level.</li> - -<li> -Benchmark the various alternative strategies to obtain performance -profiles across different operation loads and OS platforms.</li> - -<li> -Add increased functionality. Requests and suggestions are welcome.</li> -</ul> - -<hr> - -<h3> -<a NAME="logging"></a>TAO's Logging Service</h3> -Point of contact: <a href="mailto:mjb2@cs.wustl.edu">Matt Braun</a> -<p>Current status (as of August 4'th): -<ul> -<li> -The basic logging service has been implemented. It can log basic messages -from multiple clients. It is currently in the testing stage.</li> -</ul> -Future work: -<ul> -<li> -Add increased functionality. Requests and suggestions are welcome.</li> -</ul> - -<hr> - -<h3> -<a NAME="apps"></a>Test & Performance Tests</h3> -Point of contact: <a href="mailto:naga@cs.wustl.edu">Nagarajan Surendran</a> -<p>Current Status: -<p>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. -<p>The various tests in the tests/POA test the different features of the -Portable Object Adapter interface like Explicit Activation, On Demand Activation,etc.. -<p>MT_Cubit: -<p>Current status: -<p>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: -<ul> -<li> -<i>Server.</i> The server creates multiple CORBA objects (servants), each -with different real-time priorities. This priority is implemented by using -real-time thread support provided by the operating system. Thus, requests -sent to a high-priority servant are handled by a high-priority real-time -thread, and those sent to a lower priority servant are handled by correspondingly -lower priority threads.</li> - -<li> -<i>Client.</i> The client component binds to the servants, and sends a -stream of CORBA requests to the servants. It measures the response time, -i.e. the time taken for the request to complete successfully. In particular, -it measures the time taken for requests sent to the high priority servant -to complete. The volume of lower priority requests is configurable. The -client is thus able to measure the performance of the high-priority servant -in the presence of competition from several lower-priority servants.</li> -</ul> -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. -<p>Future work: -<ul> -<li> -Study the impacts of scheduling & concurrency strategies on performance.</li> - -<li> -Evolve into a testbed for discovering sources of performance non-determinism -& priority inversion.</li> -</ul> - -<p>Pluggable: -<p>Current status: -<p>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. -<p>Future work: -<ul> -<li> -Add options to redirect the output to a file.</li> -<li> -Script or otherwise automate the piping of the output to a spreadsheet.</li> -</ul> - -<hr> - -<h3> -<a NAME="ace"></a>ORB-related ACE Changes</h3> -Points of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a> -and <a href="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</a> -<p>Recently Completed Work: -<ul> -<li> -Added special declaration to OS.h for <tt>inet_ntoa</tt> and other functions -because VxWorks doesn't provide full argument prototypes for these library -functions.</li> - -<li> -The current caching connector behaves properly in the face of a non-blocking -connect request. The "fix" is simply to not support non-blocking connects -through the cache. When the <tt>connect()</tt> fails with <tt>EWOULDBLOCK</tt>, -morph the error to -1 and clean up the request.</li> - -<li> -Service handlers obtained from the caching connector are now cleaned up. -The application needs to be able to signal that it's not using it any longer, -and, when the application encounters an error, needs to effectively close -down that connection for good so that a new connection can be initiated.</li> - -<br>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. -<br>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. -<br>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. -<br>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. -<br>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection -cache.</ul> -Future work: -<blockquote><i>None currently scheduled.</i></blockquote> - -<hr> -<h3> -<a NAME="dove"></a>The DOVE Demo</h3> -Points of contact: <a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a> -and <a href="mailto:cdgill@cs.wustl.edu">Chris Gill</a>. -<p><a href="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE</a> is documented -in detail <a href="http://www.cs.wustl.edu/~schmidt/Dove.ps.gz">online</a>. -This discussion focuses on the following goals: -<ul> -<li> -Have a DOVE Browser running using Java Beans as vizualization components.</li> - -<li> -Have the Event Channel as DOVE Agent running with an Event Consumer in -the DOVE Browser.</li> - -<li> -Having a DOVE Management Information Base (MIB), which dumps all events -transfered on the Event Channel into a file on persistent storage for later -reuse.</li> -</ul> -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. -<p>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. -<p>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. -<p>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. -<p><a href="http://students.cec.wustl.edu/~mk1/dove.html">Object Diagrams</a> -are available about this new concept. -<p>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: -<ul> -<li> -Enhancing MIB functionality</li> - -<li> -Monitoring the AV Streaming Service</li> -</ul> -For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README.<P> -<hr> - -<h3> -<a NAME="forwarding"></a>Location Forwarding</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../forwarding.html">Location forwarding</a> -<p> -<hr> - -<h3> -<a NAME="leader"></a>Global Resources and Leader-Follower Model</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../leader_follower.html">Leader-follower -model</a> -<p> -<hr> - -<h3> -<a NAME="locate"></a>Implementation of locate request</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../locate_request.html">Locate request</a> -<p> -<hr> - -<h3> -<a NAME="ami"></a>Asynchronous Method Invocation</h3> -Points of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Arulanthu</a> -, <a href="mailto:Michael.Kircher@mchp.siemens.de">Michael Kircher</a> and -<a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a> -<p>Status: -<ul> - -We've implemented the callback model of the <A -HREF="http://www.cs.wustl.edu/~schmidt/CORBA-docs/98-05-05.pdf.gz">Messaging -specification</a>. To activate the AMI for TAO and the TAO IDL -compiler define <tt>TAO_HAS_CORBA_MESSAGING</tt>, -<tt>TAO_HAS_AMI_CALLBACK</tt>, <tt>TAO_HAS_VALUETYPE</tt> and -<tt>IDL_HAS_VALUETYPE</tt> in your config.h file. The TAO IDL -compiler can generate the AMI stubs, ReplyHandler und reply stubs -using the -GC switch. -<p> -For an example see <tt>$TAO_ROOT\tests\AMI</tt> and <tt>$TAO_ROOT\examples\AMI</tt>. - -</ul> - -<p> Finished work: -<ul> -<li> Redesign of the IDL compiler to make an addtional pass over -the AbstractSyntaxTree and generate the implied-IDL code in memory. -This reduced the amount of AMI specific IDL compiler code dramatically.</li> -<li>Support for exceptions</li> -<li>Support for attributes</li> -<li>Support for deferred synchronous invocations. -<a href="mailto:parsons@cs.wustl.edu">Jeff Parsons</a></li> -</ul> -<p> Future Work: -<ul> -<li>Testing the current implementation</li> -<li>Implementation of the poller model.</li> -</ul> -<p> -<hr> - -<h3> <a NAME="interceptor"></a>Portable Interceptors</h3> -Point of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a>, -<a href="mailto:kirthika@cs.wustl.edu">Kirthika Parameswaran</a>. -<p>For more information see <a href="../interceptors.html">Portable -Interceptors</a> -</p> -<hr> - -<p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -</body> -</html> |