diff options
Diffstat (limited to 'TAO/docs/releasenotes')
| -rw-r--r-- | TAO/docs/releasenotes/TODO.html | 1613 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/ec.html | 214 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 1046 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/orbcore.html | 505 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/trader.html | 1064 |
5 files changed, 0 insertions, 4442 deletions
diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html deleted file mode 100644 index bfb4630a56a..00000000000 --- a/TAO/docs/releasenotes/TODO.html +++ /dev/null @@ -1,1613 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> -<HEAD> - <TITLE>TAO TO-DO List</TITLE> -</HEAD> - <BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - <!-- $Id$ --> - <CENTER><HR></CENTER> - - <CENTER> - <H3>General TO-DO list for TAO</H3> - </CENTER> - - <P> - This document presents our TO-DO list for TAO. - Currently, the list is not very well organized or prioritized. - It started as a personal TODO list for Carlos, so it is biased - towards the Event Service and related components. - As more people get involved it will become more - organized. - </P> - <P> - Last Updated: $Date$ $Revision$ - </P> - - <HR> - <P> - <H3>Work in progress</H3> - </P> - - <OL> - <LI><P>Implement an Implementation Repository for TAO. - <BR>[ASSIGNED TO:] Darrell. - </P> - </LI> - - <LI><P>Support the thread pool reactor in the ORB. - <BR>[ASSIGNED TO:] Nanbor. - </P> - </LI> - - <LI><P>Add support for multiple Profiles in the ORB (completing - the IIOP 1.0 support) - <BR>[ASSIGNED TO:] Fred - </P> - </LI> - - <LI><P>Implement a nice example of the COS Event Channel, - showing how it can provide filtering when combined with the - real-time Event Channel. - <BR>[ASSIGNED TO:] Pradeep - </P> - </LI> - - </OL> - - <HR> - <P> - <H3>Pending Tasks</H3> - </P> - - <H4>Performance optimizations</H4> - - <OL> - <LI><P>Location forwarding should be strategized since some - applications don't need this feature. - </P> - </LI> - - <LI>Further optimize the outgoing memory allocation by adding - support for message blocks allocated from a pool (the - Message_Block class itself not the Data_Block or the buffer it - contains). - <P></LI> - - <LI>Optimize twoways by delaying memory allocation for the - incoming data buffer, thus improving interleaving between the - client and server (the client does something useful before - starting to wait for the server). - <P></LI> - - <LI>The data blocks and their buffers could be allocated in a - single operation, using the beginning of a buffer to contain - the data block and the rest of it to contain the actual buffer - <P></LI> - - <LI><P>Some applications cannot afford compiled marshaling for - all the stubs and skeletons, - the generated code size would be too big. - Yet some operations could be critical and require code as - efficient as possible; - a <CODE>#pragma</CODE> can be added to give users - fine-grained control over code generation. - </P> - </LI> - - <LI><P>For extremely low latency applications we could remove - some fields from the IIOP protocol, for instance: - <UL> - <LI>The first four bytes are always 'GIOP' - </LI> - <LI>In homogeneous environments sending the byte order is a - waste - </LI> - <LI>Fields like the <CODE>Principal</CODE>, the services - context list, the versions can also be removed - </LI> - </UL> - <BR>[STATUS] Most of this optimizations were implemented, - and can be enabled using the <CODE>-ORBiioplite</CODE> command - line option. - </P> - </LI> - - <LI><P>Once the memory for incoming data is taken from an - allocator we can implement different approaches to manage - that memory: - <UL> - <LI>The allocator is global, allowing applications to keep - the incoming buffer even after the upcall has finished. - </LI> - <LI>The allocator is TSS, giving maximum performance for - applications that do not wish to preserve the buffer - after the upcall. - </LI> - <LI>The allocator is a TSS cache for a global memory pool, - this tries to strike a balance, by practically eliminating - the locking on each allocator/deallocation. Some strategy - is required to return the memory to the global pool, - consider, for example, - an application that will always allocate memory from one - thread and deallocate it in another thread. - </LI> - </UL> - </P> - </LI> - - <LI><P>Optimize marshaling for <CODE>TypeCode</CODE>, by not - including the optional fields on the wire; - this fields are useful (in some cases), so they should be - present for the "on memory" representation. - </P> - </LI> - - <LI><P>In some cases it is possible to marshal a complete - structure in a single operation to allow this the structure - must have fixed size (in the CDR spec sense) and its memory - layout must match the CDR layout. - </P> - </LI> - - <LI><P>If all the arguments to an operation are fixed size then - the header can be sent before the rest of the data, if the - data is big enoug this can represent a performance - improvement (because we increase overlapping between client - and server); further if the arguments also have the proper - layout they can be sent without copying to a temporary - buffer. - </P> - <P>If the arguments are not fixed size the header could be - sent before, but two passes over the data will be required. - </P> - </LI> - - <LI><P>One GIOP 1.1 is implemented we could use fragments to - minimize the buffer allocations: - the buffer could be fixed size and we simply send fragments - for each buffer. - </P> - </LI> - - <LI><P>Demarshaling and managment of Anys could be optimized, - they esentially keep a copy of the CDR stream, - but they could just keep a reference (and increase the - reference count). - </P> - </LI> - - <LI><P>Some uses of DSI can optimized also, - for instance, - if the application is simply going to forward the request to - another object there is no need to parse the arguments in - the CDR stream and decompose them in the arguments, - a single *big* CDR stream can be kept. - </P> - </LI> - - <LI><P>In the collocated case the generated - <CODE>_narrow()</CODE> method calls the - <CODE>_create_stub()</CODE> method that allocates several - temporary objects. - </P> - </LI> - - <LI><P>For various projects, we need to produce a - minimal-footprint TAO ORB. One thing we could probably do - very easily would be to provide an #ifdef that will - conditionally omit the servant manager, POA manager, and - adapter activator features from TAO, along with all the - demuxing features that aren't active demuxing or perfect - hashing. - </P> - </LI> - - <LI><P>The CDR streaming classes compute the alignment on each - operation, but they could remember the alingment from the - previous insertion or extraction operation; saving a few - cycles but spending a little more memory. - </P> - </LI> - - </OL> - - <H4>New features and Bug fixes</H4> - <OL> - <LI><P><B>EC:</B>Complete the implementation of the new EC, - specially generate the strategies and changes required to - support hard real-time behavior. - </P> - </LI> - - <LI><P><B>EC:</B>Optimize the updates to the SupplierFiltering - module, specially when it is a singleton: currently it - receives a <CODE>connected</CODE> call for each supplier, - event though one would be enough. - </P> - </LI> - - <LI><P><B>EC:</B>The supplier filters could depend on the QoS - data, as consumer filters do. We should provide a factory - for them too. - </P> - </LI> - - <LI><P><B>EC:</B>We need to provide simple operations to update - the subscriptions of a consumer, as well as the publications - of a supplier, the current scheme (disconnecting and - connecting again) is inefficient. - </P> - </LI> - - <LI><P><B>EC:</B>We need some strategy in the EC to periodically - flush out mibehaving suppliers and consumers. Examples of - misbehavior include: suppliers flooding the EC; - consumers or suppliers that are destroyed, but were not - disconnected; - consumers that are not accepting events (risking a - dead-lock); - etc. - </P> - </LI> - - <LI><P><B>EC:</B>Sometimes the Event Channel dead-locks during - shutdown. According to Ulf Jährig <jaehrig@desys.com>>;, an - easy way to reproduce the problem is to run the - EC_Throughput test under windows NT. - </P> - </LI> - - <LI><P><B>IDL Compiler:</B>Support for the <CODE>version</CODE> - pragma, this also requires some changes in the - <CODE>_is_a()</CODE> implementation. - </P> - </LI> - - <LI><P>Support native C++ exceptions. - This entails the following subtasks:<P> - <OL> - <LI>Create exceptions with the right dynamic type on the - client side. - For SII this should be simple: - the stub give us a list of the - possible user exceptions together with the factory methods - to allocate an exception of each type; - if the exception is not on that list we throw a - <CODE>CORBA::UNKNOWN</CODE>. - For DII we have to throw a - <CODE>CORBA::UnknownUserException</CODE>; - the user will receive the real exception inside an - <CODE>Any</CODE> then and she will have to extract it - either using the >>= operator or using the - forthcoming <CODE>DynAny</CODE>. - System exceptions are even easier, we always know how - to create them. - <BR>[STATUS] SII is working OK, we still need to complete - the support for DII. - <BR>[STATUS] The DII support was completed, but remains - untested. - <P></LI> - - <LI>Add the _raise() method to the exceptions. - <BR>[DONE] - <P></LI> - - <LI>On the server side: catch any CORBA exceptions thrown by - the upcall, and then transform that into the - proper <CODE>Reply</CODE> to the client side. - In the case of another C++ exception should we do - something? - <BR>[DONE] - <P></LI> - - <LI>On the client side, after creating the exception with - the right dynamic type we must invoke - <CODE>_raise()</CODE> on it. - <BR>[DONE] - <P></LI> - - <LI>Provide a TSS default value for the CORBA_Environment, - all the methods in the ORB library should use this - default. - <BR>[DONE] - <P></LI> - - <LI><B>IDL Compiler:</B>The IDL compiler should be able to - generate the - alternative mapping, but with the TSS default for the env - argument. - <BR>[DONE] - <P></LI> - - <LI><B>IDL Compiler:</B>The IDL compiler should generate the - standard mapping, without the environment argument. - <P></LI> - - <LI>In general we will need to complete and debug the - <CODE>TAO_TRY</CODE> macros; - they have limitations when dealing with the - alternative mapping, but are very useful. - <BR>[STATUS] This seems to be OK now, the code seems to - compile and work correctly now. - <BR>[STATUS] We need a new macro (TAO_TRY_THROW) to use - inside the TAO_TRY blocks, because TAO_THROW will not go - into the TAO_CATCH blocks, even if the exceptions match. - <P></LI> - - <LI>We need to test the ORB for resource leaking in the - presence of exceptions. - <P></LI> - - <LI>We <EM>could</EM> write portable server side code with - any of the mappings above if we use a macro for the env - argument, but the results are ugly: - <PRE> -// IDL -interface Foo { - void bar (in long x); -}; - -// C++ -class Foo { - void bar (CORBA::Long x TAO_ENV_ARG) - TAO_THROW_SPEC ((CORBA::SystemException)); -}; - </PRE> - note the missing comma before the TAO_ENV_ARG parameter. - <P> - </P> A different alternative is to generate both - functions, and make the default implementation just invoke - the other: - <PRE> -// IDL -interface Foo { - void bar (in long x); -}; - -// C++ -class POA_Foo { - void bar (CORBA::Long x, CORBA::Environment& env) - TAO_THROW_SPEC ((CORBA::SystemException)) - { - this->bar (x); - } - void bar (CORBA::Long x) - TAO_THROW_SPEC ((CORBA::SystemException)) = 0; -}; - </PRE> - The problem is: which alternative should be the pure - virtual function? Which one is overriden by the user? - <P></LI> - - </OL> - <BR>[STATUS] The main task ahead is to generate the conforming - mapping for the server side, i.e. remove the - <CODE>CORBA::Environment</CODE> argument and generate the - throw specs. - We need to wait for the compiled marshaling support to - implement this feature, otherwise the number of conflicts, - visitors and factories will grow without limit. - </P> - </LI> - - <LI><P><B>EC:</B> Automate EC multicast group usage. This probably - requires some kind of server that mantains the relation - between event type/source and the mcast groups. - <BR>[STATUS] The multicast map server was defined, an - example implementation that hardcodes the port, and casts - the event type into the mcast address was implemented. - <BR>[STATUS] An advanced example that uses multiple mcast - groups per process was developed; this example would be used - To test the required features for general mcast support. - <BR>[STATUS] The example is able to automatically join and - leave multicast groups, as the consumer set on a local EC - changes. - The test has been constructed to minimize resources, it only - uses one socket for outgoing multicast messages; - currently it uses only one socket for each local group of - multicast UDP addresses sharing the same port; - eventually more sockets may be needed, - as sockets have limits on the number of multicast groups - they can join. - </P> - </LI> - - <LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> can be - required to subscribe for events by source, but the source - can be local instead of remote. - This is not a problem since the Event Channel supports - multiple supplier IDs, - but we could check the local publications and remove those - events from the Gateway publication and subscription list. - </P> - </LI> - - <LI>Support IIOP 1.1 in the ORB - <P></LI> - - <LI>Use the IIOP 1.1 profile info to pass QoS info and use it to - preserve end-to-end QoS. - <P></LI> - - <LI>Support IIOP 1.2 in the ORB - <P></LI> - - <LI>Support GIOP 1.1 in the ORB (fragments) - <P></LI> - - <LI>The size of pre-allocated buffer for the outgoing CDR - streams is defined at compilation time; but if we use an - efficient enough allocator we could make its size configurable - via the svc.conf file. In any case the *second* (and - subsequent) buffers come out of the allocator, so their sizes - could be configured in the already mentioned file. - <BR>[NOTE] We have to be able to do this while minimizing the - number of calls to ORB_Core_instance() - <P></LI> - - <LI><B>IDL Compiler:</B> The IDL compiler front-end should be - case insensitive, - more precisely it should flag identifiers that only differ by - case as a conflict and verify that all uses of an identifier - have the same case. - <P></LI> - - <LI><B>IDL Compiler:</B> The operation tables do not need to be - statics, they could be created on creation of the first - servant of that type. - <P></LI> - - <LI><B>IDL Compiler:</B>Support for unions with default cases - (implicit or explicit) - in the IDL compiler is incomplete. - <P></LI> - - <LI>It seems that some memory is leaked from the ORB cached - connector. - <P></LI> - - <LI><B>IDL Compiler:</B>Support for the <CODE>fixed</CODE> data - type in the IDL compiler - <P></LI> - - <LI>CDR stream support for <CODE>wchar</CODE> is flaky or at - least untested. - <P></LI> - - <LI>Add a <CODE>corbafwd.h</CODE> header file to eliminate the - deep (and recursive) header dependencies in TAO. - <P></LI> - - <LI>Add << and >> operators to the - <CODE>CORBA::Request</CODE> class, to simplify DII invocations - (this is an Orbix-sism). - The IDL compiler has to generate them for the user defined - types. - <P></LI> - - <LI>Several helper structs for <CODE>Any</CODE> have to be - added, mainly: <CODE>to_object</CODE>, <CODE>to_wchar</CODE>, - <CODE>to_wstring</CODE> and their <CODE>from_</CODE> - <BR>[STATUS] Jeff added several of them, I need to check what - is missing. - <P></LI> - - <LI>Prepare the 1.0 release:<P> - <OL> - <LI>Integrate the compiled marshalling approach. - <BR>[STATUS] Andy has made great progress on this. - </LI> - <LI>Verify the GPERF is working in all the relevant - platforms. - <BR>[STATUS] As far as we know it is working correctly. - </LI> - <LI>Integrate active demux of operations? - </LI> - </OL> - <P></LI> - - <LI>Support the Sun bootstrapping mechanism for the Naming - Service - <P></LI> - - <LI>Add a -ORBlogfile flag so we can set the ACE_ERROR and - ACE_DEBUG output destination in all TAO applications - <P></LI> - - <LI>Support several calls to ORB_init() on the same thread. - <P></LI> - - <LI><B>EC:</B> Call ORB_init() in the EC threads? - [The dispatching threads for Boeing] - <P></LI> - - <LI><B>EC:</B> Build an EC example that uses all the cool features - (multiple endpoints on each process, collocated EC and - Scheduling Service, Naming, etc.) - <P></LI> - - <LI><B>EC:</B> Extend the Concurrency Service (or create a new - one) that allow us to have global "barriers" to synchronize EC - startup/shutdown. - <P></LI> - - <LI><B>EC:</B> Debug interval computation in Linux (and NT?) - <P></LI> - - <LI><P>Remove the uneeded methods from CORBA::Object - <BR>[STATUS] This task seems to be complete - </P> - </LI> - - <LI><B>IDL Compiler:</B> The IDL compiler could generate a static - method to access the interface repository ID of a class. - <P></LI> - - <LI><B>IDL Compiler:</B> The IDL compiler should support - <CODE>#include "orb.idl"</CODE> properly. - IMHO it should not - add any <CODE>#include</CODE> to the generated code and the - <CODE>orb.idl</CODE> file should contain all the declarations, - except for the pseudo objects that are should be hardcoded - into the compiler. - <P></LI> - - <LI>The current scheme for the orbsvcs leaves the user without - control over collocation of servants, we need to move to a scheme - similar to the one in $ACE_ROOT/netsvcs. - <BR>[STATUS] The user can control collocation, but we need a - dynamic way to do it (or an example) that exploits the Service - Configurator. We also may need to split the library. - <P></LI> - - <LI><B>EC:</B> Use the Service_Configurator to dynamically load - the EC Module_Factory thus making it really configurable. - <P></LI> - - <LI><B>EC:</B> Cleanup the IDL structures for subscriptions, - publications, etc. (in the EC). - <BR>[STATUS] Part of this was completed. The Header and - Payload of the events are clearly distinguished, now we need - to use only the Header in the Publication and Subscription - definitions. - <P></LI> - - <LI>Resolve the <CODE>Typecode::equal</CODE> dilemma: is it - structural or type equivalence? Or a mixin? - <BR>[STATUS] The correct interpretation seems to be: - <UL> - <LI>If the interface repository ID is not present and/or the - optional field name is not present then TypeCode::equal - should just test for structural equivalence. - <P></LI> - <LI>If the interface repository ID is present then type - structural equivalence is not enough - <P></LI> - <LI>The spec (2.2 or 2.3?) will add a - <CODE>equivalent</CODE> method to check for structural - equivalence modulo aliases - <P></LI> - </UL> - <P></LI> - - <LI><P><B>IDL Compiler:</B> The methods on the server side - <B>must</B> have a throw spec, check CORBA 2.2, 20.35 - </P> - </LI> - - <LI><P>According to Vinoski and Henning the - <CODE>CORBA::Policy</CODE> objects are also locality - constrained. - I could not find a references in the spec.</P> - </LI> - - <LI><P>Exercise the insertion and extraction operators for - <CODE>Any</CODE> in the <CODE>Param_Test</CODE>, - for example, provide a new <CODE>-i dii_any_op</CODE> - testing mode. - </P> - </LI> - - <LI><P>Test Any with variable sized types, such as structures - that contain a string inside. Jeff reports that there is a - problem when destroying Anys initialized with this types, - even if the IDL compiler generated <<= operator is used. - </P> - </LI> - - <LI><P>Include a regression test to verify that - <CODE>octet</CODE> is <B>not</B> a valid discriminator for - unions - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> CORBA 2.2 does not allow - <CODE>octets</CODE> as - constants, yet the IDL compiler does not complain about it. - </P> - </LI> - - <LI><P>Verify that the typecode for unions use a - <CODE>octet</CODE> with value <CODE>0</CODE> for the default - discriminator - </P> - </LI> - - <LI><P>Is the client side in TAO handling a - <CODE>CloseConnection</CODE> GIOP message properly? - </P> - </LI> - - <LI><P>If the connection to the server cannot be established the - right exception is <CODE>TRANSIENT</CODE>, not - <CODE>COMM_FAILURE</CODE>; this and other exception - inconsistencies have to be checked - </P> - </LI> - - <LI><P>The spec (CORBA 2.2, 20.17) defines accesor methods for the - fields of a <CODE>SystemException</CODE>. - </P> - </LI> - - <LI><P>In some platforms it may be necessary to add an extra - value to an enum to force it to be 32-bits wide. - </P> - </LI> - - <LI><P>The spec requires that strings as fields of structures be - initialized to the empty (not the null) string. - </P> - </LI> - - <LI><P>The <CODE>SINGLE_THREAD_MODEL</CODE> for the POA requires - that the execution for all request on that POA happen on the - same thread. - </P> - </LI> - - <LI><P><CODE>$TAO_ROOT/orbsvcs/tests</CODE> may require the same - hierarchy changes that were done in - <CODE>$TAO_ROOT/tests</CODE>. - </P> - </LI> - - <LI><P>The <CODE>_duplicate()</CODE> and <CODE>_narrow()</CODE> - functions can throw exceptions, yet our mapping does not - contain an <CODE>CORBA::Environment</CODE> argument. - A similar problem ocurs with - <CODE>ORB::resolve_initial_references</CODE>, the ORB can - throw the <CODE>InvalidName</CODE> exception. - </P> - </LI> - - <LI><P>Apparently the implementation for the leader-follower - model on the client side has bug: - it will add the current thread to the follower list every - time it returns from waiting in the condition variable, - assuming that it was signaled and removed every time. - </P> - </LI> - - <LI><P>By default TAO disables Nagle's algorithm, this should be - an optional feature, otherwise TAO will perform poorly over - WANs. - </P> - </LI> - - <LI><P>Improve the connection recycling strategies, for - instance, - several strategies are possible: limit the maximum number of - open sockets, probably with both HWM and LWM bounds, - with different policies to choose the socket to close (LFU, - MRU?); - or maybe be more aggresive and recycle a socket once - all the object references pointing to a server are closed. - The later approach could be easily implemented if each - IIOP_Object held a reference to the set of sockets opened to - a certain TCP/IP address. - </P> - </LI> - - <LI><P>Check that system calls like <CODE>recv()</CODE> and - <CODE>send()</CODE> are restarted if a signal is received by - the process while they are executing. - </P> - </LI> - - <LI><P>Update the collocated test in Cubit - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> The CORBA 2.3 spec clarifies the scope of a - <CODE>#pragma prefix</CODE>: - the prefix is supposed to get cleared after each - <CODE>#include</CODE>, - also the statement -<PRE> -#pragma prefix "" -</PRE> - should clear the prefix. - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> GPERF is generating a function for - each binary search table; - a generic function could be used, or at least we should add - an option to gperf to it receives that generic function as - an argument. - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> The TAO_IDL compiler does not handle - the following code sequence properly: -<PRE> - // IDL - interface Foo; - typedef sequence<Foo> FooSeq; - - interface Foo { - // anything here - }; -</PRE> - It may be necessary to have a multi-pass code generator to - solve this problem. - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> Tom Ziomek - <tomz@cc.comm.mot.com> reports that the IDL - compiler does not verify that <CODE>oneway</CODE> operations - cannot include a <CODE>raise</CODE> expression. - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> We must also check that oneways do - not contain any <CODE>out</CODE> or <CODE>inout</CODE> - parameters. - </P> - </LI> - - <LI><P>Currently we use blocking writes for the request, we need - to change this so we use the Reactor to send the data - instead of blocking directly on the <CODE>writev</CODE> call. - </P> - </LI> - - <LI><P><B>ORB:</B> - When handling a forward request we may get forwarded to a - collocated object. - The typical scenario is a server that register with the - Implementation Repository: - if it creates an object reference to a local object the - object reference will be pointing to the ImplRepo and - potentially none of its profiles will match the local ones. - Trying to contact the ImplRepo will result in a - LOCATION_FORWARD exceptions (and/or a LocateReply) pointing - to the local endpoints, but now we should use collocation. - </P> - </LI> - - <LI><P><B>ImplRepo:</B> - How do the ImplRepo and pluggable protocols interact? What - if the ImplRepo is using a protocol that is not implemented - in the server? Or vice-versa? - </P> - </LI> - - <HR> - - <!-- Things below this point are "big" tasks" that --> - <!-- could require major work --> - - <LI><P>Provide mechanisms to marshal arguments into a CDR - stream, Jon Biggar contributed his proposal to the CORBA 2.3 - RTF: -<PRE> -Issue 991: Operations to add to CORBA::ORB pseudo-object - -Proposal: - -[Note I have expanded the SerializedEncoding IDL type to include version -information, since we now have 3 versions of CDR!] - -The following operations should be added to the CORBA::ORB -pseudo-object: - -module CORBA { - interface ORB { - ... - typedef sequence<octet> SerializedData; - typedef unsigned long SerializedFormat; - - const SerializedFormat ENCODING_CDR = 0; - - struct SerializedEncoding { - SerializedFormat format; - octet major_version; - octet minor_version; - }; - - SerializedData serialize(in Any data, - in SerializedEncoding how); - Any unserialize(in SerializedData data, - in SerializedEncoding how); - SerializedData serialize_value(in Any data, - in SerializedEncoding how); - Any unserialize_value(in SerializedData data, - in SerializedEncoding how, - in TypeCode tc); - ... - }; -}; - -These operations provide a standard mechanism for serializing and -unserializing the data in an any, along with hooks to support new -encoding formats as they are needed. The type SerializedEncoding -indicates the encoding mechanism to use to serialize and unserialize the -data. The format field specifies what encoding rules to use when -serializing the data, and the major_version and minor_version indicate -what version of the encoding rules to use. - -The serialize and unserialize encode the TypeCode along with the value -so that the serialized data is self contained. The serialize_value and -unserialize_value version encodes the value without the TypeCode to save -space, but a TypeCode must be supplied to unserialize the data. - -Since the serialized data may contain no indication of machine dependent -issues such as byte order, the serialized data can only be guaranteed to -correctly be unserialized on the same ORB. The IDL any type should be -used to exchange information between ORBs. - -Data encoded using the ENCODING_CDR format will be encoded using CDR -encapsulation format. -</PRE> - - </P> - </LI> - - <LI><P>Add support for Smart Proxies to the ORB</P> - </LI> - - <LI><P>The ORB should support server side and client side - interceptors</P> - </LI> - - <LI><P>The ORB does not have an interface repository</P> - </LI> - - <LI><P>Once the interface repository is in place we could add - support for CORBA script - </P> - </LI> - - <LI>The current scheme for Typecode (keeping a CDR buffer with - their representation) is broken; we should use classes for - each variant of a TypeCode; but initialization would be - complicated then. - <P></LI> - - <LI><P>The CORBAlite RFP is very interesting IMHO we just need to - remove features from TAO to make it a CORBAlite - implementation. The problem is how to keep the full blown - CORBA implementation also, this is an idea: - Write the TAOlite version of a class (example TypeCode):</P> - - <PRE> - class TAO_CORBAlite_TypeCode { - // Just the CORBAlite methods are implemented. - }; - </PRE> - - <P>Derive the full blown implementation:</P> - - <PRE> - class TAO_CORBA_TypeCode : public TAO_CORBAlite_TypeCode { - // Declare all the other methods. - }; - </PRE> - - <P>create two namespaces:</P> - - <PRE> - // in tao/CORBAlite.h - class CORBA { - tyedef TAO_CORBAlite_TypeCode TypeCode; - }; - - // in tao/CORBAfull.h - class CORBA { - typedef TAO_CORBAfull_TypeCode TypeCode; - }; - </PRE> - - <P>then (at compile time) the users chooses between the CORBAlite - or CORBAfull implementations:</P> - - <PRE> - // In $TAO_ROOT/tao/corba.h - #if USERS_WANTS_FAT_FREE_CORBA - #include "tao/CORBAlite.h" - #else - #include "tao/CORBAfull.h" - #endif - </PRE> - - <P>We need to consider how to support even smaller profiles that - the CORBAlite RFP, like removing <CODE>Any</CODE> or - <CODE>fixed<></CODE> support. - We also need to come out with a scheme to support - interpretive marshalling in the CORBAlite framework (where - TypeCodes don't have enough methods as to traverse them). - </P> - <P> - </LI> - - <LI><P>Consider decompositions of the ORB that would allow - dynamically linked plug-ins, for example it should be easy to - dynamically load a pluggable protocol. - Other decompositions are harder, but still worthwhile looking - at: - <UL> - <LI>Dynamically load the support for costly features, as the - ImplRepo or Location Forwarding. - <P> - </LI> - <LI>Dynamically configure POA with or without support for - holding state. - <P> - </LI> - </UL> - </P> - </LI> - - <LI><P><B>IDL Compiler:</B> Currently the IDL compiler creates an - operation table that - includes all the base classes operations; this permits the - generation of efficient code that does not rely in - dynamic_cast or the _downcast() method for Servants (which - compare strings, hence it is slow). - It could be interesting to implement the alternative approach - were the class only looks its own operations and then tries - the parent. This will reduce code size, but will probably - decrease performance. - </P></LI> - - <LI>Server_Request objects in TAO are magical, the _duplicate() - method returns 0 and release() does nothing. - The problem starts because Server_Request is allocated from the - stack (to speed up things), hence reference counting would be - useless. Adding a clone() method will work better, but the - Server_Request holds pointers to several positions in the CDR - stream, we could clone the CDR stream, but a normal - Server_Request does not own it.... In our opinion (Carlos and - Irfan) we need not worry about this until we find a use case for - it. - <P></LI> - - <LI> - The current implementation of collocation is optimal for - hard-real-time - applications, but in some cases it may be desirable to follow - the normal execution path yet minize costs for collocated - calls. - An example would include an application that activates the - objects on demand. - It would be interesting to have a half-collocated stub - implementation, that will marshall the request and then - invokes the normal path on the "server" side, but without - crossing the kernel boundary. Ideally even the serialization - could be minimized or avoided. - <P></LI> - - </OL> - -<HR><P> - <H3>Completed Tasks</H3> - - <OL> - <LI><P><B>EC:</B> The current architecture of the real-time - Event Channel does not support some features, such as: - <UL> - <LI><P><B>EC:</B> Some applications are both suppliers and - consumers of events, - they may be interested in all the - events of type <B>T</B> unless the event is generated - by them. - </LI> - <LI><P><B>EC:</B> Can we factor out the scheduling service from - the EC? - </P> - </LI> - - <LI><P><B>EC:</B> The reactive event channel can eliminate - data copies because the data does not need to survive - after the <CODE>push()</CODE> call. - </P> - </LI> - - <LI><P><B>EC:</B> Many applications require to intercept - the EC event processing, for example to keep track of - the number of events received and sent. - This requires strategized factories for many (if not - all) of the Event Channel internal servants. - </P> - </LI> - - <LI><P><B>EC:</B> Some applications require ad-hoc - filters, such as "this events must arrive in - sequence", or "wait for all this events and then send - this other event". - </P> - </LI> - - <!-- This is Boeing specific --> - <LI><P><B>EC:</B> For some applications it is insteresting - to activate the EC servants (such as the - ConsumerProxys) in different POAs - </P> - </LI> - - </UL> - We have completed a new design for the real-time event - channel that will let us implement all this features (and - others). - <BR>[DONE] The new implementation is working, we have to add - several strategies and stress test it, but the architecture - seems sound. - <BR>[ASSIGNED TO:] Carlos - </P> - </LI> - - <LI><P><B>IDL Compiler:</B>The IDL compiler could generate files - with empty - implementation classes, just to make the life of implementors - a bit easier. - <BR>[DONE] - <BR>[ASSIGNED TO:] Yamuna - </P> - </LI> - - <LI><P><B>EC:</B> Build a COS Event Channel on top of the RTEC - Event Service. - <BR>[DONE] - <BR>[ASSIGNED TO:] Pradeep - </P> - </LI> - - <LI><P><B>EC:</B>Implement fragmentation and reassembly of UDP - messages. This is important for an effective implementation - of the multicast version of the EC. The classes affected - include <CODE>UDP_Receiver</CODE> and <CODE>UDP_Sender</CODE>. - <BR>[DONE] - </P> - </LI> - - <LI><P><B>EC:</B> The Event Channel must be profiled, - quantified, etc. - Now that we have a single threaded event channel this task - is much easier, the points to investigate are: - </P> - <P> - <UL> - <LI> How many data copies does the EC make? Can we reduce it - to zero? - </LI> - <LI> How many memory allocations? - <BR>[RESULT: 8] - <BR>Can they be replaced by memory pools? - </LI> - <LI>How many locks? - <BR>[RESULT: 29 (single threaded), 31 MT] - <BR>Can we strategize locks? - <BR>Can we share a single lock for the whole dispatch? - </LI> - </UL> - <BR>[ASSIGNED TO:] Carlos - </P> - </LI> - - <LI><P>The TypeCode internal (private) state needs locking, double - checked locking is needed to avoid excessive overhead, there - is potential for memory leaks if this locking is not used. - <BR>[DONE] - </P> - </LI> - - <LI><P><B>EC:</B>The <CODE>UDP_Receiver</CODE> class has some - problems on Win32 platforms because a - <CODE>recvfrom()</CODE> call fails if the buffer is to small - for the datagram, even if the <CODE>MSG_PEEK</CODE> flag is - used. We may need to modify the - <CODE>ACE_OS::recvfrom()</CODE> call to match the unix - semantics. - </P> - <BR>[DONE] Irfan fixed the <CODE>ACE_OS::recvfrom()</CODE> - function. - </LI> - - <LI><P><B>EC:</B> When shuting down a reactive Event Channel the - timeouts for the EC have to be cancelled. - It would seem like the proper way to do that is to do it in - the <CODE>shutdown()</CODE> method of the - <CODE>Timer_Module</CODE>. - <BR>[DONE] - </P> - </LI> - - <LI><B>EC:</B> Improve configuration support in the EC, give an - example of a single threaded EC, support different dispatching - strategies, etc. - <BR>[DONE] But there are a few bugs to remove. - <P></LI> - - <LI><B>EC:</B> Correlation in the EC has a bug [?] - <BR>[DONE] Added a correlation test into the EC_Basic test, - this does not mean that all bugs have been removed, but we - don't know of any remaining bugs. - <P></LI> - - <LI><P>The methods in <CODE>CORBA::TypeCode</CODE> should be - <CODE>const</CODE>. - </P> - <BR>[DONE] - </LI> - - <LI><P>Add the <CODE>CORBA::TypeCode::_tc_Bounds</CODE> and the - <CODE>CORBA::TypeCode::_tc_BadKind</CODE> type codes. - Currently they are in the wrong namespace (just - <CODE>CORBA::_tc_Bounds</CODE>). - </P> - <BR>[DONE] - </LI> - - - <LI><P>Add compiled marshalling - <BR>[STATUS] Andy is working on this. - <BR>[DONE] The compiled marshaling code works, we still have - to fine tune it a bit. - </P> - </LI> - - <LI><P>Implement the new DynAny types. - <BR>[STATUS] Jeff is working on this. - <BR>[DONE] More testing is needed, but the basics are - there. - </P> - </LI> - - <LI><P><B>EC:</B>The <CODE>TAO_EC_Gateway_IIOP</CODE> class - receives events from a "remote" EC and pushes them on the - local EC. - The subscription and publication list for the Gateway are - the disjunction of the local EC consumer subscriptions. - Unfortunately this can result in multiple supplier_IDs for - the Gateway, the current implementation is not prepared to - handle this. - The Gateway must keep a list of suppliers, each one with a - different supplier id, - when it receives a remote event it should push the event - only to the right supplier. - It must also keep another supplier used for the events that - are of interest by their event type, regardless of their - supplier ID. - <BR>[DONE] - </P> - </LI> - - <LI><P><B>EC:</B>The Event Channel must be able to accept more - than one supplier with a given supplier ID, or at least we - should be able to configure the EC to work in such a mode. - This is required for some applications that treat the - supplier ID as a "supplier type". - <BR>[DONE] - </P> - </LI> - - <LI><P><B>EC:</B>If a Supplier disconnects while it has - consumers registered for it's Supplier_ID, - the consumers are not connected again even if the supplier - reconnects. - <BR>[DONE] - </P> - </LI> - - <LI><P>Further optimize memory allocation by using a memory pool - for the incoming CDR stream. - <BR>[DONE] The pool is configurable for the users that may - want to steal the CDR buffer. - </P> - </LI> - - <LI><P>The nested upcall support must be strategized, - some applications don't need this feature, - other applications are single threaded or use an - ORB-per-thread concurrency policy, - so using a full-blown leader follower in all cases can - result in a significant slow down. - It seems like the right way to - strategize this by changing the Client_Connection_Handlers. - <BR>[DONE] Irfan and Carlos are finished this task. - </P> - </LI> - - <LI><P>Use active demuxing in the POA to locate servants in - constant time, as well as active demuxing - in the skeletons to locate operations in constant time. - <BR>[DONE] Irfan finished this task. - </P> - </LI> - - <LI><P>Sometimes the ORB picks up the wrong name on multi-homed - hosts, - the <CODE>ACE_INET_Addr</CODE> class uses - <CODE>gethostbyaddr_r</CODE> to convert from the address into - a hostname, but it only uses the first alias. - <BR>[DONE] The current implementation tries to use the - alias that more closely matches the address of the given - host. - </P> - </LI> - - <LI><P>Many of the test programs in the - <CODE>$TAO_ROOT/tests</CODE> hierarchy are actually sample - programs or performance tests. - </P> - <P>We need to re-organize this hierarchy, following the ACE - scheme: - <UL> - <LI><B>tests</B> for programs that do regression testing. - </LI> - <LI><B>examples</B> for programs that illustrate how to use - TAO, a service or a component - </LI> - <LI><B>performace-tests</B> for programs that are used in - performance measurements - </LI> - </UL> - the same hierarchy may be needed in - <CODE>$TAO_ROOT/orbsvcs</CODE>. - <BR>[DONE] Doug did this changes already, minor revisions - many be necessary, and orbsvcs is still pending. - </P> - </LI> - - <LI>Cleanup memory managment in some of the servers, for - instance: Naming still believes that controlling the memory - for a stub will control the servants, this is not true - anymore. - <BR>[DONE] Marina fixed the Naming Service, the other services - are working OK also. - <P></LI> - - <LI><P>The mapping for the CORBA <CODE>boolean</CODE> type does - not require the <CODE>CORBA::TRUE</CODE> constant, - but it never mentions the <CODE>CORBA::B_TRUE</CODE> constant - either; in fact it recommends the usage of the literals - <CODE>0</CODE> and <CODE>1</CODE>. - We should move to use the <CODE>CORBA::TRUE</CODE> style, - because other ORBs offer the same feature, - but only use the literals, - to show the "Right Way"[tm] of doing CORBA things. - </P> - <BR>[DONE] Irfan removed the <CODE>CORBA::B_TRUE</CODE> and - <CODE>CORBA::B_FALSE</CODE> constants and replaced them with - the compliant <CODE>0</CODE> and <CODE>1</CODE> - </LI> - - <LI><P>Add an option to the IDL-compiler (e.g. -rp) meaning - "generate relative include paths". - <BR>[STATUS] Alex is working on this. - <BR>[DONE] - </P> - </LI> - - <LI><P>Add the <<= and >>= operators for - <CODE>CORBA::TypeCode</CODE> - <BR>[DONE] Jeff added the operators</P> - </LI> - - <LI>The IDL compiler should generate the code locally (not in - the directory where the .idl resides) or at least give an - option to do so - <BR>[DONE] Alex completed this, he even added an option to - select the output directory. - <P></LI> - - <LI>Are nested upcalls in different concurrency models, like - thread-per-connection working? - <BR>[STATUS] Irfan reports that this works correctly with - <CODE>thread-per-connection</CODE> - <BR>[DONE] The <CODE>NestedUpcall/Reactor</CODE> test is - giving the same results with either - <CODE>thread-per-connection</CODE> or <CODE>reactive</CODE> - strategies. - <P></LI> - - <LI>Normalize the compiled marshalling interface: the IDL - compiler is going to generate a different interface than the - code I showed in the EC_Custom_Marshal example; we need to - make all the code consistent so users have easy access to it. - <BR>[DONE] - <P></LI> - - <LI>Object references inside structures or sequences are not - decoded properly, the problem starts because the interpreter - expects a CORBA::Object_ptr, but the real type is a T_var; - virtual inheritance adds the last ingredient to the poison. - <BR>[STATUS] A possible solution is to use a T_manager_var that - has two fields a Object_ptr and a T_ptr.... - <BR>[DONE] The solution was to use - <CODE>TAO_Object_Field_T<T></CODE>, that - behaves like the _var classes, but extends them to provide - virtual methods to <CODE>_upcast()</CODE> and - <CODE>_downcast()</CODE> to and from - <CODE>CORBA_Object_ptr</CODE>. - Similar methods were added to sequences of objects. - <P></LI> - - <LI>Add options to the IDL compiler to set the suffixes. - <BR>[DONE] Alex finished this. - <P></LI> - - <LI>Support for 64bit longs in the IDL compiler - <BR>[DONE] They were supported already, but we had to test - them, I added a test to Param_Test. - <P></LI> - - <LI>The do_static_call() and do_dynamic_call() methods should - use an array of <CODE>void*</CODE> - (in the first case static and generated by the IDL compiler); - this will remove the problems with g++ and probably work - faster. - <BR>[DONE] - <P></LI> - - <LI>The IDL compiler gets confused with paths in NT, this may be - due to my changes to report errors correctly (coryan). - <BR>[STATUS] Creating a Win32 workspace to try it. - <BR>[DONE] - <P></LI> - - <LI>The current implementation of octet sequences based on - message blocks has a few problems, it cannot marshall - chains of message blocks properly. - Notice that complete support for chains of message blocks will - complicate the sequence of octets implementation (like - operator[]) and will make others either hard or expensive - (like get_buffer ()). - <BR>[STATUS] It seems like the best tradeoff would be to - support the chain during marshalling, but disable or give no - warranties for operator[] and get_buffer(). - <BR>[DONE] - <P></LI> - - <LI>Debug Memory Pools in the EC there seem to be a problem when - sending multiple events in a row (a memory leak, limit or - corruption). - <BR>[DONE] - <P></LI> - - <LI>Add suspend and resume operations to the PushConsumerProxy - and PushSupplierProxy interfaces, following the Notification - Service spec. - <BR>[DONE] - <P></LI> - - <LI>Optimize connection lookup in the client side, using "hints" - from the previous lookup, or keeping smaller sets on each IIOP - profile or a combination of both. - <BR>[STATUS] Irfan is working on - this. - <BR>[DONE] - <P></LI> - - <LI>Optimize the outgoing CDR streams by using TSS memory pools - for both the data blocks and the buffers. - <BR>[DONE] But we may consider strategizing the kind of allocator - we use (like using a free list instead of a generic - ACE_Malloc). - <P></LI> - - <LI>Optimize Octet Sequences. - <BR>[DONE] - <P></LI> - - <LI>Obtain results for the EC_Multiple test. - <UL> - <LI>Latency seems OK. - <P></LI> - <LI> Overhead: need lower priority for scavenger thread. - <P></LI> - </UL> - <P></LI> - - <LI>Debug EC_Multiple. - <P></LI> - - <LI>Your next assignment: Regenerate all methods in - _tao_collocated to avoid "inherit via dominance" warnings. - <BR>[STATUS] The IDL compiler was modified to generate a - suitable - <CODE>#pragma</CODE> that removes the warning, it reenables - the warning when leaving the file - <P></LI> - - <LI>Remove the SOLARIS2 macro from the TAO_IDL compilation. - <BR>[DONE] - <P></LI> - - <LI>Remove the preemption_prio message from Scheduling_Service. - <P></LI> - - <LI>The ORB core should be able to choose the right port for us - (in other words -ORBport 0) should work. - <BR>[DONE] - <P></LI> - - <LI>Client side optimization for Octet Sequences. - <BR>[DONE] - <P></LI> - - <LI>Minimize memory allocation in TAO - <BR>[STATUS] Down to 3 on the client side and 4 on the server - side. - <BR>[STATUS] For oneways it is down to 0 (for the common case) - on the client side and 2 on the server side. For twoways it is - 2 on both sides. - <P></LI> - - <LI>Automate subscription and publication list generation in the - EC_Gateway. - [VERY important for Boeing] - <BR>[STATUS] Completed and debugged, but the EC is still - buggy. - <P></LI> - - <LI>Debug EC shutdown and startup.... - [Specially startup for Boeign, but shutdown is important for - Purify and Quantify] - <BR>[STATUS] Shutdown is clean and startup of threads can be - controlled by the user. - <P></LI> - - <LI>Support a chain of Message Blocks in Output CDRs and use - writev() to write them. - <BR>[DONE] - <P></LI> - - <LI>Memory managment in the demarshalling engine, it is not - clear that the current scheme works in all cases (like - sequences of unions of anys). - We also need to fix sequences of object references: how does - the demarshalling engine learn about the dynamic type of the - objects? - Closely related to this is the problem of memory alignment for - different architectures, we need to develop strategies for each - one (they should only be a few) and choose the right one. - <BR>[STATUS] This seems to be working for most of the cases, the - main idea is to delay demarshalling until enough information - is available, for instance, when decoding an Any just a - reference to the CDR stream is stored, decoding actually - happens when the user invokes >>= on the any (at that point - all the info is there). - <P></LI> - - <LI>Add a new Profile type that includes the QoS info and using - for end-to-end QoS preservation. - [DEPRECATED] The IIOP 1.1 Profiles can handle that. - <P></LI> - - <LI>Show an example of the - <CODE>sequence<octet></CODE> and CDR streams. - <BR>[DONE] But the example could also include the marshalling of - plain C++ types. - <BR>[DONE too] - <P></LI> - - <LI>Test anys in the EC. - <BR>[DONE] Michael reported that they work OK on NT. - <P></LI> - - <LI>UDP for event channel and Multicast support in the EC. - <BR>[STATUS] Manual configuration using Suppliers and Consumers is - possible, automation is under research. - <P></LI> - - <LI>Unbind the EC and scheduling service from the Naming - Service. - <BR>[DONE] For the Event_Service and the examples. - <P></LI> - - <LI>Optimize oneways by not allocating the memory for the return - buffers. - <BR>[DONE] Added different Invocation classes for each case. - <P></LI> - - <LI>Fix the _non_existent call. - <BR>[DONE] The client side semantics match the new clarifications - of the C++ RTF, the server side is implemented by the IDL - compiler, though t could be a good idea to put that in the - POA. - <P></LI> - - <LI>Simplify EC configuration, a Factory class must provide the - Dispatching, Supplier, Correlation and any other Modules that - are required. - This is the right spot to add trivial Dispatching or - Correlation Modules and to dynamically load and configure the - EC. - <BR>[DONE] A Factory class is used to create the modules, only the - default factory is implemented so far. - <P></LI> - - <LI>Fix the ACE_Thread_Condition madness. - <BR>[DONE] We changed ACE so ACE_SYNCH_CONDITION expands to - ACE_Condition_Thread_Mutex - <P></LI> - - <LI>Reference counting should have locks, but we should remove - all the QueryInterface madness to make that work. The policy - for references in multiple threads is: the reference count - must be >2 if that happens. - <BR>[STATUS] The QueryInterface method (all the COM stuff for that - matter) was removed... - <BR>[DONE] - <P></LI> - - <LI>Reference counting for Typecodes is completely broken. - <BR>[DONE] - <P></LI> - - <LI>Under g++(2.7.2) the use of multiple inheritance in IDL - triggers some compiler bug, if the IDL explictly generated the - copy constructor for the skeletons (the POA_ classes) the - problem would go away. - <BR>[DONE] Fixed, Seth is testing the fixes and will commit them - soon (Tue Jul 21 14:24:56 CDT 1998) - <P></LI> - - <LI>The octet sequence optimization causes problems when Anys - get into the game. - <BR>[DONE] Seth reported that the problem was not real. - <P></LI> - - <LI>The DEEP_FREE method is also broken, sometimes we need to - release the top-level memory, sometimes not. - <BR>[DONE] We always release the memory in the Any, it was failing - due to weird interactions between the Environment containing - an exception and the Any that also did. - <P></LI> - - <LI>Improve error messages in the IDL compiler. - <BR>[DONE] At least the filename is correct now. - <P></LI> - - <LI>Support for arrays in the IDL compiler is incomplete, - specially anonymous arrays. - <BR>[DONE] According to Andy this is properly supported by the IDL - compiler now. - <P></LI> - - <LI>Prepare the 0.2 release:<P> - <OL> - <LI>Execute all the tests in $TAO_ROOT/tests - </LI> - <LI>Run Param_Test (SII) and record what fails and what works. - </LI> - <LI>Run Param_test (DII) and record what fails and what works. - </LI> - <LI>Run Param_Test across Endian Borders. - </LI> - </OL> - <BR>[DONE] At last! - <P></LI> - - <LI>Move this list to the release notes. - <P></LI> - </OL> - -<HR> - -<P>Back to the TAO <A HREF="../index.html">documentation index</A>. <!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html deleted file mode 100644 index 89c4fb506e8..00000000000 --- a/TAO/docs/releasenotes/ec.html +++ /dev/null @@ -1,214 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.06 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]"> - <TITLE>Event Service Status</TITLE> -<!-- $Id$ --> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - -<H3>TAO's Real-time Event Service</H3> -Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A> -<H4> -Last Updated: $Date$</H4> - -<H3> -New on this release</H3> - -<UL> - <LI><P>Added fragmentation and reassembly support for the multicast - gateways</P> - </LI> -</UL> - -<H3> -Known issues:</H3> - -<DL> -<DT> -<I>The schedule cannot be downloaded</I></DT> - -<DD> -The Scheduling Service seems to compute proper schedules, but it is not -possible to download them, apparently there is a marshalling problem for -sequences of complex structures.</DD> - -<P>Due to this problem we have been unable to test the run-time scheduler -and performance it is impossible to complete performance measurements and -optimizations: the (global) scheduling service latency and overhead is -at least as large as the EC itself. -<P><B>Note:</B> This does not seem to be the case anymore, but the comment -will remain here until I can confirm that the problem dissapeared. -<DT> - -<P><I>Run-time scheduler requires re-link</I></DT> - -<DD> -During a normal execution of the system there is no need to use the a global -Real-time Scheduling Service, a faster, collocated implementation for the -service is available. Obviously the scheduling information is precomputed -in some config run.</DD> - -<P>Unfortunately the current scheme requires a relink of all the involved -applications against the generated tables for the run-time scheduling service. -<P>We should be able to download the schedule to the interested parties, -without need for a separate link phase. This will simplify and speed up -the developing cycle, but requires a (small and fixed) amount of dynamic -memory allocation. It could be interesting to "save" the schedule computation -in some persistent form, so startup cost are lower too. -<P>The current design contemplates a config run were a global consumer -accumulates the QoS requirements of all the objects, next an external utility -is used to force a computation and save of the schedule. In future executions -the global scheduler pre-loads this schedule and the clients simply download -the precomputed schedule, and all scheduling queries are to a local scheduling -service, without any further contact to the global instance. -<DT> -<P><I>Users have no control over service collocations</I></DT> - -<P>The user should have complete control of services collocation, using -ACE Service Configurator; currently the services must be explicitly instantiated -by the user. -<DT> - -<DT> -<P><I>Further details:</I></DT> - -<P>Many lower level issues and tasks can be found in the <A HREF="TODO.html">TODO -list</A>. - -</DL> - -<H3> -Examples</H3> - - -For general documentation on the Event Service please read <A HREF="http://www.cs.wustl.edu/~schmidt/oopsla.ps.gz">The -Design and Performance of a Real-time CORBA Event Service</A>. -<P>The simplest test for the Event Channel is <TT>Event_Latency</TT>, below -are the basic instructions to run it: -<OL> -<LI> -Compile everything under <TT>$TAO_ROOT/orbsvcs</TT>, this needs, obviously, -<TT>$TAO_ROOT/tao</TT> -and the IDL compiler in <TT>$TAO_ROOT/TAO_IDL</TT>.</LI> - -<P>Run the naming service, the scheduling service, the event service and -the test in <TT>$TAO_ROOT/TAO/orbsvcs/tests/Event_Latency</TT>; remember -to give a different port to each one, using the <TT>-ORBport</TT> option. -As in: -<P><TT>$ cd $TAO_ROOT/orbsvcs</TT> -<P><TT>$ cd Naming_Service ; ./Naming_Service -ORBport 10000 &</TT> -<P><TT>$ cd Event_Service ; ./Event_Service -ORBport 0 &</TT> -<P><TT>$ cd tests/Event_Latency ; ./Event_Latency -ORBport 0 -m 20 -j &</TT> -<P>You may want to run each program in a separate window. Try using a fixed -port number for the <TT>Naming Service</TT> so you can use the <TT>NameService</TT> -environment variable. -<P>The script <TT>start_services</TT> in <TT>$TAO_ROOT/orbsvcs/tests</TT> -can help with this. -<LI> -If you want real-time behavior on Solaris you may need to run these programs -as root; on the other hand, this particular example really has no priority -inversion, since only one thread runs at a time.</LI> -</OL> -Another example is <TT>EC_Multiple</TT>, numerous examples on how to run -this test can be found in the scripts located in <TT>$TAO_ROOT/orbsvcs/tests/EC_Multiple</TT>. - -<H3> -Features in previous releases</H3> - -<UL> - -<LI><P>Continued work on the multicast support for the EC, we added a new -server that maps the event types (and supplier ids) into the right mcast -group. Usually this server is collocated with the helper classes that send -the events through multicast, so using a CORBA interface for this mapping -is not expensive, further it adds the flexibility of using a global service -with complete knowledge of the traffic in the system, that could try to -optimize multicast group usage. -<P>The subscriptions and publications on a particular EC can be remotely -observed by instances of the <TT>RtecChannelAdmin::Observer</TT> class. -Once more using CORBA for this interface cost us little or nothing because -it is usually used by objects collocated with the EC. -<P><TT>TAO_EC_UDP_Receiver</TT> is a helper class that receives events -from multicast groups and dispatches them as a supplier to some event channel. -This class has to <B>join</B> the right multicast groups, using the <TT>Observer</TT> -described above and the <TT>RtecUDPAdmin</TT> to map the subscriptions -into multicast groups it can do this dynamically, as consumers join or -leave its Event Channel. -<P>When sending Events through multicast all the <TT>TAO_EC_UDP_Sender</TT> -objects can shared the same socket. -</P> -</LI> - -<LI><P>Added a prototype Consumer and Supplier that can send events though -multicast groups (or regular UDP sockets). -<P>The Event Channel can be configured using a Factory that constructs -the right modules (like changing the dispatching module), in the current -release only the default Factory is implemented. -<P>When several suppliers are consumers are distributed over the network -it could be nice to exploit locality and have a separate Event Channel -on each process (or host). Only when an event is required by some remote -consumer we need to send it through the network. -<P>The basic architecture to achieve this seems very simple, each Event -Channel has a proxy that connects to the EC peers, providing a "merge" -of its (local) consumer subscriptions as its own subscription list. -<P>Locally the proxy connects as a supplier, publishing all the events -it has register for. -<P>To avoid event looping the events carry a time-to-live field that is -decremented each time the event goes through a proxy, when the TTL gets -to zero the event is not propagated by the proxy. -<P>In the current release an experimental implementation is provided, it -basically hardcodes all the subscriptions and publications, we are researching -on how to automatically build the publication list. -<P>We use the COS Time Service types (not the services) to specify time -for the Event Service and Scheduling Service. -</P> -</LI> - -<LI> -<P>The <TT>Gateway</TT> to connect two event channels was moved from a test -to the library. The corresponding test (<TT>EC_Multiple</TT>) has been -expanded and improved. -</P> -</LI> - -<LI> -<P>The user can register a set of <TT>EC_Gateways</TT> with the <TT>EventChannel</TT> -implementation, the event channel will automatically update the subscription -list as consumers subscribe to the EC. -</P> -</LI> - -<LI> -<P>The code for consumer and supplier disconnection was improved and seems -to work without problems now -</P> -</LI> - -<LI> -<P>The <TT>Event_Service</TT> program creates a collocated <TT>Scheduling -Service</TT> this works around a problem in the ORB when running on -multiprocessor. -</P> -</LI> - -<LI> -<P>Startup and shutdown were revised, the event channel shutdown -cleanly now. -</P> -</LI> - -<LI> -<P>Added yet another example -(<TT>$TAO_ROOT/orbsvcs/tests/EC_Throughput</TT>), -this one ilustrate how to use the TAO extensions to create octet sequences -based on CDR streams, without incurring in extra copies. This is useful -to implement custom marshalling or late dermashalling of the event payload. -Future versions of the test will help measuring the EC throughput, hence -the name.</P> -</LI> -</UL> - -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index c2993c0bcfc..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,1046 +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> -Information is available 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>: -<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="#poa">Portable Object Adapter</a></li> - -<li> -<a href="../implrepo/status.html">Implementation Repository</a></li> - -<li> -<a href="#interfrepo">Interface Repository</a></li> - -<li> -<a href="#nservices">CORBA Naming Service and 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 Control Service</a></li> - -<li> -<a href="#ts">CORBA Time Service</a></li> - -<li> -<a href="#ec">CORBA Event 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> - -<li> -<a href="#apps">Test & 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> -</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:gokhale@research.bell-labs.com">Aniruddha -Gokhale</a> -<p>Current status: (As of Jan 22, 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> -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> -Added partial native C++ exception support:</li> - -<ul> -<li> -The ORB can be configured to catch native C++ exceptions thrown on the -server side and transmit them to the client side. On the client side exceptions -received from the wire are thrown using native C++ exceptions also.</li> - -<li> -To facilitate portability between the standard and alternative C++ mapping -the <tt>CORBA::Environment</tt> has a default value. The IDL compiler generates -code using that default value and the TAO library methods also have the -default.</li> - -<li> -Some macros are provided to facilitate portability between platforms with -and without macros.</li> -</ul> -There is still some work to do, mainly provide complete support for the -standard mapping, i.e. remove the <tt>CORBA::Environment</tt> argument -completely. -<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> -Significantly improved the support for unions. The default case is yet -to be handled.</li> - -<li> -Added support for TIE classes. If the interfaces are defined inside modules, -then the TIE class and its code gets generated inside a conditional macro. -For platforms that support namespaces, this macro will allow these TIE -classes else they get commented out. The reason to do this is because nested -templates have problems on most compilers.</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> -</ul> - -<p><br>Known bugs/unimplemented constructs: -<ul> -<li> -Generation of Managed types must somehow be moved to the ORB Core</li> - -<li> -We need support for ``TIEs'' (i.e., the object form of the Adapter pattern).</li> - -<li> -TypeCode generation for recursive types not implemented yet.</li> - -<li> -Unions with default cases yet to be handled</li> - -<li> -IDL is case-insensitive. However, it looks like our front-end is case-sensitive. -Thanks to Anil Gopinath (anil@ittc.ukans.edu) for pointing this out.</li> -</ul> -Future work: -<ul> -<li> -Need to relocate the various libraries used by the IDL compiler out of -the ACE directory. Having them here can cause problems when working with -multiple versions of TAO and a single version of ACE.</li> - -<li> -Fix bugs in the SunSoft IDL front-end we've uncovered. These primarily -include support for Unions.</li> - -<li> -Use <a href="http://www.cs.utah.edu/projects/flux/flick/">Flick</a> (from -the University of Utah) to generate compiled stubs.</li> - -<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.<P> -</ul> - - -<hr></li> - -<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're currently adding -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 has led us to restructure how TAO's ORB Core sends and receives -requests. 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 planned example aside from -IIOP will use UNIX domain sockets. 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 initial prototype of the basic framework to support pluggable transport -protocols has been compiled, linked and, tested against an older version -of TAO. The standard TAO regression tests -<tt>MT_Cubit</tt>, <tt>Multiple_Inheritance</tt>, -<tt>CDR</tt> -and <tt>EC_Throughput</tt> were run successfully.</li><P> - -<li> -The basic framework does not include support for multiple profiles and -the Acceptor registry. What it does do is separate the transport specific -processing from the rest of the ORB.</li> - -<p> -</ul> -Known Issues: - -<ul> -<li> -The ORB Core's resource factory needs to be enhanced to support the dynamic -allocation of resources for different transport protocols.</li><p> -</ul> -Critical Work: - -<ul> -<li> -Adding support for multiple profiles.</li><p> - -<p> -</ul> -Future Work: -<ul> -<li> -Immediate plans are to bring my workspace up to date with the repository -and verify all of TAO's regression tests still work. This will be followed -by performing a suite of tests to compare performance of with the unmodified -TAO distribution. Also, we'll extensively retest TAO using purify and quantify.</li><p> - -<li> -In parallel, we will add support for multiple profiles and an acceptor -registry class. The acceptor registry will both keep track of all acceptors -and be responsible for creating a list of profiles for new object references -(essentially the IOR).</li><p> - -<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="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> -<li> -The synchronization in the POA is broken. For example, the locks are held -across the invocation on the servant. The locks are also held across the -invocation on the AdapterActivator. This forces the use of recursive locks -inside the POA. However, the problem with recursive locks is that multiple -threads cannot dispatch requests on the same POA simultaneous.</li><P> - -<li> -Add the new RefCountServantBase class to TAO. This reference counted base -class 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.</li><P> - -<li> -Currently, the complete POA name is used as the POA identity. This scheme -is 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 correct solution here 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> -Timestamps in persistent IORs are not required. They should be removed.</li> <P> - -<li> -POA exceptions should be removed from the list of system - exceptions.</li> <P> - -<li> -We need to separate out the POA functionality required to support the full -CORBA spec from the POA functionality required to support the Minimal CORBA -spec.</li> <P> - -<li> -We need to investigate whether it feasible for us to provide active demuxing -for the USER_ID policy. Currently, the best we do with the USER_ID policy -is a hash table based demuxing.</li> <P> - -Note that we have to pass the user id in addition to the demux key in -order to handle servant creation on demand. <P> -<li> -We can potentially add active demuxing for method name lookup. The benefit -of this optimization is 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> -There are some POA objects in a typical server that are not freed up properly, -resulting in a memory leak. This is not very significant since the leak -does not grow. However, it still needs a fix.</li> <P> -</UL> - -Future work: -<ul> -<li> -Determine the degree to which we will 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, but that means that request -will have to be queued rather than calling a method directly, and this -could be hazardous to our quest for real-time ORB status.</li><P> - -<li> -Provide extensions of the specification to ensure real-time delivery of -messages.</li> <P> - -</ul> -Recently completed work:<P> -<ul> -<li> -Support for collocation should be much better now because the POA can tell -if we created the object reference.</li><P> - -<li> -The POA now supports active demultiplexing of servants in the SYSTEM_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> - -</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> -<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">The -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. <P> - -<p>Current status (as of 22nd Feb 1999): -<ul> -<li> -Implementation of the CORBA Naming Service spec is complete.</li> -</ul> -Recently completed work: -<ul> -<li> -The implementation of the Naming Service has been upgraded to use TAO's -exception macros, which allow it to work both with C++ exceptions and without.</li> -<li> -Destroy method has been updated.</li> -<li> -More test examples have been added to TAO/orbsvcs/tests/Simple_Naming.</li> -</ul> - -Work in progress: -<ul> -<li> -Currently the bindings are stored as a table in memory. Work is under way -to provide persistance option for the Naming Service.</li> - -<LI> Currently adding support for the Interoperable Naming Service, -which enables the ORB to support IORs in user-friendly URL formats -using the <CODE>iioploc</CODE> and <CODE>iiopname</CODE> formats. -These features allow the ORB to configured to return arbitrary object -references from <CODE>CORBA::ORB::resolve_initial_references</CODE> -for non-locality-constrained objects. In addition, two standard -<CODE>CORBA::ORB_init</CODE> arguments are being added to override the -TAO's initial reference configuration. The service provides an -extension to the existing Naming Service to include conversions to and -from URL-style IORs. - -<LI>The Naming Service is being used as an agent to understand IIOP -request messages from clients and respond with reply messages with a -LOCATION_FORWARD status. Work is in progress for the client-side -lookup tables built through commandline arguments to the ORB, -<CODE>-ORBInitRef</CODE> and <CODE>-ORBDefaultInitRef</CODE>.<P> -</ul> -Future work: -<ul> -<li> -Replication of the bindings to other Naming Service's currently running. -It will probably be modeled after the LDAP Multi-Master Replication Protocol.</li> -</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.htm#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 Control Service</h3> -Point of contact: <a href="mailto:naga@cs.wustl.edu">Nagarajan Surendran</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>. -<p>The audio/video streaming service has been implemented in the light -profile. An MPEG-1 application which streams mpeg-1 video and mpeg-1 audio -separately has been developed using the service. This application currently -works only for Unix platforms. -<p>Work in progress: -<ul> -<li> -Implementing the SFP protocol</li> - -<li> -Integrating the mpeg-1 streaming application with the trading service.</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%"> -<!--#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> -<p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -</body> -</html> diff --git a/TAO/docs/releasenotes/orbcore.html b/TAO/docs/releasenotes/orbcore.html deleted file mode 100644 index 3bbfe38e2a1..00000000000 --- a/TAO/docs/releasenotes/orbcore.html +++ /dev/null @@ -1,505 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.5b2 [en] (WinNT; I) [Netscape]"> - <TITLE>ORB Core Status</TITLE> -<!-- $Id$ --> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> - -<H3> -<A NAME="orb"></A>ORB & ORB Core</H3> -Point of contact: <A HREF="mailto:nanbor@cs.wustl.edu">Nanbor Wang</A> -<P>Last Update: $Date$ -<P><B>Current status:</B> -<UL> -<LI> -Provides dynamically linked wholesale assignment of ORB strategies for -communication, concurrency, demultiplexing, scheduling, and dispatching -using the ACE Service Configurator framework.</LI> - -<LI> -Supports several concurrency models out of the box: Reactive, Thread-per-Connection, -and ORB-per-thread. The ORB-per-thread design is optimized for real-time -I/O subsystems. (See: <A HREF="../configurations.html">Configuration Guide</A>.)</LI> - -<LI> -Supports <TT>resolve_initial_references("<CORBA Service>")</TT> using -ACE support for multicast.</LI> -</UL> -<B>Known issues:</B> -<UL> -<LI> - -Some CORBA objects need to have access to the ORB. We tend to use -<CODE>TAO_ORB_Core_instance()->orb()</CODE> to fetch the right ORB the -object is using. This is most often true when implementing the -shutdown method which allow other process to shutdown a remote -ORB. Althought this may be the "right" thing to do in TAO, it is not -CORBA compliant and hurts the portability of object implementation. A -common way of getting around this problem is to cache the ORB pointer -in the object when it is created and simply use the cached ORB when -needed. However, remember that there could be multiple ORBs in a -process and a POA may be shared by several ORBs. That means, we may -not handling the object with the same ORB it was created. Collocation -optimization further complicated the problem. <P> At the moment, using -<CODE>TAO_ORB_Core_instance()->orb()</CODE> is the only sane way to -get arond the problem. Though there may be a better way. <P> - -<LI> Object references for objects dynamically created within a server -may not have proper host. (See also <A HREF="#hostfix">recent -fix</A>.) When an object is dynamically created and its object -reference returned, it simply has to "guess" at the host information -that is returned in the IIOP Profile. Currently, it guesses using the -host name, which is a reasonable guess in most cases. However, if -there are multiple interfaces on a machine <I>and</I> they have -different host names, it is possible that the desired effect will not -be realized, i.e., the connection to that new object may use a -different interface from the original object. Currently the only way -to change this is to use the <A -HREF="../Options.html#-ORBhost"><B>-ORBhost</B> option</A> to manually -specify that dynamically-created objects bind to a specific interface -so that their IIOP Profile has the desired hostname. A more desirable -fix is being investigated.<P> </UL> - -<B>Recently Completed Work:</B> -<UL> -<LI> -The ORB Core is ready to throw exceptions received from the wire as a native -C++ exception. Similarly, on the server side, native C++ exceptions are -catched and sent over the wire to the client.</LI> - -<LI> -Added new option <TT>-ORBgioplite</TT> when this option is enabled the -ORB removes a few fields of the GIOP messages that are normally not used, -such as the version numbers, the magic 'GIOP' string, the service context, -the Principal object, etc. This option give us a slight performance improvement -but it is important for extremely low-latency systems (such as avionics), -that fortunately have tightly controlled environments so this kind of optimization -is safe to use.</LI> - -<LI> -The buffers for outgoing CDR streams are allocated from TSS memory pools, -reducing locking on the critical path.</LI> - -<LI> -Several optimizations on the critical path have been implemented, carefully -removing excesive locking, memory allocations and data copying. In some -cases special demarshaling and marshaling functions where written for the -request headers.</LI> - -<LI> -Adding a new option into TAO_Resource_Factory to control the internal lock -used by ORB's reacotr. With "<TT>-ORBreactorlock null</TT>" added into -<TT>svc.conf</TT>, you can eliminate the token inside the Select_Reactor -inside the ORB even on multi-threaded platforms. This eliminate some overheads -caused by synchronizing access to the Select_Reactor. Usually, if you have -TSS ORB and are using reactive concurrency startegy, the ORB are not accessed -by multiple threads, then, you can safely turn the lock off. - -<LI> -Strategized the connection management scheme so that we don't always have -to pay the price of a look up in the connection cache. Basically, we "hold" -a service handler for a string of requests.</LI> - -<LI> -There is no need to call ORB::open if the port is 0. It will automagically -be called when the first stub is created. - -<LI> The ORB now handles nested upcalls correctly. See <A -HREF="../leader_follower.html">this </A>for details on the design of -the solution. - -<LI> Making the collocation table configurable. We can either use a -global collocation table to share objects among ORBs, or use the -per-ORB collocation table. - -<LI> -Implement the inheritance mechanism in Default_Server_Connection_Handler -to access the parent's POA. This is necessary when we are using thread-per-connection -concurrency model. - -<LI> It is often desireable for a server to start up and not have to -specify the TCP port number on which the ORB will listen, i.e., let -the OS decide. While this works properly (by providing an argument -<TT>-ORBport 0</TT>), the actual port number used by the server won't -be available after the server starts listening. TAO now tries to bind -the address when <TT>-ORBport 0</TT> is issued so it can get the -actual address to publish the IOR for clients' use. - -<LI> Added optimization for collocated objects. This optimization -enables TAO to bypass communication layers and talks to collocated -objects directly. - -<LI> -Broke the tight coupling between <TT>CORBA_Object</TT> and <TT>IIOP_Object</TT> -so that multiple <TT>CORBA_Object</TT>s can share a single <TT>IIOP_Object</TT>. -This has a big win in <TT>_narrow</TT> operations. - -<LI> -Eliminated substantial memory leaks in servers. - -<LI> -Added documentation for <B><A HREF="../Options.html#-ORBpoa">-ORBpoa</A></B>, -which allows individual tweaking of the POA's locality (global vs. thread-specific) -independent of the locality of other ORB resources. Also, <B><A HREF="../Options.html#-ORBpoalock">-ORBpoalock</A></B> -and <B><A HREF="../Options.html#-ORBpoamgrlock">-ORBpoamgrlock</A></B> -control locking in the POA and POA manager, respectively, according to -application needs. - -<LI> -Began the process of changing the internals of TAO to use the "underbar" -namespace mapping. This should be completed soon. - -<LI> -The ORBs manipulation of object keys and object ids is now consistent. -Canonically, everything is managed as an opaque sequence of octets. Conversion -to/from strings is permitted, with non-printables turning into a trigraph -<B>\hl</B> where <B>h</B> is the high nibble digit in hex, and <B>l</B> -is the low nibble in hex.</LI> - -<LI> -<TT>CORBA_ORB::run()</TT> should be able to be called multiply in the same -execution path now.</LI> - -<LI> -Fixed the <B>LOCATION_FORWARD</B> capabilities to work as described in -the CORBA 2.1 and the POA specification.</LI> - -<LI> -Fixed problem in the IDL Cubit example which caused the server to dump -core when dealing with <TT>_out</TT> sequence types <I>ONLY</I> when compiled -with G++. It seems that G++ decided to interpret the expression <TT>output -== 0</TT> (where <TT>output</TT> is of type <TT>vector_out</TT>) differently -from Sun's C++ compiler.</LI> - -<LI> -Fixed a slight problem in <A HREF="#hostfix">other recent work</A> where -a servant listening on <TT>INADDR_ANY</TT> reported an IOR with address -<TT>0.0.0.0</TT>. It now reports the default hostname instead.</LI> - -<LI> -Working version of TAO on VxWorks with VME transport.</LI> - -<LI> -TAO now reacts gracefully in the face of a non-existent <TT>svc.conf</TT> -file or simply missing entries in the file. It logs a warning message and -uses default values versions of items which it would normally obtain from -the Service Repository.</LI> - -<LI> -<A NAME="hostfix"></A>Fixed problem where object references for objects -dynamically created within a server do not have proper host, at least if -the desired host was specified using <B><A HREF="../Options.html#-ORBhost">-ORBhost</A></B> -on the command line.</LI> - -<LI> -Added support for <B><A HREF="../Options.html#-ORBsndsock">-ORBsndsock</A></B> -and <B><A HREF="../Options.html#-ORBrcvsock">-ORBrcvsock</A></B> ORB options. -See <A HREF="../Options.html">options documentation</A> for details.</LI> - -<LI> -Added support for pre-established connections using the <B><A HREF="../Options.html#-ORBpreconnect">-ORBpreconnect</A></B> -option. This allows connections to be esablished before any CORBA requests -are made. See <A HREF="../Options.html">options documentation</A> for details.</LI> - -<LI> -Eliminated deprecated <B>-OAxxx</B> options parsed by the Object Adapter -<TT>init</TT> method but no longer used by part of the ORB.</LI> - -<LI> -Made argument parsing within the ORB and POA consume the arguments it parses.</LI> - -<LI> -Placed an optimization in IIOP::Profile that should speed up invocations -on the client side rather substantially. This was done by caching an instance -of <TT>ACE_INET_Addr</TT> in the private portion of <TT>Profile</TT> because -the cost of constructing one for every invocation (in <TT>TAO_GIOP_Invocation::start</TT>) -was simply enormous--the construction was something like 100 cycles on -Solaris. This is all because deep down this ends up calling <TT>gethostbyname()</TT>, -which can be very costly. Of course, this is platform-dependent, so the -improvements may not be as great on a different platform.</LI> - -<LI> -Got rid of need to have compile in TSS ORB Core (<TT>-DTAO_HAS_TSS_ORBCORE</TT>). -This is accomplished by having a Resource Factory (<TT>TAO_Resource_Factory</TT>) -singleton which the ORB Core consults in order to get pointers to resources. -The Resource Factory can be configured to return pointers from thread-specific -storage, or process-global storage. By doing this, the ORB Core is shielded -from ever having to know whether or not its resources are global or not.</LI> - -<LI> -Made all command-line like options look like the standard-professed options, -i.e., <B>-ORBxxx</B> or <B>-OAxxxx</B>.</LI> - -<LI> -Moved ORB option parsing into <TT>TAO_ORB_Core::init()</TT> rather than -in <TT>ORB_init()</TT>.</LI> - -<LI> -Define <TT>_FAR</TT> for all cases as an interim fix for LynxOS.</LI> - -<LI> -Fixed TAO so that the default port of 5001 is defined in <TT>orb_core.h</TT> -config header somewhere rather than in <TT>orbobj.cpp</TT>, and use <B>MAXHOSTNAMELEN</B> -ACE -constant for the hostname buffer.</LI> - -<LI> -Eliminated need for <TT>CORBA::Object</TT> to keep a pointer to its orb -sitting around anywhere.</LI> - -<LI> -Tested <TT>CORBA_ORB::shutdown()</TT> as a manner in which a thread of -control can request that <TT>CORBA_ORB::run()</TT> should return and no -longer service requests. It only honors a <I>wait_for_completion</I> argument -of <B>FALSE</B> right now because we haven't fully explored the issues -which surround doing all the completion.</LI> - -<LI> -Created a brief section in <TT><A HREF="../../TAO-INSTALL.html">$TAO_ROOT/TAO-INSTALL.html</A></TT> -that <I>briefly</I> documents installation on Unix platforms. There is -also a brief section which documents issues that apply across ALL platforms, -such as the fact that TAO and its application will likely not work well -if your ACE is linked through Orbix, VisiBroker, or another ORB. <A HREF="../../ChangeLog">ChangeLog</A> -discovery attribution for this should go to <I>Steve Wohlever <wohlever@mitre.org></I>.</LI> - -<LI> -Implemented <TT>CORBA_ORB::shutdown()</TT> as a manner in which a thread -of control can request that <TT>CORBA_ORB::run()</TT> should return and -no longer service requests.</LI> - -<LI> -Validated movement of Strategy Connector into ORB Core.</LI> - -<LI> -Tested and commited <TT>Connector::connect_n</TT> changes to ACE.</LI> - -<LI> -ACE & TAO compiling cleanly using Sun's CC on Solaris and G++ on Linux. -Also, the ACE tests run properly.</LI> - -<LI> -Use <TT>truss</TT> to verify for <A HREF="mailto:PAUL.G.WEHLAGE@cdev.com">Paul -Wehlage</A> that TAO really uses <TT>select</TT> vs. <TT>recv</TT> for -<B>-R</B> vs. <B>-T</B>.</LI> - -<LI> -Renamed <TT>boa.*</TT> to <TT>poa.*</TT>.</LI> - -<LI> -Renamed following files: Orb_Core.* ->orb_core.* & orbobj.* -> corba_orb.*.</LI> - -<LI> -The lock used in <TT>giop.cpp:626</TT> originally appeared in the IIOP-1.4 -code base. Its purpose was to protect access to the <TT>fwd_profile</TT> -data member. The original features are available, but they are currently -not used because none of our concurrency models present a thread-unsafe -condition. The <A HREF="../../ChangeLog">ChangeLog</A> presents more details -on the subject.</LI> - -<LI> -Fixed problems seen by <A HREF="mailto:brian.r.mendel@boeing.com">Brian -Mendel</A> of Boeing where the Cubit server application was crashing in -<TT>TAO_OA_Connection_Handler::handle_message</TT> when it was trying to -call <TT>CORBA::POA::handle_request</TT> through a NULL <TT>root_poa</TT> -pointer. The NULL pointer resulted from the inadvertent use of the Thread-per-Connection -concurrency model, which is currently incompatible with the ORB-per-thread -model. It was not caught because the change is normally done in configuration -files parsed by the Service Configurator, and VxWorks requires special -code in that area which was not tested until Boeing got hold of the code.</LI> - -<LI> -Clean up build under g++. All 'function used before declared inline' warnings -have been eliminated. Also, all other warnings (except for one that is -nearly unavoidable) have been eliminated.</LI> - -<LI> -Removed BOA and ROA names from the ORB.</LI> - -<LI> -Changed <TT>CORBA_ORB::open()</TT> to return an error status (first cut -at this already there--needs to be checked out).</LI> - -<LI> -Added README file to multiCubit test.</LI> - -<LI> -Added support for the -ORBInitRef option. This allows run-time specification of -an ObjectId:IOR mapping. It is used by resolve_initial_references () and -overrides the orb-install-time defaults.</LI> - -</UL> -<B>Ongoing Work:</B> -<UL> -<LI> -Verify ACE & TAO on Linux using g++, Solaris using CC, and Solaris -using g++.</LI> - -<LI> -Use Purify to eliminate straggling problems.</LI> - -<LI> -Clean up the internals and analyze for performance bottlenecks using Quantify.</LI> - -<LI> -Resolve <TT>// @@</TT> comment blocks. These are questions or comments -placed in the code by a reviewer (typically Doug).</LI> - -<LI> -Make more and better documentation on the internals of TAO.</LI> -</UL> -<B>Current Work:</B> -<UL>Verify that, in the ORB-per-thread concurrency model, it's possible -to have a factory in each thread that creates a client and returns an object -reference to that client within that thread. This is different from the -model that Sumedh originally had where the factory was trying to turn out -a client in a separate thread/ORB combination. -There is no application which attempts this at the moment, so both a -client and a server will need to be manufactured. Using existing Cubit-like -examples (that poor app is so weary) should reduce development time to -a couple of hours. -The real strategy/solution is to make <TT>CORBA::Object</TT> not keep -a pointer to its orb sitting around anywhere. It should only get it when -it needs it. This should not be difficult to change.</UL> - The interface Dynamic -Any (CORBA v.2.2) is being implemented. It will conform to and implement -all areas of the spec except for the following: -<UL> -<LI> -Interface DynFixed not implemented since TAO does not currently support -the IDL fixed data type.</LI> - -<LI> -Long double data type not supported in accessor and mutator functions.</LI> - -<LI> -Wstring (wide character string) data type not supported in accessor and -mutator functions.</LI> - -<LI> -DynUnion attribute set_as_default in treated as read only.</LI> -</UL> -<B>Critical Work:</B> -<UL> -<LI> -Identify/fix the problems in multithreaded client with TSS resources. This -could be done using the leader-follower model (thread-pool.)</LI> - -<LI> -Support new concurrency models, e.g., Thread-per-Request, thread pool, -etc..</LI> -</UL> -<B>Future work:</B> -<UL> -<LI> -Performance optimizations, such as:</LI> - -<OL> -<LI> -Replace all uses of <TT>new</TT> and <TT>delete</TT> with allocators that -can be put into TSS. The main motivation for this is to eliminate lock -contention when multiple threads need to allocate/deallocate memory, however -it might also be possible to substitute an allocator better-tuned to an -application's specific usage.</LI> -</OL> - -<LI> -Robustness improvements:</LI> - -<OL> -<LI> -Improve connection cache so that it won't crash when there are no more -slots or sockets.</LI> - -<LI> -Add an option to the ORB core, e.g., <B>-ORBnameservicetimeout</B>, to -allow specification of an upper bound on the itime-to-wait for a response -from the ORB's multicast "search" for a running name server.</LI> -</OL> - -<LI> -New features:</LI> - -<OL> -<LI> -Implement <TT>ORB::perform_work</TT> and <TT>ORB::work_pending</TT> so -that <TT>ORB::run</TT> <I>could</I> be implemented in terms of them.</LI> - -<LI> -Improve the <TT>Service Configurator</TT> service entry faking on VxWorks.</LI> - -<LI> -Integrate with realtime upcalls (RTUs).</LI> -</OL> - -<LI> -Internal restructuring:</LI> - -<OL> -<LI> -Create some sort of internal "request" object which carries enough context -to suport deferred method invocation such as one might find in the thread-pool -approach or wherever queuing might occur.</LI> -</OL> - -<LI> -Documentation:</LI> - -<OL> -<LI> -Update ORB Patterns paper to reflect the latest TAO has to offer. Specifically</LI> - -<UL> -<LI> -sections on the Abstract Factory and Concurrency strategies need to be -updated, and the entire paper needs to be reviewed for accuracy w.r.t the -current TAO.</LI> - -<LI> -Metrics must be re-computed.</LI> - -<LI> -Tighten existing discussions.</LI> - -<LI> -Add information on new patterns (such as TSS) which have been used since -initial work.</LI> -</UL> - -<LI> -Make the section in <TT><A HREF="../../TAO-Install.html">$TAO_ROOT/TAO-Install.html</A></TT> -that documents installation on Unix platforms more complete.</LI> -</OL> - -<LI> -Miscellany:</LI> - -<OL> -<LI> -Assist in porting higher level services (e.g., <A HREF="ec.html">Event -Channel</A>) to TAO.</LI> - -<LI> -Compile and verify ACE and TAO on Linux using the Kuck and Associates, -Inc. (KAI) compiler tools.</LI> -</OL> - -<LI> -Potential Optimizations:</LI> - -<OL> -<LI> -There is a certain amount of overhead introduced by the use of TSS Singletons. -TSS singletons are very convenient as the variable does not have to be -passed from function to function. Even though sort of access is generally -acceptable, the overhead of this approach maybe too high when used in code -which is executed frequently (e.g., during an upcall). This critical code -may have to be restructured not to use TSS Singletons because of the high -overhead associated with it.</LI> -</OL> -</UL> - -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes/trader.html b/TAO/docs/releasenotes/trader.html deleted file mode 100644 index a8995ab1d81..00000000000 --- a/TAO/docs/releasenotes/trader.html +++ /dev/null @@ -1,1064 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - -<head> -<title>TAO Trading Service Documentation</title> -</head> - -<body text="#000000" link="#0000FF" vlink="#CC0000" bgcolor="#FFFFFF"> - -<hr> - -<h1 align="center">TAO Trading Service Documentation</h1> - -<hr> - -<p>The TAO transient Trading Service implements the COS TradingObject Service -specification, and conforms to the Linked Trader conformance criteria. This document -details how to use the TAO Trading Service from the following perspectives: - -<ul> - <li>as an importer bootstrapping to the Trading Service;</li> - <li>as a service offer exporter;</li> - <li>as an administrator;</li> - <li>as an out-of-the-box server process; </li> - <li>as a collocated object. </li> -</ul> - -<p>In addition, it covers running the Trading Service tests and discusses known bugs and -workarounds.</p> - -<p>This document assumes you are familiar with Trading Service concepts, such as -"importer," "exporter", "service type", "service -offer," and "dynamic property", as well as the roles of each of the Trading -Service's interfaces --- <tt>Lookup</tt>, <tt>Register</tt>, <tt>Admin</tt>, and <tt>Link</tt> -(the TAO implementation doesn't currently support <tt>Proxy</tt>). I recommend reading the -first two sections of the <a href="ftp://www.omg.org/pub/docs/formal/97-12-23.pdf">Trading -Service specification</a>. This document has the following layout: - -<ol> - <li><a href="#TheClientRole">The Client Role</a> <ul> - <li><a href="#BootstrappingtotheTradingService">Bootstrapping to the Trading Service</a> </li> - <li><a href="#The ImporterRolePerformingaQuery">The Importer Role --- Performing a Query</a><ul> - <li><a href="#Constraints">Constraints</a></li> - <li><a href="#Preferences">Preferences</a></li> - <li><a href="#Policies">Policies</a></li> - <li><a href="#FilteringProperties">Filtering Properties</a> </li> - <li><a href="#OfferIterators">Offer Iterators</a></li> - <li><a href="#PropertyEvaluation">Property Evaluation</a></li> - </ul> - </li> - <li><a href="#TheExporterRole">The Exporter Role --- Registering a Service Type and Offer</a> - <ul> - <li><a href="#TheServiceTypeRepository">The Service Type Repository</a> </li> - <li><a href="#ExportingWithdrawingandModifying">Exporting, Withdrawing, and Modifying - Service Offers</a> </li> - <li><a href="#ImplementingDynamicProperties">Implementing Dynamic Properties</a></li> - </ul> - </li> - <li><a href="#TheAdministratorRole">The Administrator Role --- Tweaking Policies and - Adjusting Links</a></li> - </ul> - </li> - <li><a href="#TheServerRole">The Server Role</a><ul> - <li><a href="#TheTAOTradingServiceApplication">The TAO <tt>Trading_Service</tt> Application</a></li> - <li><a href="#ColocatingtheTradingServiceinaTAOApplication">Colocating the Trading Service - in a TAO Application</a></li> - </ul> - </li> - <li><a href="#RunningtheTradingServiceTests">Running the Trading Service Tests</a></li> - <li><a href="#KnownBugsandWorkarounds">Known Bugs and Workarounds</a></li> - <li><a href="#FutureWork">Future Work</a></li> -</ol> - -<hr> - -<h1><a name="TheClientRole">The Client Role</a></h1> - -<p align="left">There are three categories of operations that a client can perform on a -Trading Service instance: exporting a service offer to the Trading Service, importing a -list of Service Offers whose properties satisfy a constraint expression, and attending to -administrative duties --- tweaking policies or adjusting links. The first order of -business, of course, is obtaining a reference to a Trading Service instance, assuming that -instance is not colocated with the client. </p> - -<h2 align="left"><a name="BootstrappingtotheTradingService">Bootstrapping to the Trading -Service</a></h2> - -<p align="left">Like with the Naming Service, the ORB will obtain a reference to a Trading -Service instance's <tt>Lookup</tt> interface when a client invokes the <tt>CORBA::ORB::resolve_initial_references</tt> -method and passes to it the <tt>ObjectID</tt> "<tt>TradingService</tt>". The -following TAO code bootstraps to the Trading Service:</p> - -<table border="1" width="100%" cellpadding="6"> - <tr> - <td width="100%"><pre>TAO_TRY -{ - TAO_ORB_Manager orb_manager; - orb_manager.init (argc, argv, TAO_TRY_ENV); - TAO_CHECK_ENV; - CORBA::ORB_var orb = orb_manager.orb (); - CORBA::Object_var trading_obj = - orb->resolve_initial_references ("TradingService"); - CosTrading::Lookup_var lookup_if = - CosTrading::Lookup::_narrow (trading_obj.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; -} -TAO_CATCHANY -{ - TAO_TRY_ENV.print_exception ("Failed to bootstrap to a trader"); -} -TAO_ENDTRY;</pre> - </td> - </tr> -</table> - -<p>The first time <tt>resolve_initial_references</tt> is called, the ORB uses a multicast -protocol to locate an existing trader. The ORB emits a multicast packet containing a field -identifying the desired service --- Naming or Trading --- and the port number that the -client is listening on for the response (the IP address can be inferred from the packet). -When the trader receives the packet and finds that the id contained within matches its -own, it opens a socket to the client on the designated port, and sends its IOR, which the -ORB converts to an object reference that it caches. </p> - -<p>If the trader IOR is known ahead of time, the string can be passed to the client in the -environment variable <tt>TradingService</tt>, or by the command line option <tt>-ORBtradingserviceior -<IOR></tt>. Likewise, if the multicast port is known ahead of time and differs from -the default port, the port number can be passed to the client in the environment variable <tt>TradingServicePort</tt>, -or by the command line option <tt>-ORBtradingserviceport <PORTNUM></tt>. </p> - -<h2><a name="The ImporterRolePerformingaQuery">The Importer Role --- Performing a Query</a></h2> - -<p>Once the importer has obtained a reference to a trader's <tt>Lookup</tt> interface, it -next needs to fire up a query. The query method takes nine parameters (aside from the <tt>CORBA::Environment</tt>):</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="39%"><tt>const CosTrading::ServiceTypeName</tt></td> - <td width="61%">The Trading Service will search Offers belonging to this subtype. If the <tt>exact_type_match</tt> - policy wasn't explicitly set to false, then offers belonging to subtypes of this type will - also be searched. </td> - </tr> - <tr> - <td width="39%"><tt>const CosTrading::Constraint</tt></td> - <td width="61%">An expression in the OMG standard constraint language, where each property - name is a property defined in the Service Type description of the type being searched.</td> - </tr> - <tr> - <td width="39%"><tt>const CosTrading::Lookup::Preference</tt></td> - <td width="61%">An expression in the OMG standard constraint language dictating how offers - in the <tt>returned_offers</tt> sequence should be ordered.</td> - </tr> - <tr> - <td width="39%"><tt>const CosTrading::PolicySeq</tt></td> - <td width="61%">Policies governing the breadth of search and the type of permissible - offers. A policy is a name/value pair --- a string and an <tt>Any</tt> --- that affect the - search algorithm. </td> - </tr> - <tr> - <td width="39%"><tt>const CosTrading::Lookup::SpecifiedProps</tt></td> - <td width="61%">A union specifying which properties should be returned in each offer. If - the descriminator is <tt>CosTrading::Lookup::some</tt>, the union contains the list - of designated property names. Other options are <tt>all</tt>or <tt>none</tt>. </td> - </tr> - <tr> - <td width="39%"><tt>CORBA::ULong how_many</tt></td> - <td width="61%">The number of offers that should be placed in the returned sequence.</td> - </tr> - <tr> - <td width="39%"><tt>CosTrading::OfferSeq_out</tt></td> - <td width="61%">A list of ordered offers whose properties meet the constraints.</td> - </tr> - <tr> - <td width="39%"><tt>CosTrading::OfferIterator_out</tt></td> - <td width="61%">Iterator over returned offers in excess of how_many --- unordered.</td> - </tr> - <tr> - <td width="39%"><tt>CosTrading::PolicyNameSeq_out</tt></td> - <td width="61%">A sequence of policy names for policies that limited the search.</td> - </tr> -</table> - -<h3><a name="Constraints">Constraints</a></h3> - -<p>A constraint is a string in the OMG standard constraint language (the BNF can be found -at the end of the specification). The trader iterates over applicable offers, and for each -offer determines if its properties meet the constraints, replacing property names in the -string with their values and computing the result. If the constraint evaluates to true, -the offer is placed in the pool of matched offers. If the constraint string is -syntactically invalid, contains property names not found in the service type description -for the listed service type, or has operators with mismatched operand types, the query -method will throw an <tt>InvalidConstraint</tt> exception. </p> - -<p>Operands can be of two types: property names or literals. A property name is an -unquoted string of alphanumeric characters and underscores that begins with a letter. The -service type describes the type of a property. A literal is an signed or unsigned integer, -floating point number --- scientific notation acceptable ---, single-quoted string, or -boolean --- written TRUE or FALSE. </p> - -<p>The constraint language supports the following operations:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="25%">Arithmetic (+, -, *, /)</td> - <td width="34%"><tt>Disk_Space*1000 - Amount_Used/10</tt></td> - <td width="41%">Accepts two numeric operands.</td> - </tr> - <tr> - <td width="25%">Inequality (<,>,<=,>=)</td> - <td width="34%"><tt>Amount_Used < Disk_Space</tt></td> - <td width="41%">Accepts two numeric or two string operands.</td> - </tr> - <tr> - <td width="25%">Equality (==, !=)</td> - <td width="34%"><tt>Amount_Used == Disk_Space</tt></td> - <td width="41%">Accepts two numeric, two string, or two boolean operands.</td> - </tr> - <tr> - <td width="25%">Substring (~)</td> - <td width="34%"><tt>'.wustl.edu' ~ Domain_Name</tt></td> - <td width="41%">Accept two string operands. Returns true if the right string contains the - left.</td> - </tr> - <tr> - <td width="25%">Sequence inclusion (in)</td> - <td width="34%"><tt>'sbw1' in User_Queue</tt></td> - <td width="41%">Accepts an operand of a primitive CORBA type on the left, and a sequence - of the same type on the right. Returns true when the sequence contains the value in the - left operand, false otherwise.</td> - </tr> - <tr> - <td width="25%">Property existence (exist)</td> - <td width="34%"><tt>exist User_Queue</tt></td> - <td width="41%">Accepts a property name. Returns true if the property is defined in the - offer.</td> - </tr> -</table> - -<h3><a name="Preferences">Preferences</a></h3> - -<p>A preference is a constraint language string that determines the order of offers in the -returned offer sequence. There are five types of preferences:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="18%"><tt>min</tt> <expression></td> - <td width="82%">Offers are ordered by ascending expression value. The expression must - return a number.</td> - </tr> - <tr> - <td width="18%"><tt>max</tt> <expression> </td> - <td width="82%">Offers are ordered by descending expression value. The expression must - return a number. </td> - </tr> - <tr> - <td width="18%"><tt>with</tt> <expression></td> - <td width="82%">Offers are partitioned into two parts: those offers for which the - expression returns true are placed in the front, the rest in the back. The expression must - return a boolean value.</td> - </tr> - <tr> - <td width="18%"><tt>random</tt></td> - <td width="82%">Offers in the sequence are shuffled.</td> - </tr> - <tr> - <td width="18%"><tt>first</tt></td> - <td width="82%">Offers are placed in the sequence in the order they're evaluated.</td> - </tr> -</table> - -<h3><a name="Policies">Policies</a></h3> - -<p>The following import policies are descibed in the specification and supported by the -TAO Trading Service:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="22%"><tt>exact_type_match</tt></td> - <td width="18%"><tt>CORBA::Boolean</tt></td> - <td width="60%">True --- Search only considers offers belonging to the given type.<br> - False --- Search considers offers belonging to the given type or any of its subtypes.</td> - </tr> - <tr> - <td width="22%"><tt>search_card</tt></td> - <td width="18%"><tt>CORBA::ULong</tt></td> - <td width="60%">Search ceases after <tt>search_card</tt> number of offers have been - evaluated.</td> - </tr> - <tr> - <td width="22%"><tt>match_card</tt></td> - <td width="18%"><tt>CORBA::ULong</tt></td> - <td width="60%">Search ceases after <tt>search_card</tt> number of offers have been - matched.</td> - </tr> - <tr> - <td width="22%"><tt>return_card</tt></td> - <td width="18%"><tt>CORBA::ULong</tt></td> - <td width="60%">Query returns at most <tt>return_card</tt> number of offers.</td> - </tr> - <tr> - <td width="22%"><tt>support_dynamic_properties</tt></td> - <td width="18%"><tt>CORBA::Boolean</tt></td> - <td width="60%">Search considers offers with dynamic properties.</td> - </tr> - <tr> - <td width="22%"><tt>support_modifiable_properties</tt></td> - <td width="18%"><tt>CORBA::Boolean</tt></td> - <td width="60%">Search considers offers with not readonly properties.</td> - </tr> - <tr> - <td width="22%"><tt>starting_trader</tt></td> - <td width="18%"><tt>CosTrading::TraderName</tt></td> - <td width="60%">Query is forwarded across all links in the policy, and search begins at - the final trader.</td> - </tr> - <tr> - <td width="22%"><tt>hop_count</tt></td> - <td width="18%"><tt>CORBA::ULong</tt></td> - <td width="60%">Maximum depth a query should be propagated in the trader federation.</td> - </tr> - <tr> - <td width="22%"><tt>link_follow_rule</tt></td> - <td width="18%"><tt>CosTrading::FollowOption</tt></td> - <td width="60%">Query propagates to other traders if the <tt>link_follow_rule</tt> permits - it.</td> - </tr> -</table> - -<p>The TAO Trading Service comes with a handy utility --- <tt>TAO_Policy_Manager</tt> --- -for creating a policy sequence to pass to the query method that won't incur any -exceptions. Use the <tt>TAO_Policy_Manager</tt> in the following way:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>TAO_Policy_Manager policies; -policies.exact_type_match (CORBA::B_FALSE); -policies.search_card (16*NUM_OFFERS); -policies.match_card (16*NUM_OFFERS); -policies.return_card (16*NUM_OFFERS); -policies.link_follow_rule (CosTrading::local_only); -const CosTrading::PolicySeq& policy_seq = policies.policy_seq ();</pre> - </td> - </tr> -</table> - -<h3><a name="FilteringProperties">Filtering Properties</a></h3> - -<p>If the client wants only a subset of the properties defined for a service type returned -in matching offers, it can specify those property names in the <tt>desired_properties</tt> -parameter of the query method. Pass the <tt>prop_names</tt> method of <tt>CosTrading::Lookup::SpecifiedProperties</tt> -a <tt>CosTrading::PropNameSeq</tt>:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>char* props[] = {"Name", "Description", "Location", "Host_Name" }; -CosTrading::Lookup::SpecifiedProps desired_props; -CosTrading::PropertyNameSeq prop_name_seq (4, 4, props, CORBA::B_FALSE); -desired_props.prop_names (prop_name_seq);</pre> - </td> - </tr> -</table> - -<h3><a name="OfferIterators">Offer Iterators</a></h3> - -<p>Those offers returned from the query in excess of <tt>how_many</tt> are placed in an -offer iterator for deferred retrieval. The <tt>CosTrading::OfferIterator::next_n</tt> -method will allocate a sequence and fill it with either n offers, or if it has fewer than <tt>n</tt> -offers, the remaining offers. The <tt>next_n</tt> method returns true if the iterator -contains more offers, and false if it's been depleted. After finishing with the iterator, -invoke its <tt>destroy</tt> method to release any server-side resources.</p> - -<p>The following code is an example of obtaining offers from a <tt>CosTrading::OfferIterator</tt>:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>CORBA::Boolean any_left = CORBA::B_FALSE; -CORBA::Environment _env;</pre> - <pre>do - { - CosTrading::OfferSeq_ptr iter_offers_ptr; - CosTrading::OfferSeq_out iter_offers_out (iter_offers_ptr); - - any_left = offer_iterator->next_n (length, - iter_offers_out, - _env); - TAO_CHECK_ENV_RETURN (_env, 0); - - CosTrading::OfferSeq_var iter_offers (iter_offers_ptr); - // Process offers... - - } while (any_left);</pre> - </td> - </tr> -</table> - -<h3><a name="PropertyEvaluation">Property Evaluation</a></h3> - -<p>After the client completes a query that used dynamic properties, to review the property -values of the returned offers, it has to distinguish between <tt>Anys</tt> containing -static properties and <tt>Anys</tt> containing dynamic property structures. The <tt>TAO_Property_Evaluator</tt> -class is a handy utility to obtain property values that hides how it evalutes properties -for the client --- by simple <tt>Any</tt> value extraction for static properties, or by -calling back to a dynamic property interface. The <tt>TAO_Property_Evaluator</tt> caches -the value of a dynamic property, and frees the allocated <tt>Anys</tt> during its -destruction. </p> - -<p>The following code demonstrates how to use the <tt>TAO_Property_Evaluator</tt> to dump -the properties of an offer to the screen. </p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>TAO_Property_Evaluator prop_eval (prop_seq); -for (int length = prop_seq.length (), k = 0; k < length; k++) - { - ACE_DEBUG ((LM_DEBUG, "%-15s: ", prop_seq[k].name.in ())); - TAO_TRY - { - CORBA::Boolean is_dynamic = prop_eval.is_dynamic_property (k); - TAO_CHECK_ENV; - - value = prop_eval.property_value(k, env); - TAO_CHECK_ENV; - - if (value != 0) - CORBA::Any::dump (*value); - } - TAO_CATCHANY - { - ACE_DEBUG ((LM_DEBUG, "Error retrieving property value.\n")); - } - TAO_ENDTRY; - }</pre> - </td> - </tr> -</table> - -<h2><a name="TheExporterRole">The Exporter Role --- Registering a Service Type and Offer</a></h2> - -<p>Before an exporting client can register a new service offer with the Trading Service, -it needs to ensure first that its service type is present in the service type repository -of the target trader. The most efficient way to do this is to first invoke the <tt>export</tt> -method on the <tt>Register</tt> interface, and if it raises an <tt>UnknownServiceType</tt> -exception, obtain a reference to the Repository, add the Service Type, and attempt the <tt>export</tt> -a second time. Here's the boilerplate code:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>CORBA::Object_var trading_obj = - orb_ptr->resolve_initial_references ("TradingService"); -CosTrading::Lookup_var lookup_if = - CosTrading::Lookup::_narrow (trading_obj.in (), _env); -TAO_CHECK_ENV_RETURN (_env, -1); -CosTrading::Register_var register_if = lookup_if->register_if (_env); -TAO_CHECK_ENV_RETURN (_env, -1); -CosTrading::TypeRepository_ptr obj = this->trader_->type_repos (_env); -CosTradingRepos::ServiceTypeRepository_var str = - CosTradingRepos::ServiceTypeRepository::_narrow (obj, _env); -TAO_CHECK_ENV_RETURN (_env, -1); - -TAO_TRY - { - // Attempt to export the offer. - offer_id = - register_id->export (object_ref, type, props, TAO_TRY_ENV); - TAO_CHECK_ENV; - } -TAO_CATCH (CosTrading::UnknownServiceType, excp) - { - // If the ServiceTypeName wasn't found, we'll have to add the - // type to the Service Type repository ourselves. - str->add_type (type, - object_ref->_interface_repository_id (), - prop_struct_seq, - super_type_name_seq, - _env); - TAO_CHECK_ENV_RETURN (_env, 0); - - // Now we'll try again to register the offer. - offer_id = reg->export (object_ref, type, this->tprops_, _env); - TAO_CHECK_ENV_RETURN (_env, 0); - - TAO_TRY_ENV.clear (); - } -TAO_CATCHANY - { - // Sigh, all our efforts were for naught. - TAO_RETHROW_RETURN (0); - } -TAO_ENDTRY;</pre> - </td> - </tr> -</table> - -<h3><a name="TheServiceTypeRepository">The Service Type Repository</a></h3> - -<p>Creating a service type description is simply a matter of filling in two sequences: a <tt>CosTradingRepos::ServiceTypeRepository::PropStructSeq</tt> -and a <tt>CosTradingRepos::ServiceTypeRepository::ServiceTypeNameSeq</tt>. When filling in -the <tt>value_type</tt> field, remember to up the reference count of the <tt>TypeCode</tt>, -since otherwise the <tt>TypeCode_var</tt> will sieze control of the memory and free it. -Here's a code excerpt taken from <tt>export_test</tt> showing how to build the first -couple elements of such sequences:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>this->type_structs_[TT_Info::PLOTTER].props.length (2); -this->type_structs_[TT_Info::PLOTTER].super_types.length (1); -this->type_structs_[TT_Info::PLOTTER].super_types[0] = -TT_Info::INTERFACE_NAMES[TT_Info::REMOTE_IO]; -this->type_structs_[TT_Info::PLOTTER].props[0].name = -TT_Info::PLOTTER_PROPERTY_NAMES[TT_Info::PLOTTER_NUM_COLORS]; -this->type_structs_[TT_Info::PLOTTER].props[0].value_type = -CORBA::TypeCode::_duplicate (CORBA::_tc_long); -this->type_structs_[TT_Info::PLOTTER].props[0].mode = -CosTradingRepos::ServiceTypeRepository::PROP_NORMAL; -this->type_structs_[TT_Info::PLOTTER].props[1].name = -TT_Info::PLOTTER_PROPERTY_NAMES[TT_Info::PLOTTER_AUTO_LOADING]; -this->type_structs_[TT_Info::PLOTTER].props[1].value_type = -CORBA::TypeCode::_duplicate (CORBA::_tc_boolean); -this->type_structs_[TT_Info::PLOTTER].props[1].mode = -CosTradingRepos::ServiceTypeRepository::PROP_READONLY;</pre> - </td> - </tr> -</table> - -<h3><a name="ExportingWithdrawingandModifying">Exporting, Withdrawing, and Modifying -Service Offers</a></h3> - -<p>Like with adding a Service Type, exporting an offer is just filling in the sequences. -For offers, of course, property values are passed, so this involves employing the <tt>Any</tt> -insertion operators. Here's a code exerpt from <tt>export_test</tt>:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>CosTrading::PropertySeq prop_seq (2); -prop_seq[0].name = - TT_Info::PLOTTER_PROPERTY_NAMES[TT_Info::PLOTTER_NUM_COLORS]; -prop_seq[0].value <<= ACE_static_cast (CORBA::Long, 256); -prop_seq[1].name = - TT_Info::PLOTTER_PROPERTY_NAMES[TT_Info::PLOTTER_AUTO_LOADING]; -prop_seq[1].value <<= CORBA::Any::from_boolean (CORBA::B_TRUE);</pre> - </td> - </tr> -</table> - -<p>The <tt>export_test</tt> returns a <tt>CosTrading::OfferId</tt> string, which is -required to perform the <tt>withdraw</tt> and <tt>modify</tt> operations on the exported -offer. <tt>withdraw</tt> requires that you simply pass the <tt>OfferId</tt> of the offer -to be withdrawn, while <tt>modify</tt> takes two additional sequences: a <tt>CosTrading::PropertyNameSeq</tt> -of property names to be removed from the offer, and a <tt>CosTrading::PropertySeq</tt> of -offers to be added or changed in the offer. </p> - -<h3><a name="ImplementingDynamicProperties">Implementing Dynamic Properties</a></h3> - -<p>To export an offer with a dynamic property: - -<ul> - <li>inherit from the <tt>TAO_Dynamic_Property</tt> class and implement its <tt>DP_Eval</tt> - method; </li> - <li>create a <tt>CosTradingDynamic::DynamicProperty</tt> structure using the <tt>TAO_Dynamic_Property::construct_dynamic_prop</tt> - method; </li> - <li>insert the <tt>CosTradingDynamic::DynamicProperty</tt> in the value field of the - property. </li> -</ul> - -<p>The following code, taken from the <tt>export_test</tt> example, illustrates this:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>// Step 1: Write the Dynamic Property callback handler. -class Simple_DP : public TAO_Dynamic_Property -{ -public: - - virtual CORBA::Any* evalDP (const char* name, - CORBA::TypeCode_ptr returned_type, - const CORBA::Any& extra_info, - CORBA::Environment& _env) - TAO_THROW_SPEC ((CosTradingDynamic::DPEvalFailure)); -}; - -CORBA::Any* -Simple_DP::evalDP (const char* name, - CORBA::TypeCode_ptr returned_type, - const CORBA::Any& extra_info, - CORBA::Environment& _env) - TAO_THROW_SPEC ((CosTradingDynamic::DPEvalFailure)) -{ - CORBA::Any* return_value = 0; - ACE_NEW_RETURN (return_value, CORBA::Any, 0); - - (*return_value) <<= ACE_static_cast (CORBA::ULong, ACE_OS::rand ()); - return return_value; -}</pre> - <pre>// Step 2: Create the Dynamic Property -Simple_DP dp; -CORBA::Any extra_info; -CosTrading::PropertySeq prop_seq (1); -CosTrading::DynamicProp* dp_struct = - dp.construct_dynamic_prop ("prop_name", - CORBA::_tc_ulong, - extra_info);</pre> - <pre>// Step 3: Turn over the dynamic property to the propery value Any. -CORBA::Environment env; -prop_seq[0].name = "prop_name"; -prop_seq[0].value.replace (CosTrading::_tc_DynamicProp, - dp_struct, - CORBA::B_TRUE, - env); -TAO_CHECK_ENV_RETURN (env, -1);</pre> - </td> - </tr> -</table> - -<h2><a name="TheAdministratorRole">The Administrator Role --- Tweaking Policies and -Adjusting Links</a></h2> - -<p>The trader can be configured remotely through two interfaces: the <tt>Admin</tt> -interface, for tweaking global policies, enabling and disabling interfaces, and dumping -the trader contents; and the <tt>Link</tt> interface, for attaching to and detaching from -other traders. </p> - -<p>Adjusting policies is straightforward. Here's an example of setting the <tt>max_search_card</tt> -policy:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>// lookup_if returned from resolve_initial_references. -CosTrading::Admin_var admin_if = - lookup_if->admin_if (TAO_TRY_ENV); -TAO_CHECK_ENV;</pre> - <pre>admin_if->set_max_match_card (200);</pre> - </td> - </tr> -</table> - -<p>Here's an example of using the list_offers method on the Admin interface to remove all -offers from the Trader:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>TAO_TRY -{ -CosTrading::OfferIdIterator_ptr offer_id_iter; -CosTrading::OfferIdSeq_ptr offer_id_seq; - -// lookup_if returned from resolve_initial_references. -CosTrading::Admin_var admin_if = - lookup_if->admin_if (TAO_TRY_ENV); -TAO_CHECK_ENV; - -CosTrading::Register_var register_if = - lookup_if->register_if (TAO_TRY_ENV); -TAO_CHECK_ENV; - -admin_if->list_offers (10, - CosTrading::OfferIdSeq_out (offer_id_seq), - CosTrading::OfferIdIterator_out (offer_id_iter), - TAO_TRY_ENV); -TAO_CHECK_ENV; - -if (offer_id_seq != 0) - { - CosTrading::OfferIdSeq_var offer_id_seq_var (offer_id_seq); - for (CORBA::ULong i = 0; i < offer_id_seq_var.length (); i++) - { - register_if->withdraw (offer_id_seq_var[i], TAO_TRY_ENV); - TAO_CHECK_ENV; - } - } - -if (offer_id_iter != CosTrading::OfferIdIterator::_nil ()) - { - CORBA::Boolean any_left = CORBA::B_FALSE; - CosTrading::OfferIdSeq_ptr id_seq = 0; - CosTrading::OfferIdIterator_var offer_id_iter_var (offer_id_iter); - - do - { - any_left = - offer_id_iter->next_n (length, - CosTrading::OfferIdSeq_out (id_seq), - TAO_TRY_ENV); - TAO_CHECK_ENV; - - CORBA::ULong offers = id_seq->length (); - for (CORBA::ULong i = 0; i < offers; i++) - { - register_if->withdraw (id_seq[i], TAO_TRY_ENV); - TAO_CHECK_ENV; - } - - delete id_seq; - } - while (any_left); - - offer_id_iter->destroy (TAO_TRY_ENV); - TAO_CHECK_ENV; - } -} -TAO_CATCHANY -{ - // Handle Errors. -} -TAO_ENDTRY;</pre> - </td> - </tr> -</table> - -<p>Here's an example a trader linking itself to another trader (<tt>this->trader_</tt> -is a colocated trader --- see the next section for more information): </p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>TAO_TRY - { - CosTrading::Link_var link_if = lookup_if->link_if (TAO_TRY_ENV); - TAO_CHECK_ENV; - - TAO_Trading_Components_Impl& trd_comp = - this->trader_->trading_components (); - CosTrading::Lookup_ptr our_lookup = trd_comp.lookup_if (); - CosTrading::Link_ptr our_link = trd_comp.link_if (); - - link_if->add_link (this->name_.in (), - our_lookup, - CosTrading::always, - CosTrading::always, - TAO_TRY_ENV); - TAO_CHECK_ENV; - - our_link->add_link ("Bootstrap_Trader", - lookup_if.in (), - CosTrading::always, - CosTrading::always, - TAO_TRY_ENV); - } -TAO_CATCHANY -{ - // Handle Errors. -} -TAO_ENDTRY;</pre> - </td> - </tr> -</table> - -<hr> - -<h1><a name="TheServerRole">The Server Role</a></h1> - -<p>The TAO Trading Service comes with an out-of-the-box executable suitable for common -use. However, it can also easily be colocated with any other TAO server to add Trading -Service functionality to that server.</p> - -<h2><a name="TheTAOTradingServiceApplication">The TAO Trading Service Application</a></h2> - -<p>This out-of-the-box server takes a number of command line arguments:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="26%"><tt>-TSthreadsafe</tt></td> - <td width="74%">The Trader will use reader/writer locks to protect the offer database and - link collection, and normal thread mutexes for the rest of the shared state --- global - policies, support attributes, and interface accessors. (default is not thread safe; Null - Mutexes are used)</td> - </tr> - <tr> - <td width="26%"><tt>-TSconformance</tt></td> - <td width="74%">Determines which conformance category the Trading Service will meet:<br> - <table border="0" width="100%" cellpadding="3"> - <tr> - <td width="18%"><ul> - <li><em>query</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Instantiates the <tt>Lookup</tt> interface only</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>simple</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Instantiates the <tt>Lookup</tt> and <tt>Register</tt> - interfaces</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>standalone</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Instantiates the <tt>Lookup</tt>, <tt>Register</tt>, - and <tt>Admin</tt> interfaces</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>linked</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Instantiates the <tt>Lookup</tt>, <tt>Register</tt>, - <tt>Admin</tt>, and <tt>Link</tt> interfaces (default)</td> - </tr> - </table> - </td> - </tr> - <tr> - <td width="26%"><tt>-TSsupports_dynamic_properties</tt></td> - <td width="74%"><table border="0" width="100%" cellpadding="3"> - <tr> - <td width="18%"><ul> - <li><em>true</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Will consider offers with dynamic properties in - queries unless explicitly disabled by a policy passed to the query method. (default)</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>false</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Will not consider offers with dynamic properties - in queries, unless explicitly enabled by a policy passed to the query method.</td> - </tr> - </table> - </td> - </tr> - <tr> - <td width="26%"><tt>-TSsupports_modifiable_properties</tt></td> - <td width="74%"><table border="0" width="100%" cellpadding="3"> - <tr> - <td width="18%"><ul> - <li><em>true</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Will consider offers with not explicitly - modifable properties in queries unless explicitly disabled by a policy passed to the query - method. Enables the <tt>modify</tt> method on the <tt>Register</tt> interface. (default)</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>false</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">Will not consider dynamic properties in queries, - unless explicitly overridden by a query policy. Diables <tt>modify</tt> method on the <tt>Register</tt> - interface.</td> - </tr> - </table> - </td> - </tr> - <tr> - <td width="26%"><tt>-TSdef_search_card</tt></td> - <td width="74%">Search cardinality if none is specified as a query policy. (default is - 200)</td> - </tr> - <tr> - <td width="26%"><tt>-TSmax_search_card</tt></td> - <td width="74%">Upper limit on the search cardinality for a query. (default is 500)</td> - </tr> - <tr> - <td width="26%"><tt>-TSdef_match_card</tt></td> - <td width="74%">Match cardinality if none is specified as a query policy. (default is 200)</td> - </tr> - <tr> - <td width="26%"><tt>-TSmax_match_card</tt></td> - <td width="74%">Upper limit on the match cardinality for a query. (default is 500)</td> - </tr> - <tr> - <td width="26%"><tt>-TSdef_return_card</tt></td> - <td width="74%">Return cardinality if none is specified as a query policy. (default is - 200)</td> - </tr> - <tr> - <td width="26%"><tt>-TSmax_return_card</tt></td> - <td width="74%">Upper limit on the return cardinality for a query. (default is 500)</td> - </tr> - <tr> - <td width="26%"><tt>-TSdef_hop_count</tt></td> - <td width="74%">The depths a federated query may go if no query policy is specified. - (default 5)</td> - </tr> - <tr> - <td width="26%"><tt>-TSmax_hop_count</tt></td> - <td width="74%">The maximum number of links a federated query can travel after it passes - through this trader. (default is 10) </td> - </tr> - <tr> - <td width="26%"><tt>-TSdef_follow_policy</tt></td> - <td width="74%"><table border="0" width="100%" cellpadding="3"> - <tr> - <td width="18%"><ul> - <li><em>always</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader will always pass a query onto the - next available linked trader.</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>if_no_local</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader will pass a query onto the next - trader only if the local search produced no results. (default)</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>local_only</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader will never pass on a query.</td> - </tr> - </table> - </td> - </tr> - <tr> - <td width="26%"><tt>-TSmax_follow_policy</tt></td> - <td width="74%"><table border="0" width="100%" cellpadding="3"> - <tr> - <td width="18%"><ul> - <li><em>always</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader doesn't limit the importer to the - local offer space. (default)</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>if_no_local</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader refuses to pass on queries of the - local search matched offers.</td> - </tr> - <tr> - <td width="18%"><ul> - <li><em>local_only</em></li> - </ul> - </td> - <td width="82%" valign="top" align="left">The trader will never allow federated queries.</td> - </tr> - </table> - </td> - </tr> - <tr> - <td width="26%"><tt>-ORBtradingserviceport</tt></td> - <td width="74%">Port on which to listen for multicast bootstrap requests.</td> - </tr> - <tr> - <td width="26%"><tt>-ORBtradingserviceport</tt></td> - <td width="74%">Port on which to listen for multicast bootstrap requests.</td> - </tr> - <tr> - <td width="26%"><tt>-TSdumpior</tt></td> - <td width="74%">Dumps the trader's IOR to a file (default is stdout).</td> - </tr> -</table> - -<p>By default the trader will listen for multicast <tt>resolve_initial_references</tt> -requests, and respond with the IOR of its <tt>Lookup</tt> inteface. For the purposes of -testing federated queries, when passed the <tt>-TSfederate</tt> method, instead of -becoming a bootstrappable server, the <tt>Trading_Service</tt> application will bootstrap -itself to a multicast trader, link itself to that trader and every other trader accessible -through that trader. This protocol will have all traders on the multicast network form a -complete graph. </p> - -<h2><a name="ColocatingtheTradingServiceinaTAOApplication">Colocating the Trading Service -in a TAO Application</a></h2> - -<p>Colocating the Trading Service in a TAO application amounts to constructing a <tt>TAO_TRADER</tt> -object using the <tt>TAO_Trader_Factory::construct_trader</tt> call. The <tt>argc</tt> and -<tt>argv</tt> parameters to <tt>construct_trader</tt> contain the configuration parameters -described in the previous section. The trader is also configurable programatically through -its attribute classes. The follow code exerpt demonstrates this. </p> - -<p>In addition the application will need to create a service type repository -implementation --- TAO's being the <tt>TAO_Service_Type_Repository</tt> --- and configure -the trader with it. The service type repository is separate from the trader in this way to -allow, for example, multiple traders to share the same service type repository. The -following code exerpt also demontrates configuring the repository:</p> - -<table border="1" width="100%" cellpadding="3"> - <tr> - <td width="100%"><pre>TAO_TRADER* trader = TAO_Trader_Factory::create_trader (argc, argv); -TAO_Support_Attributes_Impl& sup_attr = trader->support_attributes (); -TAO_Import_Attributes_Impl& imp_attr = trader->trading_components (); - -// Configure the trader with a service type repository. -CORBA::Environment _env; -TAO_Service_Type_Repository type_repos* type_repos = 0; -ACE_NEW (type_repos, TAO_Service_Type_Repository); -sup_attr.type_repos (type_repos->_this (_env)); -TAO_CHECK_ENV_RETURN (_env, -1);</pre> - <pre>// Configure other policies, overriding the command line arguments. -imp_attr.search_card (20); -sup_attr.supports_dynamic_properties (CORBA::B_FALSE);</pre> - </td> - </tr> -</table> - -<p>The trader interfaces register themselves with the default POA during the Trading -Service's construction. All that remains is to activate the POA and enter the ORB event -loop. </p> - -<hr> - -<h1><a name="RunningtheTradingServiceTests">Running the Trading Service Tests</a></h1> - -<p>There are two executables that test the Trading Service funtionality --- one to test -the exporter role, and the other, the importer role. To run the tests simply launch the <tt>Trading_Service</tt> -application, then run the <tt>export_test</tt> executable found in the <tt>orbsvcs/tests/Trading</tt> -directory. When the <tt>export_test</tt> ceases to output data and enters the event loop, -run the <tt>import_test</tt> found in the same directory. </p> - -<p>Also of importance: the <tt>-TSdumpior filename </tt> argument to the trader dumps -its IOR to the file. You can then paste the contents on the command line to -the tests with <tt>-ORBtradingserviceior IOR</tt>, or into the environment variable -<tt>TradingServiceIOR</tt>.</p> - -<p>The expected output of the tests can be found in the README file in the -tests directory.</p> - -<p>To test federated queries, run at least three copies of the <tt>Trading_Service</tt> -application, each using the <tt>-TSfederate</tt> flag. The traders will form a complete -graph, with each link follow policy set to <tt>CosTrading::always</tt>. When run with the <tt>-f</tt> -flag, the <tt>export_test</tt> will add the service types and export offers to each of the -traders in the federation. When run with the <tt>-f</tt> flag, the <tt>import_test </tt>will -perform a directed query to a trader two links distant from the trader boostrapped to, in -addition to performing federated queries. </p> - -<p>By default the tests dump the contents of service types and offers to the screen so the -tester can validate the results. To run the tests in quiet mode, where the results of the -describe and query methods are concealed, use the <tt>-q</tt> flag.</p> - -<hr> - -<h1><a name="KnownBugsandWorkarounds">Known Bugs and Workarounds</a></h1> - - <p>At this point there are no known problems with TAO that affect the - Trading service.</p> - -<hr> - -<h1><a name="FutureWork">Future Work</a></h1> - -<ul> - <li><strong>Persistence</strong> --- Have the Trading Service offer database and service - type repository survive the lifetime of a single Trading Service process. This would be - accomplished by either taking advantage of the ability to serialize IDL types --- using - CDR streams --- or through memory-mapped files, <em>a la </em>the ACE Naming Service.</li> -</ul> - -<ul> - <li><strong>The <tt>Proxy</tt> Interface </strong>--- Should we ever feel so motivated, we - might implement the <tt>Proxy</tt> interface. </li> -</ul> - -<hr> - -<address> - <a href="mailto:sbw1@cs.wustl.edu">Seth Benjamin Widoff</a> -</address> -<!-- Created: Mon Jun 29 12:26:36 CDT 1998 --> -<!-- hhmts start --> -</body> -</html> |