diff options
Diffstat (limited to 'TAO/docs')
| -rw-r--r-- | TAO/docs/DIFFERENCES | 360 | ||||
| -rw-r--r-- | TAO/docs/HISTORY | 44 | ||||
| -rw-r--r-- | TAO/docs/Options.html | 177 | ||||
| -rw-r--r-- | TAO/docs/REFERENCES | 91 | ||||
| -rw-r--r-- | TAO/docs/components.html | 27 | ||||
| -rw-r--r-- | TAO/docs/configurations.html | 177 | ||||
| -rw-r--r-- | TAO/docs/index.html | 18 | ||||
| -rw-r--r-- | TAO/docs/releasenotes.html | 26 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/index.html | 344 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/orbcore.html | 246 | ||||
| -rw-r--r-- | TAO/docs/releasenotes/trader.html | 31 |
11 files changed, 0 insertions, 1541 deletions
diff --git a/TAO/docs/DIFFERENCES b/TAO/docs/DIFFERENCES deleted file mode 100644 index 0a8dd343d4d..00000000000 --- a/TAO/docs/DIFFERENCES +++ /dev/null @@ -1,360 +0,0 @@ -@(#)DIFFERENCES 1.1 95/09/13 - -[ NOTE that the CORBA 2.0 specifications have now been published, but are -not yet sufficiently available that this document can usefully just list -any differences between that specification and this software. As a rule, -there are no differences between this software and CORBA 2.0 in areas -where CORBA 2.0 has specified an interface. ] - - -This document summarizes known differences between what is implemented in -this software and currently available OMG specifications. As a rule, these -establish compatibility with revised specifications that are currently being -prepared for publication. However, in some cases the differences resolve -problems that are currently being addressed by ORB taskforces. When those -revised CORBA specifications are published, this document will be updated to -reflect any remaining differences from them. - -The reason for those changes is that different specifications were adopted -at the same time and there were in some cases subtle differences which need -to be resolved. Minor errata have also been fixed. None of these changes -are substantial, with the exception of the TypeCode interpreter API which -was added to the C++ mapping. - -Also, note that the goal of this software is fidelity to the IIOP, so that -issues relating (in particular) to the C++ language mapping or other OMG -specifications were judged to be of less importance at this time. - - -DIFFERENCES from IIOP in UNO Spec (95-3-10) -------------------------------------------- -Some changes to the original specification (94-9-32) for the IIOP protocol -were found to be necessary; most related to the subsequently adopted Interface -Repository (IFR) specification (94-11-7). Others resulted from correction -of minor editorial errors, and experience gained as multiple teams implement -to that specification. - -The bulk of those changes have been incorporated into the 95-3-10 document, -but these few have not. - - -CDR TYPECODE INDIRECTION - -An additional constraint on the use of typecode indirection has been -identified. Specifically, the typecode to which an indirection points -be "self-sufficient", and may not point "outside of itself" for any -further indirections. For example, always indirections occur within -encapsulations, so it's OK for the indirection to point anywhere in -that encapsulation, or at the encoded TCKind enum value immediately -before the encapsulation's length. For typecode encapsulations nested -inside other typecode encapsulations, the indirection may point no -further than the outermost encapsulation. - -Also, when an indirection points to another typecode, the byte order -of that other typecode must be deduced from the encoded value found -there. This is straightforward for encoded TCKind values, all of which -fit into a single byte: if the first byte of the word is zero, then -the encoding is big-endian, else it's little-endian. - -Indirecting to another indirection is not allowed, since the byte order -of the encoded offset can't consistently be deduced. - - -MISCELLANY - -The type GIOP::Version is assumed to be identical to IIOP::Version. -As part of the editorial separation of GIOP from its Internet version -IIOP, this typedef was accidentally omitted. - -This implementation of IIOP supports the OMG-IDL Primitive Data Types as -defined in Appendix A of 94-9-32, but with TCKind numbers following the new -tk_exception and tk_alias codes. (That is, rather than using range 21-25, -these TCKind values are in the range 23-27.) - -These data types are currently the topic of an RFP in process in the OMG, -and are not currently defined as part of a current OMG specification. -Clients and servers using these extended data types are relying on CORBA -extensions that are not yet standardized; and should be prepared to change. - - -CORBA 2.0/CORE Differences --------------------------- -As of this writing, the new CORBA 2.0/CORE document has not yet been made -available. This is a modification of the CORBA 1.2 document, with the -addition of (mandatory) extensions from the UNO (94-9-32) specification: -notably DSI and some new object reference operations. This summarizes -differences between the as-yet-unpublished CORBA 2.0/CORE document and -the original text in the UNO specification. - - -DYNAMIC SKELETON INTERFACE - -Since the new "tk_except" typecodes now include the exception ID (this is -the repository ID describing the exception's type) the "exception" operation -used to report an exception through a ServerRequest no longer includes the -exception ID. - -Since the OperationDef entries for attributes are no longer found in the -interface repositories, the ServerRequest convenience operation to return -this has been removed. Application programs (such as bridges) must compare -the operation name string with the prefixes "_get_" and "_set_" to see if -any given operation applies to an attribute. If an operation is one of the -two for which an OMG-IDL "attribute" declaration is shorthand, then the -application must search the interface repository for that attribute. - -(There are in fact three categories of operations on which an object adapter -and implementation collaborate to handle: user defined operations, user -defined attributes, and operations defined by CORBA such as "is_a" and -"get_implementation". Some object adapters, like the BOA, handle this last -category directly, rather than exposing it to applications.) - -The "non_existent" objref operation accidentally used attribute syntax; this -has been corrected. All operations on CORBA::Object references now use -normal operation syntax in their (pseudo) IDL definitions, and are uniformly -prefixed with underscores as part of their C++ mapping. - - -DIFFERENCES from IDL C++ Mapping (94-9-14) ------------------------------------------- -There are four basic ways in which the IIOP framework does not comply -with the OMG's IDL C++ mapping specification, beyond the use of the CORBA2 -module/namespace rather than the CORBA module/namespace. (CORBA2 is used -so that this software can be linked with existing ORBs, which should be -using the CORBA module/namespace already.) - -These ways are beyond the portability-derived use of the "class" construct -(instead of the C++ namespace construct), and the use of CORBA2::Environment -(rather than C++ exceptions), both of which are accomodated by the mapping: - - (1) This framework does not attempt to be complete. - - Completeness is not required to implement the Internet IOP, - so time was not spent in providing a complete mapping. - - (2) In some cases the API provided is not the one in the mapping. - For example CORBA2::Environment is not always passed in all - operations. This was done to promote ease of implementation - and coding. - - (3) Implementation details are generally exposed. - - This isn't so much a noncompliance issue (it's not specified - that such details must be hidden) as an issue of allowing - noncompliant applications. The effort required to actively - prevent use of implementation details by higher level code - would be nontrivial, and could slow down IIOP code, so no - time was applied to hiding such details. - - (However, note that when the software was modified to use COM, - standard C++ techniques were used to hide most such details.) - - (4) The C++ mapping needs completion in some areas. - - Notably, 94-9-14 does not satisfy requirements to provide - support for for all data types in an "Any" or exception without - needing any precompiled data type support routines. The - TypeCode interpreter addresses this issue. - - Some additional operations were not adopted at the time 94-9-14 - was defined; both 94-9-32 and 94-11-7 added new ORB interfaces - which are not found in the initial C++ mapping document. - -With respect to this fourth issue, descriptions of the API extensions -used is provided later in this file. The additional CORBA operations -are not described since their mapping is straightforward if it isn't given -in those documents. - - -ACCESS TO ALL DATA IN "ANY" AND EXCEPTIONS - -The "void *" value in an "Any", and any "CORBA2::Exception *" value, may -always be passed to the TypeCode interpreter (see next). This allows access -to all data held within an "Any" and an Exception. The "void *" value in an -Any with an exception TypeCode is of type CORBA2::Exception *". Due to -the way CORBA is specified, it is not possible to tell whether an "Any" -holding an exception denotes a user or standard (system-defined) exception -except by exhaustive comparison against exception IDs. - -Also, _all_ legal OMG-IDL data types may be held in an "Any", and may be -manipulated using the TypeCode interpreter. This satisfies a language -mapping requirement that DII (and DSI) be able to manipulate all OMG-IDL -data types without requiring compiler generated support for them. - - -TYPECODE INTERPRETER - -In any given C/C++ execution environment there is a binary standard for how -data is represented. While that standard will differ between execution -environments, there are a very limited number of ways in which those -representations differ. Those differences are encapsulated only in the -TypeCode interpreter, so that portable applications using the dynamic -typing infrastructure in the ORB can completely ignore how it's done in -any particular environment. - -The APIs in this software distribution have been suggested for adoption as -part of the OMG specification suite. The two APIs are nonstatic member -functions in the C++ mapping's TypeCode pseudo-object, and are augmented -by a single new enumeration type. - - unsigned long size() - - This returns the size of an instance of the type that is - described by the TypeCode. - - For example, when invoked on the typecode constant CORBA::_tc_Short, - the value returned is sizeof(CORBA::Short); and when invoked on the - typecode for a structure, it is the size of that structure (including - any internal and tail padding needed). When invoked on a sequence - typecode, it returns a value that does not include the size for - any embedded buffer. - - enum traverse_status {TRAVERSE_STOP, TRAVERSE_CONTINUE }; - - This is a data type used in the traverse() member function. - It allows data type traversal to be terminated early for - non-exceptional conditions, and eliminates the confusion - that some similar APIs have created when they use a single - boolean value (does TRUE mean to stop, or to continue?). - - traverse_status traverse ( - const void *value1; - const void *value2 - traverse_status visit ( - TypeCode_ptr tc, - const void *visit_value1, - const void *visit_value2, - void *visit_context - ), - void *context - ); - - (In the current language mapping, CORBA2::Environment references - are passed as the final parameter to the 'traverse' and 'visit' - routines for use when reporting exceptions.) - - The pointers "value1" and "value2" point to instances of the - data type described by the typecode (or are null pointers). - - For each constituent of that data type (e.g. structure member) - the visit() routine is called once. The constituent's type - is described by "tc"; "visit_value1" points to the constituent - of that type in "value1" (assuming the traverse routine was - not passed a null pointer) and similarly for "visit_value2". - The "visit_context" parameter is the context parameter passed - to the traverse() routine, and can point to whatever data is - needed by the visit() routine. - - Members are traversed in first-to-last order, as defined in the - IDL specification for the data type. So for example, the - visit routine for a structure could print out each element - on a IO stream passed through the context parameter, perhaps in - a neatly formatted form intended for human consumption. - - The visit() function may choose to recursively traverse() each - element. So for example if "tc->kind()" in a visit routine - returned CORBA::tk_struct, the contents of that struct would - be ignored unless the visit routine invoked traverse() using - the typecode and values passed to it. - - If the visit() routine returns TRAVERSE_CONTINUE, succeeding - constituents of the data type are visited in turn; if it - returns TRAVERSE_STOP, the traverse() routine returns that - value to its caller. Of course, if a visit() routine calls - traverse() itself, it may choose to ignore TRAVERSE_STOP. - -The traverse() routine is a powerful tool. It is used in the IIOP code -itself in several ways; look at such use for tutorial details. You could -implement data value comparison and "debug" data dumping as simple exercises -in the use of these APIs. - -The "marshaling interpreter" (marshal.cc) uses it to encode and decode -values according to the IIOP protocol specification. The "Any" code -(any.cc) uses traverse() both to free embedded pointers, and to make "deep" -copies of any data structure given its TypeCode. - -Only that "deep copy" visit routine uses "value2" as anything other than a -null pointer; it allows efficient construction of "deep copies" without -needing extra space for temporary values or coroutine stacks. (A general -purpose two-value comparison could also use "value2".) Most uses of the API -only manipulate a single data value at a time; no realistic need has yet -been seen for manipulating more than two data values at once. - -With respect to the OMG C and C++ mappings, it is clear that this style API -must be provided for the C mapping, but some people have noted that a -"purer" object oriented style API could also be provided in C++. That style -would use another internal visit routine, performing the requisite "switch" -over the fixed number of TCKind values, and then make a virtual function -call to an instance of a C++ class whose private state was the "context" and -whose member functions matched the arms of the switch. - - -MEMORY ALLOCATION - -In order to dynamically manipulate instances of arbitrary data types, -applications need to be able to allocate and free memory. The OMG C++ -mapping only says how to do this for data types which have static C++ -interfaces defined, which is clearly inadequate for using constructed -types with the DII/DSI/Any family of interfaces. - -This infrastructure requires the standard "malloc" and "free" primitives to -be used, and cast to the appropriate type. Data allocated using malloc -will normally be sized according to TypeCode::size(), and then be stored -inside an Any. When the Any is deleted, if the ORB deallocates the memory -it always uses "free" (including for any nested pointers, and correctly -handling cases such as arrays and sequences). - -Note that to support implementations where C and C++ language bindings -share the same ORB infrastructure, this solution is inadequate. This is -because the C binding's CORBA_free() interface would have no way to -determine the type of the data being freed. Instead, typed allocation -APIs will need to be used even when using the dynamically typed CORBA -subsystem ... a TypeCode::malloc() routine would suffice, if it returned -memory that was internally tagged with that TypeCode. In such a case, -the CORBA_free() routine could use that TypeCode to "deep free" data as -required, and C++ "new" and "delete" operators would need to know about -the internal tagging for all those data types. Such tagged allocation -would need to be used for all data that was to be freed by the ORB. - -(Having the C mapping require use of "typed free" routines, instead of the -CORBA_free interface, is sufficient to eliminate this problem.) - - -PASSING EXCEPTIONS THROUGH THE DII - -The C++ mapping's Dynamic Invocation Interface (DII) has key omissions -in that it doesn't say how to access to user-defined exception values, -and implicitly requires ORBs either to pass "excess" data on the wire -or else to consult an interface repository to deal with exceptions or -(deprecated) "context" strings. - -This software changes the DII specification in two ways to support the -requirement for DII users to be able to see user-defined exceptions, yet -not to violate the OMG-IDL type model by reporting illegal exceptions: - - * The Object::_create_request() member function, through which DII - users provide all the information included in an IDL operation's - signature, has an additional parameter. - - That parameter is a sequence of exception typecodes, describing - the user-defined exceptions that the operation can return. (The - standard exceptions defined in CORBA may always be returned.) - When any other exception is returned, the client's ORB reports that - the object's type definition has been violated by the server's ORB. - - * The TypeCode interpreter (see above) may be used to examine all - exception values reported through a CORBA::Environment. A new - Exception::id() operation may be used to determine which typecode - should be used. - -Note that a number of portability and specification problems have been -identified in the current C++ mapping for DII, e.g. for details of memory -management. Later versions of this code may attempt to closely comply -with an improved mapping for DII, to the extent that the interpretation -used here differs from that more unambiguous specification. - -Since there is no efficient way to distinguish typecodes for user defined -exceptions from ones for system-defined ("standard") exceptions (comparing -the exception ID against all the system defined ones is inefficient :-) -a new enum type "ExceptionType" is defined. (An analogous type is already -defined for the C language mapping.) This is used to report exceptions -through DII and DSI. diff --git a/TAO/docs/HISTORY b/TAO/docs/HISTORY deleted file mode 100644 index d97a8e35b2e..00000000000 --- a/TAO/docs/HISTORY +++ /dev/null @@ -1,44 +0,0 @@ -@(#)HISTORY 1.1 95/09/13 - -Mmmmmmmm DD, 1995 -- RELEASE 1.3: ---------------------------------- -Release 1.3 includes bugfixes, and support for the COM binary interface -model, both on UNIX and on MS-Windows platforms. The source tree has -been considerably restructured, with the goal of enabling addition of -other components at both the binary and source levels. - - -September 1, 1995 -- RELEASE 1.2: ---------------------------------- -Release 1.2 includes fixes for problems noted in the recent multivendor -interoperability testing at Object World, and as reported by other users on -the Internet. The most notable of these is that in some cases, when using -multiple connections to IIOP servers and clients, the connection management -code previously would get confused about which connection was which. (One -consequence of fixing this is that an old test has been removed.) Also, -there was no simple way to use Solaris 2.4 threads; see the Makefile for -details. A few other minor features were added to facilitate use of this -code for more than just protocol testing. - - -June 28, 1995 -- RELEASE 1.1: ------------------------------ -Release 1.1 includes support for several new platforms. Particular thanks -go to the team at APM, which contributed the bulk of the new "autoconf" -support (substantially enhancing portability), support for DEC Alpha and -HP 9000 platforms, runtime initialization of the size and alignment table -used to drive the typecode interpreter, and more; see README.apm for details. - -Release 1.1 includes POSIX.1c threading support; on platforms which provide -POSIX.1c threads, applications will be able to take advantage of them. - -Union and indirection support has been added to the TypeCode interpreter, -and more typecode utility APIs have been implemented. Various bugfixes and -cleanup have also been provided. Unfinished stubs for the COS Naming service -are included; these rely on C++ exception support. - - -March 21, 1995 -- RELEASE 1.0: ------------------------------- -The original release ran on a set of UNIX platforms (including Solaris, -SunOS, Linux, and NEXTSTEP) as well as with 16-bit and 32-bit MS-Windows. diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html deleted file mode 100644 index 4a5aa57361e..00000000000 --- a/TAO/docs/Options.html +++ /dev/null @@ -1,177 +0,0 @@ -<HTML> -<HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>Options for TAO Components</TITLE> -</HEAD> -<BODY> - -<H1 ALIGN=CENTER>Options for TAO Components</H1> - -<H2>Overview</H2> -<blockquote> -<P>Certain components in TAO such as the ORB Core or object adapter -can be tuned by users by providing value for options to them. These -options are commonly specified as strings (<EM>e.g.</EM>, passed on -the command-line) and are passed to component initialization methods -for consumption.</P> - -<P><EM>Programmer's Note:</EM> the internal structure for these -options is the traditional <CODE>argc</CODE>/<CODE>argv</CODE> vector -of strings style popularized by C and Unix. By convention, an -initialization method will <b>NOT</b> consume, <EM>i.e.</EM> ,remove -from the vector, any options that it recognizes. Rather, it will -leave those options intact, and it will also simply ignore any options -is does not recognize as its own.</P> -</blockquote> - -<H2>Types of Options</H2> - -<H2>Roadmap</H2> - -<blockquote> -<P>The following components can be tuned via options:</P> - -<UL> - <LI><A HREF="#ORB"><CODE>CORBA::ORB</CODE></A> - <LI><A HREF="#POA"><CODE>CORBA::POA</CODE></A> - <LI><A HREF="#ResourceFactory"><CODE>TAO_Resource_Factory</CODE></A> - <LI><A HREF="#DefaultServer"><CODE>TAO_Default_Server_Strategy_Factory</CODE></A> - <LI><A HREF="#DefaultClient" TARGET="_top"><CODE>TAO_Default_Client_Strategy_Factory</CODE></A> -</UL> -</blockquote> - -<H2>Options</H2> - -<blockquote> -<H3><CODE>CORBA::ORB</CODE><A NAME="ORB"></A></H3> - -<P><TABLE BORDER="2" WIDTH="100%" HEIGHT="96" CELLSPACING="2" CELLPADDING= -"0"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="57%">Description</TH></TR> -<TR> -<TD HEIGHT="30"><CODE>-ORBsvcconf</CODE> <EM>config file name</EM></TD> -<TD>Specifies the name of the file from which it will read dynamic service configuration -directives <EM>ala</EM> ACE's Service Configurator.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBdaemon</CODE></TD> -<TD>Specifies that the ORB should <I>daemonize</I> itself.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBdebug</CODE></TD> -<TD>Turns on the output of debugging messages within ACE's Service Configurator -componentry.</TD></TR> -<TR> -<TD><CODE>-ORBhost</CODE> <EM>hostname</EM></TD> -<TD>Tells the Object Adapter to listen for requests on the interface associated -with the host named <I><EM>hostname</EM></I>.</TD></TR> -<TR> -<TD><CODE>-ORBport</CODE> <EM>portspec</EM></TD> -<TD>Tells the Object Adapter to listen for requests on the port specified by -<I><EM>portspec</EM></I>, which can be a name as found in <TT>/etc/services</TT> -or a number. The default is <TT>10013</TT>.</TD></TR> -<TR> -<TD><CODE>-ORBobjrefstyle</CODE> <EM>which</EM></TD> -<TD>Specifies the user-visible style of object references. The range of values -is <CODE>IOR</CODE>, which is the traditional nonsensical object reference, -or <CODE>URL</CODE>, which looks more like a URL.</TD></TR> -<TR> -<TD><CODE>-ORBobjdemux</CODE> <EM>demux_method</EM></TD> -<TD>Specifies the method used to demultiplex to an object. The range of values -is <CODE>dynamic</CODE>, <CODE>linear</CODE>, <CODE>active</CODE>, or <CODE>user</CODE>.</TD></TR> -<TR> -<TD><CODE>-ORBtablesize</CODE> <EM>object table size</EM></TD> -<TD>Specifies the size of the object table as a positive, non-zero integer. -If not specified, the default is <TT>64</TT>.</TD></TR> -<TR> -<TD><CODE>-ORBrcvsock</CODE> <EM>receive buffer size</EM></TD> -<TD>Specify the size of the socket receive buffer as a positive, non-zero integer. -If not specified, the system-dependent default is used.</TD></TR> -<TR> -<TD><CODE>-ORBsndsock</CODE> <EM>send buffer size</EM></TD> -<TD>Specify the size of the socket send buffer as a positive, non-zero integer. -If not specified, the system-dependent default is used.</TD></TR> -<TR> -<TD><CODE>-OAthread</CODE></TD> -<TD>Specify a thread-per-connection concurrency policy be utilized in processing -requests.</TD></TR> -<TR> -<TD><CODE>-ORBnameserviceport</CODE> <EM>portspec</EM></TD> -<TD>Specifies which port the Naming Service is listening on.</TD></TR> -<TR> -<TD><CODE>-ORBnameserviceior</CODE> <EM>ior</EM></TD> -<TD>Specifies the IOR for the Naming Service.</TD></TR> -</TABLE> -</P> - -<H3><CODE>CORBA::POA</CODE><A NAME="POA"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%"> -<TR> -<TH WIDTH="43%">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD><CODE>-OAid</CODE> <EM>OA Identifier</EM></TD> -<TD>Associates <I><EM>OA Identifier</EM></I> with the Object Adapter.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Resource_Factory</CODE><A NAME="ResourceFactory"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%" HEIGHT= -"186"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBresources</CODE> <EM>which</EM></TD> -<TD>Specify whether each thread uses a global -(<em>which</em> = <code>global</code>) or a thread-specific -(<em>which</em> = <code>tss</code>) instance for the resources it returns.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Default_Server_Strategy_Factory</CODE><A NAME="DefaultServer"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%" HEIGHT= -"186"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBthreadflags</CODE> <EM>thread flags</EM></TD> -<TD>Specify the flags used for thread creation. Flags can be any logical-OR -combination of <CODE>THR_DETACHED</CODE>, <CODE>THR_BOUND</CODE>, <CODE>THR_NEW_LWP</CODE>, -<CODE>THE_SUSPENDED</CODE>.</TD></TR> -<TR> -<TD HEIGHT="30"><CODE>-ORBtablesize</CODE> <EM>object table size</EM></TD> -<TD>Specify the size of the object table. If not specified, the default value -is 64.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBconcurrency</CODE> <EM>which</EM></TD> -<TD>Specify which concurrency strategy to use. Range of values is <code>reactive</code> -for a purely Reactor-driven concurrency strategy or -<code>thread-per-connection</code> for creating a new thread to service each connection.</TD></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBdemuxstrategy</CODE> <EM>demultiplexing strategy</EM></TD> -<TD>Specify the demultiplexing lookup strategy. The <EM>demultiplexing strategy</EM> -can be one of <CODE>dynamic</CODE>, <CODE>linear</CODE>, <CODE>active</CODE>, -or <CODE>user</CODE>.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Default_Client_Strategy_Factory</CODE><A NAME="DefaultClient"></A></H3> - -<BLOCKQUOTE> - <P>There are currently no options for the <CODE>TAO_Default_Client_Strategy_Factory</CODE>.</P> -</BLOCKQUOTE> -</blockquote> - -<P><HR ALIGN=LEFT></P> - -<ADDRESS><A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A></ADDRESS> - -<P><!-- Created: Fri Aug 29 10:06:40 CDT 1997 --><!-- hhmts start -->Last -modified: Wed Sep 3 16:35:23 CDT 1997 <!-- hhmts end --> -</BODY> -</HTML> diff --git a/TAO/docs/REFERENCES b/TAO/docs/REFERENCES deleted file mode 100644 index a44ef31c16e..00000000000 --- a/TAO/docs/REFERENCES +++ /dev/null @@ -1,91 +0,0 @@ -@(#)REFERENCES 1.2 95/11/08 - -REFERENCES -========== -Most of the relevant references here are to OMG documents, however there -are a few external references of some note: - - * http://www.uci.agh.edu.pl/research/cs/TOCOOS/COPERNICUS.html - - -OMG REFERENCES --------------- -As of this writing, OMG is in the process of publishing new versions of the -base CORBA specifications, merging specifications as needed into single -documents and splitting out the C mapping from the CORBA/CORE specification. - -This software has made every effort to track both the base documents and the -agreed corrections and revisions. Since those documents have not yet been -published, there will inevitably be areas in which it does not reflect the -versions yet to be published. See the "DIFFERENCES" file for information -about where this software differs from these current base documents: - -* CORBA 2.0/Interoperability: Universal Networked Objects (UNO), OMG - TC Document 95-3-10. This includes the mandatory IIOP and bridging - support, as well as the optional DCE-CIOP protocol. - -* CORBA 1.2 specification, OMG TC Document 93-12-43. This is the - base document on which the CORBA 2.0 CORE specifications build. - -* Universal Networked Objects (UNO), OMG TC Document 94-9-32. Until - the CORBA 2.0/CORE document is published, replacing the CORBA 1.2, - initialisation, and IFR specifications, you must use this earlier - version of UNO to see (only!) the specification for DSI and several - other CORBA CORE extensions (for bridging) adopted by the OMG. - [ NOTE: use the IIOP specification in 95-3-10, not the one here; - 95-3-10 has changes required by the IFR specification, 95-11-7. ] - -* Initialisation, OMG TC Document 94-10-24. This defines the portable - APIs for initialising ORBs. - -* Interface Repository, OMG TC Document 94-11-7. This updates the - CORBA specifications above and is referenced by the UNO document. - -* IDL C++ Language Mapping Specification, OMG TC Document 94-9-14. - This defines the mapping of CORBA 1.2, including OMG-IDL, onto C++. - -There are a few inconsistencies between these documents, which are in the -process of being resolved. The inconsistencies arose because different -groups worked on different parts of the system, at different times and -with some different goals. Contact the various revision committees to -find out how these differences are being resolved: - - - interop@omg.org ... the interop revision task force (RTF) - - cxx_revision@omg.org ... the C++ RTF - - orb_revision@omg.org ... the general ORB RTF - -Also, note that these ORB specifications correspond to only the lowest levels -of OMG's Object Management Architecture. In particular, the "Object Services" -define object interfaces for naming, events, persistence, relationships, -lifecycle, externalization, transactions, and concurrency control. Also, -"Common Facilities" objects will address such things as compound document -architecture. If you intend to develop software based on ORBs, these -specifications are likely to be of interest. The OMA is available in -technical bookstores: - - Richard Soley (ed.), Object Management Architecture Guide, - Second Edition, John Wiley & Sons, New York, 1992. - - -ACQUIRING REFERENCE DOCUMENTS ------------------------------ -To acquire those reference documents, use the OMG document server through -Internet email. Send a message to "server@omg.org", with content lines -such as - - send help - -to get directions about how to use the server, or - - send docs/95-3-10.ps - -to get a PostScript copy of any particular document. (OMG specifications -are available only in PostScript.) - -The OMG document server is maintained for use by OMG members, but is also -available for general Internet access. Only members will be supported in -the case of problems. - -To find out more about the OMG, send email to "omg@omg.org", or look -at the Web page at "http://www.omg.org". - diff --git a/TAO/docs/components.html b/TAO/docs/components.html deleted file mode 100644 index ae31ed258f6..00000000000 --- a/TAO/docs/components.html +++ /dev/null @@ -1,27 +0,0 @@ -<HTML> - <HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>TAO Component Documentation</TITLE> - </HEAD> - <BODY> - - <H1 ALIGN=CENTER>Component Documentation</H1> - - <P>The following documentation is available on certain TAO components:</P> - - <UL> - <LI><A HREF="Options.html">Options</A> ­ describes the - options available to tune various components within TAO. This - can be done by a user, and not a programmer.</li> - - <li><a href="configurations.html">Configuration</a> ­ - describes how to mix and match component <a - href="options.html">options</a> in order to achieve different - effects on how TAO processes requests. For example, you might - look in here to get an idea on how to configure TAO to process - each request in a separate thread, or to process each connection - in a separate thread, <em>etc.</em></li> - - </UL> - </BODY> -</HTML> diff --git a/TAO/docs/configurations.html b/TAO/docs/configurations.html deleted file mode 100644 index 288be71d330..00000000000 --- a/TAO/docs/configurations.html +++ /dev/null @@ -1,177 +0,0 @@ -<HTML> - <HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>Configuring TAO's Components</TITLE> - </HEAD> - <BODY> - - <H1 ALIGN=CENTER>Configuring TAO's Components</H1> - - <H2>Overview</H2> - <blockquote> - <p>As described in the <a href="Options.html">options</a> - documentation, various components in TAO can be "tuned" by specifying - options for those components. Here we present some examples of how to - combine these options to achieve certain effects on ORB operations.</P> - </blockquote> - - <H2>Where Are Options Specified?</H2> - <blockquote> - <p>TAO configures itself using the ACE Service Configurator - framework. Thus, options are specified in the familiar - <code>svc.conf</code> file (if you want to use a different file - name, use the <a - href="Options.html#svcfonf"><code>-ORBsvcconf</code></a> - option</p> - </blockquote> - - - <H2>Roadmap</H2> - - <blockquote> - <P>Details for the following configurations are provided.</P> - - <UL> - <LI><A HREF="#"><CODE>CORBA::ORB</CODE></A> - <LI><A HREF="#"><CODE>CORBA::POA</CODE></A> - <LI><A HREF="#"><CODE>TAO_Resource_Factory</CODE></A> - <LI><A HREF="#"><CODE>TAO_Default_Server_Strategy_Factory</CODE></A> - <LI><A HREF="#"><CODE>TAO_Default_Client_Strategy_Factory</CODE></A> - </UL> - </blockquote> - - <H2>Options</H2> - - <blockquote> - <H3><CODE>CORBA::ORB</CODE><A NAME="ORB"></A></H3> - -<P><TABLE BORDER="2" WIDTH="100%" HEIGHT="96" CELLSPACING="2" CELLPADDING= -"0"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="57%">Description</TH></TR> -<TR> -<TD HEIGHT="30"><CODE>-ORBsvcconf</CODE> <EM>config file name</EM></TD> -<TD>Specifies the name of the file from which it will read dynamic service configuration -directives <EM>ala</EM> ACE's Service Configurator.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBdaemon</CODE></TD> -<TD>Specifies that the ORB should <I>daemonize</I> itself.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBdebug</CODE></TD> -<TD>Turns on the output of debugging messages within ACE's Service Configurator -componentry.</TD></TR> -<TR> -<TD><CODE>-ORBhost</CODE> <EM>hostname</EM></TD> -<TD>Tells the Object Adapter to listen for requests on the interface associated -with the host named <I><EM>hostname</EM></I>.</TD></TR> -<TR> -<TD><CODE>-ORBport</CODE> <EM>portspec</EM></TD> -<TD>Tells the Object Adapter to listen for requests on the port specified by -<I><EM>portspec</EM></I>, which can be a name as found in <TT>/etc/services</TT> -or a number. The default is <TT>10013</TT>.</TD></TR> -<TR> -<TD><CODE>-ORBobjrefstyle</CODE> <EM>which</EM></TD> -<TD>Specifies the user-visible style of object references. The range of values -is <CODE>IOR</CODE>, which is the traditional nonsensical object reference, -or <CODE>URL</CODE>, which looks more like a URL.</TD></TR> -<TR> -<TD><CODE>-ORBobjdemux</CODE> <EM>demux_method</EM></TD> -<TD>Specifies the method used to demultiplex to an object. The range of values -is <CODE>dynamic</CODE>, <CODE>linear</CODE>, <CODE>active</CODE>, or <CODE>user</CODE>.</TD></TR> -<TR> -<TD><CODE>-ORBtablesize</CODE> <EM>object table size</EM></TD> -<TD>Specifies the size of the object table as a positive, non-zero integer. -If not specified, the default is <TT>64</TT>.</TD></TR> -<TR> -<TD><CODE>-ORBrcvsock</CODE> <EM>receive buffer size</EM></TD> -<TD>Specify the size of the socket receive buffer as a positive, non-zero integer. -If not specified, the system-dependent default is used.</TD></TR> -<TR> -<TD><CODE>-ORBsndsock</CODE> <EM>send buffer size</EM></TD> -<TD>Specify the size of the socket send buffer as a positive, non-zero integer. -If not specified, the system-dependent default is used.</TD></TR> -<TR> -<TD><CODE>-OAthread</CODE></TD> -<TD>Specify a thread-per-connection concurrency policy be utilized in processing -requests.</TD></TR> -<TR> -<TD><CODE>-ORBnameserviceport</CODE> <EM>portspec</EM></TD> -<TD>Specifies which port the Naming Service is listening on.</TD></TR> -<TR> -<TD><CODE>-ORBnameserviceior</CODE> <EM>ior</EM></TD> -<TD>Specifies the IOR for the Naming Service.</TD></TR> -</TABLE> -</P> - -<H3><CODE>CORBA::POA</CODE><A NAME="POA"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%"> -<TR> -<TH WIDTH="43%">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD><CODE>-OAid</CODE> <EM>OA Identifier</EM></TD> -<TD>Associates <I><EM>OA Identifier</EM></I> with the Object Adapter.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Resource_Factory</CODE><A NAME="ResourceFactory"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%" HEIGHT= -"186"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBresources</CODE> <EM>which</EM></TD> -<TD>Specify whether each thread uses a global -(<em>which</em> = <code>global</code>) or a thread-specific -(<em>which</em> = <code>tss</code>) instance for the resources it returns.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Default_Server_Strategy_Factory</CODE><A NAME="DefaultServer"></A></H3> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" WIDTH="100%" HEIGHT= -"186"> -<TR> -<TH WIDTH="43%" HEIGHT="17">Option</TH> -<TH WIDTH="55%">Description</TH></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBthreadflags</CODE> <EM>thread flags</EM></TD> -<TD>Specify the flags used for thread creation. Flags can be any logical-OR -combination of <CODE>THR_DETACHED</CODE>, <CODE>THR_BOUND</CODE>, <CODE>THR_NEW_LWP</CODE>, -<CODE>THE_SUSPENDED</CODE>.</TD></TR> -<TR> -<TD HEIGHT="30"><CODE>-ORBtablesize</CODE> <EM>object table size</EM></TD> -<TD>Specify the size of the object table. If not specified, the default value -is 64.</TD></TR> -<TR> -<TD HEIGHT="17"><CODE>-ORBconcurrency</CODE> <EM>which</EM></TD> -<TD>Specify which concurrency strategy to use. Range of values is <code>reactive</code> -for a purely Reactor-driven concurrency strategy or -<code>thread-per-connection</code> for creating a new thread to service each connection.</TD></TR> -<TR> -<TD HEIGHT="43"><CODE>-ORBdemuxstrategy</CODE> <EM>demultiplexing strategy</EM></TD> -<TD>Specify the demultiplexing lookup strategy. The <EM>demultiplexing strategy</EM> -can be one of <CODE>dynamic</CODE>, <CODE>linear</CODE>, <CODE>active</CODE>, -or <CODE>user</CODE>.</TD></TR> -</TABLE> -</P> - -<H3><CODE>TAO_Default_Client_Strategy_Factory</CODE><A NAME="DefaultClient"></A></H3> - -<BLOCKQUOTE> - <P>There are currently no options for the <CODE>TAO_Default_Client_Strategy_Factory</CODE>.</P> -</BLOCKQUOTE> -</blockquote> - -<P><HR ALIGN=LEFT></P> - -<ADDRESS><A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A></ADDRESS> - -<P><!-- Created: Fri Aug 29 10:06:40 CDT 1997 --><!-- hhmts start -->Last -modified: Wed Sep 3 16:35:23 CDT 1997 <!-- hhmts end --> -</BODY> -</HTML> diff --git a/TAO/docs/index.html b/TAO/docs/index.html deleted file mode 100644 index a7bf0dfe2bc..00000000000 --- a/TAO/docs/index.html +++ /dev/null @@ -1,18 +0,0 @@ -<HTML> -<HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>TAO Documentation</TITLE> -</HEAD> -<BODY> - -<H1 ALIGN=CENTER>TAO Documentation</H1> - -<P>This is a guide to various pieces of documentation on The ACE ORB (TAO).</P> - -<UL> - <LI>Background - <LI><A HREF="releasenotes.html">In this release</A> - <LI><A HREF="components.html" TARGET="_top">Components</A> -</UL> -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes.html b/TAO/docs/releasenotes.html deleted file mode 100644 index 21854918af1..00000000000 --- a/TAO/docs/releasenotes.html +++ /dev/null @@ -1,26 +0,0 @@ -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; Linux 2.0.30_SMP i686) [Netscape]"> - <META HTTP-EQUIV="Refresh" CONTENT="1;URL=releasenotes/index.html"> - <TITLE>TAO Release Information and TODO List</TITLE> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F"> -<!-- $Id$ --> -<CENTER> -<H2> -Release Information for The ACE ORB (TAO)</H2></CENTER> - -<CENTER> -<H3> -Version 0.0.12</H3></CENTER> - -<CENTER> -<H3> -17-October-1997</H3></CENTER> - -<HR> - -This document has moved <a href="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/releasenotes/index.html">here</a>. - -</HTML> diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index 0f7d36a9969..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,344 +0,0 @@ -<HTML> -<HEAD> - <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> - <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; I; Linux 2.0.30_SMP i686) [Netscape]"> - <TITLE>TAO Release Information and TODO List</TITLE> -</HEAD> -<BODY TEXT="#000000" BGCOLOR="#FFFFFF"> -<!-- $Id$ --> -<CENTER> -<HR> -<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="TAO.html">TAO</A>: - -<UL> -<LI> - -<A HREF="orbcore.html">ORB & ORB Core</A></LI> - -<LI> -<A HREF="#idl">IDL Compiler</A></LI> - -<LI> -<A HREF="#eventchannel">Event Channel</A></LI> - -<LI> -<A HREF="#apps">Test & Example Applications</A></LI> - -<LI> -<A HREF="#poa">Portable Object Adapter</A></LI> - -<LI> -<A HREF="#nservices">CORBA Naming Service</A></LI> -<LI> -<A HREF="#tservices">CORBA Trader Service</A></LI> - -<LI> -<A HREF="#ace">ORB-related ACE Changes</A></LI> -</UL> - -<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/orbcore.html" --> - - <HR> - - <H3><A NAME="idl"></A>IDL Compiler</H3> - Point of contact: <A HREF="mailto:gokhale@cs.wustl.edu">Aniruddha Gokhale</A> - - <P> Current status: (As of Nov 25th, 1997.) - <UL> - <LI> Generated code closely follows the C++ Mapping specified in - the POA Specification (ORBOS/97-05-15). </LI> - - <LI> Many IDL constructs supported including primitive types, - typedefs, sequences, structures, and unions. </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> Include files are handled properly. So are the definitions - used inside the include files that are used in the currently - parsed files. </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> IN, INOUT, and OUT object reference parameters are now - supported properly. We think the same approach should work - for sequences, structs, and unions. </LI> - - <LI> Support for attributes completed and is currently undergoing - testing </LI> - - <LI> The latest success story is that the compiler - generates correct code for COSS Naming service and it - runs properly. Correct code also gets generated for the - Event Channel program </LI> - </UL> - - <P> Known bugs: - <UL> - <LI>Works for <I>most</I> IDL constructs. Some of the known - bugs/incomplete tasks are: - <UL> - <LI> Problems when interfaces use single or multiple - inheritance. The problem is with the demultiplexing - code. </LI> - - <LI> - Sequences of strings and object references still - pose problems </LI> - - <LI> - TypeCode generation for multidimensional arrays and - indirected typecodes is still a problem. </LI> - - <LI> - Exceptions are not well-supported. TAO does not use - C++ Exceptions. Instead we use the alternative - mapping that uses CORBA::Environment. </LI> - - <LI> Unions with default cases yet to be handled </LI> - - <LI> The <<= and >>= operators for user-defined types - are not generated yet. </LI> - - <LI> Deal with names in the IDL definition that are C++ - keywords. </LI> - - </UL> - </LI> - </UL> - - Future work: - <UL> - - <LI>Improve IDL compiler to support complete IDL-to-C++ mapping.</LI> - - <LI>Fix bugs in the SunSoft IDL front-end we've - uncovered. These primarily include support for Unions.</LI> - - <LI>Add command line options to TAO IDL. These options will - decide what strategy to use for operation name - demultiplexing. Another option may decide whether to use - the interpretive IIOP engine or generate compiled - stubs/skeletons. </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> - - <LI>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.</LI> - - <LI>In doing the above, improvements to the IIOP protocol - engine in terms of size/performance/determinism will be - made.</LI> - </UL> - -<HR> -<H3> -<A NAME="eventchannel"></A>Real-time Event Channel</H3> -Point of contact: <A HREF="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</A> - -<P>Current status: -<UL> -<LI> -The current Event Channel is running under Orbix, fully distributed, the -main test has three processes, one runs the EC itself, one a Supplier and -yet another a Consumer.</LI> - -<LI> -The configuration runs can be done even on the distributed scenario, using -the Real-time "Scheduling Service", which now has an IDL interface.</LI> - -<LI> -At run-time (no config runs) there is no need to use the Real-time Scheduling -Service, a faster, collocated implementation for the service is available. -Obviously the information is generated on the config runs and linked into -the program.</LI> - -<LI> -We are using an implementation of the standard <A HREF="#naming">Naming -Service</A> for Orbix.</LI> -</UL> -Future work: -<UL> -<LI> -Port to TAO (once IDL compiler is available and stable).</LI> - -<LI> -The Scheduling Service is completely independant of the EC and the configuration -of suppliers or consumers. I think it would be convenient to have a library -and binaries for it, including a tool to dump the results in a C++ compilable -form.</LI> -</UL> - -<HR> -<H3> -<A NAME="apps"></A>Test & Example Applications</H3> -Point of contact: <A HREF="mailto:sumedh@cs.wustl.edu">Sumedh Mungee</A> - -<P>Current status: - -<P>The TAO 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. <P> - -<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> - -<HR> -<H3> -<A NAME="poa"></A>Portable Object Adapter</H3> -Point of contact: <A HREF="mailto:irfan@cs.wustl.edu">Irfan Pyarali</A> - -<P>Current Status: -<UL> -<LI> -The POA is not integrated into this release, though we've begun migrating -TAO's OA to use POA method names.</LI> -</UL> -Critical work: - -<UL> -<LI> -Re-generate win32 project files with new file names.</LI> - -<LI> -Add resolve_initial_references() to resolve the "RootPOA" entry.</LI> -</UL> - -Future work: -<UL> -<LI> -Mostly compliant with the <A HREF="http://siesta.cs.wustl.edu/~cleeland/tao/POA.pdf">ORB -Portability Specifications [orbos/97-05-15]</A> published by OMG.</LI> - -<LI> -Provide extensions of the specification to ensure real-time delivery of -messages.</LI> -</UL> - -<HR> -<H3> -<A NAME="nservices"></A>CORBA Naming Service</H3> -Point of contact: <A HREF="mailto:sergio@cs.wustl.edu">Sergio -Flores-Gaitan</A> and <A HREF="mailto:marina@cs.wustl.edu">Marina -Spivak</A><P> - -<P>Current status: -<UL> -<LI> -This implementation works with TAO.</LI> -</UL> - -<!--#include virtual="/~schmidt/ACE_wrappers/TAO/docs/releasenotes/trader.html" --> -<HR> -<H3> -<A NAME="ace"></A>ORB-related ACE Changes</H3> -Points of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</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 <code>inet_ntoa</code> - 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 - <code>connect()</code> fails with <code>EWOULDBLOCK</code>, - 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. <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. </li> - - - </UL> - - <P>Future work: - - <blockquote> - <em>None currently scheduled.</em> - </blockquote> - -</BODY> -<hr><P> -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</HTML> diff --git a/TAO/docs/releasenotes/orbcore.html b/TAO/docs/releasenotes/orbcore.html deleted file mode 100644 index 7b9bb610870..00000000000 --- a/TAO/docs/releasenotes/orbcore.html +++ /dev/null @@ -1,246 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> - -<html> - <head> - <title>ORB & ORB Core Status</title> - </head> - - <HR> - <H3><A NAME="orb"></A>ORB & ORB Core</H3> - Point of contact: <A HREF="mailto:cleeland@cs.wustl.edu">Chris Cleeland</A> - -<P>Current status: - - <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.</LI> - </UL> - - Recently Completed Work: - - <UL> - <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 <code>ACE_INET_Addr</code> in the - private portion of <code>Profile</code> because the cost of - constructing one for every invocation (in - <code>TAO_GIOP_Invocation::start</code>) was simply - enormous--the construction was something like 100 cycles on - Solaris. This is all because deep down this ends up calling - <code>gethostbyname()</code>, 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 - (<code>-DTAO_HAS_TSS_ORBCORE</code>). This is accomplished by - having a Resource Factory (<code>TAO_Resource_Factory</code>) - 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 - <code>TAO_ORB_Core::init()</code> rather than in - <code>ORB_init()</code>.</li> - - <li>Define <code>_FAR</code> for all cases as an interim fix - for LynxOS.</li> - - <li>Fixed TAO so that the default port of 5001 is defined in - <code>orb_core.h</code> config header somewhere rather than in - <code>orbobj.cpp</code>, and use <b>MAXHOSTNAMELEN</b> ACE - constant for the hostname buffer.</li> - - <li>Eliminated need for <code>CORBA::Object</code> to keep a - pointer to its orb sitting around anywhere.</li> - - <LI>Tested <code>CORBA_ORB::shutdown()</code> as a manner in - which a thread of control can request that - <code>CORBA_ORB::run()</code> should return and no longer - service requests. It only honors a - <em>wait_for_completion</em> argument of <b>FALSE</b> right - now because we haven't fully explored the issues which - surround doing all the completion.</li> - - <li>Fixed bugs reported by Steven Wohlever, David Miron, - Manojkumar Acharya.</li> - - <li>Created a brief section in <a - href="../../TAO-Install.html"><code>$TAO_ROOT/TAO-Install.html</code></a> - that <em>briefly</em> 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 <em>Steve Wohlever - <wohlever@mitre.org></em>.</li> - - <LI>Implemented <code>CORBA_ORB::shutdown()</code> as a manner - in which a thread of control can request that - <code>CORBA_ORB::run()</code> should return and no longer - service requests.</li> - - <LI>Validated movement of Strategy Connector into - ORB Core.</LI> - - <li>Debated details of <code>Svc_Handler</code> modifications - with Irfan.</li> - - <li>Tested and commited <code>Connector::connect_n</code> changes - to ACE</code>.</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 <code>truss</code> to verify for <a - href="mailto:PAUL.G.WEHLAGE@cdev.com">Paul Wehlage</a> that - TAO really uses <code>select</code> vs. <code>recv</code> for - <b>-R</b> vs. <b>-T</b>.</li> - - <li>Renamed <code>boa.*</code> to <code>poa.*</code>.</li> - - <LI>Renamed following files: Orb_Core.* ->orb_core.* - & orbobj.* -> corba_orb.*.</LI> - - <LI>The lock used in <code>giop.cpp:626</code> originally - appeared in the IIOP-1.4 code base. Its purpose was to - protect access to the <code>fwd_profile</code> 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 - <code>TAO_OA_Connection_Handler::handle_message</code> when it - was trying to call <code>CORBA::POA::handle_request</code> - through a NULL <code>root_poa</code> 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 <code>CORBA_ORB::open()</code> 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> - </UL> - - Ongoing Work: - - <UL> - <LI>Verify ACE & TAO on Linux.</LI> - - <LI>Use Purify to eliminate straggling problems.</LI> - - </UL> - - Current Work: - - <UL> - <LI>Clean up the internals and analyze for performance bottlenecks using Quantify.</LI> - - <LI> - <p> - 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.</p> - <p> - 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.</p> - <p> - The real strategy/solution is to make - <code>CORBA::Object</code> 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.</p> - </LI> - </UL> - - Critical Work: - - <UL> - <LI>Add pre-cached connection on client side. Clients will - pass in a comma-separated list of <em>host:port</em> - destinations using the <code>CORBA::ORB_init()</code> - interface.</LI> - - <LI>Support new concurrency models, e.g., - Thread-per-Request.</LI> - - </UL> - - Future work: - <UL> - <li>Make argument parsing with the orb consume the arguments it parses.</li> - - <li>Remove <code>_FAR</code> from all code.</li> - - <li>Update ORB Patterns paper to reflect the latest TAO has to - offer. Specifically, 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>Make the section in <a - href="../../TAO-Install.html"><code>$TAO_ROOT/TAO-Install.html</code></a> - that documents installation on Unix platforms more complete. - </li> - - <li>Improve the <code>Service Configurator</code> service - entry faking on VxWorks.</li> - - <LI>Integrate the <A HREF="#poa">POA</A> implementation.</LI> - - <LI>Add support for <TT>resolve_initial_references</TT> using - ACE support for UDP broadcast.</LI> - - <LI>Assist in porting higher level services (e.g., <A - HREF="#eventchannel">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> - - <LI> Remove the CORBA_SEQUENCE structure which is not a true C++ - mapping of sequences. This will affect the code that uses - OctetSequences and TC_opaque. </LI> - - </UL> - - </body> -</html> diff --git a/TAO/docs/releasenotes/trader.html b/TAO/docs/releasenotes/trader.html deleted file mode 100644 index ac3b09fc26f..00000000000 --- a/TAO/docs/releasenotes/trader.html +++ /dev/null @@ -1,31 +0,0 @@ -<HR> -<H3><A NAME="tservices"></A>CORBA Trader Service</H3> -Point of contact: <A HREF="mailto:sbw1@cs.wustl.edu">Seth Widoff</A> and <A HREF="mailto:marina@cs.wustl.edu">Marina Spivak</a><P> - -<P>Current status: - -<ul> -<li> Lookup Interface </li> -<li> Constraint Interpreter (for constraint based lookup)</li> -<li> Register Interface </li> -<li> Offer Iterator, Offer Id Iterator </li> -<li> Abstract Interfaces </li> -<li> Service Type Repository </li> -<li> Admin Interface</li> -<li> Support for Dynamic Property Evaluation</li> -</ul> - -<P>Future work: - -<ul> -<li>Utilization of Service Type Repository by Register and Lookup <br> - to provide full type checking</li> -<li>Port to NT</li> -<li>Port to TAO</li> -<li>Link Interface </li> -</ul> - -Complete design information on the TAO Trader service is available <A -HREF="http://www.cs.wustl.edu/~marina/Trader_status.html">online</A>. - -</ul> |