diff options
| author | William R. Otte <wotte@dre.vanderbilt.edu> | 2006-07-24 15:50:11 +0000 |
|---|---|---|
| committer | William R. Otte <wotte@dre.vanderbilt.edu> | 2006-07-24 15:50:11 +0000 |
| commit | 6b846cf03c0bcbd8c276cb0af61a181e5f98eaae (patch) | |
| tree | da50d054f9c761c3f6a5923f6979e93306c56d68 /TAO/docs | |
| parent | 0e555b9150d38e3b3473ba325b56db2642e6352b (diff) | |
| download | ATCD-6b846cf03c0bcbd8c276cb0af61a181e5f98eaae.tar.gz | |
Repo restructuring
Diffstat (limited to 'TAO/docs')
269 files changed, 0 insertions, 39751 deletions
diff --git a/TAO/docs/DIFFERENCES b/TAO/docs/DIFFERENCES deleted file mode 100644 index 79ea6c7619f..00000000000 --- a/TAO/docs/DIFFERENCES +++ /dev/null @@ -1,369 +0,0 @@ -@(#)DIFFERENCES 1.1 95/09/13 - -Note -- this documentation was distributed with the original SunSoft -IIOP reference implementation and has very little relevance to what's -in TAO. We include it here only for "historical" reference, i.e., you -should disregard most of what's in this document. - - Doug Schmidt - ----------------------------------------- - -[ 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/INS.html b/TAO/docs/INS.html deleted file mode 100644 index 351524ef62b..00000000000 --- a/TAO/docs/INS.html +++ /dev/null @@ -1,154 +0,0 @@ - <!-- $Id$ --> -<HTML> - -<HEAD> -<TITLE>TAO Interoperable Naming Service</TITLE> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR><P> -<H3>TAO Interoperable Naming Service</H3> - -The CORBA <A HREF="http://www.omg.org/cgi-bin/doc?ptc/99-09-01"> -Interoperable Naming Service</A> (INS) service allows the ORB to be configured -administratively to return object references from -<CODE>CORBA::ORB::resolve_initial_references</CODE> for non-locality -constrained objects. The service also introduces the -<CODE>corbaloc</CODE> and <CODE>corbaname</CODE> IOR formats, which can -be used to bootstrap services not available at ORB installation time. -<P> - -This document presents an overview of how the above mentioned features are -implemented in TAO and addresses some common questions. <P> - -<HR align=left width=80% ><P> -<H4>How does <CODE>resolve_initial_references</CODE> work ?</H4><P> - -The following is the order of mechanisms checked by <CODE>resolve_initial_references</CODE> -for locating a service: <P> - -<OL> -<LI><A HREF="#oir">ORBInitRef</A> <br> -<LI><A HREF="#odir">ORBDefaultInitRef</A> <br> -<LI>ORB Default Settings <br> -<LI>Multicast to Service <p> -</OL> - -TAO uses the ACE_Hash_Map_Manager -to keep track of the ObjectID:IOR mappings specified on the -command-line. The IOR could be in <CODE>IOR</CODE>, <CODE>iiop</CODE>, -or <CODE><A href="#corbaloc">corbaloc</A></CODE> format. If the ORB fails to resolve the IOR -using the command-line parameters or the default settings, it uses UDP -multicast to resolve the service. <P> - -The Naming Service process acts as an IIOP Agent to respond with the -IOR for the given service name. If the service being resolved is the -Naming Service or the Trading Service, TAO checks the appropriate <A -HREF="Options.html#EV">environment variables</A> prior to using -multicast to obtain the appropriate port number or IOR.<p> - -The following diagram illustrates the order in which these various -components interact. <P> - -<img width=200 height=5 -src="http://www.cs.wustl.edu/~schmidt/gifs/space.gif"><img width=723 -height=529 -src="http://www.cs.wustl.edu/~schmidt/gifs/interop-naming.gif"><p> - -<HR align=left width=80% ><P> - -<H4>ORB Parameters Used for Configuration</H4> -<A NAME="oir"></A> -<DL> -<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> -<B><FONT COLOR="#000000">-ORBInitRef :</FONT> </B> -The ORB initial reference argument allows specification of an - arbitrary object reference for an initial service. The format is : - <p> - <CODE>-ORBInitRef [ObjectID]=[ObjectURL]</CODE> <p> - Examples of use are: <p> - <CODE>-ORBInitRef NameService=IOR:0002342344AB345</CODE> ...<br> - <CODE>-ORBInitRef MyServiceID=corbaloc:iiop:tango.cs.wustl.edu:8777/myService </CODE><p> - - This mechanism allows an ORB to be configured with new initial - service Object IDs that were not defined when the ORB was - installed. The ObjectURL can be any of the URL schemes supported - by <CODE>CORBA::ORB::string_to_object</CODE>.<p> - - <A NAME="odir"></A> -<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"><B><FONT COLOR="#000000"> --ORBDefaultInitRef :</FONT></B></LI> -The ORB default initial reference argument assists in resolution of - initial references not explicitly specified with - <CODE>-ORBInitRef</CODE>. <CODE>-ORBDefaultInitRef</CODE> requires a URL that, after - appending a slash '/' and a stringified object key, forms a new - URL to identify an initial object reference. <p> - For example: <P> - <CODE>-ORBDefaultInitRef - corbaloc:iiop:tango.cs.wustl.edu:8989,iiop:merengue.cs.wustl.edu:9999</CODE> <p> - - A call to <CODE>resolve_initial_references ("NameService")</CODE> with this - argument results in a new multiple profile URL equivalent to the following: <P> - <CODE>iiop://tango.cs.wustl.edu:8989/NameService</CODE> <br> - <CODE>iiop://merengue.cs.wustl.edu:9999/NameService</CODE> <p> - - The URL is passed to <CODE>CORBA::ORB::string_to_object</CODE> to obtain the - initial reference for the service. -</DL> - -<HR align=left width=80% ><P> - -<H4><A NAME="corbaloc">corbaloc: IOR format</A></H4> -The <CODE>CORBA::ORB::string_to_object</CODE> now understands the <CODE>corbaloc:</CODE> -format IORs (previously called iioploc). These are user-friendly multiple end-point IORs. For -example - <p> - <img width=50 height=5 -src="http://www.cs.wustl.edu/~schmidt/gifs/space.gif">corbaloc:iiop:tango.cs.wustl.edu:9999,iiop:merengue.cs.wustl.edu:9999/SimpleKey <p> - -Each of the end-points can use any transport protocols ex: iiop, rir. -The corbaloc:rir URL is defined to allow access to the ORB's -configured initial references through an URL. Each of the end-points -is converted into a Profile. These profiles are used to construct the -Multiple Profile Object. This object is then used to construct the -Object Reference.<p> - -The object references constructed using this format have a -'SimpleKey' in the Object Key field of the IOR. The server side ORB -intercepts the incoming request, recognizes the Simple Key and -looks up a table to get the complete IOR. It then raises a -LOCATION_FORWARD or an OBJECT_NOT_EXIST exception to forward/fail the -request depending on if a mapping for the given simple key exists. <p> - -All default TAO Object keys are preceded by a special sequence of -octets ^t^a^o/0. This is taken care of by the POA when it generates -the Object key for the IOR. The sequence is useful for the ORB to -distinguish a simple key from the usual TAO object key. <p> - -The corbaloc::iiop URL also supports the IPv6 decimal address for the -host field using the same format as for <A HREF="ORBEndpoint.html#IIOP">IIOP endpoint</A> definitions: -<P><CODE>corbaloc:iiop:1.2@[01ef::1]:123/KeyName</CODE> -<P> -TAO only supports IPv6 endpoints in GIOP/IIOP >= 1.2. -Since the CORBA spec requires (and such is implemented in TAO) that -by default when no version is specified the version will be 1.0 the -version has been explicitly set or not the result is that for -corbalocs the version needs to be explicitly set.<BR> -If not set the corbaloc parser will report an error for encountering -an unresolvable hostname. - -<HR align=left width=80% ><P> - -<!--<EM> -Visitor #1 since Thu Apr 15 22:33:36 1999 - -from merengue.cs.wustl.edu - -<EM><br> --> -<I> Last modified Tue Apr 20 14:47:21 CDT 1999 </I> - - -</BODY> -</HTML> diff --git a/TAO/docs/LocalObject.html b/TAO/docs/LocalObject.html deleted file mode 100644 index 8aaa9e72727..00000000000 --- a/TAO/docs/LocalObject.html +++ /dev/null @@ -1,104 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<!-- $Id$ --> -<html> <head> -<title>Implementing and Using Local Objects</title> -</head> - -<body text="#000000" bgcolor="#FFFFFF"> -<h1>Implementing Local Objects</h1> - -<p>The new addition of "<code>local</code>" interfaces in CCM define a -standard behavior of locality constraint object. There are some -subtle differences in implementing and using local interfaces compared -to regular (remote) interfaces. This page tries to collect -information on things to notice and common pitfalls.</p> - -<ul> - <li><p><b>Local or not Local?</b> - A local interface is local. - Any types defined withing the interface are also local. They - include "struct, union, enum, sequence, exceptions, typedef..." - For constructed types, if a constructed type contains local - elements, then it also becomes local even if the type is not - defined within a local interface.</p> - - <li><p>You can not put objects of local types into Any's or try to use - it regular CORBA invocations.</p> - - <li><p><b>Implementation class</b> - Instead of inheriting from - <code>POA_FOOBAR</code> class, the implementation of local - interface inherit from both the C++ object mapping class (the - client side class) and the <code>CORBA::LocalObject</code>. For - example, when <code>FOOBAR</code> is a regular interface, the - declaration of the implementation class is something like this: -<pre> - - class FOOBAR_i : public POA_FOOBAR - { - . . . - }; - -</pre> - However, if <code>FOOBAR</code> is defined as a local interface, - the implementation class is defined as: -<pre> - - class FOOBAR_i : public FOOBAR, - public CORBA::LocalObject - { - . . . - }; - -</pre></p> - - <li><p><b>Reference Counting and Object Reference Lifecycle</b> - - Regular CORBA object references use reference counting to manage - lifecycle of object references. Local object references - <b>may</b> also use reference counting for lifecycle - management.</p> - - <p>There are <code>_add_ref ()</code> and <code>_remove_ref - ()</code> operations defined in all local object and the ORB - uses these operations to increase/decrease the reference count - when <code>_duplicate ()</code> or <code>CORBA::release - ()</code> are invoked on an ojbect reference. <b>However, - notice that the default implementation of <code>_add_ref - ()</code> and <code>_remove_ref ()</code> for local objects are - no-ops.</b> Therefore, if you wish to do reference counting on - your local object instances, you must overwrite <code>_add_ref - ()</code> and <code>_remove_ref ()</code> in your implementation - for that local object.</p> - - <p>By leaving <code>_add_ref ()</code> and <code>_remove_ref - ()</code> as no-ops, you assume the responsibility of managing - the local object instance. Objects that have the same lifetime - as the ORB may want to use this strategy and let the ORB to - manage these instances of local objects. This prevents user - errors from crashing the server process. However, in this case, - the object needs to be <code>delete</code>'d explicitly (as - <code>CORBA::release ()</code> basically doesn't do anything in - this case.</p> - - <p>TAO developers can get reference counting by using the mixin class - <code>TAO_Local_Ref_Counted_Object ()</code> as: - - <pre> - class FOOBAR_i : public FOOBAR, - public TAO_Local_Ref_Counted_Object - { - . . . - }; - </pre> - - if you wish to use reference counting. However, - this is not portable and should be used with care by the applications.</p> - - -</ul> - - -<hr> -<address></address> -<!-- hhmts start --> -Last modified: Wed Apr 26 02:21:35 Central Daylight Time 2000 -<!-- hhmts end --> -</body> </html> diff --git a/TAO/docs/Makefile.am b/TAO/docs/Makefile.am deleted file mode 100644 index 0c191d44985..00000000000 --- a/TAO/docs/Makefile.am +++ /dev/null @@ -1,13 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -SUBDIRS = \ - tutorials - diff --git a/TAO/docs/ORBEndpoint.html b/TAO/docs/ORBEndpoint.html deleted file mode 100644 index 881f8e4804f..00000000000 --- a/TAO/docs/ORBEndpoint.html +++ /dev/null @@ -1,622 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> - -<!-- $Id$ --> - -<html> - <head> - <title>-ORBEndpoint Details</title> - <!-- Changed by: , 12-Jun-2002 --> - </head> - - <body text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> - <h1><A HREF="Options.html#-ORBEndpoint">-ORBEndpoint</A> Details</h1> - <P> - <UL> - <LI><A HREF="#Overview">Overview</A></LI> - <LI><A HREF="#Options">Endpoint-Specific Options</A></LI> - <LI><A HREF="#IIOP">IIOP Endpoints</A></LI> - <LI><A HREF="#SHMIOP">SHMIOP Endpoints</A></LI> - <LI><A HREF="#UIOP">UIOP Endpoints</A></LI> - <LI><A HREF="#DIOP">DIOP Endpoints</A></LI> - <LI><A HREF="#SSLIOP">SSLIOP Endpoints</A></LI> - </UL> - - <hr> - <P><h2><A NAME="Overview">Overview</A></h2> - Tells the ORB to listen for requests on the interface specified - by <I><EM>endpoint</EM></I>. Endpoints are specified using a - URL style format. An endpoint has the form: - <blockquote><CODE> - protocol://V.v@addr1,...,W.w@addrN - </CODE></blockquote> - where <CODE>V.v</CODE> and <CODE>W.w</CODE> are optional protcol - versions for each address. An example of an IIOP endpoint is: - <blockquote><CODE> - iiop://<I><EM>hostname</EM></I>:<I><EM>port</EM></I> - </CODE></blockquote> - Sets of endpoints may be specified using multiple - <CODE>-ORBEndpoint</CODE> options or by delimiting endpoints with - a semi-colon (;). For example: - <blockquote><CODE> - -ORBEndpoint iiop://localhost:9999 -ORBEndpoint uiop:///tmp/mylocalsock -ORBEndpoint shmiop://10002 - </CODE></blockquote> - is equivalent to: - <blockquote><CODE> - -ORBEndpoint 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002' - </CODE></blockquote> - Notice the single quotes (') in the latter option specification. - Single quotes are needed to prevent the shell from interpreting - text after the semi-colon as another command to run. - <P> - If an endpoint is specified without an <CODE>addr</CODE> such as - the following: - <blockquote><CODE> - -ORBEndpoint uiop:// -ORBEndpoint shmiop:// - </CODE></blockquote> - then a default endpoint will be created for the specified protocol. - <P> - This is a server side option. - - <hr> - <P> - <h2><A NAME="Options">Endpoint-Specific Options</A></h2> - <P> - The <CODE>-ORBEndpoint</CODE> options can accept - endpoint-specific options. Specifically, such options will only - apply to the endpoint for which they were specified. - <P> - An endpoint-specific option is used as follows: - <BLOCKQUOTE> - <CODE> - -ORBEndpoint iiop://foo:1234/option=value - </CODE> - </BLOCKQUOTE> - <P> - Additional options can be specified by separating each option - with an ampersand '<CODE>&</CODE>' as follows: - <BLOCKQUOTE> - <CODE> - -ORBEndpoint 'iiop://foo:1234/option1=value1&option2=value2' - </CODE> - </BLOCKQUOTE> - <P> - Notice that the address and the endpoint-specific options are - separated by a forward slash '<CODE>/</CODE>' in this case, - i.e. for IIOP endpoints. This character may differ for other - types of pluggable protocol endpoints. For example, UIOP - endpoint-specifc options are separated from the address by a - vertical bar '<CODE>|</CODE>'. Also note that when using more - than option, quotes should be used to prevent the shell from - interpreting the ampersand '<CODE>&</CODE>' as a command to - tell the shell to backgroup a job. - - <hr> - <P> - <h2><A NAME="IIOP">IIOP Endpoints</A></h2> - TAO's IIOP pluggable protocol utilizes TCP/IP as its underlying - transport mechanism. - <P> - <h3>IIOP Endpoint Overview</h3> - <P> - IIOP endpoints in TAO have the form: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://V.v@hostname1:port1,...,W.w@hostname2:port2 - </CODE> - </BLOCKQUOTE> - <P> - Where "<CODE>V.v</CODE>" and "<CODE>W.w</CODE>" are the IIOP - protocol versions associated with the given address - (hostname:port pair). Currently supported versions are - <CODE>1.0</CODE>, <CODE>1.1</CODE>, and <CODE>1.2</CODE>. - - <P> - Options are separated from the addresses by a forward slash - '<CODE>/</CODE>'. For instance, if an IIOP endpoint should have - a property foobar of 50 associated with it, then the following - endpoint specification could be used - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://hostname:port/foobar=50 - </CODE> - </BLOCKQUOTE> - <P> - <h3>IIOP Address Format</h3> - <P> - IIOP addresses are comprised of a hostname (or an IP address) - and a TCP port the server should listen on. The hostname is - used to select which network interface to set up the endpoint - on. It is <STRONG>not</STRONG> used to set the hostname that - goes into the generated IOR. This is especially useful if the - endpoint should be setup on a specific network interface other - than the default network interface. - <P> - Suppose a host has the following network interfaces: - <UL> - <LI>eth0: foo1.bar.baz <FONT COLOR=RED>(DEFAULT)</FONT></LI> - <LI>eth1: foo2.bar.baz</LI> - </UL> - <P> - To set up an endpoint on the second network interface "eth1," - the following endpoint specification could be used: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://foo2 - </CODE> - </BLOCKQUOTE> - or: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://foo2.bar.baz - </CODE> - </BLOCKQUOTE> - <P> - TAO will attempt to ensure that the fully qualified domain name is - embedded in the IOR. - <P> - In the above example, an available port will be chosen by TAO - (actually the operating system kernel), which will then be - placed into the IOR. - <P> - To set up an endpoint on a specific port, simply use an endpoint - of the form: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://foo2:1234 - </CODE> - </BLOCKQUOTE> - <P> - where <CODE>1234</CODE> is the TCP port the endpoint will be - opened on. In this case, an endpoint will be opened on the - network interface associated with the hostname <CODE>foo2</CODE> - on port <CODE>1234</CODE>. - <P> - Port <I>names</I> are also accepted. For example, suppose a - UNIX installation has a service called "my_protocol" associated - with port 1234 in the service database in - <CODE>/etc/services</CODE>, then the following would cause an - endpoint to be opened on the port associated with that service: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://foo2:my_protocol - </CODE> - </BLOCKQUOTE> - <P> - Port numbers range from <CODE>0</CODE> (causes port to be chosen - by operating system) to <CODE>65355</CODE>. Port numbers less - than <CODE>1024</CODE> on UNIX systems are considered - privileged, and require super-user privileges to access them. - Also be aware that some ports may already be in use by other - applications. - <P> - Suppose an endpoint should be created on each network - interface. To do so, simply omit the address from the endpoint - specification as follows: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop:// - </CODE> - </BLOCKQUOTE> - <P> - In this case, an endpoint will be set up on each network - interface detected by TAO. The port for each opened endpoint - will be chosen automatically. The chosen port will be the same - for all endpoints. Each endpoint will be represented in - generated IOR as a separate profile. - <P> - Note that network interface detection only work on platforms - that support this feature. If network interface detection isn't - supported, then the default network interface will be chosen. - <P> - Now suppose that an endpoint should be created on each detected - network interface, but with a specific port. This can be - achieved by using an endpoint specification of the form: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://:1234 - </CODE> - </BLOCKQUOTE> - <P> - This will create endpoints on each detected network interface, - each with the TCP port <CODE>1234</CODE>. Notice that there is - a colon '<CODE>:</CODE>' preceeding the port number - <CODE>1234</CODE>. That colon is necessary to make TAO - interpret <CODE>1234</CODE> as a port. Without the colon, TAO - would interpret <CODE>1234</CODE> as a hostname associated with - a given network interface. - - <P> - <P> - The hostname part of an endpoint can also be specified as a literal - IP address in 'dotted decimal address' form for IPv4 addresses: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://192.168.10.24:1234 - </CODE> - </BLOCKQUOTE> - - For IPv6 addresses a special form is required to specify decimal IP - addresses since the decimal separator for IPv6 addresses is identical - to the separator used for port numbers; i.e. a colon (':'). - To be able to distinguish an endpoint specification for host 01ef::1 - and port 123 and one for host 01ef::1:123 and no port number IPv6 - decimal addresses need to enclosed by square brackets ('[' and ']'): - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://[01ef::1]:123 - -ORBEndpoint iiop://[01ef::1:123] - </CODE> - </BLOCKQUOTE> - - <B>NOTE:</B> - Since IPv6 endpoint are supported only for GIOP/IIOP versions >= 1.2 - it is <FONT color='RED'>illegal</FONT> to combine version numbers - < 1.2 and IPv6 decimal addresses: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint iiop://1.1@[01ef::1]:123 <B><FONT color='RED'>--> ILLEGAL</FONT></B> - </CODE> - </BLOCKQUOTE> - <P> - <h3>IIOP Endpoint-Specific Options</h3> - <P> - TAO supports the following endpoint-specific options that apply only - to IIOP endpoints: - - <TABLE BORDER="2" CELLSPACING="2" CELLPADDING= "0"> - <TR> - <TH>Option</TH> - <TH>Availability</TH> - <TH>Description</TH> - </TR> - <TR> - <TD> - <CODE>portspan</CODE> - </TD> - <TD> - <CODE>TAO 1.1.15</CODE> - </TD> - <TD> - The <CODE>portspan</CODE> option specifies that an IIOP endpoint - should be opened on the first available port within a - specified span of port numbers, beginning with a specified - initial port. This option is useful when one or more servers - may be restricted to using ports within a given range. The - intention is that the behavior should be similar to using - ephemeral ports except within a restricted user-defined - range. - <P> - The format for <CODE>ORBEndpoint</CODE> with the - <CODE>portspan</CODE> option is: - <BLOCKQUOTE> - <CODE>-ORBEndpoint iiop://[</CODE><I>hostname</I><CODE>]:</CODE><I ->initialPort</I><CODE>/portspan=</CODE><I>span</I> - </BLOCKQUOTE> - where <I>initialPort</I> is the initial port number in the - range of allowable ports, and <I>span</I> is an integer - value indicating the size of the span of allowable ports. - Valid values for <I>initialPort</I> include any valid port - number. Valid values for <I>span</I> are in the - range <CODE>1</CODE> to <CODE>65535</CODE>. The - <I>hostname</I> (in <CODE>[ ]</CODE>)is optional. - <P> - The server's ORB will attempt to create a listening endpoint - beginning with the initial port. If that fails, it will try - the next port in the range. It will continue to try each - port in the range until it - is able to successfully open one for listening or until it has exhausted the range - <CODE>[initialPort:initialPort+span-1]</CODE> at which point it fails with a <CODE>CORBA::BAD_PARAM</CODE> system exception. - </TD> - </TR> - <TR> - <TD> - <CODE>hostname_in_ior</CODE> - </TD> - <TD> - <CODE>TAO 1.2.4</CODE> - </TD> - <TD> - The <CODE>hostname_in_ior</CODE> option allows one to - specify the hostname that is inserted into the generated - IOR. This option overrides the default (local) hostnames - that TAO normally inserts. This can be useful in - environments where the hostname in use is one whose IP - address changes dynamically. - <P> - The format for <CODE>ORBEndpoint</CODE> with the - <CODE>hostname_in_ior</CODE> option is: - <BLOCKQUOTE> - <CODE>-ORBEndpoint iiop://[</CODE><I>local_hostname</I><CODE>]:</CODE><I ->port</I><CODE>/hostname_in_ior=</CODE><I>overridden_hostname</I> - </BLOCKQUOTE> - where <I>local_hostname</I> and <I>port</I> are specified - as normal, and <I>overridden_hostname</I> is the hostname - that should be put into generated IORs. - </TD> - </TR> - </TABLE> - - <P> - <h3>IIOP Endpoint Examples</h3> - <P> - Here are some additional examples of IIOP endoints: - <UL> - <LI><CODE>-ORBEndpoint iiop://1.0@foo1:0</CODE> - <LI><CODE>-ORBEndpoint iiop://1.0@foo:0,1.1@bar,baz:3456</CODE> - <LI><CODE>-ORBEndpoint iiop://1.0@foo:0,1.1@bar,baz:3456/foobar=300</CODE></LI> - <LI><CODE>-ORBEndpoint iiop:///foobar=2</CODE> <FONT COLOR=RED>(notice three slashes "<CODE>///</CODE>")</FONT> - <LI><CODE>-ORBEndpoint iiop://:2020/foobar=12345</CODE> - <LI><CODE>-ORBEndpoint iiop://1.1@</CODE> - <LI><CODE>-ORBEndpoint iiop://1.1@:1234</CODE> - <LI><CODE>-ORBEndpoint iiop://1.1@,1.0@:1234,1.1@</CODE> - <LI><CODE>-ORBEndpoint iiop://1.1@foo:2020/portspan=30</CODE> - <LI><CODE>-ORBEndpoint iiop://foo:2020 -ORBEndpoint iiop://foo:10020 </CODE> </CODE> - </UL> - - <hr> - - <P> - <h2><A NAME="SHMIOP">SHMIOP Endpoints</A></h2> - TAO's SHMIOP pluggable protocol utilizes shared memory as its - underlying transport mechanism. - <P> - <h3>SHMIOP Endpoint Overview</h3> - <P> - SHMIOP endpoints in TAO have the similar form to IIOP endpoints: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint shmiop://V.v@port1,...,W.w@port2 - </CODE> - </BLOCKQUOTE> - <P> - Where "<CODE>V.v</CODE>" and "<CODE>W.w</CODE>" are the SHMIOP - protocol versions associated with the given address - (port). Currently supported versions are <CODE>1.0</CODE>, - <CODE>1.1</CODE>, and <CODE>1.2</CODE>. - - <h3>SHMIOP Address Format</h3> - <P> - SHMIOP addresses are comprised of a port number that the server - should listen on. - <P> - Port numbers range from <CODE>0</CODE> (causes port to be chosen - by operating system) to <CODE>65335</CODE>. Port numbers less - than <CODE>1024</CODE> on UNIX systems are considered - privileged, and require super-user privileges to access them. - Also be aware that some ports may already be in use by other - applications. - <P> - To have TAO automatically choose an address for a given SHMIOP - endpoint, simply omit the address from the endpoint - specification as follows: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint shmiop:// - </CODE> - </BLOCKQUOTE> - <P> - In this case, an SHMIOP endpoint will be set up on a port chosen - by TAO. - - <P> - <h3>SHMIOP Endpoint Examples</h3> - <P> - Here are some additional examples of SHMIOP endoints: - <UL> - <LI><CODE>-ORBEndpoint shmiop://1.0@0</CODE> - <LI><CODE>-ORBEndpoint shmiop://1.0@0,3456</CODE> - <LI><CODE>-ORBEndpoint shmiop://1.0@0,3456/foobar=300</CODE></LI> - <LI><CODE>-ORBEndpoint shmiop:///foobar=2</CODE> <FONT COLOR=RED>(notice three slashes "<CODE>///</CODE>")</FONT> - <LI><CODE>-ORBEndpoint shmiop://2020/foobar=12345</CODE> - <LI><CODE>-ORBEndpoint shmiop://1.1@</CODE> - <LI><CODE>-ORBEndpoint shmiop://1.1@1234</CODE> - <LI><CODE>-ORBEndpoint shmiop://1.1@,1.0@1234,1.1@</CODE> - </UL><p> - - You <font color="red">must specify the hostname</font>, however, - when using SHMIOP with <a href="INS.html">Interoperable Naming - Service</a> as you would with IIOP. This is because SHMIOP uses - the hostname to determine the validity of an endpoint. That is, - it will not try to connect to a remote SHMIOP endpoint locally. - For examples:<p> - <BLOCKQUOTE> - <P> - <CODE> - -ORBInitRef MyService=corbaloc:shmiop:1.1@hostname:port/service_name - </CODE> - </BLOCKQUOTE> - - <hr> - - <P> - <h2><A NAME="UIOP">UIOP Endpoints</A></h2> - TAO's UIOP pluggable protocol utilizes local IPC (aka UNIX domain - sockets) as its underlying transport mechanism. - <P> - <h3>UIOP Endpoint Overview</h3> - <P> - UIOP endpoints in TAO have the form: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint uiop://V.v@rendezvous_point1,...,W.w@rendezvous_point2 - </CODE> - </BLOCKQUOTE> - <P> - Where "<CODE>V.v</CODE>" and "<CODE>W.w</CODE>" are the UIOP - protocol versions associated with the given rendezvous point. - Currently supported versions are <CODE>1.0</CODE> and - <CODE>1.1</CODE>. - - <P> - Options are separated from the addresses by a vertical bar - '<CODE>|</CODE>'. For instance, if an IIOP endpoint should have - a property foobar of 50 associated with it, then the following - endpoint specification could be used - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint 'uiop://1.0@/tmp/my_rendezvous_point|foobar=50' - </CODE> - </BLOCKQUOTE> - <P> - Notice that the endpoint is quoted to prevent the shell from - interpreting the vertical bar '<CODE>|</CODE>' as the shell - "pipe" character. - <P> - <h3>UIOP Address Format</h3> - <P> - UIOP addresses are comprised of a rendezvous point the server - should listen on. The rendezvous point is generally the - <I>full</I> path to the desired UNIX domain socket filename. - Relative paths can be used, their use is discourages. The - maximum length of the rendezvous point is 108 characters, as - dictated by the POSIX.1g specification for local IPC rendezvous - points. TAO will truncate any rendezvous point name longer than - 108 characters. - <P> - An UIOP endpoint with a rendezvous point with an <I>absolute</I> - path could be: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint uiop:///tmp/foobar - </CODE> - </BLOCKQUOTE> - In this example, the optional protocol version and - endpoint-specific options have been omitted. The rendezvous point - <CODE>/tmp/foobar</CODE> will be created, in this case. - <P> - An UIOP endpoint with a rendezvous point with a <I>relative</I> - path could be: - <BLOCKQUOTE> - <P> - <CODE>-ORBEndpoint uiop://foobar</CODE> <FONT COLOR=RED>(DISCOURAGED)</FONT> - </BLOCKQUOTE> - <P> - Again, rendezvous points with relative paths are discouraged - since it is possible that other rendezvous points with the same - basename exist on a given system, giving rise to potential - ambiguities. - <P> - To make TAO choose a rendezvous point automatically, simply omit - the rendezvous point from the endpoint specification as follows: - <BLOCKQUOTE> - <P> - <CODE> - -ORBEndpoint uiop:// - </CODE> - </BLOCKQUOTE> - <P> - This will cause an endpoint to be setup in system temporary - directory. Rendezvous points chosen by TAO are prepended with - "<CODE>TAO</CODE>." TAO will always choose rendezvous points - with absolute paths. - - <P> - <h3>UIOP Endpoint Examples</h3> - <P> - Here are some additional examples of UIOP endoints: - <UL> - <LI><CODE>-ORBEndpoint uiop://1.0@/tmp/foo1</CODE> - <LI><CODE>-ORBEndpoint uiop://1.0@/tmp/foo,1.1@/home/bar/baz</CODE> - <LI><CODE>-ORBEndpoint 'uiop://1.1@/tmp/bar|foobar=300'</CODE></LI> - <LI><CODE>-ORBEndpoint 'uiop://|foobar=2'</CODE> - <LI><CODE>-ORBEndpoint uiop://1.1@</CODE> - <LI><CODE>-ORBEndpoint uiop://1.1@,1.0@/tmp/foo,1.1@</CODE> - </UL> - <hr> - - - <P> - <h2><A NAME="DIOP">DIOP Endpoints</A></h2> - TAO's DIOP pluggable protocol utilizes UDP sockets instead TCP - sockets (IIOP) as its underlying transport mechanism. This - protocol supports unreliable datagram communication, which has - certain <A - HREF="../examples/PluggableUDP/DIOP/README">limitations</A>. - <P> - <h3>DIOP Endpoint Overview</h3> - <P> - Since DIOP endpoints in TAO have the same form as - <A HREF="#IIOP">IIOP</A> endpoints, a detailed description is - therefore omitted. DIOP has no support for endpoint-specific - options. - <P> - We recommend explicitly setting port numbers for endpoints - since TAO does not support automatic selection of free endpoints for - UDP sockets. Instead, the ORB will try to use the same default port - number in every case. - - <h3>DIOP Endpoint Examples</h3> - <P> - Here are some additional examples of DIOP endoints: - <UL> - <LI><CODE>-ORBEndpoint diop://1.0@foo1:2345</CODE> - <LI><CODE>-ORBEndpoint diop://1.1@:1234</CODE> - </UL> - - <P> - <h2><A NAME="SSLIOP">SSLIOP Endpoints</A></h2> - TAO's SSLIOP pluggable protocol facilitates CORBA request - invocation over TLS (formerly known as SSL), and is a drop-in - replacement for the <A HREF="#IIOP">IIOP</A> pluggable protocol. - <P> - The SSLIOP pluggable protocol will actually create two - endpoints: one which is meant to accept plain IIOP requests, and - another meant to accept SSLIOP requests. As security measure, - IIOP requests will be rejected by default unless the server is - configured to accept them (See the - <A HREF="Security/SSLIOP-USAGE.html">SSLIOP documentation</A> for - additional details). - <P> - <h3>SSLIOP Endpoint Format</h3> - <P> - SSLIOP endpoints basically have the same format as - <A HREF="#IIOP">IIOP</A> endpoints. The only difference between - the two is that SSLIOP endpoints accept an additional option - that allows one to select the port which will accept TLS - requests. To make a server open a SSLIOP endpoint on a specific - port use the <CODE>ssl_port</CODE> endpoint option: - - <UL> - <LI><CODE>-ORBEndpoint iiop://foo:1234/ssl_port=1235</CODE> - </UL> - - In this case, an <A HREF="#IIOP">IIOP</A> endpoint would be opened - on port <CODE>1234</CODE> and a SSLIOP endpoint on port - <CODE>1235</CODE>. If no <CODE>ssl_port</CODE> option is - supplied, a port will automatically be chosen in the same way a - port is automatically chosen for an <A HREF="#IIOP">IIOP</A> - endpoint. - - <P> - Note that the protocol label in the above example is - <CODE>iiop</CODE>, <EM>not</EM> <code>ssliop</code>. - Regardless, a SSLIOP endpoint will be opened if the SSLIOP - pluggable protocol was loaded. Furthermore, the - <CODE>ssl_port</CODE> endpoint option is only valid if the - SSLIOP pluggable protocol is used. - - <hr> - - <address><a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a></address> -<!-- Created: Thu May 18 08:37:25 PDT 2000 --> -<!-- hhmts start --> -Last modified: Fri Jun 11 16:51:59 PDT 2004 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/ORB_Internals.html b/TAO/docs/ORB_Internals.html deleted file mode 100644 index 05ffb00c2a4..00000000000 --- a/TAO/docs/ORB_Internals.html +++ /dev/null @@ -1,87 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <!-- $Id$ --> - <title>TAO ORB Internals</title> - </head> - - <body> - <h1>TAO ORB Internals</h1> - - <P>This document will describe how the ORB internals work, with - special attention to the areas that are more poorly documented. - For example: we will not document (at least initially) the - pluggable protocols framework, the interpretive marshaling - engine, the POA, the waiting strategies and the - leader-follower. - </P> - <P>New ORB developers are expected to read this document and - document here all the things that they find hard to understand, - surprizing or event broken. - New members of the ORB core team are expected to fill in details - that were not explained before. - </P> - - <H3>Client Side event sequence</H3> - - <P>In this section we will document the sequence of calls and - interactions on the client side. - Only the synchronous case, without forwarding or exceptions is - documented at this point. - </P> - - <P>Assume the application invokes a method on an object reference, - in the generated stub for that method the following sequence is - started: - <UL> - <LI>creates TAO_GIOP_Twoway_Invocation object - </LI> - <LI>calls start method on the invocation object - </LI> - - <LI>TAO_GIOP_Twoway_Invocation::start: - <UL> - <LI>finds the profile to use for this invocation - </LI> - <LI>passes the profile to Connector Registry to obtain - TAO_Transport object (wrapper around Service_Handler) - </LI> - <LI>generates and marshalls GIOP & Request headers for this - invocation - </LI> - </UL> - </LI> - - <LI>marshalls request parameters - </LI> - <LI>calls invoke method on the invocation object - </LI> - - <LI>TAO_GIOP_Twoway_Invocation::invoke: - <UL> - <LI>sets TAO_Reply_Dispatcher (this is used to make both - synch and asynch requests look the same) - </LI> - <LI>sends the request - </LI> - <LI>waits on the TAO_Wait_Strategy - </LI> - </UL> - </LI> - - <LI>if there was a minor problem or location forward, tries - again: call TAO_GIO_Twoway_Invocation::start, etc. - </LI> - <LI>if everything went ok, demarshalls reply - </LI> - </UL> - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Fri Sep 10 16:34:44 CDT 1999 --> -<!-- hhmts start --> -Last modified: Fri Sep 10 18:00:18 CDT 1999 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/Options.html b/TAO/docs/Options.html deleted file mode 100644 index ddd4e15a57c..00000000000 --- a/TAO/docs/Options.html +++ /dev/null @@ -1,1519 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> -<!-- $Id$ --> - <title>Options for TAO Components</title> -</head> -<body bgcolor="#ffffff" link="#000fff" vlink="#ff0f0f" text="#000000"> -<hr> -<p></p> -<h2 align="center">Options for TAO Components</h2> -<h3>Table of Contents</h3> -<ul> - <li><a href="#MOT">Introduction</a> </li> - <li><a href="#choose">Choosing the Right Approach</a> </li> - <li><a href="#EXP">TAO's ORB Configuration Options</a> - <ul> - <li><a href="#EV">Environment Variables</a> </li> - <li><a href="#CLO">Command-line Options</a> - <ol> - <li><a href="#CSCB">Controlling Service Configurator Behavior </a> - </li> - <li><a href="#CDI">Controlling Debugging Information </a> </li> - <li><a href="#ORP">Optimizing Request Processing </a> </li> - <li><a href="#CMPS">Connection Management and Protocol -Selection </a> </li> - <li><a href="#MO">Miscellaneous Options </a></li> - </ol> - </li> - <li><a href="#SVC">Service Configuration File </a> - <ol> - <li><a href="#TRF">Simple and Advanced Resource Factories </a> - <ol> - <li><a href="#TDRF">TAO_Default_Resource_Factory </a> </li> - <li><a href="#TARF">TAO_Advanced_Resource_Factory </a></li> - </ol> - </li> - <li><a href="#TSSF">Server_Strategy_Factory </a> </li> - <li><a href="#TCSF">Client_Strategy_Factory </a></li> - </ol> - </li> - </ul> - </li> -</ul> -<hr> -<h3><b><a name="MOT">Introduction</a></b></h3> -TAO is a highly flexible ORB that contains a wide range of ORB -configuration options. One or more of these options can be combined -to meet various application requirements, such as low-latency, -predictable real-time behavior, or small memory footprint. TAO's ORB -configuration options are managed by an object-oriented framework -within the ORB Core that contains the following types of entities: -<ul> - <li><b>Settings</b>, which are options that can be assigned values -differing from their default settings. Examples include setting the -size of a Portable Object Adapter (POA)'s active object map or -configuring the ORB to print debugging information as it processes -requests. A few of these are run-time options, while a majority of -them are compile-time options. - <p></p> - </li> - <li><b>Resources</b>, which are objects used internally by TAO, such -as a <em>reactor</em> framework that demultiplexes new connection and -data requests from a client or <em>synchronization mechanisms</em> -used to regulate access to certain parts of the ORB. - <p></p> - </li> - <li><b>Strategies</b>, which are objects that use the <b>Resource</b> -entities to perform various ORB tasks, such as connection management, -concurrency, and demultiplexing. - <p></p> - </li> - <li><b>Factories</b>, which TAO uses to create and consolidate its -many resources and strategies into a manageable number of factories -that can be (re)configured into the ORB conveniently and consistently -by ORB and application developers. - <p></p> - </li> -</ul> -The set of TAO ORB configuration options that are represented by the -settings, resources, strategies, and factories can be specified via -<b>environment variables</b>, <b>service configuration files</b>, and -<b>command-line arguments</b>, as outlined below: -<ul> - <li> <b>Environment variables</b> are limited to specifying the -interoperable object reference (IOR) and port number of TAO's Naming -Service, Trading Service and Implementation Repository. They are -limited in flexibility and don't provide the most important -configuration hooks necessary to configure TAO for real-time and -high-performance applications. - <p></p> - </li> - <li> <b>Command-line options</b> are passed to the ORB -initialization -factory method, <code>CORBA::ORB_init()</code>, by an application -using the standard <i>argc/argv</i> tuple passed to the application's - <code>main()</code>. Most of the options that can be exercised -through -environment variables can also be manipulated through command-line -options. Command-line options override the environment variable -settings if both are enabled. - <p></p> - </li> - <li> The <b>Service Configurator</b> is a framework that can be used -to statically and dynamically configure components into middleware and -applications. The information comprising the names of these -components and their corresponding options are specified in a service -configurator file, whose default file name is - <code>svc.conf</code>. The service configurator is opened and -processed by the ORB in <code>CORBA::ORB_init()</code>. The service -configurator processing is done after all the command-line options -have been parsed. - </li> -</ul> -<p></p> -<hr width="25%" align="left"> -<p></p> -<h3><a name="choose">Choosing the Right Approach</a></h3> -TAO's command-line options are useful when there's a fixed set of -configuration options, each of which has a predefined list of -alternative values. Conversely, TAO's service configurator file is -useful for configuring a broader range of resources, strategies, and -factories. Generally speaking, the service configurator file allows -the user to <br> -<ul> - <li>configure the existing components (<em>i.e.</em>, resources, -strategies and factories) based on the predefined list of alternatives -that TAO provides or - <p> </p> - </li> - <li>extend the existing factories by providing user-defined -components and dynamically load them through the service configurator -mechanism. </li> -</ul> -Additionally, the service configurator mechanism allows an -application to control the behavior of the ORB using extensible -configuration information. In general, the command-line configuration -options are provided in TAO -in order to leverage preexisting configuration settings that are -compiled within the TAO ORB. Users are not allowed to change these -settings. In contrast, those options that require more flexible -manipulation of resources, strategies, and factories must be -configured via <a href="#SVC">service configuration files</a>. As a -result, the command-line options and the service configurator options -cannot be used interchangeably. -<p></p> -<hr> -<h3><b><a name="EXP">TAO's ORB Configuration Options</a></b></h3> -This section provides a detailed overview of how to configure TAO's -options using environment variables, command-line options, and service -configuration files. -<p></p> -<hr width="25%" align="left"> -<h3><a name="EV">Environment Variables</a></h3> -As mentioned earlier, environment variables have a limited use in TAO -ORB configuration. The currently supported environment variables are -listed below. They are used to specify the IOR and port numbers for -three of TAO's ORB services. -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Environment Variable</th> - <th>Description</th> - </tr> - <tr> - <td><code>NameServicePort</code> <em>which</em></td> - <td>Specifies which port the Naming Service is listening on for -multicast requests. </td> - </tr> - <tr> - <td><code>TradingServicePort</code> <em>which</em></td> - <td>Specifies which port the Trading Service is listening on -for multicast requests. </td> - </tr> - <tr> - <td><code>ImplRepoServicePort</code> <em>which</em></td> - <td>Specifies which port the Implementation Repository is -listening on for multicast requests. </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -In addition to being able to define the port where these known services -are listening for multicast requests, as above, it is possible to set -an environment variable that specifies the IOR of any named service. -For example <code>NameServiceIOR=<which>,TradingServiceIOR=<which>, -ImplRepoServiceIOR=<which>, MyServiceIOR=<which></code>. This -will have a similar effect to defining an -ORBInitRef value on the -command line (see below). Any value set as a command line -ORBInitRef -option will override any value set as an environment variable for the -same service name.<br> -<br> -In general, setting environment variables is not particularly portable -or convenient, which is why users can also set these options via -command-line options. The example shown below demonstrates a -deployment scenario where the client and Naming Service run on the -same host: -<p><code> -% NameService.exe -ORBEndpoint iiop://localhost:12345 -</code></p> -<p><code> -% client.exe -ORBInitRef NameService=corbaloc:iiop:localhost:12345/NameService -</code></p> -<p>An explanation of these command-line options appears below. </p> -<p></p> -<hr width="25%" align="left"> -<h3><a name="CLO">Command-line Options</a></h3> -TAO's run-time behavior can also be controlled by passing options via -the CORBA initialization method <code>CORBA::ORB_init()</code>. ORB -initialization options are commonly passed into the program from the -command-line, using the <code>argc</code> and <code>argv</code> -parameters available to the <code>main()</code> function. -<p>Command-line options can be classified into the following groups -according to their purposes:</p> -<ol> - <li><a href="#CSCB">Controlling Service Configurator Behavior</a> </li> - <li><a href="#CDI">Controlling Debugging Information</a> </li> - <li><a href="#ORP">Optimizing Request Processing</a> </li> - <li><a href="#CMPS">Connection Management and Protocol Selection</a> </li> - <li><a href="#MO">Miscellaneous Options</a> - </li> -</ol> -We describe each of these five groups of options below. -<p></p> -<h4><a name="CSCB">1. Controlling Service Configurator Behavior</a></h4> -The options described below influence the behavior of the ORB's <a - href="#SVC">service configurator, which is opened and processed <em>after</em> -the command-line options -have been parsed. </a> -<p></p> -<blockquote><a href="#SVC"> </a> - <p><a href="#SVC"> </a> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBSvcConf</code> <em>config filename</em></td> - <td>Specifies the name of the file used to read service -configuration directives via the Service Configurator framework. By -default, a service configurator-based application will look for a file -named <code>"svc.conf"</code> in the current directory. </td> - </tr> - <tr> - <td><code>-ORBSvcConfDirective</code> <em>directivestring</em></td> - <td>Specifies a service configuration directive, which is -passed to the Service Configurator. You can pass multiple of these -options on the same command-line. </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="CDI">2. Controlling Debugging Information</a></h4> -During application development and testing, it is often necessary to -control the amount and type of debugging information output by the -ORB. The following options enable TAO to provide debugging -information at several levels of granularity. -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBDebug</code></td> - <td>Instructs the ORB to print debugging messages from the -service configurator framework. This option does not have a value but -is used as a toggle to enable or disable debugging messages.</td> - </tr> - <tr> - <td><code>-ORBDebugLevel </code><em>level</em></td> - <td>Control the level of debugging in the ORB. Higher numbers -generate more output (try 10). The default value of this option is 0.</td> - </tr> - <tr> - <td><code>-ORBVerboseLogging <em>level (0|1|2)</em</code></td> - <td>Controls the amount of status data printed on each line of - the debug log. Higher numbers generate more output. - The default value of this option is 0. </td> - </tr> - <tr> - <td><code>-ORBLogFile</code> <em>Logfilename</em></td> - <td>Causes all <code>ACE_DEBUG</code> and <code>ACE_ERROR</code> -output to be redirected to the designated <code>Logfilename</code>. </td> - </tr> - <tr> - <td><code>-ORBObjRefStyle</code> <em>IOR/URL</em></td> - <td>Specifies the user-visible style of object references. The <code>IOR</code> -style (default) is the conventional CORBA object reference, whereas the - <code>URL</code> style looks more like a URL. - </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="ORP">3. Optimizing Request Processing</a></h4> -It is often possible to <a href="performance.html">increase TAO's -throughput and reduce latency</a> by optimizing certain stages of -request processing in the ORB. The following command-line options -control various optimizations during request processing. -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBCDRTradeoff</code> <em>maxsize</em></td> - <td><a name="-ORBCDRTradeoff"></a>Control the strategy to -tradeoff between copy vs. no copy marshaling of octet sequences. If an -octet sequence is smaller than <code>maxsize</code> (which defaults to - <code>ACE_DEFAULT_CDR_MEMORY_TRADEOFF</code>) -- and the -current message block contains enough space for it -- the octet -sequence is copied instead of appended to the CDR stream. </td> - </tr> - <tr> - <td><code>-ORBMaxMessageSize</code> <em>maxsize</em></td> - <td><a name="-ORBMaxMessageSize"></a>Set maximum size of - outgoing GIOP request/reply. The request or reply - being sent will be fragmented, if necessary.</td> - </tr> - <tr> - <td><code>-ORBCollocation</code> <em>global/per-orb/no</em></td> - <td><a name="-ORBCollocation"></a>Specifies the use of -collocation object optimization. If <code>global</code> is specified -(default), objects in the same process will be treated as collocated. -If <code>per-orb</code> is specified, only objects in the same ORB are -treated as collocated. When <em>no</em> is specified, no objects are -treated as collocated. </td> - </tr> - <tr> - <td><code>-ORBCollocationStrategy</code> <em>thru_poa/direct</em> - </td> - <td>Specifies what type of collocated object to use. If the <code>thru_poa</code> -(default) strategy is used, TAO uses the collocation object -implementation that respects POA's current state and policies. When -using the <code>direct</code> strategy, method invocations on -collocated objects become direct calls to servant without checking -POA's status, which can increase performance. If you use the <code>direct</code> -strategy, your interfaces must be compiled with the <code><a - href="compiler.html#collocation-stubs">-Gd</a></code> IDL <a - href="compiler.html">compiler option</a>. </td> - </tr> - <tr> - <td><code>-ORBNodelay</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBNodelay"></a>Enable or disable the <code>TCP_NODELAY</code> -option (Nagle's algorithm). By default, <code>TCP_NODELAY</code> is -enabled.</td> - </tr> - <tr> - <td><code>-ORBRcvSock</code> <em>receive buffer size</em></td> - <td><a name="-ORBRcvSock"></a>Specify the size of the socket -receive buffer as a positive, non-zero integer. If not specified, the <code>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</code> -default is used.</td> - </tr> - <tr> - <td><code>-ORBSndSock</code> <em>send buffer size</em></td> - <td><a name="-ORBSndSock"></a>Specify the size of the socket -send buffer as a positive, non-zero integer. If not specified, the <code>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</code> -default is used.</td> - </tr> - <tr> - <td><code>-ORBStdProfileComponents</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBStdProfileComponents"></a>If <em>0</em> then -the ORB does not generate the OMG standardized profile components, such -as the ORB type and code sets. Notice that the presence of this -components is optional in GIOP 1.1 The default value is controlled by a -compile-time flag defined in <CODE>orbconf.h</CODE>.</td> - </tr> - <tr> - <td><code>-ORBNegotiateCodesets</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBNegotiateCodesets"></a>If <em>0</em> then the ORB -does not include the codeset negotiation subsystem, TAO_Codeset. This yields -a somewhat smaller runtime footprint as well as a smaller IOR. However this -also removes the ability to interoperate with ORBs on systems using -alternative character or wide charater encodings. The default value may be set -at compile time by defining <CODE>TAO_NEGOTIATE_CODESETS 0</CODE> in -<CODE>orbconf.h</CODE>. Codeset negotiation support is enabled by default in -TAO as shipped.<br> <bold>Note to static lib users</bold> In order to build -TAO statically and get the codeset negotiation feature, two additional steps -are needed to ensure the TAO_Codeset library is linked in and initalized. Add the MPC feature "negotiate_codesets=1" to the default.features file and regenerate your makefiles, and add <CODE>#include "tao/Codeset/Codeset.h"</CODE> somewhere in your application source, such as the cpp file containing your main.</td> - </tr> - <tr> - <td><code>-ORBSingleReadOptimization</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBSingleReadOptimization"></a>This option -controls whether TAO's ``single read optimization'' is used when -receiving requests. If this option is disabled (<code>0</code>), the -ORB will do two reads to read a request: one reads the request header -and the other reads the request payload. If this option is enabled (<code>1</code>), -the ORB will do a read of size <code>TAO_MAXBUFSIZE</code>, hoping to -read the entire request. If more than one request is read they will be -queued up for processing later. - <p> This option defaults to <code>1</code> because it can -provide better performance. In the case of Real-time CORBA, however, this -option should be set to <code>0</code>. Consider the following -scenario: (1) two requests are read from one socket, (2) the additional -request is queued, and (3) the ORB uses its Reactor's notification -mechanism to wake up the follower threads. If at the same time, -however, new requests arrive on others sockets of higher priority the -lower priority queued message will be processed before the newly -arrived higher priority request since Reactor notifications are given -preferences over normal I/O, thereby causing priority inversion.</p> - </td> - </tr> - <tr> - <td><code>-ORBDisableRTCollocation</code> <em>boolean (0|1)</em></td> <td><a name="-ORBDisableRTCollocation"></a>This - option controls whether the application wants to use or discard - RT collocation decisions made by the RT ORB. A value of - <CODE>1</CODE> (true) disables RT collocation decisions and falls back on the default - collocation decisions implemented in the default ORB, which is - useful for applications using the RT ORB and doesn't want - to use the RT collocation decisions but fallback on the default - decisions for better performance. The default value is - <code>0</code> (false). </td> - </tr> - <tr> - <td><code>-ORBUseLocalMemoryPool</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBUseLocalMemoryPool"></a>TAO can use a local memory pool - to satisfy some of its needs for heap storage, as it is often more - efficient than using the platform's default memory allocator. The local - pool will always grow as large as necessary to satisfy memory allocations, - but it will never shrink. This means that sometimes a process can retain - memory that it no longer needs. If the default allocator is used then - TAO gives memory back as soon as it is not needed which allows for better - resource sharing at the expense of memory deallocation time. - <p>If this option is disabled (<code>0</code>), the ORB will use the - default allocator for the platform.</p> - <p>If this option is enabled (<code>1</code>), the orb will use the - local memory pool.</p> - <p> This option defaults to the compile-time option specified by - <code>TAO_USES_LOCAL_MEMORY_POOL</code>.</p> - </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="CMPS">4. Connection Management and Protocol Selection</a></h4> -TAO can send and receive requests and replies using various <a - href="pluggable_protocols">transport protocols</a>. Each protocol has -its own concept of an <a href="ORBEndpoint.html">endpoint</a>. -The following options manage connections and control protocol -selection within a TAO application. -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBDefaultInitRef</code> <em>IOR prefix</em></td> - <td><a name="-ORBDefaultInitRef"></a>This argument allows -resolution of initial references not explicitly specified with -<CODE>-ORBInitRef</CODE>. It requires a URL prefix that, after appending a slash '/' -('|' for the UIOP pluggable protocol) and a simple object key, forms a -new URL to identify an initial object reference. The URL prefix format -currently supported is based on the standard <code><A href="INS.html#corbaloc">corbaloc</A></code> -mechanism in the CORBA <a href="INS.html">Interoperable Naming -Service. </a></td> - </tr> - <tr> - <td><code>-ORBDottedDecimalAddresses</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBDottedDecimalAddresses"></a>Use the dotted -decimal notation for addresses. This option can be used to workaround -broken DNS implementations and may also reduce the time spent resolving -IP addresses. This option is enabled (<code>1</code>) by default on -Windows since DNS is often misconfigured there. On other platforms -this option is disabled (<code>0</code>) since domain names are -more flexible address notations for IORs.</td> - </tr> - <tr> - <td><code>-ORBNoServerSideNameLookups</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBNoServerSideNameLookups"></a>Setting this to 1 will -prevent the ORB from looking up the peer's hostname when accepting an incoming -connection from a client when the above value (<code>ORBDottedDecimalAddresses</code>) -is <code>0</code>. This option is disabled (<code>0</code>) by default.</td> - </tr> - <tr> - <td><code>-ORBEndpoint</code> <em>endpoint</em></td> - <td><a name="-ORBEndpoint"></a>This option is same as the <a - href="#-ORBListenEndpoints"><code>-ORBListenEndPoints</code></a> - option described below. <font color="red">This option will be - deprecated in later versions on TAO since the CORBA - specification now defines the <code>-ORBListenEndpoints</code> - option instead. </font> </td> - </tr> - <tr> - <td><code>-ORBPreferredInterfaces</code> - <em>"targetNetwork:localNetwork,.."</em></td> - <td><a name="-ORBPreferredInterfaces"></a> This option allows - clients running on a multihomed host to pick a local - network/interface to communicate with a remote target. - When TAO attempts to establish a connection with a host - matching targetNetwork, then it will use the local ip address - matching localNetwork. Simple wildcards can be used for both - parameters, and multiple preferred interfaces can be specified - using comma separators. For example, for a machine with two network cards - identified by the ip addresses 192.168.1.10 and 192.168.1.20, you can - use -ORBPreferredInterfaces *=*10,*=*20. - Or to force all communication on the loopback address to try to first - use the loopback address, use -ORBPreferredInterfaces 127.0.0.1=127* . - <em>targetNetwork</em> can use any string, and must typically match - with the value read from an IOR. - <em>localNetwork</em> must use a dotted decimal address, because it - will be matched with the local ip interfaces. - </tr> - <tr> - <td><code>-ORBEnforcePreferredInterfaces</code> - <em>boolean (0|1)</em></td> - <td><a name="-ORBEnforcePreferredInterfaces"></a> If this - option is set to <CODE>1</CODE> (true), then TAO will only try to use the - interfaces specified by the <CODE>-ORBPreferredInterfaces</CODE> option. - The default is <CODE>0</CODE> (false), in which case if a connection - cannot be made using a preferred interface, TAO will - attempt to use the default interface (<CODE>INADDR_ANY</CODE>). - Note: If none of the preferred interfaces apply to an outgoing connection - then they will not be enforced. For this option to have - any effect, therefore, the connection through a legal preferred interface must fail. - </tr> - <tr> - <td><code>-ORBKeepalive</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBKeepalive"></a>This option allows users to specify - that the SO_KEEPALIVE option is set on TCP sockets used by IIOP. - The default is <code>0</code> (false). - </td> - </tr> - <tr> - <td><code>-ORBDontRoute</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBDontRoute"></a>This option allows users to specify - that the SO_DONTROUTE option is set on TCP sockets used by IIOP. - The default is <code>0</code> (false). - </td> - </tr> - <tr> - <td><code>-ORBLingerTimeout</code> <em>timeout</em></td> - <td><a name="-ORBLingerTimeout"></a> This option allows users to - set the linger timeout on a TCP socket before closing it. Hence, - this option is only useful when using IIOP. The - <code>timeout</code> value can be in the range of zero to the - maximum signed integer value for the particular platform on which - TAO is running. - </td> - </tr> - <tr> - <td><code>-ORBListenEndpoints</code> <em>endpoint</em></td> - <td><a name="-ORBListenEndpoints"></a> This option was - introduced with the CORBA <a - href="http://www.omg.org/docs/orbos/01-01-04.pdf">Object - Reference Template</A> (ORT) specification. It instructs a - server ORB to listen for requests on the interface specified - by <code>endpoint</code>. When used with Real-time CORBA, the option - specifies the endpoints that the default thread pool listens - to. TAO endpoints are specified using a URL style format. An - endpoint has the form: - <blockquote><code>protocol://V.v@addr1,...,W.w@addrN - </code></blockquote> where <code>V.v</code> and - <code>W.w</code> are optional protocol versions for each - address. An example of an IIOP endpoint is: - <blockquote><code>iiop://<i><em>hostname</em></i>:<i><em>port</em></i> - </code></blockquote> - - Sets of endpoints may be specified using multiple - <code>-ORBListenEndpoints</code> options or by delimiting - endpoints with a semi-colon (;). For example, - <blockquote><code>-ORBListenEndpoints iiop://localhost:9999 - -ORBListenEndpoints uiop:///tmp/mylocalsock - -ORBListenEndpoints shmiop://10002 </code></blockquote> is - equivalent to: <blockquote><code>-ORBListenEndpoints - 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002' - </code></blockquote> Notice the single quotes (') in the - latter option specification. Single quotes are needed to - prevent the shell from interpreting text after the semi-colon - as another command to run. <p>If an endpoint is specified - without an <code>addr</code> such as the following: </p> - <blockquote><code>-ORBListenEndpoints uiop:// - -ORBListenEndpoints shmiop:// </code></blockquote> then a - default endpoint will be created for the specified - protocol. <p> - - Click <a href="ORBEndpoint.html"> here</a> for much more on - how to specify endpoints. - </td> - </tr> - <tr> - <td><code>-ORBLaneEndpoint</code> <em>endpoint</em></td> - <td><a name="-ORBLaneEndpoint"></a>This option is same as the - <a - href="#-ORBLaneListenEndpoints"><code>-ORBLaneListenEndPoints</code></a> - option described below. <font color="red">This option will be - deprecated in later versions on TAO.</font> - </td> - </tr> - <tr> - <td><code>-ORBLaneListenEndpoints</code> - <em>thread-pool-id:thread-lane-id endpoint</em></td> <td><a - name="-ORBLaneListenEndpoints"></a> This option allows the - user to specify endpoints for thread pools and lanes. This - option is only meaningful when used with Real-time CORBA and - only makes sense when the thread pools and lanes are created in the - same order across server incarnations. See <a - href="#-ORBListenEndpoints"><code>-ORBListenEndPoints</code></a> - option on how to specify endpoints. An example is: - <blockquote><code>2:3 iiop://localhost:2345 - </code></blockquote> where <code>2</code> specifies the second - thread pool created by the process and <code>3</code> - specifies the third lane of that thread pool. Note that - <code>0</code> should be used for the lane when specifying - endpoints for thread pools without lanes. - - <p>Sets of endpoints may be specified using multiple - <code>-ORBLaneListenEndpoints</code> options or by delimiting - endpoints with a semi-colon (;). For example, - <blockquote><code>-ORBLaneListenEndpoints 1:4 - iiop://localhost:9999 -ORBLaneListenEndpoints 1:4 - uiop:///tmp/mylocalsock -ORBLaneListenEndpoints 1:4 - shmiop://10002 </code></blockquote> is equivalent to: - <blockquote><code>-ORBLaneListenEndpoints 1:4 - 'iiop://localhost:9999;uiop:///tmp/mylocalsock;shmiop://10002' - </code></blockquote> Notice the single quotes (') in the - latter option specification. Single quotes are needed to - prevent the shell from interpreting text after the semi-colon - as another command to run. <p>If an endpoint is specified - without an <code>addr</code> such as the following: </p> - <blockquote><code>-ORBLaneListenEndpoints 2:3 uiop:// - -ORBLaneListenEndpoints 2:3 shmiop:// </code></blockquote> - then a default endpoint will be created for the specified - protocol. - </td> - </tr> - <tr> - <td><code>-ORBImplRepoServicePort</code> <em>portspec</em></td> - <td>Specifies which port the Implementation Repository is -listening on for multicast requests. By default, the <code>TAO_DEFAULT_IMPLREPO_SERVER_REQUEST_PORT</code> -(10018) is used.</td> - </tr> - <tr> - <td><code>-ORBInitRef</code> <em>ObjectId=IOR</em></td> - <td><a name="-ORBInitRef"></a>Allows specification of an -arbitrary object reference for an initial service. The IOR could be in -any one of the following formats: OMG <code>IOR</code>, <code>URL</code>, - <code>corbaloc</code> (including <code>uioploc</code>) or <code>file</code>. - <code><A href="INS.html#corbaloc">corbaloc</A></code> is a multiple end-point IOR understood by - <code>ORB::string_to_object()</code> and used as a -boot-strapping mechanism by the <code>ORB::resolve_initial_references()</code>. -The mappings specified through this argument override the ORB -install-time defaults. The <code>file://pathname</code> interprets the -contents of the <code>pathname</code> file as an object reference in -any of the above formats. </td> - </tr> - <tr> - <td><code>-ORBMulticastDiscoveryEndpoint</code> <em>endpoint</em></td> - <td>Specifies the <code>endpoint</code> that should be used -for locating the Naming Service through multicast. <em>endpoint</em> -is of the form <code>ip-number:port-number</code> (<em>e.g.</em>, <code>"tango.cs.wustl.edu:1234"</code> -or <code>"128.252.166.57:1234"</code>). If there is no <code>':'</code> -in the end_point it is assumed to be a port number, with the IP address -being <code>INADDR_ANY</code>. </td> - </tr> - <tr> - <td><code>-ORBNameServicePort</code> <em>portspec</em></td> - <td>Specifies which port the Naming Service is listening on for -multicast requests. By default, the <code>TAO_DEFAULT_NAME_SERVICE_REQUEST_PORT</code> -(10013) value is used.</td> - </tr> - <tr> - <td> <code>-ORBTradingServicePort</code> - <em>portspec</em></a></td> - <td> Specifies -to which port the Trading Service is listening on for multicast -requests. By default, the <code>TAO_DEFAULT_TRADING_SERVICE_REQUEST_PORT</code> -(10016) value is used.</td> - </tr> - <tr> - <td> <code>-ORBUseIMR</code> <em>boolean (0|1)</em></td> - <td>This argument specifies that for POAs with the <code>PERSISTENT</code> -policy, that the TAO <a href="implrepo/">Implementation Repository</a> -should be used for notification of startup and shutdown and object -references should be changed to use the Implementation Repository also (N.B. -although see <code>-ORBIMREndpointsInIOR</code> below). </td> - </tr> - <tr> - <td> <code>-ORBIMREndpointsInIOR</code> <em>boolean (0|1)</em></td> - <td>This argument specifies whether, for POAs with the <code>PERSISTENT</code> -policy, the TAO <a href="implrepo/">Implementation Repository</a> -listen endpoints should be encoded into IORs when <code>-ORBUseIMR</code> -is set. The default is true. </td> - </tr> - <tr> - <td><code>-ORBUseParallelConnects</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBUseParallelConnects"></a>This option allows users to - specify the ORB attempt to connect simultaniously to all endpoints - listed in profiles, rather than stepping through individual endpoints, - trying and possibly failing, before moving on to the next. For this - feature to work, the server must be using shared profiles. - The default is <code>0</code> (false). - </td> - </tr> - <tr> - <td><code>-ORBUseSharedProfile</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBUseSharedProfile"></a> - This option allows multiple implicit or explicit endpoints to be - combined into a single profile for a given protocol rather than using - multiple profiles. For IIOP in non RTCORBA environments, the CORBA - specified tagged component <code>TAG_ALTERNATE_IIOP_ADDRESS</code> is - used to encode the combined endpoints. Processses using RTCORBA and - priority banded connections will continue to generate Profiles with - <code>TAO_TAG_IIOP_ENDPOINT</code> components. - This options is disabled by default. - </td> - </tr> - <tr> - <td><code>-ORBParallelConnectDelay</code> <em>unsigned long msec</em></td> - <td><a name="-ORBParallelConnectDelay"></a>When using parallel - connection attempts, this option defines the number of milliseconds to - delay when polling previously started connection attempts. If a server - is likely to be busy, this client side option will help avoid creating - redundant connections that must be accepted, only to be closed a moment - later. However, if the first reachable endpoint is far down the list, - this option will increase the delay before that endpoint is reached. - The default is <code>0</code>. - </td> - </tr> - <tr> - <td><code>-ORBPreferIPV6Interfaces</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBPreferIPV6Interfaces"></a> - If option is <CODE>1</CODE> (true) it directs the default - endpoint selector for client connections to first attempt to - connect any IIOP endpoints from a provided IOR specifying - IPv6 interfaces. Only when none of these can be found or sucessfully connected IPv4 - interfaces will be tried. The default is <CODE>0</CODE> (false). - <p> - This option is only available for IPv6 enabled builds of TAO (<CODE>ACE_HAS_IPV6</CODE>). - </td> - </tr> - <tr> - <td><code>-ORBConnectIPV6Only</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBConnectIPV6Only"></a> - If this option is <CODE>1</CODE> (true) it directs a server ORB to:<br><p> - <li>allow only IPv6 interfaces as listening endpoints</li> - <li>encode only IPv6 interfaces in the IOR profile</li> - <li>prevent (depending on availability of IPV6_V6ONLY socket option) - or block IPv6 to IPv4 connections</li> - <p> - This option directs the default endpoint selector for client connections - to only attempt to connect any IIOP endpoints from a provided IOR specifying - IPv6 interfaces. Any available IPv4 interfaces will be - ignored. The default setting is <CODE>0</CODE> (false). - <p> - This option is only available for IPv6 enabled builds of TAO (ACE_HAS_IPV6). - </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="MO">5. Miscellaneous Options</a></h4> -Options in this category don't control the behavior of the ORB in -terms of resouces or strategies. Instead, they are helper options -provided for specific application requirements. -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBId</code> <em>orb_name</em></td> - <td><a name="-ORBId"></a>This option allows the name of an ORB -to be set to <code>orb_name</code>. The <CODE>ORBId</CODE> will be -passed to the <CODE>CORBA::ORB_init()</CODE> method to differentiate -coexisting ORBs (when there is more than one ORB).</td> - </tr> - <tr> - <td><code>-ORBServerId</code> <em>server_id</em></td> - <td><a name="-ORBId"></a>This option allows setting a name/id -to a server to uniquely identify a server to TAO's <a href="implrepo">Implementation -Repository</a>. </td> - </tr> - <tr> - <td><code>-ORBDaemon</code></td> - <td>Specifies that the ORB should <em>daemonize</em> itself, <em>i.e.</em>, -run as a background process. This option is only meaningful on OS -platforms that support daemonization.</td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<p></p> -<hr width="25%" align="left"> -<h3><a name="SVC">The Service Configurator File</a></h3> -Internally, TAO uses the <a - href="http://www.cs.wustl.edu/%7Eschmidt/PDF/Svc-Conf.pdf">ACE Service -Configurator framework</a> to allow applications to configure the ORB -at run-time. Applications provide a file named <code>svc.conf</code> -with options that configure appropriate strategies in to the ORB. The -options enable developers to control the behavior of the factories, -strategies, and resources that the ORB uses. By default, TAO provides -the following set of factories: -<p></p> -<ol> - <li><a href="#TRF">Default Resource and Advanced Resource Factories.</a> -This factory controls the creation of configurable resources used by -TAO's ORB core. The resource factory is responsible for constructing -and providing access to various resources used by the ORB irrespective -of whether they perform client or server roles. ORB resources include -reactors, protocol factories, message flushing strategies, connection -purging strategies and different IOR parsers. - <p> </p> - </li> - <li> <a href="#TSSF">Server Strategy Factory.</a> This factory -creates various strategies of special utility to the ORB that is useful -for controlling the behavior of servers. This factory is responsible -for creating strategies useful for server objects like the concurrency -strategy and the request demultiplexing strategies used by the POA. - <p> </p> - </li> - <li> <a href="#TCSF">Client Strategy Factory.</a> This factory -creates various strategies of special utility to the ORB, useful for -controlling the behavior of clients. This factory is responsible for -creating strategies useful for clients such as request multiplexing -strategies, wait strategies, connect strategies etc. - <p></p> - </li> -</ol> -Options specified via a <code>svc.conf</code> file can represent -either the components provided by TAO (including the -<code>Resource_Factory</code>, and the -<code>Server_Strategy_Factory</code> and -<code>Client_Strategy_Factory</code>) or customized components -developed by the users. The service configurator file -(<code>svc.conf</code>) provided by the user identifies the components -to be loaded with the required strategies for each component. -<p>A <code>svc.conf</code> file is <em><b>not</b></em> required to -run -TAO applications since TAO provides a set of default values for -strategies useful for the most common use cases, <em>i.e.</em>, the -default values are set for all options. When a TAO application calls -<code>CORBA::ORB_init()</code> it will try to find the -<code>svc.conf</code> file. If found, TAO will parse and process the -directives in the file; if not found, the default value for the -default components will be used.</p> -<hr width="25%" align="left"> -<h4><a name="TRF">1. Default and Advanced Resource Factories</a></h4> -Many of TAO's ORB Core resources are fixed, including the allocators -for -the incoming and outgoing data paths, and data structures for the -various -maps and lists maintained by the ORB. There is some flexibility, -however, in the choice of a reactor, the selection of transport -protocols, choice of data flushing strategy, various forms of -connection resource management strategies and possibility of using -different IOR parsers. The resource factories supported by TAO -include the <code>Resource_Factory</code> and -<code>Advanced_Resource_Factory</code>. TAO provides defaults of these -factories, as well as the specialized resource factories described -below: -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Resource Factory</th> - <th>Description</th> - </tr> - <tr> - <td><code><a href="#TDRF">Resource Factory</a></code></td> - <td>Unless configured otherwise, this is the default resource -factory used by the ORB.The resource factory is responsible for -creating and providing access to various resources used by the server -and client ORBs. The resources managed by this factory include creation -of acceptor and connector registries, choice of data flushing strategy, -limits for connection resource management, types of CDR buffers used -for marshalling and demarshalling data, and different IOR parsers. </td> - </tr> - <tr> - <td><code><a href="#TARF">Advanced Resource Factory</a></code></td> - <td>This factory provides more advanced configuration options -in the addition to all the features of the default resource factory.<br> - <br> -The advanced resource factory gives more control than the default -resource factory over the type of resources used and how those -resources are accessed. In addition to the options provided by the -default resource factory, the advanced resource factory provides -options that allow selecting different reactors, choosing different -transport mechanisms and selecting the right connection purging -strategy to maintain limits on resources used. The advanced resource -factory was created to allow more advanced options while keeping the -footprint of the default resource factory small.<br> - <br> -The advanced resource factory inherits from the default resource -factory and accepts all of its options in addition to its own. </td> - </tr> - <tr> - <td><code>Qt Resource Factory</code></td> - <td>This is a specialized resource factory providing the means -for integrating with the Qt GUI toolkit from Trolltech. </td> - </tr> - <tr> - <td><code>Xt Resource Factory</code></td> - <td>This is a specialized resource factory providing the means -for integrating with the X Window System's Xt Intrinsics toolkit. </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<p></p> -<h4><a name="TDRF">1.1. Resource_Factory</a></h4> -Typically, the above options are exercised via the service -configurator (svc.conf) file. The following line in the -<code>svc.conf</code> file (all in one line) -<p> <code>static -Resource_Factory "[list of options]"</code></p> -<p>will load the default -resource factory with the options listed within the double quotes. The -following table shows the list of possible options that can be -specified within the double quotes in the above directive. There is an <a - href="../tests/LongUpcalls/svc.conf"> -example</a> of how this is used in TAO.</p> -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBReactorMaskSignals</code> <em>0/1</em></td> - <td>ACE select reactors mask signals during upcalls to the -event handlers. This is only useful if the application is going to trap -those signals and handle them in any special way. Disabling the mask -can improve performance by reducing the number of kernel level locks. </td> - </tr> - <tr> - <td><code>-ORBProtocolFactory</code> <em>factory</em></td> - <td><a name="-ORBProtocolFactory"></a>Specify which pluggable -protocol factory to load. By default, only the factory for the IIOP -protocol (<code>IIOP_Factory</code>) is loaded. - <p>For example, if some protocol called <em><code>Foo</code></em> -whose factory was called <em><code>Foo_Factory</code></em> was -available, then it could be loaded into TAO by specifying <code>-ORBProtocolFactory -Foo_Factory</code> in the service configurator file. The <em><code>Foo</code></em> -pluggable protocol would then be available for use. </p> - </td> - </tr> - <tr> - <td><code>-ORBIORParser</code> <em>parser</em></td> - <td><a name="-ORBIORParser"></a>Name an IOR Parser to load. IOR -Parsers are used to interpret strings passed to <code>ORB::string_to_object()</code>. -By default the ORB can handle multiple string formats, including <code>IOR:</code>, - <code>corbaloc:</code>, <code>corbaname:</code>, and <code>file:</code>. -The application developer can <a href="ior_parsing.html">add -new IOR formats </a>using this option. </td> - </tr> - <tr> - <td><code>-ORBConnectionPurgingStrategy</code> <em>type</em></td> - <td><a name="-ORBConnectionPurgingStrategy"></a>Opened -connections are added to the transport cache so they can be reused. -If a process continues to run and these connections are not reused, -however, the cache will continue to grow. Before each new connection, -therefore, the cache is checked and purged if it has reached the limit -specified by the <CODE>-ORBConnectionCacheMax</CODE> option or the -system default if that option was not used. The possible values for -type are <CODE>lru</CODE>, <CODE>lfu</CODE>, <CODE>fifo</CODE>, and -<CODE>null</CODE>. The default is <CODE>lru</CODE> (least recently -used). The other options are <CODE>lfu</CODE> (least frequently used), -<CODE>fifo</CODE> (first in first out), and <CODE>null</CODE> (no -connections are purged) and are contained within the TAO Strategies -library. </td> - </tr> - <tr> - <td><code>-ORBConnectionCacheMax</code> <em>limit</em></td> - <td><a name="-ORBConnectionCacheMax"></a>The transport cache -will grow to a maximum of the specified limit. The default is system -dependent, but can be overridden at compile-time by defining the -preprocessor macro <CODE>TAO_CONNECTION_CACHE_MAXIMUM</CODE>. </td> - </tr> - <tr> - <td><code>-ORBMuxedConnectionMax</code> <em>number</em></td> - <td><a name="-ORBMuxedConnectionMax"></a>The transport cache -allows only specified number of connections-per-QoS property to be -added to connection cache. Threads not getting the connections will -wait for the connections to be released. This option is more useful for -transports using a muxed connection strategy and want control over the -number of connections that are created by the active threads. </td> - </tr> - <tr> - <td><code>-ORBConnectionCachePurgePercentage</code> <em>percent</em></td> - <td><a name="-ORBConnectionCachePurgePercentage"></a>If the -transport cache is purged, the specified percentage (20 by default) of -the total number of connections cached will be closed. </td> - </tr> - <tr> - <td><code>-ORBConnectionCacheLock</code> <em>locktype</em></td> - <td><a name="-ORBConnectionCacheLock"></a>Specify the type of -lock to be used by the Connection Cache. Possible values for lock type -are <code>thread</code>, which specifies that an inter-thread mutex is -used to guarantee exclusive access, and <code>null</code>, which -specifies that no locking be performed. The default is thread. </td> - </tr> - <tr> - <td><code>-ORBCorbaObjectLock</code> <em>locktype</em></td> - <td><a name="-ORBCorbaObjectLock"></a> Specify the type of lock -to be used by CORBA::Object. The lock is needed within the CORBA object -to synchronize the state when the same object is shared by multiple -threads. Possible values for lock type are <code>thread</code>, which -specifies that an inter-thread mutex is used to guarantee exclusive -access, and <code>null</code>, which specifies that no locking be -performed. The default is thread. The <code>null</code> lock option is -useful when there is only one thread in the system. This option can be -used to minimize the amount of memory consumed by the locks in -applications where locks are not needed. The memory growth problem gets -particularly exacerbated for applications dealing with hundreds and -thousands of objects. </td> - </tr> - <tr> - <td><code>-ORBObjectKeyTableLock</code> <em>locktype</em></td> - <td><a name="-ORBObjectKeyTableLock"></a> Specify the type of -lock to be used by the ObjectKey table. ObjectKey table keeps track of -the ObjectKeys that are generated and made available through IORs. The -table manages the life time of the object keys within the ORB through a -reference counting mechanism. Possible values for lock type are <code>thread</code>, -which specifies that an inter-thread mutex is used to guarantee -exclusive access, and <code>null</code>, which specifies that no -locking be performed. The default is thread. </td> - </tr> - <tr> - <td><code>-ORBFlushingStrategy</code> <em>type</em></td> - <td><a name="-ORBFlushingStrategy"></a>By default TAO provides -three strategies to flush queued messages. The <code>leader_follower</code> -strategy uses the Reactor and non-blocking I/O to send the outgoing -messages, this strategy participates in the Leader/Followers protocol -to synchronize access to the Reactor. The <code>reactive</code> -strategy uses the Reactor but does not take part in the -Leader/Followers protocol, thus it is better used only in single -threaded applications. Finally, the <code>blocking</code> strategy -flushes the queue as soon as it becomes "full", and blocks the thread -until all the data is sent. - </td> - </tr> - <tr> - <td><code>-ORBDropRepliesDuringShutdown</code> <em>boolean (0|1)</em></td> - <td><a name="-ORBDropRepliesDuringShutdown"></a> Strategy to - make the ORB wait for replies to show up even if the ORB is - shutdown. The default is to drop replies. For example, clients - comunicating with misbehaved servers will continue to hang if - replies don't show up and even if the client ORB is shutdown - from another thread. This strategy helps the ORB decide to - wait for the replies or drop replies. Some clients may not - want to drop replies, and may want all their requests to be - processed until ORB::destroy () is called. Setting the value - of this option to 0 would help with that. </td> - </tr> - <tr> - <td><code>-ORBOutputCDRAllocator</code> <em>mmap|local_memory_pool</em></td> - <td><a name="-ORBOutputCDRAllocator"></a>When the define - <code>TAO_USE_OUTPUT_CDR_MMAP_MEMORY_POOL</code> is set to 1 then always the mmap pool - will be used. - </td> - </tr> - <tr> - <td><code>-ORBZeroCopyWrite</code> </td> - <td><a name="-ORBZeroCopyWrite"></a> Use a zero copy write - protocol, which at this moment the only option is sendfile. - </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="TARF">1.2. Advanced_Resource_Factory</a></h4> -This factory is located in the <code>TAO_Strategies</code> library. It -accepts the options below as well as those described above in the -<code>Resource_Factory</code>. This factory can be loaded dynamically -using a service configurator directive of the form (all on one line): -<p><code>dynamic Advanced_Resource_Factory Service_Object -*</code><br> -<code>TAO_Strategies:_make_TAO_Advanced_Resource_Factory -() "-ORBReactorType select_st" </code></p> -<p>It can also be loaded statically by doing the following:</p> -<p></p> -<ul> - <li>Add <code>#include "tao/Strategies/advanced_resource.h"</code> -to the file containing <code>main()</code>. </li> - <li>Link the TAO_Strategies library into the executable. </li> - <li>Specify a service configurator directive of the form: <code>static -Advanced_Resource_Factory "-ORBReactorType select_st"</code> </li> -</ul> -You can -omit the <code>#include</code> if you always use dynamic libraries. -<p>Loading the <code>Advanced_Resource_Factory</code> disables the -<code>Resource_Factory</code>. Any directives for the -<code>Resource_Factory</code> will have no effect (and generate -warnings telling you so). The following table lists the options that -can be provided in double quotes. An <a - href="../performance-tests/Latency/Single_Threaded/svc.conf"> example</a> -is available that shows how to specify this option in the svc.conf file.</p> -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-ORBReactorType</code> <em>which</em></td> - <td><a name="-ORBReactorType"></a>Specify what kind of reactor -the ORB uses. The default reactor is the ACE_TP_Reactor. - <table border="1" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th><em>which</em></th> - <th>Reactor</th> - </tr> - <tr> - <td><code>select_mt</code></td> - <td>Use the multi-thread select-based reactor.</td> - </tr> - <tr> - <td><code>select_st</code></td> - <td>Use the single-thread select-based reactor.</td> - </tr> - <tr> - <td><code>wfmo</code></td> - <td>Use the WFMO reactor (Win32 only).</td> - </tr> - <tr> - <td><code>msg_wfmo</code></td> - <td>Use the MsgWFMO reactor (Win32 only).</td> - </tr> - <tr> - <td><code>tp</code></td> - <td>Use the <code>ACE_TP_Reactor</code>, a select based -thread-pool reactor which is the default.</td> - </tr> - </tbody> - </table> - </td> - </tr> - <tr> - <td><code>-ORBReactorThreadQueue</code> <em>which</em></td> - <td><a name="-ORBReactorThreadQueue"></a>Applies only to the -<CODE>ACE_TP_Reactor</CODE>, i.e., when <code>-ORBReactorType</code> = -<code>tp</code>, and specifies the order, last-in-first-out -(<em>which</em> = <code>LIFO</code>), the default, or -first-in-first-out (<em>which</em> = <code>FIFO</code>), in which -waiting threads are selected to run by the -<CODE>ACE_Select_Reactor_Token</CODE>. </td> - </tr> - <tr> - <td><code>-ORBInputCDRAllocator</code> <em>which</em></td> - <td><a name="-ORBInputCDRAllocator"></a>Specify whether the -ORB uses locked (<em>which</em> = <code>thread</code>) or lock-free -(<em>which</em> = <code>null</code>) allocators for the incoming CDR -buffers. Though <code>null</code> should give the optimal performance; -we made the default <code>thread</code>. TAO optimizations for octet -sequences will not work in all cases when the allocator does not have -locks (for example if the octet sequences are part of a return -value). Using locked allocators also allows the users to take -advantage of the TAO octet sequence extensions to preserve the buffer -after the upcall. </td> - </tr> - <tr> - <td><code>-ORBAMHResponseHandlerAllocator</code> <em>which</em></td> - <td><a name="-ORBAMHResponseHandlerAllocator"></a>Specify whether the ORB -uses locked (<em>which</em> = <code>thread</code>) or lock-free (<em>which</em> -= <code>null</code>) allocators for the AMH response handlers.</td> - </tr> - <tr> - <td><code>-ORBAMIResponseHandlerAllocator</code> <em>which</em></td> - <td><a name="-ORBAMIResponseHandlerAllocator"></a>Specify whether the ORB -uses locked (<em>which</em> = <code>thread</code>) or lock-free (<em>which</em> -= <code>null</code>) allocators for the AMI response handlers.</td> - </tr> - <tr> - <td><code>-ORBReactorRegistry</code> <em>registry_type</em></td> - <td><a name="-ORBReactorRegistry"></a>This option is no longer -supported. The Advanced Resource Factory will emit an error if you -attempt its use. </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="TSSF">2. Server_Strategy_Factory</a></h4> -Certain elements of the ORB relate only to a TAO server. In this -context, the server is any application that passively accepts -connection from other processes and receives requests from those other -connections. The server strategy factory is responsible for supporting -features of TAO that are specific to servers. In particular, these -include the following strategies: -<ul> - <li> The <em>concurrency strategies</em> control the thread creation -flags and other concurrency related behaviors. - <p></p> - </li> - <li> The <em>demuliplexing strategies</em> are used -to locate servants inside the POA that are responsible for handling -requests. - <p></p> - </li> -</ul> -TAO provides a default server strategy factory called -<code>Server_Strategy_Factory</code> -<p>Typically, the following options are set via the service -configurator -(svc.conf) file. The following line in the svc.conf file (all in one -line)</p> -<p><code>static Server_Strategy_Factory "[list of -options]"</code></p> -<p>would load all the options listed within "". An -<a href="../performance-tests/Latency/Single_Threaded/svc.conf">example</a> -is available -that shows how to specify this option in the <code>svc.conf</code> -file. </p> -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><a name="orb_concurrency"><code>-ORBConcurrency</code></a> <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. The default is reactive. </td> - </tr> - <tr> - <td><a name="server_timeout"><code>-ORBThreadPerConnectionTimeout</code></a> - <em>milliseconds</em></td> - <td>In many platforms it is impossible to interrupt the server -threads created by the <code>thread-per-connection</code> model. This -is because these threads are blocked in <code>read()</code> operations -(and not in <code>select()</code>). As a workaround, the server -threads periodically poll the ORB to find out if they should shutdown. -This option controls the period of the polling, expressed in -milliseconds. Applications that do not shutdown, or that can otherwise -ensure that no server threads will be running at shutdown (for example -if all the clients terminate before the server) can disable the -polling using the magic value <code>INFINITE</code>. - <p>If the option is not provided then the ORB uses the -compile-time flag <code>TAO_DEFAULT_THREAD_PER_CONNECTION_TIMEOUT</code>, -this flag also expresses the time in milliseconds (as a string -constant) and the magic value <code>"INFINITE"</code> can be used to -disable polling entirely. This yields a slight performance improvement -(around 1%). </p> - </td> - </tr> - <tr> - <td><code>-ORBActiveObjectMapSize</code> <em>active object map -size</em></td> - <td>Specify the size of the active object map. If not -specified, the default value is 64.</td> - </tr> - <tr> - <td><code>-ORBUseridPolicyDemuxStrategy</code> <em>user id -policy based demultiplexing strategy</em></td> - <td>Specify the demultiplexing lookup strategy to be used with -the user id policy. The <em>demultiplexing strategy</em> can be one of - <code>dynamic</code> or <code>linear</code>. This option -defaults to using the <code>dynamic</code> strategy. </td> - </tr> - <tr> - <td><code>-ORBSystemidPolicyDemuxStrategy</code> <em>system id -policy based demultiplexing strategy</em></td> - <td>Specify the demultiplexing lookup strategy to be used with -the system id policy. The <em>demultiplexing strategy</em> can be one -of <code>dynamic</code>, <code>linear</code>, or <code>active</code>. -This option defaults to use the <code>dynamic</code> strategy when <code>-ORBAllowReactivationOfSystemids</code> -is true, and to <code>active</code> strategy when <code>-ORBAllowReactivationOfSystemids</code> -is false. </td> - </tr> - <tr> - <td><code>-ORBUniqueidPolicyReverseDemuxStrategy</code> <em>unique -id policy based reverse demultiplexing strategy</em></td> - <td>Specify the reverse demultiplexing lookup strategy to be -used with the unique id policy. The <em>reverse demultiplexing strategy</em> -can be one of <code>dynamic</code> or <code>linear</code>. This -option defaults to using the <code>dynamic</code> strategy. </td> - </tr> - <tr> - <td><code>-ORBAllowReactivationOfSystemids</code> <em>allows -reactivation of system ids</em></td> - <td>Specify whether system ids can be reactivated, i.e., once -an id that was generated by the system has been deactivated, will the -user reactivate a new servant using the old id. If the user is not -going to use this feature, the IORs can be shortened, an extra -comparison in the critical upcall path removed, and some memory on the -server side can be saved. The <code>ORBAllowReactivationOfSystemids</code> -can be <code>0</code> or <code>1</code>. This option defaults to <code>1</code>. - </td> - </tr> - <tr> - <td><code>-ORBActiveHintInIds</code> <em>adds an active hint -in -ids</em></td> - <td>Specify whether an active hint should be added to ids. With -active hints, ids can be found quickly. However, they lead to larger -IORs. Note that this option is disregarded <code>if --ORBAllowReactivationOfSystemids</code> is set to <code>0</code>. The <em>-ORBActiveHintInIds</em> -can be <code>0</code> or <code>1</code>. This option defaults to <code>1</code>. - </td> - </tr> - <tr> - <td><code>-ORBPoaMapSize</code> <em>poa map size</em></td> - <td>Specify the size of the POA map. If not specified, the -default value is 24.</td> - </tr> - <tr> - <td><code>-ORBPersistentidPolicyDemuxStrategy</code> <em>persistent -id policy based demultiplexing strategy</em></td> - <td>Specify the demultiplexing lookup strategy to be used with -the persistent id policy. The <em>demultiplexing strategy</em> can be -one of <code>dynamic</code> or <code>linear</code>. This option -defaults to using the <code>dynamic</code> strategy. </td> - </tr> - <tr> - <td><code>-ORBTransientidPolicyDemuxStrategy</code> <em>transient -id policy based demultiplexing strategy</em></td> - <td>Specify the demultiplexing lookup strategy to be used with -the transient id policy. The <em>demultiplexing strategy</em> can be -one of <code>dynamic</code>, <code>linear</code>, or <code>active</code>. -This option defaults to using the <code>active</code> strategy. </td> - </tr> - <tr> - <td><code>-ORBActiveHintInPOANames</code> <em>adds an active -hint in poa names</em></td> - <td>Specify whether an active hint should be added to POA -names. With active hints, POA names can be found quickly. However, they -lead to larger IORs. The <code>-ORBActiveHintInPOANames</code> can be <code>0</code> -or <code>1</code>. This option defaults to <code>1</code>. </td> - </tr> - <tr> - <td><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>. The -default is <code>THR_BOUND | THR_DETACHED</code> . </td> - </tr> - <tr> - <td><code>-ORBPOALock</code> <em>lock type</em></td> - <td><a name="-ORBPOALock"></a>Specify the type of lock to be -used for POA accesses. Possible values for <em>lock type</em> are <code>thread</code>, -which specifies that an inter-thread mutex is used to guarantee -exclusive access, and <code>null</code>, which specifies that no -locking be performed. The default is <code>thread</code>.</td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<h4><a name="TCSF">3. Client_Strategy_Factory</a></h4> -Similar to the -server strategy factory, the client strategy factory supports those -elements of TAO that are specific to the behavior of clients, which -are any CORBA applications that actively establish connections, submit -requests, and perhap receive responses. The client strategy factory -provides control over several resources used by clients. TAO provides -a default client strategy factory called -<code>Client_Strategy_Factory</code>. -<p>Typically, the following options are set via the service -configurator -(<code>svc.conf</code>) file. The following line in the -<code>svc.conf</code> file (all in one line)</p> -<p><code>static -Client_Strategy_Factory "[list of options]"</code></p> -<p> would load all -the options listed within "". An <a - href="../performance-tests/Latency/Single_Threaded/svc.conf">example</a> -is available that shows how to specify this option in the <code>svc.conf</code> -file.</p> -<p></p> -<blockquote> - <p> - <table border="2" cellpadding="0" cellspacing="2"> - <tbody> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code><a name="#-ORBProfileLock">-ORBProfileLock</a></code> - <em>which</em></td> - <td>Specify the kind of synchronization primitive for the -Profiles. Default is <em>thread</em>, which means that a regular -thread mutex is used. The second option is <em>null</em>, which means -a null lock is used. This makes sense in case of optimizations and is -allowed when no forwarding is used or only a single threaded client. </td> - </tr> - <tr> - <td><code>-ORBClientConnectionHandler</code> <em>MT | ST | RW - / MT_NOUPCALL</em><br> - <code>-ORBWaitStrategy</code> <em>MT / ST / RW / MT_NOUPCALL - </em> -</td> - <td><em>Please note that these two options are synonymous and can be used interchangeably.</em> - <p><a name="-ORBClientConnectionHandler"></a><em>ST</em> means -use the single-threaded client connection handler, i.e., the leader -follower model will not be used. However, <em>ST</em> does support -nested upcalls and handling of new requests while waiting for the reply -from a server. - <p><em>MT</em> means use the multi-threaded client connection -handler which uses the leader follower model. This model allows the use -of multiple threads with a single Reactor. </p> - <p><em>RW</em> selects a strategy that simply blocks in -<code>recv()</code> when waiting for a response from the server -instead of waiting in the Reactor using the Leader/Followers -pattern. The <em>RW</em> strategy only works when the application -does not have to worry about new request showing up when waiting for a -response. Further, this strategy cannot be used with Asynchronous -Method Invocation (AMI) calls and when using BiDIR GIOP. -Therefore, this strategy is appropriate -only for "pure" synchronous clients. Note that applications that -require nested upcalls are not "pure" synchronous clients. Also note that this -strategy will only affect two way calls, since there is no waiting for -one way calls. This strategy can also be used in an application that -is both a client and a server if the server side is handled by a -separate thread and the client threads are "pure" clients. </p> <p> - <CODE>MT_NOUPCALL</CODE> <b>(EXPERIMENTAL!)</b> means use a client connection handler that - participates in the leader-follower model like MT, but, like - RW, does not allow handling of nested upcalls within the - waiting thread. Note that with this strategy it is possible - to "run out of threads" in a thread pool, and that TAO doesn't - grow thread pools. Unlike RW, this does not require <a - href="#ORBTransportMuxStrategy">-ORBTransportMuxStrategy <em>EXCLUSIVE</em></a>. -<!-- -I'm not sure what the affect of AMI on this option is. ---> -</p> - <p>Default for this option is <em>MT</em>. </p> - </td> - </tr> - - <tr> - <td><code>-ORBConnectionHandlerCleanup</code> <em>0 | 1</em><br> - </td> - <td><a name="-ORBConnectionHandlerCleanup"></a>Setting this - option to <em>1</em> lets the ORB know that connection - handlers setup for sending messages need to be cleaned up - when errors occur. This option has an effect only for - <em> -ORBClientConnectionHandler RW </em>. Rest of the - options for <em> -ORBCleintConnectionHandler </em> have been - automatically set up for cleaning the connection - handlers. Setting the option to <em> 1 </em> has a side - effect of registering and unregistering the connection - handlers with the Reactor for every invocation, which has a - negative impact on performance. Setting the option to <em> 0 - </em> prevents this performance impact but leads to problems - outlined - <A - href="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2186"> - here</A> and <a - href="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=2224"> - here</A> - <p>Default for this option is <em>0</em>. </p> - </td> - </tr> - - <tr> - <td><code>-ORBTransportMuxStrategy</code> <em>EXCLUSIVE | MUXED</em></td> - <td><a name="ORBTransportMuxStrategy"></a><em>EXCLUSIVE</em> -means that the Transport does not multiplex requests on a connection. -At a time, there can be only one request pending on a connection. - <p><em>MUXED</em> means that Transport multiplexes more than -one request at the same time on a connection. This option is often used -in conjunction with AMI, because multiple requests can be sent "in -bulk." </p> - <p>Default for this option is <em>MUXED</em>. </p> - </td> - </tr> - <tr> - <td><code>-ORBConnectStrategy</code> <em>type</em></td> - <td><a name="-ORBConnectStrategy"></a>TAO provides three -strategies to connect to remote servers. The default <em>leader_follower</em> -strategy uses the Reactor and non-blocking connects to connect and this -strategy participates in the Leader/Followers protocol to synchronize -access to the Reactor. The <em>reactive</em> strategy uses the Reactor -for non-blocking connects but does not take part in the -Leader/Followers protocol, thus it is better used only in single -threaded applications. Finally, the <em>blocked</em> strategy as the -name implies, blocks the thread until connection is complete. Some of -the protocols in TAO (such as SHMIOP and SSLIOP) can only use the <em>blocked</em> -strategy. - </td> - </tr> - </tbody> - </table> - </p> -</blockquote> -<hr> -<p>Back to the TAO <a href="components.html">component options and tuning documentation</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -</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/Security/Conformance.html b/TAO/docs/Security/Conformance.html deleted file mode 100644 index 3f8c5488605..00000000000 --- a/TAO/docs/Security/Conformance.html +++ /dev/null @@ -1,401 +0,0 @@ -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO -- CORBA Security</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <p align="center"><font size="5">CORBA Security Conformance Statement</font></p> - <p align="center">28 November, 2000</p> - <p align="center">TAO (The ACE ORB)</p> - <p align="center">Center for Distributed Object Computing, Washington University<br> - Distributed Object Computing Laboratory, University of California at Irvine</p> - <ul> - <li><a href="#Introduction">Introduction</a> - <ul> - <li><a href="#Introduction_1">Summary of Security Conformance</a></li> - <li><a href="#Introduction_2">Scope of Product</a></li> - <li><a href="#Introduction_3">Security Overview</a></li> - </ul> - </li> - <li><a href="#Security_Conformance">Security Conformance</a> - <ul> - <li><a href="#Security_Conformance_1">Main Security Functionality Level</a></li> - <li><a href="#Security_Conformance_2">Security Functionality Options</a></li> - <li><a href="#Security_Conformance_3">Security Replaceability</a></li> - <li><a href="#Security_Conformance_4">Secure Interoperability</a></li> - <li><a href="#Security_Conformance_5">Level of Interoperability</a></li> - <li><a href="#Security_Conformance_6">Mechanism Profiles</a></li> - </ul> - </li> - <li><a href="#Assurance">Assurance</a> - <ul> - <li><a href="#Assurance_1">Philosophy of Protection</a></li> - <li><a href="#Assurance_2">Threats</a> </li> - <li><a href="#Assurance_3">Security Policies</a></li> - <li><a href="#Assurance_4">Security Protection Mechanisms</a></li> - <li><a href="#Assurance_5">Environmental Support</a></li> - <li><a href="#Assurance_6">Configuration Constraints</a></li> - <li><a href="#Assurance_7">Security Policy Extensions</a></li> - </ul> - </li> - <li><a href="#Supplemental">Supplemental Product Information</a></li> - </ul> - <h2>1. Introduction<a name="Introduction"></a> </h2> - <p>The security features that TAO provides are introduced in this section. Detailed - descriptions are available in later major sections. </p> - <h3>1.1 Summary of Security Conformance<a name="Introduction_1"></a></h3> - <p>This section summarizes the CORBA Security Service features that TAO provides.</p> - <table width="100%" border="1" align="center"> - <tr bgcolor="#CCCCFF"> - <td colspan="5"> - <div align="center"><b>CORBA Security Functionality Checklist</b></div> - </td> - </tr> - <tr> - <td rowspan="2" width="26%"> - <div align="center"> - <p><b>Main Functionality</b></p> - <p><b> (Level 1 or Level 2)</b></p> - </div> - </td> - <td rowspan="2" width="22%"> - <div align="center"> - <p><b>Functionality Options</b></p> - <p><b>(Non-Repudiation)</b></p> - </div> - </td> - <td colspan="3"> - <div align="center"><b>Security Replaceability</b></div> - </td> - </tr> - <tr> - <td width="16%"> - <div align="center"><b>ORB Services</b></div> - </td> - <td width="18%"> - <div align="center"><b>Security Services</b></div> - </td> - <td width="18%"> - <div align="center"><b>Security Ready</b></div> - </td> - </tr> - <tr> - <td width="26%" bgcolor="#3333FF"> </td> - <td width="22%"> </td> - <td width="16%"> </td> - <td width="18%" bgcolor="#3333FF"> </td> - <td width="18%"> </td> - </tr> - </table> - <p> </p> - <table width="100%" border="1" align="center"> - <tr bgcolor="#CCCCFF"> - <td height="2" colspan="9"> - <div align="center"><b>CORBA Secure Interoperability Checklist</b></div> - </td> - </tr> - <tr> - <td> - <div align="center"><b>Interoperability</b></div> - </td> - <td colspan="7"> - <div align="center"><b>IIOP</b></div> - </td> - <td> - <div align="center"><b>DCE</b></div> - </td> - </tr> - <tr> - <td rowspan="3"> - <div align="center"><b>Level</b></div> - </td> - <td colspan="6"> - <div align="center"><b>SECIOP</b></div> - </td> - <td rowspan="3"> - <div align="center"><b>SSL</b></div> - <div align="center"></div> - <div align="center"></div> - </td> - <td rowspan="3"> - <div align="center"><b>CIOP</b></div> - <div align="center"></div> - <div align="center"></div> - </td> - </tr> - <tr> - <td colspan="2"> - <div align="center"><b>SPKM</b></div> - </td> - <td rowspan="2"> - <div align="center"><b>Kerberos</b></div> - </td> - <td colspan="3"> - <div align="center"><b>CSI-ECMA</b></div> - </td> - </tr> - <tr> - <td> - <div align="center"><b>SPKM 1</b></div> - </td> - <td> - <div align="center"><b>SPKM 2</b></div> - </td> - <td> - <div align="center"><b>Private</b></div> - </td> - <td> - <div align="center"><b>Public</b></div> - </td> - <td> - <div align="center"><b>Hybrid</b></div> - </td> - </tr> - <tr> - <td> - <div align="center">Level 0</div> - </td> - <td> </td> - <td> </td> - <td> </td> - <td> </td> - <td> </td> - <td> </td> - <td bgcolor="#33FF33"> </td> - <td> </td> - </tr> - <tr> - <td> - <div align="center">Level 1</div> - </td> - <td bgcolor="#999999"> </td> - <td bgcolor="#999999"> </td> - <td> </td> - <td> </td> - <td> </td> - <td> </td> - <td bgcolor="#999999"> </td> - <td> </td> - </tr> - <tr> - <td> - <div align="center">Level 2</div> - </td> - <td bgcolor="#999999"> </td> - <td bgcolor="#999999"> </td> - <td bgcolor="#999999"> </td> - <td> </td> - <td> </td> - <td> </td> - <td bgcolor="#999999"> </td> - <td> </td> - </tr> - </table> - <p> </p> - <table width="71%" border="1" align="center"> - <tr> - <td width="22%" height="32"> - <div align="center"><b>Supported</b></div> - </td> - <td width="18%" height="32"> - <div align="center"><b>Pending</b></div> - </td> - <td width="16%" height="32"> - <div align="center"><b>N/A</b></div> - </td> - </tr> - <tr> - <td width="22%" height="32" bgcolor="#33FF33"> - <div align="left"></div> - </td> - <td width="18%" height="32" bgcolor="#3333FF"> - <div align="left"></div> - </td> - <td width="16%" height="32" bgcolor="#999999"> - <div align="left"></div> - </td> - </tr> - </table> - <h3>1.2 Scope of Product<a name="Introduction_2"></a></h3> - <p> TAO supports confidential communication through its IIOP over SSL pluggable - protocol, <a href="SSLIOP.html">SSLIOP</a>.</p> - <h3>1.3 Security Overview<a name="Introduction_3"></a></h3> - <p>Using TAO's SSLIOP pluggable protocol, it is possible to ensure that all - remote method invocations between ORBs that implement IIOP over SSL are confidential. - This is made possible by the confidentiality the Secure Socket Layer (SSL) - provides. X.509 certificate-based access control is also possible using TAO's - <code>SSLIOP::Current</code> extension.</p> - <ul> - <ul> - <blockquote> - <ul> - <ul> - <ul> - </ul> - </ul> - </ul> - </blockquote> - </ul> - </ul> - <h2>2. Security Conformance<a name="Security_Conformance"></a></h2> - <p>TAO conformance to the CORBA Security Service is detailed in this section.</p> - <h3>2.1 Main Security Functionality Level<a name="Security_Conformance_1"></a></h3> - <p>Work is currently underway to implement Security Functionality Level 1.</p> - <h3>2.2 Security Functionality Options<a name="Security_Conformance_2"></a></h3> - <p>There are no current plans to implement non-repudiation. However, this may - change in the future.</p> - <h3>2.3 Security Replaceability<a name="Security_Conformance_3"></a></h3> - <p>Work is currently underway to implement the core Security Replaceability - components detailed in the Security Service.</p> - <h3>2.4 Secure Interoperability<a name="Security_Conformance_4"></a></h3> - <p>TAO supports SSL based interoperability. It uses <a href="http://www.openssl.org/">OpenSSL</a> - as its underlying SSL implementation.</p> - <h3>2.5 Level of Interoperability<a name="Security_Conformance_5"></a></h3> - <p>TAO supports <i>level 0</i> interoperability through its IIOP over SSL pluggable - protocol, <a href="SSLIOP.html">SSLIOP</a>.</p> - <h3>2.6 Mechanism Profiles<a name="Security_Conformance_6"></a></h3> - <p>All cryptographic profiles supported by SSL, OpenSSL in particular, are supported - by TAO. ORBs that support those profiles should be able to interoperate with - TAO. </p> - <h2>3. Assurance<a name="Assurance"></a></h2> - <h3>3.1 Philosophy of Protection<a name="Assurance_1"></a></h3> - <h3>3.2 Threats<a name="Assurance_2"></a></h3> - <h3>3.3 Security Policies<a name="Assurance_3"></a></h3> - <h3>3.4 Security Protection Mechanisms<a name="Assurance_4"></a></h3> - <h3>3.5 Environmental Support<a name="Assurance_5"></a></h3> - <h3>3.6 Configuration Constraints<a name="Assurance_6"></a></h3> - <h3>3.7 Security Policy Extensions<a name="Assurance_7"></a></h3> - <h2>4. Supplemental Product Information<a name="Supplemental"></a></h2> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Security/Download.html b/TAO/docs/Security/Download.html deleted file mode 100644 index 18071bab60a..00000000000 --- a/TAO/docs/Security/Download.html +++ /dev/null @@ -1,158 +0,0 @@ -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO - CORBA Security Downloads</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <h2>Downloads</h2> - <p>The Open Source™ cryptographic software available for download from - this site is subject to United States crytpographic software export regulations. - A copy of those export regulations is available from the US <a href="http://www.bxa.doc.gov/Encryption/">Bureau - of Export Administration</a>.</p> - <p>In accordance with those regulations, the BXA has been notified of the availability - of the open source encryption-enabled software on this site. This makes it - legal to export open source cryptographic software to countries not restricted - by the BXA from this US site.</p> - <h3>TAO CORBA Security Service Software</h3> - <ul> - <li><a href="http://deuce.doc.wustl.edu/Download.html"> TAO: The ACE - ORB</a> (TAO's CORBA Security Service is now shipped with the main TAO distribution)</li> - </ul> - <h3>Cryptographic Software</h3> - <ul> - <li><a href="http://www.openssl.org/">OpenSSL</a> (0.9.4 or better required - by the ACE SSL wrappers and TAO SSLIOP)</li> - </ul> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Security/FAQ.html b/TAO/docs/Security/FAQ.html deleted file mode 100644 index 966c935117c..00000000000 --- a/TAO/docs/Security/FAQ.html +++ /dev/null @@ -1,154 +0,0 @@ -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO - CORBA Security Frequently Asked Questions</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <h2>Frequently Asked Questions</h2> - <ol> - <li>Why do I get a <code>CORBA::TRANSIENT</code> exception when using SSLIOP?<br> - <br> - A <code>CORBA::TRANSIENT</code> exception is typically an indication that - the client was unable to connect to the server when attempting to invoke - a request. For standard IIOP, such a situation normally occurs when the - client is unable to resolve the hostname embedded in the IOR or the given - IP address is unreachable.<br> - <br> - In the case of SSLIOP, a <code>CORBA::TRANSIENT</code> exception may also - be thrown when the certificates in use are invalid (e.g. expired), or the - certificate authority certificate has not been set. See the <a href="SSLIOP-USAGE.html">SSLIOP - Usage </a> page to see how to set these for TAO's SSLIOP implementation.</li> - </ol> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Security/SSLIOP-INSTALL.html b/TAO/docs/Security/SSLIOP-INSTALL.html deleted file mode 100644 index b2e5dae3dd4..00000000000 --- a/TAO/docs/Security/SSLIOP-INSTALL.html +++ /dev/null @@ -1,102 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - - <head> - <title>TAO's SSLIOP Protocol - Installation</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <H1>TAO's SSLIOP Pluggable Protocol - Installation</H1> - - -<p>The first step for all platforms is to build and install the <A HREF="http://www.openssl.org/">OpenSSL</A> - distribution. Then the TAO SSLIOP pluggable protocol library must be built according - to the instructions below. Refer to the <a href="SSLIOP.html">TAO SSLIOP usage - instructions</a> for details about how to use the SSLIOP pluggable protocol. - See the <a href="../../../ACE-INSTALL.html#sslinstall">ACE - installation notes</A> for how to build ACE_SSL after you have build OpenSSL. -</p> -<h3>UNIX</h3> -<OL> - <LI>Make sure the OpenSSL header file directory is in your compiler's include - path, and that OpenSSL libraries are in your library link/load path (e.g. - <font face="Courier New, Courier, mono">LD_LIBRARY_PATH</font>). If you installed - OpenSSL into a set of directories unknown by the compiler, then set the following - variables in your <font face="Courier New, Courier, mono">platform_macros.GNU</font> - file:</LI> - - <table width="75%" border="0" align="center"> - <tr> - <td><font face="Courier New, Courier, mono">PLATFORM_SSL_CPPFLAGS</font></td> - <td>Platform preprocessor options for OpenSSL (e.g. -I...)</td> - </tr> - <tr> - <td><font face="Courier New, Courier, mono">PLATFORM_SSL_LDFLAGS</font></td> - <td>Platform linker options for OpenSSL (e.g. -L...)</td> - </tr> - <tr> - <td><font face="Courier New, Courier, mono">PLATFORM_SSL_LIBS</font></td> - <td>Platform libraries required with OpenSSL</td> - </tr> - </table> - <br> - - <LI>Build ACE and TAO as described in the <A HREF="../../../ACE-INSTALL.html">ACE - installation</A> instructions and the <A HREF="../../../TAO/TAO-INSTALL.html">TAO - installation</A> instructions, respectively. When building ACE and TAO, add - "<font face="Courier New, Courier, mono">ssl=1</font>" to your <font face="Courier New, Courier, mono">make</font> - command line invocation, or add it to your <font face="Courier New, Courier, mono">platform_macros.GNU</font> - file.</LI> - <li>Build the SSLIOP pluggable protocol library in the <TT>$TAO_ROOT/orbsvcs/orbsvcs/SSLIOP</TT> - directory. (<TT>ACE_ROOT</TT> environment variable should be set prior - to this point), by invoking <font face="Courier New, Courier, mono">make</font> - with <font face="Courier New, Courier, mono">TAO_ORBSVCS=SSLIOP</font>.</li> -</OL> -<h3>Microsoft Visual Studio</h3> -<ol> - <li>Set the OpenSSL include/header directory path under the <b><i>Directories</i></b> - tab - <i><b>Include Files</b></i> setting in the <i><b>Tools->Options</b></i> - dialog. A typical value would be something like: <code>openssl-0.9.6\inc32</code></li> - <li>Set the OpenSSL library directory path under the <b><i>Directories</i></b> - tab - <i><b>Library Files</b></i> setting in the <i><b>Tools->Options</b></i> - dialog. A typical value would be something like: <code>openssl-0.9.6\out32dll</code></li> - <li>Open the <code>TAOACE.dsw</code> workspace, and refer to the <a href="../../../ACE-INSTALL.html">ACE - installation</a> and the <a href="../../../TAO/TAO-INSTALL.html">TAO - installation</a> instructions for details on creating a <code>config.h</code> - configuration header for this platform. Once the config.h file has been created, - build <code>SSLIOP</code> project. All project dependencies are already set, - so those projects that SSLIOP depends on will be automatically built. </li> -</ol> -<h3>Borland C++</h3> - <p>Note: You will need perl installed on your system and available on - the path to be able to build OpenSSL. - <ol> - <li>Obtain and unpack OpenSSL. - <li><p>Apply this <A HREF="http://www.tenermerx.com/programming/corba/tao_bcb/openssl-0.9.6h-bcbpatch.tgz">patch</A>. - <p>This will enable OpenSSL to build DLLs that can be used by - ACE+TAO. If you will only be doing a static build of - ACE+TAO you do not need to apply this patch. - <li>Open a command prompt and change to the OpenSSL directory.</li> - <li>Configure OpenSSL to build by executing the command: - <p><code>ms\bcb4.bat</code></li> - <li>If you want to use SSL in a dynamic library build of - ACE+TAO, run the command: - <p><code>make -f bcbdll.mak</code></li> - <li>If you want to use SSL in a static build of ACE+TAO, run the - command: - <p><code>make -f bcb.mak</code> - <li><p>To enable SSL support in ACE+TAO you simply need to set the - <code>SSL_ROOT</code> environment variable to point to the - location of OpenSSL. For example: - <p><code>set SSL_ROOT=c:\openssl-0.9.6h</code> - </ol> - -<p> </p> -<p> </p> -</body> -</html> diff --git a/TAO/docs/Security/SSLIOP-USAGE.html b/TAO/docs/Security/SSLIOP-USAGE.html deleted file mode 100644 index 507ca49db6d..00000000000 --- a/TAO/docs/Security/SSLIOP-USAGE.html +++ /dev/null @@ -1,388 +0,0 @@ - -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO -- Using SSLIOP</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <h2>Using SSLIOP</h2> - <hr> - <ul> - <li><a href="#loading">Loading and Configuring the SSLIOP Pluggable Protocol</a></li> - <li><a href="#ssliop_current">Using the <code>SSLIOP::Current</code> Object</a></li> - </ul> - <hr> - <h3><a name="loading"></a>Loading and Configuring the SSLIOP Pluggable Protocol</h3> - <p>TAO implements SSL as a pluggable protocol. As such, it must be dynamically - loaded into the ORB. You must use a service configurator file to do this. - The service configurator options for the ORB are described in detail in <a href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/docs/components.html?rev=HEAD&content-type=text/html"> - Options for TAO Components</a>. In this case you have to create a <code>svc.conf</code> - file that includes: </p> - <pre> - dynamic SSLIOP_Factory Service_Object * - TAO_SSLIOP:_make_TAO_SSLIOP_Protocol_Factory() "" - static Resource_Factory "<font color="#009900">-ORBProtocolFactory SSLIOP_Factory</font>"</pre> - <p>Note that "<code>TAO_SSLIOP:_make...</code>" is part of the first - line. This will load the SSLIOP protocol from the library called <code>TAO_SSL</code> - and then use that protocol in the ORB. The SSLIOP protocol has a number of - configuration options that we describe below. </p> - <h4>SSLIOP Options</h4> - <p>Once the SSLIOP protocol is loaded you may want to setup the private key - and certificate files, the authentication level and similar features. This - is done by setting more options in the service configurator file, for example: - </p> - <pre>dynamic SSLIOP_Factory Service_Object * - TAO_SSLIOP:_make_TAO_SSLIOP_Protocol_Factory()"<font color="#009900">-SSLAuthenticate SERVER</font>"</pre> - <p>will enforce validation of the server certificate on each SSL connection. - Note that "<code>TAO_SSLIOP:_make...</code>" is part of the first - line. The complete list of options is: </p> - <p> - <table border="2" cellspacing="2" cellpadding="0" align="center" width="100%" > - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td><code>-SSLNoProtection</code></td> - <td> - <p>On the client side, this option forces request invocations to use the - standard insecure IIOP protocol.</p> - <p>On the server side, use of this option allows invocations on the server - to be made through the standard insecure IIOP protocol. Request invocations - through SSL may still be made.</p> - <p>This option will be deprecated once the <code>SecurityLevel2::SecurityManager</code> - interface as defined in the CORBA Security Service is implemented.</p> - </td> - </tr> - <tr> - <td><code>-SSLCertificate</code> <em>FORMAT:filename</em></td> - <td> Set the name of the file that contains the certificate for this process. - The file can be in Privacy Enhanced Mail (<code>PEM</code>) format or - ASN.1 (<code>ASN1</code>). Remember that the certificate must be signed - by a Certificate Authority recognized by the client. </td> - </tr> - <tr> - <td><code>-SSLPrivateKey</code> <em>FORMAT:filename</em></td> - <td> Set the name of the file that contains the private key for this process. - The private key and certificate files must match. It is extremely important - that you secure your private key! By default the <code>OpenSSL</code> - utilities will generate pass phrase protected private key files. The password - is prompted when you run the CORBA application. </td> - </tr> - <tr> - <td><code>-SSLAuthenticate</code> <em>which</em></td> - <td> Control the level of authentication. The argument can be <code>NONE</code>, - <code>SERVER</code>, <code>CLIENT</code> or <code>SERVER_AND_CLIENT</code>. - Due to limitations in the SSL protocol <code>CLIENT</code> implies that - the server is authenticated too. </td> - </tr> - <tr> - <td><code>-SSLAcceptTimeout</code> <em>which</em></td> - <td>Set the maximum amount of time to allow for establishing a - SSL/TLS passive connection, <em>i.e.</em> for accepting a - SSL/TLS connection. The default value is <code>10</code> - seconds. - <p>See the discussion in <a - href="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1348">Bug 1348</a> in our <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">bug - tracking system</a> for the rationale behind this option.</td> - </tr> - <tr> - <td><code>-SSLDHParams</code> <em>filename</em></td> - <td>Set the filename containing the Diffie-Hellman parameters to - be used when using DSS-based certificates. The specified - file may be a file containing only Diffie-Hellman - parameters created by "<code>openssl dhparam</code>", or - it can be a certificate containing a PEM encoded set of - Diffie-Hellman parameters.</td> - </tr> - - </table> - <h4>Environment variables</h4> - <p>The SSLIOP protocol uses the following environment variables to control its - behavior. </p> - <p> - <table border="2" cellspacing="2" cellpadding="0" width="100%" > - <tr> - <th>Environment Variable</th> - <th>Description</th> - </tr> - <tr> - <td><code>SSL_CERT_FILE</code> <em>filename</em></td> - <td> The name of the file that contains all the trusted certificate authority - self-signed certificates. By default it is set to the value of the <code>ACE_DEFAULT_SSL_CERT_FILE</code> - macro. </td> - </tr> - <tr> - <td><code>SSL_CERT_DIR</code> <em>directory</em></td> - <td> The name of the directory that contains all the trusted certificate - authority self-signed certificates. By default it is set to the value - of the <code>ACE_DEFAULT_SSL_CERT_DIR</code> macro. This directory must - be indexed using the OpenSSL format, i.e. each certificate is aliased - with the following link: - <pre> -$ ln -s cacert.pem `openssl x509 -noout -hash < cacert.pem`.0 -</pre> - Consult the documentation of your SSL implementation for more details. - </td> - <tr> - <td><code>SSL_EGD_FILE </code><em>filename</em></td> - <td>The name of the UNIX domain socket that the <a href="http://www.lothar.com/tech/crypto/">Entropy - Gathering Daemon (EGD)</a> is listening on.</td> - <tr> - <td><code>SSL_RAND_FILE </code><em>filename</em></td> - <td>The file that contains previously saved state from OpenSSL's pseudo-random - number generator.</td> - </table> - <hr> - <h3><a name="ssliop_current"></a>Using the <code>SSLIOP::Current</code> Object</h3> - <p></p> - <p>TAO's SSLIOP pluggable protocol allows an application to gain access to the - SSL session state for the current request. For example, it allows an application - to obtain the SSL peer certificate chain associated with the current request - so that the application can decide whether or not to reject the request. This - is achieved by invoking certain operations on the <code>SSLIOP::Current</code> - object. The interface for <code>SSLIOP::Current</code> object is:</p> - <p><code>module <b>SSLIOP</b> {</code></p> - <p><code><font color="#0000FF"># pragma prefix</font> "<font color="#009900">omg.org</font>"</code></p> - <blockquote> - <p><code> <font color="#FF0000">/// A <b>DER</b> encoded X.509 certificate.</font><br> - typedef sequence<octet> ASN_1_Cert;</code></p> - <p><code> <font color="#FF0000">/// A chain of <b>DER</b> encoded X.509 certificates. - The chain<br> - /// is actually a sequence. The sender's certificate is<br> - /// first, followed by any Certificate Authority<br> - /// certificates proceeding sequentially upward.</font><br> - typedef sequence<ASN_1_Cert> SSL_Cert;</code></p> - </blockquote> - <p><code> <font color="#FF0000">/// The following are TAO - extensions.</font><br> - <font color="#0000FF"># pragma prefix</font> "<font color="#009900">ssliop.tao</font>"</code></p> - <blockquote> - <p><code> <font color="#FF0000">/// The SSLIOP::Current interface provides - methods to<br> - /// gain access to the SSL session state for the current<br> - /// execution context.</font><br> - local interface <b>Current</b> : CORBA::Current {</code> </p> - <blockquote> - <p><code> <font color="#FF0000">/// Exception that indicates a SSLIOP::Current<br> - /// operation was invoked outside of an SSL<br> - /// session.</font><br> - exception NoContext {};</code></p> - <p><code> <font color="#FF0000">/// Return the certificate chain associated - with<br> - /// the current execution context. If no SSL<br> - /// session is being used for the request or<br> - /// upcall, then the NoContext exception is<br> - /// raised.</font><br> - SSL_Cert get_peer_certificate_chain ()<br> - raises - (N</code><code>oContext);</code></p> - </blockquote> - <p><code>};</code></p> - </blockquote> - <p><code> <font color="#0000FF"># pragma prefix</font> "<font color="#009900">omg.org</font>"</code></p> - <p><code>};</code></p> - <h4>Obtaining a Reference to the <code>SSLIOP::Current</code> Object</h4> - <p>A reference to the <code>SSLIOP::Current</code> object may be obtained using - the standard <code>CORBA::ORB::resolve_initial_references()</code> mechanism - with the argument <code>"<font color="#009900">SSLIOPCurrent</font>"</code>. - Here is an example:</p> - <blockquote> - <p><code>int argc = 0;</code></p> - <p><code>CORBA::ORB_var orb =<br> - CORBA::ORB_init (argc, "", "<font color="#009900">my_orb</font>");</code></p> - <p><code>CORBA::Object_var obj =<br> - orb->resolve_initial_references ("<font color="#009900">SSLIOPCurrent</font>");</code></p> - <p><code><b>SSLIOP</b>::<b>Current_var</b> ssliop =<br> - <b>SSLIOP</b>::<b>Current</b>::_narrow (obj.in ());</code></p> - </blockquote> - <h4>Examining the Peer Certificate for the Current Request Using <a href="http://www.openssl.org/">OpenSSL</a></h4> - <p>Once a reference to the <code>SSLIOP::Current</code> object has been retrieved, - the peer certificate for the current request may be obtained by invoking the - <code>SSLIOP::get_peer_certificate</code> method, as follows:</p> - <blockquote> - <p><code><font color="#FF0000">// This method can throw a <b>SSLIOP::Current::NoContext</b><br> - // exception if it is not invoked during a request being<br> - // performed over SSL.</font><br> - <b>SSLIOP::ASN_1_Cert_var</b> cert =<br> - ssliop->get_peer_certificate ();</code></p> - </blockquote> - <p>The retrieved X.509 peer certificate is in DER (a variant of ASN.1) format. - DER is the on-the-wire format used to transmit certificates between peers. - </p> - <p> OpenSSL can be used to examine the certificate. For example, to extract - and display the certificate issuer from the DER encoded X.509 certificate, - the following can be done:</p> - <blockquote> - <p><code><font color="#0000FF">#include</font> <<font color="#009900">openssl/x509.h</font>><br> - <font color="#0000FF">#include</font> <<font color="#009900">iostream</font>></code><code><br> - <font color="#FF0000">.<br> - .<br> - .</font> <br> - <font color="#FF0000">// Obtain the underlying buffer from the<br> - // SSLIOP::ASN_1_Cert.</font><br> - CORBA::Octet *der_cert = cert->get_buffer ();<br> - <br> - char buf[BUFSIZ];<br> - <br> - <font color="#FF0000">// Convert the DER encoded X.509 certificate into<br> - // OpenSSL's internal format.</font><br> - <b>X509</b> *peer = ::<b>d2i_X509</b> (0, &der_cert, cert->length ());<br> - <br> - ::<b>X509_NAME_oneline</b> (<br> - ::<b>X509_get_issuer_name</b> (peer),<br> - buf,<br> - BUFSIZ);<br> - <br> - std::cout << "<font color="#009900">Certificate issuer: </font>" - << buf << std::endl;<br> - <br> - ::<b>X509_free</b> (peer);</code></p> - </blockquote> - <p> </p> - <address></address> - <table width="100%" border="0"> - <tr> - <td> - <p><font face="Georgia, Times New Roman, Times, serif"><font face="Arial, Helvetica, sans-serif"><a href="mailto:ossama@dre.vanderbilt.edu">Ossama - Othman<br> - </a></font></font><font face="Georgia, Times New Roman, Times, serif"><a href="mailto:coryan@uci.edu"><font face="Arial, Helvetica, sans-serif">Carlos - O'Ryan</font></a><font face="Arial, Helvetica, sans-serif"> </font></font></p> - </td> - <td><a href="http://www.openssl.org/"><img src="images/openssl_button.gif" width="102" height="47" align="right" border="0"></a></td> - </tr> - </table> - <h2> </h2> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --> -</html> diff --git a/TAO/docs/Security/SSLIOP.html b/TAO/docs/Security/SSLIOP.html deleted file mode 100644 index d4f463a64a4..00000000000 --- a/TAO/docs/Security/SSLIOP.html +++ /dev/null @@ -1,163 +0,0 @@ -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO - SSLIOP</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <h2>SSLIOP: Secure Socket Layer Inter-ORB Protocol</h2> - <p>TAO provides an IIOP over SSL implementation called SSLIOP. SSLIOP can be - used to enforce integrity, confidentiality and secure invocation when issuing - client requests. Furthermore, it also provides the hooks by which X.509 certificate-based - request authorization can be implemented in application code.</p> - <ul> - <li><a href="SSLIOP-INSTALL.html">Installation Instructions</a></li> - <li><a href="SSLIOP-USAGE.html">Usage Instructions</a></li> - </ul> - <p></p> - <hr> - <address></address> - <table width="100%" border="0"> - <tr> - <td> - <p><font face="Georgia, Times New Roman, Times, serif"><a href="mailto:coryan@uci.edu"><font face="Arial, Helvetica, sans-serif">Carlos - O'Ryan</font></a><font face="Arial, Helvetica, sans-serif"><br> - <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> </font></font></p> - </td> - <td><a href="http://www.openssl.org/"><img src="images/openssl_button.gif" width="102" height="47" align="right" border="0"></a></td> - </tr> - </table> - <address></address> - <H3> </H3> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Security/Security_Service.html b/TAO/docs/Security/Security_Service.html deleted file mode 100644 index cf2e89c6eac..00000000000 --- a/TAO/docs/Security/Security_Service.html +++ /dev/null @@ -1,156 +0,0 @@ -<html> -<!-- $Id$ --> -`<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO - CORBA Security Service</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <h2>The <a href="http://www.omg.org/corba/sectrans.html#sec">CORBA Security - Service</a> in TAO</h2> - <p>The CORBA Security Service for TAO is currently under development. This web - page will be updated as parts of the CORBA Security Service are completed.</p> - <ul> - <li>An <code>SSLIOP::Current</code> object is now available as a TAO extension. - It allows applications to obtain the SSL session state associated with the - current request. This feature, provides a means for applications to perform - X.509 certificate-based request authorization, for example.</li> - <li>A request interceptor is now registered with the ORB when the SSLIOP pluggable - protocol is loaded. This interceptor enforces secure invocation.</li> - <li>TAO's <a href="Conformance.html">CORBA Security Service Conformance Statement</a> - is now available.</li> - <li>IIOP over SSL, as detailed in the CORBA Security Service, has been implemented - as a <a href="http://www.cs.wustl.edu/%7Eschmidt/ACE_wrappers/TAO/docs/releasenotes/index.html#pp">pluggable - protocol</a> for TAO called <a href="SSLIOP.html">SSLIOP</a>.</li> - </ul> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Security/Templates/TAO_Security.dwt b/TAO/docs/Security/Templates/TAO_Security.dwt deleted file mode 100644 index 50123af4c84..00000000000 --- a/TAO/docs/Security/Templates/TAO_Security.dwt +++ /dev/null @@ -1,138 +0,0 @@ -<html> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO -- CORBA Security</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('../fireworks/nav_bar_r02_c2_f3.gif','../fireworks/nav_bar_r02_c2_f2.gif','../fireworks/nav_bar_r04_c2_f3.gif','../fireworks/nav_bar_r04_c2_f2.gif','../fireworks/nav_bar_r04_c2_f4.gif','../fireworks/nav_bar_r06_c2_f3.gif','../fireworks/nav_bar_r06_c2_f2.gif','../fireworks/nav_bar_r06_c2_f4.gif','../fireworks/nav_bar_r08_c2_f3.gif','../fireworks/nav_bar_r08_c2_f2.gif','../fireworks/nav_bar_r08_c2_f4.gif','../fireworks/nav_bar_r10_c2_f3.gif','../fireworks/nav_bar_r10_c2_f2.gif','../fireworks/nav_bar_r10_c2_f4.gif','../fireworks/nav_bar_r12_c2_f3.gif','../fireworks/nav_bar_r12_c2_f2.gif','../fireworks/nav_bar_r12_c2_f4.gif','../fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="../images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <p>{Body}</p> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="../fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="../fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="../index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','../fireworks/nav_bar_r02_c2_f2.gif','../fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','../fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="../fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="../fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="../fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="../Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','../fireworks/nav_bar_r04_c2_f2.gif','../fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','../fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="../fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="../fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','../fireworks/nav_bar_r06_c2_f2.gif','../fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','../fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="../fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="../fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="../SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','../fireworks/nav_bar_r08_c2_f2.gif','../fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','../fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="../fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="../fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="../Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','../fireworks/nav_bar_r10_c2_f2.gif','../fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','../fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="../fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="../fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="../FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','../fireworks/nav_bar_r12_c2_f2.gif','../fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','../fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="../fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="../fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -</html> diff --git a/TAO/docs/Security/fireworks/h_bar.gif b/TAO/docs/Security/fireworks/h_bar.gif Binary files differdeleted file mode 100644 index 8078fd221ff..00000000000 --- a/TAO/docs/Security/fireworks/h_bar.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar.html b/TAO/docs/Security/fireworks/nav_bar.html deleted file mode 100644 index 63b1cfdd3cd..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar.html +++ /dev/null @@ -1,147 +0,0 @@ -<!--To put this html into an existing HTML document, you must copy the JavaScript and--> -<!--paste it in a specific location within the destination HTML document. You must then copy--> -<!--and paste the table in a different location.--> - -<html> -<!-- $Id$ --> -<head> -<title>nav_bar.gif</title> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<meta name="description" content="Fireworks Splice HTML"> -<!-- Fireworks 3.0 Dreamweaver 3.0 target. Created Thu Apr 20 14:19:43 GMT-0700 (Pacific Daylight Time) 2000 --> - -<script language="JavaScript"> -<!--hide this script from non-javascript-enabled browsers - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} -/* Functions that swaps down images. */ -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} - -/* Functions that handle preload. */ -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -// stop hiding --> -</script> - -</head> -<body bgcolor="#ffffff" onLoad="MM_preloadImages('nav_bar_r02_c2_f2.gif','nav_bar_r02_c2_f4.gif','nav_bar_r02_c2_f3.gif','nav_bar_r04_c2_f2.gif','nav_bar_r04_c2_f4.gif','nav_bar_r04_c2_f3.gif','nav_bar_r06_c2_f2.gif','nav_bar_r06_c2_f4.gif','nav_bar_r06_c2_f3.gif','nav_bar_r08_c2_f2.gif','nav_bar_r08_c2_f4.gif','nav_bar_r08_c2_f3.gif','nav_bar_r10_c2_f2.gif','nav_bar_r10_c2_f4.gif','nav_bar_r10_c2_f3.gif','nav_bar_r12_c2_f2.gif','nav_bar_r12_c2_f4.gif','nav_bar_r12_c2_f3.gif');"> - -<!--The following section is an HTML table which reassembles the sliced image in a browser.--> -<!--Copy the table section including the opening and closing table tags, and paste the data where--> -<!--you want the reassembled image to appear in the destination document. --> - -<!-------------------------- BEGIN COPYING THE HTML HERE ----------------------------> -<!-- Image with table --> -<table border="0" cellpadding="0" cellspacing="0" width="158"> -<!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> -<!-- Shim row, height 1. --> - <td><img src="shim.gif" width="9" height="1" border="0"></td> - <td><img src="shim.gif" width="141" height="1" border="0"></td> - <td><img src="shim.gif" width="8" height="1" border="0"></td> - <td><img src="shim.gif" width="1" height="1" border="0"></td> - </tr> - - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="shim.gif" width="1" height="35" border="0"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r02_c2','nav_bar_r02_c2_f2.gif','nav_bar_r02_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r02_c2','nav_bar_r02_c2_f3.gif',1);" ><img name="nav_bar_r02_c2" src="nav_bar_r02_c2.gif" width="141" height="36" border="0"></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="shim.gif" width="1" height="5" border="0"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r04_c2','nav_bar_r04_c2_f2.gif','nav_bar_r04_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r04_c2','nav_bar_r04_c2_f3.gif',1);" ><img name="nav_bar_r04_c2" src="nav_bar_r04_c2.gif" width="141" height="36" border="0"></a></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="shim.gif" width="1" height="5" border="0"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r06_c2','nav_bar_r06_c2_f2.gif','nav_bar_r06_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r06_c2','nav_bar_r06_c2_f3.gif',1);" ><img name="nav_bar_r06_c2" src="nav_bar_r06_c2.gif" width="141" height="36" border="0"></a></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="shim.gif" width="1" height="5" border="0"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r08_c2','nav_bar_r08_c2_f2.gif','nav_bar_r08_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r08_c2','nav_bar_r08_c2_f3.gif',1);" ><img name="nav_bar_r08_c2" src="nav_bar_r08_c2.gif" width="141" height="36" border="0"></a></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="shim.gif" width="1" height="5" border="0"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r10_c2','nav_bar_r10_c2_f2.gif','nav_bar_r10_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r10_c2','nav_bar_r10_c2_f3.gif',1);" ><img name="nav_bar_r10_c2" src="nav_bar_r10_c2.gif" width="141" height="36" border="0"></a></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="shim.gif" width="1" height="5" border="0"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="#" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','nav_bar_r12_c2','nav_bar_r12_c2_f2.gif','nav_bar_r12_c2_f4.gif',1);" onClick="MM_nbGroup('down','navbar1','nav_bar_r12_c2','nav_bar_r12_c2_f3.gif',1);" ><img name="nav_bar_r12_c2" src="nav_bar_r12_c2.gif" width="141" height="36" border="0"></a></td> - <td><img src="shim.gif" width="1" height="36" border="0"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="shim.gif" width="1" height="101" border="0"></td> - </tr> -<!-- This table was automatically created with Macromedia Fireworks 3.0 --> -<!-- http://www.macromedia.com --> - -</table> -<!--------------------------- STOP COPYING THE HTML HERE ---------------------------> - -</body> - -</html> diff --git a/TAO/docs/Security/fireworks/nav_bar_r01_c1.gif b/TAO/docs/Security/fireworks/nav_bar_r01_c1.gif Binary files differdeleted file mode 100644 index 853c2857b51..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r01_c1.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c1.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c1.gif Binary files differdeleted file mode 100644 index 5ed44d9e666..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c1.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c2.gif Binary files differdeleted file mode 100644 index afc3c70fa45..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c2_f2.gif Binary files differdeleted file mode 100644 index 2d705615ddd..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c2_f3.gif Binary files differdeleted file mode 100644 index 4bd8082622e..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c2_f4.gif Binary files differdeleted file mode 100644 index f392ae120a6..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r02_c3.gif b/TAO/docs/Security/fireworks/nav_bar_r02_c3.gif Binary files differdeleted file mode 100644 index eee60d66d84..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r02_c3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r03_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r03_c2.gif Binary files differdeleted file mode 100644 index 2791e773a8c..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r03_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r04_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r04_c2.gif Binary files differdeleted file mode 100644 index 2811741f120..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r04_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r04_c2_f2.gif Binary files differdeleted file mode 100644 index 087ce5257c9..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r04_c2_f3.gif Binary files differdeleted file mode 100644 index 5a496013a26..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r04_c2_f4.gif Binary files differdeleted file mode 100644 index 2f452c3e972..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r04_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r05_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r05_c2.gif Binary files differdeleted file mode 100644 index 71133b30045..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r05_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r06_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r06_c2.gif Binary files differdeleted file mode 100644 index 3f4b9f2a590..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r06_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r06_c2_f2.gif Binary files differdeleted file mode 100644 index a26748c3a79..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r06_c2_f3.gif Binary files differdeleted file mode 100644 index 637e6397fbd..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r06_c2_f4.gif Binary files differdeleted file mode 100644 index a118b1d786a..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r06_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r07_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r07_c2.gif Binary files differdeleted file mode 100644 index 985f12f0c5c..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r07_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r08_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r08_c2.gif Binary files differdeleted file mode 100644 index 4af0eab0fc5..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r08_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r08_c2_f2.gif Binary files differdeleted file mode 100644 index be384b456bf..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r08_c2_f3.gif Binary files differdeleted file mode 100644 index e1b3ab8a707..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r08_c2_f4.gif Binary files differdeleted file mode 100644 index 4762c2f0ab6..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r08_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r09_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r09_c2.gif Binary files differdeleted file mode 100644 index f39a156f5a1..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r09_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r10_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r10_c2.gif Binary files differdeleted file mode 100644 index c9781c68792..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r10_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r10_c2_f2.gif Binary files differdeleted file mode 100644 index cf2dd02017a..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r10_c2_f3.gif Binary files differdeleted file mode 100644 index fba1e4a1c17..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r10_c2_f4.gif Binary files differdeleted file mode 100644 index 4fd35dc87b5..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r10_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r11_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r11_c2.gif Binary files differdeleted file mode 100644 index 2615c06f7e1..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r11_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r12_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r12_c2.gif Binary files differdeleted file mode 100644 index 715c7a33ad8..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r12_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f2.gif b/TAO/docs/Security/fireworks/nav_bar_r12_c2_f2.gif Binary files differdeleted file mode 100644 index 4e23db992b1..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f3.gif b/TAO/docs/Security/fireworks/nav_bar_r12_c2_f3.gif Binary files differdeleted file mode 100644 index ad8dc0a7909..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f3.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f4.gif b/TAO/docs/Security/fireworks/nav_bar_r12_c2_f4.gif Binary files differdeleted file mode 100644 index 910471bfeed..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r12_c2_f4.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/nav_bar_r13_c2.gif b/TAO/docs/Security/fireworks/nav_bar_r13_c2.gif Binary files differdeleted file mode 100644 index 7256aff78d3..00000000000 --- a/TAO/docs/Security/fireworks/nav_bar_r13_c2.gif +++ /dev/null diff --git a/TAO/docs/Security/fireworks/shim.gif b/TAO/docs/Security/fireworks/shim.gif Binary files differdeleted file mode 100644 index fc2560981ee..00000000000 --- a/TAO/docs/Security/fireworks/shim.gif +++ /dev/null diff --git a/TAO/docs/Security/images/CORBA_Security.jpg b/TAO/docs/Security/images/CORBA_Security.jpg Binary files differdeleted file mode 100644 index cdf87071400..00000000000 --- a/TAO/docs/Security/images/CORBA_Security.jpg +++ /dev/null diff --git a/TAO/docs/Security/images/CORBA_Security.png b/TAO/docs/Security/images/CORBA_Security.png Binary files differdeleted file mode 100644 index 4bc640fbd15..00000000000 --- a/TAO/docs/Security/images/CORBA_Security.png +++ /dev/null diff --git a/TAO/docs/Security/images/openssl_button.gif b/TAO/docs/Security/images/openssl_button.gif Binary files differdeleted file mode 100644 index 3d3c90c9f84..00000000000 --- a/TAO/docs/Security/images/openssl_button.gif +++ /dev/null diff --git a/TAO/docs/Security/images/tao2.gif b/TAO/docs/Security/images/tao2.gif Binary files differdeleted file mode 100644 index 04dc94110e2..00000000000 --- a/TAO/docs/Security/images/tao2.gif +++ /dev/null diff --git a/TAO/docs/Security/index.html b/TAO/docs/Security/index.html deleted file mode 100644 index 776f15cfb27..00000000000 --- a/TAO/docs/Security/index.html +++ /dev/null @@ -1,152 +0,0 @@ -<html> -<!-- $Id$ --> -<!-- #BeginTemplate "/Templates/TAO_Security.dwt" --> -<head> -<!-- #BeginEditable "doctitle" --> -<title>TAO - CORBA Security</title> -<!-- #EndEditable --> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<script language="JavaScript"> -<!-- -function MM_preloadImages() { //v3.0 - var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array(); - var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++) - if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}} -} - -function MM_findObj(n, d) { //v3.0 - var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { - d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} - if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; - for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); return x; -} - -function MM_nbGroup(event, grpName) { //v3.0 - var i,img,nbArr,args=MM_nbGroup.arguments; - if (event == "init" && args.length > 2) { - if ((img = MM_findObj(args[2])) != null && !img.MM_init) { - img.MM_init = true; img.MM_up = args[3]; img.MM_dn = img.src; - if ((nbArr = document[grpName]) == null) nbArr = document[grpName] = new Array(); - nbArr[nbArr.length] = img; - for (i=4; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } - } else if (event == "over") { - document.MM_nbOver = nbArr = new Array(); - for (i=1; i < args.length-1; i+=3) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = (img.MM_dn && args[i+2]) ? args[i+2] : args[i+1]; - nbArr[nbArr.length] = img; - } - } else if (event == "out" ) { - for (i=0; i < document.MM_nbOver.length; i++) { - img = document.MM_nbOver[i]; img.src = (img.MM_dn) ? img.MM_dn : img.MM_up; } - } else if (event == "down") { - if ((nbArr = document[grpName]) != null) - for (i=0; i < nbArr.length; i++) { img=nbArr[i]; img.src = img.MM_up; img.MM_dn = 0; } - document[grpName] = nbArr = new Array(); - for (i=2; i < args.length-1; i+=2) if ((img = MM_findObj(args[i])) != null) { - if (!img.MM_up) img.MM_up = img.src; - img.src = img.MM_dn = args[i+1]; - nbArr[nbArr.length] = img; - } } -} -//--> -</script> -</head> - -<body bgcolor="#FFFFFF" onLoad="MM_preloadImages('fireworks/nav_bar_r02_c2_f3.gif','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r04_c2_f3.gif','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif','fireworks/nav_bar_r06_c2_f3.gif','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif','fireworks/nav_bar_r08_c2_f3.gif','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif','fireworks/nav_bar_r10_c2_f3.gif','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif','fireworks/nav_bar_r12_c2_f3.gif','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif','fireworks/nav_bar_r02_c2_f4.gif')"> -<div id="Layer2" style="position:absolute; left:89px; top:32px; width:792px; height:125px; z-index:2"> - <h1 align="center"><img src="images/CORBA_Security.jpg" width="500" height="131" align="middle"></h1> -</div> -<div id="Layer3" style="position:absolute; left:257px; top:199px; width:625px; height:1px; z-index:3"><!-- #BeginEditable "Body" --> - <p>Welcome to the <a href="http://www.cs.wustl.edu/%7Eschmidt/TAO.html">TAO</a> - CORBA Security web site!</p> - <p>Information about TAO's CORBA Security Service implementation is available - on this site.</p> - <ul> - <li>TAO's SSLIOP pluggable protocol has gone through a series updates that - make it more robust, including the addition of a secure invocation request - interceptor and the <code>SSLIOP::Current</code> TAO extension.</li> - <li>A <a href="Conformance.html">CORBA Security Service Conformance Statement</a> - has been added.</li> - <li>TAO's CORBA Security Service is now distributed with the main TAO distribution.</li> - </ul> - <p> </p> - <!-- #EndEditable --></div> -<div id="Layer1" style="position:absolute; left:87px; top:162px; width:153px; height:373px; z-index:4"><!-- Image with table --> - <table border="0" cellpadding="0" cellspacing="0" width="158"> - <!-- fwtable fwsrc="Untitled" fwbase="nav_bar.gif" --> - <tr> <!-- Shim row, height 1. --> - <td><img src="/fireworks/shim.gif" width="9" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="141" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="8" height="1" border="0" name="undefined_2"></td> - <td><img src="/fireworks/shim.gif" width="1" height="1" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 1 --> - <td colspan="3"><img name="nav_bar_r01_c1" src="fireworks/nav_bar_r01_c1.gif" width="158" height="35" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="35" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 2 --> - <td rowspan="12"><img name="nav_bar_r02_c1" src="fireworks/nav_bar_r02_c1.gif" width="9" height="342" border="0"></td> - <td><a href="index.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Home','fireworks/nav_bar_r02_c2_f2.gif','fireworks/nav_bar_r02_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Home','fireworks/nav_bar_r02_c2_f3.gif',1)" ><img name="Home" src="fireworks/nav_bar_r02_c2.gif" border="0" onLoad=""></a></td> - <td rowspan="12"><img name="nav_bar_r02_c3" src="fireworks/nav_bar_r02_c3.gif" width="8" height="342" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 3 --> - <td><img name="nav_bar_r03_c2" src="fireworks/nav_bar_r03_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 4 --> - <td><a href="Download.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Download','fireworks/nav_bar_r04_c2_f2.gif','fireworks/nav_bar_r04_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Download','fireworks/nav_bar_r04_c2_f3.gif',1)" ><img name="Download" src="fireworks/nav_bar_r04_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 5 --> - <td><img name="nav_bar_r05_c2" src="fireworks/nav_bar_r05_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 6 --> - <td><a href="http://www.cs.wustl.edu/~schmidt/TAO.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','TAO','fireworks/nav_bar_r06_c2_f2.gif','fireworks/nav_bar_r06_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','TAO','fireworks/nav_bar_r06_c2_f3.gif',1)" ><img name="TAO" src="fireworks/nav_bar_r06_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 7 --> - <td><img name="nav_bar_r07_c2" src="fireworks/nav_bar_r07_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 8 --> - <td><a href="SSLIOP.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','SSLIOP','fireworks/nav_bar_r08_c2_f2.gif','fireworks/nav_bar_r08_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','SSLIOP','fireworks/nav_bar_r08_c2_f3.gif',1)" ><img name="SSLIOP" src="fireworks/nav_bar_r08_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 9 --> - <td><img name="nav_bar_r09_c2" src="fireworks/nav_bar_r09_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 10 --> - <td><a href="Security_Service.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','Security_Service','fireworks/nav_bar_r10_c2_f2.gif','fireworks/nav_bar_r10_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','Security_Service','fireworks/nav_bar_r10_c2_f3.gif',1)" ><img name="Security_Service" src="fireworks/nav_bar_r10_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 11 --> - <td><img name="nav_bar_r11_c2" src="fireworks/nav_bar_r11_c2.gif" width="141" height="5" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="5" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 12 --> - <td><a href="FAQ.html" onMouseOut="MM_nbGroup('out');" onMouseOver="MM_nbGroup('over','FAQ','fireworks/nav_bar_r12_c2_f2.gif','fireworks/nav_bar_r12_c2_f4.gif',1)" onClick="MM_nbGroup('down','navbar1','FAQ','fireworks/nav_bar_r12_c2_f3.gif',1)" ><img name="FAQ" src="fireworks/nav_bar_r12_c2.gif" width="141" height="36" border="0" onLoad=""></a></td> - <td><img src="/fireworks/shim.gif" width="1" height="36" border="0" name="undefined_2"></td> - </tr> - <tr valign="top"><!-- row 13 --> - <td><img name="nav_bar_r13_c2" src="fireworks/nav_bar_r13_c2.gif" width="141" height="101" border="0"></td> - <td><img src="/fireworks/shim.gif" width="1" height="101" border="0" name="undefined_2"></td> - </tr> - <!-- This table was automatically created with Macromedia Fireworks 3.0 --> - <!-- http://www.macromedia.com --> - </table> -</div> -<table border="0" cellpadding="0" cellspacing="0"> - <tr> - <td> </td> - </tr> -</table> -</body> -<!-- #EndTemplate --></html> diff --git a/TAO/docs/Smart_Proxies.html b/TAO/docs/Smart_Proxies.html deleted file mode 100644 index c29a03ac88f..00000000000 --- a/TAO/docs/Smart_Proxies.html +++ /dev/null @@ -1,423 +0,0 @@ -<!-- $Id$--> -<HTML> -<TITLE>Smart Proxies</TITLE> -<BODY> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<Hr><P> -<H3>Smart Proxies</H3> - -<P>Smart Proxies are a meta-programming extension supported by TAO -that provides user-defined proxy classes. By default TAO's IDL -compiler generates proxy classes for IDL interfaces. The proxy is an -exact image of the target object on whom the invocations are to be -made by the client, i.e., it has the same methods as the targeting -interface. A proxy packages the request which gets marshalled and -sent to the target object. A paper that describes TAO's <A -HREF="interceptors.html">portable interceptor</A> and smart proxy -support is available <A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/smart_proxies.pdf">online</A>.</p></p> - -<Hr><P> -<h3><a name="toc">Table of Contents</a></h3> -<ul> - <li><a href="#Examples">Examples</a> - <li><a href="#Design Issues">Design Issues</a> - <li><a href="#Design Overview">Design Overview</a> - <li><a href="#Inheritance">Inheritance Issues</a> - <li><a href="#Implementation Issues">Implementation Issues</a> - <li><a href="#Options">Usage Options</a> - <li><a href="#Acknowledgements">Acknowledgements</a> - <li><a href="#ref">References</a> -</ul> - -<Hr><P> -<h3><a name="Examples">Examples</a></h3> - -<P>The user may wish to manually change the proxy code for the following -reasons: - -<UL> <LI> Cache information about the remote object locally to save -the expense of going across the wire for every request. <P> - -<LI> Batch updates/accesses to the remote object. -<p>For instance:<br> -Consider a remote Database which has an API which can update either a -single record or 10 records at one shot. To leverage performance, one -would want to use this method. So a user can use the smart proxy to -implement the 10 record update method by caching single record update -requests.</p> - -<P>It is not certain whether this usecase might not induce extra -overhead and whether the proxy can be smart enough to deduce the use -of this kind of batch processing. Also, this scheme wont work for -two-way calls.The "cached-oneways" feature might make more sense in -this scenario. Thus the application programmer will have to determine -how this caching optimization changes the semantics of the original -interface.</p> - -<LI> The client can make a single request which results in a sequence -of invocations to one or possibly more objects. - -<p> For instance:<br> -The smart stub has some private methods (since this is user specific -this should be possible) which do validation of the request to be -made. The remote call could result in another call wherein the -validation occurs before it is shoved over the wire.</p> - -<LI> Quality of Service features like load-balancing can be considered -by the smart proxy before making the invocation on the appropriate -target object.</p> -</UL> - -<Hr><P> -<h3><a name="Design Issues">Design Issues</a></h3> - -<UL> -<LI> How will the smart proxy be created? -<LI> Who will create the smart proxy? -<LI> It has to be done before the invocations on the target object are -done, so when will it get created? -<LI> What about collocation? Will those stubs fall under this category? -<LI> Will smart proxies work for collocated object references? -</UL> - -<h3>Design Needs and discussion points</h3> - -<P>A ProxyFactory (either default or user-defined) is needed which -will create the stubs (either default or smart). This factory should -be able to create different kinds of proxies.</p> - -<P>The <code>unchecked_narrow</code> method needs to return the -appropriate stub.</p> - -<P>Collocated stubs need to be handled too. This means that smart -proxies need to be generated for collocated object references too.</p> - -<P>An existing function for creating stubs has to replaced by a class -which will handle all cases viz. default stubs, smart stubs (proxies), -collcated stubs.</p> - -<h2><a name="Design Overview">Design Overview</a></h2> - -<P>At a glance:</p> - -<P>Classses to be generated by TAO_IDL in addition to the Default -Stub:</p> - -<UL> -<LI> <CODE>TAO_Proxy_Factory_Adapter</CODE> -<p>The singleton which has the different proxies (stubs) factories -registered with it.</p> - -<LI> <CODE>TAO_Test_Default_Proxy_Factory</CODE> -<p>The factory which returns the proxy_ptr which is used in the -<code>unchecked_narow</code> method to create the appropriate proxy -object. - -<LI> <CODE>TAO_Smart_Proxy_Base</CODE> -<p>The smart proxy interface which makes it easier for the -user to simply implement only the methods he wishes to change and also -provides a <br>common interface to address remote as well as collocated -stubs.</p> -</UL> - -<P>Classes to be defined by the user:</p> - -<UL> -<LI> <CODE>SmartFactory</CODE> - inherits from TAO_Default_Proxy_Factory class. -<p>The factory which will create the smart proxy which the -user wants. Its necessary that an object of this class is created.</p> - -<LI> <CODE>SmartProxy</CODE> - derivative of the TAO_Smart_Proxy_Base class. -<p>The proxy which has the user desired extra functionality.</p> - -<P>*Note: Names are as they are to make it easier to comprehend the -concept.</p> -</UL> - -<Hr><P> -<h3>Detailed Example</h3> - -<pre> -//------------------------ Generated by TAO_IDL------------------------ - -class TAO_Proxy_Factory_Adapter -{ - // DESCRIPTION: - // Behaves like a singleton and contains the - // factory object which is used to create the - // default/smart Proxys. -public: - - friend class ACE_Singleton<TAO_Proxy_Factory_Adapter, TAO_SYNCH_RECURSIVE_MUTEX>; - - // Register the factory with the Adaptor. - register_proxy (TAO_Default_Proxy_Factory *df) - { - Perform Double-Checked Locking Optimisation... - - // If there is a factory already existing, replace it. - this->unregister_proxy_factory (); - this->proxy_factory_ = df; - this->delete_proxy_factory_ = 0; - } - - // Remove the factory. - unregister_proxy_factory (void) - { - Perform Locking to ensure exclusive access. - if (this->delete_proxy_factory_ == 0 && this->proxy_factory_ != 0) - { - // Its necessary to set <delete_proxy_factory_> to 1 to make sure that it - // doesnt get into an infinite loop in <unregister_proxy_factory> as it is - // invoked in the destructor of the class too. - this->delete_proxy_factory_ = 1; - delete this->proxy_factory_; - this->proxy_factory_ = 0; - } - } - - // Delegation of the Proxy creation to the factory - interface_ptr create_proxy (void) - { - Verify that an <proxy_factory_> is available else make one. - - return this->factory_->create_proxy (); - } - -protected: - - TAO_Test_Default_Proxy_Factory *proxy_factory_; - int delete_proxy_factory_; - TAO_SYNCH_RECURSIVE_MUTEX lock_; - -}; - -// This class will also be generated by TAO_IDL. -class TAO_Default_Proxy_Factory -{ - // DESCRIPTION: - // This class is the parent for the different Proxy factories. The - // Proxy could either be collocated or remote and hence here only - // the Proxy pointer is returned which will be created on invocation of - // <unchecked_narrow>. - -public: - TAO_Default_Proxy_Factory (int register_proxy_factory); - { - // Unless told don't register. By default registration is done. - // This comes in handy while creating the TAO_Proxy_Factory_Adapter - // instance since we want either the user to set the factory. Only - // if that doesnt happen will the TAO_Default_Proxy_Factory be set - // to the factory delegated by the Adapter and that is done using - // the Lazy Evaluation Principle when the first call to <create_proxy> - // is done. - - if (register_proxy_factory) - { - TAO_PROXY_FACTORY_ADAPTER::instance ()->register_proxy_factory (this); - } - } - - ~TAO_Default_Proxy_Factory (void) - { - } - - // By default the proxy is simply returned. - interface_ptr create_proxy (interface_ptr proxy) - { - return proxy; - } - -}; - -// This class will be generated by the TAO_IDL. -class TAO_Smart_Proxy_Base : public virtual DefaultProxyInterface -{ - // DESCRIPTION: - // This class is the class from which the user will inherit - // and simply override the methods he requires. This extra - // level of indirection is necessary to be able to provide - // the smartProxy interface for even collocated Proxies. -public: - - // The delegation to which underlying proxy is decided here. - TAO_Smart_Proxy_Base (interface_ptr proxy) - : base_proxy_ (proxy) - - // Interface operations... - int method () - { - this->proxy_->method (); - } - ... - // @@ How are exceptions handled? - // This not an issue really because the actual method call is simply - // to the application level which is catch it as the exception is - // propogated upwards from the proxy level. - -protected: - // This var member denotes the kind of proxy used: - // collacated-thru_poa, collocated-direct, or remote. - // This is decided by the collocated strategy used along - // with the smart Proxies. Note: the collocated Proxies - // themselves are smart proxies. The proxy pointer passed - // thru the constructor will be assigned to <proxy_>. The - // pointer will actually point to the smart proxy in case - // of smart proxies or else to the default proxy. - DefaultProxyInterface_var base_proxy_; - -}; - -// ----------------- User Implementation Begins here---------------- - -// Note: This has to be implemented by the user -class SmartFactory : public TAO_Default_Proxy_Factory -{ - // DESCRIPTION: - // An object of this class has to be defined by the user - // which will cause it to be registered with the - // ProxyFactoryAdaptor. -public: - - Smartinterface_ptr create_proxy (interface_ptr proxy) - { - return (!CORBA::is_nil (proxy) ? new SmartProxy (proxy) : proxy); - } -}; - -// This class will be implemented by the user. -class VerySmartProxy : public TAO_Smart_Proxy_Base -{ - // DESCRIPTION: - // This is the smart Proxy will is defined by the user - // to suit his needs. - int method () - { - print "Yahoo, I am so smart" - this->proxy_->method (); - } - -} - -// --------------------Related Stub Changes------------------ - - -// Generated by TAO_IDL. Note the changes wherein the -// TAO_Proxy_Factory_Adapter is used. - -interface_ptr _unchecked_narrow (CORBA::Object obj, - CORBA::Environment &) -{ - if (CORBA::is_nil (obj)) - return test::_nil (); - TAO_Proxy* Proxy = obj->_stubobj (); - stub->_incr_refcnt (); - interface_ptr *default_proxy = interface::_nil (); - - if (obj->_is_collocated () && _TAO_collocation_interface_Stub_Factory_function_pointer != 0) - { - default_proxy = - _TAO_collocation_interface_Stub_Factory_function_pointer (obj); - } - - if (CORBA::is_nil (default_proxy)) - ACE_NEW_RETURN (default_proxy, interface (stub), test::_nil ()); - - return TAO_PROXY_FACTORY_ADAPTER::instance ()->create_proxy (default_proxy); - } -} -</pre> - -<Hr><P> -<h3><a name="Inheritance">Inheritance Issues</a></h3> -<p>The original implementation of the Smart Proxies was cumbersome -since when a smart proxy inherited from another the constructor -explicitly had to call the constructor of the base class of the other -proxy. To get over this issue, implementation inheritance was applied -by <a href="mailto:brian.wallis@ot.com.au">Brian Wallis</a> where -there is a higher level Smart_Proxy_Base which stores the -<CODE> base_proxy_ </CODE> member. This implementation was influenced -by a similar implementation in Orbix. Thanks to Brian Wallis for this -wonderful contribution to Smart Proxies in TAO. - -<p>This design was modified slightly and now every interface smart -proxy base class holds a <CODE> proxy_ </CODE> member which is the -narrowed version of the <CODE> base_proxy_ </CODE>. This way every call -neednt have to go through the narrowing process as the -<CODE>base_proxy_</CODE> is stored as a CORBA_Object_var while we need -the interface pointer to make the desired invocations. - -<Hr><P> -<h3><a name="Implementation Issues">Implementation Issues</a></h3> - -<UL> -<LI> Native exceptions? How are these to be handled?</p> -<p> This not an issue really because the actual method call is simply -to the application level which will catch it as the exception is -propogated upwards from the proxy level.</p> - -<LI> What if the user wants to have a smart proxy which inherits from -many interfaces? -<p> First have different smart proxies which inherit from the -TAO_Smart_Proxy_Base (every default smart proxy is for an interface) and -then have a new smart proxy inheriting from the previously created -smart proxies. But remember: the SmartProxyFactory should create the -final smart proxy thru its create_proxy () method.</p> - -<LI> Do I need to create a Smart Proxy Factory every time I use a -smart proxy? -<p> Yes, you do. Once the Smart Proxy Factory is created, it is -automatically used to create the proxy and thus a smart proxy is -obtained instead of the default one. When the smart proxy makes its -first invocation, this factory is unregistered. So all the proxies -created from then on will be the default one. -</UL> - -<Hr><P> -<h3><a name="Options">Usage Options</a></h3> -<p> To use this feature in TAO, one must do the following: -(1) Generate smart proxy classes using the IDL compiler option of --Gsp and (2) Link client and server to the TAO_SmartProxies library, in -$ACE_ROOT/TAO/tao/SmartProxies. -A new smart proxy option has been added to the design: one-shot or -permanent versus per-object smart proxy. The one-shot smart proxy -option denotes that the smart proxy factory is registered permanently -and so for all object instances the same kind of proxy is used. On -disabling this default option one can achieve the use of different -smart proxies for every object instead of every interface. -For details please see the paper on -<a href="http://www.cs.wustl.edu/~schmidt/PDF/COOTS-00.pdf"> -Meta-programming Mechanisms for ORB Middleware as well as the test at -$TAO_ROOT/tests/Smart_Proxies/Policy. - -<Hr><P> -<h3><a name="Acknowledgements">Acknowledgements</a></h3> - -<P><a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a> and <a -href="mailto:schmidt@cs.wustl.edu">Dr.Schmidt</a> for their help in -designing and discussing this feature. <P> - -<P><a href="mailto:brian.wallis@ot.com.au">Brian Wallis</a> for -contributing the implementation inheritance feature. - -<Hr><P> -<h3><a name="ref">References</a></h3> - -<p> CORBA Distributed Objects using Orbix - Sean Baker </p> -<p> Visigenic Documentation </p> -<p> Orbix Documentation </p> - -<Hr><P> -<p><h3>Last Update</h3></3> - -<p> Date: 02Jul2001</p> -<p> By: <a href="mailto:parsons@cs.wustl.edu">Jeff Parsons</a></p> - -</BODY> -</HTML> diff --git a/TAO/docs/TAO-metrics.html b/TAO/docs/TAO-metrics.html deleted file mode 100644 index d35912ae7f9..00000000000 --- a/TAO/docs/TAO-metrics.html +++ /dev/null @@ -1,46 +0,0 @@ -<!-- $Id$--> -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<TITLE>TAO-metrics</TITLE> -<BODY> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR> -<H3> TAO (ACE ORB) Performance Metrics</H3> - -<A HREf="http://www.dre.vanderbilt.edu/TAO">TAO</A>'s -efficiency, scalability, and predictability have been measured on many -different real-time operating systems with different features. Here -are some pointers to obtain more information on the evaluation and -benchmarking of TAO. - -<OL> -<LI> <A - HREF="http://www.cs.wustl.edu/~schmidt/PDF/RT-OS.pdf">TAO's - performance on different real-time operating systems</A> -<LI> <A - HREF="http://www.cs.wustl.edu/~schmidt/PDF/words-02.pdf">More real-time operating system performance measurements for TAO</A> - -<LI> <A -<LI> <A HREF="http://cs.wustl.edu/~schmidt/PDF/COOTS-99.pdf">TAO's Demultiplexing Latency</A> -<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/PDF/JSAC-99.pdf">TAO's IIOP performance</A> -<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/PDF/ami2.pdf">TAO's AMI performance</A> -<LI> <A HREF="http://www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf">TAO's - pluggable protocols performance</A> -<LI> <A HREF="../../docs/ACE-subsets.html">Subsetting of ACE and minimum TAO</A> -<LI> Current and past performance and footprint metrics are available - from our <A HREF="http://www.dre.vanderbilt.edu/Stats/">nightly builds -</A>. -</LI> -</OL> - -Many other <A -HREF="http://www.cs.wustl.edu/~schmidt/corba-research.html">papers</A> -on TAO's performance and design are also available online. <P> - -</BODY> -</HTML> diff --git a/TAO/docs/TAO-tutorials.html b/TAO/docs/TAO-tutorials.html deleted file mode 100644 index 2b680c10fba..00000000000 --- a/TAO/docs/TAO-tutorials.html +++ /dev/null @@ -1,41 +0,0 @@ - <!-- $Id$ --> -<html> <head> -<title><HTML> - <TITLE>CORBA and TAO Beginners' Guide</TITLE> - <BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> - - <HR><P> - <H3>The Beginners' Guide to CORBA and TAO Programming</H3> - - The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">TAO - development team</A> is creating a set of tutorials to help TAO - newcomers learn how to use the ORB effectively. The following - links provide further information on this topic. - - <DL> - <DL> -<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <A -HREF="tutorials/Quoter/">Quoter - tutorial</A> <P> - -<DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> There -are several <A HREF="http://www.theaceorb.com/downloads/1.4a/index.html">documents</A> from <A -HREF="http://www.theaceorb.com/">OCI</A>'s <A -HREF="http://www.theaceorb.com/product/">TAO -Developer's Guide</A> that describe the process of building and running a simple client and - server using TAO and MPC. <P> - - <DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> -Additional tutorials are available in the <A -HREF="http://www.theaceorb.com/product/">TAO -Developer's Guide</A> available from <A -HREF="http://www.theaceorb.com/">OCI</A>. <P> - - </DL> - - <HR><P> - Back to the <A HREF="index.html">TAO documents</A> page. - - <!--#include virtual="/~schmidt/cgi-sig.html" --> - </BODY> -</HTML> diff --git a/TAO/docs/Tags.html b/TAO/docs/Tags.html deleted file mode 100644 index 5b073b1981c..00000000000 --- a/TAO/docs/Tags.html +++ /dev/null @@ -1,231 +0,0 @@ -<HTML> -<HEAD> - <!-- $Id$ --> - <TITLE>Tags used in TAO</TITLE> -</HEAD> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - - <HR><P><H3 ALIGN=CENTER>Tags used in TAO</H3></P> - - <H3>Overview</H3> - - <P>The <A HREF="http://www.omg.org/library/c2indx.html">CORBA</A> - specification defines several tags, a.k.a. <EM>magic numbers</EM>, - to distinguish between several otherwise opaque entities. - For example, - all profiles are transmitted as a CDR encapsulation (a sequence - of octets), - using a tag the type of the profile can be determined and the - encapsulation can be properly interpreted. - </P> - <P>To ensure that the tags uniquely indentify the entities in each - namespace the <A HREF="http://www.omg.org/">OMG</A> acts as an - <EM>allocation authority</EM>, - keeps a registry of the tags allocated so far and assigning the - new tag values on demand. - The process to request a tag is very simple, - interested readers can consult - <A HREF="http://www.omg.org/cgi-bin/doc?ptc/99-02-01">this - link</A> - for more details - </P> - - <P>We have reserved several tags for TAO, this page documents - those tags and how they are used, some details are subject to - change. We recommend that interested readers check the - <A HREF="releasenotes/releasenotes.html">release notes</A> - </P> - - <H3>List of TAGS</H3> - - <H4>ORB Type ID</H4> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Hex Value</TH><TH>ASCII Representation</TH> - <TH>Description</TH></TR> - <TR> - <TD>0x54414f00</TD><TD>"TAO\0x00"</TD><TD>IIOP profiles - contain a component list. One of the elements of this - list (the <CODE>IOP::TAG_ORB_TYPE</CODE>) contains a - identifier for the ORB that created the profile. - </TD> - </TR> - </TABLE></P> - - <H4>IOR Profile IDs</H4> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Hex Value</TH><TH>ASCII Representation</TH> - <TH>Description</TH></TR> - <TR> - <TD>0x54414f00</TD><TD>"TAO\0x00"</TD><TD>A TAO local IPC (aka - Unix domain) profile. - </TD> - </TR> - </TABLE></P> - - <P>The range <CODE>0x54414f01-0x54414f0f</CODE> - (<CODE>"TAO\0x01"-"TAO\0x0f"</CODE>) is reserved for future use. - Only for informational purposes we include the following list - of potential uses: - </P> - - <P><TABLE> - <TR><TH>Hex Value</TH><TH>ASCII Representation</TH> - <TH>Description</TH></TR> - <TR> - <TD>0x54414f01</TD><TD>"TAO\0x01"</TD> - <TD>GIOP over ATM/AAL5</TD> - </TR> - <TR> - <TD>0x54414f02</TD><TD>"TAO\0x02"</TD> - <TD>Shared memory transport</TD> - </TR> - <TR> - <TD>0x54414f03</TD><TD>"TAO\0x03"</TD> - <TD>Message queue</TD> - </TR> - <TR> - <TD>0x54414f04</TD><TD>"TAO\0x04"</TD> - <TD>UDP</TD> - </TR> - <TR> - <TD>0x54414f05</TD><TD>"TAO\0x05"</TD> - <TD>IP multicast</TD> - </TR> - <TR> - <TD>0x54414f06</TD><TD>"TAO\0x06"</TD> - <TD>Compact PCI bus</TD> - </TR> - <TR> - <TD>0x54414f07</TD><TD>"TAO\0x07"</TD> - <TD>VME bus</TD> - </TR> - <TR> - <TD>0x54414f08</TD><TD>"TAO\0x08"</TD> - <TD>NT named pipes</TD> - </TR> - <TR> - <TD>0x54414f09</TD><TD>"TAO\0x09"</TD> - <TD>HTTP-NG</TD> - </TR> - <TR> - <TD>0x54414f0A</TD><TD>"TAO\0x0A"</TD> - <TD>Pipes (for collocated calls)</TD> - </TR> - </TABLE></P> - - <H4>Service Context ID</H4> - - <P>The range <CODE>0x54414f00-0x54414f0f</CODE> - (<CODE>"TAO\0x00"-"TAO\0x0f"</CODE>) is reserved for future - use. - </P> - - <H4>Component IDs</H4> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Hex Value</TH><TH>ASCII Representation</TH> - <TH>Description</TH></TR> - <TR> - <TD>0x54414f00</TD><TD>"TAO\0x00"</TD> - <TD>Server side priority for the endpoint in this profile. - The component is encoded a two shorts, the minimum and - maximum priorities (in that order). - The values correspond to the CORBA priorities defined in the - real-time CORBA spec. - The client will select the endpoint that matches its - priorities and policies. - </TD> - </TR> - </TABLE></P> - - <P>The range <CODE>0x54414f01-0x54414f0f</CODE> - (<CODE>"TAO\0x00"-"TAO\0x0f"</CODE>) is reserved for future - use. - </P> - - <H4>Vendor Minor Code ID (VMCID)</H4> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Hex Value</TH><TH>ASCII Representation</TH> - <TH>Description</TH></TR> - <TR> - <TD>0x54410000</TD><TD>"TA\x00x00"</TD> - <TD>System exceptions thrown by TAO have their higher 20 bits - set to <CODE>0x54410</CODE>, - the other 12 bits are used to describe more precisely the - cause of the exception. - The lower 4 bits encode the errno that caused the exception, - the 8 intermediate bits encode the location where the - exception was raised. - </TD> - </TR> - </TABLE></P> - - <P>The following list describes the current use of errno and - location encodings:</P> - - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Errno Value</TH><TH>Description</TH></TR> - <TR> - <TD>0x00</TD><TD>The error was not caused by a failed system - call</TD> - </TR> - <TR><TD>0x01</TD><TD>ETIMEDTOUT</TD></TR> - <TR><TD>0x02</TD><TD>ENFILE</TD></TR> - <TR><TD>0x03</TD><TD>EMFILE</TD></TR> - <TR><TD>0x04</TD><TD>EPIPE</TD></TR> - <TR><TD>0x05</TD><TD>ECONNREFUSED</TD></TR> - <TR><TD>0x06</TD><TD>ENOENT</TD></TR> - <TR><TD>0x07</TD><TD>EBADF</TD></TR> - <TR><TD>0x08</TD><TD>ENOSYS</TD></TR> - <TR><TD>0x09</TD><TD>EPERM</TD></TR> - <TR><TD>0x0A</TD><TD>EAFNOSUPPORT</TD></TR> - </TABLE></P> - - <P>Please consult the documentation for your OS for more details - about the errno meanings</P> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0" > - <TR><TH>Location encoding</TH><TH>Description</TH></TR> - <TR><TD>0x01</TD> - <TD>Connect failed</TD></TR> - <TR><TD>0x02</TD> - <TD>Location forward failed</TD></TR> - <TR><TD>0x03</TD> - <TD>Send request failed</TD></TR> - <TR><TD>0x04</TD> - <TD>POA in discarding state</TD></TR> - <TR><TD>0x05</TD> - <TD>POA in holding state</TD></TR> - <TR><TD>0x06</TD> - <TD>Unhandled C++ exception in server side</TD></TR> - <TR><TD>0x07</TD> - <TD>Failure while reading the reply</TD></TR> - <TR><TD>0x08</TD> - <TD>All protocols failed to parse the IOR</TD></TR> - <TR><TD>0x09</TD> - <TD>Attempt to use null pointer</TD></TR> - <TR><TD>0x0A</TD> - <TD>Error during MProfile creation</TD></TR> - <TR><TD>0x0B</TD> - <TD>Timeout while trying to establish the connection</TD></TR> - <TR><TD>0x0C</TD> - <TD>Timeout while sending the request</TD></TR> - <TR><TD>0x0D</TD> - <TD>Timeout while waiting for the reply</TD></TR> - </TABLE></P> - - <P><HR></P> - - Back to the TAO <A HREF="index.html">documentation</A>. - - <!--#include virtual="/~schmidt/cgi-sig.html" --> - </BODY> -</HTML> diff --git a/TAO/docs/cec_options.html b/TAO/docs/cec_options.html deleted file mode 100644 index a1109db123d..00000000000 --- a/TAO/docs/cec_options.html +++ /dev/null @@ -1,464 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>COS Event Channel Configuration</title> - <!-- $Id$ --> - </head> - - <body> - <CENTER> - <h1>COS Event Channel Configuration</h1> - </CENTER> - - <H3>Run-time Configuration</H3> - - <P>The new implementation of the COS Event Service uses a - factory to build all the objects and strategies it requires. - The factory can be dynamically loaded using ACE Service - Configurator, this is extremely convenient because the factory - can also parse options in the Service Configurator script file. - </P> - - <P>The current implementation provides a default implementation - for this Factory, this document describes the options used by - this default implementation. - Users can define their own implementation, with new ad-hoc - strategies or with pre-selected strategies. - </P> - - <H3>The configuration file</H3> - - <P>The COS channel uses the same service configurator - file that the ORB uses, the default name for this file is - <CODE>svc.conf</CODE>, but the ORB option - <CODE>-ORBSvcConf</CODE> can be used to override this. - The format of the file is described in detail in - the service configurator documentation, but the relevant section - for the event channel looks like this: - </P> - -<PRE> -# Comments go here... -# More comments if you want to... -static CEC_Factory "-CECDispatching reactive ....." -</PRE> - - <P>All the event service factory options start with - <CODE>-CEC</CODE></P> - - - <H3>The options</H3> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - <!-- <TR NAME="CECDispatching"> --> - <TR> - <TD><CODE>-CECDispatching</CODE> - <EM>dispatching_strategy</EM> - </TD> - <TD>Select the dispatching strategy used by the COS - event service. A <EM>reactive</EM> strategy will use the - same thread that received the event from the supplier to - push the event to all the consumers. - The <EM>mt</EM> strategy will also use a pool of threads, - but the thread to dispatch is randomly selected. - </TD> - </TR> - - <!-- <TR NAME="CECDispatchingThreads"> --> - <TR> - <TD><CODE>-CECDispatchingThreads</CODE> - <EM>number_of_threads</EM> - </TD> - <TD>Select the number of threads used by the <EM>mt</EM> - dispatching strategy. - </TD> - </TR> - - <!-- <TR NAME="CECProxyConsumerLock"> --> - <TR> - <TD><CODE>-CECProxyConsumerLock</CODE> - <EM>lock_type</EM> - </TD> - <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or - <EM>recursive</EM>) to synchronize access to the - ProxyPushConsumer state. - </TD> - </TR> - - <!-- <TR NAME="CECProxySupplierLock"> --> - <TR> - <TD><CODE>-CECProxySupplierLock</CODE> - <EM>lock_type</EM> - </TD> - <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or - <EM>recursive</EM>) to synchronize access to the - ProxyPushSupplier state. - </TD> - </TR> - - <!-- <TR NAME="CECUseORBId"> --> - <TR> - <TD><CODE>-CECUseORBId</CODE> - <EM>orbid</EM> - </TD> - <TD>Set the name of the ORB used by the event service, only - useful in applications that create multiple ORBs and - activate the event service in one of them. - </TD> - </TR> - - <!-- <TR NAME="CECConsumerControl"> --> - <TR> - <TD><CODE>-CECConsumerControl</CODE> - <EM>policy</EM> - </TD> - <TD>Select the consumer control policy (<EM>null</EM> or - <EM>reactive</EM>) to detect and discard broken consumers. - </TD> - </TR> - - <!-- <TR NAME="CECSupplierControl"> --> - <TR> - <TD><CODE>-CECSupplierControl</CODE> - <EM>policy</EM> - </TD> - <TD>Select the supplier control policy (<EM>null</EM> or - <EM>reactive</EM>) to detect and discard broken suppliers. - </TD> - </TR> - - <!-- <TR NAME="CECConsumerControlPeriod"> --> - <TR> - <TD><CODE>-CECConsumerControlPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive - consumer control policy to poll the state of the - consumers. - </TD> - </TR> - - <!-- <TR NAME="CECSupplierControlPeriod"> --> - <TR> - <TD><CODE>-CECSupplierControlPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive - supplier control policy to poll the state of the - suppliers. - </TD> - </TR> - - <!-- <TR NAME="CECConsumerControlTimeout"> --> - <TR> - <TD><CODE>-CECConsumerControlTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD><P>Set the relative roundtrip timeout for push and pull - consumers. The default is 10000 microseconds. - This relative roundtrip timeout is utilized - when each consumer attached to the supplier is queried. - If querying any one of the consumers times out, it may - be disconnected depending on the - -CECProxyDisconnectRetries setting. - </P> - <P>This option can also be referenced as - -CECConsumerControlRoundtripTimeout. - </P> - </TD> - </TR> - - <!-- <TR NAME="CECSupplierControlTimeout"> --> - <TR> - <TD><CODE>-CECSupplierControlTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD><P>Set the relative roundtrip timeout for push or pull - suppliers. The default is 10000 microseconds. - This relative roundtrip timeout is utilized - when each supplier attached to the consumer is queried. - If querying any one of the suppliers times out, it may - be disconnected depending on the - -CECProxyDisconnectRetries setting. - </P> - <P>This option can also be referenced as - -CECSupplierControlRoundtripTimeout. - </P> - </TD> - </TR> - - <!-- <TR NAME="CECReactivePullingPeriod"> --> - <TR> - <TD><CODE>-CECReactivePullingPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive - pulling strategy to poll all the PullSuppliers for an - event. - </TD> - </TR> - - <!-- <TR NAME="CECConsumerOperationTimeout"> --> - <TR> - <TD><CODE>-CECConsumerOperationTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD>Set the relative roundtrip timeout for all operations (except - "pings" due to reactive consumer control) on consumers. - Reactive consumer control must be enabled for this option to take - effect. The units for <EM>timeout</EM> are microseconds. - If a remote operation invoked on the consumer exceeds the timeout, - then that consumer will be considered "bad" and will be - disconnected from the event channel. - </TD> - </TR> - - <!-- <TR NAME="CECSupplierOperationTimeout"> --> - <TR> - <TD><CODE>-CECSupplierOperationTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD>Set the relative roundtrip timeout for all operations (except - "pings" due to reactive supplier control) on suppliers. - Reactive supplier control must be enabled for this option to take - effect. The units for <EM>timeout</EM> are microseconds. - If a remote operation invoked on the supplier exceeds the timeout - then that supplier will be considered "bad" and will be - disconnected from the event channel. - </TD> - </TR> - - <!-- <TR NAME="CECProxyConsumerCollection"> --> - <TR> - <TD><CODE>-CECProxyConsumerCollection</CODE> - <EM>flag[:flags]</EM> - </TD> - <TD><P>Configure the data structure and strategies used to - implement collections of - <CODE>ProxyPushConsumers</CODE> and - <CODE>ProxyPullConsumers</CODE>. - The argument is a colon separated list of flags, with - the following semantics: - <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0"> - <TR><TH>Flag</TH><TH>Description</TH> - </TR> - <TR> - <TD>MT</TD> - <TD>Use regular mutexes and/or condition - variables for serialization. - </TD> - </tr> - <TR> - <TD>ST</TD> - <TD>Use null mutexes and/or condition - variables for serialization. - </TD> - </tr> - <TR> - <TD>LIST</TD> - <TD>Implement the collection using an ordered list, - fast for iteration (i.e. during event dispatching), - but slow for insertion and removal (i.e. when - clients connect and disconnect from the EC). - </TD> - </tr> - <TR> - <TD>RB_TREE</TD> - <TD>Implement the collection using a Red-Black tree, - slow for iteration (i.e. during event dispatching), - but fast for insertion and removal (i.e. when - clients connect and disconnect from the EC). - </TD> - </tr> - <TR> - <TD>IMMEDIATE</TD> - <TD>Threads block until they can execute a change on - the data structure, the system must use other - approaches to guarantee that the iterators are not - invalidated during event dispatching. For example, - use a separate dispatching thread. Using this option - with the reactive values for any of the - -CECSupplierControl, -CECConsumerControl, or - -CECDispatching options may cause deadlocks. - </TD> - </tr> - <TR> - <TD>COPY_ON_READ</TD> - <TD>Before initiating an iteration to dispatch events - (or similar tasks) a copy of the complete collection - is performed. - This solves most of the synchronization problems, - but introduces a significant source of overhead and - priority inversions on the critical path. - </TD> - </tr> - <TR> - <TD>COPY_ON_WRITE</TD> - <TD>Similar to the previous one, but the copy is only - performed when needed. - </TD> - </tr> - <TR> - <TD>DELAYED</TD> - <TD>Threads that need to change the collection can - detect if that change will invalidate iterators used - by other threads. - If so, the thread posts the change on a queue that - is executed once the collection is no longer in - use. - </TD> - </TR> - </TABLE> - </P> - </TD> - </TR> - - <!-- <TR NAME="CECProxySupplierCollection"> --> - <TR> - <TD><CODE>-CECProxySupplierCollection</CODE> - <EM>flag[:flags]</EM> - </TD> - <TD><P>Configure the data structure and strategies used to - implement collections of <CODE>ProxyPushSupplier</CODE> - and <CODE>ProxyPullSupplier</CODE> objects. - Use the same arguments as with the - <CODE>CECProxyConsumerCollection</CODE> option. - </P> - </TD> - </TR> - - <!-- <TR NAME="CECProxyDisconnectRetries"> --> - <TR> - <TD><CODE>-CECProxyDisconnectRetries</CODE> - <EM>number of retries</EM> - </TD> - <TD><P>This determines the number of times a consumer or - supplier can be "unresponsive" before the supplier or - consumer control will disconnect it. The default is zero - retries. - </P> - </TD> - </TR> - </TABLE> - </P> - - <H3>The constructor</H3> - - <P>The <CODE>TAO_CEC_EventChannel</CODE> class implements the - <CODE>CosEventChannelAdmin::EventChannel</CODE> interface; - this class takes one mandatory and two optional parameters in - its constructor: - </P> - -<PRE> - TAO_CEC_EventChannel (const TAO_CEC_EventChannel_Attributes& attributes, - TAO_CEC_Factory* factory = 0, - int own_factory = 0); -</PRE> - - <P>The <CODE>factory</CODE> is an optional parameter to override - the default strategy factory used by the event channel, - the event channel will destroy the factory if the - <CODE>own_factory</CODE> argument is true. - </P> - - <P>The <CODE>attributes</CODE> parameter can be used to fine tune - some of the algorithms and strategies used by the event channel, - the default values are probably OK for most applications. - Notice that the attributes include the POA used to activate the - ConsumerAdmin, SupplierAdmin, ProxyPushConsumer, - ProxyPushSupplier, ProxyPullConsumer and the ProxyPullSupplier - objects; - these POAs must have the <CODE>IMPLICIT_ACTIVATION</CODE> and the - <CODE>SYSTEM_ID</CODE> policies (as the RootPOA does). - </P> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR><TH>Attribute</TH><TH>Description</TH></TR> - - <TR><TD><CODE>consumer_reconnect</CODE></TD> - <TD>If the attribute is not zero then the same consumer can - call <CODE>connect_push_consumer</CODE> on its - ProxyPushSupplier multiple times to change its - subscriptions; - this is usually more efficient that disconnecting and - connecting again. - </TD> - </TR> - - <TR><TD><CODE>supplier_reconnect</CODE></TD> - <TD>If the attribute is not zero then the same supplier can - call <CODE>connect_push_supplier</CODE> on its - ProxyPushConsumer multiple times to change its - publications; - this is usually more efficient that disconnecting and - connecting again. - </TD> - </TR> - - <TR><TD><CODE>disconnect_callbacks</CODE></TD> - <TD>It not zero the event channel will send disconnect - callbacks when a disconnect method is called on a Proxy. - In other words, if a consumer calls - <CODE>disconnect_push_supplier()</CODE> on its proxy the - EC will invoke <CODE>disconnect_push_consumer()</CODE> - on the consumer. A similar thing is done for suppliers. - It is a matter of debate what the spec requires for the - regular event service. - </TD> - </TR> - - <TR><TD><CODE>busy_hwm</CODE></TD> - <TD>When the delayed flag is set on proxy collections, - this flag controls the maximum - number of threads that can simultaneously iterate over the - collection before blocking. - It can be used to avoid starvation in delayed updates on - the collection. - </TD> - </TR> - - <TR><TD><CODE>max_write_delay</CODE></TD> - <TD>When the delayed flag is set on proxy collections, - this flag controls the maximum - number of threads that will initiate dispatching - <B>after</B> a change has been posted. - Any thread after that is blocked until the operations are - performed. - It can be used to completely stop starvation of delayed - updates on the collection. - </TD> - </TR> - - <TR><TD><CODE>supplier_poa</CODE></TD> - <TD>The POA used by the event channel to activate SupplierAdmin - and SupplierProxy objects. - </TD> - </TR> - - <TR><TD><CODE>consumer_poa</CODE></TD> - <TD>The POA used by the event channel to activate ConsumerAdmin - and ConsumerProxy objects. - </TD> - </TR> - - </TABLE> - </P> - - <P><HR><P> - - Back to the TAO <A HREF="index.html">components documentation</A>. - - <!--#include virtual="/~schmidt/cgi-sig.html" --> - - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Thu Jul 1 21:44:28 CDT 1999 --> -<!-- hhmts start --> -Last modified: Fri Apr 20 15:24:09 CDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/compiler.html b/TAO/docs/compiler.html deleted file mode 100644 index 6c505774eb3..00000000000 --- a/TAO/docs/compiler.html +++ /dev/null @@ -1,859 +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.5 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]"> -<title>TAO IDL compiler User's Guide</title> - -<!-- $Id$ --> - -</head> -<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#CC0000"> - -<hr> -<h3> -TAO IDL Compiler User's Guide</h3> - -<h3> Scope</h3> This document describes the options and features of -TAO IDL compiler. It is not a reference manual or tutorial on OMG -IDL. For more information on OMG IDL see the <A -HREF="http://www.omg.org/technology/documents/corba_spec_catalog.htm"> -online CORBA specification</A> and the <A -HREF="http://www.triodia.com/staff/michi-henning.html">Advanced CORBA -Programming with C++</A> book. More information on the design of -TAO's IDL compiler is also available <A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/ami1.pdf">online</A>. -Finally, comprehensive documentation on TAO's IDL compiler is -available in the OCI <A HREF="http://www.theaceorb.com/product/index.html">TAO -Developer's Guide</A>.<P> - -<HR><P> -<h3>Generated Files</h3> - -The IDL compiler generates 9 files from each <tt>.idl</tt> file. The -file names are obtained by taking the IDL <EM>basename</EM> and -appending the following suffixes (see the list of TAO's IDL compiler -<A HREF="#options">options</A> on how to get different suffixes for -these files:) <P> - -<UL> - <LI> <B><EM>Client stubs</EM></B>, <EM>i.e.</EM>, <tt>*C.h</tt>, - <tt>*C.inl</tt>, and <tt>*C.cpp</tt>. Pure client applications - only need to <code>#include</code> and link with these files. - <LI> <B><EM>Server skeletons</EM></B>, <EM>i.e.</EM>, <tt>*S.h</tt>, <tt>*S.inl</tt>, and - <tt>*S.cpp</tt>. Servers need to <code>#include</code> and link - with these files. - <LI> <B><EM>Server skeleton templates</EM></B>, <EM>i.e.</EM>, <tt>*S_T.h</tt>, <tt>S_T.inl</tt>, - and <tt>*S_T.cpp</tt>. Some C++ compilers do not like template - and non-template code in the same files, so TAO's IDL compiler - generates these files separately. -</UL> - -TAO's IDL compiler creates separate <TT>*.inl</TT> and <TT>*S_T.*</TT> -files to improve the performance of the generated code. For example, -the <TT>*.inl</TT> files enable you to compile with inlining enabled or -not, which is useful for trading-off compile-time and run-time -performance. Fortunately, you only need to <CODE>#include</CODE> the -client stubs declared in the <tt>*C.h</tt> file and the skeletons in -the <tt>*S.h</tt> file in your code. <P> - -<HR><P> -<a name="idl_env"><h3>Environment Variables</h3></a> - -<TABLE BORDER=2 CELLSPACING=2 CELLPADDING=0> - <TH>Variable - <TH>Usage - <TR> - <TD>CPP_LOCATION - <TD>Deprecated in version 1.0.4 of TAO. Please use TAO_IDL_PREPROCESSOR - instead. - <TR> - <TD>TAO_IDL_DEFAULT_CPP_FLAGS - <TD>Deprecated in version 1.0.4 of TAO. Please use - TAO_IDL_PREPROCESSOR_ARGS instead. - <TR> - <TD>TAO_IDL_PREPROCESSOR - <TD>Used to override the program name of the preprocessor that TAO_IDL - uses. - <TR> - <TD>TAO_IDL_PREPROCESSOR_ARGS - <TD>Used to override the flags passed to the preprocessor that TAO_IDL - uses. This can be used to alter the default options for the - preprocessor and specify things like include directories and how - the preprocessor is invoked. Two flags that will always be passed to - the preprocessor are <CODE>-DIDL</CODE> and <CODE>-I.</CODE>. - <TR> - <TD>TAO_ROOT - <TD>Used to determine where <CODE>orb.idl</CODE> is located. - <TR> - <TD>ACE_ROOT - <TD>Used to determine where <CODE>orb.idl</CODE> is located. -</TABLE> - -<P>Because TAO_IDL doesn't have any code to implement a preprocessor, it has -to use an external one. For convenience, it uses a built-in name for an external -preprocessor to call. During compilation, this is how that default is set:</P> - -<OL> - <LI>If the macro TAO_IDL_PREPROCESSOR is defined, then it will use that. - <LI>Else if the macro ACE_CC_PREPROCESSOR is defined, then it will use that. - <LI>Otherwise, it will use "cc" -</OL> - -<P>And the same behavior occurs for the TAO_IDL_PREPROCESSOR_ARGS and -ACE_CC_PREPROCESSOR_ARGS macros.</P> - -<P>Case 1 is used by the Makefile on most machines to specify the preprocessor. -Case 2 is used on Windows and platforms that need special arguments passed -to the preprocessor (MVS, HPUX, etc.). And case 3 isn't used at all, -but is included as a default case.</P> - -<P>Since the default preprocessor may not always work when TAO_IDL is moved to -another machine or used in cross-compilation, it can be overriden at runtime -by setting the environment variables TAO_IDL_PREPROCESSOR and -TAO_IDL_PREPROCESSOR_ARGS.</P> - -<P>In previous versions, the environment variables CPP_LOCATION and -TAO_IDL_DEFAULT_CPP_FLAGS were used for this purpose. Both will still work, -but TAO_IDL will display a deprecation warning if it detects one of these. -It is possible that support for these old variables will be removed in a -future version of TAO.</P> - -<P>If ACE_ROOT or TAO_ROOT are defined, then TAO_IDL -will use them to include the $(ACE_ROOT)/TAO/tao or $(TAO_ROOT)/tao -directories. This is to allow TAO_IDL to automatically find -<orb.idl> when it is included in an IDL file. TAO_IDL will -display a warning message when neither is defined.</P> - -<HR><P> -<h3>Operation Demuxing Strategies</h3> - -The server skeleton can use different demuxing strategies to match the -incoming operation with the correct operation at the servant. TAO's -IDL compiler supports perfect hashing, binary search, and dynamic -hashing demuxing strategies. By default, TAO's IDL compiler tries to -generate perfect hash functions, which is generally the most <A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/COOTS-99.pdf">efficient and -predictable operation demuxing technique</A>. To generate perfect -hash functions, TAO's IDL compiler uses <a -href="http://www.cs.wustl.edu/~schmidt/PDF/gperf.pdf">gperf </a>, which -is a general-purpose perfect hash function generator. <P> - -To configure TAO's IDL compiler to support perfect hashing please do -the following: - -<ul> - <LI>Enable <CODE>ACE_HAS_GPERF</CODE> when building ACE and TAO. - This macro has been defined for the platforms where <CODE>gperf</CODE> - has been tested, which includes most <A - HREF="http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html">platforms</A> - that ACE runs on. <P> - - <li>Build the <CODE>gperf</CODE> in $ACE_ROOT/apps/gperf. This build - also leaves a copy/link of the gperf program at the $ACE_ROOT/bin - directory.<P> - - <li>Set the environment variable $ACE_ROOT appropriately or add - $ACE_ROOT/bin to your search path. <P> - - <li>Use the <CODE>-g</CODE> option for the TAO IDL compiler or set - your search path accordingly to install <CODE>gperf</CODE> in a - directory other than $ACE_ROOT/bin. -</ul> - -Note that if you can't use perfect hashing for some reason the next -best operation demuxing strategy is binary search, which can be -configured using TAO's IDL compiler <A HREF="#options">options</A>.<P> - -<HR><P> -<h3>AMI support</h3> - -The TAO_IDL compiler generates AMI stubs and skeletons as -described in the CORBA 3.0.3 specification. - -<hr><p> -<h3><a name="collocation-stubs">Collocation Strategies</a></h3> - -TAO_IDL can generate collocated stubs using two different collocation -strategies. It also allows you to supress/enable the generation of -the stubs of a particular strategy. To gain great flexibility at -run-time, you can gereate stubs for both collocation strategies -(using both '<a href="#Gp"><code>-Gp</code></a>' and '<a -href="#Gd"><code>-Gd</code></a>' flags at the same time) and defer the -determination of collocation strategy until run-time. On the other -hand, if you want to minimize the footprint of your program, you might -want to pre-determine the collocation strategy you want and only -generate the right collocated stubs (or not generating any at all using -both '<a href="#Sp"><code>-Sp</code></a>' and '<a -href="#Sd"><code>-Sd</code></a>' flags at the same time if -it's a pure client.) See our <a -href="http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col18.pdf">collocation -paper</a> for a detail discussion on the collocation support in -TAO.<p> - - -<HR><P> -<h3><A NAME="options">TAO's IDL Compiler Options</A></h3> - -TAO's IDL compiler invokes your <tt>C</tt> (or <tt>C++</tt>) -preprocessor to resolve included IDL files. It receives the common -options for preprocessors (such as <tt>-D</tt> or <tt>-I</tt>). It -also receives other options that are specific to it.<p> - -<table BORDER=2 CELLSPACING=2 CELLPADDING=0> - <tr> - <th>Option</th> - <th>Description</th> - <th>Remark</th> - </tr> - <tr><a NAME="u"> - <td><tt>-u</tt></td> - - <td>The compiler prints out the options that are given below and exits - clean </td> - <td> </td> - </tr> - - <tr> <a NAME="V"> - <td><tt>-V</tt></td> - - <td>The compiler printouts its version and exits</td> - <td> </td> - </tr> - - <tr><a name="Wb"> - <td><tt>-Wb,</tt><i>option_list</i></EM</TD></td> - - <td>Pass options to the TAO IDL compiler backend.</td> - <td> </td> - </tr> - - <tr><a name="skel_export_macro"> - <td></td> - - <td><tt>skel_export_macro=</tt><i>macro_name</i></td> - - <td>The compiler will emit <i>macro_name</i> right after each <tt>class</tt> - or <tt>extern</tt> keyword in the generated skeleton code (S - files,) this is needed for Windows, which requires - special directives to export symbols from DLLs, usually the definition - is just a space on unix platforms. </td> - </tr> - - <tr><a name="skel_export_include"> - <td></td> - - <td><tt>skel_export_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - top of the generated server header, this is usually a good - place to define the server side export macro.</td> - </tr> - - <tr><a name="stub_export_macro"> - <td></td> - - <td><tt>stub_export_macro=</tt><i>macro_name</i></td> - - <td>The compiler will emit <i>macro_name</i> right after each <tt>class</tt> - or <tt>extern</tt> keyword in the generated stub code, this is - needed for Windows, which requires special directives to - export symbols from DLLs, usually the definition is just a - space on unix platforms. </td> - </tr> - - <tr><a name="stub_export_include"> - <td></td> - - <td><tt>stub_export_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - top of the client header, this is usually a good place to define the export - macro.</td> - </tr> - - <tr><a name="anyop_export_macro"> - <td></td> - - <td><tt>anyop_export_macro=</tt><i>macro_name</i></td> - - <td>The compiler will emit <i>macro_name</i> before each Any operator - or <tt>extern</tt> typecode declaration in the generated stub code, - this is needed for Windows, which requires special directives to - export symbols from DLLs, usually the definition is just a - space on unix platforms. This option works only in conjuction with - the -GA option, which generates Any operators and typecodes into a - separate set of files. </td> - </tr> - - <tr><a name="anyop_export_include"> - <td></td> - - <td><tt>anyop_export_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - top of the anyop file header, this is usually a good place to define the export - macro. This option works in conjuction with the -GA option, which generates Any - operators and typecodes into a separate set of files.</td> - </tr> - - <tr><a name="export_macro"> - <td></td> - - <td><tt>export_macro=</tt><i>macro_name</i></td> - - <td>This option has the same effect as issuing<br> - <tt>-Wb,skel_export_macro=</tt><i>macro_name</i><br> - <tt>-Wb,stub_export_macro=</tt><i>macro_name</i><br> - <tt>-Wb,anyop_export_macro=</tt><i>macro_name</i>.<br> - This option is useful when building a DLL containing both stubs and - skeletons.</td> - </tr> - - <tr><a name="export_include"> - <td></td> - - <td><tt>export_include=</tt><i>include_path</i></td> - - <td>This option has the same effect as specifying<br> - <tt>-Wb,stub_export_include=</tt><i>include_path</i><br> - <tt>-Wb,skel_export_include=</tt><i>include_path</i><br> - <tt>-Wb,anyop_export_include=</tt><i>include_path</i>.<br> - This option goes with the previous option to build DLL containing - both stubs and skeletons.</td> - </tr> - - <tr><a name="pch_include"> - <td></td> - - <td><tt>pch_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - top of all TAO IDL compiler generated files. This can be used with a - precompiled header mechanism, such as those provided by Borland - C++Builder or MSVC++.</td> - </tr> - - <tr><a name="obv_opt_accessor"> - <td></td> - - <td><tt>obv_opt_accessor</tt></td> - - <td>The IDL compiler will generate code to optimize access to base class data - for valuetypes.</td> - </tr> - - <tr><a name="pre_include"> - <td></td> - - <td><tt>pre_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - top of the each header file, before any other include statements. For - example, ace/pre.h, which pushes compiler options for the Borland C++ - Builder and MSVC++ compilers, is included in this manner in all - IDL-generated files in the TAO libraries and CORBA services.</td> - </tr> - - <tr><a name="post_include"> - <td></td> - - <td><tt>post_include=</tt><i>include_path</i></td> - - <td>The compiler will generate code to include <i>include_path</i> at the - bottom of the each header file. For example, ace/post.h, which pops - compiler options for the Borland C++ Builder and MSVC++ compilers, is - included in this manner in all IDL-generated files in the TAO libraries - and CORBA services.</td> - </tr> - - <tr><a name="include_guard"> - <td></td> - - <td><tt>include_guard=</tt><i>define</i></td> - - <td>The compiler will generate code the define in the C.h file to prevent - users from including the generated C.h file. Useful for regenerating - the pidl files in the archive.</td> - </tr> - - <tr><a name="safe_include"> - <td></td> - - <td><tt>safe_include=</tt><i>file</i></td> - - <td>File that the user should include instead of this generated C.h file. - Useful for regenerating the pidl files in the archive.</td> - </tr> - - <tr><a name="E"> - <td><tt>-E</tt></td> - - <td>Invoke only the preprocessor</td> - <td> </td> - </tr> - - <tr><a name="Wp"> - <td><tt>-Wp,</tt><i>option_list</i></EM</TD></td> - - <td>Pass options to the preprocessor.</td> - <td> </td> - </tr> - - <tr><a name="d"> - <td><tt>-d</tt></td> - - <td>Causes output of a dump of the AST</td> - <td> </td> - </tr> - - <tr><a name="D"> - <td><tt>-D</tt><i>macro_definition</i></td> - - <td>It is passed to the preprocessor</td> - <td> </td> - </tr> - - <tr><a name="U"> - <td><tt>-U</tt><i>macro_name</i></td> - - <td>It is passed to the preprocessor</td> - <td> </td> - </tr> - - <tr><a name="I"> - <td><tt>-I</tt><i>include_path</i></td> - - <td>It is passed to the preprocessor</td> - <td> </td> - </tr> - - <tr><a name="A"> - <td><tt>-A</tt><i>assertion</i></td> - - <td>It is passed to the preprocessor</td> - <td> </td> - </tr> - - <tr><a name="Y"> - <td><tt>-Yp,<i>path</i></tt></td> - - <td>Specifies the path for the C preprocessor</td> - <td> </td> - </tr> - - <tr><a name="H perfect_hash"> - <td><tt>-H perfect_hash</tt></td> - - <td>To specify the IDL compiler to generate skelton code that uses perfect - hashed operation demuxing strategy, which is the default strategy. Perfect - hashing uses <a href="http://www.cs.wustl.edu/~schmidt/PDF/gperf.pdf">gperf - </a>program, - to generate demuxing methods. </td> - <td> </td> - </tr> - - <tr><a name="H dynamic_hash"> - <td><tt>-H dynamic_hash</tt></td> - - <td>To specify the IDL compiler to generate skelton code that uses dynamic - hashed operation demuxing strategy. </td> - <td> </td> - </tr> - - <tr><a name="H binary_search"> - <td><tt>-H binary_search</tt></td> - - <td>To specify the IDL compiler to generate skelton code that uses binary - search based operation demuxing strategy. </td> - <td> </td> - </tr> - - <tr><a name="H linear_search"> - <td><tt>-H linear_search</tt></td> - - <td>To specify the IDL compiler to generate skelton code that uses linear - search based operation demuxing strategy. Note that this option is for testing purposes only and should not be used for production code since it's inefficient.</td> - <td> </td> - </tr> - - - <tr><a name="in"> - <TD><TT>-in</TT></TD> - <TD> To generate #include statements with <>'s for the standard - include files (e.g. tao/corba.h) indicating them as non-changing - files</TD> - <td> </td> - </TR> - - - <TR><A NAME="ic"> - <TD><TT>-ic</TT></TD> - <TD> To generate #include statements with ""s for changing - standard include files (e.g. tao/corba.h). </TD> - <td> </td> - </TR> - - <tr><a name="g"> - <td><tt>-g</tt></td> - - <td>To specify the path for the perfect hasing program (GPERF). Default - is $ACE_ROOT/bin/gperf. </td> - <td> </td> - </tr> - - <tr><a name="o"> - <td><tt>-o </tt><i>path</i></td> - - <td>To specify the output directory to IDL compiler as to where all the - IDL-compiler-generated files are to be put. By default, all the files are - put in the current directory from where <tao_idl>is called. </td> - <td>If the specified directory does not exist, it will be created, if any path - that may precede the directory name already exists. If the directory - itself already exists, no action is taken. </td> - </tr> - - <tr><a name="oS"> - <td><tt>-oS </tt><i>path</i></td> - - <td>Same as -o option but applies only to generated *S.* files </td> - <td>Default is value of -o option or current directory </td> - </tr> - - <tr><a name="oA"> - <td><tt>-oA </tt><i>path</i></td> - - <td>Same as -o option but applies only to generated *A.* files </td> - <td>Default is value of -o option or current directory </td> - </tr> - - <tr><a name="hc"> - <td><tt>-hc</tt></td> - - <td>Client's header file name ending. Default is "C.h".</td> - <td> </td> - </tr> - - <tr><a name="hs"> - <td><tt>-hs</tt></td> - - <td>Server's header file name ending. Default is "S.h".</td> - <td> </td> - </tr> - - <tr><a name="hT"> - <td><tt>-hT</tt></td> - - <td>Server's template header file name ending. Default is "S_T.h".</td> - <td> </td> - </tr> - - <tr><a name="cs"> - <td><tt>-cs</tt></td> - - <td>Client stub's file name ending. Default is "C.cpp".</td> - <td> </td> - </tr> - - <tr><a name="ci"> - <td><tt>-ci</tt></td> - - <td>Client inline file name ending. Default is "C.inl".</td> - <td> </td> - </tr> - - <tr><a name="ss"> - <td><tt>-ss</tt></td> - - <td>Server skeleton file name ending. Default is "S.cpp".</td> - <td> </td> - </tr> - - <tr><a name="sT"> - <td><tt>-sT</tt></td> - - <td>Server template skeleton file name ending. Default is "S_T.cpp".</td> - <td> </td> - </tr> - - <tr><a name="si"> - <td><tt>-si</tt></td> - - <td>Server inline skeleton file name ending. Default is "S.inl".</td> - <td> </td> - </tr> - - <tr><a name="st"> - <td><tt>-st</tt></td> - - <td>Server's template inline file name ending. Default is "S_T.inl".</td> - <td> </td> - </tr> - - <tr><a name="t"> - <td><tt>-t</tt></td> - - <td>Temporary directory to be used by the IDL compiler. - </td> - <td>Unix: use environment variable TEMPDIR if defined, else use /tmp/. - Windows 95/98/Me: use environment variable TMP or TEMP if defined - and directory exists, else use current directory. Windows NT/2000/XP: - use environment variable TMP or TEMP if defined, else use the - Windows directory. - </td> - </tr> - - <tr><a name="Cw"> - <td><tt>-Cw</tt></td> - - <td>Output a warning if two identifiers in the same scope differ in - spelling only by case (default is output of error message).</td> - - <td>This option has been added as a nicety for dealing with legacy - IDL files, written when the CORBA rules for name resolution - were not as stringent.</td> - </tr> - - <tr><a name="Ce"> - <td><tt>-Ce</tt></td> - - <td>Output an error if two indentifiers in the same scope differ in - spelling only by case (default).</td> - - <td> </td> - </tr> - - <tr><a name="GC flag"> - <td><tt>-GC </tt></td> - - <td>Generate AMI stubs ("sendc_" methods, reply handler stubs, - exception holders, etc)</td> - <td> </td> - </tr> - - <tr><a name="GH flag"> - <td><tt>-GH </tt></td> - - <td>Generate AMH stubs, skeletons, exception holders, etc.</td> - <td> </td> - </tr> - - <tr><a name="Ge flag"> - <td><tt>-Ge </tt><i>flag</i></td> - <td>If the value of the flag is 0, operations generated from application IDL will - use native C++ exceptions. If the value of the flag is 1, such operations will - use the <CODE>CORBA::Environment</CODE> variable for passing exceptions. If the - value of the flag is 2, the C++ 'throw' keyword will be used in place of - ACE_THROW_SPEC, ACE_THROW, and ACE_RETHROW (ACE_THROW_RETURN and - TAO_INTERCEPTOR_THROW will still be used). This flag value will also disable - the generation of environment variables in argument lists for all generated - operations, including base class overrides not defined in application IDL.</td> - <td>As of TAO 1.5, support for emulated exceptions is in the process of being - dropped. The environment variable macros are still present in ORB code and in - generated code, but they now expand to nothing and are no longer maintained. - Soon they will be removed altogether, and at that point, no throw, throw spec, - or environment macros will be generated by the IDL compiler, regardless of the - value of the -Ge flag.</td> - </tr> - - <tr><a name="Gp"> - <td><tt>-Gp </tt></td> - - <td>Generated collocated stubs that use <code>Thru_POA</code> collocation strategy (default)</td> - <td> </td> - </tr> - - <tr><a name="Gd"> - <td><tt>-Gd </tt></td> - - <td>Generated collocated stubs that use <code>Direct</code> collocation strategy</td> - <td> </td> - </tr> - - <tr><a name="Gsp"> - <td><tt>-Gsp </tt></td> - - <td>Generate client smart proxies</td> - <td> </td> - </tr> - - <tr><a name="Gt"> - <td><tt>-Gt</tt></td> - - <td>Generate optimized TypeCodes</td> - <td> </td> - </tr> - - <tr><a name="GA"> - <td><tt>-GA</tt></td> - - <td>Generate type codes and Any operators in *A.h and *A.cpp</td> - <td>Decouples client and server decisions to compile and link - TypeCode- and Any-related code, which is generated in - *C.h and *C.cpp by default.</td> - </tr> - - <tr><a name="Guc"> - <td><tt>-Guc</tt></td> - - <td>Generate uninlined constant if defined in a module</td> - <td>Inlined (assigned a value in the C++ header file) by default, but this causes a - problem with some compilers when using pre-compiled headers. Constants declared - at global scope are always generated inline, while those declared in an interface - or a valuetype never are - neither case is affected by this option.</td> - </tr> - - <tr> - <td><tt>-GI</tt></td> - - <td>Generate boiler-plate files that contain empty servant implementations </td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIh </tt><i>arg</i></td> - - <td>Servant implementation header file name ending</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIs </tt><i>arg</i></td> - - <td>Servant implementation skeleton file name ending</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIb </tt><i>arg</i></td> - - <td>Prefix to the implementation class names</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIe </tt><i>arg</i></td> - - <td>Suffix to the implementation class names</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIc</tt></td> - - <td>Generate copy constructors in the servant implementation template files</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GIa</tt></td> - - <td>Generate assignment operators in the servant implementation template files</td> - <td> </td> - </tr> - - <tr> - <td><tt>-GId</tt></td> - - <td>Generate IDL compiler source file/line# debug info in implementation files</td> - <td> </td> - </tr> - - <tr><a name="GT"> - <td><tt>-GT</tt></td> - - <td>Enable generation of the TIE classes, and the *S_T.* files that - contain them.</td> - <td> </td> - </tr> - - <tr><a name="Sa"> - <td><tt>-Sa</tt></td> - - <td>Suppress generation of the Any operators</td> - <td> </td> - </tr> - - <tr><a name="Sal"> - <td><tt>-Sal</tt></td> - - <td>Suppress generation of the Any operators for local interfaces only</td> - <td> </td> - </tr> - - <tr><a name="Sp"> - <td><tt>-Sp</tt></td> - - <td>Suppress generation of collocated stubs that use <code>Thru_POA</code> collocation strategy</td> - <td> </td> - </tr> - - <tr><a name="Sd"> - <td><tt>-Sd</tt></td> - - <td>Suppress generation of collocated stubs that use <code>Direct</code> collocation strategy (default)</td> - <td> </td> - </tr> - - <tr><a name="St"> - <td><tt>-St</tt></td> - - <td>Suppress generation of typecodes</td> - - <td>Also suppresses the generation of the Any operators, since they need the - associated typecode.</td> - </tr> - - <tr><a name="Sm"> - <td><tt>-Sm</tt></td> - - <td>Suppress C++ code generation from CCM 'implied' IDL.</td> - <td>This code generation is achieved by default using a 'preprocessing' visitor - that modified the AST and is launched just before the code generating - visitors. There is a new tool in CIAO that converts the entire IDL file - into one containing explicit declarations of the implied IDL types. - For such a file, we don't want the preprocessing visitor to be launched, - so this command line option will suppress it.</td> - </tr> - - <tr><a name="SS"> - <td><tt>-SS</tt></td> - - <td>Suppress generation of the skeleton implementation and inline file.</td> - <td>This option doesn't check whether something is generated in the files. It - just suppresses them without looking at any possible contents;</td> - </tr> - - <tr><a name="Sci"> - <td><tt>-Sci</tt></td> - - <td>Suppress generation of the client inline file.</td> - <td>This option doesn't check whether something is generated in the file. It - just suppresses it without looking at any possible contents;</td> - </tr> - - <tr><a name="Ssi"> - <td><tt>-Ssi</tt></td> - - <td>Suppress generation of the server inline file.</td> - <td>This option doesn't check whether something is generated in the file. It - just suppresses it without looking at any possible contents;</td> - </tr> - - <tr><a name="Sorb"> - <td><tt>-Sorb</tt></td> - - <td>Suppress generation of the ORB.h include.</td> - <td>This option is usefull when regenerating pidl files in the core - TAO libs to prevent cyclic includes;</td> - </tr> - -</table> <P> - -<P><HR><P> -Back to the TAO <A HREF="index.html">documentation</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> - -</body> -</html> diff --git a/TAO/docs/components.html b/TAO/docs/components.html deleted file mode 100644 index dcd890a3473..00000000000 --- a/TAO/docs/components.html +++ /dev/null @@ -1,53 +0,0 @@ -<HTML> -<!-- $Id$ --> - <HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>TAO Component Options and Tuning Documentation</TITLE> - </HEAD> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR> - <H3 ALIGN=CENTER>TAO Component Options and Tuning Documentation</H3> - - <P>The following documentation is available on certain TAO components:</P> - - <UL> - <LI><A HREF="Options.html">Options</A> describes the - options available to customize various components within TAO. - These customizations can be done by an end-user and do not - require C++ programming.<P> - - <LI><A HREF="ORBEndpoint.html">ORB endpoint options</A> - describes the options that TAO supports to enable - applications to specify which endpoints to use for - ORB-to-ORB communication. These customizations can be done - by an end-user or application during ORB initialization and do not - require C++ programming.<P> - - <li><a href="configurations.html">Configuration</a> - describes how to mix and match component <a - href="Options.html">options</a> to customize - how TAO processes requests. For example, this - document explains how to configure TAO to process - all request in one thread, each request in a separate thread, or each connection - in a separate thread, <em>etc.</em><P> - - <li><a href="performance.html">Performance tuning</a> - describes how to optimize the throughput, scalability, and latency of TAO - to meet various application needs. It also describes how to - reduce the compilation times and memory footprints for - ACE+TAO and its applications. <P> - - </UL> - </BODY> - -<P><HR><P> -Back to the TAO <A HREF="index.html">documentation index</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> - -</HTML> diff --git a/TAO/docs/configurations.html b/TAO/docs/configurations.html deleted file mode 100644 index 1938d361c18..00000000000 --- a/TAO/docs/configurations.html +++ /dev/null @@ -1,895 +0,0 @@ -<!-- $Id$ --> -<!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.5 [en] (WinNT; I) [Netscape]"> -<title>Configuring TAO's Components</title> -</head> - -<body text="#000000" bgcolor="#FFFFFF" link="#000FFF" vlink="#FF0F0F"> - -<hr> -<h3> -Configuring TAO's Components</h3> - -<h3> Overview</h3> - -<p> As described in the <a href="Options.html">options</a> -documentation, various components in TAO can be customized by -specifying options for those components. This document illustrates -how to combine these options to affect the behavior and performance of -a TAO ORB, particularly its <a -href="http://www.cs.wustl.edu/~schmidt/PDF/CACM-arch.pdf">concurrency -model</a>. </p> - -<p> TAO configures itself using the <a -href="http://www.cs.wustl.edu/~schmidt/PDF/Svc-Conf.pdf">ACE Service -Configurator</a> framework. Options are therefore specified using the -<tt>svc.conf</tt> file (if you want to use a different file name, use -the <tt><a href="Options.html#svcfonf">-ORBSvcConf</a></tt> option). -Configurations selected via a <tt>svc.conf</tt> file are global -<EM>per-process</EM>, e.g., all ORBs in a process will share the same -concurrency model configured via a <code>svc.conf</code> file. You -can also setup default configurations for your programs. Please see -the <a href="#programming">Programming Considerations</a> for more -detailed discussion on this.</p> - -<hr> -<h3> -Roadmap</h3> - -<blockquote>Details for the following configurations are provided. -<ul> - <li><b><a href="#comp">Configurating key components</a>:</b></li> - - <ul> - <li><a href="#concurrency">Server Concurrency Strategy.</a></li> - - <li><a href="#orb">Number of ORBs.</a></li> - - <!-- <li><a href="#orb_resources">ORB resources.</a></li> --> - - <li><a href="#poa">POA.</a></li> - - <li><a href="#coltbl">Collocation Table.</a></li> - - <li><a href="#profile">Forwarding Profile</a></li> - - <li><a href="#orbsvcs">orbsvcs Library</a></li> - </ul> - - <li> - <b><a href="#examples">Configuration examples</a></b></li> - - <ul> - <li><a href="#reactive">Single-threaded, reactive model.</a></li> - - <li><a href="#tpc">Multiple threads, single ORB, thread-per-connection - model.</a></li> - - <li><a href="#tpool">Multiple threads, single ORB, TAO thread-pool model.</a></li> - - <li><a href="#rtpool">Multiple threads, single ORB, Real-time CORBA thread-pool model.</a></li> - - <li><a href="#multiorb">Multiple threads, multiple ORBs, - reactive model.</a></li> - - <li><a href="#multiorb-tpc">Multiple threads, multiple ORBs, - thread-per-connection model.</a></li> - - <li><a href="#multiorb-tpool">Multiple threads, - ORB-per-thread, thread-pool reactive model.</a></li> - - <li> - Each configuration has the following information:</li> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="70%"> - <tr> - <th align=left>Typical Use</th> - - <td>A brief description of the scenario and - its typical use.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>The number of threads used by - ORB-related activities.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Identifies the creator of the threads - discussed above.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>Describes what task is undertaken for - each thread.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td>Specifies the options for each service in order to - utilize this configuration.</td> - </tr> - </table> - </ul> - - <li><b><a href="#programming">Programming Considerations</a></b> - <li><b><a href="#homogenous">Configuration for Homogenous Systems</a></b></li> - - <ul> - <li><a href="#homogenous_compile">Compile-time options</a></li> - - <li><a href="#homogenous_runtime">Runtime-time</a></li> - </ul> - <li><b><a href="#suggestions">Configuration Suggestions</a></b> -</ul> -</blockquote> - -<hr> -<h3> -<a NAME="comp"></a>Configuring Key ORB Components</h3> - -<ul> - <li><a name="orb"><b>Number of ORBs</b> -- </a></li> - TAO can assign multiple endpoints to an ORB. - It is therefore not necessary to create multiple ORBs to accept - requests from multiple endpoints. However, multiple ORBs can be - used to support different policies within the same process, - <EM>e.g.</EM>, handling requests in different thread - priorities. Multiple ORBs are most commonly used in the "ORB - per-priority" pattern to avoid priority inversion in real-time - systems. <p> - - <li><a NAME="concurrency"></a><b>Server concurrency strategy</b> -- - The default server strategy factory provided by TAO supports two - types of concurrency strategies that can be specified by adding - the <tt>-ORBConcurrency</tt> flag in the <code><a - href="Options.html#orb_concurrency">Server_Strategy_Factory</a></code> - entry of the <code>svc.conf</code> file. This - specifies the concurrency strategy an ORB uses. This strategy - is orthogonal the the number of ORBs or threads that are - configured in a server process. </li><P> - - <ul> - <li><tt>reactive</tt>: The ORB handles requests reactively, - i.e., the ORB runs in one thread and service multiple - requests/connections simultaneously using the - <A - HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#reactor"> - ACE_Reactor</A>, which uses <tt>select</TT> or a similar - event demultiplexing mechanism supported by the - platform. </li> <P> - - <li><tt>thread-per-connection</tt>: The ORB handles new - connections by spawning a new thread whose job is to - service requests coming from the connection.</li> - </UL><P> - - <li><a name="orb"><b>Thread Pools</b></a></li> -- - TAO supports several types of thread pools. <P> - - <ul> - <li><tt>reactive</tt>: In this approach, each thread - in the thread pool has an ORB that accepts and processes - requests reactively. This is also called as the - "ORB-per-thread" model <P> - - <li><P><tt>leader/followers</tt>: In this model, the user must - create several threads, all of which invoke - <CODE>ORB::run</CODE>, the ORB will select one of the threads - to wait for incoming requests. - This thread is called the leader thread and will process the - first request that arrives to the ORB, but before - doing so the ORB will selects another thread in the pool to - become the leader. - In other words the threads in the pool take turns to - process the events. - </p> - - </li> - - </UL><P> - - <!-- - <li><a NAME="orb_resources"></a><b>ORB resources</b> -- - - <ul> - <li><tt>global</tt>: All threads using the ORB access to - the a set of global per-ORB resources. The same set of - pre-ORB resources are shared by all threads accessing the - ORB. Notice that if you have more than one ORB, each ORB - owns its own global resources. - - <li><tt>tss</tt>: Each thread accessing an ORB gets its own - set of thread-specific resources for the ORB. - - <!-- @@ What about resource inheritance? - -> - </ul><P></li> --> - - <li><a NAME="coltbl"></a><b>Collocation Table</b> -- An ORB can have - several listening endpoints. If there are several ORBs in a - process and a global collocation table is used, then all objects - in the same process are considered collocated. If not, only - objects reside in the same <em>ORB</em> are considered - collocated. You can control the usage of global collocation - table by passing the <code><a href="Options.html#-ORBCollocation"> - -ORBCollocation </a></code> flag as an argument of <code> - ORB_init </code> (most often thru the command line flags.) <p> - - <li> <a NAME="profile"></a><b>Forwarding Profile</b> -- - When multiple threads using the same - <tt>CORBA::Object</tt> and using forwarding, it is necessary to - protect the forwarding <tt>Profile</tt>, which is part of the - CORBA::Object, against multiple access. Therefore a mutex lock - is used by default to ensure proper access. <P> - - Using the switch <tt><a href="Options.html#-ORBProfileLock"> - -ORBProfileLock </a></tt> this policy can be deactivated - specifying <tt>-ORBProfileLock null</tt>. - The primary reason for doing this is to improve performance - when no forwarding is used or no multithreading with access to - shared <tt>CORBA::Object</tt>'s. Using a null mutex reduces - the overhead compared with using a regular mutex - lock.</li><P> - - <li> <a NAME="orbsvcs"></a><b>orbsvcs Library</b> -- - By default, - TAO's Makefiles build all the services that TAO - supports. - To reduce build time you can exclude unused services, - by defining the <tt>TAO_ORBSVCS</tt> makefile variable. - We recommend using one of these two approaches:</li><P> - - <ol> - <li>In your - <tt>$(ACE_ROOT)/include/makeinclude/platform_macros.GNU - </tt> file, - - <li>On the make command line, <i>e.g.</i>, <tt>make - TAO_ORBSVCS=RTEvent</tt>, or - - <li>Set (and export) a <tt>TAO_ORBSVCS</tt> environment variable. - </ol><p> - - Please see the <code><a - href="../orbsvcs/orbsvcs/GNUMakefile">ORBSVCS - Makefile</a></code> for the default setting of - <code>TAO_ORBSVCS</code>.<p> - - Please note that the Naming Service will always be built, even - if Naming is not specified in <code>TAO_ORBSVCS</code>. That's - because many examples, tests, and presumably applications use it.<p> -</ul> - -<hr> -<h3> -<a NAME="examples"></a>Configuration Examples</h3> - -The following are common ORB configurations used by TAO applications.<P> - -<ul> - <li> - <a NAME="reactive"></a><B>Single-threaded, reactive model.</B></li> <P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" > - <tr> - <th ALIGN=LEFT>Typical Use</th> - - <td>This is the default configuration of TAO, where one - thread handles requests from multiple clients via a - one Reactor. It is appropriate when the requests (1) - take a fixed, relatively uniform amount of time and (2) - are largely compute bound.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>1</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>OS or whoever creates the main ORB thread in a process.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>The single thread processes all connection requests and - CORBA messages.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td>Application servants needn't - be concerned with synchronizing their interactions since - there's only one thread active with this model.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td>The default settings should work just fine (by default, - the <tt>-ORBReactorType</tt> is <tt>tp</tt>). However, - you can apply the following options to improve performance:<br> - <tt>TAO_Advanced_Resource_Factory</tt>: <tt>-ORBReactorType - select_st</tt>, <tt>-ORBInputCDRAllocator null</tt> - <br><tt>TAO_Server_Strategy_Factory</tt>: - <tt>-ORBconcurrency reactive</tt> (default), - <tt>-ORBPOALock null</tt> - <br><tt>TAO_Client_Strategy_Factory</tt>: - <tt>-ORBConnectorLock null</tt></td> - </td> - </tr> - </table> - - <P>Check out the <tt><a href="../examples/Simple/grid/">Grid</a></tt> - for an example of a default configuration and - <tt><a href="../performance-tests/Latency/Single_Threaded/">this</a></tt> - for an example of settings that would provide better performance. - - <P> - - <li> <a NAME="tpc"></a><B>Multiple threads, single ORB, thread-per-connection - model.</B></li> <P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" > - <tr ALIGN="LEFT"> - <th align=left>Typical Use - </th> - - <td>This configuration spawns a new thread to serve requests - from a new connection. This approach works well when - there are multiple connections active simultaneously and - each request-per-connection may take a fair amount of - time to execute. - </td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>1 thread for the ORB, plus 1 thread for each connection.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Programmer must set up the main thread which the ORB - lives. The ORB is responsible to create new threads upon - new connections.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>The main thread handles new connections and spawns new - threads for them. Other threads handle requests for - established connections.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td> To avoid race conditions, application servants may need to - synchronize their methods if multiple clients can access - them concurrently.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td><tt>TAO_Server_Strategy_Factory</tt>: - <tt>-ORBConcurrency thread-per-connection</tt></td> - </tr> - </table> - <P> - <tt><a href="../performance-tests/Cubit/TAO/IDL_Cubit/">IDL_Cubit</a></tt> - is a good example on using <i>multiple threads, thread-per-connection</i> - configuration.<P> - -<li> - <a NAME="tpool"></a><B>Multiple threads, single ORB, TAO thread-pool model.</B></li><P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" > - <tr> - <th align=left>Typical Use</th> - - <td>This model implements a highly optimized, TAO-specific thread pool that minimizes - context switching and thread creation costs. In this - model, the programmer is responsible of spawning a group - of threads, creating an ORB instance, and then instructing all the - threads to run the ORB event loop. When a request comes in, one - of these waiting threads in the pool will handle the - request.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>Thread for the ORB, plus the number of threads used by the thread pool.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Pre-spawned by the main thread.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>Blocking on the reactor to wait for its turn to handle a request.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td> To avoid race conditions, application servants may need to - synchronize their methods if multiple clients or multiple - thread from the same client can access - them concurrently.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td> The default ORB settings support this concurrency - configuration, though you'll need to spawn the extra - threads in the pool explicitly.</td> - </tr> - </table> - <P> - <tt><a href="../tests/MT_Server">MT_Server</a></tt> is a good - example on using <i>multiple threads, single ORB, TAO thread-pool</i> - configuration.<P> -<P> - -<li> - <a NAME="rtpool"></a><B>Multiple threads, single ORB, Real-time - CORBA thread-pool model.</B></li><P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" > - <tr> - <th align=left>Typical Use</th> - - <td>This model implements a highly optimized <A HREF="rtcorba/">Real-time CORBA</A> thread pool that minimizes - context switching, and thread creation costs. In this - model, the application is responsible for starting up the ORB and then - calling the Real-time CORBA thread pool factory methods that - internally spawn a pool of threads. When a request comes in, one - of these waiting threads in the pool will handle the - request in accordance with the various CORBA policies.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>Thread for the ORB, plus the number of threads used by the thread pool.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Static threads are pre-spawned by the ORB, which also - spawns any dynamic threads on-demand.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>Blocking on the reactor to wait for its turn to handle a request.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td> To avoid race conditions, application servants may need to - synchronize their methods if multiple clients or multiple - thread from the same client can access - them concurrently.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td> The ORB must be configured to work with <A - HREF="rtcorba">Real-time CORBA</A>, at which point the - default settings work fine.</td> - </tr> - </table> - <P> - <tt><a href="../tests/RTCORBA/Thread_Pool">Thread_Pool</a></tt> is a good - example on using <i>multiple threads, single ORB, Real-time CORBA thread-pool</i> - configuration.<P> -<P> - -<li> - <P><B>Multiple threads, multiple ORBs, reactive model.</B><a NAME="multiorb"></a></li><P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%"> - <tr> - <th align=left>Typical Use</th> - - <td>In this configuration, there are multiple ORBs in a - process with multiple threads. Each thread handles requests - reactively. This model is good for hard real-time applications that - require different thread priorities for the various - ORBs.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>One thread for each ORB.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>The main process (thread).</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>Service the requests from associating ORB.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td>Application servants needn't - be concerned with synchronizing their interactions if - there's no cross ORB/thread access.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td> The default settings just works fine. However, one could - use <br><tt>TAO_Advanced_Resource_Factory</tt>: <tt>-ORBReactorType - "<em>which</em>"</tt>, for a thread-safe platform-specific reactor.<br> - </td> - </tr> -</table> -<P> - -<li><B>Multiple threads, multiple ORBs, thread-per-connection model.</B><a - NAME="multiorb-tpc"></a></li><P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%"> - <tr align="left"> - <th align=left>Typical Use - </th> - - <td>This approach provides a range of thread priorities plus connections - that don't interfere with each others.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>One thread for each ORB, plus one thread for each connection.</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Main threads creates threads running ORBs. They, in turns, - create connection handling threads.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>There are threads running ORB's event loops which handle - connection requests and handler threads which service - requests from established connections.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td> To avoid race conditions, application servants may need to - synchronize their methods if multiple clients can access - them concurrently.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td><tt>TAO_Server_Strategy_Factory</tt>: - <tt>-ORBConcurrency thread-per-connection</tt></td> - </tr> -</table> - -<P> -<tt><a href="../performance-tests/Cubit/TAO/MT_Cubit/">MT_Cubit</a> -</tt> is a good example on using <i>multiple threads, -multiple ORBs, and thread-per-connection</i> configuration.<P> - -<li> - <B>Multiple threads, multiple ORBs, thread-pool model.</B><a NAME="multiorb-tpool"></a> -</li><P> - - <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" > - <tr> - <th align=left>Typical Use</th> - - <td>This model incorporates the advantage of using thread-pool - while allowing hard real-time system to handle requests in - different priority.</td> - </tr> - - <tr> - <th align=left>Number of Threads</th> - - <td>One thread for each ORB, plus the total number of threads in all thread pools</td> - </tr> - - <tr> - <th align=left>Thread Creator</th> - - <td>Pre-spawned by the main thread.</td> - </tr> - - <tr> - <th align=left>Thread task</th> - - <td>Handle incoming request for the ORB event loop it is - waiting on.</td> - </tr> - - <tr> - <th align=left>Synchronization considerations</th> - - <td>Application servants needn't - be concerned with synchronizing their interactions if - there's no cross ORB/thread access.</td> - </tr> - - <tr> - <th align=left>Options</th> - - <td> The default settings work well for this</td> - </tr> -</table> -</ul> - -<hr> -<h3> -Programming Considerations<a NAME="programming"></a></h3> - -There are several ways to pass option flags into TAO's -components. <P> - -<ul> - - <li><p>The plain vanilla approach is do nothing. All TAO components - use their <a - href="Options.html">default settings</A>.</p> - - <li><p>The most common use case is to use a file called - <code>svc.conf</code>. On most platforms, TAO programs - automatically search and read in the file. The disadvantage of - this approach is you always need a <code>svc.conf</code> file if - you want to do use non-default configuration.</p> - - <li><p>You can use <code>-ORBSvcConf <em>filename</em></code> to use - a config file that is not called <code>svc.conf</code>. - Specifying <code>-ORBSvcConf</code> exclude the reading of - default <code>svc.conf</code> file.</p> - - <li><p>If you don't want the application users to worry about - setting up or knowing about <code>svc.conf</code> files, you can - call <code>TAO_Internal::default_svc_conf_entries()</code> - before calling the first <code>ORB_init()</code> in your program - to set up the default svc.conf entries. In this case, if a TAO - application cannot find a svc.conf file, it will configure TAO's - components using the default settings. You can still use a - <code>svc.conf</code> file or use <code>-ORBSvcConf</code> - option to tune the program.<P> - - <li><p>TAO programs evaluate the configuration settings in the following - order:</p> - - <ol> - <li>File specified in <code>-ORBSvcConf</code> command-line - option, if one exist. Otherwise, the - <code>svc.conf</code> in the start-up directory will be - evaluated, if one exist. - <li>Default entries set by - <code>TAO_Internal::default_svc_conf_entries()</code>, if - ones exist. - <li>Default configuration as specified in <a - href="Options.html">this document</a>. - </ol> - - <p>Notice that the first encountered component settings are - always the ones take effect. For example, if you set the entries - for <code>Resource_Factory</code> and - <code>Server_Strategy_Factory</code> using - <code>TAO_Internal::default_svc_conf_entries()</code> in a - program and you also have a file called <code>svc.conf</code> - which has an entry for <code>Resource_Factory</code>. This - program will use the entry for <code>Resource_Factory</code> in - the <code>svc.conf</code> file, the entry for - <code>Server_Strategy_Factory</code> set in the program, and the - in-stock <code>Client_Strategy_Factory</code> that TAO defines. <P> - - <li><p>Some platforms do not support reading of <code>svc.conf</code> - files or perhaps you would rather not to use this feature. In these cases, - you can define <code>TAO_PLATFORM_SVC_CONF_FILE_NOTSUP</code> - in your ACE <code>config.h</code> file and recompile the TAO - libraries. When this flag is set, TAO programs will not try to search for - the default <code>svc.conf</code> file. You can still use - <code>-ORBSvcConf</code> to initialize the components (assuming - the platform supports it).</p> - - <p>On these platform, you can alter the default settings for - TAO components by defining the following macros in your - <code>config.h</code> file:</p> - - <ul> - <li><code>TAO_DEFAULT_RESOURCE_FACTORY_ARGS</code> - <li><code>TAO_ADVANCED_RESOURCE_FACTORY_ARGS</code> - <li><code>TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS</code> - <li><code>TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS</code> - </ul> - - <p>The ACE Makefiles <code>fakesvcconf</code> flag can be - used to define <code>TAO_PLATFORM_SVC_CONF_FILE_NOTSUP</code>. - To define that macro, just add <code>fakesvcconf=1</code> to - your <code>make</code> invocation. - - <p>See <a href="../tao/orbconf.h"><code>orbconf.h</code></a> for - an example. -</ul> - -<hr> -<h3> -Configuration for Homogenous Systems<a NAME="homogenous"></a></h3> - -<ul> - <LI><b>Compile-time options</b><a NAME="homogenous_compile"></a> - <p>Many real-time applications run on homogenous environments, TAO (and - ACE) can take advantage of this fact by simplifying the server side demarshaling; - to enable this feature you have to edit the <tt>$ACE_ROOT/ace/OS.h</tt> - file and enable the macro <tt>ACE_DISABLE_SWAP_ON_READ</tt>. - <p>In this systems it is also common that server and the client startup - and shutdown simultaneously, in those circumstances there is no need to - check the timestamps in the POA, another macro (<tt>POA_NO_TIMESTAMP</tt>) - can be used for this purpose. - <p>Users running in embebbed systems may also need to modify the default - options for TAO, the macros <tt>TAO_DEFAULT_RESOURCE_FACTORY_ARGS</tt>, <tt>TAO_ADVANCED_RESOURCE_FACTORY_ARGS</tt>, - <tt>TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS</tt> and <tt>TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS</tt> - can be used for those purposes. If the footprint size is an issue users - may consider writing custom strategy factories that only create the right - strategies, this eliminates the parsing code for the different options. - - <p> - <LI><b>Run-time options</b><a NAME="homogenous_runtime"></a> - <p>If the only ORB running is TAO and there is no need to be - IIOP interoperable the option <tt>-ORBGIOPlite</tt> can be used - to reduce the message size and the processing time. - <P>Unix systems that support local IPC (formerly known as Unix domain - sockets) can take advantage of TAO's UIOP pluggable transport protocol - to improve performance considerably. To use TAO's UIOP pluggable - protocol, simply specify a UIOP endpoint on the command line using - the <tt>-ORBEndpoint</tt> option described in the - <A HREF="Options.html">options</A> documentation. Further performance - improvement can be achieved by using the UIOP protocol in combination - with the <tt>-ORBGIOPlite</tt> option. Additional information about - TAO's UIOP pluggable protocol can be found in the - <A HREF="releasenotes/index.html#pp">release notes</A>. - <p> - <p>Some embedded systems run without the benefit of a DNS server, in that - case they can use the <tt>-ORBDottedDecimalAddresses</tt> option; the ORB - will avoid the use of hostnames in the profiles it generates, thus clients - don't need to do any name resolution. Use the compile-time define - <tt>TAO_USES_DOTTED_DECIMAL_ADDRESSES</tt> in - <tt>$TAO_ROOT/tao/orbconf.h</tt> to make this the default behavior. -</ul> - -<hr> -<h3>Configuration Suggestions<A name="suggestions"</A></h3> - -Choosing the right configuration is hard and, of course, depends on your -application. In the following section we will attempt to describe some -motivations for features in TAO, hopefully that can guide you through the -choice of your configuration options. -<ul> - - <LI><b>ORB-per-thread</b> -- The main motivation behind this options is to - minimize priority invertion, since threads share no ORB resources no locking - is required and thus, priority is preserved in most cases (assuming proper - support from the OS). If you are not too concerned about priority inversion - try to use a single ORB, using ORB-per-thread has some tradeoffs (like - calling ORB_init on each thread, activation of a servant is more complicated, - etc.) Some of the problems, can be minimized, but they require even more - careful analysis. - <p>As the reader will note this is a delicate configuration option, the - rule of thumb should be <b>not</b> to use ORB-per-thread unless it is really - required. <P> - - <li> - - <b>Collocation tables</b> -- Why would an application not want to - use the global collocation table? Because a collocated method - invocation is run in the client's thread-of-control. If objects - are to serve requests only at a well - known priority the application can be configured with the - ORB-per-thread option, and the object is activated only in the thread - (ORB) corresponding to the desired priority. But using a global table - would subert the priority assignment (because calls would run at the - priority of the client).</li><P> - - <li> <b>Single-threaded vs. Multi-threaded Connection Handlers</b> - -- The - <tt>Client_Connection_Handler</tt> is the component in TAO that writes - the requests to the underlying transport socket; this is also the - component that reads the response back from the server.</li> - - <p> - - While waiting for this response new requests to the local ORB can - arrive, this is the so-called nested upcall support. TAO supports two - mechanisms for handling nested upcalls, the default uses the - leader-follower model to allow multiple threads to wait on a single - reactor for several concurrent requests; sometimes this configuration - can be an overkill, if only one thread is using a reactor at the same - time a lighter weight implementation can be used. <p>This - configuration is controlled by the <tt>-ORBClientConnectionHandler</tt> - option, good opportunities to use this option are:<P> - - <ul> - <li> Single threaded servers</li> - - <li> Servers running in ORB-per-thread mode (pseudo single - threaded.)</li> - - <li> Pure clients that will never receive a request</li> - </ul><P> - -<li> - <b>Allocator for input CDR streams</b> -- Normally the application has no - access to this buffer, and it is only used on the demarshaling of arguments - (or results). It is almost always better to use the "<tt>-ORBInputCDRAllocator - null</tt>" option since it will allocate memory from a thread specific allocator - and it will not need locks to manage that memory.</li> - - <p>In some cases the user <i>may</i> gain access to the CDR stream - buffer: TAO makes no copies when demarshaling octet sequences, instead - the octet sequence simply points to the CDR buffer, since the octet - sequence does not own this buffer a copy must be made if the user - wants to keep the buffer after the upcall. - - <p>The user can, however, increase the reference count on the CDR - stream buffer, thus allowing her to extend the lifetime of this - buffer. Still passing this buffer to another thread and attempting to - release it in that thread will result in some memory leak or - corruption. Users willing to use this feature of TAO can still do so, - <b>if</b> they use a global allocator for their input CDR stream, but - that will introduce extra locking on the critical path. <p>As the - reader can see this is an option that has limited applicability and - requires careful consideration of the tradeoffs involved. -</ul> - -<hr> -<p>Back to the TAO <a href="components.html">component options and tuning documentation</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -</body> -</html> diff --git a/TAO/docs/dynany/index.html b/TAO/docs/dynany/index.html deleted file mode 100644 index 213d70799e6..00000000000 --- a/TAO/docs/dynany/index.html +++ /dev/null @@ -1,121 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<title>Dynamic Any Status</title> -<!-- $Id$ --> -</head> -<body text="#000000" bgcolor="#FFFFFF"> - -<!-- *********************************** --> -<a name="toc"><h2>Table of Contents</h2></a> -<ul> - <li><a href="#current">Current Status</a> - <li><a href="#issues">Known Issues</a> - <li><a href="#ongoing">Ongoing work</a> - <li><a href="#future">Future Work</a> - <li><a href="#completed">Completed Work</a> -</ul> -<!-- *********************************** --> - -<hr> -<center> -<h1> <a name="dynany"></a>Dynamic Any</h1> - -Point of contact: <a href="mailto: parsons@cs.wustl.edu">Jeff Parsons</a> - -<p>Last Update: June 11, 2001 </p> -</center> - - -<!-- ============================================================ --> -<a name="current"><h3>Current status:</h3></a> - -<ul> - - <li><p>Fully compliant with OMG 2.4.2 spec.</p> - </li> - - <li><p>Fully compatible with CorbaScript.</p> - </li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="issues"><h3>Known issues:</h3></a> - -<ul> - - <li><p>No known issues.</p> - </li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="ongoing"><h3>Ongoing Work:</h3></a> - -<ul> - - <li><p>Although performance is not usually an issue with dynamic anys, - opportunities to optimize will be exploited. Future work on - optimization of DII/DSI performance will also benefit dynamic - anys. - </p></li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="future"><h3>Future work:</h3></a> - -<ul> - - <li><p>Implementation of dynamic any classes for value types, boxed value - types, and fixed types, as these types themselves are implemented - in TAO (value types are partially implemented, but the implementation - does not include Any insertion/extraction operators or type codes). - </p></li> - - <li><p>Implementation of get and insert operations for abstract interfaces, - when abstract interfaces themselves are implemented in TAO. - </p></li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="completed"><h3>Completed Work:</h3></a> - -<!-- ************************************************************ --> -<!-- Please make sure you append new items at the end of the list --> -<!-- ************************************************************ --> - -<ul> - - <li><p>Transfer of dynany-specific code from the TAO library to the - TAO_DynamicAny library, in ACE_ROOT/TAO/tao/DynamicAny. - </p></li> - - <li><p>Overhaul of existing implementation of dynamic anys in TAO to comply - with changes to the dynamic any spec that appeared in CORBA 2.3.1, and - with additional changes that appeared in CORBA 2.4.2. - </p></li> - - <li><p>Expansion of existing dynamic any tests to included the added functionality. - </p></li> - -</ul> - diff --git a/TAO/docs/ec_options.html b/TAO/docs/ec_options.html deleted file mode 100644 index 382ea349b64..00000000000 --- a/TAO/docs/ec_options.html +++ /dev/null @@ -1,884 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Real-Time Event Channel Configuration</title> - <!-- $Id$--> - </head> - - <body> - <CENTER> - <h1>Real-Time Event Channel Configuration</h1> - </CENTER> - - <H3>Configuring the Event Channel at Compilation Time</H3> - - <P>TAO's Real-Time Event Channel can be configured at compilation - time to use a different payload than its default. To do so - there are several options: - </P> - - <UL> - <LI><P>To eliminate the <CODE>CORBA::Any</CODE> field in the - event payload you should define the - <CODE>TAO_LACKS_EVENT_CHANNEL_ANY</CODE> - macro when invoking the IDL compiler. - You can do as follows: -<PRE> -$ cd $TAO_ROOT/orbsvcs/orbsvcs -$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_ANY -</PRE> - </P> - </LI> - <LI><P>Similarly you can eliminate the octet sequence field in - the event payload using: -<PRE> -$ cd $TAO_ROOT/orbsvcs/orbsvcs -$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_OCTET_SEQUENCE -</PRE> - </P> - </LI> - <LI><P>Finally you can provide your own event payload, to do - this you should Replace the contents of the - <CODE>RtecDefaultEventData.idl</CODE> - and define some IDL structure named - <CODE>RtecEventData</CODE>. - For example, you could define you own event type as follows: -<PRE> -// Replace RtecDefaultEventData.idl with this: - -struct RtecEventData -{ - sequence<long> my_event_payload; -}; -</PRE> - </LI> - </UL> - - <H3>Run-time Configuration</H3> - - <P>The new implementation of the real-time event channel uses a - factory to build all the objects and strategies it requires. - The factory can be dynamically loaded using ACE Service - Configurator, this is extremely convenient because the factory - can also parse options in the Service Configurator script file. - </P> - - <P>There are currently several implementations of the factory. - <ul> -<li>The <em>default</em> factory supports all of - the options below and most of the potential values, except as - specifically indicated. -<li> - The <em>sched</em> factory defines new option values as indicated - below that allow the RTES to integrate with the Real-Time - Scheduling Service. Use of the <em>sched</em> factory requires - that you link in the TAO_RTSchedEvent library. -<li> - The <em>tpc</em> (thread per consumer) factory defines new - options values as indicated below. This - strategy is similar to the MT dispatching strategy in that it - separates the thread that receives the push() from a supplier - from the thread that does the eventual push() to the - consumer(s), but it differs from MT in that MT has a pool of - threads pulling from a single queue and ultimately potentially - servicing every consumer, whereas TPC has a queue for <em>each</em> - consumer and, thus, a single thread dedicated to pushing to that - consumer. This insures that a badly-behaved consumer <b>CANNOT</b> - have an adverse effect on the channel or supplier.<br> - To use this new strategy you will have to replace the call in your code - for <code>TAO_EC_Default_Factory::init_svcs()</code> with - <code>TAO_EC_TPC_Factory::init_svcs()</code>. - -<li> The <em>basic</em> and <em>null</em> factories are hard-coded - factories that do not support any configuration options. - They both define simple configurations that may enable some - applications to use the RTES in a smaller footprint. - See the files - <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Null_Factory.h</code> - and <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Basic_Factory.h</code> - for details. -</ul> - The - table below describes all of the options (and values) supported by - these factories. - </P> -<h3>Special Topic: Queue Configuration</h3> - <p> - In certain configurations such as <em>mt</em> and <em>tpc</em>, - the RTES implementation uses something called - <code>TAO_EC_Queue</code>, which is an in-memory queue that - separates threads that receive <code>push()</code> invocations - from suppliers from the threads that dispatch - <code>push()</code> invocations to consumers. A user of the - RTES can configure some behaviors of this queue as well as - behaviors when the queue reaches certain trigger points. The - configuration of these behaviors is a combination of - compile-time and run-time specification. - </p> - <p> - The queue itself has two trigger points for the number of - invocations in the queue: - <ul> - <li><em>low-water mark (LWM)</em>, a lower threshold below which the - queue allows more invocations to be placed into the queue; - <li><em>high-water mark (HWM)</em>, an upper threshold above which the - queue prevents more invocations from being added to the queue - </ul> - The values for these can be set at compile time via - <code>TAO_EC_QUEUE_LWM</code> and <code>TAO_EC_QUEUE_HWM</code> - for the low-water mark and high-water mark, respectively. - <p> - In addition, an application can specify what the RTES should do if a - queue reaches the HWM, i.e., fills up. This behavior is encapsulated in a - derivation of an <code>ACE_Service_Object</code>, called - <code>TAO_EC_Queue_Full_Service_Object</code>. The RTES looks - for a service object of a particular name (the default for this - name is in macro TAO_EC_DEFAULT_QUEUE_FULL_SERVICE_OBJECT_NAME, - which is "EC_QueueFullSimpleActions") and invokes - <code>queue_full_action()</code> on the instance. See class - <code>TAO_EC_Simple_Queue_Full_Action</code> in file - <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Dispatching_Task.h</code> - for an example. This particular example can be configured to - either <em>wait</em> or <em>discard</em> new invocations on - reaching the HWM. - </p> - - <H3>The configuration file</H3> - - <P>The real-time event channel uses the same service configurator - file that the ORB uses, the default name for this file is - <CODE>svc.conf</CODE>, but the ORB option - <CODE>-ORBSvcConf</CODE> can be used to override this. - The format of the file is described in detail in - the service configurator documentation, but the relevant section - for the event channel looks like this: - </P> - -<PRE> -# Comments go here... -# More comments if you want to... -static EC_Factory "-ECFiltering basic ....." -# ...and optionally... -static EC_QueueFullSimpleActions "[wait | discard]" -# ...or you can define your own TAO_EC_Queue_Full_Service_Object, -# give it whatever name you want and use -ECQueueFullServiceObject -# (see below) to specify that object's service configurator tag. -</PRE> - - <P>All the event service factory options start with - <CODE>-EC</CODE></P> - - - <H3>The options</H3> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - - <!-- <TR NAME="ECDispatching"> --> - <TR> - <TD><CODE>-ECDispatching</CODE> - <EM>dispatching_strategy</EM> - </TD> - <TD>Select the dispatching strategy used by the real-time - event service. The <EM>reactive</EM> strategy uses the - same thread that received the event from the supplier to - push the event to all the consumers.<br> - The <EM>priority</EM> strategy (sched factory only) uses - a prioritized pool - of threads and queries the scheduling service to select - the thread that dispatches each event.<br> - The <EM>mt</EM> strategy also uses a pool of threads, - but the thread to dispatch is randomly selected.<br> - <b>Does not apply to the <em>tpc</em> factory.</b> - </TD> - </TR> - - <!-- <TR NAME="ECDispatchingThreads"> --> - <TR> - <TD><CODE>-ECDispatchingThreads</CODE> - <EM>number_of_threads</EM> - </TD> - <TD>Select the number of threads used by the <EM>mt</EM> - dispatching strategy.<br> - <b>Does not apply to the <em>tpc</em> factory.</b> - </TD> - </TR> - - <!-- <TR NAME="ECQueueFullServiceObject"> --> - <tr> - <td><code>-ECQueueFullServiceObject</code> - <em>service_object_name</em> - </td> - <td> - Used to specify the name/tag in the service configurator - through which the RTEC should look for a "queue full - service object".<br> - <b>Will only have an effect on dispatch strategies that - use <code>TAO_EC_Queue</code>.</b> - </td> - </tr> - <!-- <TR NAME="ECFiltering"> --> - <TR> - <TD><CODE>-ECFiltering</CODE> - <EM>consumer_filtering_strategy</EM> - </TD> - <TD>Select the filtering strategy used by the consumers. - The <EM>null</EM> filtering strategy will build trivial - filters for all consumers. - The <EM>basic</EM> filtering strategy supports - disjunction, conjunction, logical and, negation, bitmask, - and timeout filters based on the subscriptions passed by - the consumer during the connect call. It only supports limited - nesting of filter groups. - The <EM>prefix</EM> filtering strategy supports - all filter types that the <EM>basic</EM> strategy does - and allows unlimited nesting of filter groups. - When using the <EM>prefix</EM> strategy, the source field of the - group filter must specify the number of children in the group. - The <EM>priority</EM> filtering strategy (sched factory only) - supports the same - features as the <EM>basic</EM> filtering strategy, but it - also collaborates with the scheduling service to build the - dependency graph. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierFiltering"> --> - <TR> - <TD><CODE>-ECSupplierFiltering</CODE> - <EM>supplier_filtering_strategy</EM> - </TD> - <TD>The event channel can also perform some filtering close - to the suppliers by minimizing the number of consumers - that are tested for given event. - If the strategy is <EM>null</EM> then a global collection - of consumers is maintained and each event is filtered by - each consumer. - If the strategy is <EM>per-supplier</EM> then the EC uses - the supplier publications and the consumer subscriptions - to determine which consumers could potentially be - interested in events for each supplier. - This set of consumers is usually smaller than the complete - set and it is thus faster to traverse it, but keeping more - collections of consumers increases the connection and - disconnection time as well as the memory requirements. - </TD> - </TR> - - <!-- <TR NAME="ECTimeout"> --> - <TR> - <TD><CODE>-ECTimeout</CODE> - <EM>timeout_strategy</EM> - </TD> - <TD>A consumer can request that the event channel generate - periodic or oneshot timeout events. - This option controls the strategy to generate the - timeouts, - using <EM>reactive</EM> the same reactor used for the ORB - is used by the event service. - The <EM>priority</EM> strategy (sched factory only) uses a - prioritized group of - threads, timeouts with higher rate are generated by - threads of higher priority. - <BR><B>NOTE: The <EM>priority</EM> strategy is not - implemented</B> - </TD> - </TR> - - <!-- <TR NAME="ECObserver"> --> - <TR> - <TD><CODE>-ECObserver</CODE> - <EM>observer</EM> - </TD> - <TD>The event channel uses the Observer pattern to report - changes in the subscriptions and publications of its - suppliers and consumers; this is especially useful in the - implementation of event channel gateways. - The user can disable this feature by selecting the - <EM>null</EM> strategy; - whereas the <EM>basic</EM> strategy provides a simple, yet - efficient implementation. <EM>reactive</EM> provides a - strategy in which an observer that is unreachable is removed - from the observer list. - <BR><B>NOTE:<B> The default is to have the feature disabled. - </TD> - </TR> - - <!-- <TR NAME="ECScheduling"> --> - <TR> - <TD><CODE>-ECScheduling</CODE> - <EM>scheduling_strategy</EM> - </TD> - <TD>The event channel can collaborate with the scheduling - service to build the dependency list between the consumers - and the suppliers. - If the <EM>null</EM> scheduling strategy is selected this - feature is disabled, - the <EM>priority</EM> strategy (sched factory only) enables this feature. - <BR><B>NOTE:<B> The default is to have the feature disabled. - </TD> - </TR> - - <!-- <TR NAME="ECProxyConsumerLock"> --> - <TR> - <TD><CODE>-ECProxyConsumerLock</CODE> - <EM>lock_type</EM> - </TD> - <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or - <EM>recursive</EM>) to synchronize access to the - ProxyPushConsumer state. - </TD> - </TR> - - <!-- <TR NAME="ECProxySupplierLock"> --> - <TR> - <TD><CODE>-ECProxySupplierLock</CODE> - <EM>lock_type</EM> - </TD> - <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or - <EM>recursive</EM>) to synchronize access to the - ProxyPushSupplier state. - </TD> - </TR> - - <!-- <TR NAME="ECUseORBId"> --> - <TR> - <TD><CODE>-ECUseORBId</CODE> - <EM>orbid</EM> - </TD> - <TD>Set the name of the ORB used by the event service, only - useful in applications that create multiple ORBs and - activate the event service in one of them. - </TD> - </TR> - - <!-- <TR NAME="ECConsumerControl"> --> - <TR> - <TD><CODE>-ECConsumerControl</CODE> - <EM>policy</EM> - </TD> - <TD>Select the consumer control policy (<EM>null</EM> or - <EM>reactive</EM>) to detect and discard broken consumers. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierControl"> --> - <TR> - <TD><CODE>-ECSupplierControl</CODE> - <EM>policy</EM> - </TD> - <TD>Select the supplier control policy (<EM>null</EM> or - <EM>reactive</EM>) to detect and discard broken suppliers. - </TD> - </TR> - - <!-- <TR NAME="ECConsumerControlPeriod"> --> - <TR> - <TD><CODE>-ECConsumerControlPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive - consumer control policy (set <EM>ECConsumerControl</EM> to - <EM>reactive</EM>) to poll the state of the consumers. - When set to 0 there is no polling but the - reactive strategy is in place. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierControlPeriod"> --> - <TR> - <TD><CODE>-ECSupplierControlPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive - supplier control policy (set <EM>ECSupplierControl</EM> to - <EM>reactive</EM>) to poll the state of the suppliers. - When set to 0 there is no polling but the - reactive strategy is in place. - </TD> - </TR> - - <!-- <TR NAME="ECConsumerControlTimeout"> --> - <TR> - <TD><CODE>-ECConsumerControlTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD>Set the timeout period (in microseconds) used by the reactive - consumer control policy (set <EM>ECConsumerControl</EM> to - <EM>reactive</EM>) to detect a timeout when polling the state - of the consumers. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierControlTimeout"> --> - <TR> - <TD><CODE>-ECSupplierControlTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD>Set the timeout period (in microseconds) used by the reactive - supplier control policy (set <EM>ECSupplierControl</EM> to - <EM>reactive</EM>) to detect a timeout when polling the state - of the suppliers. - </TD> - </TR> - - <!-- <TR NAME="ECProxyPushConsumerCollection"> --> - <TR> - <TD><CODE>-ECProxyPushConsumerCollection</CODE> - <EM>flag[:flags]</EM> - </TD> - <TD><P>Configure the data structure and strategies used to - implement collections of - <CODE>ProxyPushConsumers</CODE>. - The argument is a colon separated list of flags, with - the following semantics: - <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0"> - <TR><TH>Flag</TH><TH>Description</TH> - </TR> - <TR> - <TD>MT</TD> - <TD>Use regular mutexes and/or condition - variables for serialization. - </TD> - </tr> - <TR> - <TD>ST</TD> - <TD>Use null mutexes and/or condition - variables for serialization. - </TD> - </tr> - <TR> - <TD>LIST</TD> - <TD>Implement the collection using an ordered list, - fast for iteration (i.e. during event dispatching), - but slow for insertion and removal (i.e. when - clients connect and disconnect from the EC). - </TD> - </tr> - <TR> - <TD>RB_TREE</TD> - <TD>Implement the collection using a Red-Black tree, - slow for iteration (i.e. during event dispatching), - but fast for insertion and removal (i.e. when - clients connect and disconnect from the EC). - </TD> - </tr> - <TR> - <TD>IMMEDIATE</TD> - <TD>Threads block until they can execute a change on - the data structure, the system must use other - approaches to guarantee that the iterators are not - invalidated during event dispatching. For example, - use a separate dispatching thread. Using this option - with the reactive values for any of the - -ECSupplierControl, -ECConsumerControl, or - -ECDispatching options may cause deadlocks. - </TD> - </tr> - <TR> - <TD>COPY_ON_READ</TD> - <TD>Before initiating an iteration to dispatch events - (or similar tasks) a copy of the complete collection - is performed. - This solves most of the synchronization problems, - but introduces a significant source of overhead and - priority inversions on the critical path. - </TD> - </tr> - <TR> - <TD>COPY_ON_WRITE</TD> - <TD>Similar to the previous one, but the copy is only - performed when needed. - </TD> - </tr> - <TR> - <TD>DELAYED</TD> - <TD>Threads that need to change the collection can - detect if that change will invalidate iterators used - by other threads. - If so, the thread posts the change on a queue that - is executed once the collection is no longer in - use. - </TD> - </TR> - </TABLE> - </P> - </TD> - </TR> - - <!-- <TR NAME="ECProxyPushSupplierCollection"> --> - <TR> - <TD><CODE>-ECProxyPushSupplierCollection</CODE> - <EM>flag[:flags]</EM> - </TD> - <TD><P>Configure the data structure and strategies used to - implement collections of <CODE>ProxyPushSupplier</CODE> - objects. - Use the same arguments as with the - <CODE>ECProxyPushConsumerCollection</CODE> option. - </P> - </TD> - </TR> - - <!-- <TR NAME="ECPushSupplierSet"> --> - <TR> - <TD><CODE>-ECPushSupplierSet</CODE> - </TD> - <TD><P>Obsolete option, ignored. - </P> - </TD> - </TR> - - <!-- <TR NAME="ECConsumerAdminLock"> --> - <TR> - <TD><CODE>-ECConsumerAdminLock</CODE> - </TD> - <TD>Obsolete option, ignored in the current version. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierAdminLock"> --> - <TR> - <TD><CODE>-ECSupplierAdminLock</CODE> - </TD> - <TD>Obsolete option, ignored in the current version. - </TD> - </TR> - - <!-- <TR NAME="ECConsumerValidateConnection"> --> - <TR> - <TD><CODE>-ECConsumerValidateConnection</CODE> - <EM>validate_connection: 0 | 1</EM> - </TD> - <TD>When this option is set the connection from the Event Channel - to the consumer will be created during the connect of the - consumer, just before the consumer is added to the consumer - list. By default - the Event Channel will create the connection to the consumer at - the moment the first event is pushed to the consumer. - When the network is heavily loaded during this connect and a new event - is pushed before the connection is establed, a new create connection - request is done. When having very high connection establishment - time (for example running on a WAN) and an interval that is much - smaller than the connection establishment time it is wise to - set this option. Else you get dozens of new connection request - that can result in a stack overflow. Another option is to use BiDIR - GIOP so that there is only one connection between Rtec and consumer - but for this the Rtec and the consumer must be changed to set the - BiDIR Policy, this is not implemented at this moment. - </TD> - </TR> - - </TABLE> - </P> - - <H3>The constructor</H3> - - <P>The <CODE>TAO_EC_Event_Channel</CODE> class implements the - <CODE>RtecEventChannelAdmin::EventChannel</CODE> interface; - this class takes one mandatory and two optional parameters in - its constructor: - </P> - -<PRE> - TAO_EC_Event_Channel (const TAO_EC_Event_Channel_Attributes& attributes, - TAO_EC_Factory* factory = 0, - int own_factory = 0); -</PRE> - - <P>The <CODE>factory</CODE> is an optional parameter to override - the default strategy factory used by the event channel, - the event channel will destroy the factory if the - <CODE>own_factory</CODE> argument is true. - </P> - - <P>The <CODE>attributes</CODE> parameter can be used to fine tune - some of the algorithms and strategies used by the event channel, - the default values are probably OK for most applications. - Notice that the attributes include the POA used to activate the - ConsumerAdmin, SupplierAdmin, ProxyPushConsumer and - ProxyPushSupplier objects; - these POAs must have the <CODE>IMPLICIT_ACTIVATION</CODE> and the - <CODE>SYSTEM_ID</CODE> policies (as the RootPOA does). - </P> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR><TH>Attribute</TH><TH>Description</TH></TR> - - <TR><TD><CODE>consumer_reconnect</CODE></TD> - <TD>If the attribute is not zero then the same consumer can - call <CODE>connect_push_consumer</CODE> on its - ProxyPushSupplier multiple times to change its - subscriptions; - this is usually more efficient that disconnecting and - connecting again. - </TD> - </TR> - - <TR><TD><CODE>supplier_reconnect</CODE></TD> - <TD>If the attribute is not zero then the same supplier can - call <CODE>connect_push_supplier</CODE> on its - ProxyPushConsumer multiple times to change its - publications; - this is usually more efficient that disconnecting and - connecting again. - </TD> - </TR> - - <TR><TD><CODE>busy_hwm</CODE></TD> - <TD>When the delayed flag is set on proxy collections, - this flag controls the maximum - number of threads that can simultaneously iterate over the - collection before blocking. - It can be used to avoid starvation in delayed updates on - the collection. - </TD> - </TR> - - <TR><TD><CODE>max_write_delay</CODE></TD> - <TD>When the delayed flag is set on proxy collections, - this flag controls the maximum - number of threads that will initiate dispatching - <B>after</B> a change has been posted. - Any thread after that is blocked until the operations are - performed. - It can be used to completely stop starvation of delayed - updates on the collection. - </TD> - </TR> - - <TR><TD><CODE>scheduler</CODE></TD> - <TD>Most configurations of the real-time event channel do - not require an scheduler. - If any of the strategies that require an scheduling - service is selected then this attribute should be set - appropiately. - </TD> - </TR> - - <TR><TD><CODE>supplier_poa</CODE></TD> - <TD>The POA used by the event channel to activate SupplierAdmin - and SupplierProxy objects. - </TD> - </TR> - - <TR><TD><CODE>consumer_poa</CODE></TD> - <TD>The POA used by the event channel to activate ConsumerAdmin - and ConsumerProxy objects. - </TD> - </TR> - - <TR><TD><CODE>disconnect_callbacks</CODE></TD> - <TD>If not zero, then the event channel sends disconnect - callbacks when a disconnect method is called on a Proxy. - For example, if a consumer calls - disconnect_push_supplier() on its proxy the EC - invokes disconnect_push_consumer() on the consumer. - An analogous call is also made for suppliers when this - attribute is set. - By default, these callbacks are not made in this situation. - </TD> - </TR> - </TABLE> - </P> - - <H3>Configuring the IIOP Gateway</H3> - - <P>The <CODE>TAO_EC_Gateway_IIOP_Factory</CODE> is the factory for - the <CODE>TAO_EC_Gateway_IIOP</CODE> class. This factory can be - used to configure the settings of the IIOP Gateway using the - svc.conf file. The contents looks like this: - </P> - -<PRE> -# Comments go here... -# More comments if you want to... -static EC_Gateway_IIOP_Factory "-ECGIIOPConsumerECControl null ....." -</PRE> - - <P>All the IIOP Gateway factory options start with - <CODE>-ECGIIOP</CODE></P> - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - - <!-- <TR NAME="ECGIIOPConsumerECControl"> --> - <TR> - <TD><CODE>-ECGIIOPConsumerECControl</CODE> - <EM>policy</EM> - </TD> - <TD>Select the consumer ec control policy (<EM>null</EM> or - <EM>reactive</EM> or <EM>reconnect</EM>) to detect and handle - broken consumer ec's. - </TD> - </TR> - <!-- <TR NAME="ECGIIOPConsumerECControlPeriod"> --> - <TR> - <TD><CODE>-ECGIIOPConsumerECControlPeriod</CODE> - <EM>period</EM> - </TD> - <TD>Set the period (in microseconds) used by the reactive and reconnect - consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to - <EM>reactive</EM> or <EM>reconnect</EM>) to poll the state of the consumer ec. - When set to 0 there is no polling but the - reactive strategy is in place. - </TD> - </TR> - - <!-- <TR NAME="ECGIIOPConsumerECControlTimeout"> --> - <TR> - <TD><CODE>-ECGIIOPConsumerECControlTimeout</CODE> - <EM>timeout</EM> - </TD> - <TD>Set the timeout period (in microseconds) used by the reactive and reconnect - consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to - <EM>reactive</EM> or <EM>reconnect</EM>) to detect a timeout when polling the state - of the consumer ec. - </TD> - </TR> - - <!-- <TR NAME="ECGIIOPUseORBId"> --> - <TR> - <TD><CODE>-ECGIIOPUseORBId</CODE> - <EM>orbid</EM> - </TD> - <TD>Set the name of the ORB used by the event gateway, only - useful in applications that create multiple ORBs and - activate the gateway in one of them. - </TD> - </TR> - - <!-- <TR NAME="ECGIIOPUseTTL"> --> - <TR> - <TD><CODE>-ECGIIOPUseTTL</CODE> - <EM>use_ttl: 0 | 1</EM> - </TD> - <TD>Set whether the IIOP Gateway uses the TTL or not. - This is 1 by default. When set to 0 make sure that - no recursive structure is build between ec's, else an - event can keep looping for ever. Useful when there are no - recursive structures and we want the gateway to - transfer all events independent of their TTL because suppliers - can be unaware about the maximum number of hops. In case - this option is 0, the TTL in the event isn't decremented - by the gateway also. - </TD> - </TR> - - <!-- <TR NAME="ECGIIOPUseConsumerProxyMap"> --> - <TR> - <TD><CODE>-ECGIIOPUseConsumerProxyMap</CODE> - <EM>use_consumer_proxy_map: 0 | 1</EM> - </TD> - <TD>Set whether the IIOP Gateway uses a map with a proxy - push consumer for each unique source id or not. This is 1 - by default meaning that a map is used. When set to 0 the - gateway will just use one proxy push consumer to push - events to the consumer ec. This options is useful when - a lot of different source id's are used but there is no - need for a different proxy push consumer for each source id. - Setting this option to 0 then improves the performance. - </TD> - </TR> - </TABLE> - </P> - - <H3>The commandline arguments</H3> - - The Event_Service executable has several commandline arguments you can use. - The following arguments are available. - - <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Option</TH> - <TH>Description</TH> - </TR> - - <!-- <TR NAME="-d"> --> - <TR> - <TD><CODE>-n</CODE> - <EM>service_name</EM> - </TD> - <TD>The name with which the Event Service registers itself in the - Naming Service. - </TD> - </TR> - <!-- <TR NAME="-o"> --> - <TR> - <TD><CODE>-o</CODE> - <EM>ior_file_name</EM> - </TD> - <TD>The file to which the IOR of the Event Service will be written. - </TD> - </TR> - - <!-- <TR NAME="-p"> --> - <TR> - <TD><CODE>-p</CODE> - <EM>pid_file_name</EM> - </TD> - <TD>The process id of the Event Service will be written to this - file - </TD> - </TR> - - <!-- <TR NAME="-q"> --> - <TR> - <TD><CODE>-q</CODE> - <EM>ec_object_id</EM> - </TD> - <TD>The object ID for the Event Channel that will be used - when a Persistent IOR is generated - </TD> - </TR> - - <!-- <TR NAME="-b"> --> - <TR> - <TD><CODE>-b</CODE> - <EM></EM> - </TD> - <TD>Use BiDIR GIOP - </TD> - </TR> - - <!-- <TR NAME="-x"> --> - <TR> - <TD><CODE>-x</CODE> - <EM></EM> - </TD> - <TD>Don't register the Event Service to the Naming Service - </TD> - </TR> - - <!-- <TR NAME="-s"> --> - <TR> - <TD><CODE>-s</CODE> - <EM>global|local|none</EM> - </TD> - <TD>Which scheduler should be used. The default is <CODE>none</CODE>. - With <CODE>local</CODE> an in process scheduler is created. With - <CODE>global</CODE> a scheduler is retrieved from the Naming Service - </TD> - </TR> - </TABLE> - </P> - - <P><HR><P> - - Back to the TAO <A HREF="index.html">components documentation</A>. - - <!--#include virtual="/~schmidt/cgi-sig.html" --> - -<!-- <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address>--> -<!-- Created: Thu Jul 1 21:44:28 CDT 1999 --> -<!-- hhmts start --> -Last modified: Tue Oct 18 13:13:54 CDT 2005 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/es_configs.html b/TAO/docs/es_configs.html deleted file mode 100644 index 79e891026fe..00000000000 --- a/TAO/docs/es_configs.html +++ /dev/null @@ -1,35 +0,0 @@ -<!-- $Id$ --> -<!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.5 [en] (WinNT; I) [Netscape]"> -<title>Configuring TAO's Components</title> -</head> - -<body text="#000000" bgcolor="#FFFFFF" link="#000FFF" vlink="#FF0F0F"> - -<hr> -<h3>Configuring TAO's Event Services</h3> - - <P>The following documentation is available on TAO's Event Services:</P> - - <UL> - <LI><A HREF="ec_options.html">Real-time Event Channel Configuration</A> describes the - options available to configure TAO's Real-time Event - Service. <P> - - <LI><A HREF="cec_options.html">CoS Event Channel Configuration</A> - describes the options available to configuration TAO's CoS - Event Service.<P> - - </UL> - </BODY> - -<P><HR><P> -Back to the TAO <A HREF="index.html">documentation index</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> - -</HTML> diff --git a/TAO/docs/events_tutorial.html b/TAO/docs/events_tutorial.html deleted file mode 100644 index a631d4503ab..00000000000 --- a/TAO/docs/events_tutorial.html +++ /dev/null @@ -1,1799 +0,0 @@ -<html> -<!-- $Id$ --> -<head> -<title>Using the Real-Time Event Service</title> -</head> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<br> -<br> - -<center> -<h1>Using the Real-Time Event Service</h1><P> - -<A HREF="http://www.cs.wustl.edu/~cdgill/">Chris Gill</a>, -<A HREF="http://www.cs.wustl.edu/~harrison/">Tim Harrison</a>, and -<A HREF="http://www.cs.wustl.edu/~coryan/">Carlos O'Ryan</a><br><br> - -<A HREF="mailto:cdgill@cs.wustl.edu">cdgill@cs.wustl.edu</a>, -<A HREF="mailto:harrison@cs.wustl.edu">harrison@cs.wustl.edu</a>, and -<A HREF="mailto:coryan@cs.wustl.edu">coryan@cs.wustl.edu</a><br> -</center> - -<br> -<br> - -<P><HR><P> -<!-- ************************************************************ --> - -<center> -<table cellpadding=10 border=0 cellspacing=4> -<tr><td> -<h2><a name="Section0">Overview</a></h2> -<BR> -<BR> -<tr><td> -<h3>Contents</h3> -<BR> -<ol> - <li> <a href="events_tutorial.html#Section0">Overview</a> - <li> <a href="events_tutorial.html#Section1">The COS Event Model</a> - <li> <a href="events_tutorial.html#Section2">Real-Time Event Service Enhancements</a> - <li> <a href="events_tutorial.html#Section3">The Real-Time Event Service</a> - <li> <a href="events_tutorial.html#Section4">Developing Consumers</a> - <li> <a href="events_tutorial.html#Section5">Developing Suppliers</a> - <li> <a href="events_tutorial.html#Section6">Caring For Your Event Channel</a> - <li> <a href="events_tutorial.html#Section7">Sample Applications</a> - <li> <a href="events_tutorial.html#Section8">Reference Materials</a> -</ol> - -<P><HR><P> -<tr><td> -<h3>Introduction</h3> -<BR> -This material is intended to provide an introduction to the COS Event Model, -the Real-Time extensions to that model in TAO, and a set of examples that -illustrate the techniques used to build systems using these models. The CORBA -Event Service provides a flexible model for asynchronous communication among -objects. However, the standard CORBAEvent Service specification lacks -important features required by real-time applications. These features include -event filtering, event correlation, and periodic event processing.<P> - -The standard CORBA operation invocation model supports twoway, oneway, -and deferred synchronous interactions between clients and servers. -The primary strength of the twoway model is its intuitive mapping onto -the <code>object->operation()</code> paradigm supported by OO languages. -In principle, twoway invocations simplify the development of -distributed applications by supporting an implicit request/response -protocol that makes remote operation invocations transparent to the -client. <P> - -In practice, however, the standard CORBA operation invocation models -are too restrictive for real-time applications. In particular, these -models lack asynchronous message delivery, do not support timed -invocations or group communication, and can lead to excessive polling -by clients. Moreover, standard oneway invocations might not implement -reliable delivery and deferred synchronous invocations require the use -of the CORBA Dynamic Invocation Interface (DII), which yields -<A HREF="http://www.cs.wustl.edu/~schmidt/GLOBECOM-96.ps.gz">excessive -overhead</A> for most real-time applications. <P> - -The Event Service is a CORBA Object Service (COS) that is designed to -alleviate some of the restrictions with standard CORBA invocation -models. In particular, the COS Event Service supports asynchronous -message delivery and allows one or more suppliers to send messages to -one or more consumers. Event data can be delivered from suppliers to -consumers without requiring these participants to know about each -other explicitly. <P> - -There are two models (<EM>i.e.</EM>, <EM>push</EM> vs. <EM>pull</EM>) -of participant collaborations in the COS Event Service architecture. -This material focuses on real-time enhancements to the push model, which -allows suppliers of events to initiate the transfer of event data to -consumers. Suppliers push events to the Event Channel, which in turn -pushes the events to consumers. <P> - -Suppliers use Event Channels to push data to consumers. Likewise, -consumers can explicitly pull data from suppliers. The push and pull -semantics of event propagation help to free consumers and suppliers -from the overly restrictive synchronous semantics of the standard -CORBA twoway communication model. In addition, Event Channels can -implement group communication by serving as a replicator, broadcaster, -or multicaster that forward events from one or more suppliers to -multiple consumers.<p> - -</table> -</center> - -<hr><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td align=center> -<center><h2><a name="Section1">The COS Event Model</a></h2></center> -</table></center> - -<table cellpadding=1 border=0 cellspacing=4> -<h3>Relationships Between Modules</h3> - -The role of each component in the COS Event Model is outlined -below:<P> - -<ul> - <li> <b><i>EventChannel</i></b> -- The EventChannel interface provides - two factory methods, which allow applications to obtain consumer and - supplier administration objects, respectively, and use them to create - the other objects described below, to connect to the event channel. <P> - - <li> <b><i>SupplierAdmin</i></b> -- The SupplierAdmin interface provides - factory methods which create the appropriate supplier proxy objects. <P> - - <li> <b><i>ConsumerAdmin</i></b> -- The ConsumerAdmin interface provides - factory methods which create the appropriate consumer proxy objects. <P> - - <li> <b><i>ProxyPullSupplier</i></b> -- The ProxyPullSupplier - interface is used by consumers in the pull model to connect and - disconnect from the channel. This interface inherits from the - PullSupplier interface, and acts as a proxy for the suppliers - from which the channel will pull events. <P> - - <li> <b><i>ProxyPushSupplier</i></b> -- The ProxyPushSupplier - interface is used by consumers in the push model to connect and - disconnect from the channel. This interface inherits from the - PushSupplier interface, and acts as a proxy for the suppliers - which will push events to the channel. <P> - - <li> <b><i>ProxyPullConsumer</i></b> -- The ProxyPullConsumer - interface is used by suppliers in the pull model to connect and - disconnect from the channel. This interface inherits from the - PullConsumer interface, and acts as a proxy for the consumers - on whose behalf the channel will pull events. <P> - - <li> <b><i>ProxyPushConsumer</i></b> -- The ProxyPushConsumer - interface is used by suppliers in the push model to connect and - disconnect from the channel. This interface inherits from the - PushConsumer interface, and acts as a proxy for the consumers - to which the channel will push events. <P> - - <li> <b><i>PullSupplier</i></b> -- The PullSupplier interface provides - the necessary methods of a supplier of events in the pull model. <P> - - <li> <b><i>PushSupplier</i></b> -- The PushSupplier interface provides - the necessary methods of a supplier of events in the push model. <P> - - <li> <b><i>PullConsumer</i></b> -- The PullConsumer interface provides - the necessary methods of a consumer of events in the pull model. <P> - - <li> <b><i>PushConsumer</i></b> -- The PushConsumer interface provides - the necessary methods of a consumer of events in the push model. <P> -</ul> - -<tr><td> -</table> -<br> -<br> -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td align=center> -<center><IMG SRC="http://www.cs.wustl.edu/~schmidt/gifs/ec_participants2.gif"></center> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3>The Push Model</h3> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~schmidt/gifs/ec_push.gif"></center> - -<tr><td> -<UL> - <LI> Consumers - Ultimate targets of events - <LI> Suppliers - Generate events - <LI> Event Channel - Decouple consumers and suppliers by propagating - events to consumers on behalf of suppliers -</UL> -</table></center> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> - -<h2><a name="Section2">Real-Time Event Service Enhancements</a></h2> - -<tr><td> -<ul> - <li> <b><i>Prioritized dispatching within preemption - classes</i></b> -- The current implementation can dispatch - events in the same queue by their order of importance, which is - necessary to support priorities within a rate group. <p> - - <li> <b><i>Suspend/resume</i></b> -- If a consumer's event - dependencies change at run-time, it can utilize the - suspend/resume functionality through the new - <code>ProxyPushSupplier::suspend</code> and - <code>ProxyPushSupplier::resume</code> methods. When a - consumer invokes <code>ProxyPushSupplier::suspend</code>, the - dependencies registered with that proxy will be disabled until - the <code>resume</code> methods is called. These enhancements - allow run-time flexibility of event dependencies, but maintains - the determinism required by the system scheduling policy (i.e., - consumers can not add and remove dependencies at run-time - - just suspend and resume them).<p> - - <LI> <B><I>Event data model</I></B> -- The data model may use - unions, untyped buffers, or type anys.<P> - -<LI> <B><I>Event filtering</I></B> -- Consumers may register for -events based on event type, or supplier id. The event channel filters events -based on these registrations, to ensure efficient event delivery.<P> - -<LI> <B><I>Event correlation</I></B> -- Consumers may register -for event delivery based on conjunctive or disjunctive sets of events. Conjunctive -registrations cause the event channel to notify the consumer when <I>all</I> -events in the set have arrived. Disjunctive registrations cause the event channel -to notify the consumer when <I>any</I> event in the set has arrived.<P> - -<LI> <B><I>Periodic event processing</I></B> -- Consumers -may register for suppliers based on timed events. Periodic suppliers push events -into the channel at well defined intervals.<P> - - <LI> <B><I>Active consumers and suppliers</I></B> -- See - <a href="events_tutorial.html#Section3">The Real-Time Event Service</a><P>. - -</ul> -</table> -</center> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td align=center> -<h2><a name="Section3">The Real-Time Event Service</a></h2> -</table></center> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3>Real-Time ORB and Services</h3> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~schmidt/gifs/corbaopt10.gif"></center> - -<br> -<center><tr><td> -<ul> - <li> Real-time event dispatching<P> - <UL> - <LI> Priority-based queueing and preemption mechanisms<P> - </UL> - <li> Centralized event filtering and correlation<P> - <ul> - <LI> Source/type-based filtering<P> - <LI> Conjunction/Disjunction (AND/OR) correlations<P> - </ul> - - <li> Periodic and Aperiodic processing <P> - <UL> - <LI> Canonical timeouts<P> - <LI> Dependency timeouts - </UL> -</ul> -</center> -</table></center> -<br> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td align=center> -<h3>Real-Time Event Service Internals</h3> -<BR> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~schmidt/gifs/ec_dispatching.gif"></center> -</table></center> -<br> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3>Characteristics of Real-Time Push Event Service Participants</h3> - -<tr><td> -Two major roles are played by the participants in a real-time push event -service.<P> - -<tr><td> -The first role is that of an event consumer, which receives events from the -event channel. A consumer specifies the type and/or source id for each event -it is interested in receiving.<P> - -In hard real-time applications, a consumer must also specify RT_Info data for -each event it is interested in receiving, and any other events on which that -event depends. The RT_Info structure resides in the Scheduler, and is -accessed through the scheduler interface. A unique handle is returned to the -consumer when an RT_Info is created, which can then be used to set the -information in the RT_Info. An RT_Info handle may also be obtained via the -Scheduler's lookup method.<P> - -<tr><td> -The second role is that of an event supplier, which generates events and -passes them into the event channel. A supplier must specify its source id, -and the type of each event it will generate. - -<tr><td> -In hard real-time applications, a supplier must also specify RT_Info data for -the events it will generate. In particular, it must specify the maximum rate -at which it will generate each event. This information is used by a real-time -scheduler to assign appropriate dispatch priorities.<P> - -<tr><td> -Note that the event channel may also be configured to use a null scheduling service. This will -cause all operations to be dispatched at the same priority, and will not require the application -to specify worst case execution times, periods, etc. - -<tr><td> -The consumer and supplier roles may be combined, as illustrated in the tables below. There are -two main cases in which the roles are combined: a passive one termed Consumer/Supplier which -borrows a thread of execution to produce events, and an active one termed Supplier/Consumer -which produces events in its own thread. Both consume events and produce events.<P> -</table></center> - -<br> -<br> -<center><table cellpadding=4 border=1 cellspacing=4> -<h4>EC Roles and Specified RT_Info Contents</h4> - -<tr> -<th>EC Roles -<th>RT_Info Contents -<th>Domain Examples -</tr> - -<tr> -<td> Consumer -<td> dependencies (and optionally, importance) -<td> Display, Exception & Maintenance Logs -</tr> - -<tr> -<td> Consumer/Supplier -<td> dependencies (and optionally, importance) -<td> Navigation Component (NAV) -</tr> - -<tr> -<td> Supplier/Consumer -<td> rate, dependencies (and optionally, importance) -<td> Kalman Filter -</tr> - -<tr> -<td> Supplier -<td> rate -<td> Operator Control Panel, EC Reactor Threads -</tr> - -</table></center> -<BR> -<BR> - - -<center><table cellpadding=1 border=1 cellspacing=4> -<h4>EC Roles and Scheduler Dependency Chain</h4> - -<tr> -<th> EC Roles -<th> Scheduler Dependency Chain -</tr> - -<tr> -<td> Pure Consumer -<td> root node -</tr> - -<tr> -<td> Consumer/Supplier -<td> internal node -</tr> - -<tr> -<td> Supplier/Consumer -<td> internal node -</tr> - -<tr> -<td> Pure Supplier -<td> leaf node -</tr> - -</table></center> -<BR> -<BR> - -<center><table cellpadding=1 border=1 cellspacing=4> -<h4>EC Roles, Threading, and CORBA Roles</h4> - -<tr> -<th> EC Roles -<th> Activity -<th> Thread Behavior -<th> CORBA Roles -</tr> - -<tr> -<td> Pure Consumer -<td> Passive -<td> Threads optional, "internal", wait for an event to occur -<td> Servant -</tr> - -<tr> -<td> Consumer/Supplier -<td> Passive -<td> Threads optional, "internal", wait for an event to occur -<td> Client and/or Servant -</tr> - -<tr> -<td> Supplier/Consumer -<td> Active -<td> Threads required and visible to EC: consume events and actively produce other events -<td> Client and/or Servant -</tr> - -<tr> -<td> Pure Supplier -<td> Active -<td> Threads required and visible to EC: actively produce events -<td> Client -</tr> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~cdgill/ec_roles.GIF"></center> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~cdgill/ec_roles2.GIF"></center> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~cdgill/ec_backbone.GIF"></center> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~cdgill/distributed_ec_roles.GIF"></center> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><IMG SRC="http://www.cs.wustl.edu/~cdgill/ec_orb_view.GIF"></center> -</table></center> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<center><h2><a name="Section4">Developing Consumers</a></h2></center> -<br> -<ul> - <li> <a href="events_tutorial.html#Section4_1">Providing QoS Information</a> - <li> <a href="events_tutorial.html#Section4_2">Connecting Consumers to the Event Channel</a> - <li> <a href="events_tutorial.html#Section4_3">Receiving Events</a> - <li> <a href="events_tutorial.html#Section4_4">Disconnecting Consumers from the Event Channel</a> -</ul> -</table></center> - -<P><hr width="75%"><P> <!-- intra-section separator --> -<center><table cellpadding=1 border=0 cellspacing=4> -<center><h3><a name="Section4_1">Providing QoS Information</a><h3></center><p> - -<tr><td> -The following steps are only necessary for applications that make use of the -Event Service's hard real-time features. Applications that do not need these -features and are configured with a null scheduler may skip the following -operations on the scheduling server. - -<tr><td> -For each operation, a Consumer should provide the worst case, expected, and -cached execution time for that operation. It must also specify criticality and -importance values for each operation. A real-time scheduler uses this information -to order dispatches within a set of operations whose dependencies have been met. - -<tr><td> -If it is a Consumer/Supplier (one which consumes an event and passively generates -one or more events from the thread in which it was called, as illustrated in the -tables above), it must provide dependencies on one or more other events to the -scheduler. - -<tr><td> -If it is a Supplier/Consumer (one which consumes an event and actively generates -one or more events from its own thread, as illustrated in the tables above), it -must also specify the rate at which it will generate the new events by passing a -positive value in the period argument to the scheduler set method. It may also -indicate a positive number of threads in which the dispatch will be made. If the -number of threads given is zero, but a period is specified, the number of threads -defaults to 1. - -</table> -</center> - - -<center><table cellpadding=1 border=0 cellspacing=4> - -<tr><td> -<pre> - - // Obtain a reference to the scheduler server. - RtecScheduler::Scheduler_ptr server = - ACE_Scheduler_Factory::server (); - - // Create new RT_Info descriptors for three events. - - RtecScheduler::handle_t handle1 = - server->create ("event_1", // Name of entry point - TAO_TRY_ENV // Environment - ); - - RtecScheduler::handle_t handle2 = - server->create ("event_2", // Name of entry point - TAO_TRY_ENV // Environment - ); - - RtecScheduler::handle_t handle3 = - server->create ("event_3", // Name of entry point - TAO_TRY_ENV // Environment - ); - - - // Register as a consumer/supplier: act as a supplier of event_1 but with - // a consumer dependency on event_3. Therefore, the actual period and - // number of threads for event_1 depends on the characteristics of event_3. - server->set (handle1, // RT_Info handle - RtecScheduler::HIGH_CRITICALITY, // Criticality - 500, // Worst case time (in 100 nanosecs) - 500, // Typical time (in 100 nanosecs) - 500, // Cached time (in 100 nanosecs) - 0, // Period - will depend on event_3 - RtecScheduler::LOW_IMPORTANCE, // Importance - 0, // Quantum (unused) - 0, // Threads - will depend on event_3 - RtecScheduler::OPERATION, // Info type - TAO_TRY_ENV); - - // Register as a producer of event_2. - server->set (handle2, // RT_Info handle - RtecScheduler::HIGH_CRITICALITY, // Criticality - 500, // Worst case time (in 100 nanosecs) - 500, // Typical time (in 100 nanosecs) - 500, // Cached time (in 100 nanosecs) - 50000 * 10, // Period in 100 nsec (= 20 Hz) - RtecScheduler::LOW_IMPORTANCE, // Importance - 0, // Quantum (unused) - 1, // Threads - RtecScheduler::OPERATION, // Info type - TAO_TRY_ENV); - - // Register as a consumer of event_3. - server->set (handle3, // RT_Info handle - RtecScheduler::HIGH_CRITICALITY, // Criticality - 500, // Worst case time (in 100 nanosecs) - 500, // Typical time (in 100 nanosecs) - 500, // Cached time (in 100 nanosecs) - 0, // Period - will depend on supplier - RtecScheduler::LOW_IMPORTANCE, // Importance - 0, // Quantum (unused) - 0, // Threads - will depend on supplier - RtecScheduler::OPERATION, // Info type - TAO_TRY_ENV); - - - // Establish a dependency of event_1 on event_3. - server->add_dependency (handle1, // handle that depends - handle3, // handle that is depended on - 1, // number of calls per event occurance - TAO_TRY_ENV // environment - ); - - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3> -<a name="Section4_2">Connecting Consumers to the Event Channel</a> -</h3> - -<tr><td> -The following code is derived from the EC_Throughput consumer code, which can be -found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a> - -<tr><td> -<pre> - -void -Test_Consumer::connect (const char* name, - int event_a, int event_b, - RtecEventChannelAdmin::EventChannel_ptr ec, - CORBA::Environment& _env) -{ - - // Register operations with the scheduling service. The following steps are - // only necessary for applications that make use of the Event Service's hard - // real-time features. Applications that do not need these features and are - // configured with a null scheduler may skip the following operations on the - // scheduling server. - - // Obtain a reference to the scheduler from the ACE_Scheduler_Factory. - RtecScheduler::Scheduler_ptr server = - ACE_Scheduler_Factory::server (); - - // Create a new RT_Info entry for the function identifier - // we were passed, and hang onto the handle to the RT_Info. - RtecScheduler::handle_t rt_info = - server->create (name, _env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Set the attributes for the RT_Info. - ACE_Time_Value tv (0, 2000); - TimeBase::TimeT time; - ORBSVCS_Time::Time_Value_to_TimeT (time, tv); - server->set (rt_info, - RtecScheduler::VERY_HIGH_CRITICALITY, - time, time, time, - 0, - RtecScheduler::VERY_LOW_IMPORTANCE, - time, - 0, - RtecScheduler::OPERATION, - _env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Specify a disjunctive dependency on the arrival of event_a, the arrival - // of event b, OR the arrival of an event service shutdown event. Note that - // the same RT_Info is used for each event. This can be used to simplify - // code in applications using a null scheduler, or to consolidate events - // with identical characteristics in hard real-time applications. - ACE_ConsumerQOS_Factory qos; - qos.start_disjunction_group (); - qos.insert_type (ACE_ES_EVENT_SHUTDOWN, rt_info); - qos.insert_type (event_a, rt_info); - qos.insert_type (event_b, rt_info); - - // = Connect as a consumer. - - // Obtain a reference to the consumer administration object. - RtecEventChannelAdmin::ConsumerAdmin_var consumer_admin = - ec->for_consumers (_env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Obtain a reference to the push supplier proxy. - this->supplier_proxy_ = - consumer_admin->obtain_push_supplier (_env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Obtain a reference to this object. - RtecEventComm::PushConsumer_var objref = this->_this (_env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Connect as a consumer. - this->supplier_proxy_->connect_push_consumer (objref.in (), - qos.get_ConsumerQOS (), - _env); - TAO_CHECK_ENV_RETURN_VOID(_env); -} - -</pre> - -<tr><td> -The following code is derived from the EC_Throughput consumer driver code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer_Driver.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer_Driver.cpp</a> - -<tr><td> -<pre> - -int -ECT_Consumer_Driver::run (int argc, char* argv[]) -{ - // argc/argv are used to initialize the ORB and the options - // for this particular test. Other applications may hard-code - // the ORB options, obtain them from another source, etc. - - TAO_TRY - { - // The use of TAO_TRY macros isolate us from the differences - // between platforms with and without native C++ exceptions. - // This is work in progress and may change in the future! - - // Below is some boiler plate code to initialize the ORB and - // the POA. Notice that applications that connect to the Event - // Channel play the server role in some instances, because - // they receive push() requests (as Consumers) or - // disconnect_push_supplier() requests (as Suppliers). - - // Initialize the ORB reference. - this->orb_ = - CORBA::ORB_init (argc, argv, "", TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Initialize the root POA reference. - CORBA::Object_var poa_object = - this->orb_->resolve_initial_references("RootPOA"); - if (CORBA::is_nil (poa_object.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to initialize the POA.\n"), - 1); - - // Obtain the narrowed root POA reference. - PortableServer::POA_var root_poa = - PortableServer::POA::_narrow (poa_object.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Obtain a reference to the POA manager. - PortableServer::POAManager_var poa_manager = - root_poa->the_POAManager (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Now some boiler plate code to obtain a reference to the - // naming service..... - - // Resolve a reference to the naming service. - CORBA::Object_var naming_obj = - this->orb_->resolve_initial_references ("NameService"); - if (CORBA::is_nil (naming_obj.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to get the Naming Service.\n"), - 1); - - // Narrow the naming service reference. - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_obj.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Use the Naming Service to locate the Scheduling Service and - // use the Scheduler_Factory to keep a global pointer to the - // latter. - - // Initialize the scheduler factory to operate in configuration mode. - if (ACE_Scheduler_Factory::use_config (naming_context.in ()) == -1) - return -1; - - // Use the Naming Service to locate the Event Service.... - - // Set up the event service lookup name. - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("EventService"); - - // Resolve a reference to the event service. - CORBA::Object_var ec_obj = - naming_context->resolve (name, TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Narrow the reference to the event service. - RtecEventChannelAdmin::EventChannel_var channel; - if (CORBA::is_nil (ec_obj.in ())) - channel = RtecEventChannelAdmin::EventChannel::_nil (); - else - channel = RtecEventChannelAdmin::EventChannel::_narrow (ec_obj.in (), - TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Activate the POA so we can start receiving requests... - - // Activate the POA manager. - poa_manager->activate (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Connect consumers to the event service. - this->connect_consumers (channel.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - ACE_DEBUG ((LM_DEBUG, "connected consumer(s)\n")); - ACE_DEBUG ((LM_DEBUG, "running the test\n")); - - // Run the event loop. - if (this->orb_->run () == -1) - ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "orb->run"), -1); - ACE_DEBUG ((LM_DEBUG, "event loop finished\n")); - - this->dump_results (); - - // Disconnect consumers from the event service. - this->disconnect_consumers (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Destroy the event service. - channel->destroy (TAO_TRY_ENV); - TAO_CHECK_ENV; - } - TAO_CATCH (CORBA::SystemException, sys_ex) - { - TAO_TRY_ENV.print_exception ("SYS_EX"); - } - TAO_CATCHANY - { - TAO_TRY_ENV.print_exception ("NON SYS EX"); - } - TAO_ENDTRY; - return 0; -} - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<!-- Must be after suppliers connect. --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3><a name="Section4_3">Receiving Events</a></h3><p> - -<tr><td> -The following code is derived from the EC_Throughput consumer code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a> - -<tr><td> -<pre> - -void -Test_Consumer::push (const RtecEventComm::EventSet& events, - CORBA::Environment &_env) -{ - // Make sure at least one event was pushed. - if (events.length () == 0) - { - // ACE_DEBUG ((LM_DEBUG, "no events\n")); - return; - } - - // Make sure only one thread has access. - ACE_GUARD (TAO_SYNCH_MUTEX, ace_mon, this->lock_); - - // We start the timer as soon as we receive the first event. - if (this->recv_count_ == 0) - this->timer_.start (); - - // Update the count of received events. - this->recv_count_ += events.length (); - - if (TAO_debug_level > 0 - && this->recv_count_ % 1000 == 0) - { - ACE_DEBUG ((LM_DEBUG, - "ECT_Consumer (%P|%t): %d events received\n", - this->recv_count_)); - } - - // Loop through the events, looking for shutdown events. - for (u_int i = 0; i < events.length (); ++i) - { - if (events[i].header.type == ACE_ES_EVENT_SHUTDOWN) - { - this->shutdown_count_++; - if (this->shutdown_count_ >= this->n_suppliers_) - { - // We stop the timer as soon as we realize it is time to - // do so. - this->timer_.stop (); - this->driver_->shutdown_consumer (this->cookie_, _env); - } - } - } -} - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3> -<a name="Section4_4">Disconnecting Consumers from the Event Channel</a> -</h3> - -<tr><td> -The following code is derived from the EC_Throughput consumer code, which can be -found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Consumer.cpp</a> - -<tr><td> -<pre> - -void -Test_Consumer::disconnect (CORBA::Environment &_env) -{ - // Make sure the supplier proxy reference is valid. - if (CORBA::is_nil (this->supplier_proxy_.in ())) - return; - - // Disconnect from further communication with the push - // supplier(s). Each consumer is represented by a unique - // ACE_ES_ConsumerModule instance. Which connection to - // disconnect is determined by the instance for the consumer. - this->supplier_proxy_->disconnect_push_supplier (_env); - TAO_CHECK_ENV_RETURN_VOID(_env); - - // Mark the supplier proxy reference invalid. - this->supplier_proxy_ = - RtecEventChannelAdmin::ProxyPushSupplier::_nil (); - - // We want to stop processing events for this consumer. Above, - // we disconnected the consumer from the Event Channel, so no - // more events will be sent, but we could have some events in - // transit. - - // Without a flushing protocol we need to deactivate the - // servant to stop accepting push () requests for any - // incoming events. - - // Deactivate the servant - PortableServer::POA_var poa = - this->_default_POA (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - PortableServer::ObjectId_var id = - poa->servant_to_id (this, _env); - TAO_CHECK_ENV_RETURN_VOID (_env); - poa->deactivate_object (id.in (), _env); - TAO_CHECK_ENV_RETURN_VOID (_env); -} - -</pre> -</table> -</center> - - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<td> -<h2><a name="Section5">Developing Suppliers</a></h2> - -<ul> - <li> <a href="events_tutorial.html#Section5_1">Providing QoS Information</a> - <li> <a href="events_tutorial.html#Section5_2">Connecting Suppliers to the Event Channel</a> - <li> <a href="events_tutorial.html#Section5_3">Generating Events</a> - <li> <a href="events_tutorial.html#Section5_4">Disconnecting Suppliers from the Event Channel</a> -</ul> -</table> -</center> - - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3><a name="Section5_1">Providing QoS Information</a></h3><p> -<tr><td> -In applications that use hard real-time scheduling, a Supplier should provide -the worst case, expected, and cached execution time for each operation on the -supplier side. Even if these values are small and highly deterministic, it is -generally better to specify them in the supplier's RT_Info rather than folding -them into the RT_Info of each consumer. - -<tr><td> -Such a supplier must also specify criticality and importance values, a period, -and the number of threads for each operation. A real-time scheduler propagates -this information to consumer RT_Infos along the graph of dependencies. The -scheduler then uses the propagated information to order dispatches within a -set of operations whose dependencies have been met. - -<tr><td> -The Event Service matches supplier publications with consumer subscriptions to -provide efficient event filtering. Providing incorrect publications or -subscriptions will result in missed events. The Event Service also uses the -subscription information to create additional dependencies between registered -RT_Infos. Thus, providing correct supplier publication and consumer -subscription information is also critical for correct scheduling in hard -real-time applications. - - -<tr><td> -As noted before in the discussion of consumers, the following steps are only -necessary for applications that make use of the Event Service's hard real-time -features. Applications that do not need these features and are configured -with a null scheduler may skip the following operations on the scheduling -server. - -</table> -</center> - -<center><table cellpadding=1 border=0 cellspacing=4> - -<tr><td> -<pre> - - // Obtain a reference to the scheduler server. - RtecScheduler::Scheduler_ptr server = - ACE_Scheduler_Factory::server (); - - // Create new RT_Info descriptors for two events. - - RtecScheduler::handle_t handle0 = - server->create ("event_0", // Name of entry point - TAO_TRY_ENV // Environment - ); - - RtecScheduler::handle_t handle1 = - server->create ("event_1", // Name of entry point - TAO_TRY_ENV // Environment - ); - - // Register as a producer of event_0. - server->set (handle0, // RT_Info handle - RtecScheduler::HIGH_CRITICALITY, // Criticality - 10, // Worst case time (in 100 nanosecs) - 10, // Typical time (in 100 nanosecs) - 10, // Cached time (in 100 nanosecs) - 50000 * 10, // Period in 100 nanosecs (= 20 Hz) - RtecScheduler::LOW_IMPORTANCE, // Importance - 0, // Quantum (unused) - 1, // Threads - RtecScheduler::OPERATION, // Info type - TAO_TRY_ENV); - - // Register as a producer of event_1. - server->set (handle1, // RT_Info handle - RtecScheduler::HIGH_CRITICALITY, // Criticality - 10, // Worst case time (in 100 nanosecs) - 10, // Typical time (in 100 nanosecs) - 10, // Cached time (in 100 nanosecs) - 50000 * 10, // Period in 100 nanosecs (= 20 Hz) - RtecScheduler::LOW_IMPORTANCE, // Importance - 0, // Quantum (unused) - 1, // Threads - RtecScheduler::OPERATION, // Info type - TAO_TRY_ENV); - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<td> -<h3><a name="Section5_2">Connecting Suppliers to Event Channel</a></h3><P> -<p> - -<tr><td> -The following code is derived from the EC_Throughput supplier code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a> - - -<tr><td> -<pre> - -void -Test_Supplier::connect (const char* name, - int burst_count, - int burst_size, - int event_size, - int burst_pause, - int event_a, - int event_b, - RtecEventChannelAdmin::EventChannel_ptr ec, - CORBA::Environment &_env) -{ - // Some application-specific setup code. - - // Store the passed parameters in the object. - this->burst_count_ = burst_count; - this->burst_size_ = burst_size; - this->event_size_ = event_size; - this->burst_pause_ = burst_pause; - this->event_a_ = event_a; - this->event_b_ = event_b; - - // Register operations with the scheduling service. The following steps are - // only necessary for applications that make use of the Event Service's hard - // real-time features. Applications that do not need these features and are - // configured with a null scheduler may skip the following operations on the - // scheduling server. - - // Obtain a reference to the scheduling service. - RtecScheduler::Scheduler_ptr server = - ACE_Scheduler_Factory::server (); - - // Create an RT_Info descriptor for the passed operation name. - RtecScheduler::handle_t rt_info = - server->create (name, _env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Calculate the period at which to supply events. - ACE_Time_Value tv (0, burst_pause); - RtecScheduler::Period_t rate = tv.usec () * 10; - - // Set the information in the RT_Info descriptor. - tv.set (0, 2000); - TimeBase::TimeT time; - ORBSVCS_Time::Time_Value_to_TimeT (time, tv); - server->set (rt_info, - RtecScheduler::VERY_HIGH_CRITICALITY, - time, time, time, - rate, - RtecScheduler::VERY_LOW_IMPORTANCE, - time, - 1, - RtecScheduler::OPERATION, - _env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Now, create a supplier id, and publish the events - // that will be supplied under this id. - - // Create a supplier id from the passed name - this->supplier_id_ = ACE::crc32 (name); - ACE_DEBUG ((LM_DEBUG, "ID for <%s> is %04.4x\n", name, - this->supplier_id_)); - - // Publish the events the supplier provides. - ACE_SupplierQOS_Factory qos; - qos.insert (this->supplier_id_, - event_a, - rt_info, 1); - qos.insert (this->supplier_id_, - event_b, - rt_info, 1); - qos.insert (this->supplier_id_, - ACE_ES_EVENT_SHUTDOWN, - rt_info, 1); - - // And finally, some boiler plate code to connect a supplier - // to the Event Service. This is where the connection is - // actually made. - - // Obtain a reference to the supplier administration object. - RtecEventChannelAdmin::SupplierAdmin_var supplier_admin = - ec->for_suppliers (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Obtain a reference to the consumer proxy object. - this->consumer_proxy_ = - supplier_admin->obtain_push_consumer (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Obtain a reference to this supplier object. - RtecEventComm::PushSupplier_var objref = - this->supplier_._this (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Connect as a supplier of the published events. - this->consumer_proxy_->connect_push_supplier (objref.in (), - qos.get_SupplierQOS (), - _env); - TAO_CHECK_ENV_RETURN_VOID (_env); -} - -</pre> - - -<tr><td> -The following code is derived from the EC_Throughput supplier driver code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier_Driver.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier_Driver.cpp</a> - -<tr><td> -<pre> - -int -ECT_Supplier_Driver::run (int argc, char* argv[]) -{ - // argc/argv are used to initialize the ORB and the options - // for this particular test. Other applications may hard-code - // the ORB options, obtain them from another source, etc. - - TAO_TRY - { - // The use of TAO_TRY macros isolate us from the differences - // between platforms with and without native C++ exceptions. - // This is work in progress and may change in the future! - - // Below is some boiler plate code to initialize the ORB and - // the POA. Notice that applications that connect to the Event - // Channel play the server role in some instances, because - // they receive push() requests (as Consumers) or - // disconnect_push_supplier() requests (as Suppliers). - - // Initialize the ORB reference. - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, "", TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Initialize the root POA reference. - CORBA::Object_var poa_object = - orb->resolve_initial_references("RootPOA"); - if (CORBA::is_nil (poa_object.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to initialize the POA.\n"), - 1); - - // Obtain the narrowed root POA reference. - PortableServer::POA_var root_poa = - PortableServer::POA::_narrow (poa_object.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Obtain a reference to the POA manager. - PortableServer::POAManager_var poa_manager = - root_poa->the_POAManager (TAO_TRY_ENV); - TAO_CHECK_ENV; - - - // Now some boiler plate code to obtain a reference to the - // naming service..... - - // Resolve a reference to the naming service. - CORBA::Object_var naming_obj = - orb->resolve_initial_references ("NameService"); - if (CORBA::is_nil (naming_obj.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to get the Naming Service.\n"), - 1); - - // Narrow the naming service reference. - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_obj.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Use the Naming Service to locate the Scheduling Service and - // use the Scheduler_Factory to keep a global pointer to the - // latter. - - // Initialize the scheduler factory to operate in configuration mode. - if (ACE_Scheduler_Factory::use_config (naming_context.in ()) == -1) - return -1; - - // Use the Naming Service to locate the Event Service.... - - // Set up the event service lookup name. - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("EventService"); - - // Resolve a reference to the event service. - CORBA::Object_var ec_obj = - naming_context->resolve (name, TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Narrow the reference to the event service. - RtecEventChannelAdmin::EventChannel_var channel; - if (CORBA::is_nil (ec_obj.in ())) - channel = RtecEventChannelAdmin::EventChannel::_nil (); - else - channel = RtecEventChannelAdmin::EventChannel::_narrow (ec_obj.in (), - TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Activate the POA so we can start receiving requests... - - // Activate the POA manager. - poa_manager->activate (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Connect suppliers to the event service. - this->connect_suppliers (channel.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - ACE_DEBUG ((LM_DEBUG, "connected supplier(s)\n")); - - // Activate the supplier objects - this->activate_suppliers (TAO_TRY_ENV); - TAO_CHECK_ENV; - - ACE_DEBUG ((LM_DEBUG, "suppliers are active\n")); - - // Wait for the supplier threads. - if (ACE_Thread_Manager::instance ()->wait () == -1) - { - ACE_ERROR ((LM_ERROR, "Thread_Manager wait failed\n")); - return 1; - } - - ACE_DEBUG ((LM_DEBUG, "suppliers finished\n")); - - this->dump_results (); - - // Disconnect suppliers from the event service. - this->disconnect_suppliers (TAO_TRY_ENV); - TAO_CHECK_ENV; - } - TAO_CATCH (CORBA::SystemException, sys_ex) - { - TAO_TRY_ENV.print_exception ("SYS_EX"); - } - TAO_CATCHANY - { - TAO_TRY_ENV.print_exception ("NON SYS EX"); - } - TAO_ENDTRY; - return 0; -} - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<h3><a name="Section5_3">Generating Events</a></h3><P><p> - -<tr><td> -The following code is derived from the EC_Throughput supplier code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a> - -<tr><td> -<pre> - -int -Test_Supplier::svc () -{ - TAO_TRY - { - // First, a bunch of code that is specific to this test. - - // Set pause (sleep) value between message bursts. - ACE_Time_Value tv (0, this->burst_pause_); - - // Set up message block for event data. - ACE_Message_Block mb (this->event_size_); - mb.wr_ptr (this->event_size_); - - // Create an event set for one event, initialize event header. - RtecEventComm::EventSet event (1); - event.length (1); - event[0].header.source = this->supplier_id (); - event[0].header.ttl = 1; - - // Set up time stamps in event header. This is for performance - // measurements, so this step can be omitted at will. - ACE_hrtime_t t = ACE_OS::gethrtime (); - ORBSVCS_Time::hrtime_to_TimeT (event[0].header.creation_time, t); - event[0].header.ec_recv_time = ORBSVCS_Time::zero; - event[0].header.ec_send_time = ORBSVCS_Time::zero; - - // Initialize data fields in event. - event[0].data.x = 0; - event[0].data.y = 0; - - // We use replace to minimize the copies. This should result - // in just one memory allocation; - event[0].data.payload.replace (this->event_size_, - &mb); - - // This is where the events are actually pushed into - // the event channel. The test pushes bursts of events, - // pausing a specified interval between bursts. - - // Start the timer, and begin pushing events. - this->timer_.start (); - for (int i = 0; i < this->burst_count_; ++i) - { - // Send a burst of events. - for (int j = 0; j < this->burst_size_; ++j) - { - if (j % 2 == 0) - event[0].header.type = this->event_a_; - else - event[0].header.type = this->event_b_; - - // ACE_DEBUG ((LM_DEBUG, "(%t) supplier push event\n")); - this->consumer_proxy ()->push (event, TAO_TRY_ENV); - - TAO_CHECK_ENV; - } - - // Sleep until it's time to send the next burst. - ACE_OS::sleep (tv); - } - - // Send a "magic" type of event to inform the consumer that we are - // not sending anything else... - - // Send one event shutdown from each supplier - event[0].header.type = ACE_ES_EVENT_SHUTDOWN; - this->consumer_proxy ()->push(event, TAO_TRY_ENV); - TAO_CHECK_ENV; - this->timer_.stop (); - - } - TAO_CATCH (CORBA::SystemException, sys_ex) - { - TAO_TRY_ENV.print_exception ("SYS_EX"); - } - TAO_CATCHANY - { - TAO_TRY_ENV.print_exception ("NON SYS EX"); - } - TAO_ENDTRY; - return 0; -} - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<td> -<h3><a name="Section5_4">Disconnecting Suppliers from the Event Channel</a></h3><P> -<p> - -<tr><td> -The following code is derived from the EC_Throughput supplier code, which -can be found in TAO in the file: -<A HREF="../orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp"> -$TAO_ROOT/orbsvcs/tests/EC_Throughput/ECT_Supplier.cpp</a> - - -<tr><td> -<pre> - -void -Test_Supplier::disconnect (CORBA::Environment &_env) -{ - // Make sure the consumer proxy reference is valid. - if (CORBA::is_nil (this->consumer_proxy_.in ())) - return; - - // Disconnect communication with the push consumer(s). - this->consumer_proxy_->disconnect_push_consumer (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - - // Mark the consumer proxy reference invalid. - this->consumer_proxy_ = - RtecEventChannelAdmin::ProxyPushConsumer::_nil (); - - // We need to stop accepting disconnect_push_supplier () requests - // for this supplier, before it is safe to destroy the supplier. - // As required by the CORBA spec, you must explicitly deactivate - // a servant before destroying it. - - // Deactivate the servant - PortableServer::POA_var poa = - this->supplier_._default_POA (_env); - TAO_CHECK_ENV_RETURN_VOID (_env); - PortableServer::ObjectId_var id = - poa->servant_to_id (&this->supplier_, _env); - TAO_CHECK_ENV_RETURN_VOID (_env); - poa->deactivate_object (id.in (), _env); - TAO_CHECK_ENV_RETURN_VOID (_env); - RtecEventChannelAdmin::ProxyPushConsumer::_nil (); -} - -</pre> - -</table> -</center> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<td> -<h2><a name="Section6">Caring for your Event Channel</a></h2> - - -<BR> - -The following code is derived from the Event_Service executable, which can be -found in TAO in the file: -<A HREF="../orbsvcs/Event_Service/Event_Service.cpp"> -$TAO_ROOT/orbsvcs/Event_Service/Event_Service.cpp</a> - -<tr><td> -<pre> - -int main (int argc, char *argv[]) -{ - TAO_TRY - { - // argc/argv are used to initialize the ORB and the options - // for the Event Service executable. Other applications may - // hard code the ORB options, obtain them from another source, etc. - - // Again the boiler plate code for ORB and POA initialization. - - // Initialize ORB. - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, "internet", TAO_TRY_ENV); - TAO_CHECK_ENV; - - if (parse_args (argc, argv) == -1) - return 1; - - CORBA::Object_var poa_object = - orb->resolve_initial_references("RootPOA"); - if (CORBA::is_nil (poa_object.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to initialize the POA.\n"), - 1); - - PortableServer::POA_var root_poa = - PortableServer::POA::_narrow (poa_object.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - PortableServer::POAManager_var poa_manager = - root_poa->the_POAManager (TAO_TRY_ENV); - TAO_CHECK_ENV; - - CORBA::Object_var naming_obj = - orb->resolve_initial_references ("NameService"); - if (CORBA::is_nil (naming_obj.in ())) - ACE_ERROR_RETURN ((LM_ERROR, - " (%P|%t) Unable to initialize the Naming Service.\n"), - 1); - - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_obj.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Notice the use of auto_ptr<> to automagically manage the - // destruction of the servant. When the auto_ptr goes out - // of scope, its destructor is called, which in turn destroys - // the servant. - - auto_ptr<POA_RtecScheduler::Scheduler> scheduler_impl; - RtecScheduler::Scheduler_var scheduler; - - - // Create a new servant to implement the Scheduling Service, - // register it with the Naming Service, and use the - // Scheduler_Factory to keep a global pointer to the new - // Scheduling Service. - - // This is the name we (potentially) use to register the Scheduling - // Service in the Naming Service. - CosNaming::Name schedule_name (1); - schedule_name.length (1); - schedule_name[0].id = CORBA::string_dup ("ScheduleService"); - - if (global_scheduler == 0) - { - scheduler_impl = - auto_ptr<POA_RtecScheduler::Scheduler>(new ACE_Config_Scheduler); - if (scheduler_impl.get () == 0) - return 1; - scheduler = scheduler_impl->_this (TAO_TRY_ENV); - TAO_CHECK_ENV; - - CORBA::String_var str = - orb->object_to_string (scheduler.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - ACE_DEBUG ((LM_DEBUG, "The (local) scheduler IOR is <%s>\n", - str.in ())); - - // Register the servant with the Naming Context.... - naming_context->bind (schedule_name, scheduler.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - } - - ACE_Scheduler_Factory::use_config (naming_context.in ()); - - // The Event Service can be configured to support priority based - // dispatching (the "default_Module_Factory") or best effort (the - // "Reactive_Module_Factory"). We pick the right module factory - // according to the command line options processed above. - - TAO_Default_Module_Factory default_module_factory; - TAO_Reactive_Module_Factory reactive_module_factory; - - TAO_Module_Factory* module_factory = &default_module_factory; - if (reactive) - module_factory = &reactive_module_factory; - - // Now, create a new event channel servant to implement the - // Event Service, and register it with Naming Service. - - // Construct the event channel using the given module factory. - ACE_EventChannel ec_impl (1, - ACE_DEFAULT_EVENT_CHANNEL_TYPE, - module_factory); - - // Obtain an object reference to the new channel. - RtecEventChannelAdmin::EventChannel_var ec = - ec_impl._this (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Convert the EC object reference to a string. - CORBA::String_var str = - orb->object_to_string (ec.in (), TAO_TRY_ENV); - - // Output the EC object reference string (debug only). - ACE_DEBUG ((LM_DEBUG, - "The EC IOR is <%s>\n", str.in ())); - - // Register the EC with the Naming Service. - CosNaming::Name channel_name (1); - channel_name.length (1); - channel_name[0].id = CORBA::string_dup (service_name); - naming_context->bind (channel_name, ec.in (), TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Activate the POA so we can start receiving requests... - - // Activate the POA manager. - poa_manager->activate (TAO_TRY_ENV); - TAO_CHECK_ENV; - - // Run the ORB event loop - ACE_DEBUG ((LM_DEBUG, "%s; running event service\n", __FILE__)); - if (orb->run () == -1) - ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "run"), 1); - - // Now the Event Service is finished. We could deactivate the - // EC and SS here, but we don't need to, as the server is - // going down anyway. - - - // Remove the event service and the scheduling service from - // the Naming Service. - - naming_context->unbind (channel_name, TAO_TRY_ENV); - TAO_CHECK_ENV; - - if (global_scheduler == 0) - { - naming_context->unbind (schedule_name, TAO_TRY_ENV); - TAO_CHECK_ENV; - } - - } - TAO_CATCHANY - { - TAO_TRY_ENV.print_exception ("EC"); - } - TAO_ENDTRY; - - - return 0; -} - -</pre> -</table> -</center> - -<P><hr width="75%"><P> <!-- intra-section separator --> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<h2><a name="Section7">Sample Applications</a></h2> - -<tr><td> -A number of sample applications are available in the directories under -<a href="../orbsvcs/tests/"> -TAO's ORB Services tests</a>. - -<tr><td> -In particular, much of the code shown in this tutorial was drawn from the -<a href="../orbsvcs/tests/EC_Throughput/"> -EC_Throughput</a> test. This test exercises the Event Service and measures its -throughput capabilities. - -<tr><td> -A similar test, -<a href="../orbsvcs/tests/Event_Latency/"> -Event_Latency</a>, measures the latency of events through the Event Service. - -<tr><td> -The -<a href="../orbsvcs/tests/EC_Basic/"> -EC_Basic</a> test demonstrates the basic use the Event Service. - -<tr><td> -The -<a href="../orbsvcs/tests/EC_Multiple/"> -EC_Multiple</a> test shows a number of ways to connect multiple Event Channels. - - -<tr><td> -For the IDL source for the various interfaces, please see -<a href="../orbsvcs/orbsvcs/RtecScheduler.idl">RtecScheduler.idl</a>, -<a href="../orbsvcs/orbsvcs/CosEventChannelAdmin.idl">CosEventChannelAdmin.idl</a>, -<a href="../orbsvcs/orbsvcs/CosEventComm.idl">CosEventComm.idl</a> -and -<a href="../orbsvcs/orbsvcs/CosNaming.idl">CosNaming.idl</a>. - - -</table> -</center> - -<P><HR><P> -<!-- ************************************************************ --> - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -<h2><a name="Section8">Reference Materials</a></h2> - -<tr><td> -The following materials were used in developing this tutorial: please refer to them for further information. - -<tr><td> -<br> -<tr><td> -<h3>Books</h3> - -<tr><td> -Mowbray, T. and Zahavi, R. The Essential CORBA, Systems Integration Using Distributed Objects. Wiley, 1995. -ISBN 0-471-10611-9 - -<tr><td> -<br> - -<tr><td> -Baker, S. CORBA Distributed Objects Using Orbix. Addison-Wesley, 1997. ISBN 0-201-92475-7 - -<tr><td> -<br> -<tr><td> -<h3>Papers</h3> - -<tr><td> -<ul> - -<li><a href="http://www.cs.wustl.edu/~schmidt/Arch.ps.gz"> -Architectural Considerations for Deterministic Real-Time ORB -Endsystems and Applications</a> - -<li><a href="http://www.cs.wustl.edu/~schmidt/JSAC-98.ps.gz"> The -Design and Performance of a Real-Time CORBA Object Event Service</a> - -<li><a href="http://www.cs.wustl.edu/~schmidt/RT-ORB.ps.gz"> The -Design of the TAO Real-Time Object Request Broker</a> - -</ul> - - -<tr><td> - -</table> -</center> - -<P><HR><P> -<!-- ************************************************************ --> - - -<center><table cellpadding=1 border=0 cellspacing=4> -<tr><td> -Last modified 10:50:30 CST 22 December 1998 by Chris Gill -</table></center> - -</body></html> - diff --git a/TAO/docs/exceptions.html b/TAO/docs/exceptions.html deleted file mode 100644 index f847bd780ef..00000000000 --- a/TAO/docs/exceptions.html +++ /dev/null @@ -1,22 +0,0 @@ -<!DOCTYPE HTML SYSTEM -"http://www.w3.org/pub/WWW/MarkUp/Cougar/Cougar.dtd"> -<!-- $Id$ --> -<html> <head> -<title>Exception handling</title> -</head> - -<body> -<h1>Exception Handling</h1> - -Since the exception handling macros in TAO can be used with any ORB, -they have been generalized and moved to ACE. <P> - -<h3>Note that ACE's try macros are now prefered over the original TAO -try macros. You should avoid using them in your applications. They -might be removed completely one day.</h3> - -The new document about exception handling has been moved to -<a href="../../docs/exceptions.html">here</a>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</body></HTML> diff --git a/TAO/docs/forwarding.html b/TAO/docs/forwarding.html deleted file mode 100644 index 82301a47905..00000000000 --- a/TAO/docs/forwarding.html +++ /dev/null @@ -1,90 +0,0 @@ -<html> - <!-- $Id$ --> - <head> - <title>Implementation of location forwarding</title> - </head> - - <BODY text = "#000000" - link="#0000ff" - vlink="#cc0000" - bgcolor="#ffffff"> - - <body> - <HR> - <h1>Location forwarding</h1> - <HR> - <h2>Context</h2> - - The motivation to support location forwarding for objects is - to allow objects to move or forward certain requests to - other objects. Moving of objects is very important for the - Common Object Services LifeCycle Service. An object - complying to the LifeCycleObject interface, defined by the - LifeCycle Service should support the move() operation. The - move() operation allows the client to keep its object - reference to the object, but the object is going to be - relocated on the same or a different server. Making - location forwarding transparent to the client is the most - important issue. - - <h2>Communication between server and client</h2> - - GIOP defines a message named "LOCATION_FORWARD", which - should be used to inform the client stub, that the object - has been moved. The message body has to contain an object - reference to the new location of the forwarded object. - - <h2>Server side implementation</h2> - - Two approaches are possible, one is to use a POA servant - locator and the other is to use a servant activator. - - <h2>Client side implementation</h2> - - The client has to expect the location forwarding GIOP - message and should respond to it in setting the Profile of - its Object right. - - <h2>Conclusion</h2> - - Changing the Profile is transparent to the client. So the - client gets no idea that the object now resides somewhere - else. - - The result of the above mentioned solution is that if an - object moves the client will notice it with the next call to - the object. If the object moves again, the original location - is not bothered at all again. Say if the original location - was A, then it moved to B and finally to C. First location A - responded with a GIOP Location Forward to the client, then B - gets used and finally after moving the object to C, B will - send a GIOP Location Forward and location C gets used. - - There is "no" concept of a home location. If the object - moves very often and old servers die it might be a problem, - because clients, which did not call on the object lately - will not know where to search. Though in the situation of a - home location, there is also the risk that this server might - die and the object is not reachable any more. - - <h2>Optimization</h2> - - In the case, when the object moves several times, a chain of - forwarding servers is created. But this chain might be - easily disturbed by just one server failing. A good idea is - to give the servant locator more intelligence to tell all - the other/previous servers where the object is now. This - will of course increase the communication overhead in the - case of a move, but we get a high reliability against dying - hosts. - - <HR> - For more details and questions, - <p> - - <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address> - <p> - <address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address> - </body> -</html> - diff --git a/TAO/docs/implrepo.html b/TAO/docs/implrepo.html deleted file mode 100644 index c1221a88564..00000000000 --- a/TAO/docs/implrepo.html +++ /dev/null @@ -1,12 +0,0 @@ -<HTML> -<!-- $Id$ --> -<HEAD> -<TITLE>IR docs have moved</TITLE> -<META HTTP-EQUIV="Refresh" CONTENT="1; URL=implrepo/index.html"> -</HEAD> -<BODY> -<P>The IR docs have moved to <A HREF="implrepo/index.html">here</A>.</P> -<P>This page should automatically redirect you there, if not, click on -the link above.</P> -</BODY> -</HTML> diff --git a/TAO/docs/implrepo/index.html b/TAO/docs/implrepo/index.html deleted file mode 100644 index 34d0e34c492..00000000000 --- a/TAO/docs/implrepo/index.html +++ /dev/null @@ -1,42 +0,0 @@ -<html> - -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -<meta name="ProgId" content="FrontPage.Editor.Document"> -<title>Implementation Repository</title> -<!-- $Id$ --> -</head> - -<body bgcolor="#FFFFFF" text="#000000"> - -<hr> - -<h2>Implementation Repository in TAO</h2> - -<p><b>Note:</b> I have moved most of the documentation here to the <A -HREF="http://www.dre.vanderbilt.edu/Doxygen/">ACE+TAO doxygen</A> website, so -please check for the last night documention <A -HREF="http://www.dre.vanderbilt.edu/Doxygen/Current/html/tao/implrepo_service/index.html">here</A> and -<A HREF="http://www.dre.vanderbilt.edu/Doxygen/Stable/tao/implrepo_service/index.html">here</A> for the -latest stable documentation - -<hr> - -<h3>Stuff still here</h3> - -<p><a href="tao_imr.html">tao_imr Guide</a> - Guide to the commands for the -tao_imr application.</p> - -<p><a href="paper.html">The Paper</a> - A paper that has a general -description of the IMR. This is also where to look to find information on the -inner working of the IMR. Be warned, it was written a while ago and there has -been several changes since then in the implementation.</p> - -<hr> - -<p>Back to the <a href="../index.html">TAO Documentation</a>.</p> - -</body> - -</html> diff --git a/TAO/docs/implrepo/paper.html b/TAO/docs/implrepo/paper.html deleted file mode 100644 index 22f8e233512..00000000000 --- a/TAO/docs/implrepo/paper.html +++ /dev/null @@ -1,820 +0,0 @@ -<html> - -<head> -<meta http-equiv="Content-Type" -content="text/html; charset=iso-8859-1"> -<meta name="GENERATOR" content="Microsoft FrontPage Express 2.0"> -<title>TAO Implementation Repository</title> -<!-- $Id$ --> -</head> - -<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" -vlink="#CC0000"> - -<hr> - -<h1>TAO Implementation Repository </h1> - -<p>Revision 3.05</p> - -<hr> - -<h2>Table of Contents</h2> - -<ul> - <li><a href="#Changes">Recent Changes</a> </li> - <li><a href="#Overview">Overview</a> <ul> - <li><a href="#PersistentandTransientIORs">Persistent - and Transient IORs</a> </li> - <li><a href="#TheImplementationRepository">The - Implementation Repository</a> </li> - </ul> - </li> - <li><a href="#TAOsImplementationRepository">TAO's - Implementation Repository</a> <ul> - <li><a href="#VirtualServers">Virtual Servers</a> </li> - <li><a href="#PingObject">Ping Object</a></li> - <li><a href="#NewIORs">New IORs</a> <ul> - <li><a href="#WhatwaswrongwiththeoldIOR">What - was wrong with the old IOR?</a> </li> - <li><a href="#WhydoesImplRepocontainanOBJKey">Why - does the Implementation Repository - profile contain an Object Key?</a> </li> - </ul> - </li> - <li><a href="#POAExtensions">POA Extensions</a> </li> - <li><a href="#PossibleFutureGoals">Possible Future - Goals</a> </li> - <li><a href="#ServerRestrictions">Server Restrictions</a> - </li> - <li><a href="#PreliminaryInterface">Preliminary - Interface</a> </li> - </ul> - </li> - <li><a href="#AlternateImplementations">Alternate - Implementations</a> </li> - <li><a href="#AccessingtheImplementationRepository">Accessing - the Implementation Repository</a> <ul> - <li><a href="#HelperApplication">Helper Application</a> - </li> - <li><a href="#LocatinganinstanceofImplRepo">Locating - an instance of the Implementation Repository</a> <ul> - <li><a href="#Serverside">Server Side</a> </li> - <li><a href="#Clientside">Client Side</a> </li> - </ul> - </li> - </ul> - </li> - <li><a href="#Howitworks">How It Works</a> <ul> - <li><a href="#HowServerProducesPersistentIORdefault">How - a server produces a Persistent IOR (in the - default case)</a> </li> - <li><a href="#HowServerProducesPersistentIORcomplex">How - a server produces a Persistent IOR (in the - complex case)</a> </li> - <li><a href="#HowClientUsesPersistentIOR">How a - client uses a Persistent IOR</a> </li> - </ul> - </li> -</ul> - -<hr> - -<h2><a name="Changes">Recent Changes</a></h2> - -<p>Since 3.04</p> - -<ul> - <li>Moved it to the same directory as all the new</li> - <li>After a long delay (too long, if you ask me) addressed - the comments that John Mulhern <<a - href="mailto:9107@mn3.lawson.lawson.com">9107@mn3.lawson.lawson.com</a>> - sent me. </li> -</ul> - -<p>Since 3.03 </p> - -<ul> - <li>Added information on the new POA policy where the format - of the persistent IOR can be changed from that of both - the last-known-server-IOR and Implementation Repository - to that just of the Implementation Repository</li> - <li>TAO is now fork-safe, with the introduction of the - CLOEXEC flag through ACE_CLOEXEC.</li> -</ul> - -<p>Since 3.02 </p> - -<ul> - <li>Added a section to give more detailed information on how - Ping Objects work.</li> - <li>Rewrote the Virtual Server section</li> -</ul> - -<hr> - -<h2><a name="Overview">Overview</a></h2> - -<p>This document describes the proposed design of the TAO -Implementation Repository, which was originally known as the -reactivator/activation service. If you have any questions or -comments on our design, please post them to the <a -href="http://www.cs.wustl.edu/~schmidt/ACE-mail.html">ACE</a> -mailing list <<a href="mailto:ace-useres@cs.wustl.edu">ace-users@cs.wustl.edu</a>> -or send email to Darrell Brunsch <<a -href="mailto:brunsch@cs.wustl.edu">brunsch@cs.wustl.edu</a>>.</p> - -<h3><a name="PersistentandTransientIORs">Persistent and Transient -IORs</a></h3> - -<p>CORBA defines two types of object references: <a -href="http://www.cs.wustl.edu/~schmidt/C++-report-col12.ps.gz">persistent -and transient</a>. The difference between the two stems from the -lifetime of the reference in relation to the lifetime of the -server process that created it. The lifetime of a transient -object reference is limited to the lifetime of its server -process. Once the server process exits the transient object -reference no longer exists. All references to this object should -now be invalid, even if the server is restarted. In contrast, -persistent object references can outlive their originating server -process. Therefore, the server can exit and be restarted without -invalidating its persistent object references. This enables the -implementation of features like automatic server activation and -object migration.</p> - -<p>Note that both persistent and transient object references can -refer to objects that reside in <em>manually activated</em> -servers, <em>i.e.</em>, the so-called ``persistent servers.'' A -persistent server is a server that is launched manually, <em>i.e.</em>, -it is always running. A persistent server can generate transient -references and/or persistent references. </p> - -<p>Developers should be aware that persistence of the object -reference does not imply any persistence on the object -implementation state. It is certainly possible to provide -persistent object references for objects whose state is not -persistent. Therefore, servant implementors are responsible for -preserving the state of their servants, <em>e.g.</em>, using a -database or file. </p> - -<h3><a name="TheImplementationRepository">The Implementation -Repository</a></h3> - -<p>According to the CORBA specification, "The Implementation -Repository contains information that allows the ORB to locate and -activate implementations of objects" [CORBA Spec Rev. 2.2: -2.1.14] In earlier revisions of the specification, there was a -method <code>get_implementation</code> in the CORBA Object -interface. This has been deprecated as of the CORBA 2.2 -specification, leaving both the interface and implementation of -the Implementation Repository to the ORB vendor.</p> - -<p>A good paper describing the functionality of the CORBA -Implementation Repository is "<a -href="http://www.triodia.com/staff/michi/cacm.pdf">Binding, -Migration, and Scalability in CORBA</a>" [Michi Henning]. -This paper describes the following three functions of the -Implementation Repository: </p> - -<ol> - <li>Maintain a registry of known servers.</li> - <li>Record which server is currently running, and which port - and host it uses.</li> - <li>Starts servers on demand if they are registered with the - Implementation Repository.</li> -</ol> - -<p>The TAO Implementation Repository is based on the design in -this paper. He also wrote an earlier <a -href="http://www.triodia.com/staff/michi/binding.txt">email</a> -that may be useful to see the issues involved. The next section -details our goals and plans for the implementation.</p> - -<hr> - -<h2><a name="TAOsImplementationRepository">TAO's Implementation -Repository</a></h2> - -<p>The following is an brief outline of TAO'S Implementation -Repository. </p> - -<ul> - <li>Use of TAO's Implementation Repository will be optional. - Real-time applications can choose not to use the - Implementation Repository according to their - performance/predictability/footprint requirements.</li> - <li>Use of TAO's Implementation Repository will be invisible - to clients and servers for common use-case. For more - complicated behavior, programs can use Implementation - Repository extensions of the POA.</li> - <li>TAO's Implementation Repository will work with any CORBA - client that supports <code>LOCATION_FORWARD</code> IIOP - messages and multiple profiles in IORs, even if the - client is not implemented using TAO.</li> - <li>TAO's Implementation Repository will know if one of the - servers registered with it is running by the use of a - "ping"-like service in the server. This service - allows the Implementation Repository to know when it - should restart the server.</li> - <li>TAO will be fork-safe. Since there will be an open - connection to the client while the server is restarted - (via fork or CreateProcess) then care will be needed to - make sure that the open sockets will be closed in the - client process. The addition of CLOEXEC feature to TAO - will cover this problem.</li> - <li>TAO will exploit features of IIOP 1.1 to safely and - efficiently verify if an IOR was generated by TAO itself - on the client side. The server will still determine this - through the object key, since that is all that is passed - in a request.</li> - <li>TAO will support multiple profiles in IORs. A profile - contains the host/port and object key of a CORBA Object. - An optimization that will be possible is to have a last - known profile of the object as the first profile and an - Implementation Repository as the second profile in an - IOR. The client will first try the object to see if it - still active at the host/port before it contacts the - Implementation Repository. This strategy will reduce - latency. </li> -</ul> - -<h3><a name="VirtualServers">Virtual Servers</a></h3> - -<p>TAO's Implementation Repository must keep track of whether an -object's implementation is currently running or is stopped. To -have a record for every object would require too much overhead, -but having a record for every executable server would be -inflexible and prevent the migration of objects. In the Henning -paper, he mentions the use of a <em>server name</em> as the index -for the table maintained by the Implementation Repository. </p> - -<p>A virtual server does not refer to the executable but instead -to a group of objects. An executable may have one or more virtual -servers within it. This allows one virtual server to be moved off -the executable to another executable (for instance, onto another -machine) without affecting the objects in other virtual servers -on the original executable. </p> - -<p>Each virtual server will be indexed in the Implementation -Repository by a name that is given to it by the user. It is the -users responsibility to make sure that each virtual server name -is unique. By default, this name is the name of the executable -(since by default there is only one virtual server per -executable). However, this default behavior can be overridden. </p> - -<h3><a name="PingObject">Ping Object</a></h3> - -<p>Ping objects are simple objects that reside in the server, one -for every virtual server. It is contacted by the Implementation -Repository to determine if the virtual server is still running -and responding. At certain intervals the Implementation -Repository will invoke a one-way method on the ping object, and -then will expect a "pong" message to be sent back. -Different strategies for pinging (which will depend on a TAO -option) will be used by the implementation repository. If a -server is expected to be responsive, the Implementation -Repository will not wait long for a response before considering -the server to be gone. Other servers may be -computationally-intensive and need to be held under less -stringent expectations.</p> - -<p>We chose the ping method to be a one-way (instead of two-way) -because if the server became unresponsive, it would not return -from the method invocation. The Implementation Repository needs -some form of a timeout with the ping to be able to determine if -the server is unresponsive or not.</p> - -<h3><a name="NewIORs">New IORs</a></h3> - -<p>Standard CORBA IORs contain the following two sections:</p> - -<table border="1"> - <tr> - <td>Type ID</td> - <td>Sequence of Tagged Profiles</td> - </tr> -</table> - -<p>The Type ID is an indicator for the most derived type known at -the time of the reference creation. It is used as a hint for the -client in determining what interfaces the object can support. The -Sequence of Tagged Profiles consist of one or more profiles that -encapsulate information used by the associated protocol in order -to communicate with the object (host, port, object id, etc.).</p> - -<p>Currently, TAO uses only one IIOP 1.0 Tagged Profile, which is -defined as follows:</p> - -<table border="1"> - <tr> - <td>Version</td> - <td>Host</td> - <td>Port</td> - <td>Object Key</td> - </tr> -</table> - -<table border="0"> - <tr> - <td>Object Key: </td> - <td><table border="1"> - <tr> - <td>Transient/Persistent Flag</td> - <td>TimeStamp</td> - <td>POA ID</td> - <td>OBJ ID</td> - </tr> - </table> - </td> - </tr> -</table> - -<p>To accomodate the Implementation Repository and IIOP 1.1, the -Profile was changed according to the CORBA specification as -follows:</p> - -<table border="1"> - <tr> - <td>Version</td> - <td>Host</td> - <td>Port</td> - <td>Object Key</td> - <td>Components</td> - </tr> -</table> - -<table border="0"> - <tr> - <td>Object Key: </td> - <td><table border="1"> - <tr> - <td>TAO</td> - <td>TAO version</td> - <td>TimeStamp/Server Name</td> - <td>POA ID</td> - <td>OBJ ID</td> - </tr> - </table> - </td> - </tr> -</table> - -<p>The two main changes is the addition of the Components field -(which is a IIOP 1.1 thing) and the addition of TAO with its -version. Transient object references will still have a TimeStamp -to ensure uniqueness, but persistent object references will have -a server name to identify themselves to the Implementation -Repository. </p> - -<p>For servers that move around or need to be restarted often, -the IOR will contain a reference to the Implementation Repository -with the object key of the server and the server name imbedded. - Once the client contacts the Implementation Repository, it -will be forwarded to the correct object. This IOR will look like -the following:</p> - -<table border="1"> - <tr> - <td>Version</td> - <td>Host</td> - <td>Port</td> - <td>Object Key</td> - <td>Components</td> - </tr> -</table> - -<table border="0"> - <tr> - <td>Object Key: </td> - <td><table border="1"> - <tr> - <td>TAO</td> - <td>TAO version</td> - <td>Server Name</td> - <td>POA ID</td> - <td>OBJ ID (actually the OBJ Key of the Server)</td> - </tr> - </table> - </td> - </tr> -</table> - -<p>For servers that expect to remain in the same host/port for a -long time, the above IOR can be optimized by placing the server -profile in the IOR before the Implementation Repository -profile. TAO clients will first try the server, and if that -fails, then try the Implementation Repository. Clients from -other ORBs may behave the same way, but this isn't guaranteed -since the handling of multiple profiles is not yet in the CORBA -spec. There will be an option to only generate the IR-only IORs -for ORBs that do not support multiple profiles in the needed -manner. </p> - -<p>There will be a POA policy to determine which type of -Persistent IOR to use. By default, the Implementation -Repository alone version will be used.</p> - -<h4><a name="WhatwaswrongwiththeoldIOR">What was wrong with the -old IOR?</a></h4> - -<p>We need a place to put a TAO marker in the IOR so TAO servers -can differentiate TAO IORs from IORs of other vendors. In the -original scheme used in TAO, Persistent IORs had a null -timestamp. To support virtual servers, we will use that slot to -store the server name so the Implementation Repository knows -which server to launch.</p> - -<h4><a name="WhydoesImplRepocontainanOBJKey">Why does the -Implementation Repository profile contain an Object Key?</a></h4> - -<p>It needs to know what the object key of the object when -forwarding is used. A server may contain more than one object, so -the object key is needed to forward to the correct object on the -server. </p> - -<h3><a name="POAExtensions">POA Extensions</a></h3> - -<p>TAO's POA will contain a new TAO-specific method called <code>create_reference_with_virtual_server[_and_id] -(...)</code>. This method takes additional arguments for a -virtual server name and a sequence of Implementation Repository -IORs. The POA will register the virtual server name with each of -the Implementation Repositories in the sequence passed in. -Several Implementation Repositories can be specified to enhance -availability through redundancy. </p> - -<p>TAO's POA will also contain a policy for the type of IOR -created with <code>create_reference</code>. It can either -produce the standard type, with just a reference to the -Implementation Repository, or it can produce one also containing -a reference to the current server.</p> - -<h3><a name="PossibleFutureGoals">Possible Future Goals</a></h3> - -<p>The following are features that may be added to support TAO's -Implementation Repository: </p> - -<ul> - <li>Optimization on TAO clients to recognize when a server is - restarted, and change all other IORs that contain the - server instead of going through the Implementation - Repository</li> - <li>Some sort of server security that checks the executable - to make sure it is the correct executable (checksum, - signatures, etc).</li> - <li>Add the ability to put servers into DLLs or Shared Object - files so the Implementation Repository can load it via - those methods.</li> - <li>GUI interface for such things as the helper application.</li> - <li>Federations of Implementation Repositories.</li> - <li>The ability to start a remote server (possibly with rsh, - ssh, rexec, etc)</li> -</ul> - -<h3><a name="ServerRestrictions">Server Restrictions</a></h3> - -<p>Most often servers that have Persistent IORs will save their -state to secondary storage. Databases are a good example of this, -where the server can be stopped and restarted with all the -information remaining on disk. </p> - -<p>The server must also make sure it creates the POA and Object -in a way that does not change the POA ID and Object ID. The -Implementation Repository forwards requests based on the -information in the IOR; if the POA ID or Object ID changes, then -the Implementation Repository will be unable to sucessfully -forward requests. If the server implements dynamic servants and -dynamic POA activations, then this is not an issue since the -necessary POAs and servants will be created on demand.</p> - -<h3><a name="PreliminaryInterface">Preliminary Interface</a></h3> - -<p>The following is a proposed IDL interface for the TAO -Implementation Repository: </p> - -<pre>module TAO -{ - // .... - - exception Already_Registered {}; - // Object already bound in the Implementation Repository - - exception Cannot_Activate - { - string reason_; - }; - - exception Not_Found {}; - // Object not found in the Implementation Repository - - struct Environment_Variable - { - string name_; - string value_; - }; - // One environment variable - - struct INET_Addr - { - unsigned short port_; - unsigned long host_; - }; - // The location of a server - - typedef sequence<Environment_Variable> Environment; - // Complete environment - - typedef sequence<string> Command_Line_Options; - // Command line options - - struct Process_Options - { - string executable_name_; - // Executable name - - Command_Line_Options command_line_options_; - // Command line options - - Environment environment_; - // Environment - - string working_directory_; - // Working directory - - unsigned long creation_flags_; - // Creation flags - }; - - interface Ping_Object - { - oneway void ping (); - // Used for checking for liveness of a server. When the server receives - // this, it should send back a response indicating it is sill alive. - // Depending on the policy specified, a timeout can be reached where the - // Implementation Repository will restart the server. - }; - - interface Implementation_Repository - { - Object activate_object (in Object obj) - raises (Not_Found, - Cannot_Activate); - // Restart server that will contain this persistent object and return the - // new Object reference. - // - // The <Not_Found> exception is raised when <obj> is not found - // in the Implementation Repository. The <Cannot_Activate> exception - // is raised when <obj> is found in the Repository but could not be - // activated. - - INET_Addr activate_server (in string server) - raises (Not_Found, - Cannot_Activate); - // Restart server that is named <server> and return the host/port - // - // - // The <Not_Found> exception is raised when <server> is not found - // in the Implementation Repository. The <Cannot_Activate> exception - // is raised when <server> is found in the Repository but could not be - // activated. - - void register_server (in string server, - in Process_Options options) - raises (Already_Registered); - // Restart server process when client is looking for <server>. - // - // The <Already_Registered> exception is raised when <server> has - // already been registered with the Implementation Repository. - // - // The <Object_Not_Persistent> exception is raised when <server> is - // not a Persistent Object Reference. - - void reregister_server (in string server, - in Process_Options options) - raises (Already_Registered); - // Restart server process when client is looking for <server>. - // - // The <Already_Registered> exception is raised when <server> has - // already been registered with the Implementation Repository. - // - // The <Object_Not_Persistent> exception is raised when <server> is - // not a Persistent Object Reference. - - void remove_server (in string server) - raises (Not_Found); - // Remove <server> from the Implementation Repository. - // - // The <Not_Found> exception is raised when <server> is not found - // in the Implementation Repository. - - Profile server_is_running (in string server, - in INET_Addr addr, - in Ping_Object ping); - // Used to notify the Implementation Repository that <server> is alive and - // well at <addr>. - - void server_is_shutting_down (in string server); - // Used to tell the Implementation Repository that <server> is shutting - // down. - }; -};</pre> - -<hr> - -<h2><a name="AlternateImplementations">Alternate Implementations</a></h2> - -<p>Other ORB vendors use alternative techniques for their -Implementation Repositories. These techniques usually require new -naming techniques to access persistent object references and new -client-side APIs to bind to persistent object references. TAO's -Implementation Repository will not require such extensions. </p> - -<p>A possible design alternative for the IR might use an Object -Reference that points to the Implementation Repository instead of -pointing directly to the persistent object. This extra level of -indirection would be used by the Implementation Repository to -start the server, if needed. The Location Forwarding mechanism -would then be used to forward the client request to the server. -The difference between this design and TAO's design is that the -persistent IOR in TAO will contain a profile pointing to a -location of the server (where it still might be running) to try -first, and then only if that fails does the client contact the -Implementation Repository. This is an optimization for case where -the server does not shut down often, and most requests do not -need to be forwarded to a new address.</p> - -<p>In cases where most requests will require a forward, TAO can -support a policy that is just like this alternative, where the -Implmentation Repository will be contacted first.</p> - -<hr> - -<h2><a name="AccessingtheImplementationRepository">Accessing the -Implementation Repository</a> </h2> - -<p>The Implementation Repository will be transparent to the -clients and the servers. Clients will only deal with IIOP 1.1 -IORs, and in the default case all the Implementation Repository -logic on the server side will be handled internally by the ORB -and the POA. </p> - -<h3><a name="HelperApplication">Helper Application</a></h3> - -<p>A helper application will be included with the Implementation -Repository. It will be a command-line utility that will assist -users with adding and removing server records (containing virtual -server names and executable name/options) from the Implementation -Repository. </p> - -<h3><a name="LocatinganinstanceofImplRepo">Locating an Instance -of the Implementation Repository </a></h3> - -<h4><a name="Serverside">Server-side</a></h4> - -<p>In the default case, the Implementation Repository will be -found via the command-line, environment variables, and multicast -(in that order). This location strategy is consistent with that -used by TAO to local its default Naming Service instance. Using -the POA extensions, other Implementation Repositories can be -specified in the call to <code>POA::create_reference_with_virtual_server</code>. -The default port of the Implementation Repository can be -overridden through command-line options or environment variables. -</p> - -<h4><a name="Clientside">Client-side</a></h4> - -<p>One or more Implementation Repositories will be stored in -additional profiles in the IOR. Other Implementation Repositories -can also be located by multicasting (on a default multicast -group) the server name of the Persistent Object the client is -interested in. The default multicast group and default port of -the Implementation Repository can be overridden through command -line options or environment variables. </p> - -<p>In most cases, one Implementation Repository will be enough. -For redundancy, several Implementation Repositories can be -specified.</p> - -<hr> - -<h2><a name="Howitworks">How It Works</a></h2> - -<h3><a name="HowServerProducesPersistentIORdefault">How a server -produces a Persistent IOR (in the default case)</a></h3> - -<p>Before a server starts, it must be registered (via a -command-line utility) with an implementation repository. On -platforms that don't support multicast, the Implementation -Repository must be specified on the command line or in an -environment variable. </p> - -<ol> - <li>When the server starts up it calls <code>ORB_init</code>. - <code>ORB_init</code>, if not passed a server name, will - take argv[0] and use that as a default server name (TAO - expects this to be the executable name). </li> - <li><code>ORB_init</code> will create a ping object.</li> - <li><code>ORB_init</code> will look for Implementation - Repositories on the command-line, environmental - variables, and then through multicast (in that order). - Once it finds one it registers itself and passes the ping - object to the implementation repository with <code>server_is_running</code> - operation. </li> - <li>The profile returned by registration will be stored for - later use.</li> - <li>Client later can call the <code>POA::create_reference</code> - operation.</li> - <li>The <code>create_reference</code> operation will create - the local profile.</li> - <li>The stored Implementation Repository profile will have - its object id changed to be the object key just created.</li> - <li>Both profiles will be joined together if the multiple - profile IOR policy is set, and then returned.</li> -</ol> - -<h3><a name="HowServerProducesPersistentIORcomplex">How a server -produces a Persistent IOR (in complex cases)</a></h3> - -<p>As with the default case, the server must be registered with -an Implementation Repository, although it does not need to be -multicast aware since the IORs will be passed to the POA by the -program. </p> - -<ol> - <li><code>ORB_init</code> is called and does the default work - (if it has Implementation Repositories to contact).</li> - <li><code>POA::create_reference_with_virtual_server[_and_id]</code> - will be called with a server name and list of - Implementation Repositories. </li> - <li>The profile for the object is created.</li> - <li>The ping object created in <code>ORB_init</code> and the - object key is passed to the Implementation Repositories, - and their profiles are returned.</li> - <li>Both profiles will be joined together if the multiple - profile IOR policy is set, and then returned.</li> -</ol> - -<h3><a name="HowClientUsesPersistentIOR">How a client uses a -Persistent IOR</a></h3> - -<p>For all Clients: </p> - -<ul> - <li>Client obtains a Persistent Object Reference, which - contains multiple profiles to both regular objects and - Implementation Repositories.</li> - <li>It will now make a request on the first profile.</li> - <li>If the first profile if the server profile, and the - server is still there, then it will be successful. - If the server has moved (or shut down), then the next - profile will be tried.</li> - <li>If the first profile is the Implementation Repository, or - if the server profile failed, then it will be - contacted. The Implemenation Repository will then - return NOT_FOUND or will start up the server and return a - Location Forward message.</li> -</ul> - -<p>If everything fails, then most clients will return failure for -the request. TAO clients will attempt to contact other -Implementation Repositories that are specified on the -command-line, in environment variables, or found through -multicast. </p> - -<ul> - <li>If all of the profiles fail, then contact the other - Implementation Repositories. First get those specified on - the command line or in environment variables.</li> - <li>Then, if multicast is available: <ul> - <li>Multicast the Object Reference to a group of - Implementation Repositories </li> - <li>Wait until response or a timeout. The response - will contain the Object Reference of a - Implementation Repository that knows about the - Object Reference </li> - </ul> - </li> - <li>Connect to the Implementation Repository that responds - first.</li> - <li>Call <i>activate</i> passing the Persistent Object - Reference.</li> - <li>If a new Object Reference was sent back then retry the - request using the it. If this request fails, then fail - (no more retries).</li> - <li>If a null reference was sent back, then fail.</li> -</ul> - -<p>TAO clients will have an optimization where if there are -several IORs that have the same server name, and one of them gets -forwarded, then the client will be able to change its other IORs -without going through the overhead of contacting Implementation -Repository.</p> - -<hr> - -<p>Last update to this document: $Date$</p> - -<p>Back to <a href="../releasenotes/">TAO Release Notes</a></p> - -<p>Back to <a href="index.html">Implementation Repository</a></p> -</body> -</html> diff --git a/TAO/docs/implrepo/tao_imr.html b/TAO/docs/implrepo/tao_imr.html deleted file mode 100644 index 88b6e330000..00000000000 --- a/TAO/docs/implrepo/tao_imr.html +++ /dev/null @@ -1,290 +0,0 @@ -<html> -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" -content="text/html; charset=iso-8859-1"> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -<title>Implementation Repository User's Guide</title> -</head> - -<body bgcolor="#FFFFFF"> - -<hr> - -<h2>tao_imr Usage</h2> - -<p>The usage of tao_imr is as follows:</p> - -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] <a href="#commands">command</a> -[command-arguments]</code></p> - -<p><i>ORB_options</i> is the ORB options to be given. This is where -options like "-ORBInitRef ImplRepoService=file://implrepo.ior" would be placed. -<i>command </i>is one of the supported commands like add, remove, etc. <i>command-arguments</i> -are dependent on the command used. For example, <i>add </i>will need a -server name for registration, but list does not necessarily need any arguments.</p> - -<hr> - -<h3><a name="examples">Examples</a></h3> -<p>There is a file in the current directory name <i>implrepo.ior</i> that -contains the IOR of the Implementation Repository. The server executable -is called <i>airplane.exe</i> and the POA name used by the object is <i>plane</i>. -The server needs the -i option to use the IMR and the IOR of the IMR. So the -command would be:</p> - -<p><code>tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior add plane -c "airplane.exe --i file://implrepo.ior"</code></p> - -<p><code>And if you want to later remove that server from the IMR:</code></p> - -<p><code>tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior remove plane</code></p> - -<p>Or if you wanted to update the entry to have a working directory of -C:\airplane\.</p> - -<p><code>tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior update plane -w -"C:\airplane\"</code></p> - -<hr> - -<h3><a name="commands">Commands</a></h3> - -<p><i>tao_imr</i> currently supports these commands:</p> - -<table border="1"> - <tr> - <th>Command</th> - <th>Description</th> - </tr> - <tr> - <td><a href="#activate">activate</a></td> - <td>Activates a server through the IMR</td> - </tr> - <tr> - <td><a href="#add">add</a></td> - <td>Adds a server to the server database in the IMR</td> - </tr> - <tr> - <td><a href="#autostart">add</a></td> - <td>Activates all servers that are marked AUTO_START</td> - </tr> - <tr> - <td><a href="#ior">ior</a></td> - <td>Creates a simple IOR for a registered server</td> - </tr> - <tr> - <td><a href="#list">list</a></td> - <td>Lists the details of one server or lists all the servers registered in - the IMR</td> - </tr> - <tr> - <td><a href="#remove">remove</a></td> - <td>Removes a server from the server database in the IMR</td> - </tr> - <tr> - <td><a href="#shutdown">shutdown</a></td> - <td>Shuts down a server through the IMR</td> - </tr> - <tr> - <td><a href="#update">update</a></td> - <td>Updates information for a server in the server database in the IMR</td> - </tr> -</table> - -<hr> - -<h3><a name="activate">activate</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] activate <i>name </i>[-h]</code></p> - -<p>Activate a server through the Implementation Repository. The <i>name</i> is -the server (POA) name that is used to identify the server.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> -</table> - -<hr> - -<h3><a name="add">add</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] add <i>name </i>[-h] -[-c <i>command</i>] [-w <i>working_dir</i>] [-a NORMAL|MANUAL|PER_CLIENT]</code></p> - -<p>Creates a new server entry in the Implementation Repository. The <i>name</i> -must be be the name of the POA that the object resides in.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> - <tr> - <td>-c <i>command</i></td> - <td>Adds the command line string used to restart this server</td> - </tr> - <tr> - <td>-w <i>working_dir</i></td> - <td>Adds the working directory that is used for the server</td> - </tr> - <tr> - <td>[-a NORMAL|MANUAL|PER_CLIENT|AUTO_START]</td> - <td>Specifies the type of activation.<br> - NORMAL = normal activation (default)<br> - MANUAL = only can be started manually on the command line or with tao_imr<br> - PER_CLIENT = each client that contacts the ImplRepo will get its own activated server<br> - AUTO_START = activated when the IMR is started or when tao_imr autostart is used</td> - </tr> -</table> - -<hr> - -<h3><a name="auto_start">auto_start</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] auto_start [-h]</code></p> - -<p>Activates all servers with the activation mode of AUTO_START. It will not start new -copies if the server is already activated.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> -</table> - -<hr> - -<h3><a name="ior">ior</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] ior <i>name</i> [-h] -[-f <i>filename</i>]</code></p> - -<p>Creates a simple IOR that can be used with the Implementation Repository. Please refer -to the <a href="usersguide.html">User's Guide</a> for more information on when to use this -command.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> - <tr> - <td>-f <i>filename</i></td> - <td>Outputs the IOR also to this file</td> - </tr> -</table> - -<hr> - -<h3><a name="list">list</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] list [<i>name</i>]<i> -</i>[-h] [-v]</code></p> - -<p>Lists all or one of the server entries in the Implementation Repository. If a -<i>name</i> is used, it will display verbose information about the server -identified by its server (POA) name.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> - <tr> - <td>-v</td> - <td>When listing the list of servers (no <i>name</i> specified), display - verbose information for all servers.</td> - </tr> -</table> - -<hr> - -<h3><a name="remove">remove</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] add <i>name </i>[-h]</code></p> - -<p>Removes a server entry from the Implementation Repository. The <i>name</i> is -the server (POA) name that is used to identify the server.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> -</table> - -<hr> - -<h3><a name="shutdown">shutdown</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] shutdown <i>name </i>[-h]</code></p> - -<p>Shuts down a server through the Implementation Repository. The <i>name</i> is -the server (POA) name that is used to identify the server.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> -</table> - -<hr> - -<h3><a name="update">update</a></h3> -<p><code><b>tao_imr </b>[<a href="../Options.html">ORB options</a>] add <i>name </i>[-h] -[-c <i>command</i>] [-w <i>working_dir</i>]</code></p> - -<p><code>Update a server entry in the Implementation Repository. </code>The <i>name</i> -is the server (POA) name that is used to identify the server.</p> - -<table border="1"> - <tr> - <th>Option</th> - <th>Description</th> - </tr> - <tr> - <td>-h</td> - <td>Displays help for this command</td> - </tr> - <tr> - <td>-c <i>command</i></td> - <td>Changes the command line string used to restart this server</td> - </tr> - <tr> - <td>-w <i>working_dir</i></td> - <td>Changes the working directory that is used for the server</td> - </tr> -</table> - -<hr> - -<p>Back to <a href="index.html">Implementation Repository</a></p> -</body> -</html> diff --git a/TAO/docs/implrepo/usersguide.html b/TAO/docs/implrepo/usersguide.html deleted file mode 100644 index d268e7860b9..00000000000 --- a/TAO/docs/implrepo/usersguide.html +++ /dev/null @@ -1,24 +0,0 @@ -<html> -<!-- $Id$ --> - -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -<title>Implementation Repository User's Guide</title> -</head> - -<body bgcolor="#FFFFFF"> - -<hr> - -<p><b>Note:</b> I have moved most of the documentation here to doxygen, so -they are now <a href = "../../../html/tao/implrepo_service/index.html">here</a>. - - -<hr> - -<p>Last update to this document: $Date$</p> - -<p>Back to <a href="index.html">Implementation Repository</a></p> -</body> -</html> diff --git a/TAO/docs/index.html b/TAO/docs/index.html deleted file mode 100644 index b7cf1b75376..00000000000 --- a/TAO/docs/index.html +++ /dev/null @@ -1,69 +0,0 @@ -<html> - -<head> - -<!-- $Id$ --> - -<meta NAME="GENERATOR" CONTENT="Microsoft FrontPage 4.0"> -<title>TAO Documentation</title> -</head> - -<body text="#000000" link="#0000ff" vlink="#cc0000" bgcolor="#ffffff"> - -<hr> - -<h3 ALIGN="CENTER">TAO <A -HREF="http://www.omg.org/library/c2indx.html">CORBA</a> Documentation</h3> -<div align="center"><center> - -<table cellpadding="10" cellspacing="8" border="10"> - <tr> - <td><font SIZE="+1"><dl> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a HREF="http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html">Technical - Papers</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a HREF="http://www.cs.wustl.edu/~schmidt/TAO/index.html">Tutorials</a></dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a HREF="releasenotes/index.html">Release Notes</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <A HREF="http://www.theaceorb.com">OCI</A> TAO <a HREF="http://www.theaceorb.com/faq/">FAQ</a> </dt><P> - </dl> - </td> - - <td><font SIZE="+1"><dl> - <DT> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <A - HREF="http://www.dre.vanderbilt.edu/Doxygen/">Doxygen Documentation</A> <P> - <dt> <img alt="o" - src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="components.html">ORB Configuration & Tuning</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a HREF="compiler.html">IDL Compiler Options</a> </dt><P> - <dt> <img alt="o" - src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a HREF="libraries.html">Library Subsets</a></dt><p> - </dl> - </td> - - <td><font SIZE="+1"><dl> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="orbsvcs.html">ORB Services Documentation</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="Tags.html">Tags and Magic Numbers</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a href="rtcorba/index.html">Real-Time CORBA</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="INS.html">Interoperable Naming Service</a> </dt><P> - </dl> - </font> - </td> - - <td><font SIZE="+1"><dl> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="implrepo/index.html">Implementation Repository</a> </dt><P> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> TAO <a href="exceptions.html">Exception Handling</a></dt><p> - <dt> <img alt="o" src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="pluggable_protocols/index.html">Writing Pluggable Protocols</a> </dt><P> - <dt> <img alt="o" - src="http://www.cs.wustl.edu/~schmidt/gifs/misc/redball.gif"> <a HREF="es_configs.html">Event Service Configurations</a> </dt><P> - - </dl> - </font> - </td> - - </tr> -</table> -</center></div> - -<P><hr> - -<p>Back to the <a HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a> home page. <!--#include virtual="/~schmidt/cgi-sig.html" --> </p> -</body> -</html> diff --git a/TAO/docs/interceptors.html b/TAO/docs/interceptors.html deleted file mode 100644 index 318f2023315..00000000000 --- a/TAO/docs/interceptors.html +++ /dev/null @@ -1,409 +0,0 @@ -<HTML> -<TITLE>Portable Interceptors</TITLE> -<BODY> - -<hr><P> -<H3>Portable Interceptors</H3> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<p>We have revised TAO's interceptor implementation so that it -conforms to the Portable Interceptor specification which is now a part -of the <a href="http://www.omg.org/cgi-bin/doc?formal/04-03-01">CORBA -3.0.3</A> specification. The purpose of this document is to provide a -transition guide for those who have used our old interceptors. The -old interceptors will no longer be supported now that we have the new -mechanism in place. A paper that describes TAO's portable -interceptors and <A HREF="Smart_Proxies.html">smart proxies</A> is -available -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/smart_proxies.pdf">online</A>. -</p> - -<hr><P> -<h3><a name="toc">Table of Contents</a></h3> -<ul> - <li><a href="#context">Context</a> - <li><a href="#implement">TAO's Implementation</a> - <li><a href="#api">Transition</a> - <li><a href="#status">Current Status</a> - <li><a href="#future">Future Work</a> - <li><a href="#issues">Known Issues</a> - <li><a href="#ref">References</a> -</ul> - -<hr><P> -<h2><a name="context">Context</a></h2> - -<p>Interceptors allow you to interpose other CORBA services to the ORB -and extend the ORB's functionalities. They are most commonly used in, -but not limited to, Security Service, Transaction Service. They are -also for accounting, auditing and debugging distributed applications. -</p> - -<hr><P> -<h3><a name="implement">TAO's Implementation of "Portable -Interceptors"</a></h3> - -<p>We have modifed TAO's interceptor interface to conform with the -CORBA 2.5 spec. The current implementation of interceptors consists of -support for the <CODE>Dynamic</CODE> module as well as the canonical -interception points including -(1) <CODE>send_request</CODE>, -(2) <CODE>receive_reply</CODE>, -(3) <CODE>receive_exception</CODE>, -(4) <CODE>receive_other</CODE>, -(5) <CODE>receive_request_service_contexts</CODE>, -(6) <CODE>receive_request</CODE>, -(7) <CODE>send_reply</CODE>, -(8) <CODE>send_exception</CODE>, -(9) <CODE>send_other</CODE>, and -(10) <CODE>establish_components</CODE> (specific to -<CODE>IORInterceptor</CODE>s). Each request interception point is -passed a <CODE>RequestInfo</CODE> object which encapsulates the -details of the operation like arguments, etc. The IOR interception -point is passed an <CODE>IORInfo</CODE> object that encapsulates -operations for adding tagged components to profiles in an IOR. -Registration of all three types of interceptors (client and server -request interceptors, and IOR interceptors) is now done using the -interface provided by the standard <CODE>ORBInitInfo</CODE> -object.</p> - -<p> -Details of this implementation along with benchmarking is available in -the paper on <a -href="http://www.cs.wustl.edu/~schmidt/PDF/COOTS-00.pdf">Meta-programming -mechanisms.</a> -</p> - -<p> Examples on this new version of Portable Interceptors is available -at <CODE>$TAO_ROOT/tests/Portable_Interceptors</CODE>.</p> - -<hr><P> -<h3><a name="api">Transitting from TAO's Old "Portable" -Interceptor APIs to the Standard Portable Interceptor APIs</a></h3> - -<p>Please refer to CORBA 2.5 specification for details on the proposed -Portable Interceptor interfaces. Below is the old but now obsolete -interceptor version in TAO.</p> - -<pre> -// -*- IDL -*- $Id$ - -// This file contains the interface definitions for "Portable" -// Interceptor support. - -// ********************************************************** -// Notice that the Portable Interceptor specification -// is still under discussion in OMG and both the IDL -// and the implementation details in TAO will eventually -// change to conform with the PI spec in the future. -// -// @@ Now that a working draft of the Portable Interceptors -// is available, we will provide a compliant implementation -// shortly. -// -// Please see the annotation marked with "@@" in this file -// for hints on transitting from the temporary -// implementation to new APIs. -// -// See $TAO_ROOT/docs/interceptors.html for more info. -// ********************************************************** - -// Author (currently): Nanbor Wang <nanbor@cs.wustl.edu> -// @@ I will no longer be the author of this IDL file. ;-) - -#include <corba.pidl> -#include <IOP.pidl> - -#pragma prefix "TAO" -// The prefix should be changed to "omg.org" once the spec. gets -// finallized. -// @@ The prefix will be changed to "omg.org". - -module PortableInterceptor -{ - interface Cookie - { - // Cookie's are used to pass information among interceptors - // within a invocation or an upcall. - // - // @@ Cookie will no longer be available. - string myname (); - }; - - typedef sequence<Cookie> Cookies; - // Collections of Cookie's become Cookies'es. - // - // @@ Cookies will no longer be available. - - interface Interceptor - { - // Base interface for Interceptors. - // - // @@ This interface will not change. - readonly attribute string name; - }; - - interface ServerRequestInterceptor : Interceptor - { - // Server side request interceptor definition. - // - // @@ The name of the interface will not change. - - void preinvoke (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout IOP::ServiceContextList sc, - inout NVList arguments, - inout Cookies ck); - // Interception pointer before invoking the servant method. - // Currently, we don't pass NVList into the interceptor because - // I haven't figured out how to best optimize this stuff. - // In the future, NVList will contain all in and inout arguments - // of the operation. - // - // @@ This operation will map to either - // <receive_request_service_contexts> or <receive_request> of - // the standard APIs. If you are not sure, use - // <receive_request>. - // - // void receive_request_service_contexts (in ServerRequestInfo ri) raises (ForwardRequest); - // void receive_request (in ServerRequestInfo ri) raises (ForwardRequest); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ServerRequestInfo> interface. - - void postinvoke (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout IOP::ServiceContextList sc, - inout NVList arguments, - inout Cookies ck); - // Interception pointer after invoking the servant method. - // Currently, we don't pass NVList into the interceptor because - // I haven't figured out how to best optimize this stuff. - // In the future, NVList will contain all out, inout arguments - // and the return value of the operation. - // - // @@ This operation will map to <send_reply>. - // It is not clear whether oneway call will invoke <send_other> - // operation or not. - // - // void send_reply (in ServerRequestInfo ri); - // void send_other (in ServerRequestInfo ri) raises (ForwardRequest); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ServerRequestInfo> interface. - - void exception_occurred (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout Cookies ck); - // Exception interception point. - // - // @@ This method will map to <send_exception> method. - // - // void send_exception (in ServerRequestInfo ri) raises (ForwardRequest); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ServerRequestInfo> interface. - }; - - interface ClientRequestInterceptor : Interceptor - { - // Client side interceptor. - // - // @@ The name of the interface will not change. - - void preinvoke (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout IOP::ServiceContextList sc, - inout NVList arguments, - inout Cookies ck); - // Before remote invocation. - // Currently, we don't pass NVList into the interceptor because - // I haven't figured out how to best optimize this stuff. - // In the future, NVList will contain all in and inout arguments - // of the operation. - // - // @@ This operation will map to <send_request> of the standard - // APIs. - // - // void send_request (in ClientRequestInfo) raises (ForwardRequest); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ClientRequestInfo> interface. - - void postinvoke (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout IOP::ServiceContextList sc, - inout NVList arguments, - inout Cookies ck); - // After returned from remote invocation. - // Currently, we don't pass NVList into the interceptor because - // I haven't figured out how to best optimize this stuff. - // In the future, NVList will contain all out, inout arguments - // and the return value of the operation. - // - // @@ This operation will map to either <receive_reply> or - // <receive_other> in the standard APIs depending on whether the - // operation is oneway or not. - // - // void receive_reply (in ClientRequestInfo ri); - // void receive_other (in ClientRequestInfo ri); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ClientRequestInfo> interface. - - void exception_occurred (in unsigned long request_id, - in boolean response_expected, - in CORBA::Object objref, - in string operation_name, - inout Cookies ck); - // Exception occurred. - // - // @@ This method will map to <receive_exception> method as: - // - // void receive_exception (in ClientRequestInfo ri) raises (ForwardRequest); - // - // @@ Note that all arguments will be accessed thru - // <PortableInterceptor::ClientRequestInfo> interface. - }; -}; - -#pragma prefix "" -</pre> - -<hr><P> -<h3><a name="status">Current Status</a></h3> -<ul> - <li>The core infrastructure is in place as well as the canonical - request and IOR interception points: - <CODE>send_request</CODE>, - <CODE>receive_reply</CODE>, - <CODE>receive_exception</CODE>, - <CODE>receive_other</CODE>, - <CODE>receive_request_service_contexts</CODE>, - <CODE>receive_request</CODE>, - <CODE>send_reply</CODE>, - <CODE>send_exception</CODE>, - <CODE>send_other</CODE>, and - <CODE>establish_components</CODE>. - The remaining client request interception point, - <CODE>send_poll</CODE>, is <EM>time independent invocation</EM> - specific. Once TAO supports time independent invocations, the - <CODE>send_poll</CODE> interception point will be implemented. - <li><CODE>ORBInitializer</CODE> registration has been implemented, - as per the spec. - <li>Registration of interceptors is now conformant to the spec - through the <CODE>ORBInitInfo</CODE> class. Multiple - interceptors may now be registered. - <li>IOR interceptors have been implemented. They allow an external - service, for example, to add tagged components to profiles - within IORs as they are being generated. - <li>Policy factory registration, i.e. - <CODE>ORBInitInfo::register_policy_factory</CODE>, has been - implemented. Corresponding policies can then be created using - the <CODE>ORB::create_policy</CODE> method. - <li>Initial reference registration, i.e. - <CODE>ORBInitInfo::register_initial_reference</CODE>, has been - implemented. This is particularly useful for registering local - objects with the ORB's <CODE>resolve_initial_references</CODE> - mechanism since they can't be stringified and registered via - <CODE>-ORBInitRef</CODE> ORB option. - <li>Basically, all <CODE>ORBInitInfo</CODE> methods have been - implemented except <CODE>allocate_slot_id</CODE>. - <li>Implemented most of the remaining - <CODE>ClientRequestInfo</CODE>, <CODE>ServerRequestInfo</CODE> - and <CODE>IORInfo</CODE> methods. - <li>Added support for the - <CODE>PortableInterceptor::ForwardRequest</CODE> - exception on both the client and server sides. - <li>Implemented the <CODE>IOP::CodecFactory</CODE> and the CDR - encapsulation <CODE>IOP::Codec</CODE> objects. The CDR - encapsulation <CODE>Codec</CODE> is useful for embedding data in - an <CODE>octet</CODE> sequence that conforms to the CDR - encapsulation rules. For example, it could be used to marshal - data into the <CODE>octet</CODE> sequence that is part of an - <CODE>IOP::ServiceContext</CODE> or an - <CODE>IOP::TaggedComponent</CODE>. This means that it could - compliment the IOR interceptor support, and the service context - manipulation support found in request interceptors. - <li>Implemented the - <CODE>PortableInterceptor::ServerRequestInfo::object_id</CODE>, - <CODE>PortableInterceptor::ServerRequestInfo::adapter_id</CODE> - and - <CODE>PortableServer::POA::id</CODE> methods. - <li>Greatly improved the speed of the - <CODE>PortableInterceptor::RequestInfo::arguments</CODE> method - for the case when a given target method has more than one - parameter. - <li>Corrected the <CODE>Dynamic::Parameter</CODE> IDL. It now - correctly uses the <CODE>CORBA::ParameterMode</CODE> enumeration - in place of the <CODE>Dynamic::ParameterMode</CODE> - enumeration. The latter has been removed since it was not a - standard type. - <li>The - <CODE>PortableInterceptor::ClientRequestInterceptor::send_request</CODE> - interception point now occurs before a connection attempt to the - target is ever made. This greatly improves the speed of client - request interceptor initiated <CODE>LOCATION_FORWARD</CODE>s, in - addition to making it possible to prevent connection attempts - from occuring by throwing an exception, for example. - <li>Corrected <CODE>PortableInterceptor::ForwardRequest</CODE> - exception support. It is longer possible to throw a - <CODE>PortableInterceptor::ForwardRequest</CODE> exception in - application code (i.e. not an interceptor) and expect it to be - converted to a <CODE>LOCATION_FORWARD</CODE>. A - <CODE>PortableInterceptor::ForwardRequest</CODE> exception will - now only be treated as a <CODE>LOCATION_FORWARD</CODE> if it is - thrown from an interception point capable of raising that - exception. Otherwise it will be propagated to the client. This - change also has the added benefit of reducing the stub/skeleton - footprint, particularly for IDL with many interfaces. - <li>Implemented <CODE>PortableInterceptor::Current</CODE> interface, - <CODE>ORBInitInfo::allocate_slot_id</CODE>, - <CODE>ClientRequestInfo::get_slot</CODE>, - <CODE>ServerRequestInfo::get_slot</CODE>, - <CODE>ServerRequestInfo::set_slot</CODE>, and - <CODE>ServerRequestInfo::get_server_policy</CODE> methods. - <li>Client interception points are now invoked for AMI calls. -</ul> - -<hr><P> -<h2><a name="future">Future Work</a></h2> -<ol> - <li>Add support for the <CODE>ThruPOA</CODE> collocation - optimization to the interceptor chain; the <CODE>direct</CODE> - collocation optimization will not go through the interceptor - chain. - <li>The <CODE>send_poll</CODE> request interception point - implementation will most likely be deferred until TII is - supported in TAO. -</ol> - -<hr><p> -<h3><a name="issues">Known Issues</a></h3> -<ul> - <li>Currently none.</li> -</ul> - -<hr><P> -<H3><a name="ref">References</a></H3> -<UL> - <LI><A HREF="http://www.omg.org/cgi-bin/doc?formal/04-03-01">formal/2004-03-01</A> -- CORBA 3.0.3 Specification -- contains the Portable Interceptors chapter</LI> - -</UL> -<hr> - -</BODY> diff --git a/TAO/docs/interfacerepo/index.html b/TAO/docs/interfacerepo/index.html deleted file mode 100644 index 8bd63ecadb3..00000000000 --- a/TAO/docs/interfacerepo/index.html +++ /dev/null @@ -1,211 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<title>Dynamic Any Status</title> -<!-- $Id$ --> -</head> -<body text="#000000" bgcolor="#FFFFFF"> - -<!-- *********************************** --> -<a name="toc"><h2>Table of Contents</h2></a> -<ul> - <li><a href="#current">Current Status</a> - <li><a href="#issues">Known Issues</a> - <li><a href="#ongoing">Ongoing work</a> - <li><a href="#future">Future Work</a> - <li><a href="#completed">Completed Work</a> -</ul> -<!-- *********************************** --> - -<hr> -<center> -<h1> <a name="interfacerepo"></a>Interface Repository</h1> - -Point of contact: <a href="mailto: parsons@cs.wustl.edu">Jeff Parsons</a> - -<p>Last Update: October 21, 2003 </p> -</center> - - -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 invoke requests using the DII. - -<p><a href="tao_ifr.html">tao_ifr Guide</a> - Guide to the usage of, and command line options for, tao_ifr, the interface repository loader.</p> - -<!-- ============================================================ --> -<a name="current"><h3>Current status:</h3></a> - -<ul> - - <li><p>Fully compliant with OMG 3.0 spec.</p> - </li> - - <li><p>Fully compatible with CorbaScript.</p> - </li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="issues"><h3>Known issues:</h3></a> - -<ul> - -<li> If, while processing an IDL file, tao_ifr discovers that the interface -repository id of some declaration in that file already exists in the repository, the reason may be one of the following: (1) the existing entry is for a different type, and so there is a name clash with some repository entry which came from another IDL file; (2) both entries are for an interface declaration, in which case the new entry may be (a) a full definition of a forward declaration from the other IDl file or (b) there is a name clash. If the case is (2), then tao_ifr has no way of telling whether it has an instance of (a) or (b). We have chosen to follow the path taken by other ORB vendors - when tao_ifr comes across this situation, it will replace the old repository entry with the new one.</li><p> - -<li> With the chosen design, calling move() on a Contained IR object will -invalidate the object reference, since the object ID is based on the path -to the object in the database. This is not expected to be a serious problem -in the forthcoming implementation of automatic IFR administration, but users -should be aware of this, if they attempt to write their own IFR administration -code.</li><p> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="ongoing"><h3>Ongoing Work:</h3></a> - -<ul> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="future"><h3>Future work:</h3></a> - -<ul> - -<li> Add support for recursive structs and unions to the IFR, and for -their typecodes to the TypeCodeFactory.</li><p> - -<li> Add capability to resize the hash maps that provide low-level storage for the IFR, when the hash map resize feature is added to ACE.</li><p> - -<li> Add pluggability for commonly used OTS databases.</li><p> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="completed"><h3>Completed Work:</h3></a> - -<!-- ************************************************************ --> -<!-- Please make sure you append new items at the end of the list --> -<!-- ************************************************************ --> - -<ul> - -<li> The Interface Repository Service has been added to TAO, in -ACE_wrappers/TAO/orbsvcs/IFR_Service. The implementation follows the -expanded IDL found in CORBA Components vol. III. The database used to store -IR objects is an ACE tool called ACE_Configuration, written by -<a href="mailto:chafey@stentorsoft.com">Chris Hafey</a>. This -class represents its contents to the user as a tree of hash maps. -By specifying a disk file to read from at startup, the storage may -be made persistent. There is also an option to use a win32 registry -to store the data, although persistence is not available with this -option.</li><p> - -<li> Several methods have been added to class TypeCodeFactory, including -create_exception_tc, create_alias_tc, create_native_tc, create_wstring_tc, -create_value_box_tc, and create_union_tc. Union typecodes with both -multiple and default case labels have been tested.</li><p> - -<li> Test code for the IFR service has been added in the directory -ACE_wrappers/TAO/orbsvcs/tests/InterfaceRepo/IFR_Test.</li><p> - -<li> Code to support multicast discovery of the Interface Repository -IOR has been added to TAO. Testing has been done using loopback on NT, -loopback on Solaris, and remotely between these two platforms in both -directions.</li><p> - -<li> Read/write locking option added to IFR service. This option should be -used if the IFR service is started using a service config file that -chooses the thread-per-request threading model.</li><p> - -<li> A test of the persistence option for the IFR added in the directory -ACE_wrappers/TAO/orbsvcs/tests/InterfaceRepo/Persistence_Test.</li><p> - -<li> Executable to add or subtract the contents of an IDL file to/from the -IFR, has been added. This executable uses the TAO IDL compiler front end library, -with a new back end library and top level executable. An application-style test has -also been added wherein a server is started, the IFR started, the contents of the IDL -file added to the IFR, a client started, which discovers information about a desired -operation by searching the IFR, and a DII request constructed from this information. -</li><p> - -<li> The TypeCodeFactory has been moved from the IFR_Service directory to its own -directory under TAO/tao, taking its place alongside the other satellite libraries -that have been created recently.</li><p> - -<li> IFR has been made compliant with the CORBA 2.4 version of Interface.idl. -Two new IFR object classes have been added, AbstractInterfaceDef and -LocalInterfaceDef. Some data structures have changed, as well as the signature -of some operations.</li><p> - -<li> The create_*_tc functions have been replaced in CORBA::ORB (as part of the -CORBA 2.x IFR compliance). These functions call the corresponding TypeCodeFactory -functions. The methods are also hooks, so that the TypeCodeFactory does not have to -be built and linked if an application does not intend to call those functions. If -it does, however, the application should have -#include "tao/TypeCodeFactory_Adapter_Impl.h" or something similar in it somewhere, -and also link to the TAO_TypeCodeFactory library. This will automatically load the -library if it has been compiled. Please see the example in -ACE_ROOT/TAO/examples/TypeCode_Creation.</li><p> - -<li> The CORBA::Object::_get_interface() method has been implemented. This method will -resolve the IFR of the target object (whether local or remote), and return the -InterfaceDef associated with that object, if it is found in the repository. The test -in orbsvcs/tests/InterfaceRepo/Application_Test has been modified to use _get_interface().</li><p> - -<li> The executable tao_ifr now handles -ORB options and multiple IDL files in -the command line. The option<br><br> - -<b> --ORBInitRef InterfaceRepository=file://[filename]<br><br> -</b> - -can now be used instead of relying on IP multicast to resolve the IFR service.</li><p> - -<li> The executable tao_ifr now works with the <a href="../INS.html">Interoperable -Naming Service</a>.<br><br> - -<b> -IFR_Service -ORBEndpoint iiop://[hostname]:[port] <br><br> - -tao_ifr -ORBInitRef InterfaceRepository=corbaloc:iiop:[hostname]:[port]/InterfaceRepository [idl file] <br><br> -</b> - -</li> - -<li> A command line option -Si has been added to tao_ifr which suppresses processing of included IDL files. The default is to process them. </li><p> - -<li> tao_ifr can now process multiple IDL files per execution portably on all supported platforms. File names and command line options may occur in any order on the command line.</li><p> - -<li> Underlying mechanism of access to the IFR has been changed from servant - locator (where a servant is created and destroyed for each access - invocation) to default servant (where persistent servants and their - associated POAs are created at IFR startup and destroyed at shutdown). - </li><p> - -<li> IFR now supports valuetypes, components, homes and eventtypes. A test - for this support has been added in TAO/orbsvcs/tests/InterfaceRepo/IDL3_Test. - </li><p> - -</ul> diff --git a/TAO/docs/interfacerepo/tao_ifr.html b/TAO/docs/interfacerepo/tao_ifr.html deleted file mode 100644 index b9a3ff740f2..00000000000 --- a/TAO/docs/interfacerepo/tao_ifr.html +++ /dev/null @@ -1,186 +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.5 [en] (X11; I; SunOS 5.5.1 sun4u) [Netscape]"> -<title>tao_ifr User's Guide</title> -<!-- $Id$ --> -</head> -<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#CC0000"> - -<hr> -<h3> -tao_ifr User's Guide</h3> - -<h3> Overview</h3> tao_ifr is TAO's interface repository loader. When executed, it will first resolve the interface repository, either by finding the interface repository's IOR in a file whose name is passed to it through the -ORBInitRef command line option, or by IP multicast (the default). Note - if the -ORBInitRef option is used, it should come first on the command line, since it will be consumed when the ORB is initialized. Then it will create entries in (or remove entries from) the repository corresponding to the declarations found in the IDL file(s) passed to it. If an entry to be removed is not found the repository, nothing happens. As stated elsewhere in the documentation, if an entry to be added is found to already exist in the repository (that is, if the interface repository id is found by lookup), the old entry will be replaced by the new one. It is the user's responsibility to make sure that no entries are unexpectedly replaced in the repository. This is also the method by which interfaces forward declared but not defined in one IDL file are fully defined in another. If the old and new entries are both interfaces, there is no way for tao_ifr to know if this is the intention, or if there is a genuine name clash. The behavior shown by tao_ifr in this case was chosen to conform to the behavior of the interface repository loaders from other ORB vendors. - -<P> - -<HR><P> - -<h3><A NAME="options">tao_ifr Command Line Options</A></h3> - -tao_ifr uses the front end of the TAO IDL compiler, which invokes your <tt>C</tt> (or <tt>C++</tt>) -preprocessor to resolve included IDL files. It receives the common -options for preprocessors (such as <tt>-D</tt> or <tt>-I</tt>). It -also receives other options that are specific to it<P> - -<table BORDER=2 CELLSPACING=2 CELLPADDING=0 > - <tr> - <th>Option</th> - <th>Description</th> - <th>Remark</th> - </tr> - <tr><a NAME="ORBInitRef"> - <td><tt>-ORBInitRef InterfaceRepository= - corbaloc:iiop:[hostname]:[port]/InterfaceRepository</tt></td> - - <td>Locate the Interface Repository using the <a href="../INS.html">Interoperable Naming Service</a></td> - <td>Without this option, the Interface Repository will be located by multicast.</td> - - </tr> - <tr> - <td><tt>-ORBInitRef InterfaceRepository=file://[filename]</tt></td> - <td>Locate the Interface Repository using the IOR from a file.</td> - - <td>Without this option, the Interface Repository will be located by multicast.</td> - </tr> - <tr><a NAME="u"> - <td><tt>-u</tt></td> - - <td>Prints the options given below and exits.</td> - <td>Outputs to stdout by default.</td> - </tr> - - <tr> <a NAME="v"> - <td><tt>-v</tt></td> - - <td>Traces tao_ifr processing stages.</td> - <td> </td> - </tr> - - <tr> <a NAME="V"> - <td><tt>-V</tt></td> - - <td>Prints version information and exits.</td> - <td> </td> - </tr> - - <tr><a name="E"> - <td><tt>-E</tt></td> - - <td>Invokes the preprocessor and exits.</td> - <td>Outputs to stdout by default.</td> - </tr> - - <tr><a name="d"> - <td><tt>-d</tt></td> - - <td>Outputs a dump of the AST.</td> - <td>Outputs to stdout by default.</td> - </tr> - - <tr><a name="D"> - <td><tt>-D</tt><i>macro_definition</i></td> - - <td><i>macro_definition</i> is passed to the preprocessor.</td> - <td> </td> - </tr> - - <tr><a name="U"> - <td><tt>-U</tt><i>macro_name</i></td> - - <td><i>macro_name</i> is passed to the preprocessor.</td> - <td>Undefines <i>macro_name</i>.</td> - </tr> - - <tr><a name="I"> - <td><tt>-I</tt><i>include_path</i></td> - - <td><i>include_path</i> is passed to the preprocessor.</td> - <td> </td> - </tr> - - <tr><a name="A"> - <td><tt>-A</tt><i>assertion</i></td> - - <td><i>assertion</i> is passed to the preprocessor.</td> - <td>Local implementation-specific escape.</td> - </tr> - - <tr><a name="Y"> - <td><tt>-Yp,<i>path</i></tt></td> - - <td>Specifies the path for the preprocessor.</td> - <td> </td> - </tr> - - <tr><a name="t"> - <td><tt>-t</tt> <i>directory_name</i></td> - - <td>Temporary directory to be used by the IDL compiler.</td> - <td> Default: - Resolve ACE_DEFAULT_TEMP_DIR_ENV. If it is not defined, - /tmp/ is used. - </td> - </tr> - - <tr><a name="Cw"> - <td><tt>-Cw</tt></td> - - <td>Output a warning if two identifiers in the same scope differ in - spelling only by case.</td> - - <td>Default is to output error message. This option has been added as a nicety - for dealing with legacy IDL files, written when the CORBA rules for name - resolution were not as stringent.</td> - </tr> - - <tr><a name="Ce"> - <td><tt>-Ce</tt></td> - - <td>Output an error if two indentifiers in the same scope differ in - spelling only by case.</td> - - <td>This will also happen by default.</td> - </tr> - - <tr><a name="w"> - <td><tt>-w</tt></td> - - <td>Suppress IDL compiler warning messages.</td> - - <td> </td> - </tr> - - <tr><a name="Si"> - <td><tt>-Si</tt></td> - - <td>Suppress processing of included IDL files.</td> - <td>Default is to process included IDL files.</td> - </tr> - - <tr><a name="L"> - <td><tt>-L</tt></td> - - <td>Enables locking at the IDL file level.</td> - <td>Guards against the same IDL file being processed concurrently by multiple - threads running tao_ifr.</td> - </tr> - - <tr><a name="r"> - <td><tt>-r</tt></td> - - <td>Remove contents of IDL file(s) from the repository.</td> - <td>Default is to add contents.</td> - </tr> - -</table> <P> - - <P><HR><P> -Back to the Interface Repository <A HREF="index.html">documentation</A>. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> - -</body> -</html> diff --git a/TAO/docs/ior_parsing.html b/TAO/docs/ior_parsing.html deleted file mode 100644 index 9f51a690fe0..00000000000 --- a/TAO/docs/ior_parsing.html +++ /dev/null @@ -1,226 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <!-- $Id$ --> - <title>Adding new IOR Parsers to TAO</title> - </head> - - <body text="#000000" link="#0000ff" vlink="#cc0000" bgcolor="#ffffff"> - - <CENTER> - <H1>Introduction</H2> - </CENTER> - - <h4>What is an IOR Parser?</h4> - - <P>TAO supports several IOR formats, including - <CODE>IOR:</CODE>, <CODE>corbaloc:</CODE>, - <CODE>corbaname:</CODE> and <CODE>file:</CODE>. - However, some applications may benefit from other formats, for - example, <CODE>http:</CODE> could allow applications to download - an object reference from a web server. - </P> - <P>Adding new IOR formats to the ORB is a simple task, the ORB - takes advantage ACE's - <A HREF="http://www.cs.wustl.edu/~schmidt/DSEJ-94.ps.gz"> - Service Configurator - </A> - to dynamically load new <EM>IOR Parsers</EM>. - The implementation of <CODE>string_to_object()</CODE> queries - each available IOR Parser to convert an string into an object - reference. - Application developers can implement their own parsers and - dynamically (or statically) add them to the ORB, without any - need to recompile TAO. - </P> - - <H4>Why aren't the IOR parsers in TAO enough?</H4> - - <P>TAO provides a basic set of IOR parsers, - but it would be detrimental to TAO's footprint to implement a - huge collection of IOR parsers into the ORB. - Moreover, the DOC group does not have the ability to create all - possible IOR parsers: many applications will use proprietary - databases to configure the ORB. - <P> - - <H4>Why should I use an IOR parser?</H4> - - <P>Using an IOR parser is more convenient than, say, - setting up the ad-hoc configuration code in - <CODE>main()</CODE>. - It also allows for easier integration with other TAO components, - such as the <CODE>-ORBInitRef</CODE> options. - </P> - - <HR> - - <CENTER> - <H1>Implementation</H2> - </CENTER> - - <H1>How do you Implement an IOR Parser?</H1> - - <P>Implementing an IOR parser is easy, - you must implement a class derived from - <CODE>TAO_IOR_Parser</CODE>. - As an example we will develop an HTTP IOR parser, - the class declaration will probably look like this: -<PRE> -class HTTP_Parser : public TAO_IOR_Parser -{ -public: - virtual int match_prefix (const char *ior_string) const; - virtual CORBA::Object_ptr parse_string (const char *ior, - CORBA::ORB_ptr orb, - CORBA::Environment &) - ACE_THROW_SPEC ((CORBA::SystemException)); -}; -</PRE> - For maximal portability this class uses the alternative mapping - for exception handling, if you are not familiar with the - alternative mapping you can safely ignore the - <CODE>CORBA::Environment</CODE> argument. - Please read the exception handling - <A HREF="exceptions.html"> - documentation - </A> - for more details. - </P> - - <UL> - <LI><B>match_prefix</B> This method must recognize all the IOR - prefixes that this parser supports. Normally this is a single - prefix, a typical implementation will look like this: -<PRE> -int -HTTP_Parser::match_prefix (const char *ior_string) const -{ - static char http_prefix[] = "http:"; - int cmp = ACE_OS::strncmp (ior_string, http_prefix, sizeof(http_prefix)); - return (cmp == 0); -} -</PRE> - </LI> - <LI><B>parse_string</B> This method implements the real string - parsing, you can safely assume that the string has been - validated by the <CODE>match_prefix()</CODE> method. - Typically, this method will obtain the IOR string, in our - example by downloading the document from the web server, - and then uses <CODE>string_to_object()</CODE> to return the - object reference: -<PRE> -CORBA::Object_ptr -HTTP_Parser::parse_string (const char *ior, - CORBA::ORB_ptr orb, - CORBA::Environment &ACE_TRY_ENV) - ACE_THROW_SPEC ((CORBA::SystemException)) -{ - // Parse IOR as if it was an http:-URL - ACE_URL_Addr *url_addr = - ACE_URL_Addr::create_addr (ior); - - ACE_HTTP_Addr *http_addr = - ACE_dynamic_cast(ACE_HTTP_Addr*,url_addr); - - // Connect to the remote host and download the web page, store the - // contents in: - char *document_contents = ...; - - return orb->string_to_object (document_contents, ACE_TRY_ENV); -} -</PRE> - </LI> - </UL> - - <H4>How do you add an IOR Parser to the ORB?</H4> - - <P>As we mentioned above, TAO uses the ACE Service Configurator - framework to find (dynamically or statically) the IOR parsers. - You may want to read the - <A HREF="../../docs/tutorials/022/page01.html"> - ACE tutorial - </A> - on this subject, but the process is mostly mechanic, and - described here. - </P> - <P>First you must declare, in the header file, a factory method - and a description of the service, - this is easily accomplished via the following ACE macros: -<PRE> -ACE_FACTORY_DECLARE (Export_Prefix, HTTP_Parser) -ACE_STATIC_SVC_DELCARE_EXPORT (Export_Prefix, HTTP_Parser) -</PRE> - If you are only going to use Unix-like compilers and linkers, - then you can simply use <CODE>TAO</CODE> in place of - <CODE>Export_Prefix</CODE>. - However, under Microsoft Windows variants, this string must be - the prefix of the DLL export/import macros used by your library. - If you are going to statically link your IOR Parser into the - application you will also need to add - <CODE>ACE_STATIC_SVC_REQUIRE</CODE>, as follows: -<PRE> -ACE_FACTORY_DECLARE (Export_Prefix, HTTP_Parser) -ACE_STATIC_SVC_DELCARE_EXPORT (Export_Prefix, HTTP_Parser) -ACE_STATIC_SVC_REQUIRE (HTTP_Parser) -</PRE> - </P> - - <P>Next you must implement the services defined above, using some - other group of helper macros, in your source file you should - add: -<PRE> -ACE_STATIC_SVC_DEFINE (HTTP_Parser, - ACE_TEXT ("HTTP_Parser"), - ACE_SVC_OBJ_T, - &ACE_SVC_NAME (HTTP_Parser), - ACE_Service_Type::DELETE_THIS | - ACE_Service_Type::DELETE_OBJ, - 0) -ACE_FACTORY_DEFINE (Export_Prefix, HTTP_Parser) -</PRE> - The second argument to <CODE>ACE_STATIC_SVC_DEFINE</CODE> is - the name of the service in ACE's Service Configurator. - It is customary, but not required, to use the name of the class. - </P> - - <P>Finally you can dynamically add your IOR parser to the ORB - using the <CODE>-ORBIORParser</CODE> option in the - Resource Factory - (see - <A HREF="Options.html"> - Options for TAO Components - </A> - for details about ORB and Resource Factory options), - for example: -<PRE> -# svc.conf file -static Resource_Factory "-ORBIORPaser HTTP_Parser" -</PRE> - would add our new parser to the ORB. - </P> -<PRE> - -</PRE> - </P> - - <H4>Are there any complete examples?</H4> - - <P>Yes, the IOR parsers in the ORB can serve as complete examples, - please check: - <CODE>FILE_Parser.h</CODE>, - <CODE>CORBALOC_Parser.h</CODE>, - <CODE>CORBANAME_Parser.h</CODE>, - or <CODE>DLL_Parser.h</CODE>. - Unfortunately there are no examples that show how to dynamically - add a new IOR parser into the ORB. - </P> - - <hr> - <address><a href="mailto:coryan@uci.edu">Carlos O'Ryan</a></address> -<!-- Created: Tue Feb 20 08:42:57 PST 2001 --> -<!-- hhmts start --> -Last modified: Tue Feb 20 16:32:13 PST 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/leader_follower.html b/TAO/docs/leader_follower.html deleted file mode 100644 index 01af5fff1eb..00000000000 --- a/TAO/docs/leader_follower.html +++ /dev/null @@ -1,60 +0,0 @@ -<html> - <!-- $Id$ --> - <head> - <title>Implementation of leader follower model for global resources</title> - </head> - - <BODY text = "#000000" - link="#0000ff" - vlink="#cc0000" - bgcolor="#ffffff"> - - <body> - <HR> - <h1>Leader follower model for global resources</h1> - <HR> - <h2>Context</h2> - Global resources in TAO mean one ORB and using the reactive strategy - one Reactor. TAO uses the ACE Select Reactor for this purpose. - One main problem with multithreading and only one Reactor is that - only one thread can wait in handle_events at a time. - Handle_events is called, when a thread expects input, meaning - it is blocking to wait for it. - - <h2>Idea</h2> - One solution to this problem is to use a leader-follower model, - which partitions the set of threads wanting to wait for input - into one leader and followers. Every thread is eligible to become - a leader. A thread wanting to wait while nobody else is waiting - becomes the leader. If the leader gets its input, which is in - this case its response, it will select a new leader out of the - set of followers. The followers wait on a condition variable they - own and register it with the ORB core. The ORB core is thereby - responsible for making this access thread-save by providing - a lock for the list of followers with some flags, like - leader_available. - - <h2>Implementation</h2> - The above mentioned condition variables are owned by the - connection handlers, because reponses are expected per connection, - not necessarily, thinking about other resource models, per thread. - <p> - The involved classes are TAO_ORB_Core, TAO_Client_Connection_Handler - and TAO_ORB. In the TAO_ORB_Core class the list of followers, a lock, - a leader reference counter and a leader thread ID were added. - The handle_input and send_request methods on the TAO_Client_Connection_Handler - contain 95% of the code used for implementing the leader-follower - model. Care has to be taken, that the connection handlers are - suspended and resumed, properly. A special concern is that - no deadlocking occurs. - - <HR> - For more details and questions, - <p> - - <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address> - <p> - <address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address> - </body> -</html> - diff --git a/TAO/docs/libraries.html b/TAO/docs/libraries.html deleted file mode 100644 index 7119f953b6a..00000000000 --- a/TAO/docs/libraries.html +++ /dev/null @@ -1,282 +0,0 @@ -<!-- $Id$ --> -<HTML> - -<HEAD> - <TITLE>TAO libraries.</TITLE> -</HEAD> - -<BODY text = "#000000" -link="#000fff" -vlink="#ff0f0f" -bgcolor="#ffffff"> - -<HR><P><H3 ALIGN=CENTER>Libraries in TAO</H3></P> - -<H3>Overview</H3> - -As part of the <a href="minimumTAO.html">subsetting effort</a> to -reduce footprint of applications using TAO, we have created different -libraries that house various CORBA features, such the POA and -DynamicAny. This design helps minimize application footprint, only -linking in features that are required. However, applications must -link in the libraries they need. It is possible to load most of these -libraries dynamically using the ACE Service Configurator framework, -though this will not work for statically linked executables. Linking -the necessary libraries with your application is therefore the most -straightforward way to get the features you need. - -<H3> List of Libraries </H3> - -Here we outline the list of libraries in TAO core with the list of <a -href="../../MPC/README"> MPC </a> projects that can be used by the -application to get all the required libraries linked into the -application. The library names in table below are the ones created on -UNIX based systems. Windows systems have a slightly different naming -convention, e.g., the PortableServer library is named as -PortableServerd.lib and PortableServerd.dll. But for the naming -conventions used on different platforms, the contents of the libraries -and the dependencies outlined below are the same. <P> - -<table width="75%" border=1> - <caption><b>List of CORE Libraries in TAO<P></B></caption> - <thead> - <tr valign=top > - <th>Name of the Library - <th>Feature - <th> MPC project to use - </tr> - </thead> - <tbody> - <tr align=left> - <th>libTAO.so</th> - <td> All the core features for a client and server side ORB. The - list includes support for IIOP, invocation framework, - wait strategies for transports, leader-follower framework, - thread pools and thread-per-connection framework, - portable interceptors, CORBA Any's, CORBA Policy framework, - CDR framework etc. </td> - <td>taoclient.mpb for simple clients or tao_lib_with_idl.mpb to - create an application library.</td> - </tr> - <tr align=left> - <th>libTAO_AnyTypeCode.so</th> - <td>Library with all the TypeCode and Any support. If you use - the anytypecode base project the IDL compiler flags -Sa and - -St are removed from the default idl flags. - <td>anytypecode.mpb</td> - </tr> - <tr align=left> - <th>libTAO_BiDirGIOP.so</th> - <td>Support for BiDirectional GIOP as outlined by the CORBA - spec. Please see $TAO_ROOT/tests/BiDirectional for a simple - test case of this feature. Applications need to <code> - #include "tao/BiDir_GIOP/BiDirGIOP.h" </code> within their - code to get this feature. </td> - <td>bidir_giop.mpb</td> - </tr> - <tr align=left> - <th>libTAO_CodecFactory.so</th> - <td>Support for CodecFactory as outlined by the CORBA - spec. Please see $TAO_ROOT/tests/Codec for a simple - test case of this feature. Applications need to <code> - #include "tao/CodecFactory/CodecFactory.h" </code> within their - code to get this feature. </td> - <td>codecfactory.mpb</td> - </tr> - <tr align=left> - <th>libTAO_Domain.so</th> - <td>Support for server side skeletons for the DomainManager - interface. </td> - <td>No base projects available</td> - </tr> - <tr align=left> - <th>libTAO_DynamicAny.so</th> - <td>Support for DynamicAny. Please see - $TAO_ROOT/tests/DynAny_Test for an example of how to access - and use this library. Applications have to <code> #include - "tao/DynamicAny/DynamicAny.h" </code> to get the right - symbols.</td> - <td>dynamicany.mpb</td> - </tr> - <tr align=left> - <th>libTAO_EndpointPolicy.so</th> - <td>Support for the TAO-specific Endpoint Policy. This is used - to set up constraints on endpoints placed in IORs. The endpoint - policy is applied to a POAManager via the POAManagerFactory and - affects all POAs associated with that mananger. Examples of use - are in $TAO_ROOT/tests/POA/EndpointPolicy. Applications have to - <code> #include "tao/EndpointPolicy/EndpointPolicy.h" </code> to - get the right symbols.</td> - <td>endpointpolicy.mpb</td> - </tr> - <tr align=left> - <th>libTAO_DynamicInterface.so</th> - <td>Support for DII and DSI invocations. Applications have to - <code> #include "tao/DynamicInterface/Dynamic_Adapter_Impl.h" - </code> to get the right symbols.</td> - <td>dynamicinterface.mpb</td> - </tr> - <tr align=left> - <th>libTAO_IFR_Client.so</th> - <td>Support for client/stub side interfaces for - InterfaceRepository applications. Applications have to <code> - #include "tao/IFR_Client/IFR_Client_Adapter_Impl.h" </code> to - get the right symbols.</td> - <td>ifr_client.mpb</td> - </tr> - <tr align=left> - <th>libTAO_ImR_Client.so</th> - <td>Support for applications that want to register itself to - the Implementation Repository. Applications have to <code> - #include "tao/ImR_Client/ImR_Client.h" </code> to - get the right symbols.</td> - <td>imr_client.mpb</td> - </tr> - <tr align=left> - <th>libTAO_IORInterceptor.so</th> - <td>Support for IORInterceptor. The portable server library - depends on the IORInterceptor library. Applications have to - <code> #include - "tao/IORInterceptor/IORInterceptor_Adapter_Factory_Impl.h" - </code> to get the right symbols.</td> - <td>iorinterceptor.mpb</td> - </tr> - <tr align=left> - <th>libTAO_IORManipulation.so</th> - <td>Support for IOR manipulation. The interfaces offered - provide operations to create and multi-profile IOR's and - other related utilities. Applications have to <code> #include - "tao/IORManipulation/IORManip_Loader.h" </code> to get the - right symbols.</td> - <td>iormanip.mpb</td> - </tr> - <tr align=left> - <th>libTAO_IORTable.so</th> - <td> Any TAO server can be configured as an corbaloc - agent. Such agents forward requests generated using a simple - ObjectKey in a corbaloc specification to the real location of - the object. In TAO we implement this feature by dynamically - (or statically) adding a new Object Adapter to the ORB, that - handles any sort of request. This feature is placed in this - library. Applications have to <code> #include - "tao/IORTable/IORTable.h" </code> to get the right - symbols.</td> - <td>iortable.mpb</td> - </tr> - <tr align=left> - <th>libTAO_Messaging.so</th> - <td>Support for AMI and CORBA policies such as - RoundtripTimeout and ConnectionTimeout are placed in this - library. Applications have to <code> #include - "tao/Messaging/Messaging.h" </code> to get the - rightsymbols.</td> - <td>messaging.mpb</td> - </tr> - <tr align=left> - <th>libTAO_ObjRefTemplate.so</th> - <td>Support for Object Reference Template - specification. The portable server library depends on this - library. </td> - <td>objreftemplate.mpb</td> - </tr> - <tr align=left> - <th>libTAO_PI.so</th> - <td>Support for Portalbe Interceptors. This library is automagically - loaded by - the ORB when the application uses the PolicyFactory or ORBInitializer - . Just linking this library should be sufficient to - get all the features that are required to write applications - using portable intercetpros. </td> - <td>pi.mpb</td> - </tr> - <tr align=left> - <th>libTAO_PortableServer.so</th> - <td>Support for POA. This library is automagically loaded by - the ORB when the application calls resolve_intial_references - ("RootPOA"); Just linking this library should be sufficient to - get all the features that are required to write powerful - servers. </td> - <td>taoserver.mpb</td> - </tr> - <tr align=left> - <th>libTAO_RTCORBA.so</th> - <td>Support for RTCORBA client side features. Applications are - required to <code> #include "tao/RTCORBA/RTCORBA.h" </code> to - get the required symbols for linking. Support in this library - is complaint with RTCORBA 1.0 spec.</td> - <td>rt_client.mpb</td> - </tr> - <tr align=left> - <th>libTAO_RTPortableServer.so</th> - <td>Support for RTCORBA server side features. Applications are - required to <code> #include - "tao/RTPortableServer/RTPortableServer.h" </code> to - get the required symbols for linking. Support in this library - is complaint with RTCORBA 1.0 spec.</td> - <td>rt_server.mpb</td> - </tr> - <tr align=left> - <th>libTAO_RTScheduling.so</th> - <td>Support for RTCORBA 2.0 features. Applications are - required to <code> #include - "tao/RTScheduling/RTScheulding.h" </code> to - get the required symbols for linking. Support in this library - is complaint with RTCORBA 2.0 spec.</td> - <td>rtscheduling.mpb</td> - </tr> - <tr align=left> - <th>libTAO_SmartProxies.so</th> - <td>Support for <a href - ="Smart_Proxies.html">Smartproxies</a>.</td> - <td>smart_proxies.mpb</td> - </tr> - <tr align=left> - <th>libTAO_Strategies.so</th> - <td>Support for advanced resource options for the ORB that have - been strategized into this library. Advanced resource - categories include new transport protocols, additional - reactors, connection purging strategies etc. Applications - should <code> #include "tao/Strategies/advanced_resources.h" - </code>.</td> - <td>strategies.mpb</td> - </tr> - <tr align=left> - <th>libTAO_TypeCodeFactory.so</th> - <td>Support for TypeCodeFactory interface.</td> - <td>typecodefactory.mpb</td> - </tr> - <tr align=left> - <th>libTAO_Utils.so</th> - <td>Helper methods for that are useful for writing portable, - exception safe application code.</td> - <td>utils.mpb</td> - </tr> - <tr align=left> - <th>libTAO_Valuetype.so</th> - <td>Support for object by value (OBV). Portable server and messaging depends on - this library </td> - <td>valuetype.mpb</td> - </tr> - <tr align=left> - <th>libTAO_CSD_Framework.so</th> - <td>Support framework for Custom Servant Dispatching (CSD) feature. The CSD_ThreadPool - depends on this library</td> - <td>csd_framework.mpb</td> - </tr> - <tr align=left> - <th>libTAO_CSD_ThreadPool.so</th> - <td>Support for ThreadPool Custom Servant Dispatching (CSD) Strategy. This library can - be loaded statically or dynamically. Applications are required to - <code> #include "tao/CSD_ThreadPool/CSD_ThreadPool.h" - </code> for static loading and provide service configuration file for dynamic loading. - </td> - <td>csd_threadpool.mpb</td> - </tr> -</tr> -</table> - -<hr> -<p>Back to the TAO <a href="index.html">TAO documentation page</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -</body> - -</HTML> diff --git a/TAO/docs/locate_request.html b/TAO/docs/locate_request.html deleted file mode 100644 index 5c04d652874..00000000000 --- a/TAO/docs/locate_request.html +++ /dev/null @@ -1,56 +0,0 @@ -<html> - <!-- $Id$ --> - <head> - <title>Implementation of locate requests</title> - </head> - - <BODY text = "#000000" - link="#0000ff" - vlink="#cc0000" - bgcolor="#ffffff"> - - <body> - <HR> - <h1>Locate requests</h1> - <HR> - <h2>Context</h2> - The CORBA specification describes locate requests as a way to - find out if an object is available at the other end of the wire - or not without invoking an actual method on it. - This way expensive marshalling and demarshalling can be prohibited. - Locate requests are part of GIOP. - - <h2>Implementation</h2> - The main classes involved in locate requests are the Server_Connection_Handler - to do check for the object. This is done by invoking the non standard - "non_existent" method on it. If it fails an exception will be thrown, - if the exception is not the Forward_Request exception of the POA, - the object is not there. If it is this specific exception, the new - forwarded location can be extracted and returned in the locate reply. - If the call on "non_existent" succeeds, we know the object is there and - return that. - - The client part of the locate request is handled int Locate_Request_Invocation. - The response is checked on the answer. If there, we go on and invoke the - actual method on the distant object. If not there, we fail and throw the proper - exception and if we get forwarded we replace our IIOP profile acordingly. - - <h2>API</h2> - To activate the locate requests, please invoke the non standard method - "_use_locate_requests (CORBA::B_TRUE)" on your CORBA::Object or any - object which inherits form this object. This will activate the locate - request on the first call to the object. The second time and on all - following calls "no" locate request will be used any more. To switch - it on again use "_use_locate_requests (CORBA::B_TRUE)" again. - You can also switch it of by "_use_locate_requests (CORBA::B_FALSE)". - - <HR> - For more details and questions, - <p> - <address><a href="mailto:irfan1@cs.wustl.edu">Irfan Pyarali</a></address> - <p> - <address><a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a></address> - <p> - </body> -</html> - diff --git a/TAO/docs/minimumTAO.html b/TAO/docs/minimumTAO.html deleted file mode 100644 index 7bed09a91ab..00000000000 --- a/TAO/docs/minimumTAO.html +++ /dev/null @@ -1,275 +0,0 @@ -<!-- $Id$ --> - -<html> - <head> - <title>Minimum TAO</title> - <link rev=made href="mailto:tao-users@cs.wustl.edu"> - </head> - -<body text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - -<hr> -<p> - -<strong>Minimum TAO</strong> -<p> - -In addition to our work on <A HREF="../../docs/ACE-subsets.html">ACE -subsetting</A>, we have also been reducing the footprint of TAO. We -are pursuing two complementary strategies to reduce TAO's footprint: - -<OL> - -<LI> <B><EM>Implicit subsetting</EM></B>, e.g., by reducing - dependencies in the TAO library so that programs need not link - unused TAO components. <P> - -<LI> <B><EM>Explicit subsetting</EM></B>, e.g., by supporting the <a -href="http://www.omg.org/cgi-bin/doc?orbos/98-08-04.pdf"><em>minimumCORBA -</em></a> specification to <a href = -"http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a>. The <em> -minimumCORBA </em> specification removes the following features from -the <a href -="http://www.omg.org/technology/documents/formal/">CORBA</a> -specification. <P> -<ul> -<li>Dynamic Skeleton Interface<br> -<li>Dynamic Invocation Interface<br> -<li>Dynamic Any<br> -<li>Interceptors<br> -<li>Interface Repository<br> -<li>Advanced POA features<br> -<li>CORBA/COM interworking<br> -</ul> -</OL> - -The implicit subsetting of TAO requires no explicit application -programmer intervention. In contrast, to minimize the footprint of -TAO explicitly, you must -<OL> -<LI> <a -href="../ACE-INSTALL.html">Configure</a> ACE to support only those -components that are required by TAO and <P> -<LI> <a href = -"../TAO/TAO-INSTALL.html">Configure</a> TAO to only support the -components specified by the <em>minimumCORBA</em> specification. -</OL> - -The following two tables show the footprint reduction achievable via -explicit subsetting. Note that the IDL Compiler column refers to the -code required to collaborate between the IDL compiler and the ORB, and -not to the code for the IDL compiler itself. - -<p><hr width=50% align=left> <p> - -Note: All measurement are for ACE 5.0 and TAO 1.0 using egcs-2.91.60 -on SunOS5.7<P> - -The <a -href="../ACE-INSTALL.html#flags">make -flags</a> options used were: <P> - -<code> debug=0 optimize=1 static_libs_only=1 DEFFLAGS=-DACE_USE_RCSID=0 </code> <P> - -These options translate into:<P> -<UL> -<LI> No debugging -<LI> Optimization is set to -O2 -<LI> Static ACE and TAO libraries -<LI> Use of RCS Ids is turned off -</UL> -<p> - -To build a TAO static library, if shared libraries are the default, -use <code>make static_libs_only=1</code> (make sure to do this for -ACE, as well). If you're using recent versions of GNU GCC, you can -use the <A HREF="../ACE-INSTALL.html#repo">-frepo</A> option, which -typically reduces the footprint by another 25 percent. <P> - -<HR> - -<h3><a name="Status">ACE+TAO Subsetting Work in Progress</a></h3> - -We've been tracking the footprint reduction of ACE+TAO periodically -since April, 2000. All the statistics are available <A -HREF="http://www.dre.vanderbilt.edu/Stats/footprint.shtml">online</A>. As the result of -this prior work, we've identified various areas for improvement that -we're now addressing. For example, the following are the remaining -areas for ACE subsetting: - - <ul> - <li><EM><B>Log_Msg decoupling</EM></B> -- We have a good start on this, but it needs work - to finish. It might be easiest to make an abstract - base class, then have ACE_Log_Msg derive from it. That way - we could remove the exposure of all the #includes in Log_Msg.cpp - to applications that don't need it. Another alternative would - be to disable compilation of Log_Msg.cpp when ACE_NLOGGING is - enabled.<p> - - <li><EM><B>Higher layer interdependencies</EM></B> -- We haven't - exhaustively tested all possible combinations of subsets. It's possible - that there are interdependencies between some layers that - we haven't yet identified and removed.<p> - - <li><EM><B>Remove reliance on multiple inheritance</EM></B> -- Multiple - inheriance is only used in a few - places in ACE. This - isn't really a subsetting problem, but is necessary to - fully take advantage of optimizations available on C++ compilers for - embedded systems.<p> - </ul> - -We anticipate that these changes should reduce the default size of ACE -by around 100-200 kbytes.<P> - -As the effort to reduce TAO's footprint continues, we are planning -several modifications for TAO that should reduce the footprint for -both the full CORBA and minimum CORBA configurations by around 300-400 -Kbytes. The list below contains an estimate of the impact of each one -of these changes, along with the estimated effort to implement them. -</P> - -<P> - <TABLE CELLPADDING=4 BORDER=4> - <TR> - <TD>Component</TD><TD>Impact</TD><TD>Effort</TD> - <TD>Description</TD> - </TR> - <TR> - <TD>ACE</TD><TD>14 Kb</TD><TD>4 weeks</TD> - <TD> - Implement a TAO-specific Reactor. - ACE's reactor supports a number of features that TAO does not - require. Thus, a TAO-specific implementation is an important way to - reduce the footprint. - </TD> - </TR> - <TR> - <TD>ACE</TD><TD>20 Kb</TD><TD>4 weeks</TD> - <TD> - Implement a TAO-specific Service Configurator. - TAO uses the ACE Service Configurator to dynamically configure - its strategies. In many embedded applications the set of - strategies are selected at design-time, on those platforms it - would be appropriate to disable all the features to - dynamically load components into the ORB. - </TD> - </TR> - <TR> - <TD>TAO</TD><TD>10-15 Kb</TD><TD>1-2 weeks</TD> - <TD> - Eliminate duplicate code due to instantiations of string -> - pointer maps. TAO uses several such maps, they could be replaced by a - generic version, wrapped with a fully inlined (i.e. zero - footprint) adapter for type-safety. - </TD> - </TR> - <TR> - <TD>TAO</TD><TD>3-10 Kb</TD><TD>1-2 weeks</TD> - <TD> - Make message buffering strategies optional. - TAO supports policy extensions to control the outgoing oneway and AMI - request buffers. Those policies are not used by all - applications. - </TD> - </TR> - <TR> - <TD>TAO</TD><TD>10 Kb</TD><TD>2 weeks</TD> - <TD> - Make support for multiple ORBs optional. - TAO can support multiple ORBs in the same process, but most - applications only require one. - </TD> - </TR> - <TR> - <TD>TAO</TD><TD>5 Kb</TD><TD>1 week</TD> - <TD> - Move the less common transport muxing and reply waiting - strategies to an optional library. - </TD> - </TR> - <TR> - <TD>ACE+TAO</TD><TD>30 Kb</TD><TD>8 weeks</TD> - <TD> - Decouple ACE (and then TAO) from the - <CODE>ACE_Thread_Manager</CODE> component. - This component is only used in the thread-per-connection - model, if we could decouple it in ACE then TAO could be - modified to only link this component when that concurrency - model is enabled. - </TD> - </TR> - <TR> - <TD>TAO</TD><TD>>50 Kb</TD><TD>6 weeks</TD> - <TD> - Move <CODE><<=</CODE> and <CODE>>>=</CODE> - operators to separate files. - Currently TAO includes nearly 500 such operators, moving them - to separate files (grouped by component?) would eliminate them - from most applications. - </TD> - </TR> - </TABLE> -</P> - -<P>In parallel with the activities described above we are pursuing -other avenues of research to find sources of rarely used or unused -code in ACE+TAO, and to modify the software to eliminate such code. -These activities include the following:</P> - -<UL> - <LI><P> - Using profiling tools, such as gprof, Quantify and True Coverage - to find unreachable code, or code only reachable in certain - applications. - </P></LI> - <LI><P> - The code TAO's IDL compiler generates for <CODE>CORBA::Any</CODE> - operators is large, so we are evaluating designs that reduce the impact of the <CODE>CORBA::Any</CODE> - type support. TAO's IDL compiler already makes that support optional. - However, for applications that require <CODE>Anys</CODE> it may be useful to separate that code - in another file to reduce the size of generated stubs and skeletons, - without losing the opportunity to use more dynamic CORBA invocation - modes. - </P></LI> - <LI><P> - The Notification Service currently depends on the Trading service to - implement the Trader Constraint Language. We are planning to break that - dependency and factor the TCL parser into a smaller library shared - by both services. - </P></LI> - <LI><P> - TAO still contains features that are rarely or never used. - Examples include the interfaces to query the well-known services and - to dynamically discover the level of security support. Those - components should only be linked (dynamically) in applications that require them. - </P></LI> - <LI><P> - The support for interceptors currently generated by the IDL compiler - can be partially refactored into common ORB code. - Moreover, we evaluating a new implementation of interceptors - that can be configured dynamically, thereby eliminating the need for - compile-time configuration flags. - </P></LI> - <LI><P> - We are planning to provide compile-time flags to eliminate certain mandatory features - in CORBA that are not used in all applications, such as IOR - parsers (corbaloc, corbaname, etc.). - </P></LI> - <LI><P> - Finally, we will perfom more code inspections to determine if template code can be - refactored into base classes and thereby shared by many objects in - the ACE+TAO implementations. - </P></LI> -</UL> - -Although we do not yet have sufficient insights to know how much -footprint reduction these activities will afford, we anticipate these -enhancements could reduce the default footprint of TAO by another -100-200 Kbytes. - -</body> -</html> diff --git a/TAO/docs/notification/reliability.html b/TAO/docs/notification/reliability.html deleted file mode 100644 index cc04b3c07c7..00000000000 --- a/TAO/docs/notification/reliability.html +++ /dev/null @@ -1,347 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> - <head> - <title>Using the Reliable Notification Service</title> - <meta content="False" name="vs_snapToGrid"> - <meta content="False" name="vs_showGrid"> - <!-- $Id$ --> - </head> - <body> - <h1>Using the Reliable Notification Service</h1> - <h2>Background</h2> - <p>There are two CORBA services defined by the OMG to support the - Supplier/Consumer design pattern. This pattern allows messages (known as - Events in this context) to be generated by one or more suppliers and delivered - to one or more consumers without requiring that the suppliers and consumers - have any knowledge of each other. </p> - <P>The Event Service provides a basic implementation of this pattern, and the - Notification service extends this basic service to support a rich variety of - optional features.</P> - <h2>Reliability and Persistence</h2> - <p>One of the optional features of the Notification service is Reliability. - By default the Event Service and the Notification service provide a <EM>best-effort</EM> - support for event delivery. If things go wrong -- program crashes, - communications failures, etc. events may be lost without notice.</p> - <P>There are some circumstances in which losing events is not - acceptable. The Notification service may be used for these situations if - it is configured for reliable operation. Reliable operation is not - available in the Event Service. Reliable operation means information is - saved persistently (usually on a disk file) and used to recover from the - various failures that might otherwise lead to loss of data.</P> - <P>There are two separate, but related, issues that need to be addressed to - provide reliable event delivery: topology persistence an event - persistence.</P> - <P>To provide topology persistence, sometimes called connection persistence, the - Notification service must keep track of what clients (Suppliers and Consumers) - have connected to the Notification service and what options have been specified - to contol the delivery of events.</P> - <P>To provide event persistence the Notification service tracks each event in - persistent storage to be sure it is delivered to every consumer that should - receive it. - </P> - <P>There may be situations in which topology persistence is all that is necessary - -- it may be acceptable to lose events during a failure as long as - the system is restored to normal operation afterward. Event persistence - on the other hand can only be supported if topology persistence is also being - used. It doesn't help to keep track of events if the system is unable to - find the consumers to which the events should be delivered.</P> - <P>Two separate issues must be addressed as part of setting up the Notifcation - for reliable operation. At the system administration level the - Notification service must be configured for topology persistence and - possibly for event persistence. At the application level, programs - that operate as consumers and suppliers must set the appropriate parameters to - enable reliable operation, and must cooperate with the reconnection process - that occurs during topology recovery.</P> - <h2>Configuring Notification Service Reliability.</h2> - <h3>Service Configurator Changes</h3> - <P>Runtime configuration of the Notification Service is supported through the - service configurator file. This file is normally named svc.conf; however the - -ORBSvcConf command line option allows an alternate service configuration file - to be specified. - </P> - <P> - Service configuration changes to support Notification Service reliability - include a new option on the existing <code>Notify_Default_Event_Manager_Objects_Factory</code> - service configuration command, and two new service configuration commands. - </P> - <H4>Notify_Default_Event_Manager_Objects_Factory option: -AllowReconnect</H4> - <p>Certain recovery cases require that a Consumer be able to reconnect to an - existing proxy object in the Notification Service in order to receive all - events delivered by that proxy object. This behavior is a departure from the - OMG Specification which mandates that the Notification Service should throw an - "Already Connected" exception when a consumer attempts to connect to a proxy - that was previously used by another Consumer. - </p> - <p>A new option, -AllowReconnect, is available for the existing <code>Notify_Default_Event_Manager_Objects_Factory - </code>command to support this requirement. As an example of its use, the - following line configures the Notification Service for multi-threaded operation - supporting reconnection.</p> - <code>static Notify_Default_Event_Manager_Objects_Factory "-DispatchingThreads 2 - -SourceThreads 2 -AllowReconnect" </code> - <H3>Configuring Connection (Topologogy) Reliability</H3> - <p>The support for persistent topology is actually a configurable strategy. - TAO includes an XML Topology Persistence Strategy that uses an XML file for - persistent storage, but it it is designed to allow other strategies to be - developed. For example if topology information should be stored in a - relational database file, it is possible to develop a persistent topology - strategy to do so. The details of doing this are beyond the scope of this - document. - </p> - <P>This document describes how to configure the XML topology persistence included - with TAO.</P> - <P>An example of the service configuration command to configure the XML - strategy is: - </P> - <p><code>dynamic Topology_Factory Service_Object* - TAO_CosNotification_Persist:_make_XML_Topology_Factory() "-base_path ./reconnect_test" </code> - </p> - <p>The first part of this line: <code>dynamic Topology_Factory Service_Object* - TAO_CosNotification_Persist:_make_XML_Topology_Factory()</code>should be given - exactly as shown. For details on this syntax, see chapter 17 of the TAO - Developer's Guide. - </p> - <P>The quoted string at the end of the line contain arguments for the configured - strategy. The arguments recognized by the XML topology strategy implemented in - this project are: - </P> - <ul> - <li> - -v - <li> - -base_path <EM>file_path</EM> - <li> - -backup_count <EM>count</EM> - <li> - -save_base_path <EM>file_path</EM> - <li> - -load_base_path <EM>file_path</EM> - <li> - <H4>-no_timestamp - </H4> - </li> - </ul> - <H4>Topology_Factory Option: -v</H4> - To help diagnose and/or document svc.conf settings, the "-v" will cause the - options for the Topology_Factory to be displayed as they are interpreted - <H4>Topology_Factory Option: -base_path file_path - </H4> - <P>The argument for this option is a fully qualified path name without an - extension for the xml file in which topology information is saved. Three - extensions will be appended to this name: .new, .xml, and .000 - </P> - <P>Saved topology information will be written to <EM>file_path</EM>.new file. - Information with a .new extension is not necessarily complete and will not be - used to restore the topology. - </P> - <P>When the .new file is complete, the previous <EM>file_path</EM>.000 (if any) - will be deleted, the previous <EM>file_path</EM>.xml (if any) will be renamed - as <EM>file_path</EM>.000 and the <EM>file_path</EM>.new file will be renamed - as file_path.xml. The assumption is that a file system rename operation is - atomic. If this assumption holds than at any time the file <EM>file_path</EM>.xml - (if it exists) contains the most recent complete save. If <EM>file_path</EM>.xml - does not exist then <EM>file_path</EM>.000 contains the most recent complete - save. If neither of these files exist the saved topology information is not - available. - </P> - <H4>Topology_Factory Option: -backup_count count</H4> - <P>This option modifies the behavior described in the preceeding section to allow - additional backup copies of the topology file to be retained. The default - value, 1, means that only the <EM>file_path</EM>.000 file will be kept. If a - higher number is specified, then older versions will be kept. Rather than - deleting <EM>file_path</EM>.000, the system will rename it to be <EM>file_path.</EM>001. - Older versions will be named <EM>file_path</EM>.002, <EM>file_path</EM>.002 and - so on. - </P> - <P>Under normal circumstances only one backup file is required -- in fact these - additional backup files will not be used to restore the topoogy. However - setting this number to a larger value lets the system keep a brief history of - topology changes. Since the XML files are roughly human-readable this can be - used as a diagnostic tool for problems related to Notification Service - topology. - </P> - <H4>Topology_Factory Options: -save_base_path file_path and -load_base_path - file_path - </H4> - <P>These options are alternatives to the -base_path option. They allow the file - from which topology information is loaded at Notification Service startup time - to be different from the file to which this information is saved as the system - runs. - </P> - <P>This option is mostly used for developer testing, a system administrator may - find an interesting use for this option -- possibly involving script files that - rename the XML files during recovery from a Notification Service failure. - </P> - <H4>Topology_Factory Option: -no_timestamp</H4> - <P>The XML files include a timestamp to indicate when the information was saved. - The timestamp is for information only and is not needed for correct functioning - of the topology persistence. This option suppresses that timestamp. Doing so - makes it possible to compare XML files using a program like diff to see if the - files represent the same topology. - </P> - <P>This option is intended primarily for testing the persistent topology - implementation. - </P> - <h3>Configuring Event Reliability</h3> - <p>A service configuraton new object, "Event_Persistence", can be configured in - the service configuration file to enable and configure the Event Reliability. - An example of the line needed to configure the Event_Persistence object is: - </p> - <p><code>dynamic Event_Persistence Service_Object* - TAO_CosNotification_Persist:_make_Standard_Event_Persistence() "-v -file_path - ./event_persist.db" </code> - </p> - <p><CODE></CODE>If this line does not appear in svc.conf, then event reliability - will not be supported. QoS parameters for reliable event delivery will be - silently ignored when Event Reliability is not configured. Event reliability - also requires topology reliability, so if this line appears there must also be - a "Topology_Factory" line in the file. If not, the Notification Service will - fail to start up. - </p> - <P>The beginning of this line, up to and including the parentheses, should appear - exactly as shown. For details on this syntax, see chapter 17 of the TAO - Developer's Guide. The quoted string at the end of the line contains options - for Event_Persistence. - </P> - <h4>Event_Persistence Option: -v</h4> - <p>This option and any option that appears after this option will be written to - the log (normally the console) as it is processed. This is intended to help - diagnose and document the Event Persistence settings. The default is to - configure Event Persistence silently. - </p> - <h4>Event_Persistence Option: -file_path path - </h4> - <p>This option gives the completely qualified name for the file in which - persistent event information will be stored. The file should be configured on a - reliable device that supports synchronized writes (i.e. flushing the operating - system's write cache.) A device that is suitable for storing a reliable - database would be appropriate for storing this file. The file will be subject - to a relatively high number of small (single block) write requests, but very - few, if any, read requests. If the file does not exist, then a new file will be - created. If the file does exist, and if topology is successfully loaded, the - events from this file will be reloaded and redelivered automatically. This is a - required option. There is no default value. - </p> - <h4>Event_Persistence Option: -block_size n - </h4> - <p>This option gives the block size in bytes for the device on which the event - reliability file is stored. For both performance and reliability reasons it is - important that the value matches the physical characteristics of the device. - The default value is 512. - </p> - <h2>Application Programming Changes to Support Reliability</h2> - <p> - When it is configured as described above, the Notification service - supports reliable connectivity and/or event delivery. - Actually achieving such reliability, however, requires cooperation from the - Notification service clients (Suppliers and Consumers). - <P> - There are a number of failure possibilities and different recovery techniques - are needed to handle them. The simplest case is when a client - fails and is restarted. - <P> - The Notification service will have maintained the connection points (Supplier - and Consumer Admins, Proxy Consumers, Proxy Admins, etc.) As each of these - connections was established, an ID returned by the notification - service. An application that wishes to be reconnected after a failure - should save a persistent copy of these IDs. For example, it could write - the IDs to a file, then read them back from the file after restarting. - Using these ID's the application can reconnect to the existing connection - points in the Notification service. The reconnection to the Proxy objects - will only work if the Notification service has been configured with the - -AllowReconnection option described above, but otherwise this process is fairly - straightforward. - <P> - As soon as a supplier has reconnected, it can resume sending events. As - soon as a consumer has reconnected, persistent events (if any) and new events - will start to arrive. - <P> - Notice that the identity of a consumer or supplier is determined by these saved - IDs. This is true even if the restarted client is running on a completely - different machine from the original client. - <P> - The case of the Notification service itself failing then being restarted on the - same or a different machine is somewhat more complicated. The - Notification service wasn't designed to initiate a connection to a - client. It must wait for the client to reconnect before it can start - accepting or delivering events. The difficulty is in having the client - know when to initiatie the reconnection, and to where the Notification service - is running in case it was necessary to move it to a new machine due to the - failure - <H3>Reconnection Registry</H3> - <p>The reconnection registry provides an answer to the question of how the client - knows where and when to reconnect to the Notification service. This - TAO-specific interface is implemented by the EventChannelFactory in the - reliable Notification Service. Clients can narrow the EventChannelFactory - object reference to a Reconnection Registery interface, then register a - Reconnection Callback object that will be notified when the Notification - service has restarted and is ready for reconections. The - EventChannelFactory passes its own object reference to the Reconnection - Callback object to inform the client where the Notification service is now - running.</p> - <P>The interfaces involved are defined in the NotifyExt.idl file (in - $TAO_ROOT/orbsvcs/orbsvcs) and are shown here:</P> - <pre> - /** - * \brief An interface which gets registered with a ReconnectionRegistry. - * - * A supplier or consumer must implement this interface in order to - * allow the Notification Service to attempt to reconnect to it after - * a failure. The supplier or consumer must register its instance of - * this interface with the ReconnectionRegistry. - */ - interface ReconnectionCallback - { - /// Perform operations to reconnect to the Notification Service - /// after a failure. - void reconnect (in Object new_connection); - - /// Check to see if the ReconnectionCallback is alive - boolean is_alive (); - }; - - /** - * \brief An interface that handles registration of suppliers and consumers. - * - * This registry should be implemented by an EventChannelFactory and - * will call the appropriate reconnect methods for all ReconnectionCallback - * objects registered with it. - */ - interface ReconnectionRegistry - { - typedef unsigned long ReconnectionID; - ReconnectionID register_callback(in ReconnectionCallback reconection); - - void unregister_callback (in ReconnectionID id); - - /// Check to see if the ReconnectionRegistry is alive - boolean is_alive (); - }; - </pre> - <H3>Using Event Reliability</H3> - <P>Configuring the Notification service for reliable event delivery is necessary, - but not sufficient to enable reliable handling of events. The application - code in either the client or the server must configure the EventChannel through - which the events are delivered to operate in the reliable mode. This is - done by setting the QoSProperties named "ConnectionReliabilty" and - "EventReliability" to the value "persistent" -- either at the time the channel - is created or at a later time useing the set_qos method.</P> - <P>Once an channel has been configured for reliable operation, persistence can be - disabled on an event by event basis using QoSProperties of the event - itself. This could be none, for examlpe, to avoid the overhead of - persistently storing events for which reliability is not needed.</P> - <P>The supplier sends events to the EventChannel using a push() method. For - persistent events, this call will not return to the supplier until the - Notification service is prepared to guarantee event delivery. - </P> - <P>Application code in the Consumer should be written with the knowledge that - events are guaranteed to be delivered, but during recovery from a failure there - is a possiblity that an event may arrive more than once. This could - happen, for example if the event was in the process of being delivered at the - time the failure occurred and the failure prevents the Notfication service from - determining if the delivery completed successfully. To meet its - committment that every event will be delivered, the Notification service will - retry the delivery in this canse which may result in a duplicate event.</P> - <P>As long as this situation is understood at the time the application is - designed, it should be possible for the application to handle this situation.</P> - </body> -</html> diff --git a/TAO/docs/orbsvcs.html b/TAO/docs/orbsvcs.html deleted file mode 100644 index e79eb4f411e..00000000000 --- a/TAO/docs/orbsvcs.html +++ /dev/null @@ -1,235 +0,0 @@ -<html> - <!-- $Id$ --> - <head> - <title>TAO's CORBA Object Services Documentation</title> - </head> - - -<BODY text = "#000000" -link="#0000ff" -vlink="#cc0000"` -bgcolor="#ffffff"> - - <body> -<HR> - <h3>TAO's CORBA Object Services Directory Hierarchy</h3> - - <P>The file and directory organization for TAO services can be - confusing at first glance (and even on subsequent ones to be - honest), - so we felt like some rationale and explanation of the directory - hierarchy was needed.</P> - - <P>For general sanity all TAO services files are located under - <CODE>$TAO_ROOT/orbsvcs</CODE>.</P> - - <P>It is expected that clients use more - than one service at the same time - (in fact some of the services already do, for instance the - <B>Event Service</B> uses the <B>Naming Service</B> and the - <B>Scheduling Service</B>). - Every service is put together as a library. These libraries are - located in <CODE>$TAO_ROOT/orbsvcs/orbsvcs</CODE>. - Usually the include path is <CODE>$TAO_ROOT</CODE>, - so files are included like this:</P> - - <P><CODE> - #include "orbsvcs/CosNamingC.h" - </CODE></P> - - <P>To simplify the IDL generation the skeletons are also on the - library, this is not a problem for client programs and most - services need to link the library anyway (since they use other - services.) Further, the current support for collocation - requires that clients link the skeleton files anyway. - </P> - - <P>In the future we intend to use ACE Service Configurator to give - the users control over collocation of the services implementation. - As a first cut all the service implementations are included in the - orbsvcs library <CODE>$TAO_ROOT/orbsvcs/orbsvcs</CODE>. - Since there are serveral services and each one is implemented - using several files we have given a different directory to each - service. - This structure could also simplify a future split into several - libraries (if it proves necessary). - </P> - - <P>The complete list of directories is:</P> - - <P> - <TABLE BORDER="2" - CELLSPACING="2" - CELLPADDING= "0"> - <TR> - <TH>Service</TH> - <TH>Implementation Sub-directory</TH> - <TH>Maitainer/Point-of-Contact </TH> - </TR> - <TR> - <TD>A/V Streams Service</TD> - <TD><CODE>orbsvcs/orbsvcs/AV</CODE></TD> - <TD> Yamuna Krishnamurthy <yamuna at oomworks dot com> - </TR> - <TR> - <TD>Concurrency Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Concurrency</CODE></TD> - <TD> None </TD> - </TR> - <TR> - <TD>Event Service</TD> - <TD><CODE>orbsvcs/orbsvcs/CosEvent</CODE></TD> - <TD>Pradeep Gore <pradeep at oomworks dot com> - and OCI<taosupport at ociweb dot com> </TD> - </TR> - <TR> - <TD>Real-time Event Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Event</CODE></TD> - <TD> Johnny Willemsen <jwillemsen at remedy dot nl> </TD> - </TR> - <TR> - <TD>LifeCycle Service</TD> - <TD><CODE>orbsvcs/orbsvcs/LifeCycle</CODE></TD> - <TD>None </TD> - </TR> - <TR> - <TD>Load Balancing Service</TD> - <TD><CODE>orbsvcs/orbsvcs/LoadBalancing</CODE></TD> - <TD> Ossama Othman <ossama at dre dot vanderbilt dot edu> </TD> - </TR> - <TR> - <TD>Logging Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Log</CODE></TD> - <TD> D A Hanvey <d dot hanvey@qub dot ac dot uk> </TD> - </TR> - <TR> - <TD>Naming Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Naming</CODE></TD> - <TD> DOC group </TD> - </TR> - <TR> - <TD>Property Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Property</CODE></TD> - <TD> None</TD> - </TR> - <TR> - <TD>Scheduling Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Sched</CODE></TD> - <TD>Venkita Subromianian <vankita at cs dot wustl dot edu> - </TR> - <TR> - <TD>Security Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Security</CODE></TD> - <TD> Ossama Othman <ossama at dre dot vanderbilt dot edu> - </TR> - <TR> - <TD>SSLIOP Pluggable Protocol</TD> - <TD><CODE>orbsvcs/orbsvcs/SSLIOP</CODE></TD> - <TD> Ossama Othman <ossama at dre dot vanderbilt dot edu> - </TR> - <TR> - <TD>Trading Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Trader</CODE></TD> - <TD> None </TD> - </TR> - <TR> - <TD>Time Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Time</CODE></TD> - <TD>None </TD> - </TR> - <TR> - <TD>Notification Service</TD> - <TD><CODE>orbsvcs/orbsvcs/Notify</CODE></TD> - <TD> Pradeep Gore <pradeep at oomworks dot com> </TD> - </TR> - <TR> - <TD>FtRt Event Service</TD> - <TD><CODE>orbsvcs/orbsvcs/FtRtEvent</CODE></TD> - <TD> Huang-huang Min <hh1 at cs dot wustl dot edu></TD> - </TR> - <TR> - <TD>FaultTolerance</TD> - <TD><CODE>orbsvcs/orbsvcs/FaultTolerance</CODE></TD> - <TD> Bala Natarajan <bala at dre dot vanderbilt dot edu> </TD> - </TR> - <TR> - <TD>IFRService</TD> - <TD><CODE>orbsvcs/orbsvcs/IFRservice</CODE></TD> - <TD> Jeff parsons <parsons at dre dot vanderbilt dot edu> </TD> - </TR> - <TR> - <TD>PortableGroup</TD> - <TD><CODE>orbsvcs/orbsvcs/PortableGroup</CODE></TD> - <TD> Frank Hunleth <frank at hunleth dot com> </TD> - </TR> - <TR> - <TD>RTCoSScheduling</TD> - <TD><CODE>orbsvcs/orbsvcs/RTCOSScheduling</CODE></TD> - <TD> Kevin Bryan <bryank at cs dot uri dot edu></TD> - </TR> - </TABLE> - </P> - - <P>Note that in the current version of TAO we still have standalone - binaries for some of the services. However, some applications - may want to control what process implements a particular service. - Therefore, it has proved useful for - debugging purposes to keep the most used services - separated. Users are highly encouraged to write their own - executables if they want any changes in CORBA policies or would - like to set their own bits when running a service. The - executables that are packed with the TAO distribution should be - viewed as an executable with a basic subset of features. - The binaries in question are located in - <CODE>$TAO_ROOT/orbsvcs</CODE>, and the list includes: - </P> - - <UL> - <LI>Concurrency_Service</LI> - <LI>Dump_Schedule</LI> - <LI>LifeCycle_Service</LI> - <LI>LoadBalancer</LI> - <LI>CosEvent_Service</LI> - <LI>Event_Service</LI> - <LI>FTRT_Event_Service</LI> - <LI>FTRT_Event_Service</LI> - <LI>FT_ReplicationManager </LI> - <LI>FT_Service</LI> - <LI>Fault_Detector</LI> - <LI>Fault_Notifier</LI> - <LI>Naming_Service</LI> - <LI>Scheduling_Service</LI> - <LI>Trading_Service</LI> - <LI>Time_Service</LI> - <LI>ImplRepo_Service *(see below)*</LI> - <LI>Notify_Service</LI> - </UL> - - <P>In the future we plan to use a single binary and ACE Service - Configurator and keep a single binary.</P> - - <P>The Implementation Repository is a unique service in that it - starts server executables, and it doesn't make sense to collocate - it in another server. Because of this, only the IDL files are - located in <CODE>$TAO_ROOT/orbsvcs/orbsvcs</CODE>. The other - files are all located in - <CODE>$TAO_ROOT/orbsvcs/ImplRepo_Service</code>.</P> - - <P>Finally the tests and example programs are located in - <CODE>$TAO_ROOT/orbsvcs/tests</CODE>; - once more each may involve more than a single binary, - so each one is kept in its own directory; - the following list describes the contents of each one: - </P> - - <H2>SEE ALSO</H2> - - <P>You may want to check TAO - <A HREF="releasenotes/index.html">release notes</A> - for up to date information on status, changes, future work, etc.</P> - - <hr> - - <address><a href="mailto:bala at dre dot vanderbilt dot edu">Bala Natarajan</a></address> - </body> -</html> diff --git a/TAO/docs/performance.html b/TAO/docs/performance.html deleted file mode 100644 index 687b9ae0ce1..00000000000 --- a/TAO/docs/performance.html +++ /dev/null @@ -1,713 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> - <head> - <!-- $Id$ --> - <title>TAO Performance and Footprint Tuning</title> - <LINK href="tao.css" rel="stylesheet" type="text/css"> - </head> - - <body> - <hr><p> - <h3>TAO Compile-time and Run-time Performance and Footprint Tuning</h3> - - <a name="overview"></a> - <h3>Overview</h3> - - <p> -<!-- We talk of real-time here and throughout this document I dont --> -<!-- see where we have talked about lower latencies one of the --> -<!-- important aspects of RT systems. I understand the term --> -<!-- "throughput" is used for latencies. My understanding is that --> -<!-- improved latencies can give better throughtput, but better --> -<!-- throughput doesnt necessarily mean lower latencies. Please --> -<!-- correct me if I am wrong --> - TAO is increasingly being used to support high-performance - distributed real-time and embedded (DRE) applications. DRE - applications constitute an important class of distributed - systems where predictability and efficiency are essential for - success. This document describes how to configure <a href - ="index.html">TAO</a> to enhance its throughput, scalability, - <!-- Ossama, let me know if I am offtrack. Would it be better if --> - <!-- we mention this as "reduced latencies" instead of improved --> - <!-- latencies. I can make the change but thought would discuss --> - <!-- with you before jumping on to it. - Bala --> - <!-- Bala, aren't they the same? In any case Doug wrote --> - <!-- this. ;-) --> - <!-- Shouldnt be an issue though :-) --> - and latency for a variety of applications. We also explain - various ways to speedup the compilation of ACE+TAO and - applications that use ACE+TAO. </p> - - <p> - As with most applications, including compilers, enabling - optimizations can often introduce side-effects that may not be - desirable for all use-cases. TAO's default configuration - therefore emphasizes programming simplicity rather than top - speed or scalability. Our goal is to assure that CORBA - applications work correctly ``out-of-the-box,'' while also - enabling developers to further optimize their CORBA applications - to meet stringent performance requirements. </P> - - <p> - TAO's performance tuning philosophy reflects the fact that there - are trade-offs between speed, size, scalability, and programming - simplicity. For example, certain ORB configurations work well - for a large number of clients, whereas others work better for a - small number. Likewise, certain configurations minimize - internal ORB synchronization and memory allocation overhead by - making assumptions about how applications are designed. - </p> - - <p> - This document is organized as follows: - </p> - <ul> - <li> - <!-- Ossama, do we call it optimizing throughput? Shouldnt --> - <!-- we mention it as Improving throughput? Because the --> - <!-- suggestions that we give seems to show only that. --> - <!-- - Bala, by optimizing throughput aren't we improving it? I - prefer "optimizing" but if the general consensus is that - "improving" is better than I won't debate the issue. - --> - <!-- Neither am I :-). I dont know why the term Optimizing --> - <!-- looks odd to me. I think this way -- the user can --> - <!-- apply different optimization strategies that we have --> - <!-- offered through different ORB options. Using the --> - <!-- strategies that TAO offers the user, can optimize --> - <!-- applications to get better throughput or reduced --> - <!-- latencies, as the case may be. For the application --> - <!-- developer this could involve rewriting portions of his --> - <!-- code. He actually optimizes his application --> - <!-- constrained by the strategies that TAO offers. - - <!-- Honestly, I dont think its a matter worth loosing sleep --> - <!-- over. Why did I start that in the first place. Late --> - <!-- realisation :-)--> - - <a href="#throughput">Optimizing Run-time Throughput</a> - <ul> - <li> - <a href="#client_throughput">Optimizing Client Throughput</a> - </li> - <li> - <a href="#server_throughput">Optimizing Server Throughput</a> - </li> - </ul> - </li> - <li> - <a href="#scalability">Optimizing Run-time Scalability</a> - <ul> - <li> - <a href="#client_scalability">Optimizing Client Scalability</a> - </li> - <li> - <a href="#server_scalability">Optimizing Server Scalability</a> - </li> - </ul> - </li> - <li> - <a href="#compile">Reducing Compilation Time</a> - <ul> - <li> - <a href="#compile_optimization">Compilation Optimization</a> - </li> - <li> - <a href="#compile_inlinling">Compilation Inlining</a> - </li> - </ul> - </li> - <li> - <a href="#footprint">Reducing Memory Footprint</a> - <ul> - <li> - <a href="#compile_footprint">Compile-time Footprint</a> - </li> - <li> - <a href="#runtime_footprint">Run-time Footprint</a> - </li> - </ul> - </li> - </ul> - - <p><hr><p> - <a name="throughput"></a> - <h3>Optimizing Throughput</h3> - - <p> - In this context, ``throughput'' refers to the number of events - occurring per unit time, where ``events'' can refer to - ORB-mediated operation invocations, for example. This section - describes how to optimize client and server throughput. - </p> - - <p> - It is important to understand that enabling throughput - optimizations for the client may not affect the server - performance and vice versa. In particular, the client and - server ORBs may be designed by different ORB suppliers. - </p> - - <a name="client_throughput"></a> - <h4>Optimizing Client Throughput</h4> - - <p> - Client ORB throughput optimizations improve the rate at which - CORBA requests (operation invocations) are sent to the target - server. Depending on the application, various techniques can be - employed to improve the rate at which CORBA requests are sent - and/or the amount of work the client can perform as requests are - sent or replies received. These techniques consist of: - </p> - <ul> - <li> - <!-- Ossama, I have my jitters on putting this here for the --> - <!-- following reasons --> - <!-- 1. AMI doesnt have many optimizations built in. Most of --> - <!-- the configurations that we mention below wouldnt work --> - <!-- with AMI. Say for instance we dont have a RW handler --> - <!-- for AMI --> - - <!-- - Yes, I know that. No claim was made that the ORB - configurations mentioned below should be or could be used - with AMI. AMI was only given as an example of how to - potentially improve throughput using programmatical means, - as opposed to using static ORB configurations. - --> - - <!-- Agreed. With the little I know of users, they try to --> - <!-- mix and match. They tend to assume that programming --> - <!-- considerations can be mixed and matched with ORB --> - <!-- configurations. Hence my jitters. If we split things as --> - <!-- Dr.Schmidt suggests, I guess things could be better --> - - - <!-- 2.For long we have been interchanging the terms, --> - <!-- "Throughput" and "Latency". AMI is good for --> - <!-- "Throughput", you could keep the client thread busy by --> - <!-- making more invocations. I doubt whether that leads to --> - <!-- better latencies. I dont know. Further the ORB --> - - <!-- - No such claim was made, so what's the issue here? This - section is after all about improving throughput not - latency. :-) - --> - <!-- Aahn!! See we interchange the usage of Latency and --> - <!-- Throughput which doesnt sound like a good idea. The ORB --> - <!-- configuration options that we suggest are mainly for --> - <!-- getting low latencies. Throughput is an after effect of --> - <!-- it. --> - - <!-- configuration section talks about options that improve --> - <!-- latencies. IMHO, lower latencies can lead to improved --> - - <!-- If the options I wrote about improve latency and not - throughput that should certainly be corrected. --> - - <!-- I guess that is where we need to start working. The --> - <!-- strategies that we talk gives lower latencies and hence --> - <!-- better throughput. They have been --> - <!-- implemented/designed/thought about as options that will --> - <!-- give low latencies. Making that change should help a lot. --> - - <!-- throughput, but vice-versa may not apply. --> - <!-- Please correct me if I am wrong. I am willing to stand --> - <!-- corrected. --> - <b>Run-time features</b> offered by the ORB, such as - Asynchronous Method Invocations (AMI) - <!-- Ossama, are there other examples you can list here? --> - <!-- ADD BUFFERED ONEWAYS --> - </li> - <li> - <b>ORB configurations</b>, such as disabling synchronization - of various parts of the ORB in a single-threaded application - </li> - </ul> - - <p> - We explore these techniques below. - </p> - - <h4>Run-time Client Optimizations</h4> - - <p> - For two-way invocations, i.e., those that expect a reply - (including ``<CODE>void</CODE>'' replies), Asynchronous method - invocations (AMI) can be used to give the client the opportunity - to perform other work as a CORBA request is sent to the target, - handled by the target, and the reply is received. - </p> - - <h4>Client Optimizations via ORB Configuration</h4> - - <p> - A TAO client ORB can be optimized for various types of - applications: - </p> - - <ul> - <li> - <b>Single-Threaded</b> - <ul> - <li> - <p> - A single-threaded client application may not require - the internal thread synchronization performed by TAO. - It may therefore be useful to add the following line to your - <code>svc.conf</code> file: - </p> - - <blockquote> - <code>static <a href = "Options.html#DefaultClient">Client_Strategy_Factory</a> "<a href="Options.html#-ORBProfileLock">-ORBProfileLock</a> null"</code> - </blockquote> - - <p> - If such an entry already exists in your - <code>svc.conf</code> file, then just add - <code>-ORBProfileLock null</code> to the list options - between the quotes found after - <code>Client_Strategy_Factory</code>. - </p> - - <p> - Other options include disabling synchronization in the - components of TAO responsible for constructing and sending - requests to the target and for receiving replies. These - components are called ``connection handlers.'' To disable - synchronization in the client connection handlers, simply - add: - </p> - <!-- Ossama, if we are going to ask people to use ST, --> - <!-- they could as well use ST reactor too. TAO uses a --> - <!-- reactor for ST and it would be better to use ST --> - - <!-- Sure, but this particular section is about the - -ORBClientConnectionHandler section. We can certainly - mention that it is better to use the ST reactor. --> - - <!-- reactor instead of TP. BTW, shouldnt we interchange --> - - <!-- The TP reactor was never mentioned here, so what the - issue? --> - - <!-- things here for example tell about RW and then go --> - <!-- to ST handlers? --> - - <!-- Fine with me Bala. You know more about the this - option than I do. Go for it! :-) --> - - <!-- No problem. I will start changing this once you --> - <!-- make your next pass --> - <blockquote> - <code> - <a href="Options.html#-ORBClientConnectionHandler"> - -ORBClientConnectionHandler</a> ST - </code> - </blockquote> - - <p> - to the list of <code>Client_Strategy_Factory</code> - options. Other values for this option, such as - <code>RW</code>, are more appropriate for "pure" - synchronous clients. See the <code> - <a href="Options.html#-ORBClientConnectionHandler"> - -ORBClientConnectionHandler</a></code> option - documentation for details. - </p> - - </li> - </ul> - </li> - - <li> - <b>Low Client Scalability Requirements</b> - <ul> - <li> - <p> - Clients with lower scalability requirements can dedicate a - connection to one request at a time, which means that no - other requests or replies will be sent or received, - respectively, over that connection while a request is - pending. The connection is <i>exclusive</i> to a given - request, thus reducing contention on a connection. - However, that exclusivity - <!-- Ossama, I am not sure I understand that using --> - <!-- exclusive connections could lead to reduced --> - <!-- throughput. As a matter of fact we have a cache map --> - <!-- lookup on the client side for muxed and that would --> - <!-- increase the latencies a bit :-). Exclusive takes --> - <!-- more resources and that could leade reduced --> - <!-- scalability, right?--> - - <!-- Bala, isn't that what I said? Paraphrasing what I - said, if the client has low scalability - requirements then exclusive connections can be used - to improve throughput. Isn't that incorrect? --> - - comes at the cost of a smaller number of requests that - may be issued at a given point in time. - - <!-- May be I am confused :-). The above statement that --> - <!-- says "smaller number of requests" tries to convey --> - <!-- that we will have reduced throughput. What am I --> - <!-- missing here? --> - To enable this - behaviour, add the following option to the - <code>Client_Strategy_Factory</code> line of your - <code>svc.conf</code> file: - </p> - - <blockquote> - <code> - <a href="Options.html#-ORBTransportMuxStrategy"> - -ORBTransportMuxStrategy</a> EXCLUSIVE - </code> - </blockquote> - - </li> - </ul> - </li> - </ul> - - <a name="server_throughput"></a> - <h4>Optimizing Server Throughput</h4> - - <p> - Throughput on the server side can be improved by configuring TAO - to use a <i>thread-per-connection</i> concurrency model. With - this concurrency model, a single thread is assigned to service - each connection. That same thread is used to dispatch the - request to the appropriate servant, meaning that thread context - switching is kept to minimum. To enable this concurrency model - in TAO, add the following option to the - <code> - <a href="Options.html#DefaultServer">Server_Strategy_Factory</a> - </code> - entry in your <code>svc.conf</code> file: - </p> - - <blockquote> - <code> - <a href="Options.html#orb_concurrency"> - -ORBConcurrency</a> thread-per-connection - </code> - </blockquote> - - <p> - While the <i>thread-per-connection</i> concurrency model may - improve throughput, it generally does not scale well due to - limitations of the platform the application is running. In - particular, most operating systems cannot efficiently handle - more than <code>100</code> or <code>200</code> threads running - concurrently. Hence performance often degrades sharply as the - number of connections increases over those numbers. - </p> - - <p> - Other concurrency models are further discussed in the - <i><a href="#server_scalability">Optimizing Server - Scalability</a></i> section below. - </p> - - <p><hr><p> - - <a name="scalability"></a> - <h3>Optimizing Scalability</h3> - - <p> - In this context, ``scalability'' refers to how well an ORB - performs as the number of CORBA requests increases. For - example, a non-scalable configuration will perform poorly as the - number of pending CORBA requests on the client increases from - <code>10</code> to <code>1,000</code>, and similarly on the - server. ORB scalability is particularly important on the server - since it must often handle many requests from multiple clients. - </p> - - <a name="client_scalability"></a> - <h4>Optimizing Client Scalability</h4> - - <p> - In order to optimize TAO for scalability on the client side, - connection multiplexing must be enabled. Specifically, multiple - requests may be issued and pending over the same connection. - Sharing a connection in this manner reduces the amount of - resources required by the ORB, which in turn makes more - resources available to the application. To enable this behavior - use the following <code>Client_Strategy_Factory</code> option: - </p> - - <blockquote> - <code> - <a href="Options.html#-ORBTransportMuxStrategy"> - -ORBTransportMuxStrategy</a> MUXED - </code> - </blockquote> - - <p> - This is the default setting used by TAO. - </p> - - <a name="server_scalability"></a> - <h4>Optimizing Server Scalability</h4> - - <p> - Scalability on the server side depends greatly on the - <i>concurrency model</i> in use. TAO supports two concurrency - models: - </p> - - <ol> - <li>Reactive, and</li> - <li>Thread-per-connection</li> - </ol> - - <p> - The thread-per-connection concurrency model is described above - in the - <i><a href="#server_throughput">Optimizing Server - Throughput</a></i> - section. - </p> - - <p> - A <i>reactive</i> concurrency model employs the Reactor design - pattern to demultiplex incoming CORBA requests. The underlying - event demultiplexing mechanism is typically one of the - mechanisms provided by the operating system, such as the - <code>select(2)</code> system call. To enable this concurrency - model, add the following option to the - <code> - <a href="Options.html#DefaultServer">Server_Strategy_Factory</a> - </code> - entry in your <code>svc.conf</code> file: - </p> - - <blockquote> - <code> - <a href="Options.html#orb_concurrency"> - -ORBConcurrency</a> reactive - </code> - </blockquote> - - <p> - This is the default setting used by TAO. - </p> - - <p> - The reactive concurrency model provides improved scalability on - the server side due to the fact that less resources are used, - which in turn allows a very large number of requests to be - handled by the server side ORB. This concurrency model provides - much better scalability than the thread-per-connection model - described above. - </p> - - <p> - Further scalability tuning can be achieved by choosing a Reactor - appropriate for your application. For example, if your - application is single-threaded then a reactor optimized for - single-threaded use may be appropriate. To select a - single-threaded <code>select(2)</code> based reactor, add the - following option to the - <code> - <a href="Options.html#AdvancedResourceFactory">Advanced_Resource_Factory</a> - </code> - entry in your <code>svc.conf</code> file: - </p> - - <blockquote> - <code> - <a href="Options.html#-ORBReactorType"> - -ORBReactorType</a> select_st - </code> - </blockquote> - - <p> - If your application uses thread pools, then the thread pool - reactor may be a better choice. To use it, add the following - option instead: - </p> - - <blockquote> - <code> - <a href="Options.html#-ORBReactorType"> - -ORBReactorType</a> tp_reactor - </code> - </blockquote> - - <p> - This is TAO's default reactor. See the - <code> - <a href="Options.html#-ORBReactorType">-ORBReactorType</a> - </code> - documentation for other reactor choices. - </p> - - <p> - Note that may have to link the <code>TAO_Strategies</code> - library into your application in order to take advantage of the - <code> - <a href="Options.html#AdvancedResourceFactory">Advanced_Resource_Factory</a> - </code> - features, such as alternate reactor choices. - </p> - - <p> - A third concurrency model, <i>un</i>supported by TAO, is - <i>thread-per-request</i>. In this case, a single thread is - used to service each request as it arrives. This concurrency - model generally provides neither scalability nor speed, which is - the reason why it is often not used in practice. - </p> - - <p><hr><p> - <a name="compile"></a> - <h3>Reducing Compilation Time</h3> - - <a name="compile_optimization"></a> - <h4>Compilation Optimization</h4> - -When developing software that uses ACE+TAO you can reduce the time it -takes to compile your software by not enabling you compiler's optimizer -flags. These often take the form -O<n>.<P> - -Disabling optimization for your application will come at the cost of run -time performance, so you should normally only do this during -development, keeping your test and release build optimized. <P> - - <a name="compile_inlinling"></a> - <h4>Compilation Inlining</h4> - -When compiler optimization is disabled, it is frequently the case that -no inlining will be performed. In this case the ACE inlining will be -adding to your compile time without any appreciable benefit. You can -therefore decrease compile times further by build building your -application with the -DACE_NO_INLINE C++ flag. <P> - -In order for code built with -DACE_NO_INLINE to link, you will need to -be using a version of ACE+TAO built with the "inline=0" make flag. <P> - -To accommodate both inline and non-inline builds of your application -it will be necessary to build two copies of your ACE+TAO libraries, -one with inlining and one without. You can then use your ACE_ROOT and -TAO_ROOT variables to point at the appropriate installation.<P> - - <p><hr><p> - <a name="footprint"></a> - <h3>Reducing Memory Footprint</h3> - - <a name="compile_footprint"></a> - <h4>Compile-time Footprint</h4> - -It has also been observed recently that using -xO3 with -xspace on SUN -CC 5.x compiler gives a big footprint reduction of the order of 40%.</P> -<P>Also footprint can be saved by specifying the following in your -platform_macros.GNU file: </P> -<P> -<code> -<pre> -optimize=1 -debug=0 -CPPFLAGS += -DACE_USE_RCSID=0 -DACE_NLOGGING=1 -</pre> -</code> - -<P> -If portable interceptors aren't needed, code around line 729 in -<code>$TAO_ROOT/tao/orbconf.h</code> can be modified to hard-code -<code>TAO_HAS_INTERCEPTORS</code> as <code>0</code>, and all interceptor -code will be skipped by the preprocessor. - -<P> -<TABLE BORDER=2 CELLSPACING=2 CELLPADDING=2> -<caption><b>IDL compiler options to reduce compile-time footprint</b></caption> - <TH>Command-Line Option - <TH>Description and Usage - <TR> - <TD><code>-Sc</code> - <TD>Suppresses generation of the TIE classes (template classes used - to delegate request dispatching when IDL interface inheritance - would cause a 'ladder' of inheritance if the servant classe had - corresponding inheritance). This option can be used almost all the - time. - <tr> - <td><code>-Sa</code> - <td>Suppresses generation of Any insertion/extraction operators. If - the application IDL contains no Anys, and the application itself - doesn't use them, this can be a useful option. - <tr> - <td><code>-St</code> - <td>Suppresses type code generation. Since Anys depend on type codes, - this option will also suppress the generation of Any operators. Usage - requires the same conditions as for the suppression of Any operators, - plus no type codes in application IDL and no application usage of - generated type codes. - <tr> - <td><code>-GA</code> - <td>Generates type code and Any operator definitions into a separate - file with a 'A' suffix just before the <code>.cpp</code> extension. - This is a little more flexible and transparent than using <code>-Sa</code> or - <code>-St</code> if you are compiling to DLLs or shared objects, - since the code in this file won't get linked in unless it's used. - <tr> - <td><code>-Sp</code> - <td>Suppresses the generation of extra classes used for thru-POA - collocation optimization. If the application has no collocated - client/server pairs, or if the performance gain from collocation - optimization is not important, this option can be used. - <tr> - <td><code>-H dynamic_hash</code><br> - <code>-H binary_search</code><br> - <code>-H linear_search</code><br> - <td>Generates alternatives to the default code generated on - the skeleton side for operation dispatching (which uses perfect - hashing). These options each give a small amount of footprint - reducion, each amount slightly different, with a corresponding tradeoff - in speed of operation dispatch. -</TABLE> - - <a name="runtime_footprint"></a> - <h4>Run-time Footprint</h4> - -<!-- Doug, put information about how to reduce the size of the --> -<!-- connection blocks, etc. --> - -<table border="1" width="75%"> -<caption><b>Control size of internal data structures<br></b></caption> -<thead> - <tr valign="top"> - <th>Define</th> - <th>Default</th> - <th>Minimum</th> - <th>Maximum</th> - <th>Description</th> - </tr> -</thead><tbody> - <tr> - <td>TAO_DEFAULT_ORB_TABLE_SIZE</td> - <td>16</td> - <td>1</td> - <td>-</td> - <td>The size of the internal table that stores all ORB Cores.</td> - </tr> - </tr> - <tr><td></td> - </tr> -</tbody></table></p><p> - -More information on reducing the memory footprint of TAO is available -<A -HREF="http://www.ociweb.com/cnb/CORBANewsBrief-200212.html">here</A>. <P> - - <hr><P> - <address><a href="mailto:ossama@uci.edu">Ossama Othman</a></address> -<!-- Created: Mon Nov 26 13:22:00 PST 2001 --> -<!-- hhmts start --> -Last modified: Thu Jul 14 16:36:12 CDT 2005 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/pluggable_messaging.html b/TAO/docs/pluggable_messaging.html deleted file mode 100644 index dd3d37b184a..00000000000 --- a/TAO/docs/pluggable_messaging.html +++ /dev/null @@ -1,141 +0,0 @@ -<!DOCTYPE HTML SYSTEM -"http://www.w3.org/pub/WWW/MarkUp/Cougar/Cougar.dtd"> - <!-- $Id$--> - <head> - <title>Pluggable Messaging framework</title> - </head> - - <BODY text = "#000000" - link="#0000ff" - vlink="#cc0000" - bgcolor="#ffffff"> - - <body> - <HR> - <h1>Pluggable Messaging Framework</h1> - <HR> - <h2>Context</h2> - TAO uses GIOP message formats to exchange messages between - inter-operating ORBs. GIOP, essentially specifies formats of - messages exchanged between ORBs. It has only a few message - types but still provides full CORBA support. But, there has - been a trend to try out different message formats like <a - HREF= "http://www.w3.org/TR/WD-HTTP-NG-architecture/"> - HTTP-NG </a> for inter-ORB communication. This framework - tends to take a first step in the direction to support - different protocols. The framework,though not complete in - itself, has been used for implementing GIOP and - GIOPlite. The framework would be re-factored and reworked - depending on the use cases our users come across. - - <h2>Idea</h2> - We wanted to give a flexibility to the user to load the message - formatting protocol by selecting a protocol during the - bootstrapping process. So, we tried to leverage the work - that has already been done for the <a HREF = - "pluggable_protocols/index.html"> pluggable_protocols</a>. - - The fundamental idea that we followed was to isolate all of - the ORB code from the message formatting details. The - framework is constrained by the type of marshalling - scheme. The framework now completely relies on CDR - formatted streams. - - - <h2>Implementation of GIOP</h2> - - <P>The common interface that has been defined is the class - Pluggable_Messaging_Interface forms the core class for the - implementation of a concrete messaging protocol. We have - been able to implement the GIOP & GIOPlite succesfully using - this minimal interface. The different versions of GIOP have - been managed succesfully within this implementation.</P> - - <P>When the user loads protocols like IIOP he/she in turn is - loading the TCP/IP mapping of GIOP formatted message. The - same argument can be used for UIOP, SHMIOP too. So, using - this fundamental understanding, we load the GIOP protocol for - the user behind the scene. If an user wants to use GIOPlite - mapped on to TCP/IP he would load IIOP_Lite using the - svc.conf file. The format is given below </P> - - <P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P> - <P><code>static Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P> - - <P>At the moment the TAO Strategies library is used the - svc.conf file should contain: </P> - - <P><code>dynamic IIOP_Lite_Factory Service_Object * TAO:_make_TAO_IIOP_Lite_Protocol_Factory() ""</code></P> - <P><code>static Advanced_Resource_Factory "-ORBProtocolFactory IIOP_Lite_Factory". </code></P> - - <P>Please see the documentation of the pluggable protocol - framework for exact meaning of the above syntax. The same - applies to GIOPlite mapping on UIOP too.</P> - - <P>The class GIOP_Message_Base derives from the - Pluggable_Messaging_Interface. This class holds most of the - common code needed for the GIOP classes. GIOP places a - restriction on the client and server roles, in terms of - initiating and receiving messages. This concept has been - mapped on to the framework by two sets implementation - classes, namely GIOP_Message_Connectors and - GIOP_Message_Acceptors. </P> - - <P>The GIOP_Message_Connector and the derived classes - implements the different types of messages that can - originate from the client. In GIOP 1.2, with the - specification of Bi-Directional GIOP, this disticntion - between the client and server would decrease. But, this - would be applicable only for GIOP 1.2. The present - inheritance model, allows us to implement some of the roles - defined for the server in the 1.0 and 1.1 versions of GIOP, on - the client side. This needs to be done only for 1.2.</P> - - <P>The GIOP_Message_Acceptor class is a Context, which maintains - a reference to a strategy based on the incoming request.</P> - - <P>The GIOP specification specifies that if a server supports - GIOP-1.2, it should also offer support for GIOP-1.1 and - GIOP-1.0. This would mean that clients that can communicate - in any of the three protocols can connect to a server that - supports 1.2. The server should also reply based on the same - revision.</P> - - <P> The strategisation on the server side is based on the - different version numbers of GIOP. The reference that would - be maintained by the context, GIOP_Message_Acceptor, would - be based on the version number of the incoming request. The - reply is also sent using the same reference. This makes it - possible to send compatible replies to the client. </P> - - <h2>Limitations</h2> - <P> Uses only CDR formats. </P> - <P> Need more ise cases to make the interface more flexible - and better. </P> - - - <HR> - For more details and questions, - <p> - - <address><a href="mailto:bala@cs.wustl.edu">Balachandran - Natarajan</a></address> - <p> - <address><a href="mailto:fredk@cs.wustl.edu">Fred Kuhns</a></address> - </body> -</html> - -</title> -</head> - -<body> -<h1></h1> - - - -<hr> -<address></address> -<!-- hhmts start --> -Last modified: Thu Mar 16 11:23:03 CST 2000 -<!-- hhmts end --> -</body> </html> diff --git a/TAO/docs/pluggable_protocols/cross_ref_motif.png b/TAO/docs/pluggable_protocols/cross_ref_motif.png Binary files differdeleted file mode 100644 index 7dd2dddf5ac..00000000000 --- a/TAO/docs/pluggable_protocols/cross_ref_motif.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/img1.png b/TAO/docs/pluggable_protocols/img1.png Binary files differdeleted file mode 100644 index 5899eb18c0b..00000000000 --- a/TAO/docs/pluggable_protocols/img1.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/img2.png b/TAO/docs/pluggable_protocols/img2.png Binary files differdeleted file mode 100644 index 1ddb28513a5..00000000000 --- a/TAO/docs/pluggable_protocols/img2.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/img3.png b/TAO/docs/pluggable_protocols/img3.png Binary files differdeleted file mode 100644 index c80c7edf6a8..00000000000 --- a/TAO/docs/pluggable_protocols/img3.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/img4.png b/TAO/docs/pluggable_protocols/img4.png Binary files differdeleted file mode 100644 index 8eab370af23..00000000000 --- a/TAO/docs/pluggable_protocols/img4.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/img5.png b/TAO/docs/pluggable_protocols/img5.png Binary files differdeleted file mode 100644 index 8cf1e2ca8ab..00000000000 --- a/TAO/docs/pluggable_protocols/img5.png +++ /dev/null diff --git a/TAO/docs/pluggable_protocols/index.html b/TAO/docs/pluggable_protocols/index.html deleted file mode 100644 index 21fc5208a62..00000000000 --- a/TAO/docs/pluggable_protocols/index.html +++ /dev/null @@ -1,2997 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> - -<!-- $Id$ --> - -<HTML> -<HEAD> -<TITLE>Implementing Pluggable Protocols for TAO</TITLE> - -<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> -<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> - -<LINK REL="STYLESHEET" HREF="pluggable_protocols.css"> - -</HEAD> - -<BODY TEXT = "#000000" LINK="#000fff" VLINK="#ff0f0f" BGCOLOR="#ffffff"> - -<P> - -<H1 ALIGN="CENTER">Implementing Pluggable Protocols for TAO</H1> -<P ALIGN="CENTER"> -<STRONG> -<A HREF="http://www.cs.wustl.edu/~fredk/">Fred Kuhns</A>, -<A HREF="http://www.ece.uci.edu/~schmidt/">Douglas C. Schmidt</A>, -<A HREF="http://doc.ece.uci.edu/~coryan">Carlos O'Ryan</A>, -<A HREF="http://www.ece.uci.edu/~ossama/">Ossama Othman</A>, -and <A HREF="mailto:BTRASK@contactsystems.com">Bruce Trask</A> -</STRONG> -</P> - -<P ALIGN="CENTER"> -Center for Distributed Object Computing<BR> -Washington University at St.Louis -</P> - -<HR> - -<P> -<H3>Overview</H3><P> - -To be an effective platform for performance-sensitive real-time and -embedded applications, off-the-shelf CORBA middleware must preserve -the communication-layer quality of service (QoS) properties of -applications end-to-end. However, the standard CORBA GIOP/IIOP -interoperability protocols are not well suited for applications that -cannot tolerate the message footprint size, latency, and jitter -associated with general-purpose messaging and transport protocols. -Fortunately, the CORBA specification defines the notion of -"Environmentally-Specific Inter-ORB Protocols" (ESIOPs) that can be -used to integrate non-GIOP/IIOP protocols beneath an ORB. <P> - -To allow end-users and developers to take advantage of ESIOP -capabilities, it is useful for an ORB to support a <EM>pluggable -protocols framework</em> that allows custom messaging and transport -protocols to be configured flexibly and used transparently by -applications. This document explains how to develop pluggable -protocols using TAO's pluggable protocols framework. Here are some -links that describe TAO's pluggable protocols framework, though not -how to implement one: <BLOCKQUOTE> <A -HREF="../releasenotes/index.html#pp">../releasenotes/index.html#pp</A><BR> - -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/PfHSN.pdf">http://www.cs.wustl.edu/~schmidt/PDF/PfHSN.pdf</A><BR> -<A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf">http://www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf</A> -</BLOCKQUOTE> - -<P> -<HR> -<H3>Table of Contents</H3><P> -<UL> -<LI><A NAME="TOC_SECTION100" HREF="#SECTION100">Overview of Implementation of Pluggable Protocols for TAO</A> -<UL> -<LI><A NAME="TOC_SECTION110" HREF="#SECTION110">The Hard Way</A> -<LI><A NAME="TOC_SECTION120" HREF="#SECTION120">The Path of Least Resistance</A> -<UL> -<LI><A NAME="TOC_SECTION121" HREF="#SECTION121">Basic Requirements</A> -<LI><A NAME="TOC_SECTION122" HREF="#SECTION122">Basics of Implementing a Pluggable Protocol for TAO</A> -</UL> -</UL> -<LI><A NAME="TOC_SECTION200" HREF="#SECTION200">Pluggable Protocol Framework Components</A> -<UL> -<LI><A NAME="TOC_SECTION210" HREF="#SECTION210">The <TT>Acceptor</TT></A> -<UL> -<LI><A NAME="TOC_SECTION211" HREF="#SECTION211">Context</A> -<LI><A NAME="TOC_SECTION212" HREF="#SECTION212">Problem</A> -<LI><A NAME="TOC_SECTION213" HREF="#SECTION213">Solution</A> -<LI><A NAME="TOC_SECTION214" HREF="#SECTION214">Applying the solution to TAO</A> -<LI><A NAME="TOC_SECTION215" HREF="#SECTION215"><TT>Acceptor</TT> Implementation</A> -</UL> -<LI><A NAME="TOC_SECTION220" HREF="#SECTION220">The <TT>Connector</TT></A> -<UL> -<LI><A NAME="TOC_SECTION221" HREF="#SECTION221">Context</A> -<LI><A NAME="TOC_SECTION222" HREF="#SECTION222">Problem</A> -<LI><A NAME="TOC_SECTION223" HREF="#SECTION223">Solution</A> -<LI><A NAME="TOC_SECTION224" HREF="#SECTION224">Applying the solution in TAO</A> -<LI><A NAME="TOC_SECTION225" HREF="#SECTION225"><TT>Connector</TT> Implementation</A> -</UL> -<LI><A NAME="TOC_SECTION230" HREF="#SECTION230">The <TT>Profile</TT> Object</A> -<LI><A NAME="TOC_SECTION240" HREF="#SECTION240">The <TT>Protocol_Factory</TT> Object</A> -<LI><A NAME="TOC_SECTION250" HREF="#SECTION250">The <TT>Transport</TT> Object</A> -<UL> -<LI><A NAME="TOC_SECTION251" HREF="#SECTION251">Context</A> -<LI><A NAME="TOC_SECTION252" HREF="#SECTION252">Problem</A> -<LI><A NAME="TOC_SECTION253" HREF="#SECTION253">Solution</A> -<LI><A NAME="TOC_SECTION254" HREF="#SECTION254">Applying the solution in TAO</A> -<LI><A NAME="TOC_SECTION255" HREF="#SECTION255"><TT>Transport</TT> Implementation</A> -</UL> -<LI><A NAME="TOC_SECTION260" HREF="#SECTION260">The <TT>Connection_Handler</TT></A></LI> -<UL> -<LI><A NAME="TOC_SECTION261" HREF="#SECTION261"><TT>Connection_Handler</TT> Implementation</A></LI> -</UL> -</UL> -<LI><A NAME="TOC_SECTION300" HREF="#SECTION300">Notes From a ``Real World'' Pluggable Protocol Implementation</A> -<LI><A NAME="TOC_SECTION400" HREF="#SECTION400">Additional Implementation Information</A> -<UL> -<LI><A NAME="TOC_SECTION410" HREF="#SECTION410">Tags</A></LI> -</UL> -<LI><A NAME="TOC_SECTION500" HREF="#SECTION500">Using a Pluggable Protocol</A> -<LI><A NAME="TOC_SECTION600" HREF="#SECTION600">Bibliography</A> -</UL> -<!-- End of Table of Contents --> -<BR><HR> - - -<P> - -<H3><A NAME="SECTION100" HREF="#TOC_SECTION100"> -Overview of Implementation of Pluggable Protocols for TAO</A> -</H3> - -<P> -There are several basic implementation details that should be followed when -implementing pluggable protocols for -<A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A>. This -section describes them. - -<P> - -<H3><A NAME="SECTION110" HREF="#TOC_SECTION110"> -The Hard Way</A> -</H3> - -<P> -It is possible to implement a pluggable protocol for TAO without using -any <A HREF="http://www.cs.wustl.edu/~schmidt/ACE.html">ACE</A> -components, or using existing pluggable protocols as a reference, but that is -certainly more difficult than taking advantage of the code reuse offered by -using existing ACE and TAO models and implementations. - -<P> - -<H3><A NAME="SECTION120" HREF="#TOC_SECTION120"> -The Path of Least Resistance</A> -</H3> - -<P> -TAO takes advantage of the many useful encapsulations provided by ACE. These -include ACE's <TT>IPC_SAP</TT> classes, <TT>Event Handlers</TT> and the operation -dispatching features provided by the <TT>Reactor</TT>. However, in order to -use these encapsulations some requirements must be satisfied. - -<P> - -<H3><A NAME="SECTION121" HREF="#TOC_SECTION121"> -Basic Requirements</A> -</H3> - -<P> -To be able to successfully use the ACE components listed above, the underlying -protocol used in the pluggable protocol for TAO should support the following -features and characteristics: - -<P> - -<UL> -<LI>Access to a session/connection via some type of handle (e.g. a UNIX file descriptor -or a Win32 <TT>HANDLE</TT>).</LI> -<LI>The ability to multiplex I/O using the <TT>select</TT> system call, or on Win32 -platforms, the <TT>WaitForMultipleObjects</TT> call on the handles that refer -to the open sessions/connections. This ability is required in order to use the -<TT>ACE_Select_Reactor</TT> or the <TT>ACE_WFMO_Reactor</TT> concrete <TT>Reactor</TT> -implementations. - -<P> -Some underlying transports do not provide any such ability. However, it may -sometimes be possible to separate data delivery from notification. For example, -TAO's shared memory transport transports data through shared memory, but since -it is not possible to use <TT>select</TT> on shared memory another mechanism -must be used for notification. One way to do this is to use a local IPC connection -strictly for notification purposes. Whenever, data is sent through shared memory, -a byte of data could be written to the local IPC connection. That local IPC -connection would be used to notify the receiving process that data is available -for reading in shared memory. Since local IPC can be multiplexed using the <TT>select</TT> -system call, the <TT>ACE_Select_Reactor</TT> can be used to handle operation -dispatching for the shared memory pluggable protocol. - -<P> - </LI> -<LI>A pluggable protocol should sit on top of lower-level implementation. The underlying -protocol implementation should not rely on any resources/features that are at -a similar or higher layer of abstraction than the pluggable protocol. For example, -if the underlying protocol needs to use Win32 resources/features such as <TT>HANDLE</TT>s -to hidden windows or the use of a window message pump then the underlying pluggable -protocol may be difficult or pointless to implement as a pluggable protocol.</LI> -</UL> - -<P> - -<H3><A NAME="SECTION122" HREF="#TOC_SECTION122"> -Basics of Implementing a Pluggable Protocol for TAO</A> -</H3> - -<P> -One of the easiest ways to implement a pluggable protocol for TAO is to do the -following: - -<P> - -<OL> -<LI>Implement ACE <TT>IPC_SAP</TT> wrappers around the underlying protocol implementation. -For example, ACE wraps the <I>socket</I> API to create an <TT>ACE_INET_Addr</TT>, -<TT>ACE_SOCK_Acceptor</TT>, <TT>ACE_SOCK_Connector</TT> and <TT>ACE_SOCK_Stream</TT>. -<TT>IPC_SAP</TT> wrappers for other implementations, such as OSI transport -protocol layer 4, aka <I>TP4</I>, should be implemented similarly. A TP4 implementation -could have an <TT>ACE_TP4_Addr</TT>, <TT>ACE_TP4_Acceptor</TT>, <TT>ACE_TP4_Connector</TT> -and an <TT>ACE_TP4_Stream</TT>. Any new implementation should retain the interface -provided by the base <TT>IPC_SAP</TT> classes in ACE.</LI> <P> - -<LI>Once the above ACE <TT>IPC_SAP</TT> components have been implemented, creating -the necessary TAO pluggable protocol components should be fairly easy. In fact, -much of the code can be ``cut and pasted'' from existing TAO pluggable protocol -implementations. For example, TAO's UIOP pluggable protocol was, for the most -part, based entirely on the IIOP pluggable protocol code found in TAO's ``tao/IIOP_*'' -source files. The only things that had to be changed for UIOP were the protocol -prefix, address format and URL style IOR format. Each of these pluggable protocol -characteristics is documented later in this documentation.</LI> -</OL> - -<P> - -The next section goes into detail about TAO's pluggable protocol -framework components and their public interfaces. It is our goal that -no changes to ACE or TAO should be necessary to implement a pluggable -protocol. Naturally, as with all frameworks, it's only possible to -achieve this goal if (1) all possible use-cases are understood in -advance or (2) the framework is generalized when confronted with new -use-cases that weren't handled before. Therefore, we describe the -conditions that must currently hold in order to develop and integrate -a pluggable protocol for TAO. -<P> -<HR> -<P> -<H3><A NAME="SECTION200" HREF="#TOC_SECTION200"> -Pluggable Protocol Framework Components</A> -</H3> - -<P> -In order for a pluggable protocol to be usable by TAO <STRONG><EM>without</EM></STRONG> making any modifications -to TAO itself, it must be implemented to provide the functionality dictated -by TAO's pluggable protocols framework interface. This functionality is implemented -within several components, namely the <TT>Acceptor</TT>, <TT>Connector</TT>, -<TT>Connection Handler</TT>, <TT>Protocol Factory</TT>, <TT>Profile</TT> and -<TT>Transport</TT>. This section describes each of them. - -<P> - -<H3><A NAME="SECTION210" HREF="#TOC_SECTION210"> -The <TT>Acceptor</TT></A> -</H3> - -<P> - -<A NAME="design:accept"></A> -<P> - -<H3><A NAME="SECTION211" HREF="#TOC_SECTION211"> -Context</A> -</H3> - -<P> -A server can accept connections at one or more endpoints, potentially using -the same protocol for all endpoints. The set of protocols that an ORB uses to -play the client role need not match the set of protocols used for the server -role. Moreover, the ORB can even be a ``pure client,'' <I>i.e.</I>, a client -that only makes requests, in which case it can use several protocols to make -requests, but receive no requests from other clients. - -<P> - -<H3><A NAME="SECTION212" HREF="#TOC_SECTION212"> -Problem</A> -</H3> - -<P> -The server must generate an IOR that includes all possible inter-ORB and transport-protocol-specific -profiles for which the object can be accessed. As with the client, it should -be possible to add new protocols without changing the ORB. - -<P> - -<H3><A NAME="SECTION213" HREF="#TOC_SECTION213"> -Solution</A> -</H3> - -<P> -We use the Acceptor pattern [<A - HREF="#Schmidt:97c">1</A>] to accept the connections. As -with the Connector pattern, an Acceptor decouples the connection establishment -from the processing performed on that connection. However, in the Acceptor pattern, -the connection is accepted <I>passively</I>, rather than being initiated <I>actively</I>. - -<P> - -<H3><A NAME="SECTION214" HREF="#TOC_SECTION214"> -Applying the solution to TAO</A> -</H3> - -<P> -Figure <A HREF="#server">1</A> illustrates how TAO's pluggable protocols framework leverages -the design presented in Section <A HREF="#design:transparent"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" - SRC="cross_ref_motif.png"></A>. The concrete ACE -<TT>Service Handler</TT> created by the ACE <TT>Acceptor</TT> is responsible -for implementing the External Polymorphism pattern [<A HREF="#Schmidt:97e">2</A>] and encapsulating itself -behind the <TT>Transport</TT> interface defined in our pluggable protocols framework. - -<P> - -<P></P> -<DIV ALIGN="CENTER"><A NAME="server"></A><A NAME="683"></A> -<TABLE> -<CAPTION ALIGN="BOTTOM"><STRONG>Figure 1:</STRONG> -Server Pluggable Protocol Class Diagram</CAPTION> -<TR><TD><P> - -<P> - -<DIV ALIGN="CENTER"> -<!-- MATH - $\resizebox* {5in}{!}{\includegraphics{graphics/server.eps}}$ - --> -<IMG - WIDTH="561" HEIGHT="634" ALIGN="BOTTOM" BORDER="0" - SRC="img1.png" - ALT="Server"> </DIV> -<P> -<DIV ALIGN="CENTER"></DIV></TD></TR> -</TABLE> -</DIV><P></P> - -<P> -As discussed in Section <A HREF="#design:adapt"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" - SRC="cross_ref_motif.png"></A>, we use the Adapter pattern to leverage -the ACE implementation of the Acceptors. This pattern also permits a seamless -integration with the lower levels of the ORB. In the Acceptor pattern, the <TT>Acceptor</TT> -object is a factory that creates <TT>Service Handler</TT>s. <TT>Service -Handler</TT>s are responsible for performing I/O with their connected peers. In -TAO's pluggable protocol framework, the <TT>Transport</TT> objects are <TT>Service -Handlers</TT> implemented as abstract classes. This design shields the ORB from -variations in the <TT>Acceptor</TT>s, <TT>Connector</TT>s, and <TT>Service -Handler</TT>s for each particular protocol. - -<P> -When a connection is established, the concrete <TT>Acceptor</TT> creates the -appropriate <TT>Connection Handler</TT> and IOP objects. The <TT>Connection -Handler</TT> also creates a <TT>Transport</TT> object that functions as a bridge. -As with the <TT>Connector</TT>, the <TT>Acceptor</TT> also acts as a bridge -object, hiding the transport- and strategy-specific details of the acceptor. - -<P> - -<H3><A NAME="SECTION215" HREF="#TOC_SECTION215"> -<TT>Acceptor</TT> Implementation</A> -</H3> - -<P> -TAO's <TT>Acceptor</TT> interface, shown below, is declared in the file -<TT><<A HREF="../../tao/Transport_Acceptor.h">tao/Transport_Acceptor.h</A>></TT>. -All <TT>Acceptor</TT> implementations must inherit from the <TT>TAO_Acceptor</TT> -abstract base class. - -<P> - -<DL COMPACT> -<DT> -<DD>class TAO_Export TAO_Acceptor<BR> -{<BR> - // = TITLE<BR> - // Abstract Acceptor class used for pluggable protocols.<BR> - //<BR> - // = DESCRIPTION<BR> - // Base class for the Acceptor bridge calls.<BR> -public:<BR> - TAO_Acceptor (CORBA::ULong tag);<BR> - - -<BR> - - virtual ~TAO_Acceptor (void); - -<BR> - - // Destructor - -<BR> - - - -<BR> - - CORBA::ULong tag (void) const; - -<BR> - - // The tag, each concrete class will have a specific tag value. - -<BR> - - - -<BR> - - CORBA::Short priority (void) const; - -<BR> - - // The priority for this endpoint. - -<BR> - - - -<BR> - - virtual int open (TAO_ORB_Core *orb_core, - -<BR> - - int version_major, - -<BR> - - int version_minor, - -<BR> - - const char *address, - -<BR> - - const char *options = 0) = 0; - -<BR> - - // Method to initialize acceptor for address. - -<BR> - - - -<BR> - - virtual int open_default (TAO_ORB_Core *orb_core, - -<BR> - - const char *options = 0) = 0; - -<BR> - - // Open an acceptor on the default endpoint for this protocol - -<BR> - - - -<BR> - - virtual int close (void) = 0; - -<BR> - - // Closes the acceptor - -<BR> - - - -<BR> - - virtual int create_mprofile (const TAO_ObjectKey &object_key, - -<BR> - - TAO_MProfile &mprofile) = 0; - -<BR> - - // Create the corresponding profile for this endpoint. - -<BR> - - - -<BR> - - virtual int is_collocated (const TAO_Profile* profile) = 0; - -<BR> - - // Return 1 if the <profile> has the same endpoint as the acceptor. - -<BR> - - - -<BR> - - virtual CORBA::ULong endpoint_count (void) = 0; - -<BR> - - // Returns the number of endpoints this acceptor is listening on. This - -<BR> - - // is used for determining how many profiles will be generated - -<BR> - - // for this acceptor. - -<BR> - - - -<BR> -protected: - -<BR> - - CORBA::Short priority_; - -<BR> - - // The priority for this endpoint - -<BR> - - - -<BR> -private: - -<BR> - - CORBA::ULong tag_; - -<BR> - - // IOP protocol tag. - -<BR> - - - -<BR> - -}; - - </DD> -</DL> -A description of each of the methods that must be implemented follows: - -<P> - -<DL> -<DT><STRONG>The Constructor.</STRONG></DT> -<DD>Other than initializing members of a pluggable protocol <TT>Acceptor</TT> -implementation, nothing else is really done in the constructor. For example, -the <TT>TAO_IIOP_Acceptor</TT> constructor implementation is: -<P> - -<DL COMPACT> -<DT> -<DD>TAO_IIOP_Acceptor::TAO_IIOP_Acceptor (void)<BR> -<DD> : TAO_Acceptor (TAO_TAG_IIOP_PROFILE), - -<BR> - - version_ (TAO_DEF_GIOP_MAJOR, TAO_DEF_GIOP_MINOR), - -<BR> - - orb_core_ (0), - -<BR> - - base_acceptor_ (), - -<BR> - - creation_strategy_ (0), - -<BR> - - concurrency_strategy_ (0), - -<BR> - - accept_strategy_ (0) - -<BR> - -{ - -<BR> - -}</DD> -</DL> -<P> -Note that initializing the <TT>TAO_Acceptor</TT> base class with a -<I>tag</I> value is required. Additional information about tags is -available in the -<A HREF="#SECTION410">tags section</A> -of this document. In this case, -<TT>TAO_TAG_IIOP_PROFILE</TT> is defined to be the OMG assigned tag -for the CORBA IIOP protocol. Until a tag that uniquely -identifies the protocol is assigned, a tag value that isn't -used by any other protocol can be used in the meantime. -</DL> - -<P> -<DL> -<DT><STRONG><TT><A NAME="TAO_Acceptor::open">open</A></TT>.</STRONG></DT> -<DD>The <TT>open</TT> method initializes the acceptor, i.e. sets -the protocol version to use (if supported), parses any protocol-specific options -(if any) and creates the endpoint passed to it. -<P> -The address specified by using the <TT><A HREF="../Options.html#-ORBEndpoint">-ORBEndpoint</A></TT> ORB option is passed -directly to this method. If more than one address is specified within a given -<TT>-ORBEndpoint</TT> option then each address is passed one by one to this -method by the pluggable protocols framework. For example, the following <TT>-ORBEndpoint</TT> -command line option: - -<P> - -<DL COMPACT> -<DT> -<DD>-ORBEndpoint iiop://1.1@foo.xyz.com,1.0@bar.abc.com</DD> -</DL> -<P> -will cause the following <TT>open</TT> method invocations to occur: - -<P> - -<DL COMPACT> -<DT> -<DD>open (orb_core, 1, 1, "foo.xyz.com", 0)<BR> -open (orb_core, 1, 0, "bar.abc.com", 0)</DD> -</DL> -<P> -Extracting individual addresses from an <TT>-ORBEndpoint</TT> option is handled -by TAO's pluggable protocols framework. It is up to the pluggable protocol to -handle the address passed to this method. - -<P> - </DD> -<DT><STRONG><TT><A NAME="TAO_Acceptor::open_default">open_default</A></TT>.</STRONG></DT> -<DD>Each pluggable protocol should have the ability to -open a default endpoint. For example, it should be possible to make the pluggable -protocol open an endpoint without specifying an address, in which case an address -is chosen by the pluggable protocol. This method is invoked when <TT>-ORBEndpoint</TT> -options such as the following are used: - -<P> - -<DL COMPACT> -<DT> -<DD>-ORBEndpoint iiop://</DD> -</DL> -<P>In this case, an IIOP endpoint will be created on the local host. The port will -be chosen by the IIOP pluggable protocol. <TT>open_default</TT> will invoked -in the following manner: - -<P> - -<DL COMPACT> -<DT> -<DD><TT>open_default (orbcore, 0)</TT></DD> -</DL></DD> -<P> -<DT><STRONG><TT>close</TT>.</STRONG></DT> -<DD>The <TT>close</TT> method is self-explanatory. It simply shuts -down any open endpoints, and recovers resources as necessary. This method is -automatically invoked by the pluggable protocols framework when the ORB associated -with that endpoint is shut down.</DD> -<P> -<DT><STRONG><TT>create_mprofile</TT>.</STRONG></DT> -<DD>The <TT>create_mprofile</TT> method creates a protocol-specific -<TT>Profile</TT> object and gives ownership of that profile to the <TT>TAO_MProfile</TT> -object, basically a container that holds multiple profiles, passed to it. The -code for this method is typically ``boilerplate,'' i.e. it can be based almost -entirely on TAO's existing pluggable protocol implementations of <TT>create_profile</TT>. -Here is how it is implemented in TAO's IIOP acceptor: - -<P> - -<DL COMPACT> -<DT> -<DD>int<BR> -TAO_IIOP_Acceptor::create_mprofile (const TAO_ObjectKey &object_key, <BR> -TAO_MProfile &mprofile) -<BR> -{ -<BR> - // @@ we only make one for now -<BR> - int count = mprofile.profile_count (); -<BR> - if ((mprofile.size () - count) < 1 -<BR> - && mprofile.grow (count + 1) == -1) -<BR> - return -1; -<BR> - -<BR> - TAO_IIOP_Profile *pfile = 0; -<BR> - ACE_NEW_RETURN (pfile, -<BR> - TAO_IIOP_Profile (this->host_.c_str (), -<BR> - this->address_.get_port_number (), -<BR> - object_key, -<BR> - this->address_, -<BR> - this->version_, -<BR> - this->orb_core_), -<BR> - -1); -<BR> - -<BR> - if (mprofile.give_profile (pfile) == -1) -<BR> - { -<BR> - pfile->_decr_refcnt (); -<BR> - pfile = 0; -<BR> - return -1; -<BR> - } -<BR> - -<BR> - if (this->orb_core_->orb_params ()->std_profile_components () == 0) -<BR> - return 0; -<BR> - -<BR> - pfile->tagged_components ().set_orb_type (TAO_ORB_TYPE); -<BR> - -<BR> - CONV_FRAME::CodeSetComponentInfo code_set_info; -<BR> - code_set_info.ForCharData.native_code_set = -<BR> - TAO_DEFAULT_CHAR_CODESET_ID; -<BR> - code_set_info.ForWcharData.native_code_set = -<BR> - TAO_DEFAULT_WCHAR_CODESET_ID; -<BR> - pfile->tagged_components ().set_code_sets (code_set_info); -<BR> - -<BR> - pfile->tagged_components ().set_tao_priority (this->priority ()); -<BR> - -<BR> - return 0; - -<P> - -}</DD> -</DL> -<P> -Most of the code that is common to all pluggable protocols will be factored -out of this method in the near future. - -<P> - </DD> -<DT><STRONG><TT>is_collocated</TT>.</STRONG></DT> -<DD>The <TT>is_collocated</TT> method checks if the <TT>Profile</TT> -has the same endpoint as the <TT>Acceptor</TT>. Assuming ACE is used as the -underlying layer between the operating system calls and a pluggable protocol, -this code is also ``boilerplate.'' TAO's IIOP implementation does the following: - -<P> - -<DL COMPACT> -<DT> -<DD>int -<BR> -TAO_IIOP_Acceptor::is_collocated (const TAO_Profile *pfile) -<BR> -{ -<BR> - const TAO_IIOP_Profile *profile = -<BR> - ACE_dynamic_cast(const TAO_IIOP_Profile *, -<BR> - pfile); -<BR> - -<BR> - // compare the port and sin_addr (numeric host address) -<BR> - return profile->object_addr () == this->address_; -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>endpoint_count</TT>.</STRONG></DT> -<DD><TT>endpoint_count</TT> returns the number of endpoints -the <TT>Acceptor</TT> is listening on. This is used for determining how many -<TT>Profiles</TT> will be generated for this <TT>Acceptor</TT>. Currently, all -of TAO's pluggable protocols simply return <TT>1</TT>.</DD> -</DL> - -<P> - -<H3><A NAME="SECTION220" HREF="#TOC_SECTION220"> -The <TT>Connector</TT></A> -</H3> - -<P> - -<A NAME="design:connect"></A> -<P> - -<H3><A NAME="SECTION221" HREF="#TOC_SECTION221"> -Context</A> -</H3> - -<P> -When a client references an object, the ORB must obtain the corresponding profile -list, which is derived from the IOR and a profile ordering policy, and transparently -establish a connection to the server. - -<P> - -<H3><A NAME="SECTION222" HREF="#TOC_SECTION222"> -Problem</A> -</H3> - -<P> -There can be one or more combinations of inter-ORB and transport protocols available -in an ORB. For a given profile, the ORB must verify the presence of the associated -IOP and transport protocol, if available. It must then locate the applicable -<TT>Connector</TT> and delegate it to establish the connection. - -<P> - -<H3><A NAME="SECTION223" HREF="#TOC_SECTION223"> -Solution</A> -</H3> - -<P> -We use the Connector pattern [<A - HREF="#Schmidt:97c">1</A>] to actively establish a connection -to a remote object. This pattern decouples the connection establishment from -the processing performed after the connection is successful. As before, the -<TT>Connector Registry</TT> shown in Figure <A HREF="#e2e">2</A> is used - -<P></P> -<DIV ALIGN="CENTER"><A NAME="e2e"></A><A NAME="184"></A> -<TABLE> -<CAPTION ALIGN="BOTTOM"><STRONG>Figure 2:</STRONG> -Connection Establishment Using Multiple Pluggable Protocols</CAPTION> -<TR><TD><P> - -<P> - -<P> - -<DIV ALIGN="CENTER"> -<!-- MATH - $\resizebox* {9cm}{!}{\includegraphics{graphics/pp_e2e.eps}}$ - --> -<IMG - WIDTH="405" HEIGHT="460" ALIGN="BOTTOM" BORDER="0" - SRC="img2.png" - ALT="pp_e2e"> </DIV> -<P> -<DIV ALIGN="CENTER"></DIV></TD></TR> -</TABLE> -</DIV><P></P> -to locate the right <TT>Connector</TT> for the current profile. The actual -profile selected for use will depend on the set of Policies active at the time -of connection establishment. However, once a profile is selected, the connector -registry matches the profile type, represented by a well known tag, with an -instance of a concrete <TT>Connector</TT>. - -<P> - -<H3><A NAME="SECTION224" HREF="#TOC_SECTION224"> -Applying the solution in TAO</A> -</H3> - -<P> -As described in Section <A HREF="#design:adapt"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" - SRC="cross_ref_motif.png"></A>, <TT>Connector</TT>s are adapters -for the ACE implementation of the Connector pattern. Thus, they are typically -lightweight objects that simply delegate to a corresponding ACE component. - -<P> -Figure <A HREF="#client">3</A> shows the base classes and their relations for IIOP. - -<P></P> -<DIV ALIGN="CENTER"><A NAME="client"></A><A NAME="688"></A> -<TABLE> -<CAPTION ALIGN="BOTTOM"><STRONG>Figure 3:</STRONG> -Client Pluggable Protocol Class Diagram</CAPTION> -<TR><TD><P> - -<P> - -<DIV ALIGN="CENTER"> -<!-- MATH - $\resizebox* {5in}{!}{\includegraphics{graphics/client.eps}}$ - --> -<IMG - WIDTH="563" HEIGHT="416" ALIGN="BOTTOM" BORDER="0" - SRC="img3.png" - ALT="Client"> </DIV> -<P> -<DIV ALIGN="CENTER"></DIV></TD></TR> -</TABLE> -</DIV><P></P> -This figure shows an explicit co-variance between the <TT>Profile</TT> and -the <TT>Connector</TT>s for each protocol. In general, a <TT>Connector</TT> -must downcast the <TT>Profile</TT> to its specific type. This downcast is safe -because profile creation is limited to the <TT>Connector</TT> and <TT>Acceptor</TT> -registries. In both cases, the profile is created with a matching tag. The tag -is used by the Connector Registry to choose the <TT>Connector</TT> that can -handle each profile. - -<P> -As shown in the same figure, the Connector Registry manipulates only the base -classes. Therefore, new protocols can be added without requiring any modification -to the existing pluggable protocols framework. When a connection is successfully -established, the <TT>Profile</TT> is passed a pointer to the particular IOP -object and to the <TT>Transport</TT> objects that were created. - -<P> - -<H3><A NAME="SECTION225" HREF="#TOC_SECTION225"> -<TT>Connector</TT> Implementation</A> -</H3> - -<P> -TAO's <TT>Connector</TT> interface, shown below, is declared in the file <TT>< -<A HREF="../../tao/Transport_Connector.h">tao/Transport_Connector.h</A>></TT>. -All <TT>Connector</TT> implementations must inherit from the <TT>TAO_Connector</TT> -abstract base class. - -<P> - -<DL COMPACT> -<DT> -<DD>class TAO_Export TAO_Connector -<BR> -{ -<BR> - // = TITLE -<BR> - // Generic Connector interface definitions. -<BR> - // -<BR> - // = DESCRIPTION -<BR> - // Base class for connector bridge object. -<BR> -public: -<BR> - -<BR> - TAO_Connector (CORBA::ULong tag); -<BR> - // default constructor. -<BR> - -<BR> - virtual ~TAO_Connector (void); -<BR> - // the destructor. -<BR> - -<BR> - CORBA::ULong tag (void) const; -<BR> - // The tag identifying the specific ORB transport layer protocol. -<BR> - // For example TAO_TAG_IIOP_PROFILE = 0. The tag is used in the -<BR> - // IOR to identify the type of profile included. IOR -> {{tag0, -<BR> - // profile0} {tag1, profole1} ...} GIOP.h defines typedef -<BR> - // CORBA::ULong TAO_IOP_Profile_ID; -<BR> - -<BR> - int make_mprofile (const char *ior, -<BR> - TAO_MProfile &mprofile, -<BR> - CORBA::Environment &ACE_TRY_ENV); -<BR> - // Parse a string containing a URL style IOR and return an -<BR> - // MProfile. -<BR> - -<BR> - virtual int open (TAO_ORB_Core *orb_core) = 0; -<BR> - // Initialize object and register with reactor. -<BR> - -<BR> - virtual int close (void) = 0; -<BR> - // Shutdown Connector bridge and concreate Connector. -<BR> - -<BR> - virtual int connect (TAO_Profile *profile, -<BR> - TAO_Transport *&, -<BR> - ACE_Time_Value *max_wait_time) = 0; -<BR> - // To support pluggable we need to abstract away the connect() -<BR> - // method so it can be called from the GIOP code independant of the -<BR> - // actual transport protocol in use. -<BR> - -<BR> - virtual int preconnect (const char *preconnections) = 0; -<BR> - // Initial set of connections to be established. -<BR> - -<BR> - virtual TAO_Profile *create_profile (TAO_InputCDR& cdr) = 0; -<BR> - // Create a profile for this protocol and initialize it based on the -<BR> - // encapsulation in <cdr> -<BR> - -<BR> - virtual int check_prefix (const char *endpoint) = 0; -<BR> - // Check that the prefix of the provided endpoint is valid for use -<BR> - // with a given pluggable protocol. -<BR> - -<BR> - virtual char object_key_delimiter (void) const = 0; -<BR> - // Return the object key delimiter to use or expect. -<BR> - -<BR> -#if defined (TAO_USES_ROBUST_CONNECTION_MGMT) -<BR> - virtual int purge_connections (void) = 0; -<BR> - // Purge "old" connections. -<BR> -#endif /* TAO_USES_ROBUST_CONNECTION_MGMT */ -<BR> - -<BR> -protected: -<BR> - virtual void make_profile (const char *endpoint, -<BR> - TAO_Profile *&, -<BR> - CORBA::Environment &ACE_TRY_ENV) = 0; -<BR> - // Create a profile with a given endpoint. -<BR> - -<BR> -private: -<BR> - CORBA::ULong tag_; -<BR> - // IOP protocol tag. -<BR> -};</DD> -</DL>A description of each of the methods that must be implemented follows: - -<P> - -<DL> -<DT><STRONG>The Constructor.</STRONG></DT> -<DD>As with the <TT>Acceptor</TT> constructor, the <TT>TAO_Connector</TT> -base class should be initialized with the tag associated with the pluggable -protocol in question. Here is TAO's IIOP pluggable protocol <TT>Connector</TT> -constructor: -<P> - -<DL COMPACT> -<DT> -<DD>TAO_IIOP_Connector::TAO_IIOP_Connector (void) -<BR> - : TAO_Connector (TAO_TAG_IIOP_PROFILE), -<BR> - orb_core_ (0), -<BR> - base_connector_ () -<BR> -{ -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>open</TT>.</STRONG></DT> -<DD>The <TT>open</TT> method simply opens the underlying connector. -This is typically an <TT>ACE_Strategy_Connector</TT> template instance. For -example, TAO's IIOP pluggable protocol uses an - -<P> - -<DL COMPACT> -<DT> -<DD>ACE_Strategy_Connector<TAO_IIOP_Client_Connection_Handler, -<BR> - ACE_SOCK_CONNECTOR></DD> -</DL>as its underlying connection strategy. No connection establishment occurs here. -Note that, if ACE is used to implement a <TT>Connector</TT>, this method should -also register the <TT>Connection Handler</TT> with an <TT>ACE_Reactor</TT>. - -<P> - </DD> -<DT><STRONG><TT>close</TT>.</STRONG></DT> -<DD><TT>close</TT> simply closes the underlying <TT>Connector</TT> -bridge and the concrete <TT>Connector</TT>.</DD> -<P> -<DT><STRONG><TT>connect</TT>.</STRONG></DT> -<DD>The <TT>connect</TT> method actively establishes a connection -to the endpoint encoded within the IOR in use. It should first verify that the -tag contained within <TT>Profile</TT> passed to it matches the tag associated -with the pluggable protocol. If the tags do not match then an attempt use a -<TT>Profile</TT> for another pluggable protocol was made. - -<P> -The <TT>Transport</TT> object must also be set in this method. This is generally -done by using the <TT>transport</TT> method found within the <TT>Connection -Handler</TT> being used. - -<P> - </DD> -<DT><STRONG><TT>preconnect</TT>.</STRONG></DT> -<DD>The <TT>preconnect</TT> method is invoked when the <TT><A HREF="../Options.html#-ORBPreconnect">-ORBPreconnect</A></TT> -ORB option is used. It causes a blocking connection to be made to the specified -address. Multiple connections can be made to the same endpoint. For example, -the following <TT>-ORBPreconnect</TT> option will cause two IIOP blocking connections -to be made to the specified host and port: - -<P> - -<DL COMPACT> -<DT> -<DD>-ORBPreconnect iiop://foo.bar.com:1234,foo.bar.com:1234</DD> -</DL> -<P> -Much of the preconnect parsing code in TAO's current <TT>preconnect</TT> implementations -will be factored out into a common method. Pluggable protocols will still be -responsible for parsing addresses, just like the <TT>open</TT> method in <TT>Acceptor</TT>s -(not <TT>Connector</TT>s). - -<P> - </DD> -<DT><STRONG><TT>check_prefix</TT>.</STRONG></DT> -<DD><TT>check_prefix</TT> checks that the protocol prefix -in a URL style IOR or preconnect endpoint is valid for use with a given pluggable -protocol. For example, the <TT>check_prefix</TT> implementation in TAO's IIOP -pluggable protocol looks like the following: - -<P> - -<DL COMPACT> -<DT> -<DD>int -<BR> -TAO_IIOP_Connector::check_prefix (const char *endpoint) -<BR> -{ -<BR> - // Check for a valid string -<BR> - if (!endpoint || !*endpoint) -<BR> - return -1; // Failure -<BR> - -<BR> - const char *protocol[] = { "iiop", "iioploc" }; -<BR> - -<BR> - size_t slot = ACE_OS::strchr (endpoint, ':') - endpoint; -<BR> - -<BR> - size_t len0 = ACE_OS::strlen (protocol[0]); -<BR> - size_t len1 = ACE_OS::strlen (protocol[1]); -<BR> - -<BR> - // Check for the proper prefix in the IOR. If the proper prefix -<BR> - // isn't in the IOR then it is not an IOR we can use. -<BR> - if (slot == len0 -<BR> - && ACE_OS::strncasecmp (endpoint, protocol[0], len0) == 0) -<BR> - return 0; -<BR> - else if (slot == len1 -<BR> - && ACE_OS::strncasecmp (endpoint, protocol[1], len1) == 0) -<BR> - return 0; -<BR> - -<BR> - return -1; -<BR> - // Failure: not an IIOP IOR -<BR> - // DO NOT throw an exception here. -<BR> -}</DD> -</DL> -<P> -It checks that the protocol prefix in a URL style IOR (e.g. <TT>corbaloc:iiop:foo.bar.com:1234/...</TT>) -or preconnect endpoint matches the one(s) supported by the IIOP pluggable protocol, -in this case ``<TT>iiop</TT>'' and ``<TT>iioploc</TT>.'' If no match occurs -then return an error condition (<TT>-1</TT>). Note that the protocol prefix -``<TT>iiop</TT>'' is only there for backward compatibility. It may be removed -in future TAO releases. - -<P> -This method is important for TAO's implementation of the CORBA Interoperable -Naming Service. - -<P> - </DD> -<DT><STRONG><TT>object_key_delimiter</TT>.</STRONG></DT> -<DD>The object key delimiter within a URL style -IOR is the character that separates the address from the object key. For example, -in the following IIOP URL style IOR: - -<P> - -<DL COMPACT> -<DT> -<DD>corbaloc:iiop:1.1@foo.bar.com:1234/some_object_key</DD> -</DL> -<P> -the object key delimiter is `<TT>/</TT>.' However, this character is not suitable -for all pluggable protocols, such as TAO's UIOP pluggable protocol, because -addresses within a URL style IOR may contain that very same character. A typical -TAO UIOP URL style IOR may look something like: - -<P> - -<DL COMPACT> -<DT> -<DD>uioploc:///tmp/foobar|some_other_object_key</DD> -</DL> -<P> -In this case, the object key delimiter is a vertical bar `<TT>|</TT>' because -using the same object key delimiter that IIOP uses `<TT>/</TT>' would cause -the point where the UIOP rendezvous point ``<TT>/tmp/foobar</TT>'' ends and -where the object key ``<TT>some_other_object_key</TT>'' begins to be ambiguous. -For instance, if an IIOP object key delimiter was used in a UIOP URL style IOR -as follows: - -<P> - -<DL COMPACT> -<DT> -<DD>uioploc:///tmp/foobar/some_other_object_key</DD> -</DL> -<P> -it then becomes impossible to tell if the rendezous point is ``<TT>/tmp</TT>'' -or ``<TT>/tmp/foobar</TT>,'' and similarly for the object key, hence the need -for an object key delimiter other than `<TT>/</TT>.' - -<P> -In general, this method simply returns a static variable in the associated <TT>Profile</TT> -that contains the object key delimiter appropriate for the given pluggable protocol. - -<P> - </DD> -<DT><STRONG><TT>create_profile</TT>.</STRONG></DT> -<DD>This method creates and initializes a profile using -the provided CDR stream. Most of this code is also ``boilerblate.'' As such, -it may be factored out in future TAO releases.</DD> -<P> -<DT><STRONG><TT>make_profile</TT>.</STRONG></DT> -<DD><TT>make_profile</TT> is another method that can essentially -be ``cut and pasted'' from existing TAO pluggable protocols. It is simply -a <TT>Profile</TT> factory. The <TT>Profile</TT> it creates is initialized with -an object reference of the form: - -<P> - -<DL COMPACT> -<DT> -<DD>N.n@address/object_key</DD> -</DL> -<P> -or -<P> -<DL COMPACT> -<DT> -<DD>address/object_key</DD> -</DL> -<P> -where ``<TT>N.n</TT>'' are the major and minor protocol versions, respectively, -and the `<TT>/</TT>' is the protocol-specific object key delimiter. - -<P></DD> -</DL> - -<P> - -<H3><A NAME="SECTION230" HREF="#TOC_SECTION230"> -The <TT>Profile</TT> Object</A> -</H3> - -<P> -TAO <TT>Profile</TT> objects encapsulate all of the methods and members necessary -to create and parse a protocol-specific IOR, in addition to representing object -address and location information. TAO <TT>Profile</TT>s are based on CORBA IOR -definitions. - -<P> -All protocol-specific <TT>Profile</TT> implementations should inherit from the -<TT>TAO_Profile</TT> abstract base class. The <TT>TAO_Profile</TT> interface -is declared in the file -<TT><<A HREF="../../tao/Profile.h">tao/Profile.h></A></TT>. -Its interface follows. Only the methods that must be implemented are shown: - - -<P> - -<DL COMPACT> -<DT> -<DD>class TAO_Export TAO_Profile -<BR> -{ -<BR> - // = TITLE -<BR> - // Defines the Profile interface -<BR> - // -<BR> - // = DESCRIPTION -<BR> - // An abstract base class for representing object address or location -<BR> - // information. This is based on the CORBA IOR definitions. -<BR> - // -<BR> -public: -<BR> - -<BR> - virtual int parse_string (const char *string, -<BR> - CORBA::Environment &ACE_TRY_ENV) = 0; -<BR> - // Initialize this object using the given input string. -<BR> - // Supports URL style of object references -<BR> - -<BR> - virtual char* to_string (CORBA::Environment &ACE_TRY_ENV) = 0; -<BR> - // Return a string representation for this profile. client must -<BR> - // deallocate memory. -<BR> - -<BR> - virtual int decode (TAO_InputCDR& cdr) = 0; -<BR> - // Initialize this object using the given CDR octet string. -<BR> - -<BR> - virtual int encode (TAO_OutputCDR &stream) const = 0; -<BR> - // Encode this profile in a stream, i.e. marshal it. -<BR> - -<BR> - virtual TAO_ObjectKey *_key (void) const = 0; -<BR> - // Obtain the object key, return 0 if the profile cannot be parsed. -<BR> - // The memory is owned by the caller! -<BR> - -<BR> - virtual CORBA::Boolean is_equivalent (const TAO_Profile* other_profile) = 0; -<BR> - // Return true if this profile is equivalent to other_profile. Two -<BR> - // profiles are equivalent iff their key, port, host, object_key and -<BR> - // version are the same. -<BR> - -<BR> - virtual CORBA::ULong hash (CORBA::ULong max, -<BR> - CORBA::Environment &ACE_TRY_ENV) = 0; -<BR> - // Return a hash value for this object. -<BR> - -<BR> - virtual int addr_to_string (char *buffer, size_t length) = 0; -<BR> - // Return a string representation for the address. Returns -<BR> - // -1 if buffer is too small. The purpose of this method is to -<BR> - // provide a general interface to the underlying address object's -<BR> - // addr_to_string method. This allowsthe protocol implementor to -<BR> - // select the appropriate string format. -<BR> - -<BR> - virtual void reset_hint (void) = 0; -<BR> - // This method is used with a connection has been reset requiring -<BR> - // the hint to be cleaned up and reset to NULL. -<BR> -};</DD> -</DL>TAO's existing pluggable protocols have a static member containing the object -key delimiter specific to the given pluggable protocol, in addition to a static -protocol prefix accessor method that simply returns a pointer to a static string -containing the protocol prefix specific to the pluggable protocol. Note that -both of these members will always remain constant so there is no problem in -making them static. - -<P> -Theses static member are: - -<P> - -<DL> -<DT><STRONG><TT>object_key_delimiter</TT>.</STRONG></DT> -<DD>This <I>variable</I> contains the object key -delimiter specific to the given pluggable protocol. A typical definition looks -like: -<P> - -<DL COMPACT> -<DT> -<DD>const char TAO_IIOP_Profile::object_key_delimiter = '/';</DD> -</DL></DD> -<DT><STRONG><TT>prefix</TT>.</STRONG></DT> -<DD>This <I>method</I> simply returns a pointer to a static string -that contains the protocol prefix specific to the pluggable protocol in use. -The static string for the IIOP pluggable protocol is: - -<P> - -<DL COMPACT> -<DT> -<DD>static const char prefix_[] = "iiop";</DD> -</DL> -<P> -The IIOP <TT>prefix</TT> method is: - -<P> - -<DL COMPACT> -<DT> -<DD>const char * -<BR> -TAO_IIOP_Profile::prefix (void) -<BR> -{ -<BR> - return ::prefix_; -<BR> -}</DD> -</DL></DD> -</DL> -Note that it not strictly necessary to implement equivalent versions of these -static members. TAO's implementation just happens to use them. However, pluggable -protocol implementations that are based on TAO's pluggable protocols may need -them. - -<P> -Common to all concrete <TT>Profile</TT> implementations are a set of methods -that must be implemented. A description of each of these methods: - -<P> - -<DL> -<DT><STRONG>The Constructors.</STRONG></DT> -<DD>TAO's existing pluggable protocols each implement several -constructors in their concrete <TT>Profile</TT> classes. While pluggable protocols -are not strictly required to implement analogs to all of the constructors in -existing TAO pluggable protocols, it is generally a good idea to do so. All -of the constructors should initialize the <TT>TAO_Profile</TT> abstract base -class with the tag associated with the pluggable protocol. The object key should -also be set during <TT>Profile</TT> construction.</DD> -<P> -<DT><STRONG><TT>parse_string</TT>.</STRONG></DT> -<DD><TT>parse_string</TT> initialize a <TT>Profile</TT> -object using the provided string. The string passed to this method has the format: -<P> - -<DL COMPACT> -<DT> -<DD>N.n@address/object_key</DD> -</DL> -<P> -or - -<P> - -<DL COMPACT> -<DT> -<DD>address/object_key</DD> -</DL> -<P>where the <TT>address</TT> and the object key delimiter `<TT>/</TT>' are pluggable -protocol specific. The <TT>parse_string</TT> method must be able to extract -the protocol version (even if it isn't used), the address and the object key -from the provided string. It is generally a good idea to use the <TT>parse_string</TT> -methods in TAO's existing pluggable protocols as a reference when implementing -this method. - -<P> - </DD> -<DT><STRONG><TT>to_string</TT>.</STRONG></DT> -<DD>This method returns the URL style representation of the -object reference encapsulated by the <TT>Profile</TT> object. Most of this code -is also ``boilerplate.'' However, the address part of the URL style IOR, returned -by this method should be specific to the pluggable protocol. For example, the -address in the following IIOP URL style IOR: - -<P> - -<DL COMPACT> -<DT> -<DD>corbaloc:iiop:1.1@foo.bar.com:1234/yet_another_object_key</DD> -</DL> -<P>is ``<TT>foo.bar.com:1234</TT>.'' Much of the in TAO's existing pluggable -protocols may also be factored out because that code is common to all pluggable -protocols. The URL style IOR created by this method should be usable -by TAO's <A HREF="../INS.html">Interoperable Naming Service</A> via the -<TT><A HREF="../Options.html#-ORBInitRef">-ORBInitRef</A></TT> ORB option. - -<P> - </DD> -<DT><STRONG><TT>decode</TT>.</STRONG></DT> -<DD>The input CDR stream reference passed to this method is used -to initialize the <TT>Profile</TT> object, by extracting (<I>decoding</I> all -object reference information found within the CDR stream. Care must be taken -to extract the information in the correct order. Use existing TAO pluggable -protocol <TT>decode</TT> implementations as a reference. - -<P> -The <TT>decode</TT> method performs the inverse operation of the <TT>encode</TT> -method. - -<P> - </DD> -<DT><STRONG><TT>encode</TT>.</STRONG></DT> -<DD>This method inserts (<I>encodes</I> all of the information -encapsulated by the <TT>Profile</TT> object in to the provided output CDR stream. -Care must be taken to insert the information in the correct order. Use existing -TAO pluggable protocol <TT>encode</TT> implementations as a reference. - -<P> -The <TT>encode</TT> method performs the inverse operation of the <TT>decode</TT> -method. - -<P> - </DD> -<DT><STRONG><TT>_key</TT>.</STRONG></DT> -<DD>The <TT>_key</TT> method constructs a <TT>TAO_ObjectKey</TT> -object that is a <I>copy</I> of the object key found within the <TT>Profile</TT> -object, and returns a pointer to the newly create <TT>TAO_ObjectKey</TT> object. -Note that the <I>caller</I> owns the memory allocated by this method. TAO's -IIOP <TT>_key</TT> implementation is: - -<P> - -<DL COMPACT> -<DT> -<DD>ACE_INLINE TAO_ObjectKey * -<BR> -TAO_IIOP_Profile::_key (void) const -<BR> -{ -<BR> - TAO_ObjectKey *key = 0; -<BR> - -<BR> - ACE_NEW_RETURN (key, -<BR> - TAO_ObjectKey (this->object_key_), -<BR> - 0); -<BR> - -<BR> - return key; -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>is_equivalent</TT>.</STRONG></DT> -<DD>The <TT>is_equivalent</TT> method implements the -CORBA specified method of the same name. It should return true if this profile -is equivalent to the profile to which it is being compared. Two profiles are -equivalent <I>if and only if</I> their tag, version, address and object key -are the same.</DD> -<P> -<DT><STRONG><TT>hash</TT>.</STRONG></DT> -<DD>The <TT>hash</TT> method implements the CORBA specified method -of the same name. It is expected to return 32 bit <TT>unsigned integer</TT> -(<TT>CORBA::ULong</TT>) that uniquely identifies the CORBA object referenced -by the <TT>Profile</TT> object. This method accepts an argument that specifies -the largest value the hash can be. - -<P> -Any algorithm deemed suitable to provide the required functionality may be used. -The <TT>ACE</TT> class in the ACE library provides implementations of several -hash algorithms. - -<P> - </DD> -<DT><STRONG><TT>addr_to_string</TT>.</STRONG></DT> -<DD><TT>addr_to_string</TT> returns a string representation -of the address. It should return <TT>-1</TT> if the supplied buffer is too small. -The stringified address should have the same form that the address in the URL -style IOR has. This method should be reentrant.</DD> -<P> -<DT><STRONG><TT>reset_hint</TT>.</STRONG></DT> -<DD>The <TT>reset_hint</TT> method resets the pointer to -a successfully used <TT>Connection Handler</TT>. If no pointer to such a <TT>Connection -Handler</TT>, i.e. a <I>hint</I> is provided by the pluggable protocol then this -method may be implemented as a ``no-op.'' A pluggable protcol that does not -provide a cached <TT>Connection Handler</TT> will not be able to take advantage -of improved <TT>Connector</TT> table look up times.</DD> -</DL> - -<P> - -<H3><A NAME="SECTION240" HREF="#TOC_SECTION240"> -The <TT>Protocol_Factory</TT> Object</A> -</H3> - -<P> -TAO's uses the ACE's Service Configurator implementation [<A - HREF="#Schmidt:94k">3</A>] -to dynamically load pluggable protocol factories. A <TT>Protocol_Factory</TT> -is responsible for creating the <TT>Acceptor</TT> and <TT>Connector</TT> for -the given pluggable protocol. TAO iterates through the list of loaded <TT>Protocol -Factories</TT> and invokes a factory operation that creates the desired object: -an <TT>Acceptor</TT> on the server-side, and a <TT>Connector</TT> on the client-side. - -<P> -All <TT>Protocol_Factory</TT> implementations should be derived from the <TT>TAO_Protocol_Factory</TT> -abstract base class defined in -<TT><<A HREF="../../tao/Protocol_Factory.h">tao/Protocol_Factory.h</A>></TT>. -The <TT>TAO_Protocol_Factory</TT> interface is shown below: - -<P> - -<DL COMPACT> -<DT> -<DD>class TAO_Export TAO_Protocol_Factory : public ACE_Service_Object -<BR> -{ -<BR> -public: -<BR> - TAO_Protocol_Factory (void); -<BR> - virtual ~TAO_Protocol_Factory (void); -<BR> - -<BR> - virtual int init (int argc, char *argv[]); -<BR> - // Initialization hook. -<BR> - -<BR> - virtual int match_prefix (const ACE_CString &prefix); -<BR> - // Verify prefix is a match -<BR> - -<BR> - virtual const char *prefix (void) const; -<BR> - // Returns the prefix used by the protocol. -<BR> - -<BR> - virtual char options_delimiter (void) const; -<BR> - // Return the character used to mark where an endpoint ends and -<BR> - // where its options begin. -<BR> - -<BR> - // Factory methods -<BR> - virtual TAO_Acceptor *make_acceptor (void); -<BR> - // Create an acceptor -<BR> - -<BR> - virtual TAO_Connector *make_connector (void); -<BR> - // Create a connector -<BR> - -<BR> - virtual int requires_explicit_endpoint (void) const = 0; -<BR> - // Some protocols should not create a default endpoint unless the -<BR> - // user specifies a -ORBEndpoint option. For example, local IPC -<BR> - // (aka UNIX domain sockets) is unable to remove the rendesvouz -<BR> - // point if the server crashes. For those protocols is better to -<BR> - // create the endpoint only if the user requests one. -<BR> -};</DD> -</DL>Each of the important methods to be implemented are described below: - -<P> - -<DL> -<DT><STRONG><TT>init</TT>.</STRONG></DT> -<DD>The <TT>init</TT> method is invoked immediately after the pluggable -protocol factory is loaded. The <TT>Service Configurator</TT> passes <TT>Protocol -Factory</TT> options specified in a <TT>Service Configurator</TT> configuration -file (e.g. <TT>svc.conf</TT>) to this method. The passing convention is essentially -the same as command line <TT>argc</TT>/<TT>argv</TT> argument passing convention. -The only difference lies in the fact that the option parsing should begin at -<TT>argv[0]</TT> instead of <TT>argv[1]</TT>. This differs from the -standard command line passing convention where <TT>argv[0]</TT> is the -name of the program currently being run. In any case, the <TT>init</TT> method -allows protocol-specific options to be implemented. Once passed to this method, -the pluggable protocol can use them to, for example, enable or disable certain -features or flags within the <TT>Protocol Factory</TT>. Other pluggable protocol -components can then use these flags or features as necessary. -<P> -A typical <TT>Service Configurator</TT> file line that loads a pluggable protocol -dynamically, and passes arguments to the <TT>init</TT> method would look like: - -<P> - -<DL COMPACT> -<DT> -<DD>dynamic IIOP_Factory Service_Object * TAO:_make_TAO_IIOP_Protocol_Factory() "-Foo Bar"</DD> -</DL> -<P> -In the above example, the arguments ``<TT>-Foo</TT>'' and ``<TT>Bar</TT>'' -would be passed as <TT>argv[0]</TT> and <TT>argv[1]</TT>, respectively, -to the <TT>Protocol_Factory init</TT> method. - -<P> - </DD> -<DT><STRONG><TT>match_prefix</TT>.</STRONG></DT> -<DD>This method verifies that protocol prefix contained -in the string passed to matches the one used by the pluggable protocol. A typical -implementation, such as the one used by the IIOP pluggable protocol, looks like: - -<P> - -<DL COMPACT> -<DT> -<DD>static const char prefix_[] = "iiop"; -<BR> - -<BR> -int -<BR> -TAO_IIOP_Protocol_Factory::match_prefix (const ACE_CString &prefix) -<BR> -{ -<BR> - // Check for the proper prefix for this protocol. -<BR> - return (ACE_OS::strcasecmp (prefix.c_str (), ::prefix_) == 0); -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>prefix</TT>.</STRONG></DT> -<DD>The <TT>prefix</TT> method simply returns a pointer to the -static string containing the protocol prefix used by the pluggable protocol.</DD> -<P> -<DT><STRONG><TT>options_delimiter</TT>.</STRONG></DT> -<DD>The <TT>options_delimiter</TT> method is similar -to the <TT>object_key_delimiter</TT> method found in the <TT>Connector</TT>. -However, it used to delimit where an endpoint ends and where its options begin. -For example, the following <TT>-ORBEndpoint</TT> option specifies a endpoint-specific -priority: - -<P> - -<DL COMPACT> -<DT> -<DD>-ORBEndpoint iiop://1.1@foo.bar.com/priority=25</DD> -</DL> -<P> -To get around ambiguities in endpoints that can have a `<TT>/</TT>' character -in them, the <TT>options_delimiter</TT> method can be used to determine what -character to be used. For example, TAO's UIOP pluggable protocol implementation -defines the following: - -<P> - -<DL COMPACT> -<DT> -<DD>char -<BR> -TAO_UIOP_Protocol_Factory::options_delimiter (void) const -<BR> -{ -<BR> - return '|'; -<BR> -}</DD> -</DL> -<P> -An endpoint option for the UIOP pluggable protocol can look like the following: - -<P> - -<DL COMPACT> -<DT> -<DD>-ORBEndpoint uiop://1.1@/tmp/foo|priority=25</DD> -</DL> -<P> -Notice that the `<TT>|</TT>' character is used to mark where the rendezvous -point ends and where the endpoint-specific options begin. - -<P> - -<TT>options_delimiter</TT> is a server-side related method. It is of no use -to the client-side. - -<P> - </DD> -<DT><STRONG><TT>make_acceptor</TT>.</STRONG></DT> -<DD>The <TT>make_acceptor</TT> method is a factory method -that returns a pointer to a dynamically allocated <TT>Acceptor</TT> specific -to the pluggable protocol to which the <TT>Protocol_Factory</TT> object belongs. -TAO's UIOP pluggable protocol implementation defines this method as follows: - -<P> - -<DL COMPACT> -<DT> -<DD>TAO_Acceptor * -<BR> -TAO_UIOP_Protocol_Factory::make_acceptor (void) -<BR> -{ -<BR> - TAO_Acceptor *acceptor = 0; -<BR> - -<BR> - ACE_NEW_RETURN (acceptor, -<BR> - TAO_UIOP_Acceptor, -<BR> - 0); -<BR> - -<BR> - return acceptor; -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>make_connector</TT>.</STRONG></DT> -<DD>The <TT>make_connector</TT> method is a factory -method that returns a pointer to a dynamically allocated <TT>Connector</TT> -specific to the pluggable protocol to which the <TT>Protocol_Factory</TT> object -belongs. TAO's UIOP pluggable protocol implementation defines this method as -follows: - -<P> - -<DL COMPACT> -<DT> -<DD>TAO_Connector * -<BR> -TAO_UIOP_Protocol_Factory::make_connector (void) -<BR> -{ -<BR> - TAO_Connector *connector = 0; -<BR> - -<BR> - ACE_NEW_RETURN (connector, -<BR> - TAO_UIOP_Connector, -<BR> - 0); -<BR> - -<BR> - return connector; -<BR> -}</DD> -</DL></DD> -<P> -<DT><STRONG><TT>requires_explicit_endpoint</TT>.</STRONG></DT> -<DD>Some protocols should not create a default -endpoint unless the user specifies a <TT>-ORBEndpoint</TT> option. For example, local -IPC (aka UNIX domain sockets) is unable to remove the rendesvouz point if the -server crashes. For those protocols, it is better to create the endpoint only -if the user requests one. This method is queried by TAO before creating a default -acceptor during ORB initialization. If it returns <TT>1</TT> then no default -endpoint should be created.</DD> -</DL> -<TT>Service Object</TT>s, such as the <TT>Protocol_Factory</TT>, must be declared -in a certain way. ACE's Service Configurator implementation provides two macros -to ensure that the required additional declarations are made to make an object -have to the correct interface. The two macros are <TT>ACE_STATIC_SVC_DECLARE</TT> -and <TT>ACE_FACTORY_DECLARE</TT>. Typical usage of these declaration macros -is demonstrated by TAO's UIOP pluggable protocol implementation: - -<P> - -<DL COMPACT> -<DT> -<DD>ACE_STATIC_SVC_DECLARE (TAO_UIOP_Protocol_Factory) -<BR> -ACE_FACTORY_DECLARE (TAO, TAO_UIOP_Protocol_Factory)</DD> -</DL>also required. These are provided by ``<TT>DEFINE</TT>'' counterparts of the -above two declaration macros. An example of how to use them follows: - -<P> - -<DL COMPACT> -<DT> -<DD>ACE_STATIC_SVC_DEFINE (TAO_UIOP_Protocol_Factory, -<BR> - ASYS_TEXT ("UIOP_Factory"), -<BR> - ACE_SVC_OBJ_T, -<BR> - &ACE_SVC_NAME (TAO_UIOP_Protocol_Factory), -<BR> - ACE_Service_Type::DELETE_THIS | -<BR> - ACE_Service_Type::DELETE_OBJ, -<BR> - 0) -<BR> - -<BR> -ACE_FACTORY_DEFINE (TAO, TAO_UIOP_Protocol_Factory)</DD> -</DL>Notice that the macro arguments above have corresponding <TT>Service Configurator</TT> -configuration file entries: - -<P> - -<DL COMPACT> -<DT> -<DD>dynamic UIOP_Factory Service_Object * TAO:_make_TAO_UIOP_Protocol_Factory() "" -<BR> -static Resource_Factory "-ORBProtocolFactory UIOP_Factory"</DD> -</DL> -<P> - -<H3><A NAME="SECTION250" HREF="#TOC_SECTION250"> -The <TT>Transport</TT> Object</A> -</H3> - -<P> - -<H3><A NAME="SECTION251" HREF="#TOC_SECTION251"> -Context</A> -</H3> - -<P> -It is desirable to provide for alternative mappings between different ORB messaging -protocols and ORB transport adaptors. For example, a single ORB messaging protocol -such as GIOP can be mapped to any reliable, connection-oriented transport protocol, -such as TCP or TP4. Alternatively, a single transport protocol can be the basis -for alternative instantiations of ORB messaging protocols, <I>e.g.</I>, different -versions of GIOP differing in the number and types of messages, as well as in -the format of those messages. - -<P> -An ORB messaging protocol imposes requirements on any underlying network transport -protocols. For instance, the transport requirements assumed by GIOP, see Section <A HREF="#IOP"><IMG ALIGN="BOTTOM" BORDER="1" ALT="[*]" - SRC="cross_ref_motif.png"></A>, -require the underlying network transport protocol to support a reliable, connection-oriented -byte-stream. These requirements are fulfilled by TCP thus leading to the direct -mapping of GIOP onto this transport protocol. However, alternative network transport -protocols such as ATM with AAL5 encapsulation may be more appropriate in some -environments. In this case, the messaging implementation will have to provide -the missing semantics, such as reliability, in order to use GIOP. - -<P> - -<H3><A NAME="SECTION252" HREF="#TOC_SECTION252"> -Problem</A> -</H3> - -<P> -The ORB Messaging protocol implementations must be independent of the adaptation -layer needed for transports that do not satisfy all their requirements. Otherwise, -the same messaging protocol may be re-implemented needlessly for each transport, -which is time-consuming, error-prone, and time/space inefficient. Likewise, -for those transports that can support multiple ORB Messaging protocols, it must -be possible to isolate them from the details of the ORB messaging implementation. -Care must be taken, however, because not all ORB Messaging protocols can be -used with all transport protocols, <I>i.e.</I>, some mechanism is needed to -ensure only semantically compatible protocols are configured [<A - HREF="#Johnson:95a">4</A>]. - -<P></P> -<DIV ALIGN="CENTER"><A NAME="iop_client"></A><A NAME="700"></A> -<TABLE> -<CAPTION ALIGN="BOTTOM"><STRONG>Figure 4:</STRONG> -Client Inter-ORB and Transport Class Diagram</CAPTION> -<TR><TD><P> - -<P> - -<DIV ALIGN="CENTER"> -<!-- MATH - $\resizebox* {5in}{!}{\includegraphics{graphics/pp_iopc.eps}}$ - --> -<IMG - WIDTH="568" HEIGHT="537" ALIGN="BOTTOM" BORDER="0" - SRC="img4.png" - ALT="pp_iopc"> </DIV> -<P> -<DIV ALIGN="CENTER"></DIV></TD></TR> -</TABLE> -</DIV><P></P> - -<P> - -<H3><A NAME="SECTION253" HREF="#TOC_SECTION253"> -Solution</A> -</H3> - -<P> -Use the Layers architecture pattern [<A - HREF="#Buschmann:95b">5</A>], which decomposes -the system into groups of components, each one at a different level of abstraction.<A NAME="tex2html5" - HREF="#foot549"><SUP>1</SUP></A> For the client, the ORB uses a particular ORB messaging protocol to send a -request. This ORB messaging protocol delegates part of the work to the transport -adapter component that completes the message and sends it to the server. If -the low-level transport in use, <I>e.g.</I>, ATM, UDP, TCP/IP, etc., does not -satisfy the requirements of the ORB messaging protocol, the ORB transport adapter -component can implement them. - -<P> -In the server, the transport adapter component receives data from the underlying -communication infrastructure, such as sockets or shared memory, and it passes -the message up to the ORB messaging layer. As with the client, this layer can -be very lightweight if the requirements imposed by the ORB messaging layer are -satisfied by the underlying network transport protocol. Otherwise, it must implement -those missing requirements by building them into the concrete transport adapter -component. - -<P></P> -<DIV ALIGN="CENTER"><A NAME="iop_server"></A><A NAME="702"></A> -<TABLE> -<CAPTION ALIGN="BOTTOM"><STRONG>Figure 5:</STRONG> -Server Inter-ORB and Transport Class Diagram</CAPTION> -<TR><TD><P> - -<P> - -<DIV ALIGN="CENTER"> -<!-- MATH - $\resizebox* {5in}{!}{\includegraphics{graphics/pp_iops.eps}}$ - --> -<IMG - WIDTH="422" HEIGHT="563" ALIGN="BOTTOM" BORDER="0" - SRC="img5.png" - ALT="pp_iops"> </DIV> -<P> -<DIV ALIGN="CENTER"></DIV></TD></TR> -</TABLE> -</DIV><P></P> - -<P> - -<H3><A NAME="SECTION254" HREF="#TOC_SECTION254"> -Applying the solution in TAO</A> -</H3> - - <P> - As shown in Figure <A HREF="#iop_client">4</A>, TAO - implements the messaging protocol and the transport protocol in - separate components. The client ORB uses the current profile to - find the right transport and ORB messaging implementations. The - creation and initialization of these classes is controlled by - the <A HREF="#design:connect"><TT>Connector</TT></A>, with each - <TT>Connector</TT> instance handling a particular ORB - messaging/transport tuple. - - - <P> - Figure <A HREF="#iop_server">5</A> illustrates how the - server's implementation uses the same transport classes, but - with a different relationship. In particular, the transport - class calls back the messaging class when data is received from - the IPC mechanism. As with the client, a factory, in this case - the <A HREF="#design:accept"><TT>Acceptor</TT></A>, creates and - initializes these objects. - -<P> - -<H3><A NAME="SECTION255" HREF="#TOC_SECTION255"> -<TT>Transport</TT> Implementation</A> -</H3> - -<P> -A <TT>Transport</TT> implements -external polymorphism [<A HREF="#Schmidt:97e">2</A>] over the -<TT>Client_Connection_Handler</TT> and the -<TT>Service_Connection_Handler</TT> objects described in the -<A HREF="#SECTION260"><TT>Connection_Handler</TT></A> section of this -document. A <TT>Connection_Handler</TT> is simply a template -instantiation of <TT>ACE_Svc_Handler<></TT>, but they don't do -much work. They just delegate on the <TT>Transport</TT> classes. -This somewhat strange design is easy to understand once it is realized -that not all <TT>ACE_Svc_Handler<></TT> classes are type -compatible (except in their most basic <TT>ACE_Event_Handler</TT> -form) so they must be wrapped using the <TT>TAO_Transport</TT> -class. - -<P> -All TAO pluggable protocol <TT>Transport</TT> classes must inherit from the -<TT>TAO_Transport</TT> abstract base class defined in <TT><<A HREF="../../tao/Transport.h">tao/Transport.h</A>></TT>. -The <TT>TAO_Transport</TT> interface is shown below. Again, only the methods -that should be implemented for a given pluggable protocol are shown: - -<P> - -<DL COMPACT> -<DT> -<DD>class TAO_Export TAO_Transport -<BR> -{ -<BR> - // = TITLE -<BR> - // Generic definitions for the Transport class. -<BR> - // -<BR> - // = DESCRIPTION -<BR> - // The transport object is created in the Service handler -<BR> - // constructor and deleted in the service handler's destructor!! -<BR> - -<BR> -public: -<BR> - TAO_Transport (CORBA::ULong tag, -<BR> - TAO_ORB_Core *orb_core); -<BR> - // default creator, requres the tag value be supplied. -<BR> - -<BR> - virtual ~TAO_Transport (void); -<BR> - // destructor -<BR> - -<BR> - virtual void close_connection (void) = 0; -<BR> - // Call the corresponding connection handler's <close> -<BR> - // method. -<BR> - -<BR> - virtual int idle (void) = 0; -<BR> - // Idles the corresponding connection handler. -<BR> - -<BR> - virtual ACE_HANDLE handle (void) = 0; -<BR> - // This method provides a way to gain access to the underlying file -<BR> - // handle used by the reactor. -<BR> - -<BR> - virtual ACE_Event_Handler *event_handler (void) = 0; -<BR> - // This method provides a way to gain access to the underlying event -<BR> - // handler used by the reactor. -<BR> - -<BR> - virtual ssize_t send (TAO_Stub *stub, -<BR> - const ACE_Message_Block *mblk, -<BR> - const ACE_Time_Value *s = 0) = 0; -<BR> - virtual ssize_t send (const ACE_Message_Block *mblk, -<BR> - const ACE_Time_Value *s = 0) = 0; -<BR> - // Write the complete Message_Block chain to the connection. -<BR> - // @@ The ACE_Time_Value *s is just a place holder for now. It is -<BR> - // not clear this this is the best place to specify this. The actual -<BR> - // timeout values will be kept in the Policies. -<BR> - -<BR> - virtual ssize_t send (const u_char *buf, -<BR> - size_t len, -<BR> - const ACE_Time_Value *s = 0) = 0; -<BR> - // Write the contents of the buffer of length len to the connection. -<BR> - -<BR> - virtual ssize_t recv (char *buf, -<BR> - size_t len, -<BR> - const ACE_Time_Value *s = 0) = 0; -<BR> - // Read len bytes from into buf. -<BR> - // @@ The ACE_Time_Value *s is just a place holder for now. It is -<BR> - // not clear this this is the best place to specify this. The actual -<BR> - // timeout values will be kept in the Policies. -<BR> - -<BR> - virtual void start_request (TAO_ORB_Core *orb_core, -<BR> - const TAO_Profile *profile, -<BR> - TAO_OutputCDR &output, -<BR> - CORBA::Environment &ACE_TRY_ENV = -<BR> - TAO_default_environment ()) -<BR> - ACE_THROW_SPEC ((CORBA::SystemException)); -<BR> - // Fill into <output> the right headers to make a request. -<BR> - -<BR> - virtual void start_locate (TAO_ORB_Core *orb_core, -<BR> - const TAO_Profile *profile, -<BR> - CORBA::ULong request_id, -<BR> - TAO_OutputCDR &output, -<BR> - CORBA::Environment &ACE_TRY_ENV = -<BR> - TAO_default_environment ()) -<BR> - ACE_THROW_SPEC ((CORBA::SystemException)); -<BR> - // Fill into <output> the right headers to make a locate request. -<BR> - -<BR> - virtual int send_request (TAO_Stub *stub, -<BR> - TAO_ORB_Core *orb_core, -<BR> - TAO_OutputCDR &stream, -<BR> - int twoway, -<BR> - ACE_Time_Value *max_time_wait) = 0; -<BR> - // Depending on the concurrency strategy used by the transport it -<BR> - // may be required to setup state to receive a reply before the -<BR> - // request is sent. -<BR> - // Using this method, instead of send(), allows the transport (and -<BR> - // wait strategy) to take appropiate action. -<BR> - -<BR> - virtual int handle_client_input (int block = 0, -<BR> - ACE_Time_Value *max_wait_time = 0); -<BR> - // Read and handle the reply. Returns 0 when there is Short Read on -<BR> - // the connection. Returns 1 when the full reply is read and -<BR> - // handled. Returns -1 on errors. -<BR> - // If <block> is 1, then reply is read in a blocking manner. -<BR> - -<BR> - virtual int register_handler (void); -<BR> - // Register the handler with the reactor. Will be called by the Wait -<BR> - // Strategy if Reactor is used for that strategy. Default -<BR> - // implementation out here returns -1 setting <errno> to ENOTSUP. -<BR> - -<BR> -};</DD> -</DL>Each method is described below: - -<P> - -<DL> -<DT><STRONG>The Constructor.</STRONG></DT> -<DD>As with all of the TAO pluggable protocol framework components -described so far, the constructor for the concrete <TT>Transport</TT> object -should also initialize the <TT>TAO_Transport</TT> base class with the tag corresponding -to the pluggable protocol.</DD> -<P> -<DT><STRONG><TT>close_connection</TT>.</STRONG></DT> -<DD>The underlying <TT>Connection Handler</TT>'s <TT>close</TT> -method is invoked my this method.</DD> -<P> -<DT><STRONG><TT>idle</TT>.</STRONG></DT> -<DD>This method idles the underlying <TT>Connection Handler</TT>.</DD> -<P> -<DT><STRONG><TT>handle</TT>.</STRONG></DT> -<DD>This method returns the underlying file handle used by the -<TT>Reactor</TT>.</DD> -<P> -<DT><STRONG><TT>event_handler</TT>.</STRONG></DT> -<DD>This method returns the underlying <TT>Event Handler</TT> -used by the <TT>Reactor</TT>.</DD> -<P> -<DT><STRONG><TT>send</TT>.</STRONG></DT> -<DD>The <TT>send</TT> writes data to the connection established -in the underlying transport, such as a TCP connection in the IIOP pluggable -protocol. Three versions of this method must be implemented. Two of them write -data contained within an <TT>ACE_Message_Block</TT> and the remaining simply -sends the data within a buffer of a given length. -<P> -When implementing this method, it is important to be aware of the correct underlying -<TT>send</TT> or <TT>write</TT> operation to use. Some of TAO's existing pluggable -protocols use the <TT>send</TT> calls provided by the operating system because -no further processing of the data being sent is necessary. However, other protocols -may process perform additional operations on the data being sent, in which case -the <TT>send</TT> operation provided by the underlying protocol implementation -should be used instead of the raw operating system <TT>send</TT> call. -</DD> -<P> -<DT><STRONG><TT>recv</TT>.</STRONG></DT> -<DD>The <TT>recv</TT> operation reads a given number of bytes into -a supplied buffer. Unlike the <TT>send</TT> method, there is only one version -of the <TT>recv</TT> operation. The same caveat of ensuring that the appropriate -<TT>recv</TT> or <TT>read</TT> operation is used also applies to this method.</DD> -<P> -<DT><STRONG><TT>start_request</TT>.</STRONG></DT> -<DD>This method creates the appropriate header to make -a request and write it into the provided output CDR stream. This method is closely -tied to TAO's GIOP implementation. <TT>start_request</TT> implementations should -essentially be the same in all pluggable protocol implementations. The only -thing that should differ is the type of <TT>Profile</TT> being used. Note that -this method is only useful for clients.</DD> -<P> -<DT><STRONG><TT>start_locate</TT>.</STRONG></DT> -<DD>This method creates the appropriate header to make -a <I>locate</I> request and write it into the provided output CDR stream. This -method is closely tied to TAO's GIOP implementation. <TT>start_locate</TT> -implementations should essentially be the same in all pluggable protocol implementations. -The only thing that should differ is the type of <TT>Profile</TT> being used. -Note that this method is only useful for clients. Note that this method is only -useful for clients.</DD> -<P> -<DT><STRONG><TT>send_request</TT>.</STRONG></DT> -<DD>Depending on the concurrency strategy used by the transport -it may be required to setup state to receive a reply before the request is sent. -Using this method, instead of <TT>send</TT>, allows the transport (and wait -strategy) to take appropiate action. This method is closely tied to TAO's GIOP -implementation. <TT>send_request</TT> implementations should essentially be -the same in all pluggable protocol implementations. The only thing that should -differ is the type of <TT>Profile</TT> being used. Note that this method is -only useful for clients.</DD> -<P> -<DT><STRONG><TT>handle_client_input</TT>.</STRONG></DT> -<DD><TT>handle_client_input</TT> reads and handles -the reply from the server. It returns zero when there is <TT>Short Read</TT> -on the connection, returns <TT>1</TT> when the full reply is read and handled, -and returns <TT>-1</TT> on errors. Note that this method is only useful for -clients.</DD> -<P> -<DT><STRONG><TT>register_handler</TT>.</STRONG></DT> -<DD>This method registers the <TT>Connection Handler</TT> -with the <TT>Reactor</TT>. It will be called by the <TT>Wait Strategy</TT> if -the <TT>Reactor</TT> is used for that strategy. This code should essentially -be ``boilerplate'' code. It shouldn't differ much between pluggable protocol -implementations if the same ACE event handling and dispatching components are -used. Note that this method may be deprecated in the future.</DD> -</DL> -There other methods in the <TT>TAO_Transport</TT> that can be overridden. However, -the default implementations should be more than satisfactory for most pluggable -protocols. - -<P> -TAO's existing pluggable protocols implement client-side and server-side specific -<TT>Transport</TT>s. For the most part, they can be used as references for other -pluggable protocols. - -<H3><A NAME="SECTION260" HREF="#TOC_SECTION260"> -The <TT>Connection_Handler</TT></A> -</H3> -A <TT>Connection_Handler</TT> is simply a template instantiation of -<TT>ACE_Svc_Handler<></TT> [<A HREF="#Schmidt:97c">1</A>], -a service handler. <TT>ACE_Svc_Handler</TT>s provide a well-defined -interface that <TT>Acceptor</TT> and <TT>Connector</TT> pattern -factories use as their target. Service handlers perform -application-specific processing and communicate via the connection -established by the <TT>Connector</TT> and <TT>Acceptor</TT> -components. Typically, TAO <TT>Connection_Handler</TT>s will subclass -<TT>ACE_Svc_Handler</TT> and do all the interesting work in the -subclass. - -<P> - -<H3><A NAME="SECTION261" HREF="#TOC_SECTION261"> -<TT>Connection_Handler</TT> Implementation</A> -</H3> - -TAO pluggable transport protocol <TT>Connection_Handler</TT>s should -be derived from the <TT>ACE_Svc_Handler</TT> class declared in -<<A - HREF="../../../ace/Svc_Handler.h"><TT>ace/Svc_Handler.h</TT></A>>. TAO's existing pluggable transport protocol -implementations define three classes, a base class derived from an -<TT>ACE_Svc_Handler</TT> specific to that protocol, and a client-side -and a server-side class derived from that base class. Generally, it -is a good idea to base new <TT>Connection_Handler</TT> implementations -on TAO's existing ones. The interfaces for the existing -<TT>Connection_Handler</TT>s are defined in -<<A HREF="../../tao/IIOP_Connect.h"><TT>tao/IIOP_Connect.h</TT></A>> -and -<<A HREF="../../tao/UIOP_Connect.h"><TT>tao/UIOP_Connect.h</TT></A>>. - -<P> -<HR> -<P> - -<H3><A NAME="SECTION300" HREF="#TOC_SECTION300"> -Notes From a ``Real World'' Pluggable Protocol Implementation</A> -</H3> - -By Bruce Trask <<A -HREF="mailto:btrask@contactsystems.com">btrask@contactsystems.com</A>> - -<P>This section is based on notes I took when adding a different -transport layer to the TAO ORB. I was given some initial guidelines -on adding an additional protocol and these proved very helpful. -Beyond that there was not much more documentation and so I hope the -information in this paper will serve to further assist anybody whose -is adding a pluggable protocol to the TAO ORB. - -<P>I found that in order to successfully add the new protocol capabilities, one had to -have a very good understanding of some of the patterns upon which the ACE framework -is built. These are the REACTOR, ACCEPTOR, CONNECTOR, FACTORY, STRATEGY, -and SERVICE CONFIGURATOR PATTERN. The papers that I found helpful on these -were: -<BR> -<BLOCKQUOTE> -Reactor ( -<A HREF="http://www.cs.wustl.edu/~schmidt/Reactor.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/Reactor.pdf">PDF</A> -)<BR> - -Reactor1-93 ( -<A HREF="http://www.cs.wustl.edu/~schmidt/Reactor1-93.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/Reactor1-93.pdf">PDF</A> -)<BR> - -Reactor2-93 ( -<A HREF="http://www.cs.wustl.edu/~schmidt/Reactor2-93.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/Reactor2-93.pdf">PDF</A> -)<BR> - -reactor-rules ( -<A HREF="http://www.cs.wustl.edu/~schmidt/reactor-rules.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/reactor-rules.pdf">PDF</A> -)<BR> - -reactor-siemens ( -<A HREF="http://www.cs.wustl.edu/~schmidt/reactor-siemens.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf">PDF</A> -)<BR> - -Svc-Conf ( -<A -HREF="http://www.cs.wustl.edu/~schmidt/Svc-Conf.ps.gz">PostScript</A> | -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/Svc-Conf.pdf">PDF</A> -)<BR> - -Acc-Con ( -<A HREF="http://www.cs.wustl.edu/~schmidt/Acc-Con.ps.gz">PostScript</A> -<A HREF="http://www.cs.wustl.edu/~schmidt/PDF/Acc-Con.pdf">PDF</A> -) -</BLOCKQUOTE> -<P>These are all readily available from the TAO and ACE website. -<P>My starting point for understanding how to add a pluggable protocol -to the TAO ORB came from mailing list entry from <A -HREF="mailto:coryan@uci.edu">Carlos O'Ryan</A>. One can find it -in the archives of the comp.soft-sys.ace newsgroup. It is dated -1999/06/02 RE: [ace-users] TAO: ATM pluggable protocol. I will repeat -the section of that email that was particularly useful to me. (In the -email, he is responding to someone who had inquired about adding the -ATM protocol). <p> - -<BLOCKQUOTE> -Basically, you need to look at the following files:<BR> - -<BLOCKQUOTE> -IIOP_Profile.{h,i,cpp}<BR> -IIOP_Connector.{h,i,cpp}<BR> -IIOP_Acceptor.{h,i,cpp}<BR> -IIOP_Factory.{h,i,cpp}<BR> -IIOP_Transport.{h,i,cpp}<BR> -Connect.{h,i,cpp} [probably will be renamed IIOP_Connect VSN] -</BLOCKQUOTE> - -<P> -The profile class handles the addressing format for your transport. -It would basically be a wrapper around the ACE_ATM_Addr() class. The -Connector and Acceptor classes are simply wrappers around -ACE_Acceptor<ACE_ATM_ACCEPTOR> and -ACE_Connector<ACE_ATM_ACCEPTOR>, again no big deal (I think). -The factory is even simpler. - -<P> -Things get really interesting in the Transport and Connect classes. -Transport just implements external polymorphism over the -Client_Connection_Handler and the Service_Connection_Handler objects -defined in the Connect.{h,i,cpp}, those are simply -ACE_Svc_Handler<ACE_ATM_Stream>, but they don't do much work, -they just delegate on the Transport classes. This somewhat strange -design is easy to understand once you realize that all the -ACE_Svc_Handler<> classes are not type compatible (except in -their most basic ACE_Event_Handler form). So they must be wrapped -using the TAO_Transport class. -</BLOCKQUOTE> - - -<P>Make sure to review -``<A HREF="../releasenotes/index.html#pp">Pluggable Protocols</A>'' -in -``<A HREF="../releasenotes/index.html">Release Information for the ACE -ORB (TAO)</A>'' -in the -<A HREF="../releasenotes">TAO/docs/releasenotes</A> directory. -<BR><P> -Just for completeness sake, I'll include some other mailing list entries which were helpful -in getting me started. The following is from <A HREF="mailto:ossama@uci.edu">Ossama Othman</A>. - -<BLOCKQUOTE>The stock TAO distribution has support for two transport protocols, -TCP/IP and local namespace sockets (aka Unix Domain sockets). However, -TAO's pluggable protocols framework allows users to add support for -additional transport protocols. All you'd really have to do is -implement a SCRAMNet pluggable transport protocol with the interface -TAO's pluggable protocol framework provides and you'd be able to use -SCRAMNet with TAO just as easily as the IIOP (GIOP over TCP/IP) and -UIOP (GIOP over Unix domains sockets) protocols. -<P> -The idea is to implement GIOP messaging over a SCRAMNet transport. If -you model your implementation on TAO's IIOP and UIOP implementations -then it should be fairly straightforward to create a SCRAMNet -pluggable protocol for TAO. The hard part is implementing the -equivalent ACE classes for SCRAMNet. -<P> -. . . -<P> -It's actually not that bad. The easiest way to add a pluggable protocol -to TAO, IMO, is to base your pluggable protocol on existing ones. As -long as you have the same interface for your protocol as the existing -ones then it is fairly easy to create your TAO pluggable protocol. -However, in order to do that you have to create ACE_SCRAMNet_{Acceptor, -Connector, Stream, Addr} implementations, for example, since TAO's -existing pluggable protocols use those interfaces. - -<P> -As long as you use the same interface for your protocol as the -interface for ace/ACE_SOCK* and tao/IIOP* then you shouldn't have much -of a problem. -</BLOCKQUOTE> - -<P> -This also assumes that you're implementation can satisfy the -conditions stated earlier in this document. - -<P>Note also that the TAO files pluggable.* -are important to review and understand as they contain the abstract -classes that form the common inteface for TAO's pluggable protocol -framework. <BR> <P>Getting a full understanding on how IIOP was -implemented (GIOP over TCP/IP) and also seeing how provisions were -made to add UIOP, was very helpful to adding my own protocol. In -understanding IIOP, I needed to review the section of the OMG CORBA -spec on GIOP, IIOP and Object references and see how this would apply -to my protocol. <BR> - -<P>In my case, I added a transport layer that uses SCRAMNet (from -Systran Corp) replicated shared memory hardware. This is actual -physical memory cards located on two different machines. When a -change is made to one memory then that change appears very quickly -(very low latency here) in the other memory. I decided that I would -implement GIOP over SCRAMNet as this seemed to be the simplest. With -SCRAMNet, one could implement this transport layer for the TAO ORB in -a few different ways, GIOP over SCRAMNet, Environment-specific -inter-ORB protocol (ESIOP) or using collocation (since it is shared -replicated memory). I have not done the latter two, only GIOP over -SCRAMNet just to get a proof of concept working. - -<BR><P> For a graphical representation of the extensions for the new -SCRAMNet classes I have may a skeletal Rose diagram showing (at this -point) the inheritance relationships of the new and existing classes. -See (TBD) ftp site for this Rose diagram. - -<BR><P> -The new classes created were. -<BR> -<BLOCKQUOTE> -TAO_SCRAMNet_Profile (Derived from TAO_Profile in <A HREF="../../tao/Profile.h">Profile.h</A>)<BR> -TAO_SCRAMNet_Acceptor (Derived from TAO_Acceptor in <A HREF="../../tao/Pluggable.h">Pluggable.h</A>) <BR> -TAO_SCRAMNet_Connector (Derived from TAO_Connector in <A HREF="../../tao/Pluggable.h">Pluggable.h</A>)<BR> -TAO_SCRAMNet_Transport (Derived from TAO_Transport in <A HREF="../../tao/Pluggable.h">Pluggable.h</A>) - <BLOCKQUOTE>TAO_SCRAMNet_Server_Transport<BR> - TAO_SCRAMNet_Client_Transport</BLOCKQUOTE> -TAO_SCRAMNet_Protocol_Factory (Derived from TAO_Protocol Factory in <A HREF="../../tao/Protocol_Factory.h">Protocol_Factory.h</A>)<BR> -TAO_SCRAMNet_Handler_Base (as in <A HREF="../../tao/IIOP_Connect.h">IIOP_Connect.h</A>) - <BLOCKQUOTE>TAO_SCRAMNet_Client_Connection_Handler<BR> - TAO_SCRAMNet_Server_Connection_Handler</BLOCKQUOTE></BLOCKQUOTE> -<BLOCKQUOTE>ACE_SCRAMNet_Addr<BR> -ACE_SCRAMNet_Acceptor<BR> -ACE_SCRAMNet_Connector<BR> -ACE_SCRAMNet_Stream</BLOCKQUOTE> -<P>I closely followed the way that IIOP and UIOP were defined and implemented in the definition and -implementation of the SCRAMNet classes. Following the existing protocol implementation was -the largest source of help for me. Being able to step through the operation of the ORB for -the IIOP protocol and then transposing that over to my protocol made the process relatively painless -and quite the learning experience. -<BR><P> - -I am using TAO under Phar Lap's Embedded Tool Suite Real-Time -Operating System which is an RTOS which supports a subset of the Win32 -API and Winsock 1.1. Because of the new SCRAMNet transport hardware I -needed to change the ORBs core reactor to a WFMO_Reactor. Any -instance of the TAO ORB can only have one reactor type or it won't -work. In my case I am using an ORB in one thread that uses the -WFMO_Reactor and the SCRAMNet transport, and an ORB in another thread -that uses a Select Reactor and the IIOP protocol. I won't go into -much of the SCRAMNet specific stuff as I assume most people are -interested in adding a pluggable protocol in general. <BR><P> - -<P> - -RE: IORs<BR> -I found that I needed to have a full understanding of what the exact contents of -a TAO-created IOR were as I needed to be able to understand how to decode the -location information that was now written in the IOR with the SCRAMNet -specific information. Decoding of the preconnect and endpoint info is important. -The endpoint info both in the command line arguments and in the IOR are different -for the each protocol and so your implemention of the new classes has to parse this -information correctly. -<BR><P> -In order to create the ORB with the Win32 Reactor at the core as well as the -SCRAMNet protocol factory loaded and initialize I needed to use the -svc.conf file with the the following options -<A HREF="../Options.html#-ORBReactorType">-ORBReactorType</A> wfmo -<A HREF="../Options.html#-ORBProtocolFactory">-ORBProtocolFactory</A> SCRAMNet_Factory -<BR><P> - -</OL> - -Beyond the above, I just traced through the operation of the IIOP -protocol in action to see exactly where I needed to just graft on the -new ACE_SCRAMNet classes, the TAO_SCRAMNet classes and their -associated implementations for send and recv so that the SCRAMNet -hardware was used as the transport and not the ethernet hardware. -Questions, comments, changes are welcome. I can be reached at <A -HREF="mailto:btrask@contactsystems.com">btrask@contactsystems.com</A> - -<P> -<HR> -<P> - -<H3> -<A NAME="SECTION400" HREF="#TOC_SECTION400"> -Additional Implementation Information -</A> -</H3> - -<P> -This section covers additional information not necessarily related to -TAO's pluggable protocol framework but may still be of interest to -pluggable protocol and ORB developers, nevertheless. - -<H3> -<A NAME="SECTION410" HREF="#TOC_SECTION410"> -Tags -</A> -</H3> - -Tags are used to uniquely identify certain parts of an ORB, including -the following: -<P> -<UL> -<LI>vendor</LI> -<LI>profile</LI> -<LI>service</LI> -<LI>component</LI> -<LI>ORB type</LI> -</UL> -<P> -A list of current <A HREF="http://www.omg.org/">OMG</A> assigned tags -is available at: -<BLOCKQUOTE> -<A HREF="ftp://ftp.omg.org/pub/docs/ptc/99-05-02.txt">ftp://ftp.omg.org/pub/docs/ptc/99-05-02.txt</A> -</BLOCKQUOTE> -<P> -For information about tags and tag allocation see: -<BLOCKQUOTE> -<A HREF="http://www.omg.org/cgi-bin/doc?ptc/99-02-01">http://www.omg.org/cgi-bin/doc?ptc/99-02-01</A> -</BLOCKQUOTE> - -<P> -Information about tags used in TAO is available -<A HREF="../Tags.html">here</A>. - -<P> -<HR> -<P> - -<H3><A NAME="SECTION500" HREF="#TOC_SECTION500"> -Using a Pluggable Protocol</A> -</H3> - -<P> -Once a TAO pluggable protocol is implemented, the ORB is told to load it by -adding entries to a <TT>Service Configurator</TT> configuration file (e.g. <TT>svc.conf</TT> -for that protocol. A typical <TT>svc.conf</TT> file could contain entries such -as the following: - -<P> - -<DL COMPACT> -<DT> -<DD> -dynamic FOOIOP_Factory Service_Object * TAO_FOO:_make_TAO_FOOIOP_Protocol_Factory() "" -<BR> -static Resource_Factory "-ORBProtocolFactory FOOIOP_Factory" -<P> -</DD> -</DL>These entries would cause a pluggable protocol called ``FOOIOP'' to be loaded -into the ORB. By default the IIOP and UIOP (if supported) pluggable protocols -are loaded into TAO if no such entries are provided. Explicitly specifying which -protocols to load in this way prevents any pluggable protocols from being loaded -by default. The -<TT><A HREF="../Options.html#-ORBProtocolFactory">-ORBProtocolFactory</A></TT> -ORB option causes the specified protocol factory to be loaded into the -ORB. - -Multiple pluggable protocols can be loaded simply by adding more -<TT>Service Configurator</TT> configuration file entries. For example, the following -entries would cause the TAO's IIOP and the fictional FOOIOP pluggable protocols -to be loaded: - -<P> - -<DL COMPACT> -<DT> -<DD>dynamic FOOIOP_Factory Service_Object * TAO_FOO:_make_TAO_FOOIOP_Protocol_Factory() "" -<BR> -static Resource_Factory "-ORBProtocolFactory FOOIOP_Factory" -<BR> -dynamic IIOP_Factory Service_Object * TAO:_make_TAO_IIOP_Protocol_Factory() "" -<BR> -static Resource_Factory "-ORBProtocolFactory IIOP_Factory" -<P> -</DD> -</DL>In this case, TAO's UIOP pluggable protocol would <I>not</I> be -loaded. <TT>Service Configurator</TT> configuration file names are -not limited to the name ``<TT>svc.conf</TT>.'' The ORB can be told -to use a configuration file other than ``<TT>svc.conf</TT>'' by using the -<TT><A HREF="../Options.html#-ORBSvcConf">-ORBSvcConf</A></TT> -ORB option. - - -<P> -Note that the FOOIOP protocol resides in a library other than the TAO -library, called ``<TT>libTAO_FOO.so</TT>'' on UNIX platforms, and -``<TT>TAO_FOO.dll</TT>'' on Win32 platforms. This ability to -dynamically load pluggable protocols in libraries that are completely -separate libraries from the TAO library truly makes TAO's pluggable -protocol framework ``pluggable.'' Make sure the directory your -pluggable protocol library is located in is also in your library -search path, typically <TT>LD_LIBRARY_PATH</TT> on UNIX systems and/or -the ``<TT>/etc/ld.so.conf</TT>'' file on some UNIX systems. Remember -to run <TT>ldconfig</TT> if you modify ``<TT>/etc/ld.so.conf</TT>.'' - -<P> -Creating an endpoint specific to a given pluggable protocol is simply a matter -of using TAO's <TT><A HREF="../Options.html#-ORBEndpoint">-ORBEndpoint</A></TT> ORB option. This is detailed in the documentation -for the -<TT><A HREF="#TAO_Acceptor::open">open</A></TT> -and -<TT><A HREF="#TAO_Acceptor::open_default">open_default</A></TT> -methods in the -<TT><A HREF="#SECTION210">Acceptor</A></TT> -section of this document. Once an endpoint is created, the client uses -the IOR that points to the object on that endpoint to make requests on -that object. - -<P> -All ORB options are described <A HREF="../Options.html">here</A>. - -<P> -<HR> -<P> - -<H3><A NAME="SECTION600" HREF="#TOC_SECTION600"> -Bibliography</A> -</H3><DL COMPACT><DD><P></P><DT><A NAME="Schmidt:97c">1</A> -<DD> -D. C. Schmidt, -``<A HREF=http://www.cs.wustl.edu/~schmidt/PDF/Acc-Con.pdf> - Acceptor and Connector: Design Patterns for Initializing - Communication Services</A>,'' - in <EM> Pattern Languages of Program Design</EM> - (R. Martin, F. Buschmann, and D. Riehle, eds.), Reading, MA: Addison-Wesley, - 1997. - -<P></P><DT><A NAME="Schmidt:97e">2</A> -<DD> -C. Cleeland, D. C. Schmidt and T. Harrison, -``<A HREF=http://www.cs.wustl.edu/~schmidt/PDF/External-Polymorphism.pdf> - External Polymorphism -- An Object Structural Pattern for - Transparently Extending Concrete Data Types</A>,'' - in <EM> Pattern Languages of Program Design</EM> - (R. Martin, F. Buschmann, and D. Riehle, eds.), Reading, MA: Addison-Wesley, - 1997. - -<P></P><DT><A NAME="Schmidt:94k">3</A> -<DD> -D. C. Schmidt and T. Suda, - ``<A HREF=http://www.cs.wustl.edu/~schmidt/PDF/DSEJ-94.pdf> - An Object-Oriented Framework for Dynamically - Configuring Extensible Distributed Communication Systems</A>,'' <EM> IEE/BCS - Distributed Systems Engineering Journal (Special Issue on Configurable - Distributed Systems)</EM>, vol. 2, pp. 280-293, December 1994. - -<P></P><DT><A NAME="Johnson:95a">4</A> -<DD> -H. Hueni, R. Johnson, and R. Engel, ``A Framework for Network Protocol - Software,'' in <EM> Proceedings of OOPSLA '95</EM>, (Austin, Texas), ACM, - October 1995. - -<P></P><DT><A NAME="Buschmann:95b">5</A> -<DD> -F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, <A -HREF="http://www.cs.wustl.edu/~schmidt/POSA/">Pattern-Oriented Software -Architecture - A System of Patterns</EM>.</A> Wiley and Sons, 1996. - -<P></P><DT><A NAME="Schmidt:99x">6</A> -<DD> -Carlos O'Ryan, Fred Kuhns, Douglas C. Schmidt, Ossama Othman, and Jeff -Parsons, <A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf"> The -Design and Performance of a Pluggable Protocols Framework for -Real-time Distributed Object Computing Middleware</A>, Proceedings of -the IFIP/ACM <A -HREF="http://www.research.ibm.com/Middleware2000/">Middleware 2000</A> -Conference, Pallisades, New York, April 3-7, 2000. <P> - -<P></P><DT><A NAME="Schmidt:99c">7</A> <DD> Fred Kuhns, Carlos O'Ryan, -Douglas C. Schmidt, Ossama Othman, and Jeff Parsons, <A -HREF="http://www.cs.wustl.edu/~schmidt/PDF/PfHSN.pdf">The Design and -Performance of a Pluggable Protocols Framework for Object Request -Broker Middleware,</A> Proceedings of the <A -HREF="http://www.isi.edu/pfhsn99/call.html">IFIP Sixth International -Workshop on Protocols For High-Speed Networks (PfHSN '99)</A>, Salem, -MA, August 25--27, 1999. <P> - -</DL> - -<P> - -<HR><H4>Footnotes</H4> -<DL> -<DT><A NAME="foot549">... abstraction.</A><A NAME="foot549" - HREF="#tex2html5"><SUP>1</SUP></A> -<DD>Protocol stacks based on the Internet or ISO OSI reference models are common -examples of the Layers architecture. - - -</DL><HR> - <ADDRESS><a href="mailto:ossama@uci.edu">Ossama Othman</a></ADDRESS> -<!-- Created: Tue Dec 14 16:53:58 CST 1999 --> -<!-- hhmts start --> -Last modified: Sat Dec 8 10:43:59 PST 2001 -<!-- hhmts end --> -</BODY> -</HTML> diff --git a/TAO/docs/pluggable_protocols/pluggable_protocols.css b/TAO/docs/pluggable_protocols/pluggable_protocols.css deleted file mode 100644 index 1993b851311..00000000000 --- a/TAO/docs/pluggable_protocols/pluggable_protocols.css +++ /dev/null @@ -1,31 +0,0 @@ - -/* Century Schoolbook font is very similar to Computer Modern Math: cmmi */ -.MATH { font-family: "Century Schoolbook", serif; } -.MATH I { font-family: "Century Schoolbook", serif; font-shape: italic } -.BOLDMATH { font-family: "Century Schoolbook", serif; font-weight: bold } - -/* implement both fixed-size and relative sizes */ -SMALL.XTINY { font-size : xx-small } -SMALL.TINY { font-size : x-small } -SMALL.SCRIPTSIZE { font-size : smaller } -SMALL.FOOTNOTESIZE { font-size : small } -SMALL.SMALL { } -BIG.LARGE { } -BIG.XLARGE { font-size : large } -BIG.XXLARGE { font-size : x-large } -BIG.HUGE { font-size : larger } -BIG.XHUGE { font-size : xx-large } - -/* heading styles */ -H1 { } -H2 { } -H3 { } -H4 { } -H5 { } - -/* mathematics styles */ -DIV.displaymath { } /* math displays */ -TD.eqno { } /* equation-number cells */ - - -/* document-specific styles come next */ diff --git a/TAO/docs/poa_migration.html b/TAO/docs/poa_migration.html deleted file mode 100644 index 7cb99ccd7e3..00000000000 --- a/TAO/docs/poa_migration.html +++ /dev/null @@ -1,208 +0,0 @@ -<HTML> -<HEAD> - <META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac"> - <TITLE>Migrating from the BOA to the POA</TITLE> - <!-- $Id$ --> -</HEAD> - -<BODY text = "#000000" -link="#0000ff" -vlink="#cc0000" -bgcolor="#ffffff"> - -<HR><P> -<H3>Migrating CORBA Applications from BOA to POA</H3> - -Starting with the CORBA 2.2, the Basic Object Adapter (BOA) has been -deprecated in favor of the <A -HREF="http://www.cs.wustl.edu/~schmidt/POA.ps.gz">Portable Object -Adapter</A> (POA). This document explains the changes required to -migrate CORBA applications based on the BOA to use TAO's POA -implementation, which is the only Object Adapter supported by TAO. -For more information on the benefits of the POA please see the <A -HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html">Object -Interconnection</A> columns written by <A -HREF="http://www.cs.wustl.edu/~schmidt/">Doug Schmidt</A> and <A -HREF="http://www.iona.com/hyplan/vinoski/">Steve Vinoski</a>. - -<h3>Contents</h3> -<ul> - <li><a href="#Client-side Changes">Client-side Changes</a> - <li><a href="#Server-side Changes">Server-side Changes</a> - <li><a href="#Reference counting Servants">Reference counting Servants</a> -</ul> - -<H4><a name="Client-side Changes">Client-side Changes</a></h4> - -<ul> -<li>Very little has changed. Thus, many applications require no changes.</li><P> -</ul> - -<h4><a name="Server-side Changes">Server-side Changes</a></h4> - -<UL> -<li><CODE>POA_init</CODE> is replaced with <CODE>resolve_initial_references("RootPOA")</CODE> followed -by a <CODE>_narrow</CODE> operation.</li><P> - -<li>The implementation no longer inherits from the client-side stub. -Instead, they inherit from <CODE>PortableServer::ServantBase</CODE>. -The implications of this are (a) if you want a object reference for -that, you must use the <CODE>_this</CODE> method.</li><P> - -<li>Object ID's are assigned by the POA unless you activate the -servant with a specific ID. <A -HREF="../performance-tests/Cubit/TAO/IDL_Cubit">IDL_Cubit</A> -has examples on how to do this.</li><P> - -<li>Unlike the BOA, the POA explicitly addresses the temporal nature -of servants and declares that a POA can service either transient or -persistent servants (not both). The root POA's (mandated, -unchangeable) policy is "transient". The implications of this are -that in order for a client to be able to manufacture an object -reference on its own and use that to access an object, the servant for -that object must be registered with a POA whose policy is -"persistent". Thus, you must create a child POA with that policy and -register the servant with that POA. NOTE: when the POA declares -something as "persistent", it is only stating that the key is valid -between different runs of the server; it makes no claims that state or -anything else is persistent.</li><P> - -<ul> - <li> Servants are not automatically activated, hence you must register - them by calling some of the <CODE>activate_object*</CODE> methods on a POA or - calling <CODE>_this</CODE> on the servant; with the latest you have no control on - the ObjectId (which sometimes is good), and the POA must support the - right policies (the RootPOA does).</li><P> - - <li>Servant constructors use to take a <CODE>const -char*</CODE> parameter to set - they object id, this is not needed now, in fact in many cases they use - to pass this argument to the skeleton class: this will fail -now.</li><P> </ul> This list is not intended to be exhaustive, but -should give you a good starting point. If you find things along the -way that change your applications and I didn't note them, please send -them to me. Perhaps we can work together on the ultimate migration -document. <P> </UL> - -<h4><a name="Reference counting Servants">Reference counting Servants</h4> - -The new POA/servant <a -href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">reference -counting rules</a> of the CORBA 2.3 spec are somewhat tricky. Here are -two main reasons why: <p> - -<ul> - -<li> If a servant is deleted without deactivating from the POA, the -application will crash because the POA will try to access the still -registered (but now non-existent) servant when the POA is destroyed. <p> - -The solution to this is to make sure that the servant is deleted after -the POA is deleted or make sure that the servant is deactivated from -the POA before the servant is deleted. </li> <p> - -<li> You cannot delete a servant which is the target of the current -upcall/request. A good example of this is the typical destroy() -method, usually written like this: - -<PRE> - -class TAO_Export TAO_Thread_Policy : public POA_PortableServer::ThreadPolicy -{ - void destroy (CORBA_Environment &ACE_TRY_ENV); -}; - -void -TAO_Thread_Policy::destroy (CORBA::Environment &ACE_TRY_ENV) -{ - PortableServer::POA_var poa = this->_default_POA (ACE_TRY_ENV); - ACE_CHECK; - - PortableServer::ObjectId_var id = poa->servant_to_id (this, - ACE_TRY_ENV); - ACE_CHECK; - - poa->deactivate_object (id.in (), - ACE_TRY_ENV); - ACE_CHECK; - - // Commit suicide: must have been dynamically allocated. - delete this; -} - -</PRE> - -The correct implementation is: - -<PRE> - -class TAO_Export TAO_Thread_Policy : public virtual PortableServer::RefCountServantBase, - public virtual POA_PortableServer::ThreadPolicy -{ - void destroy (CORBA_Environment &ACE_TRY_ENV); -}; - -void -TAO_Thread_Policy::destroy (CORBA::Environment &ACE_TRY_ENV) -{ - // - // Remove self from POA. Because of reference counting, the POA - // will automatically delete the servant when all pending requests - // on this servant are complete. - // - - PortableServer::POA_var poa = this->_default_POA (ACE_TRY_ENV); - ACE_CHECK; - - PortableServer::ObjectId_var id = poa->servant_to_id (this, - ACE_TRY_ENV); - ACE_CHECK; - - poa->deactivate_object (id.in (), - ACE_TRY_ENV); - ACE_CHECK; -} - -</PRE> - -One additional step required is to make the POA responsible for the -servant after it has been registered with the POA: - -<PRE> - - // Register with the POA. - PortableServer::ThreadPolicy_var result = new_thread_policy->_this (ACE_TRY_ENV); - - // Give ownership of this servant to the POA. - new_thread_policy->_remove_ref (ACE_TRY_ENV); - -</PRE> - -If you use the above approach of multiple inheritance, you must add -the following to your header file: - -<PRE> - -// This is to remove "inherits via dominance" warnings from MSVC. -// MSVC is being a little too paranoid. -#if defined (_MSC_VER) -# pragma warning (disable : 4250) -#endif /* _MSC_VER */ - -</PRE> - -To see the above example in detail, checkout <A -HREF="../examples/POA/Reference_Counted_Servant">TAO/examples/POA/Reference_Counted_Servant</A> -and/or <A HREF="../tao/PortableServer/Root_POA.cpp">Root_POA.cpp</A> and <A -HREF="../tao/PortableServer/Root_POA.h">Root_POA.h</A>. </li> <p> - -</ul> - -<hr><P> - -Back to the <A HREF="index.html">TAO -documentation</A> page. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</html> diff --git a/TAO/docs/reactivator.html b/TAO/docs/reactivator.html deleted file mode 100644 index 43e853d572e..00000000000 --- a/TAO/docs/reactivator.html +++ /dev/null @@ -1,22 +0,0 @@ -<html> -<!-- $Id$ --> - -<head> -<title> TAO Reactivation Service </title> -<meta HTTP-EQUIV="Refresh" CONTENT="1;URL=implrepo.html"> -</head> - -<body text="#000000" link="#0000ff" vlink="#cc0000" bgcolor="#ffffff"> - -<hr> - -<h1>TAO Reactivator </h1> - -<p>Has moved to <a href="implrepo.html">here</a> as the Implementation Repository</p> - -<hr> - -<p>Back to the <a HREF="index.html">TAO -documentation</a> page. <!--#include virtual="/~schmidt/cgi-sig.html" --> </p> -</body> -</html> diff --git a/TAO/docs/releasenotes.html b/TAO/docs/releasenotes.html deleted file mode 100644 index 03f1b5b2c73..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="releasenotes/index.html">here</a>. - -</HTML> diff --git a/TAO/docs/releasenotes/FT_FaultAnalyzerFramework.jpg b/TAO/docs/releasenotes/FT_FaultAnalyzerFramework.jpg Binary files differdeleted file mode 100755 index 5c8e872788a..00000000000 --- a/TAO/docs/releasenotes/FT_FaultAnalyzerFramework.jpg +++ /dev/null diff --git a/TAO/docs/releasenotes/FT_PrototypeArchitecture.jpg b/TAO/docs/releasenotes/FT_PrototypeArchitecture.jpg Binary files differdeleted file mode 100755 index a2f62a4ae8b..00000000000 --- a/TAO/docs/releasenotes/FT_PrototypeArchitecture.jpg +++ /dev/null diff --git a/TAO/docs/releasenotes/OBV.html b/TAO/docs/releasenotes/OBV.html deleted file mode 100644 index 6320b983ab1..00000000000 --- a/TAO/docs/releasenotes/OBV.html +++ /dev/null @@ -1,134 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> -<body text="#000000" bgcolor="#FFFFFF"> - - <head> - <title>Object-by-Value status</title> - <!-- $Id$ --> - </head> - - <body> - <center> - <h1><a name="orb"></a>Objects-by-Value</h1> - Points of contact: <a href="mailto: parsons@cs.wustl.edu">Jeff Parsons</a> - <a href="mailto: bosk@ipmce.ru">Boris Kolpackov</a> - <a href="mailto:g.edwards@vanderbilt.edu">George Edwards</a> - - <p>Last Update: 2004/08/24 </p> - </center> - - <p>Objects-by-Value (OBV) describes the new type, <CODE>valuetype</CODE>, introduced in CORBA 2.3 - <br>(Core: - <a href="http://www.omg.org/cgi-bin/apps/doc?formal/02-12-06.pdf">formal/02-12-06.pdf</a>; Mapping to C++: - <a href="http://www.omg.org/cgi-bin/apps/doc?formal/03-06-03.pdf">formal/03-06-03.pdf</a>). - <p>The original TAO implementation was contributed by - <a href="mailto: kuepper2@uni-wuppertal.de">Torsten Kuepper</a>, and has subsequently been enhanced and corrected by <a href="mailto: parsons@cs.wustl.edu">Jeff Parsons</a> and <a href="mailto:g.edwards@vanderbilt.edu">George Edwards</a>. - <p><CODE>Valuetype</CODE>s are similar to IDL <CODE>struct</CODE>s extended with - these capabilities: - <ul> - <li><p>Encapsulate both state information and operations in an implementation that is guaranteed to be local.</p> - </li> - - <li><p>Can be declared <CODE>abstract</CODE>, in which case no state members are defined.</p> - </li> -<li><p>Can inherit from a single concrete <CODE>valuetype</CODE> and multiple <CODE>abstract valuetype</CODE>s.</p></li> -<li><p>Can support a single concrete <CODE>interface</CODE>, allowing them to be manipulated as either a valuetype or an object reference.</p></li> -<li><p>Can support multiple <CODE>abstract interface</CODE>s, allowing them to be substituted for those interfaces in operation invocations.</p></li> - <li><p>Can hold references to other <CODE>valuetype</CODE>s, with the - possibility of NULL references or shared (aliased) references.</p> - </li> - </ul> - -<p>Valuetypes have the following uses: -<UL> -<li><p>Implement abstract datatypes (ADTs) that can be copied to another process.</p></li> -<li><p>Represent <CODE>eventtype</CODE>s in the Event Service.</p></li> -<li><p>Ensure operations are executed locally for increased performance.</p></li> -</UL> - <a name="current"><h3>Current status:</h3></a> - - <ul> - <li><p>The IDL compiler understands <CODE>valuetype</CODE>. - Relevant option of TAO's IDL compiler is: <P> - <UL> - <LI>-Wb,obv_opt_accessor Make accessor and modifier functions inline. - Overriding them is not allowed in this mode.</LI> - </UL></P> - <p></p> - </li> - <li><p><CODE>Valuetype</CODE>s can be used as arguments in CORBA invocations. - There is an example in - <A HREF="../../examples/OBV/Typed_Events">$TAO_ROOT/TAO/examples/OBV/Typed_Events</A>. - <CODE>Valuetype</CODE>s can reference other - <CODE>valuetype</CODE> objects (but without sharing). - </p> - </li> - <li> - <p>Support for valuetypes as members of IDL aggregate types has been - added.</p> - </li> - <li> - <p>Support for inheritance from a concrete interface (<CODE>supports</CODE>) has been added. There is an example in <A HREF="../../tests/OBV/Supports">$TAO_ROOT/TAO/tests/OBV/Supports</A>.</p> - </li> -<li> -<p>Support for inheritance from abstract interfaces has been added. There is an example in <A HREF="../../tests/Abstract_Interface">$TAO_ROOT/TAO/tests/Abstract_Interface</A>.</p> - <li> - <p>Support for forward declared valuetypes defined in another compilation - unit has been added. See <A HREF="../../examples/OBV/Typed_Events">$TAO_ROOT/TAO/examples/OBV/Typed_Events</A>.</p> - </li> -<li> -<p>Support for recursively-defined valuetypes has been added. See <A HREF="../../tests/OBV/Supports">$TAO_ROOT/TAO/tests/OBV/Supports</A>.</p> -</li> -<li> -<p>Support for user-declared factories has been added. See <A HREF="../../tests/OBV/Factory">$TAO_ROOT/TAO/tests/OBV/Factory</A>.</p> -</li> - </ul> - - <a name="issues"><h3>Known issues:</h3></a> - - <ul> - <li><p><CODE>Valuetype</CODE>s work only in conjunction with - compiled marshaling (<CODE>-Gc</CODE>, currently default for - <CODE>tao_idl</CODE>). - </p> - </li> - - <li><p>No support for sharing (aliasing). - </p> - </li> - - <li><p>No support for <CODE>valuebox</CODE>es - </p> - </li> -<li> -<p> -No support for <CODE>valuetype</CODE>s with cyclic references.</p></li> - - <li><p>No support for fragmentation (chunking) of the marshalled - <CODE>valuetype</CODE> object. Hence no support for truncation or - custom marshalling.</p> - </li> - - <li><p>The marshal engine accesses the state members directly and - does not utilize the accessor/modifier functions. This is different - from the CORBA specs and needs to be changed. But the - optimized mode (<CODE>-Wb,obv_opt_accessor</CODE>) should be - unaffected by that. - </p> - </li> - - <li><p>The map of <CODE>valuetype</CODE> factories needs some - revision to provide proper locking. Currently the - registration of factories is best completed before - unmarshalling <CODE>valuetype</CODE>s. - There is one map of factories for the whole process. This - will once be changed to conform to the specs, which - suggests one per ORB. - </p> - </li> - </ul> - - <P><HR><P> - <a href="#toc">Back to TOC</a> - </body> -</html> diff --git a/TAO/docs/releasenotes/PSS.html b/TAO/docs/releasenotes/PSS.html deleted file mode 100644 index 3f44535a1b4..00000000000 --- a/TAO/docs/releasenotes/PSS.html +++ /dev/null @@ -1,82 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> -<body text="#000000" bgcolor="#FFFFFF"> - - <head> - <title>Persistent State Service status</title> - <!-- $Id$ --> - </head> - - <body> - <center> - <h1><a name="orb"></a>Persistent State Service</h1> - Points of contact: <a href="mailto: gontla_p@ociweb.com">Priyanka Gontla</a> - - <p>Last Update: 2002/07/29 </p> - </center> - - <p>Persistent State Service (PSS) desribes a way of making a - service persistent. The fact that PSS is being used by a - service is known only to the service (server) and not to the - client which makes use of the service. PSS presents persistent - information as storage objects stored in storage homes, to - quote the specification. The storage homes are the datastores - where the persistent data is saved. </p> - <br> - <p>The specification introduced Persistent State Definition - Language (PSDL), a superset of IDL with five new - constructs. PSDL is used to specify the interface to the - datastore. The PSDL file used in the application will define - the types that might be saved in the datastore. </p> - <br> - <p>We have a compiler, psdl_tao, which is similar to the tao_idl - compiler, which will process the psdl file and generate stubs - that are used mainly for the insertion and extraction - operations. - </p> - - <a name="current"><h3>Current status:</h3></a> - - <ul> - <li><p>The PSDL compiler understands and supports the simple - types like <br><CODE> - typdef, module, structures, interfaces.</CODE> - </p> - </li> - <li> - <p> The datastore for now is a regular file. The - <CODE>libTAO_PSDL_Datastore</CODE> interfaces the - datastore and helps write and read from the datastore. - The data that is saved persistently is a hash map whose - external id is TAO_PSDL_String, a wrapper around - ACE_CString and the internal id is TAO_PSDL_OctetSeq, a - wrapper around for CORBA::OctetSeq. </p> - </li> - <li> - <p> There is an example in - $ACE_ROOT/TAO/orbsvcs/examples/PSS which shows how the PSS - can be used to make a simplified naming service persistent. - </p> - </li> - </ul> - - <a name="future"><h3>Future work:</h3></a> - - <ul> - <li> - <p>Add support to the remaining types defined in PSDL. - </p> - </li> - - <li> - <p>Use RMCast to have another form of persistency via data - replication. - </p> - </li> - - </ul> - - <P><HR><P> - <a href="#toc">Back to TOC</a> - </body> -</html> diff --git a/TAO/docs/releasenotes/RTCorba.html b/TAO/docs/releasenotes/RTCorba.html deleted file mode 100644 index 0607c76936e..00000000000 --- a/TAO/docs/releasenotes/RTCorba.html +++ /dev/null @@ -1,354 +0,0 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -<html> - -<head> -<title>RT CORBA</title> -</head> - -<body> -<!-- $Id$ --> -<h1 align="center">Real-Time CORBA</h1> -<p align="center"><i>Last Update October 4, 2000</i></p> -<p align="left">This documents keeps track of the TAO's <a href="#RT Corba Development Status">Real-Time CORBA Development Status</a> , and a description of the <a href="#Release Notes">Release -Notes</a> for our implementation. For any comment or question on a specific aspect of RT CORBA you can contact the responsible as listed in the <a href="#RT Corba Development Status">Real-Time CORBA Development Status</a>, -or you can contact one of us: <a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a>, <a href="mailto:irfan@cs.wustl.edu">Irfan - Pyrali</a>, <a href="mailto:corsaro@cs.wustl.edu">Angelo - Corsaro</a>.</p> -<h1 align="center"><a name="RT Corba Development Status">RT Corba Development Status</a></h1> -<p>The scope of this brief document is to keep track of the progress of the -RT-CORBA implementation, and to let the user understand what is already in place -what will be soon available and what will not be supported. <a href="#Table 1 - Status of the feature described in the RT CORBA Spec.">Table -1</a> contains a detailed list of the features that are described by the RT-CORBA -spec. and their status respect to our implementation. <a href="#Table 2 - Feature needed to Enable RT-CORBA">Table -2</a> contains features that are not described in the RT-CORBA spec. but -that are needed to "enable" our RT-CORBA implementation, and at last <a href="#Table 3 - Issue to be shortly addressed">Table -3</a> contains a list of issues that should be addressed soon.</p> -<p> - </p> -<p style="margin-left: 0; margin-right: 0; margin-top: 0; margin-bottom: 5" align="center"><b><a name="Table 1 - Status of the feature described in the RT CORBA Spec.">Table -1 -</a></b><a name="Table 1 - Status of the feature described in the RT CORBA Spec."> -Status of the feature described in the RT CORBA Spec. </a></p> -<div align="center"> - <center> - <table border="1" width="663" height="216"> - <tr> - <td width="236" align="center" height="19"><b>Feature</b></td> - <td width="151" align="center" height="19"><b>Reference</b></td> - <td width="115" align="center" height="19"><b>Status</b></td> - <td width="133" align="center" height="19"><b> Contact</b></td> - </tr> - <tr> - <td width="236" align="center" height="1">Real-Time ORB</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.1</td> - <td width="115" align="center" height="1">Done</td> - <td width="133" align="center" height="1"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="16">Real-Time POA</td> - <td width="151" align="center" height="16">ptc/99-05-03 sec. 4.2</td> - <td width="115" align="center" height="16">Done</td> - <td width="133" align="center" height="16"><a href="mailto:irfan@cs.wustl.edu">Irfan - Pyrali</a></td> - </tr> - <tr> - <td width="236" align="center" height="38">CORBA Priority & Priority - Mappings</td> - <td width="151" align="center" height="38"> - <p align="center">ptc/99-05-03 sec. 4.4, sec. 4.5</td> - <td width="115" align="center" height="38">Done </td> - <td width="133" align="center" height="38"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="19">Real-Time Current</td> - <td width="151" align="center" height="19">ptc/99-05-03 sec. 4.6</td> - <td width="115" align="center" height="19">Done</td> - <td width="133" align="center" height="19"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="19">Real-Time CORBA Priority Models</td> - <td width="151" align="center" height="19">ptc/99-05-03 sec. 4.7</td> - <td width="115" align="center" height="19">Done</td> - <td width="133" align="center" height="19"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Priority Transforms</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.8</td> - <td width="115" align="center" height="1">Not Supported </td> - <td width="133" align="center" height="1">-</td> - </tr> - <tr> - <td width="236" align="center" height="1">Mutex Interface</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.9</td> - <td width="115" align="center" height="1">Not Supported </td> - <td width="133" align="center" height="1">-</td> - </tr> - <tr> - <td width="236" align="center" height="1">Thread Pools</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.10</td> - <td width="115" align="center" height="1">Due - ???</td> - <td width="133" align="center" height="1"><a href="mailto:irfan@cs.wustl.edu">Irfan - Pyrali</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Implicit & Explicit Binding</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.11</td> - <td width="115" align="center" height="1">Due Oct. 13 2K</td> - <td width="133" align="center" height="1"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Priority Banded Connections</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.12</td> - <td width="115" align="center" height="1">Done</td> - <td width="133" align="center" height="1"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Private Connection Policy</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.13</td> - <td width="115" align="center" height="1">Due Oct. 13 2K</td> - <td width="133" align="center" height="1"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Protocol Configuration</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.15</td> - <td width="115" align="center" height="1">Done</td> - <td width="133" align="center" height="1"><a href="mailto:marina@cs.wustl.edu">Marina - Spivak</a></td> - </tr> - </table> - </center> -</div> -<p> </p> -<p><b>Real-Time ORB - </b>Extension to the CORBA::ORB interface that provides operations to create and destroy other constituents of a RT ORB.</p> -<p><b>Real Time POA </b><b> - </b>RT extension of the traditional POA that -provides additional operation to support object level priority and -"understand" the RT Policies defined in ptc/99-05-03. This interface -is derived from the POA interface so it support all the semantics prescribed for -a non RT-POA. </p> -<p><b>CORBA Priority & Priority Mappings - </b>RT-CORBA Priority have the -intent of shielding the user from the different priority scheme that a RTOS -might use, providing a uniform representation system wide. RT-CORBA Priority -Mappings take care of mapping RTCORBA::Priority into native priorities. Right -now to scheme are implemented and respectively the <i>Linear</i> and <i>Direct</i>.</p> -<p><b>Real-Time Current - </b> The RTCORBA::Current interface is derived from -CORBA::Current, and provide access to the CORBA Priority of the current thread. -Real Time CORBA Priority can be associated with the current thread by using this -interface.</p> -<p><b>Real-Time CORBA Priority Models - </b>Real-Time CORBA supports two models -for the coordination of priorities across a system, that let set the priority at -which a servant executes. This two different model are <i>Client Propagated -Priority Model</i> and <i>Server Declared Priority Model</i>.<i> </i></p> -<p><b>Priority Transforms - </b>Priority Transforms allow the application -designer to implement RT-CORBA system using priority models different from -either the Client Propagated or Server Declared. Priority Transforms are user -provided functions that map one RTCORBA::Priority value to another -RTCORBA::Priority value.</p> -<p><b>Mutex Interface - </b>Real-Time CORBA defines a Mutex interface, and two operation in the RTORB interface for creating and destroying such mutex. This mutex -should have the same priority inheritance scheme used by the ORB.</p> -<p><b>Thread Pools - </b>Real-Time CORBA define an interface for creating -Thread Pools, with or without lanes, and for creating Thread Pools Priorities. -Lanes are just sub-sets of threads at assigned different RTCORBA::Priority -values. The only feature that won't be supported is the <i>Request Buffering</i> -(see sec. 4.10.3).</p> -<p><b>Implicit & Explicit Binding - </b>Provide control on when a binding is -made on a object reference. In particular a call to <font face="Courier New">validate_connection -</font>force the binding to an object reference to be made as <i>explicit -binding</i>.</p> -<p><b> Priority Banded Connections - </b>Real-Time CORBA defines priority -bands that are in turn used to serve request depending on the priority model -used by the target object.</p> -<p><b>Private Connection Policy - </b>This policy allows a client to obtain a -private transport connection which will not be shared with other client-server -connections.</p> -<p><b>Protocol Configuration - </b>Enables the selection and configuration of -the protocols on the client and server side of the ORB.</p> -<p align="center" style="margin-bottom: 5"><a name="Table 2 - Feature needed to Enable RT-CORBA">Table -2 - Feature needed to Enable RT-CORBA</a></p> -<div align="center"> - <center> - <table border="1" width="663" height="122"> - <tr> - <td width="236" align="center" height="19"><b>Feature</b></td> - <td width="151" align="center" height="19"><b>Reference</b></td> - <td width="115" align="center" height="19"><b>Status</b></td> - <td width="133" align="center" height="19"><b> Contact</b></td> - </tr> - <tr> - <td width="236" align="center" height="16">Collocation</td> - <td width="151" align="center" height="16">Not yet available</td> - <td width="115" align="center" height="16">Done</td> - <td width="133" align="center" height="16"><a href="mailto:corsaro@cs.wustl.edu">Angelo - Corsaro</a></td> - </tr> - <tr> - <td width="236" align="center" height="14">Policy Streaming</td> - <td width="151" align="center" height="14">ptc/99-05-03 orbos/98-05-05</td> - <td width="115" align="center" height="14">Done</td> - <td width="133" align="center" height="14"><a href="mailto:corsaro@cs.wustl.edu">Angelo - Corsaro</a></td> - </tr> - <tr> - <td width="236" align="center" height="1">Invocation Timeout</td> - <td width="151" align="center" height="1">ptc/99-05-03 sec. 4.14 orbos/98-05-05</td> - <td width="115" align="center" height="1">Done</td> - <td width="133" align="center" height="1"><a href="mailto:coryan@ece.uci.edu">Carlos O'Ryan</a></td> - </tr> - </table> - </center> -</div> -<p align="center"> </p> -<p><b>Collocation - </b>A new collocation scheme has been designed and is in its -last stage of development. The collocation scheme has been changed because the -selection of the right proxy to use to perform a call, now has to be taken on a -call-per-call basis, to avoid interference between thread priorities. In -designing the new scheme we tried to reduce the memory footprint and the -overhead that the new scheme needs to introduce.</p> - -<p><b>Policy Streaming - </b>Different policies defined by the RT-CORBA Spec. -need to be exposed to the client by embeddeding those into the IOR. -This facilities were added to those policies.</p> - -<p><b>Invocation Timeout - </b>Allows the setting of timeout that expire if an invocation doesn't complete in a given amount of time.</p> - -<p> </p> -<p> </p> -<p align="center" style="margin-bottom: 5"><a name="Table 3 - Issue to be shortly addressed">Table -3 - Issue to be shortly addressed</a></p> -<div align="center"> - <center> - <table border="1" width="546" height="77"> - <tr> - <td width="126" align="center" height="19"><b>Issue</b></td> - <td width="152" align="center" height="19"><b>Status</b></td> - <td width="89" align="center" height="19"><b> Contact</b></td> - </tr> - <tr> - <td width="126" align="center" height="1"> - <p align="center">Factoring of TAO's Protocol Policies</td> - <td width="152" align="center" height="1">???</td> - <td width="89" align="center" height="1">???</td> - </tr> - <tr> - <td width="126" align="center" height="1">Profile Mangement</td> - <td width="152" align="center" height="1">???</td> - <td width="89" align="center" height="1">???</td> - </tr> - <tr> - <td width="126" align="center" height="1">RT CORBA Example/Test</td> - <td width="152" align="center" height="1">???</td> - <td width="89" align="center" height="1">???</td> - </tr> - <tr> - <td width="126" align="center" height="1">RT-TAO Performance</td> - <td width="152" align="center" height="1">???</td> - <td width="89" align="center" height="1">???</td> - </tr> - </table> - </center> -</div> -<p align="left"> </p> -<p align="left"><b>Factoring of TAO's Protocol Policies -</b></p> -<p align="left"><b>Profile Management - </b>The Profile management is right now -quite nasty. The class interface are pretty counter-intuitive, and the code that -deal with profile needs to be redesigned and re-implemented.</p> -<p align="left"><b>RT CORBA Example Test - </b>Examples and Tests need to be -written to show how to use RT CORBA's features, and to massively test the -behavior of the new stuff.</p> -<p align="left"><b>Performance - </b>Performance tests needs to performed on TAO -to see the impact of the changes and to early individuate critical path and -bottlenecks.</p> -<p align="left"> </p> - -<h1 align="center"><a name="Release Notes">Release Notes</a></h1> -<p>We are currently working on implementing RT CORBA 1.0 specification in TAO. Our design is an extension of the <em>endpoint-per-priority</em> architecture mentioned in the <tt>Recently -Completed Work</tt> section below. In this design, codenamed <em>reactor-per-lane</em>, each threadpool lane owns a set of I/O resources, i.e., <tt>Reactor</tt>, <tt>Acceptor</tt>, -and <tt>Connector_Registry.</tt> Each request is serviced by a single thread without context switches, i.e., the same thread performs I/O and runs the servant code. -<p>Below there is a list of feature recently added to TAO, and in also a brief description of the main feature that characterize certain feature related to our implementation of -RT-CORBA.</p> -<ul> - <li> - <p style="line-height: 150%">Client Protocol Policy. - <li> - <p style="line-height: 150%">Priority Banded Connections. - <li> - <p style="line-height: 150%">TAO's RTCORBA Documentation web pages. - <li> - <p style="line-height: 150%">POA Threadpools & SERVER_DECLARED Priority Model.</li> - <li> - <p style="line-height: 150%">CLIENT_PROPAGATED Priority Model.</li> - <li> - <p style="line-height: 150%">Server Protocol Policy. - <li> - <p style="line-height: 150%">RTORB, RTCurrent and ProrityMappingManger interfaces. - <li> - <p style="line-height: 150%">Support for client-exposed policies. - <li> - <p style="line-height: 150%">All RTCORBA, Policy and POA interfaces converted to local. - <li> - <p style="line-height: 150%">Collocation-related classes are restructured to support RTCORBA. - <li> - <p style="line-height: 150%">Implemented Policy framework (defined in the Messaging specification, used in RT CORBA). - <li> - <p style="line-height: 150%">Added support for Real-time CORBA Priority and implemented two Priority Mappings: <tt>Linear</tt> and <tt>Direct</tt>. - <li> - <p style="line-height: 100%">Added support for end-to-end CORBA request priority preservation. This is achieved through <em>multiple listening endpoint</em> architecture, a.k.a. <em>endpoint-per-priority</em>, - on the server and a Client Priority Policy on the client. Following is a brief description of how this is implemented. - <p style="line-height: 100%">Server ORB uses multiple transport endpoints to accept connections from clients. Each transport endpoint has a priority, which is the priority of the - thread(s) servicing the endpoint as well as all connections it accepts. When a server ORB creates an IOR for one of its objects, it embeds all of the server's listening endpoints - along with their priorities into the object's IOR. Then, a client ORB selects the priority that best matches client's need (as specified by the Client Priority Policy) from those - offered by the server, and uses the corresponding transport endpoint specified by the server to obtain the desired level of service. - <p style="line-height: 100%">For more details and performance results for <em>endpoint-per-priority</em> architecture, see <a href="http://www.cs.wustl.edu/~marina/boeing.pdf">this - paper.</a> See <tt>TAO/tao/TAO.pidl</tt> for Client Priority Policy interface definition, and <tt>TAO/tests/Endpoint_Per_Priority</tt> for example of using priority preservation - in TAO. - <p style="line-height: 100%"> - <li> - <p style="line-height: 100%">Implemented reliable one-way requests, i.e., SyncScope Policy from the Messaging specification. This is relevant to RT CORBA because of the following - feature: setting SyncScope Policy to SYNC_NONE enables buffering of one-way requests in the client ORB. Request buffering can be used to optimize message throughput, possibly at - the expense of latency. ORB buffering behavior is controlled by the Buffering Constraint Policy, which is described next. -</ul> -<p style="line-height: 100%"> -<ul> - <li> - <p style="line-height: 100%">Added support for buffered one-way and asynchronous requests in the client ORB. Buffering Constraint Policy gives users control over queueing and - flushing of requests in the ORB. A combination of the following conditions for initiating buffer flush can be specified using this policy: - <ul> - <li> - <p style="line-height: 100%">Timeout value expires. - <li> - <p style="line-height: 100%">Max byte count is exceeded. - <li> - <p style="line-height: 100%">Explicit flush by the user. - <li> - <p style="line-height: 100%">Max message count is exceeded, or - <li> - <p style="line-height: 100%">ORB shutdown.</li> - </ul> - <p style="line-height: 100%">Also supported are out-of-band requests, i.e., requests that bypass buffers and are delivered to the server immediately. - <p style="line-height: 100%">Buffering Constraint Policy is a TAO-specific feature. See <tt>TAO/tao/TAO.pidl</tt> for policy interface definition and <tt>TAO/examples/Buffered_Oneways</tt> - and <tt>TAO/examples/Buffered_AMI</tt> directories for its use. For motivation and performance of buffered one-ways see <a href="http://www.cs.wustl.edu/~marina/boeing.pdf">this - paper.</a></p> - </li> -</ul> -<p style="line-height: 100%">Known issues: -<ul> - <li> - <p style="line-height: 100%">Location forwarding does not work properly with <em>endpoint-per-priority</em> model.</li> -</ul> -<p style="line-height: 100%">Future work: -<ul> - <li> - <p style="line-height: 100%">Provide server-side RT CORBA implementation using a <em>queue-per-lane</em> approach. In this approach each threadpool lane owns a queue, while I/O - resources are being shared among all the threadpool lanes of the same priority within the server. Strategize TAO to use either <em>queue-per-lane</em> or <em>reactor-per-lane</em> - implementation, and compare the two.</li> -</ul> - -</body> - -</html> diff --git a/TAO/docs/releasenotes/TODO.html b/TAO/docs/releasenotes/TODO.html deleted file mode 100644 index 317cb064820..00000000000 --- a/TAO/docs/releasenotes/TODO.html +++ /dev/null @@ -1,28 +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> - We used to keep a TODO list for TAO here, - but we are using - <A HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi"> - Bugzilla - </A> now. - </P> - <P> - Last Updated: $Date$ $Revision$ - </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/amh.html b/TAO/docs/releasenotes/amh.html deleted file mode 100644 index 6d6084a438e..00000000000 --- a/TAO/docs/releasenotes/amh.html +++ /dev/null @@ -1,105 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> - <title>AMH Status</title> - <!-- $Id$ --> -</head> -<body bgcolor="#FFFFFF" text="#000000"> - -<h3>TAO's Asynchronous Method Handling (AMH) Feature</h3> - Point of contact: <a href="mailto:coryan@uci.edu">Carlos O'Ryan, </a> - <a href="mailto:mayur@ics.uci.edu">Mayur Deshpande</a> - <h4>Last Updated: $Date$</h4> - - <p> The purpose of this document is to provide a guide to using the AMH -capability available in TAO. This capability is not specified by any -CORBA specification (as of date). This document lists the motivation for AMH, -how to use it and its current implementation status. </p> - -<HR SIZE=4 WIDTH="100%"> - - -<h3>Context</h3> -For many types of distributed systems, the CORBA asynchronous method -invocation -<a href="index.html/#ami"> (AMI) </a> -mechanism can improve concurrency, scalability, and -responsiveness significantly. AMI allows clients to invoke multiple -two-way requests without waiting for responses. The time normally -spent waiting for replies can therefore be used to perform other -useful work. The TAO asynchronous method handling (AMH) is a -mechanism, which extends the concepts of AMI from clients to -servers. Servers with AMH capability can return immediately -from (potentially) long, blocking requests. This makes the -servers capable of higher throughput. For a detailed description -for the motivation and potential use-cases of AMH, please refer to -<a href="http://www.cs.wustl.edu/~schmidt/PDF/AMH.pdf">AMH-Motivation. </a> - -<HR SIZE=4 WIDTH="100%"> - - -<h3>Using AMH</h3> -Servers that want to take advantage of AMH capability must use -AMH-servants derived from AMH-skeletons. Invoking the -<a href="index.html#idl">IDL-Compiler </a> -with the "-GH" option causes the IDL-Compiler to generate -AMH-skeletons for all interfaces in the ".idl" file. The signatures -of the AMH-methods differ from the original interfaces as per the -rules described in -<a href="http://www.cs.wustl.edu/~schmidt/PDF/DOA-02.pdf"">AMH-In-Detail. </a> -Servants derived from the AMH-skeletons are registered with the POA in the usual manner -and appear to clients as "normal" servants for the corresponding -interfaces; Thus even while being transparent to the client, these -servants are now capable of handling requests asynchronously. -AMH-servants can be registered in any POA and can intermix with -"normal" servants in the same POA. The granularity of AMH is at -the interface level and not at the method level; Thus for an interface -compiled with the "-GH" option, all operations in that interface are -asynchronous. Currently, AMH doesn't work in conjunction with -<a href="index.html#interceptor">Interceptors </a> -and behaviour is undefined if both are used together. - -<HR SIZE=4 WIDTH="100%"> - - -<h3>Current Status</h3> -<b>(As of March 3rd, 2002)</b> -<br> -<P> -<b>Completed:</b> -<ul> -<li>Changes to ORB for asynchronous upcalls.</li> -<li>Generation of AMH-skeletons.</li> -<li>Generation of AMH ResponseHandlers.</li> -<li>AMH Exceptions.</li> -<li>Fix the narrow method bug for AMH skeletons : Fixed -<li>Sending intelligent exception codes back to client in case -something nasty happens in the AMH server.</li> -<li>Example of using AMH available at ACE_wrappers/TAO/examples/AMH/Sink_Server.</li> -<li>Test for AMH : ACE_wrappers/TAO/performance-tests/Latency/AMH</li> -<li>Test for AMH Exceptions : ACE_wrappers/TAO/tests/AMH_Exceptions</li> -</ul> -</P> - -<HR SIZE=4 WIDTH="100%"> - - -<h3>Credits</h3> -Original idea first proposed by -<a href="mailto:coryan@uci.edu">Carlos O'Ryan </a> -and changes to ORB for AMH first attempted by -<a href="mailto:brucetrask@aol.com">Bruce Trask. </a> -First go to get the IDL-Compiler to generate AMH code attempted by -<a href="mailto:brunsch@doc.ece.uci.edu"> Darrell Brunsch. </a> -ORB changes for AMH as they stand today put in by -<a href="mailto:mayur@ics.uci.edu">Mayur Deshpande. </a> -Second go at getting IDL-compiler to generate code attempted by Mayur and -<a href="mailto:parsons@cs.wustl.edu">Jeff Parsons. </a> -Getting the IDL-Compiler beast to generate the right AMH code finally -achieved by Carlos. - -<HR SIZE=4 WIDTH="100%"> - - -</body> -</html> diff --git a/TAO/docs/releasenotes/ec.html b/TAO/docs/releasenotes/ec.html deleted file mode 100644 index 34311012efe..00000000000 --- a/TAO/docs/releasenotes/ec.html +++ /dev/null @@ -1,277 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<HTML> -<HEAD> - <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:jwillemsen@remedy.nl">Johnny Willemsen</A> - <H4>Last Updated: $Date$</H4> - - Documentation for the command line and service configurator - options used to configure the real-time event service is available <A - HREF="../ec_options.html">here</A>. - - -<H3>New on this release</H3> - - <UL> - <LI><P>The consumer/supplier control can be controlled better, interval - and timeout can be configured. - </P> - </LI> - <LI><P>At the moment a consumer is connected it can be controlled when the - connection from the EC to the consumer is created, this can be directly - at the first connect or with the first push. - </P> - </LI> - <LI><P>The IIOP Gateway has been expanded with several options to control - its behaviour. - </P> - </LI> - <LI><P>The implementation of the multicast gateway has been improved. - </P> - </LI> - </UL> - -<H3>Known issues:</H3> - - <DL> - <DT><I>The new EC does not use the scheduling service</I> - </DT> - <DD> - <P>The new implementation has been designed to simplify its use - in applications that do not require an scheduling service and - to minimize the code footprint when the scheduling service is - only required for dispatching - </P> - <P>To achieve this goals the EC will able to run without any - scheduling service or only consulting the schedule, but not - updating the dependencies. - </P> - <P>Using strategies and factories we will be able to - configure the EC to update the schedule only in the - configurations that required. - Unfortunately this features have not been implemented yet. - </P> - </DD> - - <DT><I>Further details:</I></DT> - - <DD><P>Many lower level issues and tasks can be found in the - <A HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi"> - DOC Center Bugzilla webpage - </A>. - </P> - </DD> - </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>. -As in: -<P><TT>$ cd $TAO_ROOT/orbsvcs</TT> -<P><TT>$ cd Naming_Service ; ./Naming_Service &</TT> -<P><TT>$ cd Event_Service ; ./Event_Service &</TT> -<P><TT>$ cd tests/Event_Latency ; ./Event_Latency -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>The copy-on-write semantics has been supported for a - while now. - </P> - </LI> - <LI><P>The event service library has been divided in several - smaller libraries, so applications only link the required - components. - The base code for the Event Service is located in the - <CODE>TAO_RTEvent</CODE> library. - <CODE>TAO_RTOLDEvent</CODE> contains the old implementation - for the real-time Event Service, - in addition to this the <CODE>TAO_RTSchedEvent</CODE> - contains the components that will support scheduling in the - new Event Service. - This means that applications using only the - <CODE>TAO_RTEvent</CODE> library do not need to link the - scheduling service. - </P> - </LI> - <LI><P>More details can be found on the <CODE>README</CODE> file - in the <CODE>$TAO_ROOT/orbsvcs/orbsvcs/Event</CODE> - directory. - </P> - </LI> - <LI><P>Add strategies to remove unresponsive or dead consumers - and/or suppliers - </P> - </LI> - <LI><P>Lots of bug fixes since the last time this releases notes - where updated. - </P> - </LI> - <LI><P>In this release the EC supports atomic updates of - subscriptions and publications. In previous versions events - could be lost during an update of the subscription list. - </P> - </LI> - <LI><P>The internal data structures in the event channel have - been strategized, for example, it is possible to use - RB-trees instead of ordered lists. The benefits are small - at this stage. - </P> - </LI> - <LI><P>New implementation of the serialization protocols. The - new version is based on "internal iterators" (aka Worker). - This implementation can support copy-on-read (already - implemented) and copy-on-write (in progress). - </P> - </LI> - <LI><P>The new EC allows the suppliers and consumers to update - their publications and subscriptions, they can simply call - the corresponding <CODE>connect</CODE> operation. - The default EC configuration disallows this, but it is very - easy to change it. - </P> - </LI> - <LI><P>The new EC uses an abstract factory to build its - strategies, this factory can be dynamically loaded using the - service configurator. - </P> - </LI> - <LI><P>The new EC can use trivial filters for both consumers and - suppliers, resulting in optimal performance for broadcasters. - </P> - </LI> - <LI><P>Most of the locks on the new EC are strategized. - </P> - </LI> - <LI><P>The duration of all locks in the EC can be bounded, - resulting in very predictable behavior. - </P> - </LI> - - <LI><P>Added fragmentation and reassembly support for the multicast - gateways</P> - </LI> - -<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 marshaling or late dermarhaling 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/ftcorba_services.html b/TAO/docs/releasenotes/ftcorba_services.html deleted file mode 100755 index 2ad37756b77..00000000000 --- a/TAO/docs/releasenotes/ftcorba_services.html +++ /dev/null @@ -1,627 +0,0 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -<!-- $Id$ --> -<html> -<head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="Author" content="Steve Totten"> - <title>Fault Tolerant (FT) CORBA Services</title> -</head> -<body> - -<center> - -<h2>Fault Tolerant (FT) CORBA Services</h2></center> - -<p> -Points of contact: <a href="mailto:wilson_d@ociweb.com">Dale - Wilson</a> and <a href="mailto:totten_s@ociweb.com">Steve Totten</a> -</p> - -<p> -<ul> - <li><a href="#Introduction">Introduction</a></li> - <li> - <a href="#FTCORBA_Services">FT CORBA Services</a> - <ul> - <li><a href="#Replication_Manager">Replication Manager</a></li> - <li><a href="#Fault_Notifier">Fault Notifier</a></li> - <li><a href="#Fault_Detector">Fault Detector</a></li> - <li><a href="#Fault_Detector_Factory">Fault Detector Factory</a></li> - <li><a href="#Redundancy">Redundancy of FT CORBA Infrastructure - Services</a></li> - </ul> - </li> - <li> - <a href="#Sample_FT_Application">Sample FT Application</a> - <ul> - <li><a href="#Replica_Factory">Replica Factory</a></li> - <li><a href="#Replica">Replica</a></li> - <li><a href="#Object_Group_Creator">Object Group Creator</a></li> - <li><a href="#Client">Client</a></li> - <li><a href="#Prototype_Architecture">Prototype Architecture</a></li> - </ul> - </li> - <li><a href="#Propagating_IOGRs">Propagating IOGRs</a></li> - <li><a href="#IOGR_Creation_Manipulation">IOGR Creation and - Manipulation</a></li> - <li><a href="#Bootstrapping">Bootstrapping of FT CORBA - Infrastructure and Application</a></li> - <li><a href="#Future_Work">Future Work</a></li> -</ul> -</p> - -<h3><a name="Introduction"></a>Introduction</h3> - -<p> -Object Computing, Inc. (OCI) and the Distributed Object Computing -(DOC) group at Vanderbilt University's Institute for Software -Intensive Systems (ISIS) collaborated on a research and development -(R&D) effort to demonstrate the viability of the OMG FT CORBA -specification (defined in Chapter 23 of the <a - href="http://www.omg.org/cgi-bin/doc?formal/02-12-02">CORBA 3.0 - specification</a>), with some extensions, as a platform for building -fault-tolerant DRE applications. -</p> - -<p> -The OCI team designed, implemented, and tested FT service-level -entities and other components needed to support an FT infrastructure -in TAO, and a sample application to demonstrate TAO's FT capabilities. -The ISIS team provided enhancements to TAO's ORB Core to support fault -tolerance in applications, including implementing ORB-core-level -features defined in the FT CORBA specification. -</p> - -<p> -Extensions to the FT CORBA specification investigated during the -project included: -<ol> - <li>Adding a <code>SEMI_ACTIVE</code> replication style similar to - that described <a - href="http://www.cs.wustl.edu/~schmidt/PDF/WDMS02.pdf">here</a>.</li> - <li>Separating interfaces and type definitions that are common - across multiple specifications into a Portable Group module as - described in the <a - href="http://www.omg.org/cgi-bin/doc?ptc/01-11-09">OMG Data - Parallel Processing specification</a> and the <a - href="http://www.omg.org/cgi-bin/doc?ptc/01-11-08">Unreliable - Multicast Inter-ORB Protocol specification</a></li> - <li>Adding factory registration and a fault detector factory - interfaces.</li> - <li>Adding mechanisms for bootstrapping FT CORBA systems.</li> - <li>Defining protocols for operating between the ORB core and FT - services.</li> -</ol> - -<h3><a name="FTCORBA_Services"></a>FT CORBA Services</h3> - -<h4><a name="Replication_Manager"></a>Replication Manager</h4> - -<p> -The Replication Manager is perhaps the most visible of FT CORBA's -infrastructure components. Fault tolerant services interact with the -replication manager to create object groups, manage an object group's -properties, control an object group's membership, and so forth. The -Replication Manager is also solely responsible for the creation and -maintenance of Interoperable Object Group References (IOGRs). -According to the FT CORBA specification, the Replication Manager's -operations are defined by three separate interfaces: -</p> - -<ul> - <li><em>Property Manager</em>: Defines operations for setting - properties, such as replication style, at several levels: by group, - by type, or by default.</li> - <li><em>Object Group Manager</em>: Defines operations to add and - remove members of an object group, change the primary member of an - object group (for passive replication styles only), specify or get - the locations of object group members, and get the current object - group reference and object group identifier.</li> - <li><em>Generic Factory</em>: Defines operations for creating and - destroying objects. The replication manager's realization of these - interfaces effect the creation and destruction of object groups. - These operations are also realized by application specific object - factories to create and destroy replicas as object groups are - created and maintained.</li> -</ul> - -<p> -<em> -Note: The Data Parallel (DP) CORBA final adopted specification defines -a new <code>PortableGroup</code> module, including the three -interfaces listed above, to share common interfaces and their -supporting types among DP CORBA, FT CORBA, Load Balancing, and other -specifications. It is identical to a subset of the FT CORBA -specification with a few changes to make it more generic to group -management. TAO already has an implementation of the PortableGroup -module that we adapted for reuse by the Replication Manager's -implementation for this project. -</em> -</p> - -<p> -In addition, the Replication Manager serves the role of a consumer for -fault report events propagated to it via the Fault Notifier, so it -must realize the Structured Push Consumer interface from the -CosNotifyComm module (defined in the <a - href="http://www.omg.org/cgi-bin/doc?formal/02-08-04">OMG's - Notification Service specification (formal/02-08-04)</a>. Our -design provides a <em>Fault Consumer/Analyzer framework</em> and -concrete fault consumer and fault analyzer implementations that are -tailored for use by the Replication Manager. The classes making up -this framework, and the relationships among them, are shown in the -figure below. -</p> - -<center> -<p> -<a name="FT_FaultAnalyzerFramework"></a> <img -src="FT_FaultAnalyzerFramework.jpg" alt="Fault Consumer/Analyzer -Framework" title="Fault Consumer/Analyzer Framework"></img> -</p> -<h4>Figure 1: Fault Consumer/Analyzer Framework</h4> -</center> - - -<p> -The OCI team also added a <em>Factory Registry</em> interface that is -also realized by the Replication Manager to allow various types of -factories, such as Replica Factories and Fault Detector Factories (all -of which implement the Generic Factory interface) to register with the -Replication Manager. The Replication Manager then uses these -factories when necessary to add members (replicas) to object groups or -to create a new Fault Detector at a specific location to monitor a -replica. -</p> - -<p> -The Replication Manager's interfaces are defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_ReplicationManager.idl">FT_ReplicationManager.idl</a>. -The Replication Manager also supports interfaces and types from the -PortableGroup module that is defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/PortableGroup.idl">PortableGroup.idl</a> -and additional interfaces and types from the FT module that is defined -in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_CORBA.idl">FT_CORBA.idl</a>. -Source code for the Replication Manager's implementation is found in -the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/FT_ReplicationManager/">FT_ReplicationManager</a> -directory. -</p> - -<h4><a name="Fault_Notifier"></a>Fault Notifier</h4> - -<p> -FT CORBA's Fault Notifier is based upon a subset of the <a - href="http://www.omg.org/cgi-bin/doc?formal/02-08-04">OMG's - Notification Service specification (formal/02-08-04)</a>. The Fault -Notifier typically gathers fault reports from Fault Detectors as well -as from application- or platform-specific fault detectors. -</p> - -<p> -The Fault Notifier can support an arbitrary number of Fault Detectors -and consumers because it is based upon the Notification Service. -Components interested in receiving fault reports assume the role of -push consumer with respect to the Fault Notifier. The Replication -Manager is one such component, as described above; an application may -provide its own fault analysis capability by connecting an -application-specific fault analyzer as a consumer to the Fault -Notifier. (In fact, a real-world application will likely participate -intimately in identifying and analyzing faults. One way this could be -done is to "plug-in" an application-specific fault analyzer to the -Replication Manager, using the <a - href="#FT_FaultAnalyzerFramework">Fault Consumer/Analyzer - framework</a> described above.) -</p> - -<p> -The Fault Notifier's interfaces are defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_Notifier.idl">FT_Notifier.idl</a>. -Source code for the Fault Notifier's implementation is found in the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/Fault_Notifier/">Fault_Notifier</a> -directory. -</p> - - -<h4><a name="Fault_Detector"></a>Fault Detector</h4> - -<p> -The Fault Detector is the basic component in FT CORBA for monitoring a -fault tolerant system's software components, processes, and processing -nodes and reporting faults. The FT CORBA specification defines a -single monitoring style, the <em>pull</em> monitoring style, in which -a Fault Detector periodically issues a CORBA request -(<code>is_alive</code>) to monitored objects and reports faults for -those objects that fail to respond. A fault detector that monitors a -single replica may be co-located on the same host as that replica. If -the replica fails (defined as failure to reply to the detector's -<code>is_alive</code> invocation within a prescribed time-out period), -the detector issues a fault report to the Fault Notifier, which it -finds via the Replication Manager. In our example application, the -detector then exits since the replica that it was monitoring no longer -exists. Fault detectors can also be deployed on other nodes and used -to monitor other FT CORBA infrastructure components, such as a Fault -Detector or Fault Detector Factory on another host. The pull -monitoring style is used to monitor these components as well. -</p> - -<h4><a name="Fault_Detector_Factory"></a>Fault Detector Factory</h4> - -<p> -Fault Detectors are created and managed by a Fault Detector Factory. -There may be many Fault Detector Factories deployed in a typical fault -tolerant system. The Fault Detector Factory implements the Generic -Factory interface. -</p> - -<p> -Fault Detectors are created in the same process as their Fault -Detector Factory. Each Fault Detector runs in its own thread and -monitors its replica according to its prescribed monitoring interval -(defined by a property on the object group). The Fault Detector -Factory owns the thread manager for these threads. If a replica -member is removed from an object group, the Fault Detector Factory -that "owns" the Fault Detector that is monitoring that replica can -cause the detector to "quit," thereby causing it to clean up any -resources and its thread to exit. -</p> - -<p> -Fault Detector Factories register with the Replication Manager via the -Factory Registry interface. The Replication Manager then uses these -Fault Detector Factories to create new Fault Detectors as needed to -monitor replicas as they are created. -</p> - -<p> -The Fault Detector Factory's interfaces are defined in -<a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_FaultDetectorFactory.idl">FT_FaultDetectorFactory.idl</a>. Source code for the -Fault Detector and Fault Detector Factory implementations is found in -the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/Fault_Detector/">Fault_Detector</a> directory. -</p> - -<h4><a name="Redundancy"></a>Redundancy of FT CORBA Infrastructure Services</h4> - -<p> -To achieve fault tolerance, a system must not have a single point of -failure. This includes not only application services, but -infrastructure services as well. In the case of this project, the -following FT infrastructure services need to be made fault tolerant -via redundancy: -</p> - -<ul> - <li>Replication Manager</li> - <li>Fault Notifier</li> - <li>Fault Detector Factories</li> - <li>Replica Factories</li> -</ul> - -<p> -<em> -One of the initial goals of this project was to provide redundant -implementations of each of these services after first providing basic -non-redundant implementations. Unfortunately, due to complexities -encountered during implementation and the relatively short time frame -for the project, we did not complete development of redundant versions -of the various FT infrastructure services. We encourage this to be -given a high priority for any follow-on work. -</em> -</p> - -<p> -Note that making the Replication Manager redundant will require direct access to the lower-level state synchronization mechanism (i.e., via a synchronization strategy) while other FT infrastructure services can likely be made fault tolerant using the full range of FT CORBA mechanisms. -</p> - - -<h3><a name="Sample_FT_Application"></a>Sample FT Application</h3> - -<h4><a name="Replica_Factory"></a>Replica Factory</h4> - -<p> -A Replica Factory is an application-defined entity that implements the -Generic Factory interface. There may be many Replica Factories -deployed in a typical fault tolerant application. Each Replica -Factory acts as an agent for the Replication Manager to create and -manage replica members of object groups of a specific type at a -specific location. Replica Factories register with the Replication -Manager via the Factory Registry interface. The Replication Manager -then uses these Replica Factories to create new replicas as needed -when creating object groups or adding new members to existing object -groups. -</p> - -<p> -We have provided a sample implementation of a Replica Factory as part -of our example application for this project. It implements the -Generic Factory interface from the FT module defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_CORBA.idl">FT_CORBA.idl</a>. -Source code for the example application's Replica Factory is found in -the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/tests/FT_App/">FT_App</a> -directory. -</p> - - -<h4><a name="Replica"></a>Replica</h4> - -<p> -A Replica is an application object that serves as a member of an -object group. Each replica implements an application-defined -interface. In addition, each replica must implement the Pull -Monitorable interface so it can be monitored by a Fault Detector. -Replicas are created by Replica Factories by the Replication Manager -or by another application. Each new replica is then added to an -object group and managed by the Replication Manager. -</p> - -<p> -We have provided a sample implementation of a Replica as part of our -example application for this project. A Replica must implement the -<code>PullMonitorable</code>, <code>Checkpointable</code>, and -<code>Updateable</code> interfaces, which are defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/orbsvcs/FT_Replica.idl">FT_Replica.idl</a>. -For our example application, a test replica interface is defined in <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/tests/FT_App/FT_TestReplica.idl">FT_App/FT_TestReplica.idl</a>. -The implementation of the test replica is also in the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/tests/FT_App/">FT_App</a> -directory. -</p> - -<h4><a name="Object_Group_Creator"></a>Object Group Creator</h4> - -<p> -The Object Group Creator is a utility for creating an object group. -It can be used by an application to create an initial set of objects -in a system. The Object Group Creator finds the Replication Manager -and uses its Factory Registry interface to get a list of factories it -can use to create objects of the desired type. The Object Group -Creator can be used in different ways depending upon if the object -group's <code>MembershipStyle</code> property value is -application-controlled membership or infrastructure-controlled -membership. -</p> - -<ul> - <li>Application-controlled membership: If application-controlled - membership is being used, the Object Group Creator calls the - Replication Manager to create an empty object group, then calls the - factories to create members for the group. Members are added via - the Replication Manager's <code>add_member</code> operation.</li> - - <li>Infrastructure-controlled membership: If - infrastructure-controlled membership is being used, and the object - creator is configured to set factories at the type level, the object - creator optionally passes the set of factories to the - <code>set_type_properties</code> operation of the Replication - Manager, then calls Replication Manager's <code>create_object</code> - operation to create an object group.</li> -</ul> - -<p> -After creating the object group, the Object Group Creator can -optionally write the group's IOGR to a file or bind it in the Naming -Service so it can be accessed by clients. -</p> - -<p> -The Object Group Creator can exist as a stand-alone utility or it can -be integrated with an application. Our example application includes -an implementation of the Object Group Creator in the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/tests/FT_App/">FT_App</a> -directory. -</p> - - -<h4><a name="Client"></a>Client</h4> - -<p> -A client application obtains the object group reference from a file or -from the Naming Service and invokes operations on it as it would a -normal IOR. In the <code>SEMI_ACTIVE</code> replication style, only the primary -replica receives and processes each request. The state -synchronization strategy developed by the ISIS team for this project -is used synchronize state between the primary and backup replicas with -the completion of each request. If the primary replica fails, the -transparent reinvocation mechanism inherent in the FT ORB (also -developed by the ISIS team) causes the client's failed request to be -automatically reinvoked on a backup replica. Meanwhile, the fault -detection mechanisms described above are used to notify the -Replication Manager of the fault and the Replication Manager takes the -necessary actions to maintain the object group's integrity. Our -example application includes a simple client in the <a - href="http://cvs.doc.wustl.edu/viewcvs.cgi/*checkout*/TAO/orbsvcs/tests/FT_App/">FT_App</a> -directory. -</p> - -<h4><a name="Prototype_Architecture"></a>Prototype Architecture</h4> - -<p> -The figure below shows the architecture of a prototypical FT system -and the relationships among the various FT infrastructure and -application-defined components described above. -</p> - -<center> -<p> -<a name="FT_PrototypeArchitecture"></a> <img -src="FT_PrototypeArchitecture.jpg" alt="Architecture of Prototypical FT System" title="Architecture of Prototypical FT System"></img> -</p> -<h4>Figure 2: Architecture of Prototypical FT System</h4> -</center> - -<p> -The steps involved in orderly start-up and operation of an FT system -are numbered in Figure 2 and described below: -</p> - -<ol> - <li>Start the Naming Service. (This step is optional as none of the - FT components actually depends upon the Naming Service.)</li> - <li>Start the Replication Manager.</li> - <li>Start the Fault Notifier.</li> - <li>The Fault Notifier finds the Replication Manager and registers - with it.</li> - <li>The Replication Manager connects as a consumer to the Fault - Notifier.</li> - <li>Start one or more Fault Detector Factories.</li> - <li>The Fault Detector Factories register with the Replication Manager's Factory Registry.</li> - <li>Start one or more Replica Factories.</li> - <li>The Replica Factories register with the Replication Manager's Factory Registry.</li> - <li>Start the Object Group Creator.</li> - <li>(not shown) The Object Group Creator finds the Replication Manager and gets a list of Fault Detector Factories for the Replication Manager's Factory Registry.</li> - <li>(not shown) The Object Group Creator gets a list of Replica Factories from the Replication Manager's Factory Registry.</li> - <li>The Object Group Creator creates an object group via the Replication Manager's Generic Factory interface.</li> - <li>The Object Group Creator creates one or more Replicas via Replica Factories.</li> - <li>Each Replica Factory creates a Replica.</li> - <li>The Object Group Creator creates a Fault Detector for each Replica via the Fault Detector Factories.</li> - <li>Each Fault Detector Factory creates a Fault Detector for a Replica.</li> - <li>Each Fault Detector finds the Replication Manager and gets the Fault Notifier from the Replication Manager.</li> - <li>Each Fault Detector connects as a supplier to the Fault Notifier.</li> - <li>The Object Group Creator adds each Replica as a member to the object group via the Replication Manager's Object Group Manager interface.</li> - <li>The Replication Manager generates a new IOGR for each added Replica and updates each Replica member of the object group with the new IOGR.</li> - <li>The Object Group Creator optionally binds the IOGR of the object group with the Naming Service or publishes its IOGR in some other way, such as a file.</li> - <li>Start a Client.</li> - <li>The Client optionally resolves the object group by name from the Naming Service or resolves it in some other way, such as from a file or via a corbaloc ObjectURL.</li> - <li>The Client invokes a request on the object group. This request is carried out by the primary Replica of the object group.</li> - <li>Each Fault Detector periodically pings its Replica via the Replica's PullMonitorable interface.</li> - <li>If a Replica fails, the Fault Detector pushes a structured fault report to the Fault Notifier.</li> - <li>The Fault Notifier pushes the structured fault report as an event to the Replication Manager's consumer.</li> - <li>(not shown) The Replication Manager removes the failed member from the object group, selects a new primary for the object group, generates a new IOGR, and updates each Replica member of the object group with the new IOGR.</li> - <li>(not shown) The Replication Manager may also add new members to the object group if the number of replicas has fallen below the object group's MinimumNumberReplicas property. When it adds new members, the Replication Manager also generates a new IOGR and updates each Replica member of the object group with the new IOGR.</li> -</ol> - - -<h3><a name="Propagating_IOGRs"></a>Propagating IOGRs</h3> - -<p> -The FT CORBA specification requires the Replication Manager to create -and maintain IOGRs. It also requires the FT ORB to perform -<em>most-recent IOGR</em> processing, whereby the FT ORB can update a -client using an old IOGR, by means of a <code>LOCATION_FORWARD</code> -reply, with a new IOGR. However, the specification fails to define a -way for the Replication Manager to propagate revised IOGRs to the FT -ORBs of object group members. Therefore, the OCI and ISIS teams -agreed upon a simple interface (<code>tao_update_iogr</code>) by which -the Replication Manager can propagate revised IOGRs to the FT ORB for -each member of an object group (e.g., after failure of a primary -replica, selection of a new primary member, and generation of a new -IOGR by the Replication Manager). While this interface is -TAO-specific, it accomplishes one of our research goals of -investigating formal protocols by which different ORB implementations -of FT CORBA could be made interoperable. The ISIS team implemented -this interface and the OCI team incorporated its use within the -Replication Manager. -</p> - -<h3><a name="IOGR_Creation_Manipulation"></a>IOGR Creation and - Manipulation</h3> - -<p> -To support FT CORBA, the Replication Manager must be able to create -and manipulate IOGRs. For example, the Replication Manager's -realization of the Generic Factory interface must return an IOGR. -Also, upon receiving a fault report on an object group, the -Replication Manager may need to remove a member, designate a member as -the new primary replica, and generate a new IOGR that can then be -propagated to each member of the object group. -</p> - -<p> -For the purposes of this project, we used TAO's existing -IORManipulation library for creating and managing IOGRs. However, the -IORManipulation library lacked certain features that were needed. We -worked with the ISIS team to define extensions to the IORManipulation -library to: -</p> - -<ul> - <li>Support the creation of "empty" IORs that have no profiles.</li> - <li>Support the complete replacement of all the profiles in an -IOR.</li> - <li>Support the addition of the following tagged components:</li> - <ul> - <li>TAG_MULTIPLE_COMPONENTS</li> - <li>TAG_GROUP</li> - <li>TAG_FT_PRIMARY</li> - </ul> -</ul> - -<p> -<em> -While the IORManipulation library can be used to create and manipulate -IOGRs, a longer term approach may be to use a specialized -implementation of the Object Reference Template and IORInterceptor -abstractions defined in sections 21.5.3 and 21.5.4 of the <a - href="http://www.omg.org/cgi-bin/doc?formal/02-12-02">CORBA 3.0 - specification</a>, respectively. -</em> -</p> - -<h3><a name="Bootstrapping"></a>Bootstrapping of FT CORBA Infrastructure and Application</h3> - -<p> -FT CORBA infrastructure and application components must collaborate to -achieve fault tolerance. To do so, infrastructure and application -components must be started and initial objects and object groups -created in an orderly fashion. Much of this "bootstrapping" can be -accomplished by scripting. However, an entity to control the creation -of initial objects and object groups can greatly simplify certain -aspects of the bootstrapping process. -</p> - -<p> -The sample application provided as part of this project uses an Object -Group Creator utility to create initial objects and object groups. -The Object Group Creator is implemented as a library that can be -easily integrated with other parts of an application. A simple -wrapper is also provided allowing the Object Group Creator to be used -as a stand-alone executable. -</p> - -<h3><a name="Future_Work"></a>Future Work</h3> - -<p> -During the course of this research, we uncovered several areas for -further research and development, including: -</p> - -<ul> - <li>Adding redundancy to the FT infrastructure services.</li> - <li>Extending FT support to additional platforms, such as the - VxWorks RTOS.</li> - <li>Incorporating FT capabilities into an advanced application, - such as TAO's RT Notification Service, or Naming - Service.</li> - <li> Integrating the <a href="ftrt_ec.html"> FT RT Event Service </a> - with FT Services. The current implementation of FT RT Event - Service in TAO is not based on the FT Services implemented - by OCI because they are developed independently. - </li> - <li>Investigating improvements to the mechanisms used to detect - faults in replicated application objects.</li> - <li>Investigating advanced fault analysis capabilities and - mechanisms by which application- or platform-specific fault - analyzers to be "plugged" into the Replication Manager or other - components.</li> - <li>Investigating formal protocols that will allow interoperability - among different ORB implementations of FT CORBA.</li> - <li>Refactoring of the Replication Manager and Portable Group - implementations to consolidate the representation of object - groups.</li> - <li>Employing standard mechanisms, such as Object Reference Template - and IORInterceptors, instead of the TAO-specific IORManipulation - library, for the creation and manipulation of IOGRs.</li> - <li>Investigating performance and scalability issues in FT - systems.</li> - <li>Enabling the configuration and enforcement of FT quality of - service (QoS) properties, such as bounds on fault detection and - recovery times.</li> -</ul> - -</body> -</html> - diff --git a/TAO/docs/releasenotes/ftrt_ec.html b/TAO/docs/releasenotes/ftrt_ec.html deleted file mode 100644 index 1a398627da9..00000000000 --- a/TAO/docs/releasenotes/ftrt_ec.html +++ /dev/null @@ -1,238 +0,0 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -<!-- $Id$ --> -<html> -<head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="Author" content="Venkita Subramonian"> - <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]"> - <title>Fault Tolerant Real-Time Event Service</title> -</head> -<body> - -<center> -<h2> -Fault Tolerant Real-time Event Service</h2></center> - -<h3> -Introduction</h3> -The Fault Tolerant Real-time Event Service provides the fault tolerant -capability to the TAO Real-time Event Service. Essentially, it allows you -to start several event services in different machines. These event services -form an object group which can be treated as a logical event service by -clients. The clients only communicate with the primary (leader) of the -object group. The rest event channels in the object group are called backups. -Once the primary dies, one of the backups will assume the reponsibility -of primary and this process is transparent to the clients. -<p>The key to provide fault tolerance to event channels is to replicate -the states of primary to its backups. There are two kinds of states in -the event channels, transient and persistent. A transient state in the -event channels is the events which are yet to be delivered to the consumers. -Those events are hard to replicate because the time scale is too small. -They might be delivered late or out of scope if we tried to replicate the -events. However, the subscription information occurs at a suitable -time scale for replication, and is in fact more essential for the delivery -of events since it establishes a kind of connectivity from suppliers to -consumers. Therefore, we only replicate the subscriptions -<p>Once the primary receives the subscription requests from the clients, -it will replicate the requests to the backup event channels.In order to -provide time bounds on replication, we introduce the concept of transaction -depth. If we say the transaction depth is n, that means a subscription -method invocation has to be blocked until the first n replicas complete -the subscription operation, illustrated by the assured-replicate arc in -the figure. Other replicas can get the state change via a so called soft-replicate -which conceptually means the replication is not assured to complete before -the subscription operation returns. So, if the soft-replicate fails -due to loss of the primary, we will have only the assured depth of replication. -The clients are allowed to configure the transaction depth to tradeoff -reliability and responsiveness. Furthermore, it is necessary to roll back -an operation in some replicas if the transaction depth can not be met. -In addition, we can use either two-way or AMI calls for assured-replication -and one-way operations for soft-replication. -<p><b><font color="#FF6666">Important Note</font> :</b> In current stage, -the Fault Tolerant Event Service can only be made under <a href="../../../bin/MakeProjectCreator/README">MPC</a> build. The -conventional makefiles are yet to be supported. In other words, you should -use $ACE_ROOT/bin/mwc.pl to generate makefiles for ACE and TAO before you can -build it. See <a href="../../../bin/MakeProjectCreator/USAGE">here</a> for the instruction of using mwc.pl. -<br> -<h3> -Programs</h3> -There are serveral programs in $TAO_ROOT/orbsvcs/FTRT_Event_Servce directory: -<p>ftrt_eventservice : Located under $TAO_ROOT/orbsvcs/FTRT_Event_Servce/Event_Service -directory. It implements the functionality of fault tolerant event -channel. It can be started directly or be started by the ftrtec_factory_service. -<p>ftrtec_factory_service : Located under $TAO_ROOT/orbsvcs/FTRT_Event_Servce/Factory_Service -directory. It is a program used to spawn the ftrt_eventservice -process. The process it create can be controled through "test.cfg" whose -contents should begin with the repository id of EventChannel followed by -the executable path of ftrt_eventservice. -<p>ftrtec_gateway_service : Located under $TAO_ROOT/orbsvcs/FTRT_Event_Servce/Gateway_Service -directory. It is an intermediator program between the ftrt_eventservice -and the clients which do not support FT CORBA. -<p>consumer : A shell script to start the consumer test program. The actual -consumer pragram is in $TAO_ROOT/orbsvcs/tests/FtRtEvent. -<p>supplier : A shell script to start the supplier test program. The actual -supplier pragram is in $TAO_ROOT/orbsvcs/orbsvcs/tests/FtRtEvent. -<p>ftec : a shell script to start ftrt_eventservice. -<br> -<h3> -Quick start:</h3> - Run the applications as follows: -<br> -<p> 1. Start Naming_Service -<p> -<br> $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1 -<br> or you can use the shell script NameService -in this directory to start it. -<p> 2. Start the ftrt_eventservice. Use the "-p" option to start -it as a primary and -<br> use the "-j" option to start it as a backup. -<p> $ cd $TAO_ROOT/orbsvcs/FTRT_Event_Service -<br> $ ./ftec -p -<br> $ ./ftec -j -<br> $ ./ftec -j -<br> -<p> 3. Start the consumer and supplier. -<p> $ ./consumer -<br> $ ./supplier -<br> -<h3> -How do we add a new FTRTEC to the system?</h3> - Just use -<p> ./ftec -j -<p> The newly created process will contact to the naming service -and then join to -<br> the existing object group. -<br> -<h3> -Is there any adjustable options for FTRTEC?</h3> - Here is the list of options for the ftec script -<p> -sciop -Use SCIOP for CORBA communication -<br> -sctp -Use SCTP for fault detection -<br> -hb n -Specify the heart beat interval in sec -<br> -for SCTP connection, this option also activate sctp option. -<br> -ami -Use AMI call for replication messages (The default is -<br> -two-way CORBA call for replication) -<br> -p -activate as a primary replica. -<br> -j -activate as a backup replica. -<br> -<p> Below are some options that are used for the consumer and supplier -<br> test scripts. -<p> -sciop -Use SCIOP for CORBA communication. This requires that the Naming -<br> -Service and ftec are also started using SCIOP transport protocol. -<p> -d n -Specify the transaction depth. The transaction depth indicates the -<br> -number of replicas that must complete the subscription request before -<br> -the request can return. -<p> -t f.f -For supplier only. Specify the time interval between event sending -<br> -in seconds, this value should be a float point. -<p> If you the naming service are not running at the same machine -with above programs, you can always set the environmental variables NameServiceIOR -before starting the ftec, consumer or supplier. -<br> -<h3> -How do I start the FTRTEC using ftrtec_factory_service?</h3> -The ftrtec_factory_service is a small program that can instaniate a ftrt_eventservice -on demand. It exports the FT::GenericFactory interface to its client. There -are two ways that you can get the IOR for the factory object. 1) -specify the name you want the factory register to the naming service -and then get the IOR from the naming service by the name. 2) output the -IOR to a file when the factory starts. Here are the options -<p> ftrtec_factory_service : -<p> -i id_string -The id field of the name that is used to register to the naming service -<br> -k kind_string -The kind field of the name that is used to register to the naming service -<br> -o output_filename -The output file name for the factory IOR. -<p>Once you get the IOR for the factory, you can use create_object to intantiate -the ftrt_eventservice. -<br>Here are the parameters in create_object() to control how ftrt_eventservice -is created. -<p> type_id : this value should be "IDL:FtRtecEventChannelAdmin/EventChannel:1.0" -<br> the_criteria : the_criteria is a sequence of Property -which in term consists of "nam" and "value". Below a a list of possible -nam and values. -<br> -<br> -<table BORDER COLS=2 WIDTH="100%" > -<tr> -<td>nam</td> - -<td>value</td> -</tr> - -<tr> -<td>FTEC_MEMBERSHIP</td> - -<td>PRIMARY -<br>BACKUP -<br>NONE</td> -</tr> - -<tr> -<td>FTEC_DETECTOR_TRANSPORT_PROTOCL</td> - -<td>TCP -<br>SCTP</td> -</tr> - -<tr> -<td>FTEC_HEART_BEAT</td> - -<td>the heart beat value in sec. (Note, you have to specify it using string, -i.e. the_criteria[0].value <<= "5");</td> -</tr> - -<tr> -<td>FTEC_REPLICATION_STRATEGY</td> - -<td>AMI -<br>(If not specified, the ftrt_eventservice use default two-way call for -replication) -<br> </td> -</tr> - -<tr> -<td>NameServieIOR</td> - -<td>the corbaloc representation for the naming service -<br> </td> -</tr> -</table> - -<p> Any nam string started with "-" will be used as a command line -option to start ftrt_eventservice. For example, if you specfiy the name -as "-ORBEndpoint" and value as "sciop://" then the ftrt_eventservice can -be started using sciop. -<br> -<h3> -How do I use the ftrtec_gateway_service program ?</h3> -The FTRTEC uses some features in FT CORBA that requires every client to -use FT ORB to work. If your client is written based other ORBs other -than TAO. You cannot get the desired fault tolerance feature. In this case -you can have the ftec_gateway as an intermediator between the FTRTEC and -you client program. -<br>For example, if you have an existing client called my_supplier. -<p> # setting up the event channel group as previously -stated. -<p> $ftrtec_gateway_service -o gateway.ior -## start the gateway and output the IOR of the gateway to a file -<br> $my_supplier -i file://gateway.ior ## start -the supplier using the gateway -<br> -</body> -</html> diff --git a/TAO/docs/releasenotes/index.html b/TAO/docs/releasenotes/index.html deleted file mode 100644 index 6bc88f7be11..00000000000 --- a/TAO/docs/releasenotes/index.html +++ /dev/null @@ -1,2539 +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.79 [en] (Windows NT 5.0; U) [Netscape]"> - <title>TAO Release Information and TODO List</title> -</head> -<body text="#000000" bgcolor="#FFFFFF"> -<!-- $Id$ --> -<center> -<hr></center> - -<center> -<h3> -Release Information for The ACE ORB (TAO)</h3></center> -This document contains information on the following topics related to the -<a href="../../VERSION">current -release</a> of <a href="http://www.dre.vanderbilt.edu/TAO">TAO</a>: - -<table BORDER=0 CELLSPACING=0 CELLPADDING=10 > -<tr> -<td VALIGN=TOP> -<b>ACE Related</b> -<br> -<ul> -<li> -<a href="#ace">ORB-related ACE Changes</a></li> -</ul> -</td> -<td VALIGN=TOP> - -<b>Misc Entries</b> -<br> -<ul> - -<li> -<a href="#CORBA-conformance">CORBA Standards Conformance</a></li> - - -<li> -<a href="#dove">The DOVE Demo</a></li> - -<li> -<a href="TODO.html">TODO list</a></li> -</ul> -</td> - -</table> - -<table BORDER=0 CELLSPACING=0 CELLPADDING=10 > -<tr> -<td VALIGN=TOP> -<b>ORB Related</b> -<br> -<ul> -<li> -<a href="amh.html">Asynchronous Method Handling (AMH)</a></li> - -<li> -<a href="#ami">Asynchronous Method Invocation (AMI)</a></li> - -<li> -<a href="#csd">Custom Servant Dispatching (CSD)</a></li> - -<li> -<a href="../dynany/index.html">Dynamic Any</a></li> - -<li> -<a href="#leader">Global Resources and Leader-Follower Model</a></li> - -<li> -<a href="#idl">IDL Compiler</a></li> - -<li> -<a href="../implrepo/index.html">Implementation Repository</a></li> - -<li> -<a href="../interfacerepo/index.html">Interface Repository</a></li> - -<li> -<a href="#localobject">Local Interfaces</a></li> - -<li> -<a href="#locate">Locate requests</a></li> -<li> -<a href="#forwarding">Location Forwarding</a></li> - - - -<li> -<a href="#miop">Multicast InterORB Protocol (MIOP)</a></li> - -<li> -<a href="orbcore.html">ORB Core</a></li> - -<li> -<a href="OBV.html">Object-by-Value</a></li> - -<li> -<a href="../poa_migration.html">POA Migration Notes</a></li> - - -<li> -<a href="#pp">Pluggable Protocols</a></li> - -<li> -<a href="#interceptor">Portable Interceptors</a></li> - -<li> -<a href="#poa">Portable Object Adapter (POA)</a></li> - - -<li> -<a href="../rtcorba/index.html">Real-Time CORBA</a></li> - -<li> -<a href="#sciop">SCIOP Support in TAO</a></li> - -<li> -<a href="#ipv6">IPv6 Support in TAO</a></li> - -<li> -<a href="../Smart_Proxies.html">Smart Proxies</a></li> -</ul> -<td VALIGN=TOP> -<b>CORBA Services Related</b> -<br> -<ul> -<li> -<a href="#av">Audio/Video Streaming Service</a></li> -<li> -<a href="#cservices">Concurrency Service</a></li> -<li> Event Service -<ul> -<li> -<a href="#ec">CORBA Event Service</a></li> -<li> -<a href="ftrt_ec.html">Fault_Tolerant/Real_Time Event Service</a></li> -<li> -<a href="ec.html">Real-time Event Service</a></li> -</ul> - -<li> -<a href="#fault_tolerance">Fault Tolerant Services </a></li> - -<li> -<a href="#loadbalancer">Load Balancer Service</a></li> - - -<li> -<a href="#nservices">Naming Service </a></li> -<li> -Notification Service -<ul> -<li> -<a href="#notify">Notification Service</a></li> -<li> -<a href="#rt_notify">Real-Time Notification Service</a></li> -</ul> -<li> -<a href="PSS.html">Persistent State Service</a></li> -<li> -<a href="#pservices">Property Service</a></li> -<li>Scheduling Service -<ul> -<li> -<a href="#scheduling">Kokyu Scheduling Service</a></li> -<li> -<a href="rtc10_sched.html">RTCORBA 1.0 Scheduling Service</a></li> -</ul> - -<li> -<a href="#security">Security Service</a></li> - -<li> -<a href="#log">Telecom Log Service</a></li> -<li> -<a href="#ts">Time Service</a></li> -<li> -<a href="#tservices">Trading Service</a></li> - - - -</ul> -</td> - -<td VALIGN=TOP> -<ul> -<b>CCM Related</b> -<br><BR> -<li> -<a href="../../CIAO/docs/releasenotes/index.html">CORBA Component Model (CIAO)</a></li> -<li> -<a href="../../CIAO/docs/releasenotes/dance.html">Deployment and - Configuration Engine (DAnCE)</a></li> -<li> -<a href="../../CIAO/CIDLC/README.html">Component Implementation -Definition Language Compiler (CIDLC)</a></li> -<li> -<a href="../../CIAO/docs/static_ciao_contents.html">Static Configuration - Support for Real-Time Platforms</a></li> -</ul> -</td> - -<td VALIGN=TOP> -</td> -</tr> -</table> - - -<table BORDER=0 CELLSPACING=0 CELLPADDING=10 > -<tr> - - -</table> - - -A complete list of all modifications to TAO is available in the <a href="../../ChangeLog">ChangeLog</a>. -<p> -<hr> -<h3> -<a NAME="ace"></a>ACE Wrappers</h3> -Current status: (As of July 07, 2003.) -<ul> -<li> -The following changes are related to improving memory management of Event -Handlers when they interact with Reactors (and Timer Queues). When a handler -is registered with the Reactor, the Reactor increments the reference count -on the handler. The Reactor also increments this reference count when making -upcalls on the handler. The reference count is decremented when an upcall -completes or when the handler is removed from the Reactor.</li> - -<p>This mechanism is similar to what happens between POAs and Servants -and it allows for the safe deletion of handlers. This mechanism is particularly -need for multi-threaded applications that can have multiple threads executing -upcalls on a handler that needs to be shutdown in a safe manner. The following -illustrates an example of how this mechanism works: -<ul> -<li> -When a handler is created, it reference count is one.</li> - -<li> -After the handler is registered with the Reactor, it reference count becomes -two.</li> - -<li> -At this point, the handler creator can let go of the handler reference, -bringing down the reference count to one.</li> - -<li> -For each thread executing upcalls on the handler, the Reactor increments -the reference count by one. So if three threads were simultaneously making -upcalls on a handler, the reference count would be four.</li> - -<li> -Assuming an external event (and thread) decides to close the handler. It -simply removes the handler from the Reactor. This decreases the reference -count to three.</li> - -<li> -As each thread completes their upcall, the reference reduces.</li> - -<li> -Once the final thread exits the upcall, the reference reaches zero, and -the handler is finally deleted.</li> -</ul> -This mechanism ensures that the handler is not deleted until the final -upcall thread exits the handler. -<p>Reference counting on handlers is optional and is disabled by default. -To enable reference counting on a handler, reset its reference counting -policy to "ENABLED". -<p>To facilitate reference counting of handlers, an ACE_Event_Handler_var -class was added. This class is akin to the PortableServer::ServantBase_var -class. -<p>Similar reference counting related changes were made to the Timer Queues -so that handlers can be used in a thread safe manner with the queues. -<p>The Connector implementation was completely revised to utilize the new -memory management mechanisms and remove existing concurrency bugs. -<p>Several new examples/tests were added: Reference_Counted_Event_Handler_Test, -MT_Reference_Counted_Event_Handler_Test, MT_Reference_Counted_Notify_Test, -Timer_Queue_Reference_Counting_Test, NonBlocking_Conn_Test, Reactor_Registration_Test, -WFMO_Reactor_Test, Timer_Cancellation_Test</ul> - -<hr> -<h3> -<a NAME="idl"></a>IDL Compiler</h3> -Point of contact: <a href="mailto:j.parsons@vanderbilt.edu">Jeff Parsons</a> -<p>Current status: (As of May 4, 2006.) -<ul> -<li> -Generated code closely follows the C++ Mapping specified in the latest -C++ mapping for CORBA 3.0 (Document ptc/03-06-03).</li> - -<li> -IDL compiler is now able to generate code that support native C++ exceptions -on the stubs and skeletons. With this strict mapping, the CORBA::Environment -parameter is no longer generated. The default behavior is to generate code -without the extra parameter on plaforms with native exceptions and with -the extra parameter in platforms without native exceptions. Use the -Ge -flag to override the defaults.</li> - -<li> -We are now able to handle shared case labels and default label in unions. -In addition, whenever appropriate, we are also able to generate the "default -()" operation.</li> - -<li> -We are now able to handle recursive types. We are also able to generate -optimized typecodes.</li> - -<li> -Struct members of type strings and arrays of strings now use the managed -type instead of the _var type. This change was necessary to conform to -the IDL->C++ mapping.</li> - -<li> -Fixed a large number of problems with anonymous arrays and sequences inside -structs and unions. The name of anonymous sequence needs to be fixed as -per latest C++ mapping spec.</li> - -<li> -Compile problems with sequence of forward declared interfaces is fixed. -In addition, problems with sequence of CORBA::Objects is fixed. In this -specific case, we were not generating the _downcast and _upcast methods.</li> - -<li> -Some more problems with the front-end have been fixed. In particular, oneway -operations with a "raises" clause or having an "inout", "out", or "return" -mode is flagged as an error.</li> - -<li> -For platforms that support namespaces, we now allow reopening modules.</li> - -<li> -Support for generating compiled marshaling code is added. Use the -Gc option. -However, this needs thorough testing before we can claim success. Unions -are still a problme with compiled marshaling.</li> - -<li> -The problem of "#include"ing the relative path of the header files rather -than the paths of their corresponding IDL files has been fixed. tao_idl -now generates #include path names that are derived from the IDL files that -are #include'd in the main idl file.</li> - -<li> -Added options to IDL compiler to specify file name endings for the IDL-generated -stubs, skeletons and the various header files. Please refer to the <a href="../compiler.html">IDL -compiler options</a> for details.</li> - -<li> -Verified support for the "long long" and "unsigned long long" datatypes. -On platforms that do not support 64 bit longs we provided <i>partial</i> -emulation through ACE_U_LongLong.</li> - -<li> -Perfect Hashed Operation Lookup Strategy has been added to the IDL Compiler. --P flag to <tt>tao_idl</tt> enables the perfect hased lookup strategy. -This strategy uses <a href="http://www.cs.wustl.edu/~schmidt/gperf.ps.gz">GPERF</a>, -the GNU's Perfect Hash Function Generator written by Dr.Douglas C. Schmidt. -Right now, GPERF works only on Solaris. Any work on porting GPERF to other -platforms will be highly appreciated.</L1></li> - -<li> -The <<= and >>= operators for user-defined types are now generated.</li> - -<li> -Completely redesigned the IDL compiler using the Visitor patterns. Many -incomplete issues have been resolved. These include support for "sequence -of typecodes", passing object references as in, inout, and out parameters. -Code generation for sequences is also properly handled i.e., for a named -sequence such as <tt>typedef sequence<char>CharSeq;</tt>, we now generate -a new class (and hence a type) called "class CharSeq". Arrays are still -being worked out and will be done soon. An important difference in the -generated code is that the skeletons now use a table driven approach very -similar to the stubs.</li> - -<li> -Support for the "native" keyword added.</li> - -<li> -The problem of incorrect code generation for typedefs defined in an imported -file is resolved.</li> - -<li> -Problems when interfaces use single or multiple inheritance solved. The -problem was with the demultiplexing code, the generated operation tables, -and the dispatching mechanism. We are currently testing this with the Event -Channel code.</li> - -<li> -The problems arising due to public virtual inheritance when casting from -an interface class to CORBA::Object_ptr has been solved. We do this casting -inside the stubs/skeletons rather than first converting an interface class -pointer to a void*, storing it in an Any, and casting it to CORBA::Object_ptr -in the encode/decode methods. The casting inside the stubs/skeletons work -because the compiler has knowledge of both types.</li> - -<li> -Include files are handled properly. So are the definitions used inside -the include files that are used in the currently parsed files.</li> - -<li> -Generates C++ stubs and skeletons that use TAO's -<a href="http://www.cs.wustl.edu/~schmidt/HICSS-97.ps.gz"> -interpretive IIOP protocol engine</a>.</li> - -<li> -Support dynamic libraries on NT, i.e., marking classes for DLL export was -added. Two backend options control the name of the export macro, and the -name of an extra include file were the macro is defined; the options are -<tt>-Wp,export_macro=MACRO_NAME-Wp,export_include=INCLUDE_NAME</tt>.</li> - -<li> -The IDL compiler generates now source code for sequences. The user has -now the option to use these generated sequence classes or to use, as up -to now, the template instatiation. If TAO_LACKS_TEMPLATE_SPECIALIZATION -is defined, then template instantiation will be used, else not. The reason -for this was, that some C++ compilers did not support template instantiation -properly and sequences were based on templates. The generated source code -is mainly contained in the generated header file directly in the class -declaration.</li> - -<li> -The IDL Compiler generates templates for servant implementations. The options -are -GI [ h | s | b | e | c ]</li> - -<li> -The IDL compiler generates source code for the management and (de)marshaling -of wide characters and wide strings, enabling the sending and receiving -of Unicode over the wire. However, wide character and wide string literals -are not yet portable to Unix platforms (see entry under Future Work below).</li> - -<li> -Since the CORBA spec requires that all enums be 32 bits, and some compilers -will try to use less space if the enum values are small enough, the IDL -compiler now appends <enum name>_TAO_ENUM_32BIT_ENFORCER = 0xFFFFFFFF -to every enum. This appended enum value is not part of the IDL compiler's -internal representation of the enum, so unions that use the enum as a discriminator -will not have incorrect _default() code generated for them.</li> - -<li> -The IDL compiler generates a C++ ostream operator for IDL exceptions. So -far only the repository ID is output, but this may be enhanced when requirements -and/or desires become clearer.</li> - -<li> -The IDL compiler has support for valuetypes (see release notes -for valuetypes for details). </li> - -<li> -As part of the implementation of interceptors, the TAO IDL compiler now -generates interception points in the client and server, as well as the -prepare_header method in the stubs.</li> - -<li> -Scoping and name resolution rules have changed in CORBA with version 2.3. -The IDL compiler now conforms to these new rules.</li> - -<li> -IDL compiler now supports the CORBA AMI callback model, generating code -for reply handlers and reply stubs if the -GC command line option is used. -The TAO library must be compiled with TAO_HAS_CORBA_MESSAGING = 1. If this -is done, TAO_HAS_AMI_CALLBACK will automatically be defined to 1 as well. -IDL_HAS_VALUETYPE is defined to 1 by default.</li> - -<li> -New command line option -So added to suppress generation of ostream operators -for exceptions.</li> - -<li> -New command line option -Sc added to suppress generation of tie classes -and *S_T.* files. The default is still to generate them.</li> - -<li> -IDL compiler now handles escaped identifiers (CORBA 2.3.1). An identifier -appearing in an IDL file with a leading underscore will appear in generated -code without the underscore. This enables the use of identifiers in generated -code identical to IDL keywords, as specified in CORBA 2.3.1. If the resulting -identifier matches a C++ keyword, "_cxx_" will be prepended in generated -code as before.</li> - -<li> -The -St option to suppress generation of typecodes now also suppresses -the generation of the Any insertion and extraction operators. The extraction -operators require the associated typecode, so the generated code for those -operators would not compile when the -St option was used.</li> - -<li> -Option -Ge 2 added which generates 'throw' instead of ACE_THROW_SPEC, ACE_THROW, -and ACE_RETHROW. Since the expansion of ACE_THROW_RETURN is platform-dependent, -it was left as is. Same for TAO_INTERCEPTOR_THROW, since it sometimes expands -to ACE_THROW_RETURN. Of course ACE_HAS_EXCEPTIONS must be defined for this -option to work.</li> - -<li> -Removed generation of ostream operators for user exceptions, along with -the command line option to suppress this generation. The ostream operator -defined in the base class CORBA::Exception works fine and produces the -same output.</li> - -<li> -The TAO IDL compiler is no longer monolithic. It is composed of a top-level -executable, a front end library and a back end library. This will enable -different back ends to be plugged in for code generation in different languages, -and for IfR administration. Different back ends may require a few changes -to the executable (described below), but the front end library can remain -unchanged. The chain of dependencies is as follows:</li> - -<blockquote>FE : ACE -<br>BE : FE -<br>EXE : FE, BE</blockquote> -Executing the Makefile (or the TAO_IDL Compiler project in the MSVC 'tao_idl' -workspace) will build whatever is required in the proper order, as before. -Back end files, classes and functions required by the executable are as -follows: -<blockquote>be.h - file containing #includes of the major BE file headers. -<br>TAO_Codegen - class, holds output stream references for the various -generated files. -<br>TAO_CODEGEN - ACE_Singleton typedef of the above class. -<br>tao_cg - pointer to instance of TAO_CODEGEN. -<br>be_generator - class, inherits from AST_Generator in FE and generates -AST nodes. -<br>void BE_produce (void) - global function, starts AST traversal for -code generation. -<br>BE_GlobalData - class, holds default/command line arg settings specific -to BE. -<br>be_global - pointer to instance of above class.</blockquote> -All the code in the executable that may need to be modified for different -back ends in contained in the file drv_args.cpp. Code in this file processes -the command line arguments, outputs a usage message, and performs other -miscellaneous BE initialization. -<li> -The IDL compiler can how handle interfaces forward declared in one IDL -file and defined in another. It will handle interfaces that are mutually -dependent across two IDL files, as long as code generated from both IDL -files is included in the same C++ build.</li> - -<li> -Generation of template tie class declarations has been moved from the *S.h -file to the *S_T.h file. The new SunCC 5.2 compiler does not require that -template source code be included in the header file, but it does require -that template declarations and implementations be in the same 'compilation -unit' that is, the same header/source file combination. Generated ifdef -guards prevent the compilation of tie class code if the target platform -does not support namespaces. For such platforms, TAO maps the IDL 'module' -keyword to a class instead of to 'namespace', and C++ does not allow template -class declarations to occur inside another class.</li> - -<li> -IDL compiler can now process multiple IDL files per execution, on all platforms. -A separate process is spawned for each file. IDL files and command line -options may appear in any order on the command line. Any option not starting -with '-' will be treated as a filename.</li> - -<li> -Support for value types has been expanded to include forward declared value -types, sequences of value types, and factory methods. Also, work to support -Anys and type codes for value types is in progress.</li> - -<li> -Support for #pragma prefix has been revamped and improved to be compliant -(the prefix is now cleared when leaving the scope or the included IDL file -where it was defined), and support for #pragma version and #pragma ID has -been added.</li> - -<li> -Support for forward declared structs and unions has been added. In compliance -with CORBA 2.6, such forward declarations must be fully defined in the -same compilation unit, and may be used only in sequence declarations, which -in turn may be used in the declaration of recursive structs and unions. -Use of a forward declared struct or union as an aggregate type member or -as an operation parameter will generat an error message.</li> - -<li> -Support for enum constants has been added.</li> - -<li> -The IDL compiler can now handle concatenation of string literals, for example</li> - -<blockquote>const string foo = "hel" "lo " "the" "re";</blockquote> - -<li> -Support for abstract interfaces has been added.</li> - -<li> -Support for valuetypes has been expanded.</li> - -<ul> -<li> -Forward declared valuetypes not defined in the same compilation unit</li> - -<li> -Type codes for valuetypes</li> - -<li> -Generation of Any insertion/extraction operators</li> - -<li> -Abstract valuetypes</li> - -<li> -Valuetype members of all IDL aggregate types</li> - -<li> -Interface supports list</li> -</ul> - -<li> -Support for the CCM extensions to IDL, which first appeared in CORBA 3.0 -is complete, with the exception of support for the 'import' keyword.</li> - -<li> -Generated code for constants defined in a module is now inlined -(value is assigned in the header file) by default, enabling such -constants to be referenced by name as array bounds, etc. either in -subsequent generated code or in application code. However, this inlining causes -a problem with some compilers when using pre-compiled headers, so the -option -Guc has been added to turn it off. NOTE: Constants -defined at global scope (always inlined) and constants defined inside an -interface or a valuetype (never inlined) are not affected by the option. -</li> - -<li> -Generation of explicit template instantiations is now off by default. The -option -GT turns it on. If turned on, the generated explicit instantiations -are guarded by the same #ifdef preprocessor directives as before. -</li> - -<li> -The mechanism for processing multiple IDL files in a single execution has -changed. Instead of spawning a separate process for each IDL file, the -IDL compiler now processes the files sequentially in a single process. -Note that, for each file, execution of the preprocessor spawns a new -process, as it always has. -</li> - -<li> -Added command line option -Sm to suppress the action of CCM preprocessing -visitor, which is by default launched before the C++ generating visitors, -in order to add CCM equivalent IDL to the AST. There is a new tool in CIAO -which converts IDL files by replacing IDL3 constructs with equivalent IDL2 -constructs, and if the IDL compiler is run on these files, we do not want -the CCM preprocessing to occur. -</li> - -<li> -Changed the behavior of the -o option to create the specified directory -if it does not already exist. Only one level of directory can be created -with this option (any path prefix included must already exist). -If the specified directory already exists, no action is taken. -</li> - -<li> -As part of the subsetting in TAO of Anys and TypeCodes, the generation of -these things in the IDL compiler has been further decoupled from other -code generation. Now the -GA option generates not only a *A.cpp file but -also a *A.h file, and in addition, the -oA option will create these files -in a directory different from that where the other generated files are -created.</li> - -<li> -Generation of explicit template instantiations has been completely -removed, it is no longer available via the command line option -GT.</li> - -<li> -Generation of Any insertion/extracion operators for local interfaces -has been enabled by default. An additional command line option -Sal -has also been added to suppress the generation of Any operators for -local interfaces only.</li> - -<li> -Added new command line option -oS to specify output directory for -all skeleton files, including TIE class files, if generated. Overrides --o option value, if any.</li> - -</ul> - -<h4> -Known Issues:</h4> - -<ul> -<li> -With Microsoft Visual C++, verison 6.0 and earlier, a problem has been -discovered when the IDL compiler is built using the Release version of -the MSVC project. For the Release version, the Optimizations box in the -C/C++ tab has 'Maximize Speed' selected. This setting turned out to cause -a problem when</li> - -<p>const char *foo = ...... -<p>occurs in the source code. The variable foo is sometimes not allocated -or assigned properly, and if foo is part of generated code, it will then -display as garbage or as an empty string (or substring). Two workarounds -have been found. One is to change the declaration of foo to be -<p>static const char *foo = .... -<p>and this has been done in all cases we could find in the IDL compiler -source code. Another way to avoid the problem is to change the Release -project Optimization setting to 'Minimize Size'. Reportedly the problem -has been fixed in MSVC version 7.0.</ul> - -<h4> -Future work:</h4> - -<ul> -<li> -Implement the complete <a href="../ReleaseNotes/OBV.html">Object-by-Value</a> -specification. Originally implemented solely for use in holding exceptions -raised in <a href="../../../PDFs/ami1.pdf">asynchronous</a> invocations, -work is now ongoing to extend TAO's OBV implementation until it includes -the complete CORBA value type specification. Some of the items yet to be -implemented include:</li> - -<ul> -<li> -Boxed value types</li> - -<li> -Custom marshaling</li> - -<li> -Truncation</li> - -<li> -Marshaling of complex state (graphs with cycles)</li> - -</ul> -For a complete description of value type semantics, see chapter 5 in the -CORBA specification. -<li> -The generated sequence classes should not be generated per sequence, but -per type and parent scope. Which means, that the overhead of having the -source code generated serveral times should be reduced. To do this, an -extra pass over the internal representation of the IDL file has to be done.</li> - -<li> -Updated and portable support for wide characters and wide strings. The -original implementation supports Unicode only. At the time, the CORBA specification -required wide characters, whether standalone or in a wide string, to be -marshaled as 16-bit quantities. This is the same size as the native wchar_t -type on Win32 platforms. However, the wchar_t type on UNIX and related -platforms is 32 bits in size. In addition, the General Inter-ORB Protocol -(GIOP) version 1.2 has changed the CDR transfer syntax for wide characters. -In the new version, a wide character is marshaled as a single byte indicating -the size of the wide character representation, followed by the specified -nunber of bytes. The IDL compiler's handling of wide characters needs to -be updated, both to handle the GIOP 1.2 CDR transfer syntax, and to be -portable under previous versions of GIOP. For more information about GIOP -CDR transfer syntax, see section 15.3 in the CORBA specification. and for -information about the marshaling of IDL character types specifically, see -section 15.3.1.6.</li> - -</ul> - -<p><br><!--#include virtual="orbcore.html" --> -<hr> -<h3> -<a NAME="pp"></a>Pluggable Protocols</h3> -Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</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 process: (1) basic pluggable -transport protocols framework, (2) support for multiple profiles, (4) add -example transport protocols, such as ATM and VME, and refine/optimize the -transport protocols framework, and (4) add support for pluggable ORB protocols, -e.g., replacements for GIOP. Each of these steps is outlined below: -<ul> -<li> -<b>Basic pluggable transport protocols framework</b>: We have added several -Bridge classes that decouple the transport-specific details from the rest -of TAO's ORB Core. This allows us to isolate the details of how messages -are communicated at the transport layer in a few classes. This design resulted -in the restructuring of the ORB Core and how requests are handled. For -instance, there is now the concept of communication layers: Objects (e.g., -references, method invocations, etc.), ORB Messaging, Transport, and Network. -The Object layer is just the usual stubs and skeletons.</li> - -<p>The common interfaces have been defined in the new abstract classes -that form the core of TAO's pluggable protocol framework, e.g., -<tt>TAO_Connector</tt>, -<tt>TAO_Acceptor</tt>, -<tt>TAO_Profile</tt> -and <tt>TAO_Transport</tt>. Two new mechanisms for keeping track of supported -transport protocols are the -<tt>TAO_Connector_Registry</tt> and -<tt>TAO_Acceptor_Registry</tt>, -which are essentially Abstract Factories that produce the right types of -connector, acceptors, and transports. -<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.</li> - -<li> -<b>Example Transport protocols</b> - Aside from IIOP, the following transport -protocols are distributed with TAO:</li> - -<ol> -<li> -UIOP: GIOP over local IPC (UNIX domain sockets)</li> - -<li> -SHMIOP: GIOP over shared memory</li> - -<li> -SSLIOP: GIOP over SSL (Secure Socket Layer)</li> - -<li> -SCIOP: GIOP over SCTP</LI> - -<li> -DIOP: GIOP over UDP/IP unicast</li> - -<li> -MIOP: GIOP over UDP/IP multicast</li> -</ol> -Other interesting transport protocols could be for ATM, Buses (VME or PCI), -TP4, and GSMP. TAO users have also created their own pluggable transport -protocols, such as a ScramNet pluggable protocol. -<li> -<b>Pluggable ORB protocols</b> - This step will add support for ORB protocols -besides GIOP. In particular, we will explore lightweight protocols using -shared memory and system buses like PCI or VME.</li> -</ul> -Current Status: -<ul> -<li> -The basic framework to support pluggable transport protocols has been completed. -The standard TAO regression tests <tt>Latency</tt>, -<tt>MT_Cubit</tt>, -<tt>Multiple_Inheritance</tt>, -<tt>CDR</tt> and -<tt>EC_Throughput</tt> can be used to verify performance -using the new framework.</li> - -<li> -Multiple endpoint support in the ORB has been added. A list of TAO_Acceptors -is kept in the Acceptor Registry. When the ORB needs to create an IOR it -iterates over all the acceptors to do so. Using either multiple <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> -options or several endpoints separated by semi-colons ';', the user can -specify what addresses the ORB should use. Each endpoint is specified in -URL format (ex: <tt>iiop://foo.bar.com:0</tt>), this format can be extended -to support different protocols.</li> - -<li> -If the user does not specify a list of endpoints then the ORB creates a -default endpoint for each protocol configured, unless the pluggable protocol -explicitly prevents that in an effort to prevent resource leaks.</li> - -<li> -Added support for multiple Connectors in the ORB, the ORB finds the correct -connector based on the tag for the profile.</li> - -<li> -Added support for multiple profiles in the IORs, when the ORB demarshals -an IOR it queries the Connector Registry to create the right kind of profile -for the known protocols. If one of the protocols is unknown we create a -special profile class that can only be used for marshaling and demarshaling, -not communication.</li> - -<li> -Enabled the UIOP protocol. This protocol uses local IPC (aka UNIX domain -sockets) as the transport mechanism. The protocol is loaded by default.</li> - -<li> -Enabled the SHMIOP protocol. This protocol uses shared memory as the transport -mechanism. The protocol is loaded by default.</li> - -<li> -An IIOP over SSL pluggable transport called "SSLIOP" has been implemented. -It provides secure communication between hosts that support IIOP over SSL, -and is meant to be a drop-in replacement for the IIOP pluggable transport. -TAO's SSLIOP pluggable transport implementation supports both the standard -IIOP transport protocol and the secure IIOP over SSL transport protocol.</li> - -<p>No changes were made to the core TAO sources to provide to this SSL -support, nor does TAO contain any security related hooks. TAO's SSLIOP -implementation is completely self-contained. This ensures that the core -TAO sources remains free of export restrictions. -<li> -Protocols can be dynamically loaded into the ORB: The default resource -factory reads the protocol "names" from its list of arguments. These protocol -names are used to load an abstract factory via the service configurator. -This factory can create acceptors or connectors on demand. By default only -IIOP is loaded.</li> - -<li> -The service configurator is now used to load protocol factories.</li> - -<li> -Support for the <tt>-ORBHost</tt> and <tt>-ORBPort</tt> has been removed. -The new <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> option -supersedes them, and provides the same functionality in a protocol-neutral -way. If the deprecated options are used, the ORB exits with a <tt>CORBA::BAD_PARAM</tt> -exception, indicating an unknown <tt>-ORB</tt> option.</li> - -<li> -The <tt>-ORBPreconnect</tt> ORB option has been deprecated in favor of -the standard <tt>validate_connection</tt> run-time feature. Support for -this option will be removed from future releases.</li> - -<li> -The URL style object reference format has been updated to conform with -the format that <tt>corbaloc</tt> uses. The BNF specification for <tt>corbaloc</tt> -is:</li> - -<blockquote><tt><corbaloc> = "corbaloc:/"[<obj_addr_list>]["/"<key_string>]</tt> -<br><tt><obj_addr_list>= [<obj_addr> ","]* <obj_addr></tt> -<br><tt><obj_addr>= <prot_addr> | <future_prot_addr></tt> -<br><tt><prot_addr>= <rir_prot_addr> | <iiop_prot_addr></tt> -<br><tt><rir_prot_addr>= <rir_prot_token>":"</tt> -<br><tt><iiop_prot_addr>= <iiop_id><iiop_addr></tt> -<br><tt><iiop_id>= ":" | <iiop_prot_token>":"</tt> -<br><tt><iiop_prot_token> = "iiop"</tt> -<br><tt><iiop_add> = [<version> <host> [":" <port>]]</tt> -<br><tt><host> = DNS-style Host Name | ip_address</tt> -<br><tt><version> = <major> "." <minor> "@" | empty_string</tt> -<br><tt><port> = number</tt> -<br><tt><major> = number</tt> -<br><tt><minor> = number</tt> -<br><tt><future_prot_addr> = <future_prot_id><future_prot_addr> -<future_prot_id> = <future_prot_token>":" <future_prot_token> -= possible examples: "atm" | "dce" <future_prot_addr> = protocol specific -address <key_string> = <string> | empty_string</tt></blockquote> -The <tt>uiop</tt> URL style object references syntax is: -<blockquote><tt><uioploc> = "uioploc://"[<addr_list>]["|"<key_string>]</tt> -<br><tt><addr_list>= [<address> ","]* <address></tt> -<br><tt><address> = [<version> <rendezvous point>]</tt> -<br><tt><rendezvous point> = Valid Filesystem Path</tt> -<br><tt><version> = <major> "." <minor> "@" | empty_string</tt> -<br><tt><major> = number</tt> -<br><tt><minor> = number</tt> -<br><tt><key_string> = <string> | empty_string</tt></blockquote> -Note that the key string delimiter for <b><tt>uiop</tt></b> is a vertical -bar `<b><tt>|</tt></b>' (the command line "pipe" symbol) not a forward -slash `<tt>/</tt>'. A delimiter other than a forward slash is needed to -prevent ambiguities of where the rendezvous point ends and where the key -string begins since both may contain forward slashes in them. The new <tt>corbaloc:uiop</tt> -URL format may also be used. -<p>It should be noted that these formats have been superseded by the new -<tt>corbaloc</tt> -<a href="../INS.html">Interoperable Naming Service</a> support. -<li> -The <i>rendezvous point</i> for <tt>uiop</tt> is any valid path and filename -that the ORB has permission to read and write to. However, UIOP rendezvous -points have the same restrictions that local IPC has. The following are -some guidelines that will help ensure successful use TAO's UIOP pluggable -transport protocol:</li> - -<blockquote> -<li> -To guarantee portability, local IPC rendezvous points (including the path -and filename) should not be longer than 99 characters long. Some platforms -may support longer rendezvous points, usually 108 characters including -the null terminator, but Posix.1g only requires that local IPC rendezvous -point arrays contain a maximum of <b>at least</b> 100 characters, including -the null terminator.</li> - -<P>If an endpoint is longer than what the platform supports then -it will be truncated so that it fits, and a warning will be issued. -<li> -Avoid using <i>relative</i> paths in your UIOP endpoints. If possible, -use <b><i>absolute</i></b> paths instead. Imagine that the server is given -an endpoint to create using <tt>-ORBEndpoint uiop://foobar</tt>. A local -IPC rendezvous point called <tt>foobar</tt> will be created in the current -working directory. If the client is not started in the directory where -the <tt>foobar</tt> rendezvous point exists then the client will not be -able to communicate with the server since its point of communication, the -rendezvous point, was not found. On the other hand, if an absolute path -was used, the client would know exactly where to find the rendezvous point.</li> - -<p>It is up to the user to make sure that a given UIOP endpoint is accessible -by both the server and the client. -<li> -It is important to be consistent in the use of absolute paths and relative -paths for rendezvous points. The two types of paths should not be used -for the same endpoint. For example, if <tt>uiop:///tmp/foo</tt> is specified -as the server endpoint and <tt>uiop://foo</tt> as a preconnect for a client -in <tt>/tmp</tt>, then the preconnection may be established but it is likely -it won't be used since the endpoint and preconnect are interpreted as different -strings, i.e. <tt>/tmp/foo</tt> and <tt>foo</tt> are not the same, lexicographically. -On the other hand, if both the endpoint and the preconnect are the same -string then a preconnection will be established and used successfully.</li> - -</blockquote> -The <tt><a href="../ORBEndpoint.html">-ORBEndpoint</a></tt> option uses -a syntax similar to that of the URL style object reference shown above. -The only difference is that the object key delimiter and the object key -string are not specified. -<li> -Added documentation that describes how to implement pluggable transport -protocols for TAO. The document is available <a href="../pluggable_protocols/index.html">here</a>.</li> - -<li> -TAO's IIOP pluggable protocol now supports automatic creation of profiles -for endpoints created on a host with multiple network interfaces. It should -no longer be necessary to manually specify an endpoint for each network -interface.</li> - -<p>This means that server IORs will contain profiles for all of the default -endpoints created on each network interface the server is listening on, -if no explicit endpoints were specified.</ul> -Known Issues: -<ul> -<li> -</li> -</ul> -Critical Work: -<ul> -<li> -None.</li> - -</ul> -Future Work: -<ul> -<li> -Complete support for multiple ORB messaging protocols.</li> - -<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> -</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> -<p>The POA associates servants with the ORB and demultiplexes incoming -requests to servants. -<p>Current Status: -<ul> -<li> -TAO supports the POA spec. This section will carry updates as available.</li> -</ul> -Known issues: -<br>Future work: -<br>Recently completed work: -<ul> -<li> -ORB::shutdown now properly deactives all the POA Managers.</li> - -<li> -POA Managers in TAO were previously ignored in the request processing path -on the server. This is now fixed such that their state is checked before -dispatching the client request to the servant. Only if the state is <tt>ACTIVE</tt>, -is the request dispatched to the servant. Otherwise, the request is rejected. -Since POA Managers start off in <tt>HOLDING</tt> state, make sure to -<tt>activate()</tt> -them before falling into the event loop.</li> - -<li> -TAO's POA now properly supports both the threading policies: SINGLE_THREAD_MODEL -and ORB_CTRL_MODEL.</li> - -<li> -The synchronization in the POA is now very optimal. For example, the locks -are not held across the invocation on the servant. The locks are also not -held across the invocation on the AdapterActivator and ServantManagers. -This allows us to use regular locks instead of recursive locks inside the -POA. This also allows multiple threads to dispatch requests on the same -POA simultaneous.</li> - -<li> -Before 1.4.6 TAO supports reference counting between POA and servants, including -the new RefCountServantBase and ServantBase_var classes. RefCountServantBase -is a reference counted base class that was added to the CORBA specification -to avoid race conditions for servant deletion in threaded servers. <a href="ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf">ftp://ftp.omg.org/pub/docs/orbos/98-07-12.pdf</a> -contains the relevant text. Check <a href="../poa_migration.html#Reference counting Servants">here</a> -on some hints to avoid trouble. From TAO 1.4.6 reference counting is always -enabled for servants and RefCountServantBase is a noop struct you don't -need anymore.</li> - -<li> -The POA now supports active demultiplexing of servants in the SYSTEM_ID -and the USER_ID policy. This should make the POA faster and more predictable -since there is no hashing involved and the index of the slot where the -servant is registered is in the Object Key.</li> - -<li> -Previously, the complete POA name was used as the POA identity. This scheme -was inefficient in many ways including: (a) the complete POA name can be -significantly large in size, and therefore, ineffient to pass with every -method call from the client to the server; (b) it is varible in size, and -therefore, does not lend itself to smart and effective parsing; (c) the -searching based on the complete POA name is very ineffient.</li> - -<p>The new solution is to use an active demux table, and flatten the POA -hierarchy. This will help in the searching since active demuxing is fast -and predictable. This will also help in the parsing since the demux key -will be fixed size. -<p>Note that for persistent ids, we have to pass the complete POA name -in addition to the demux key in order to handle POA creation on demand. -<li> -There were some POA objects in a typical server that are not freed up properly, -resulting in a memory leak. This has now been fixed.</li> - -<li> -Timestamps in persistent IORs were not required and have been removed.</li> - -<li> -POA exceptions are not not system exceptions and have been removed from -the list of system exceptions.</li> - -<li> -Vastly improved the ability of the POA to deal with user exceptions, memory -allocation failures, and constructor failures.</li> - -<li> -We now support a minimum POA for the minimum CORBA specification. Recently, -this feature was enchanced such that the minimum CORBA footprint was further -reduced. In addition, minimum POA can be enabled/disable irrespective of -the minimum CORBA setting.</li> - -<li> -We have decided not to support active demuxing for method name lookup. -The benefit of this optimization was questionable since the current perfect -hashing scheme provide very good and predictable behavior.</li> - -<p>Also, note that this optimization will require many changes. We would -have to use the help of the IDL compiler to modify the object key that -is passed for every method call differently. Note that this scheme doesn't -work in the case of multiple inheritance or when the client stubs are not -TAO. -<li> -Improved the parsing of object keys belonging to the RootPOA. Since this -is the default POA and is commonly used, we have given it a reserved byte -in the object key in order to quickly identify it. With the reserved bit, -the active demux key for the RootPOA is not used, and no map lookups are -required.</li> - -<li> -POA name separator was changed from '/' to '\0'. Since POA names are strings, -this makes a better choice since there is no chance of a conflict with -the string specified by the user.</li> - -<li> -We have support for reactivating servants with system generated ids.</li> - -<li> -The TAO specific synchronization POA policy has been removed.</li> - -<li> -New examples have been added to show how servants can be dynamically loaded -from DLLs on demand.</li> - -<li> -Support for collocation should be much better now because the POA can tell -if we created the object reference.</li> - -<li> -After Nanbor's recent changes for collocation, we support the full semantics -of remote objects on a collocated object. The spec mandates that collocated -object should behave <i>exactly</i> like remote objects, which includes -going through the POA, running the Servant Managers, running the interceptors, -and expecting the reference counting behavior provided by the POA. Note -that the old scheme of direct call through to the servant is also still -available.</li> - -</ul> - -<hr> -<br><!--#include virtual="OBV.html" --> -<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>OMG defined CORBA Naming Service (spec <a href="ftp://ftp.omg.org/pub/docs/formal/97-07-12.pdf">here</a>) -to provide a basic service location mechanism for CORBA systems. CosNaming -manages a hierarchy of name-to-object-reference mappings. Anything, but -typically the server process hosting an object, may bind an object reference -with a name in the Naming Service by providing the name and object reference. -Interested parties (typically clients) can then use the Naming Service -to resolve a name to an object reference. -<p>More recently, CORBA Naming Service was subsumed/extended by the CORBA -Interoperable Naming Service, a.k.a. INS (spec <a href="ftp://ftp.omg.org/pub/docs/orbos/98-10-11.pdf">here</a>). -INS inherits all the functionality from the original Naming Service specification -in addition to addressing some its shortcomings. In particular, INS defines -a standard way for clients and servers to locate the Naming Service itself. -It also allows the ORB to be administratively configured for bootstrapping -to services not set up with the orb at install time. <a href="../INS.html">This -page</a> provides a brief description of additional features INS provides, -and how they are implemented in TAO. -<p>Current status (as of 18 May 2001): -<ul> -<li> -The Naming Service now <i>does not</i> do listen for multicast discovery -as the default. Use <tt>-m1</tt> option to turn it on.</li> -</ul> -Recent work: -<ul> -<li> -Changed default for multicast discovery to</li> -</ul> -Features: -<ul> -<li> -Added support for Persistence (using memory-mapped files). Persistence -feature is optional, and is controlled by the command line argument.</li> - -<li> -Updated the implementation of the Naming Service to use new ACE exception -macros.</li> - -<li> -Added support for the InterOperable Naming Service, which enables the ORB -to support IORs in user-friendly <tt>corbaloc</tt> format. These features -allow the ORB to be configured to return arbitrary object references from -<tt>CORBA::ORB::resolve_initial_references</tt> -for non-locality-constrained objects. Two options -ORBInitRef and -ORBDefaultInitRef -have been added to the orb for bootstrapping to arbitrary services.</li> - -<li> -Added support for the Naming service to act like an agent: to understand -IIOP request messages from clients and respond with reply messages with -a <tt>LOCATION_FORWARD/OBJECT_NOT_EXIST</tt> status. The Naming Service -can be configured through ORB options to register arbitrary services given -the URL-format IOR for the service. The <tt>resolve_initial_references -()</tt> resolves a service in the following order :</li> - -<ol> -<li> -<tt>-ORBInitRef</tt></li> - -<li> -<tt>-ORBDefaultInitRef</tt></li> - -<li> -Multicast discovery</li> -</ol> - -<li> -Added a test for the InterOperable Naming Service that works in conjunction -with the current TAO examples.</li> - -<li> -Implementation of the CORBA INS spec is completed. The following features -are now supported:</li> - -<ul> -<li> -corbaname format</li> - -<li> -NamingServiceExt interface</li> -</ul> -</ul> -Future work: -<ul> -<li> -Support for a load balancing feature similar to the one present in ORBIX. -It will be possible to bind a group of objects under a single name, and -when a client attempts to resolve the name in question, a preset policy -(e.g., random, round robin, etc.) will determine which one of the object -references from the group will be returned.</li> - -<li> -Support for the Naming Service to handle the IIOP LocateRequest messages -and respond with LocateReply messages with a -<tt>LOCATION_FORWARD/OBJECT_NOT_EXIST</tt> -status.</li> -</ul> - -<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/technology/documents/formal/trading_object_service.htm">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: -<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> - -<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/technology/documents/formal/property_service.htm">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> - -<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/technology/documents/formal/concurrency_service.htm">Concurrency -Service</a> provides a mechanism that allows clients to acquire and release -various types of locks in a distributed system. -<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> - -<hr WIDTH="100%"> -<h3> -<a NAME="av"></a>CORBA Audio/Video Streaming Service</h3> -Point of contact: <a href="mailto:yamuna@oomworks.com">Yamuna Krishnamurthy</a> -<p>This is an implementation of the OMG spec addressing the <a href="http://www.omg.org/technology/documents/formal/audio.htm">Control -and Management of Audio/Video Streams</a>. For more documentation on TAO's -A/V Service please have a look <a href="http://www.cs.wustl.edu/~schmidt/av.html">here</a>. -<h4> -Current Status:</h4> -(as of July 30 2002) -<ul> -<li> -The audio/video streaming service has been implemented in the full profile. -The current implementation support all the flow related components like -flowEndpoint,FDev,FlowConnection,..,etc.</li> - -<li> -Point-to_Point and Point-to-MultiPoint streams have been implemented.</li> - -<li> -A Pluggable protocols framework has been implemented to flexibly add new -flow protocols like SFP, RTP and new transports like ATM. The current implementation -has protoocol implementations for SFP, RTP over UDP and Multicast UDP. -Please look at <tt><a href="../../orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html">orbsvcs/orbsvcs/AV/AV_Pluggable_Framework.html</a></tt>for -more documentation about the implementation.</li> - -<li> -QoS_UDP pluggable protocol added which implements RSVP QoS support for -UDP streams.</li> - -<li> -Diffserv support added to the UDP pluggable protocol by <a href="mailto:crodrigu@bbn.com">Craig -Rodrigues</a>.</li> - -<li> -RTP/UDP support enhancements and RTCP control protocol support added by -<a href="mailto:rruff@scires.com">Rob -Ruff</a>.</li> -</ul> -Work in progress: -<ul> -<li> -Integration with <a href="http://www.dist-systems.bbn.com/projects/AIRES/UAV/">BBN -UAV software.</a></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> - -<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="ftp://ftp.omg.org/pub/docs/formal/97-12-11.pdf">(.pdf)</a>, -<a href="ftp://ftp.omg.org/pub/docs/formal/97-12-11.ps">(.ps)</a> -<br>The different command line and service configurator options used -for configuring the CORBA event services are located <A -href="../cec_options.html"> here</a>. This implementation is based on -the Real Time Event service. -<h3> -Features in this release:</h3> - -<ul>There is a new implementation of the COS Event Service available. This -new implementation supports both the Push and Pull styles for event communication, -and it does not require the Real-time Event Service to work. -<p>A new testsuite for the COS Event Service has been started, they are -available at: <tt>$TAO_ROOT/orbsvcs/tests/CosEvent/</tt> -<p>A new example for the COS Event Service is provided in <tt>$TAO_ROOT/orbsvcs/examples/CosEC/Simple/</tt> -<p>A new binary to run the native COS Event Service was added, it is compiled -in: <tt>$TAO_ROOT/orbsvcs/CosEvent_Service/CosEvent_Service_Native</tt> -<li> -A simple test (<tt>$TAO_ROOT/orbsvcs/tests/CosEC_Basic</tt>) demonstrates -how to create and use the event channel.</li> - -<li> -Event Service (<tt>$TAO_ROOT/orbsvcs/CosEvent_Service</tt>)The Event Service -creates a COS compliant event channel and registers it with the naming -service with the default name "CosEventChannel".</li> - -<br>Please read the associated README for more details. -<li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: This -test demonstrates how multiple CosEC's connect to one RtEC and how multiple -consumers and producers exchange events in this configuration.</li> -</ul> - -<h3> -Known bugs:</h3> - -<ul> -<li> -CosEC_Multiple: <tt>($TAO_ROOT/orbsvcs/tests/CosEC_Multiple)</tt>: Once -the tests are done, the control doesn't return to the shell, you have to -say CTRL-C to get back to the prompt.</li> -</ul> - -<hr WIDTH="100%"> -<h3> -<a NAME="log"></a>CORBA Telecom Log Service</h3> - -<h4> -Last updated: Sun May 28 15:42:44 PDT 2006</h4> -Point of contact: <a href="mailto:jtc@acorntoolworks.com">J.T. Conklin</a> -<p>The CORBA <a href="ftp://ftp.omg.org/docs/formal/03-07-01.pdf">Telecom -Log Service</a> was updated in TAO 1.5. -<h3> -Features supported in the current version:</h3> - -<ul> -<li> -The Log Service implementation under <tt>$TAO_ROOT/orbsvcs/orbsvcs/Log</tt> -implements the <tt>DsLogAdmin </tt>module.</li> - -<li> -Support for the <tt>DsEventLogAdmin </tt>module, which uses the <a href="#ec">COS -Event Service</a> has been added.</li> - -<li> -Support for the <tt>DsNotifyLogAdmin </tt>module, which uses the <a href="#notify">Notification -Service</a> has been added.</li> - -<li> -Support for the <tt>RTEventLog </tt>module, which uses the <a href="ec.html">RTEvent -Service</a> has been added.</li> - -<li> -Support for the <tt>DsLogNotification </tt>module for log- generated events -has been added.</li> - -<li> -The Logging_Service (<tt>$TAO_ROOT/orbsvcs/Logging_Service</tt>) contains -4 separate services</li> - -<ul> -<li> -Basic_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Basic_Logging_Service</tt></li> - -<li> -Event_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Event_Logging_Service</tt></li> - -<li> -Notify_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/Notify_Logging_Service</tt></li> - -<li> -RTEvent_Logging_Service <tt>$TAO_ROOT/orbsvcs/Logging_Service/RTEvent_Logging_Service</tt></li></ul> - -<li> -Each service registers with the Naming Service as -"BasicLogFactory", "EventLogFactory", "NotifyLogFactory" and -"RTEventLogFactory" respectively.</li> - -<li> -Each service registers with the Interoperable Naming Service as -"BasicLogService", "EventLogService", "NotifyLogService" and -"RTEventLogService" respectively.</li> - -<li> -The Log Service uses a dynamically loaded "plug-in" Strategy for storing and -querying log records. The default Strategy stores Log records in memory and -supports the Extended Trader Constraint Language (ETCL) Query Language.</li> - -<li> -There are now examples that demonstrate simple usage of the Log Services. -These are found in <tt>$TAO_ROOT/orbsvcs/examples/Log</tt> and the relevant -sub-directories.</li> - -<br>A thorough test <tt>$TAO_ROOT/orbsvcs/tests/Log/Basic_Log_Test</tt> -tests most of the features of the basic logging service.</li> -</ul> - -<h3> -Future work and enhancements:</h3> - -<ul> -<li> -Provide Strategies that support persistent storage of log records.</li> - -<li> -Change default Strategy to use Red-Black trees to optimize lookup on -frequently used query keys - namely record id's and time.</li> -</ul> - -<hr WIDTH="100%"> -<h3> -<a NAME="notify"></a>Notification Service</h3> - -<h4> -Last updated:Thu Nov 21 18:41:11 2002</h4> -Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> -<p>TAO's CORBA <a href="ftp://ftp.omg.org/pub/docs/telecom/99-07-01.pdf">Notification -Service </a>implementation consists of the following (see the associated -README's for more information): -<ul> -<li> -The implementation of the interfaces in the Notification Service spec is -in <tt><a href="../../orbsvcs/orbsvcs/Notify">$TAO_ROOT/orbsvcs/orbsvcs/Notify -</a></tt>.</li> - -<li> -The service driver is implemented in <tt><a href="../../orbsvcs/Notify_Service">$TAO_ROOT/orbsvcs/Notify_Service</a></tt>.</li> - -<br>The various options of the Notify_Service are described <a href="notify.html#notify_Service">here -</a>. -<li> -The example in <tt><a href="../../orbsvcs/examples/Notify/Filter">$TAO_ROOT/orbsvcs/examples/Notify/Filter</a></tt> -shows a basic example of using filters.</li> - -<li> -The example in <tt><a href="../../orbsvcs/examples/Notify/Subscribe">$TAO_ROOT/orbsvcs/examples/Notify/Subscribe</a></tt>shows -a basic example of how to use subscriptions.</li> - -<li> -Feature unit tests are under <tt><a href="../../orbsvcs/tests/Notify">$TAO_ROOT/orbsvcs/tests/Notify</a></tt></li> - -<li> -The <a href="notify.html#feature_matrix">Notification feature matrix </a>lists -the features implemented.</li> -</ul> -<i>Note that this implementation does not support Pull interfaces and Typed -Event style communication.</i> -<p> -<hr WIDTH="100%"> -<h3> -<a NAME="rt_notify"></a>Real-Time Notification Service</h3> - -<h4> -Last updated:Thu Jul 24 11:57:53 2003</h4> -Point of contact: <a href="mailto:pradeep@oomworks.com">Pradeep Gore</a> -<p>This is an extension to TAO's CORBA Notification Service with Real-Time -CORBA support. -<p><b>IDL Extensions:</b> -<ul> -<li> -<b>Interface Extensions:</b> The <a href="../../orbsvcs/orbsvcs/NotifyExt.idl">$TAO_ROOT/orbsvcs/orbsvcs/NotifyExt.idl</a> -extends the ConsumerAdmin and SupplierAdmin interfaces. The <tt>obtain_notification_push_supplier_with_qos</tt> -and <tt>obtain_notification_push_consumer_with_qos</tt> methods can be -used to specify QoS parameters.</li> - -<li> -<b>QoS Definitions:</b></li> - -<ul> -<li> -ThreadPoolParams: This specifies the parameters for creating a threadpool -in an RT POA.</li> - -<li> -ThreadPoolLanesParams: This specifies the parameters for creating a threadpool -with lanes in an RT POA.</li> -</ul> -</ul> -<b>Tests and Examples:</b> -<ul> -<li> -The <tt><a href="../../orbsvcs/examples/Notify/Lanes">$TAO_ROOT/orbsvcs/examples/Notify/Lanes -</a></tt>example -shows how to use RTCORBA Lanes in RT Notification.</li> - -<li> -The <tt><a href="../../orbsvcs/examples/Notify/ThreadPool">$TAO_ROOT/orbsvcs/examples/Notify/ThreadPool</a></tt> -example shows how to use RTCORBA ThreadPools in RT Notification.</li> -</ul> -The performance tests for RT Notification measure the throughput, latency -and jitter for various test configurations using Periodic Suppliers: -<ul> -<li> -<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/1_Path_Period_0_Lanes</a></tt></li> - -<br>This configuration measures performance for a single data path when -the load is increased. The Supplier sends events in a single burst. -<li> -<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes">$TAO_ROOT/tests/Notify/performance-tests/scripts/3_Path_Period_10ms_Lanes</a></tt></li> - -<br>This configuration measures performance for 3 data paths of high, ,medium -and low priorities when the Load is increased. The Suppliers send events -at 100Hz. -<li> -<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Paths_vs_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Paths_vs_Throughput</a></tt></li> - -<br>This configuration has 1 high priority path ans several low priority -paths. we measure the performance of the high priority path as a function -of the number of low priority paths. -<li> -<tt><a href="../../orbsvcs/tests/Notify/performance-tests/scripts/Max_Throughput">$TAO_ROOT/tests/Notify/performance-tests/scripts/Max_Throughput</a></tt></li> - -<br>This Configuration measures the performance obtained for a data path -using a Structured Event payload: -<ul> -<li> -directly between a Supplier and Consumer in seperate processes.</li> - -<li> -directly between a colocated Supplier and Consumer.</li> - -<li> -between a Supplier and Consumer with a "Relay Consumer" as an intermidiary.</li> - -<li> -between a a Supplier and Consumer using the Notification Service.</li> -</ul> -</ul> -<b>Test Framework:</b> -<br>The <tt><a href="../../orbsvcs/tests/Notify/lib">$TAO_ROOT/orbsvcs/tests/Notify/lib</a></tt> -contains a scripting based test framework which can be used to quickly -create test cases. The framemork and its options are described <a href="notify.html#test_framework">here. </a><!-- BEGIN: CORBA Security Service Release Notes --> -<hr WIDTH="100%"> -<h3> -<a NAME="security"></a>CORBA Security Service</h3> -Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> -<p>Additional information is available -<a href="../Security/index.html">here</a>. - -<h4>Security Service Overview</h4> - -TAO's current Security Service support implements the core -functionality of the <a href="http://www.omg.org/cgi-bin/apps/doc?formal/02-03-11.pdf">CORBA Security Service v1.8</a>. -<p> -In particular, it implements the most of the CORBA <a href="../../orbsvcs/orbsvcs/SecurityLevel1.idl">SecurityLevel1 API</a>, -in addition to some of <a - href="../../orbsvcs/orbsvcs/SecurityLevel2.idl">SecurityLevel2</a>. -Of the transport protocols described in the above specification, only - SSLIOP is supported. Documentation for TAO's SSLIOP pluggable - transport is available <a href="../Security/index.html">here</a>. - -<p> -The 1.8 specification defines the Common Secure Interoperability version -1 (CSIv1) protocol that is currently implemented in TAO. - -<p> -There are basically two ways to use security in TAO: -<ol> -<li> -Use TAO's SSLIOP pluggable transport in TAO alone. This allows one -to secure application requests without modifying the application code. -This is the easiest approach but is also the least flexible. -</li> -<li> -Use the Security Service API implemented by TAO in conjunction with -TAO's SSLIOP pluggable transport. This provides the benefits of -secured application requests with the flexibility of disabling -security in some requests, if so desired. This approach also allows -one to choose at run-time which X.509 certificates will be associated -with application requests, as opposed to setting configuring only one -SSL certificate at application start-up-time. These things are -basically configured using the SecurityLevel2 or SecurityLevel3 -defined policies: - -<blockquote><code> - SecurityLevel2::QOPPolicy<br> - SecurityLevel2::EstablishTrustPolicy<br> - SecurityLevel3::ContextEstablishmentPolicy<br> -</blockquote></code> -</li> -</ol> - -<h4>Implemented Features</h4> -IIOP over SSL integration via TAO's <a href="../Security/SSLIOP.html">SSLIOP -pluggable transport</a>. -<ul> -<li> -Added an <tt>SSLIOP::Current</tt> implementation that can be used to obtain -the SSL session state for the current execution context. This is useful -for obtaining the SSL peer certificate chain associated with the current -request, for example.</li> - -<li> -TAO's SSLIOP pluggable transport now registers a secure invocation server -request interceptor. It enforces secure invocation by rejecting requests -coming in on the insecure port if the server is configured to do so (default -behavior).</li> - -<li> -Implemented <tt>SecurityLevel1</tt> for the SSLIOP security mechanism.</li> - -<li> -The <tt>SecurityLevel2::QOPPolicy</tt> policy has been implemented. This -policy is used to set the desired invocation Quality-of-Protection (QoP). -It can be created using <tt>ORB::create_policy()</tt>, and used in conjunction -with the standard policy manipulation CORBA features (e.g. <tt>PolicyManager</tt>, -<tt>PolicyCurrent</tt>), -meaning that this policy can be set on a per-ORB, per-thread or per-object -basis.</li> - -<p>This policy makes it possible to, for example, make both secure and -insecure invocations within the same client process. -<li> -TAO's SSLIOP pluggable transport implementation is now thread-safe.</li> - -<li> -The <tt>SecurityLevel2::EstablishTrustPolicy</tt> policy has been implemented. -This policy is used to set the desired invocation level of establishment -of trust. It can be created using <tt>ORB::create_policy()</tt>, and used -in conjunction with the standard policy manipulation CORBA features (e.g. -<tt>PolicyManager</tt>, -<tt>PolicyCurrent</tt>), meaning that this policy can be set on a per-ORB, -per-thread or per-object basis.</li> - -<p>This policy makes it possible to, for example, make authenticated and -non-authenticated invocations within the same client process. -<li> -Implemented <tt>SecurityLevel2::PrincipalAuthenticator</tt> support for -SSLIOP. In particular, a SSLIOP-specific <tt>SecurityReplaceable::Vault</tt> -implementation is now available.</li> -<li> - Implemented basic (stateless) CSIv2 support. Advanced CSIv2 - features, such as identity assertion, are currently under - development. - -</ul> -</ul> -<h4>Current Status</h4> -<ul> -<li> - Began implementation of the interfaces in the - <tt>SecurityReplaceable</tt> IDL module. They provide the - ability to replace key security components in the ORB with - another implementation with ease. Thus, the security - components in the ORB become highly extensible.</li> -<li> - Development of core <tt>SecurityLevel2</tt> interfaces such as - <tt>Credentials</tt>, <tt>SecurityManager</tt>, - and <tt>PrincipalAuthenticator</tt> has been halted in favor - of Adiron's <tt>SecurityLevel3</tt> interfaces</li> -<li> - Advanced CSIv2 features, such as identity assertion, are - currently under testing.</li> -</ul> -<h4>Schedule</h4> -<ul> -<li> -<font color="#0000FF">August 2004</font></li> - -<ul> -<li> - Complete integration of the Common Secure Interoperability - version 2 (CSIv2) protocol defined in the <a - href="http://www.omg.org/cgi-bin/doc?formal/04-03-12">CORBA - 3.0.x</a> core specification, and the <a - href="http://www.omg.org/technology/documents/formal/atlas.htm">Authorization Token Layer Acquisition Service (ATLAS)</a>. - <p> - CSIv2 and ATLAS address many of the shortcomings of the - current CSIv1-based Security Service. Overviews of each are - available on the <a href="http://www.omg.org/technology/documents/formal/omg_security.htm">OMG Security</a> web page. - <blockquote><em> - Note that CSIv2 as defined by the CORBA 3.0.x specification - has no API so TAO's implementation will use a slightly - <a - href="http://adiron.com/ORBAsec/3.5.0/docs/SL3/#SecurityLevel3API">modified API</a> currently used by several ORBs defined by Adiron LLC. - </em></blockquote> - -</li> -</ul> -<!-- - <LI> - <FONT COLOR=BLUE>November 2002</FONT> - <UL> - <LI> - Request authentication via - <A HREF="http://web.mit.edu/kerberos/www/">Kerberos</A>, as - detailed in the CORBA Security Service specification. This - requires the Common Secure Interoperability protocol (CSIv2), - but initial experiments will be performed via TAO's existing - SSLIOP pluggable transport. - </LI> - <LI> - Partial implementation of the <CODE>SecurityLevel2</CODE> - interfaces. This includes the <CODE>Credential</CODE> and - <CODE>Current</CODE> objects. - </LI> - <LI> - Partial implementation of the <CODE>SecurityAdmin</CODE> - interfaces. - </LI> - <LI> - Begin implementation of <CODE>SecurityAudit</CODE> objects. - As a side benefit, this project will allow us to research how - to secure existing services such as - <A HREF="ec.html">TAO's Real-Time Event Service</A>. - </LI> - </UL - </LI> -<li> -<font color="#0000FF">December 2002</font></li> - -<ul> -<li> -Begin implementation of the <i>Resource Access Decision (RAD) Facility</i> -specification for TAO.</li> -</ul> - -<li> -<font color="#0000FF">February 2003</font></li> - -<ul> -<li> -Begin implementation of the <i>Security Domain Membership Management (SDMM)</i> -specification for TAO. It is needed to support security domains.</li> -</ul> - -<li> -<font color="#0000FF">April 2003</font></li> - -<ul> -<li> -SSLIOP and SECIOP performance enhancements.</li> -</ul> ---> -</ul> -<!-- END: CORBA Security Service Release Notes --> - -<!--#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="fault_tolerance"></a>TAO's support for FT services</h3> -Point of contact: <a href="mailto:bala@dre.vanderbilt.edu">Balachandran -Natarajan</a> -<h4> -Current Status:</h4> -TAO supports the ORB level requirements to achieve Fault Tolerance for -CORBA Objects. The details of the ORB level support is described in the -FT chapter of the -<a href="http://www.omg.org/cgi-bin/doc?formal/02-06-01">CORBA -3.0 specification</a>. Specifically TAO implements the sections 23.2.2, -23.2.3, 23.2.6 thru 23.2.8 of the document. - -<p> -Basic support for <a href="ftcorba_services.html">FT CORBA services</a> has been added. -</p> - -<h4> -Future Work:</h4> - -<ul> -<li> -Implement 23.2.9 of the document.</li> -</ul> - -<hr> -<h3> -<a NAME="loadbalancer"></a>Load Balancer</h3> -Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a> -<h4> -Current Status:</h4> -TAO's -<a href="http://www.cs.wustl.edu/~schmidt/PDF/load_balancing.pdf">Load -Balancer</a> currently implements the latest revision of the OMG <i>Load -Balancing and Monitoring</i> proposed specification. -<p>It provides many features and advantages over the previous prototype. -Those features and advantages include: -<ul> -<li> -Multiple object group support</li> - -<li> -Extensible load balancing strategies through IDL interfaces</li> - -<li> -Extensible load monitoring</li> - -<li> -Both "push" and "pull" style monitoring are supported</li> - -<li> -Support for infrastructure and application controlled object group membership</li> - -<li> -Improved server-side transparency</li> -</ul> -The current proposed <i>Load Balancing and Monitoring</i> specification -defines three built-in load balancing strategies. They are: -<ol> -<li> -<tt>RoundRobin</tt> <font color="#0000FF">(non-adaptive)</font></li> - -<li> -<tt>Random</tt> <font color="#0000FF">(non-adaptive)</font></li> - -<li> -<tt>LeastLoaded</tt> <font color="#0000FF">(adaptive)</font></li> - -</ol> -TAO implements all of these and the following load balancing strategies: -<ol> -<li> -<tt>LoadAverage</tt> <font color="#0000FF">(adaptive)</font></li> - -<li> -<tt>LoadMinimum</tt> <font color="#0000FF">(adaptive)</font></li> - -</ol> -<h4> -Known Issues:</h4> - -<ul> -<li> -CPU load monitoring is not working in Windows. -</li> -</ul> - -<h4> -Recent Work:</h4> - -<ul> -<li> -Implemented <tt>LoadAverage</tt> load balancing strategy.</li> - -<li> -Implemented <tt>LoadMinimum</tt> load balancing strategy.</li> - -<li> -Implemented a CPU load utilization monitor in Linux. -</li> -</ul> - -<h4> -Future Work:</h4> - -<ul> -<li> -Implement cooperative (distributed) load balancing support</li> - -<li> -Integrate multicast support</li> -<li> -Implement a middleware load balancing performance measurement toolkit</li> -<li> -Implement self adaptive load balancing strategies</li> - -</ul> - -<hr> -<h3> -<a NAME="miop"></a>Multicast InterORB Protocol (MIOP)</h3> -Point of contact: <a href="mailto:fhunleth@cs.wustl.edu">Frank Hunleth</a> -<h4> -Current Status:</h4> -The final <a href="http://www.omg.org/cgi-bin/doc?ptc/2001-11-08">MIOP -specification</a> has recently been adopted by the OMG. TAO's MIOP support -(located in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup) enables servants to -receive requests sent to multicast addresses. This is performed by creating -a GroupId that identifies the multicast group and associating it with one -or more servants. Additionally, the Unreliable IP Multicast (UIPMC) pluggable -protocol is used to send and receive multicast requests. Multicast endpoints -can be created dynamically at runtime. -<h4> -Known Issues:</h4> - -<ul> -<li> -MIOP packet reassembly is not performed yet, so the maximum request size -is limited to about 5-6kb depending on the platform.</li> -</ul> - -<h4> -Recent Work:</h4> - -<ul> -<li> -Initial check in of MIOP implementation.</li> -</ul> - -<h4> -Future Work:</h4> - -<ul> -<li> -Allow group references to be disassociated when no longer needed.</li> - -<li> -Implement MIOP packet reassembly.</li> - -<li> -Implement a Multicast Group Manager (MGM).</li> - -<li> -Implement a Multicast Gateway (MG).</li> -</ul> - -<hr> -<h3> -<a NAME="apps"></a>Test & Performance Tests</h3> -[Note: This section is not uptodate. Use with caution. February 2004.] -<br> -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> -Pluggable: -<p>Current status: -<p>The TAO Pluggable test utilizes ACE Timeprobes to time the latency at -various points in the ORB, especially that incurred by the Pluggable Protocols -implementation. Comparisons can be made not only between different layers -of the ORB, but also between different protocols as they become available. -<p>Future work: -<ul> -<li> -Add options to redirect the output to a file.</li> - -<li> -Script or otherwise automate the piping of the output to a spreadsheet.</li> -</ul> - -<hr> -<h3> -<a NAME="ace"></a>ORB-related ACE Changes</h3> -Points of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a> -and <a href="mailto:irfan@cs.wustl.edu">Irfan Pyrarli</a> -<p>Recently Completed Work: -<ul> -<li> -Added special declaration to OS.h for <tt>inet_ntoa</tt> and other functions -because VxWorks doesn't provide full argument prototypes for these library -functions.</li> - -<li> -The current caching connector behaves properly in the face of a non-blocking -connect request. The "fix" is simply to not support non-blocking connects -through the cache. When the <tt>connect()</tt> fails with <tt>EWOULDBLOCK</tt>, -morph the error to -1 and clean up the request.</li> - -<li> -Service handlers obtained from the caching connector are now cleaned up. -The application needs to be able to signal that it's not using it any longer, -and, when the application encounters an error, needs to effectively close -down that connection for good so that a new connection can be initiated.</li> - -<br>Added the ability for a Svc_Handler to recycle itself. idle() can be -called when the Svc_Handler is done serving a particular connection and -can how be recycled. The Svc_Handler now also has a pointer to a recycler -that is responsible for managing the connections. The recycler is usually -a Cached_Connector. -<br>Added new class ACE_Recycling_Strategy. It defines the interface (and -default implementation) for specifying a recycling strategy for a Svc_Handler. -This strategy acts as a consular to the Svc_Handler, preparing it for the -tough times ahead when the Svc_Handler will be recycled. -<br>Added new class ACE_NOOP_Concurrency_Strategy. It implements a no-op -activation strategy in order to avoid calling open on a recycled svc_handler -multiple times. -<br>ACE_Cached_Connect_Strategy now implements the ACE_Connection_Recycling_Strategy -interface. This allows Svc_Handlers to cache themselves with ACE_Cached_Connect_Strategy -when they become idle. It also allows them to purge themselves from the -connection cache when the Svc_Handlers close down. -<br>Also added ~ACE_Cached_Connect_Strategy that will cleanup up the connection -cache.</ul> -Future work: -<blockquote><i>None currently scheduled.</i></blockquote> - -<hr> -<h3> -<a NAME="dove"></a>The DOVE Demo</h3> -Points of contact: <a href="mailto:mk1@cs.wustl.edu">Michael Kircher</a> -and <a href="mailto:cdgill@cs.wustl.edu">Chris Gill</a>. -<p><a href="http://www.cs.wustl.edu/~schmidt/dove.html">DOVE</a> is documented -in detail <a href="http://www.cs.wustl.edu/~schmidt/Dove.ps.gz">online</a>. -This discussion focuses on the following goals: -<ul> -<li> -Have a DOVE Browser running using Java Beans as vizualization components.</li> - -<li> -Have the Event Channel as DOVE Agent running with an Event Consumer in -the DOVE Browser.</li> - -<li> -Having a DOVE Management Information Base (MIB), which dumps all events -transfered on the Event Channel into a file on persistent storage for later -reuse.</li> -</ul> -The DOVE Browser uses independent visualization components (Java Beans) -and the Event Channel as DOVE Agent. Connections can be established between -monitored metrics and the visualization components. -<p>We have three major components: Observables (monitored metrics), Observers -(a Java Bean for displaying the metric) and a DataHandler (for demultiplexing -the monitored metrics to the appropriate Observables). Each component inherits -from a base class, so that a certain behavior of the components can be -assured for each component. Relationships between components are based -on these base classes. -<p>The used Java Beans are required to conform to some standards, as they -have to support a function called "getProperty" which allows the DOVE Browser -to determine if the vizualization capabilities of a specific Java Bean -are sufficient to display the metric. A JavaBean is for example a Java -Panel which shows a Graph of the delivered doubles. So all metrics can -be displayed by this visualization component which can be expressed by -a single double. -<p>The DataHandler is connected to the Event Push Consumer (PUSH, because -we use the push concept of the Event Service). The Event Push Consumer -does not know what kind of data is transported. The only component knowing -all the details about the dependencies of the metrics is the DataHandler. -This separation allows easy extension and change of the demo. -<p><a href="http://students.cec.wustl.edu/~mk1/dove.html">Object Diagrams</a> -are available about this new concept. -<p>Event Service events are used as communication between DOVE Applications -and the DOVE Browser. The DOVE MIB analyses the event data field of all -events and stores this information into a file. The event data filed is -of type CORBA::Any and the DOVE MIB has no notion of what is conveyed in -this field. So the DOVE MIB has to discover the content via the embedded -type code information. Future work includes: -<ul> -<li> -Enhancing MIB functionality</li> - -<li> -Monitoring the AV Streaming Service</li> -</ul> -For more information on the DOVE demo, please refer to: $TAO_ROOT/orbsvcs/tests/Simulator/README. -<p> -<hr> -<h3> -<a NAME="forwarding"></a>Location Forwarding</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../forwarding.html">Location forwarding</a> -<p> -<hr> -<h3> -<a NAME="leader"></a>Global Resources and Leader-Follower Model</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../leader_follower.html">Leader-follower -model</a> -<p> -<hr> -<h3> -<a NAME="locate"></a>Implementation of locate request</h3> -Point of contact: <a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a>, -<a href="mailto:mk1@mk1.wustl.edu">Michael -Kircher</a>. -<p>For more information see <a href="../locate_request.html">Locate request</a> -<p> -<hr> -<h3> -<a NAME="ami"></a>Asynchronous Method Invocation</h3> -Points of contact: <a href="mailto:alex@cs.wustl.edu">Alexander Arulanthu</a> -, <a href="mailto:Michael.Kircher@mchp.siemens.de">Michael Kircher</a> -and -<a href="mailto:coryan@uci.edu">Carlos O'Ryan</a> -<p>Status: -<ul>We've implemented the callback model of the -<a href="http://www.omg.org/cgi-bin/doc?formal/01-12-60">CORBA -Messaging specification</a>. To activate the AMI for TAO and the TAO IDL -compiler define <tt>TAO_HAS_CORBA_MESSAGING</tt>, -<tt>TAO_HAS_AMI_CALLBACK</tt> -in your config.h file. The TAO IDL compiler can generate the AMI "callback" -stubs, ReplyHandler und reply stubs using the <tt>-GC</tt> switch. -<p>For an example see <tt>$TAO_ROOT/tests/AMI</tt> and <tt>$TAO_ROOT/examples/AMI</tt>.</ul> -Finished work: -<ul> -<li> -Redesign of the IDL compiler to make an addtional pass over the AbstractSyntaxTree -and generate the implied-IDL code in memory. This reduced the amount of -AMI specific IDL compiler code dramatically.</li> - -<li> -Support for exceptions</li> - -<li> -Support for attributes</li> - -<li> -Support for buffering and batching AMI calls. See <a href="../../examples/Buffered_AMI">Buffered -AMI</a> example for details.</li> - -<li> -Support for deferred synchronous invocations. -<a href="mailto:j.parsons@vanderbilt.edu">Jeff -Parsons</a></li> - -<li> -Support for timeouts in combination with AMI calls, response handler gets -CORBA::TIMEOUT exception on timeout</li> -<li> -The AMI support in TAO 1.4.7 is as described in the 2.6 spec, from 1.4.8 we support -by default the 3.0.3 described mapping.</li> -</ul> -Future Work: -<ul> -<li> -Implementation of the poller model.</li> -</ul> -<hr> -<h3> -<a NAME="csd"></a>Custom Servant Dispatching</h3> -Points of contact: <a href="mailto:bradley_t@ociweb.com">Tim Bradley</a> -<h4> -Current Status:</h4> -<ul>This Custom Servant Dispatching (CSD) feature provides user applications with the ability to implement and "plug-in" custom strategies to handle the dispatching of requests to servants. -<p>A concrete CSD Strategy implementation has also been added to serve as a "reference implementation". This is being called the CSD Thread Pool Strategy (TP_Strategy). The TP_Strategy provides a means to decouple the threads (ORB threads) that receive requests from the underlying transport from the thread that will ultimately dispatch the request to the target servant object. The TP_Strategy implements a "request queue" as the integral part of the mechanism that allows an ORB thread to "hand-off" a request to one of the TP_Strategy object's worker threads. The TP_Strategy reference implementation is provided as an example of how concrete CSD Strategy could be implemented. -<p>Two approaches are supported for applying CSD strategy to an application. -<ol> -<li>Explicitly calling CSD interfaces. -<p>Here is an example application code showing how a TP_Strategy object can be created and applied to a POA: - -<pre> - - PortableServer::POA_var poa = ...; // create the poa. - - // Create a new TP_Strategy object and save it into a "smart pointer" variable. - TAO::CSD::TP_Strategy_Handle csd_strategy = new TAO::CSD::TP_Strategy(); - - // Set the number of threads before calling apply_to(). - csd_strategy->set_num_threads(2); - - // Set the servant serialization flag before calling apply_to(). - csd_strategy->set_servant_serialization (false); - - // Tell the strategy to apply itself to the poa. - if (csd_strategy->apply_to(poa.in()) == false) - { - ACE_ERROR((LM_ERROR, "Failed to apply CSD strategy to the poa.\n")); - return -1; - } -</pre> -<li>Service Configurator - - <p>The format of the CSD specific parameters for creating the TP_Strategy service object is: - <pre>-CSDtp <poa_name>:<csd_thread_number>:[OFF]</pre> - - <p>The last portion of the parameter is the servant serialization flag. It's only needed when the servant serialization needs be turned off, otherwise the servant serialization is always on. When servant serialization is on (the default), the TP_Strategy will serialize requests to any particular servant. Requests to different servant objects can occur in parallel, but requests to any particular servant will be dispatched serially (ie, one at a time). - - <p>Here is an example of the svc.conf file. - - <pre> - dynamic TAO_CSD_TP_Strategy_Factory Service_Object * - TAO_CSD_ThreadPool:_make_TAO_CSD_TP_Strategy_Factory() "-CSDtp RootPOA:2" - </pre> -</ol> -</ul> -<h4> -Known Issues:</h4> -<ul> -<li> -This feature is not currently tested for VxWorks. -</li> -</ul> -<hr> -<h3> -<a NAME="interceptor"></a>Portable Interceptors</h3> -Point of contact: <a href="mailto:ossama@dre.vanderbilt.edu">Ossama Othman</a>. -<p>For more information see <a href="../interceptors.html">Portable Interceptors</a> -<br> -<hr> -<h3> -<a NAME="localobject"></a>Local Interfaces</h3> -Point of contact: <a href="mailto:nanbor@cs.wustl.edu">Nanbor Wang</a>. -<p>Local interfaces are first defined in the CORBA Component Model specification. -For more information on using the local interfaces, please refers to Section -11.1.1 to 11.1.4 of the -<a href="http://www.omg.org/cgi-bin/doc?orbos/99-07-01/">spec</a> -and our short <a href="../LocalObject.html">guideline</a> on implementing -local objects. -<br> - - -<hr> -<h3> -<a NAME="sciop"></a>SCIOP Support in TAO</h3> -Point of contact: <a href="mailto:gthaker@atl.lmco.com">Gautam H. Thaker</a>, Lockheed Martin Advanced Technology Labs, Cherry Hill, NJ. - - -<p>TAO has support for OMG's GIOP SCTP Protocol mapping <a -href=http://www.omg.org/cgi-bin/doc?ptc/2003-08-20>spec</a>, except -that SCIOP protocol properties are not yet supported. Extensive -information about SCTP and how it may be used from both ACE and TAO is -available in several README files in $ACE_ROOT/performance-tests/SCTP/ -directory. ACE+TAO's SCTP support can be used either with Linux's -OpenSS7 SCTP implementation or with Linux's LKSCTP SCTP -implementation. <p> A paper describing the ACE+TAO SCTP -implementation and measured results are available <a -href=http://www.atl.external.lmco.com/projects/QoS/documents/DOA2003_97_Thaker.pdf> -online</a>.<P> - -<hr> -<h3> -<a NAME="ipv6"></a>IPv6 Support in TAO</h3> -Point of contact: <a href="mailto:mcorino@remedy.nl">Martin Corino</a>, Remedy IT. - - -<p>TAO has support for IPv6 for IIOP under Windows and Linux. -To use this, add <code>ipv6</code> to your <code>default.features</code> -file and regenerate all makefiles. When using the automated tests, add IPV6 -to the configs. -<p> -Finished work: -<li>Added IPv6 support to all IIOP related classes (parsers, connectors, - acceptors)</li> -<li>Added IPv6 support to corbaloc and mcast URL parsers.</li> -<li>Implemented IPv6 support in the TAO_IOR_MCast utility class from TAO Svc - Utils</li> -<p> - -The following gotchas are known: -<li>In a localhost situation connecting a server listening at the IPv6 ANY address - has the following problems: -On Linux this does not work when the client tries to connect to a - LinkLocal address of one the local NICs, -on Windows this only works (locally) by using the 'localhost' address (either - IPv4 or IPv6) -</li> -<li>Usage of the '-ORBObjRefStyle url' switch poses problems in localhost situations - on Windows since this switch causes 'object_to_string' to only return the first server - endpoint from the IOR profile as a corbaloc URL. In IPv6 servers this will (almost) allways be an IPv4 interface address of one - of the local NICs. This will than cause problems when the server is listening at - the IPv6 ANY address as described above. -</li> - -<p> -Future work: -<li>IPv6 support for other protocols/strategies than IIOP (i.e. SHMIOP, UIOP, - SCIOP, SSLIOP etc.; for this we excluded some regression tests in IPv6 builds for this - reason)</li> - -<li>IPv4 runtime dependencies in various CORBA services (f.i. Event service) -</li> - - -<P> - - - -<hr> -<h3> -<a NAME="CORBA-conformance"></a>CORBA Standards Conformance</h3> -Here is a summary of TAO's conformance issues with CORBA latest CORBA specifications -(updated 9 August 2000): -<br>2.3.1 and 2.3 differ in very little, if at all, check: -<br><a href="ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf">ftp://ftp.omg.org/pub/docs/formal/99-10-07.pdf</a> -<br>and search for the change bars, meanwhile this can help: -<ul> -<li> -The full OBV (valueboxes, valuetypes in all sorts of things, value graphs, -Anys and value types, abstract interfaces, etc. etc.)</li> - -<li> -The IfR database cannot be populated (so it is less than fully operational -;-))</li> - -<li> -Fixed data types (who cares)</li> - -<li> -GIOP fragments (1.1 and 1.2) are not completely tested.</li> - -<li> -The old ServantManager interfaces (POA stuff)</li> - -<li> -Domain Managers (useful for security, but otherwise nobody seems to care)</li> - -<li> -I think our interpretation of codesets is compliant (we only support one -codeset), but would have to check.</li> -</ul> -Future Work (aka. known problems): -<ul> -<li> -Supposedly, any constructed types that contains local types become local -automatically. TAO_IDL currently doesn't handle the array type very well -if one is defined outside the scope of a local interface.</li> - -<li> -Need to test local object support more systematically and comprehensively. -(Does TAO throw a MARSHAL exception when trying to marshal a local type?)</li> -</ul> - -<hr> -<p>Back to the TAO <a href="../index.html">documentation index</a>.<!--#include virtual="/~schmidt/cgi-sig.html" --> -<hr><!-- hhmts start -->Last modified: Thu May 4 13:08:35 UTC 2006<!-- hhmts end --> -</body> -</html> diff --git a/TAO/docs/releasenotes/notify.html b/TAO/docs/releasenotes/notify.html deleted file mode 100644 index b03a3cd5765..00000000000 --- a/TAO/docs/releasenotes/notify.html +++ /dev/null @@ -1,2601 +0,0 @@ -<HTML> -<BODY text="#000000" bgcolor="#FFFFFF"> -<!-- $Id$ --> - - <title>TAO's Notification Service</title> - -<H1><center>TAO's Notification Service</center> </H1><p> -<p> -<ul> - -<li> -<a href="#notify_service">Options to Notify_Service</a> -</li> - -<li> -<a href="#feature_matrix">Feature Matrix</a> -</li> - - -<li> -<a href="#test_framework">Notification Service Testing framework</a> -</li> -</ul> - -<HR> -<H2><center><a NAME="notify_service"></a>Options to Notify_Service</center> </H2><p> -<HR> - -The <a href="../../orbsvcs/Notify_Service"> Notify_Service </a> driver program options are: <br> - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=40%>Command</TH> -<TH >Description</TH> -</TR> - -<TR> -<TD> -Factory factory_name -</TD> - -<TD> -Uses the <factory_name> as the default name for the Channel Factory. -The default is "NotifyEventChannelFactory". -</TD> -</TR> - -<TR> -<TD>-Boot </TD> - -<TD> -Flag asking that the factory_name be registered -in the IOR table. -The option is disabled by default. -See the "Using the Boot option" section in the <a href="../../orbsvcs/Notify_Service/README"> README </a> for details. -</TD> - -</TR> - -<TR> -<TD>-NameSvc </TD> - -<TD> -Registers the Factory and if specified, an Event - Channel with the Naming Service. - if this option is used, a Naming Service must - be accessible. - This option is enabled by default. -</TD> -</TR> - -<TR> -<TD>-NoNameSvc</TD> - -<TD>Asks to skip any registration with the - Naming Service. - This option is disabled by default. -</TD> -</TR> - -<TR> - -<TD>-IORoutput file_name</TD> - -<TD>The IOR is output to the file file_name. - By default, the IOR is printed out. -</TD> - -</TR> - -<TR> -<TD>-Channel </TD> - -<TD>If this option is specified, a EventChannel is - created and registered with the Naming Service. - This option is disabled by default. -</TD> -</TR> - -<TR> -<TD>-ChannelName channel_name </TD> -<TD> - Specifes the channel_name to register with the - Naming Service. - The default is "NotifyEventChannel". -</TD> -</TR> - -<TR> -<TD>-ORBRunThreads threads</TD> -<TD> Specifies the number of threads that will run the ORB::run method. -</TD> -</TR> - -</TABLE> -<p> -The Notify_Service driver can be used to load the CosNotification service or it's Real-Time CORBA extension, the RT-Notification.<br> -By using the svc.conf file, the appropriate service is loaded. -<p>To load the CosNotification do: <br> - -<tt> -dynamic TAO_Notify_Service Service_Object * TAO_CosNotification:_make_TAO_CosNotify_Service () "" -</tt> -<p> or <br> -<tt> static TAO_CosNotify_Service "" </tt> - -<p> -To load the RT-Notification Service, do: <br> -<tt> dynamic TAO_Notify_Service Service_Object * TAO_RT_Notification:_make_TAO_RT_Notify_Service () "" -</tt> -<p> - -If your application links to the RT-Notification library, you can configure the RT-Notification statically via: <br> -<tt> static TAO_RT_Notify_Service "" </tt> - -<p> The service objects also accept the following options to control concurrency in the Notification. <br> -Note that the <a href="#rt_ext">Notification extensions </a> allow threads to be specified at the EventChannel, Admin and Proxy levels via QoS parameters at run-time. - <br> - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=40%>Option</TH> -<TH >Description</TH> -</TR> - -<TR> -<TD> -DispatchingThreads [thread_count] -</TD> - -<TD> -Specifies the number of threads for dispatching. -</TD> -</TR> - -<TR> -<TD> -SourceThreads [thread_count] -</TD> - -<TD> -Specifies the number of threads for ProxyConsumer filter evaluation. -</TD> -</TR> - -<TR> -<TD> -ListenerThreads [thread_count] -</TD> - -<TD> -Specifies the number of threads for ProxySupplier filter evaluation. -</TD> -</TR> - -<TR> -<TD> -AsynchUpdates -</TD> - -<TD> -Send subscription and publication updates asynchronously. -</TD> -</TR> - -<TR> -<TD> -NoUpdates -</TD> - -<TD> -Do not send any subscription and publication updates. -</TD> -</TR> - -<TR> -<TD> -AllocateTaskperProxy -</TD> - -<TD> -Allocate threads for the -LookupThreads and -ListenerThreads <b> per proxy </b> <br> -See the README for further explaination.<br> -</TD> -</TR> - -</TABLE> - - - -<hr> -<H2><center><a NAME="feature_matrix"></a>Feature matrix for the Cos Notification Service</center> </H2><p> -<hr> -<H4>Supported Interfaces</H4> - -<a href="#qos_admin">CosNotification::QoSAdmin</a><br> -<a href="#admin_prop_admin">CosNotification::AdminPropertiesAdmin</a><br> -<a href="#notify_publish">CosNotifyComm::NotifyPublish</a><br> -<a href="#notify_subscribe">CosNotifyComm::NotifySubscribe</a><br> -<a href="#push_consumer">CosNotifyComm::PushConsumer</a><br> -<a href="#push_supplier">CosNotifyComm::PushSupplier</a><br> -<a href="#structured_push_consumer">CosNotifyComm::StructuredPushConsumer</a><br> -<a href="#structured_push_supplier">CosNotifyComm::StructuredPushSupplier</a><br> -<a href="#sequence_push_consumer">CosNotifyComm::SequencePushConsumer</a><br> -<a href="#sequence_push_supplier">CosNotifyComm::SequencePushSupplier</a><br> -<a href="#filter">CosNotifyFilter::Filter</a><br> -<a href="#filter">CosNotifyFilter::MappingFilter</a><br> -<a href="#filter_factory">CosNotifyFilter::FilterFactory</a><br> -<a href="#filter_admin">CosNotifyFilter::FilterAdmin</a><br> -<a href="#proxy_consumer">CosNotifyChannelAdmin::ProxyConsumer </a><br> -<a href="#proxy_supplier">CosNotifyChannelAdmin::ProxySupplier </a><br> - -<a href="#proxy_push_consumer">CosNotifyChannelAdmin::ProxyPushConsumer </a><br> -<a href="#structured_proxy_push_consumer">CosNotifyChannelAdmin::StructuredProxyPushConsumer </a><br> -<a href="#sequence_proxy_push_consumer">CosNotifyChannelAdmin::SequenceProxyPushConsumer </a><br> - -<a href="#proxy_push_supplier">CosNotifyChannelAdmin::ProxyPushSupplier </a><br> -<a href="#structured_proxy_push_supplier">CosNotifyChannelAdmin::StructuredProxyPushSupplier </a><br> -<a href="#sequence_proxy_push_supplier">CosNotifyChannelAdmin::SequenceProxyPushSupplier </a><br> - -<a href="#consumer_admin">CosNotifyChannelAdmin::ConumerAdmin </a><br> -<a href="#supplier_admin">CosNotifyChannelAdmin::SupplierAdmin </a><br> -<a href="#event_channel">CosNotifyChannelAdmin::EventChannel </a><br> -<a href="#event_channel_factory">CosNotifyChannelAdmin::EventChannelFactory </a><br> - -<H4>UnSupported Interfaces</H4> - -<a href="#pull_consumer">CosNotifyComm::PullConsumer</a><br> -<a href="#pull_supplier">CosNotifyComm::PullSupplier</a><br> -<a href="#structured_pull_consumer">CosNotifyComm::StructuredPullConsumer</a><br> -<a href="#structured_pull_supplier">CosNotifyComm::StructuredPullSupplier</a><br> - -<a href="#sequence_pull_consumer">CosNotifyComm::SequencePullConsumer</a><br> -<a href="#sequence_pull_supplier">CosNotifyComm::SequencePullSupplier</a><br> - -<a href="#proxy_pull_supplier">CosNotifyChannelAdmin::ProxyPullSupplier </a><br> -<a href="#structured_proxy_pull_supplier">CosNotifyChannelAdmin::StructuredProxyPullSupplier </a><br> -<a href="#sequence_proxy_pull_supplier">CosNotifyChannelAdmin::SequenceProxyPullSupplier </a><br> -<a href="#proxy_pull_consumer">CosNotifyChannelAdmin::ProxyPullConsumer </a><br> -<a href="#structured_proxy_pull_consumer">CosNotifyChannelAdmin::StructuredProxyPullConsumer </a><br> -<a href="#sequence_proxy_pull_consumer">CosNotifyChannelAdmin::SequenceProxyPullConsumer </a><br> - -<a NAME="rt_ext"><H4>Interfaces Extensions for RTCORBA support</H4> </a> -<a href="#ext_ecf">NotifyExt::EventChannelFactory</a><br> -<a href="#ext_ca">NotifyExt::ConsumerAdmin</a><br> -<a href="#ext_sa">NotifyExt::SupplierAdmin</a><br> - -<a NAME="qos_admin"></a><HR> - <B>Interface </B> : <CODE>CosNotification::QoSAdmin </CODE><br> -<B>Base Interface(s) </B> : none<br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>get_qos</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>set_qos</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a href="../../orbsvcs/tests/Notify/Ordering"> Ordering </a> - <a href="../../orbsvcs/tests/Notify/Discarding"> Discarding </a> - <br> - </TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>validate_qos</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -QoS Properties support on all interfaces supporting CosNotification::QoSAdmin -<ul> -<li> EventReliability : Not supported</li> -<li> ConnectionReliability : Not supported </li> -<li> Priority : Supported Per Message, Priority applied to Channel, -Admin or proxy Objects are NOT applied to the events. - -<li> StartTime : Not supported </li> -<li> StopTime : Not Supported </li> - -<li> Timeout : Supported Per Message, Timeouts applied to Channel, -Admin or proxy Objects are NOT applied to the events. - -<li> StartTimeSupported : Not Supported </li> -<li> StopTimeSupported : Not Supported </li> - -<li> MaxEventsPerConsumer : Supported (Only applies to ProxySuppliers) -</li> - -<li> OrderPolicy : Supported policies - PriorityOrder, AnyOrder, FifoOrder, -LifoOrder, DeadlineOrder </li> - -<li> DiscardPolicy : : Supported policies - PriorityOrder, AnyOrder, FifoOrder, -LifoOrder, DeadlineOrder </li> - -<li>MaximumBatchSize : Supported and applied to SequenceProxySuppliers -</li> - -<li>PacingInterval : Supported and applied to SequenceProxySuppliers -</li> -</ul> - -<a NAME="admin_prop_admin"></a><HR> -<B>Interface </B> : <CODE>CosNotification::AdminPropertiesAdmin </CODE><br> -<B>Base Interface(s) </B> : none<br> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>get_admin</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>set_admin</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a href="../../orbsvcs/tests/Notify/Basic/"> Events -</a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="notify_publish"></a><HR> -<B>Interface </B> : <CODE>CosNotifyComm::NotifyPublish </CODE><br> -<B>Base Interface(s) </B> : none<br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>offer_change</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/"> Updates </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="notify_subscribe"></a><HR><B>Interface </B> : <CODE>CosNotifyComm::NotifySubscribe </CODE><br> -<B>Base Interface(s) </B> : none<br> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>subscription_change</CODE></TD> - <TD>Yes</TD> - <TD> see <a -href="../../orbsvcs/tests/Notify/Basic/"> Updates </a></TD> - <TD></TD> - </TR> -</TABLE> </P> - - -<a NAME="push_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::PushConsumer </CODE><br> -<B>Base Interface(s) </B> : <CODE><a href="#notify_publish">CosNotifyComm::NotifyPublish</a></CODE>, CosEventComm::PushConsumer <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE> CosEventComm::PushConsumer::push</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/"> MultiTypes,Simple </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE> CosEventComm::PushConsumer::disconnect_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="pull_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::PullConsumer </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="push_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::PushSupplier </CODE><br> -<B>Base Interface(s) </B> : <CODE><a href="#notify_subscribe"> CosNotifyComm::NotifySubscribe</a>, CosEventComm::PushSupplier</CODE> <br> -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE> CosEventComm::PushConsumer::disconnect_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic"> ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - - -<a NAME="pull_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::PullSupplier </CODE><br> -<B> Not Supported </B>. -</P> - - -<a NAME="structured_push_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyComm::StructuredPushConsumer </CODE><br> -<B>Base Interface(s) </B><a href="#notify_publish"> CosNotifyComm::NotifyPublish</a> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>push_structured_event</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic">MultiTypes </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>disconnect_structured_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic">ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="structured_pull_consumer"></a> -<HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::StructuredPullConsumer </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="structured_pull_supplier"></a> -<HR><P><B>Interface </B> : <CODE>CosNotifyComm::StructuredPullSupplier </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="structured_push_supplier"></a> -<HR><B>Interface </B> : <CODE>CosNotifyComm::StructuredPushSupplier </CODE><br> -<B>Base Interface(s) </B> <a href="#notify_subscribe"> -CosNotifyComm::NotifySubscribe </a> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>disconnect_structured_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="sequence_push_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyComm::SequencePushConsumer </CODE><br> -<B>Base Interface(s) </B><a href="#notify_publish"> <CODE>CosNotifyComm::NotifyPublish</CODE> </a><br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>push_structured_events</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>disconnect_sequence_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="sequence_pull_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::SequencePullConsumer </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="sequence_pull_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyComm::SequencePullSupplier </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="sequence_push_supplier"></a><HR> -<B>Interface </B> : <CODE>CosNotifyComm::SequencePushSupplier </CODE><br> -<B>Base Interface(s) </B> <a href="#notify_subscribe"> -CosNotifyComm::NotifySubscribe </a> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>disconnect_sequence_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="filter"></a><HR><B>Interface </B> : <CODE>CosNotifyFilter::Filter </CODE><br> -<B>Base Interface(s) </B> none <br> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>constraint_grammar</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>add_constraints</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter</a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>modify_constraints</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_constraints</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_all_constraints</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>remove_all_constraints</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>destroy</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>match</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>match_structured</CODE></TD> - <TD>Yes</TD> - <TD>yes, called internally by Notification during -execution of <a -href="../../orbsvcs/tests/Notify/Structured_Filter/">Structured_Filter</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>match_typed</CODE></TD> - <TD>No</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>attach_callback</CODE></TD> - <TD>No</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>detach_callback</CODE></TD> - <TD>No</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_callbacks</CODE></TD> - <TD>No</TD> - <TD>No</TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<HR><P> -<a NAME="mapping_filter"></a><B>Interface </B> : <CODE>CosNotifyFilter::MappingFilter </CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="filter_factory"></a><HR><B>Interface </B> : <CODE>CosNotifyFilter::FilterFactory </CODE><br> -<B>Base Interface(s) </B> none <br> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>create_filter</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>create_mapping_filter</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - -</TABLE> </P> - - -<a NAME="filter_admin"></a><HR><B>Interface </B> : <CODE>CosNotifyFilter::FilterAdmin </CODE><br> -<B>Base Interface(s) </B> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>add_filter</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>remove_filter</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_filter</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_all_filters</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>remove_all_filters</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="proxy_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxyConsumer </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#qos_admin">CosNotification::QoSAdmin </a><CODE>, -<CODE><a href="#filter_admin"> CosNotifyFilter::FilterAdmin </a></CODE> <br> - - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>MyType</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyAdmin</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_subscription_types</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic"> Updates </a></TD> - <TD>Only CosNotifyChannelAdmin::ALL_NOW_UPDATES_ON tested</TD> - </TR> - - <TR> - <TD><CODE>validate_event_qos</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="proxy_supplier"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxySupplier </CODE><br> -<B>Base Interface(s) </B> <CODE><a href="#qos_admin"> CosNotification::QoSAdmin </a><CODE>, -<CODE> <a href="#filter_admin"> CosNotifyFilter::FilterAdmin </a> </CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>MyType</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyAdmin</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>priority_filter</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - - <TR> - <TD><CODE>lifetime_filter</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_offered_types</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Updates </a></TD> - <TD>Only CosNotifyChannelAdmin::ALL_NOW_UPDATES_ON tested</TD> - </TR> - - <TR> - <TD><CODE>validate_event_qos</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="proxy_push_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxyPushConsumer </CODE><br> -<B>Base Interface(s) </B> <CODE> <a -href="#proxy_consumer">CosNotification::ProxyConsumer </a>, -<a href="#push_consumer"> CosNotifyComm::PushConsumer <CODE> </a><br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_any_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes,ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="structured_proxy_push_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::StructuredProxyPushConsumer </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#proxy_consumer"> -CosNotification::ProxyConsumer </a>, -<a href="#structured_push_consumer"> -CosNotifyComm::StructuredPushConsumer </a> <CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_structured_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes,ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="sequence_proxy_push_consumer"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::SequenceProxyPushConsumer </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#proxy_consumer"> -CosNotification::ProxyConsumer </a>, -<a href="#sequence_push_consumer"> CosNotifyComm::SequencePushConsumer -</a> <CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_sequence_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes,ConnectDisconnect </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="proxy_pull_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxyPullSupplier</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="structured_proxy_pull_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::StructuredProxyPullSupplier</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="sequence_proxy_pull_supplier"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::SequenceProxyPullSupplier</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="proxy_pull_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxyPullConsumer</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="structured_proxy_pull_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::StructuredProxyPullConsumer</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="sequence_proxy_pull_consumer"></a><HR><P> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::SequenceProxyPullConsumer</CODE><br> -<B> Not Supported </B>. -</P> - -<a NAME="proxy_push_supplier"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ProxyPushSupplier </CODE><br> -<B>Base Interface(s) </B> <CODE> CosNotification::ProxySupplier, -CosNotifyComm::PushSupplier <CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_any_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes,ConnectDisconnect </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>suspend_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>resume_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="structured_proxy_push_supplier"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::StructuredProxyPushSupplier </CODE><br> -<B>Base Interface(s) </B> <CODE> CosNotification::ProxySupplier, -CosNotifyComm::StructuredPushSupplier <CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_structured_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/"> MultiTypes,ConnectDisconnect -</a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>suspend_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>resume_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="sequence_proxy_push_supplier"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::SequenceProxyPushSupplier </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#proxy_supplier"> -CosNotification::ProxySupplier </a>, -<a href="#sequence_push_supplier"> CosNotifyComm::SequencePushSupplier -</a><CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>connect_sequence_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes,ConnectDisconnect </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>suspend_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>resume_connection</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="consumer_admin"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::ConsumerAdmin </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#qos_admin"> -CosNotification::QoSAdmin </a> - , <a href="#notify_subscribe"> CosNotifyComm::NotifySubscribe </a> - , <a href="#filter_admin"> CosNotifyFilter::FilterAdmin </a> - , CosEventChannelAdmin::ConsumerAdmin </CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::ConsumerAdmin::obtain_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - - <TR> - <TD><CODE>CosEventChannelAdmin::ConsumerAdmin::obtain_pull_supplier</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyID</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyChannel</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyOperator</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>priority_filter</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>lifetime_filter</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>pull_suppliers</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>push_suppliers</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_proxy_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Updates </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_notification_pull_supplier</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_notification_push_supplier</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see -<a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes, ConnectDisconnect -</a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>destroy</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">LifeCycle, IdAssignment </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="supplier_admin"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::SupplierAdmin </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#qos_admin"> -CosNotification::QoSAdmin </a> - , <a href="#notify_publish"> CosNotifyComm::NotifyPublish </a> - , <a href="#filter_admin"> CosNotifyFilter::FilterAdmin </a> - , CosEventChannelAdmin::SupplierAdmin </CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::SupplierAdmin::obtain_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::SupplierAdmin::obtain_pull_consumer</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyID</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyChannel</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyOperator</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>pull_consumers</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>push_consumers</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_proxy_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Updates </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_notification_pull_supplier</CODE></TD> - <TD>No</TD> - <TD></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>obtain_notification_push_consumer</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">MultiTypes, ConnectDisconnect -</a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>destroy</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/"> LifeCycle, IdAssignment </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="event_channel"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::EventChannel </CODE><br> -<B>Base Interface(s) </B> <CODE> <a href="#qos_admin"> -CosNotification::QoSAdmin </a> - , <a href="#admin_prop_admin"> -CosNotification::AdminPropertiesAdmin </a> - , CosEventChannelAdmin::EventChannel </CODE> <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::EventChannel::for_consumers</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::EventChannel::for_suppliers</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>CosEventChannelAdmin::EventChannel::destroy</CODE></TD> - <TD>Yes</TD> - <TD>yes, see <a -href="../../orbsvcs/tests/Notify/Basic/"> Events, Filter </a> </TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>MyFactory</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>default_consumer_admin</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Events </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>default_supplier_admin</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Events </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>default_filter_factory</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Filter </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>new_for_consumers</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Simple,Events </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>new_for_suppliers</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Simple,Events </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_consumeradmin</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">IdAssignment </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_supplieradmin</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">IdAssignment </a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_all_consumeradmins</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_all_supplieradmins</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - -</TABLE> </P> - - -AdminProperties supported at the EventChannel are: -<ul> -<li> -MaxQueueLength, MaxConsumers, MaxSuppliers, RejectNewEvents -</li> -</ul> - -see <a href="../../orbsvcs/tests/Notify/Basic/"> AdminProperties </a> - -<a NAME="event_channel_factory"></a><HR> -<B>Interface </B> : <CODE>CosNotifyChannelAdmin::EventChannelFactory </CODE><br> -<B>Base Interface(s) </B>: none <br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>create_channel</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">Events,Simple</a></TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_all_channels</CODE></TD> - <TD>Yes</TD> - <TD>No</TD> - <TD></TD> - </TR> - - <TR> - <TD><CODE>get_event_channel</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a -href="../../orbsvcs/tests/Notify/Basic/">IdAssignment </a></TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="ext_ecf"></a><HR> - <B>Interface </B> : <CODE>NotifyExt::EventChannelFactory</CODE><br> -<B>Base Interface(s) </B> : CosNotifyChannelAdmin::EventChannelFactory<br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>destroy</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a href="../../orbsvcs/tests/Notify/Destroy"> Destroy </a> - </TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="ext_ca"></a><HR> - <B>Interface </B> : <CODE>NotifyExt::ConsumerAdmin</CODE><br> -<B>Base Interface(s) </B> : CosNotifyChannelAdmin::ConsumerAdmin<br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>obtain_notification_push_supplier_with_qos</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a href="../../orbsvcs/tests/Notify/Lanes"> Lanes </a> - </TD> - <TD></TD> - </TR> - -</TABLE> </P> - -<a NAME="ext_sa"></a><HR> - <B>Interface </B> : <CODE>NotifyExt::SupplierAdmin</CODE><br> -<B>Base Interface(s) </B> : CosNotifyChannelAdmin::SupplierAdmin<br> - -<P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> - <TR> - <TH>Method</TH> - <TH>Supported</TH> - <TH>Tested</TH> - <TH>Notes</TH> - </TR> - - <TR> - <TD><CODE>obtain_notification_push_consumer_with_qos</CODE></TD> - <TD>Yes</TD> - <TD>Yes, see <a href="../../orbsvcs/tests/Notify/Lanes"> Lanes </a> - </TD> - <TD></TD> - </TR> - -</TABLE> </P> - -The additional QoS properties supported are: <br> - -<ul> -<li> -ThreadPoolParams -</li> - -<li> -ThreadPoolLanesParams -</li> -</ul> - -see the <a href="../../orbsvcs/orbsvcs/NotifyExt.idl"> NotifyExt.idl </a> file for the QoS definitions. - -<P> -<HR> -<H2><center><a NAME="test_framework"></a>Scripting Options for Notification Service Testing framework</center> </H2><p> -<HR> - -The Notification Service Testing framework uses the Service Configurator to load various command objects. <br> -The <tt>Command_Builder</tt> object is used to load the target objects. <br> -To test the various Notification features we then write scripts to rapidly reproduce test cases.<br> - -The <a href="../../orbsvcs/tests/Notify/Driver" >Notify_Test_Driver </a> program reads a svc.conf file and executes the commands specified. <br> -The following options can specified to the Driver program: <p> - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=40%>Command</TH> -<TH>Description</TH> -</TR> - -<TR> - -<TD>-Timeout timeout_period_in_seconds</TD> - -<TD> Specify the timeout period for this test</TD> - -</TR> - -<TR> - -<TD>-IORoutput output_file_name</TD> - -<TD> Output the IOR of the <a href="../../orbsvcs/tests/Notify/lib/Activation_Manager.idl" >Activation Manager </a>.<br> -This is used by a client to signal its peer.</TD> - -</TR> - -<TR> - -<TD>-IORinput file://input_file_name</TD> - -<TD> - Input the IOR of the peer's <a href="../../orbsvcs/tests/Notify/lib/Activation_Manager.idl" >Activation Manager </a>.<br> -This is used to signal the peer. -</TD> - -</TR> - -<TR> -<TD>-Skip_Priority_Levels_Check</TD> - -<TD> -Skip the check for multiple priority levels. -</TD> - -</TR> - -</TABLE> -<p> -See the *.conf files in <a href="../../orbsvcs/tests/Notify/Lanes" >Lanes </a> -and -<a href="../../orbsvcs/tests/Notify/ThreadPool" >ThreadPool </a> -for examples of the test framework in use. - -<p> -The options that can be specified to each target object are as follows: -<p> - -<h3>Target Object : <b> EventChannel </b></h3> -Loading Syntax: dynamic TAO_Notify_EventChannel_Command_Factory Service_Object *TAO_NotifyTests:_make_TAO_Notify_EventChannel_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create </TD> -<TD WIDTH=60%>Name_of_channel <br> Name_of_EventChannelFactory <br> [COLLOCATED] -</TD> -<TD>Create an Event Channel</TD> -</TR> -</TABLE> - -<br><b>Example : </b> static Command_Builder "EventChannel -Create ec1 NotifyEventChannelFactory" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Destroy</TD> -<TD WIDTH=60%>Name_of_channel -</TD> -<TD>Destroy an Event Channel</TD> -</TR> -</TABLE> - -<br><b>Example : </b> static Command_Builder "EventChannel -Destroy ec1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Set_QoS</TD> -<TD > -Name_of_channel [QoS_Options] -</TD> - -<TD>Set QoS parameters on an event channel -</TD> -</TR> -</TABLE> -<br> -QoS_Options = -ThreadPool [-Threads thread_pool_size (default= 1) ] - -[-Priority default_priority (default=ACE_DEFAULT_THREAD_PRIORITY)] -| - --Lanes lane_count [-Lane priority static_threads dynamic_threads]* - -<p><b>Example : </b>: static Command_Builder "EventChannel -Set_QoS -ThreadPool Threads 2 -Priority 2" -<br><b>Example : </b>: static Command_Builder "EventChannel -Set_QoS -Lanes 2 -Lane 10 1 0 -Lane 30 2 1" - -<hr> - -<h3>Target Object : <b> ConsumerAdmin </b></h3> -Loading Syntax: dynamic TAO_Notify_ConsumerAdmin_Command_Factory Service_Object *TAO_NotifyTests:_make_TAO_Notify_ConsumerAdmin_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create</TD> -<TD> -Name_of_Admin <br> - -Name_of_EventChannel <br> - -[-AND_OP | OR_OP (default = CosNotifyChannelAdmin::OR_OP)] - -</TD> -<TD>Create a ConsumerAdmin</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "ConsumerAdmin -Create ca1 ec1 -AND_OP" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Subscription</TD> -<TD> -Name_of_Admin <br> - -+added_type1 +added_type2 ... -removed_type3 -removed_type4 ... -</TD> - -<TD>Send subscription updates to the ConsumerAdmin. Note that domain name is set to "*". -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "ConsumerAdmin -Subscription ca1 +Red +Green -Blue" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Set_QoS</TD> -<TD > -Name_of_Admin [QoS_Options] -</TD> - -<TD> -Set QoS options for ConsumerAdmin -</TD> - -</TR> -</TABLE> -<P> -QoS_Options = -ThreadPool [-Threads thread_pool_size (default= 1) ] - -[-Priority default_priority (default=ACE_DEFAULT_THREAD_PRIORITY)] -| - --Lanes lane_count [-Lane priority static_threads dynamic_threads]* - -<p><b>Example : </b>: static Command_Builder "ConsumerAdmin -Set_Qos -ThreadPool Threads 2 -Priority 2" -<br><b>Example : </b>: static Command_Builder "ConsumerAdmin -Set_Qos -Lanes 2 -Lane 10 1 0 -Lane 30 2 1" - -<hr> -<h3>Target Object : <b> SupplierAdmin </b></h3> -Loading Syntax: dynamic TAO_Notify_SupplierAdmin_Command_Factory Service_Object *TAO_NotifyTests:_make_TAO_Notify_SupplierAdmin_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create</TD> -<TD> -Name_of_Admin <br> - -Name_of_EventChannel <br> - -[-AND_OP | OR_OP (default = CosNotifyChannelAdmin::OR_OP)] - -</TD> -<TD>Create a SupplierAdmin</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "SupplierAdmin -Create sa1 ec1 -AND_OP" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Offer</TD> -<TD> -Name_of_Admin <br> - -+added_type1 +added_type2 ... -removed_type3 -removed_type4 ... -</TD> - -<TD>Send offer updates to the SupplierAdmin. Note that domain name is set to "*". -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "SupplierAdmin -Offer ca1 +Red +Green -Blue" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Set_QoS</TD> -<TD > -Name_of_Admin [QoS_Options] -</TD> - -<TD> -Set QoS options for SupplierAdmin -</TD> - -</TR> -</TABLE> -<P> -QoS_Options = -ThreadPool [-Threads thread_pool_size (default= 1) ] - -[-Priority default_priority (default=ACE_DEFAULT_THREAD_PRIORITY)] -| - --Lanes lane_count [-Lane priority static_threads dynamic_threads]* - -<p><b>Example : </b>: static Command_Builder "SupplierAdmin -Set_Qos -ThreadPool Threads 2 -Priority 2" -<br><b>Example : </b>: static Command_Builder "SupplierAdmin -Set_Qos -Lanes 2 -Lane 10 1 0 -Lane 30 2 1" - -<hr> -<h3>Target Object : <b> PeriodicConsumer </b></h3> -Loading Syntax: dynamic TAO_Notify_Periodic_Consumer_Command_Factory Service_Object* TAO_NotifyTests:_make_TAO_Notify_Periodic_Consumer_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create</TD> -<TD> -Name_of_Consumer<br> - -[-Relay relay_destination] <br> -[-Direct] <br> - -[-Admin Name_of_ConsumerAdmin] <br> - -[-POA name_of_POA (default = RootPOA)]<br> - -[-Proxy proxy_name] <br> - -[-Set_QoS [Qos_Options]] <br> - -[-MaxCount expected_number_of_events] <br> - -[-Check_Priority] - -</TD> -<TD>Create a PeriodicConsumer. The consumer is activated in the POA specified. -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "PeriodicConsumer -Create c1 ca1 -POA myPOA -Proxy ca1_proxy -MaxCount 10" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Subscription</TD> -<TD> -Name_of_Consumer <br> - -+added_type1 +added_type2 ... -removed_type3 -removed_type4 ... - -</TD> - -<TD> -static Command_Builder "PeriodicConsumer -Subscription ca1 +Red +Green -Blue" -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: Send subscription updates to its proxy. Note that domain name is set to "*". - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Disconnect</TD> -<TD> -Name_of_Consumer -</TD> - -<TD>Disconnect the Consumer from the EventChannel. -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder -PeriodicConsumer "Disconnect ca1" - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Deactivate</TD> -<TD> -Name_of_Consumer -</TD> - -<TD>Deactivate the Consumer from its POA </TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "-PeriodicConsumer -Deactivate ca1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Status</TD> -<TD> -Name_of_Consumer -</TD> -<TD>Print the status of the consumer. - -Checks if the proxy is alive. -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "-PeriodicConsumer -Status ca1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Set_QoS</TD> -<TD > -Name_of_consumer [QoS_Options] -</TD> - -<TD>Set QoS parameters on a Periodic Consumer. The actual QoS settings are applied to the corresponding ProxySupplier. -</TD> -</TR> -</TABLE> -<br> -QoS_Options = -ThreadPool [-Threads thread_pool_size (default= 1) ] - -[-Priority default_priority (default=ACE_DEFAULT_THREAD_PRIORITY)] -| - --Laness lane_count [-Lane priority static_threads dynamic_threads]* - -<p><b>Example : </b>: static Command_Builder "PeriodicConsumer -Set_QoS -ThreadPool Threads 2 -Priority 2" -<br><b>Example : </b>: static Command_Builder "PeriodicConsumer -Set_QoS -Lanes 2 -Lane 10 1 0 -Lane 30 2 1" - -<hr> -<h3>Target Object : <b> PeriodicSupplier </b></h3> -Loading Syntax: dynamic TAO_Notify_Periodic_Supplier_Command_Factory Service_Object* TAO_NotifyTests:_make_TAO_Notify_Periodic_Supplier_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create</TD> -<TD> - -Name_of_Supplier <br> - -[-Direct direct_target]<br> - -[-Admin Name_of_ConsumerAdmin] <br> - -[-POA name_of_POA (default = RootPOA)]<br> - -[-Proxy proxy_name] <br> - -[-Set_QoS [Qos_Options]] <br> - --EventType type_of_event <br> - --FilterLongData name long_filterable_data <br> - --Priority supplier_thread_priority <br> - --Period sending_period (in microseconds) <br> - --ExecTime estimated_time_per_send_operation <br> - --Phase supplier_thread_starting_phase <br> - --Iter number_of_events-to_send <br> - --Load hint_to_consumer <br> - --RunTime time_to_run_in_sec -</TD> - -<TD> -Create a PeriodicSupplier. - -The supplier is activated in the POA specified. -<br> -The -Create command spawns a thread that sends periodic events. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "PeriodicSupplier -Create s1 sa1_ec1 -Proxy s1_proxy -EventType RED -FilterLongData Temp 3 -Priority 0 -Period 10000 -ExecTime 10000 -Phase 0 -Iter 1 -Load 1 " - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Offer</TD> -<TD> -Name_of_Supplier <br> - -+added_type1 +added_type2 ... -removed_type3 -removed_type4 ... - -</TD> - -<TD> -static Command_Builder "PeriodicSupplier -Offer sa1 +Red +Green -Blue" -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: Send offer updates to its proxy. Note that domain name is set to "*". - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Disconnect</TD> -<TD> -Name_of_Supplier -</TD> - -<TD>Disconnect the Supplier from the EventChannel. -</TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder -PeriodicSupplier "Disconnect sa1" - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Deactivate</TD> -<TD> -Name_of_Supplier -</TD> - -<TD>Deactivate the Supplier from its POA </TD> - -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "-PeriodicSupplier -Deactivate ca1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>Status</TD> -<TD> -Name_of_Supplier -</TD> -<TD>Print the status of the consumer. - -Checks if the proxy is alive. -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "-PeriodicSupplier -Status sa1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Set_QoS</TD> -<TD > -Name_of_Supplier [QoS_Options] -</TD> - -<TD>Set QoS parameters on a Periodic Supplier. The actual QoS settings are applied to the corresponding ProxyConsumer. -</TD> -</TR> -</TABLE> -<br> -QoS_Options = -ThreadPool [-Threads thread_pool_size (default= 1) ] - -[-Priority default_priority (default=ACE_DEFAULT_THREAD_PRIORITY)] -| - --Laness lane_count [-Lane priority static_threads dynamic_threads]* - -<p><b>Example : </b>: static Command_Builder "PeriodicSupplier -Set_QoS -ThreadPool Threads 2 -Priority 2" -<br><b>Example : </b>: static Command_Builder "PeriodicSupplier -Set_QoS -Lanes 2 -Lane 10 1 0 -Lane 30 2 1" - -<hr> - -<h3>Target Object : <b> Filter </b></h3> -Loading Syntax: dynamic TAO_Notify_Filter_Command_Factory Service_Object* TAO_NotifyTests:_make_TAO_Notify_Filter_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-CreateFactory</TD> - -<TD> -Filter_Factory_Name<br> - -Event_Channel_Name -</TD> - -<TD>Obtain the default FilterFactory from the EventChannel. -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Filter -CreateFactory ff ec1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-CreateFilter</TD> - -<TD> -Filter_Name<br> -Filter_Factory_Name -</TD> - -<TD>Create a Filter -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Filter -CreateFilter f1 ff" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Add_Constraint</TD> - -<TD> -Filter_Name -<br> -Constraint_Expression -</TD> - -<TD> -Add a constraint to a filter. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Filter -Add_Constraint f1 'Temp > 2'" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-AddFilter</TD> - -<TD> -Filter_Name -<br> -FilterAdmin_Name -</TD> - -<TD> -Add a filter to an Admin. - -The FilterAdmin can be the name of any Admin or Proxy objects. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Filter -Add_Filter f1 sa1_ec1" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Destroy</TD> - -<TD> -Filter_Name -<br> -</TD> - -<TD> -Destroy the Filter. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Filter –Destroy ff " - -<hr> -<h3>Target Object : <b> Application </b></h3> -Loading Syntax for RTCORBA Application: <br> -dynamic TAO_Notify_RT_Application_Command_Factory Service_Object * TAO_RT_NotifyTests:_make_TAO_Notify_RT_Application_Command_Factory () "" <br> -Loading Syntax for non-RTCORBA Application: <br> -dynamic TAO_Notify_Application_Command_Factory Service_Object * TAO_NotifyTests:_make_TAO_Notify_Application_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Init</TD> - -<TD> -<br> -</TD> - -<TD> -Init the Application - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Application -Init" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Run</TD> - -<TD> -<br> -</TD> - -<TD> -Run all the suppliers and consumers. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Application -Run" - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-WaitForEvents</TD> - -<TD> -<br> -</TD> - -<TD> -Wait till all the suppliers have send all there events and all the consumers have received the expected count of events. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Application –Wait_For_Events" - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Shutdown</TD> - -<TD> -<br> -</TD> - -<TD> -Shutdown the ORB. - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Application –Shutdown" - - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH WIDTH=20%>Description</TH> -</TR> - -<TR> -<TD>-DumpStats</TD> - -<TD> -[-Samples] -<br> -</TD> - -<TD> -Dump performance statistics. <br> - -if the -Samples option is specified all the latency samples are generated. <br> - -Data files are created in the current directory with the following names: <br> - -Supplier_{supplier_name}.dat <br> - -Consumer_{consumer_name}.dat <br> - -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "Application –DumpStats" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-SignalPeer</TD> - -<TD> -<br> -</TD> - -<TD> -Signal another waiting instance of the test. -</TD> -</TR> -</TABLE> - -<br><b>Example </b>: static Command_Builder "Application –SignalPeer": - -<hr> - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-WaitToStart</TD> - -<TD> -<br> -</TD> - -<TD> -Wait for another instance to signal. -</TD> -</TR> -</TABLE> - -<br><b>Example </b>:static Command_Builder "Application –WaitToStart" - -<hr> - -<hr> -<h3>Target Object : <b> POA </b></h3> -Loading Syntax for RTCORBA Application: <br> -dynamic TAO_Notify_RT_POA_Command_Factory Service_Object* TAO_RT_NotifyTests:_make_TAO_Notify_RT_POA_Command_Factory () "" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Create</TD> - -<TD> -POA_Name <br> - --PriorityModel {CLIENT|SERVER} default_priority (defaults : CLIENT_PROPAGATED, Priority = 0)<br> - --Lanes lane_count [-Lane priority static_threads dynamic_threads>]* <br> - --Bands band_count [-Band low_priority high_priority]* <br> - --ThreadPool static_threads priority -<br> -</TD> - -<TD> -Create an RT POA with the specified name and options of -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "POA -Create poa_test -PriorityModel CLIENT 1 -Lanes 1 -Lane -15 1 0" - -<P><TABLE WIDTH = 80% BORDER="1" CELLSPACING="1" CELLPADDING="1"> - -<TR> -<TH WIDTH=20%>Command</TH> -<TH WIDTH=60%>Parameters</TH> -<TH>Description</TH> -</TR> - -<TR> -<TD>-Destroy</TD> - -<TD> -POA_Name -<br> -</TD> - -<TD> -Destroy a POA -</TD> -</TR> -</TABLE> - -<br><b>Example : </b>: static Command_Builder "POA –Destroy” -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes/orbcore.html b/TAO/docs/releasenotes/orbcore.html deleted file mode 100644 index 78ee249f584..00000000000 --- a/TAO/docs/releasenotes/orbcore.html +++ /dev/null @@ -1,224 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> -<html> -<head> -<title>ORB Core Status</title> -<!-- $Id$ --> -</head> -<body text="#000000" bgcolor="#FFFFFF"> - -<!-- *********************************** --> -<a name="toc"><h2>Table of Contents</h2></a> -<ul> - <li><a href="#current">Current Status</a> - <li><a href="#issues">Known Issues</a> - <li><a href="#ongoing">Ongoing work</a> - <li><a href="#future">Future Work</a> - <li><a href="#completed">Completed Work</a> -</ul> -<!-- *********************************** --> - -<hr> -<center> -<h1> <a name="orb"></a>ORB & ORB Core</h1> - -Point of contact: <a href="mailto: bala@cs.wustl.edu">Balchandran Natarajan</a> - -<p>Last Update: $Date$</p> -</center> - -<!-- ============================================================ --> -<a name="current"><h3>Current status:</h3></a> - -<ul> - - <li><p>We are compliant with OMG's CORBA 2.6 specification. </p> - </li> - -</ul> - -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="issues"><h3>Known issues:</h3></a> - -<ul> - <li><p> TAO's support for wstring as per GIOP 1.2 rules are not - perfect. There have been reported interoperability - problems. <p></li> - - <li><p> The multi-profile parsing code in TAO hasnt been tested well - and we have been able to identify some issues with it. The - details are documented in our <A - HREF="http://deuce.doc.wustl.edu/bugzilla/index.cgi">bug tracking - system</A> under id's <A - HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1237">1237</A>, <A - HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1238"> - 1238</A>and<A - HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1239">1239</A> <p></li> - - <li><p> Applications using the distributed callback paradigm could - see crashes if they use multiple nested upcalls. The nested - upcalls sets of a stack growth and crashes when it runs out of - stack space. This happens when an upcall as a part of the - request leads to another request. The client thread waiting for - the reply in the reactor could in turn process yet another - request to build up the stack. The unbounded growth on the stack - leads to crash failures. <p> - </li> - - -</ul> -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="ongoing"><h3>Ongoing Work:</h3></a> - -<ul> - <li><p>Support new concurrency models, e.g., Thread-per-Request, - etc..</p> - </li> - <li><p>Improvement to connection cache on the acceptor side so that - it will purge old connections when there are no more slots or - sockets are available. The connection cache does good job of - purging things on the connector side</p> - </li> - - <li><p> Prevent unbounded stack growth that leads to a failure in - situations explained in <a href="#issues">known issues</a>.</p> - </li> - -</ul> -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="future"><h3>Future work:</h3></a> - -<ul> - <li>Performance bottlenecks:</li> - <ol> - <li><p> Need to identify performance bottlenecks. Looks like - TAO has slowed down a bit over the past two betas. Need to - identify the bottlenecks before improving the performance.</p> - </li> - - <li><p> Its a known fact that thread-per-connection is faster - than the reactive model, even for single threaded cases. Need - to identify portions of the reactor that slows down things and - fix them or create a fast path in the ORB just using plain - vanilla select for the server.</p> - </li> - - <li><p> In the output data path, the CDR creates the message - block and all other associted things on TSS. If we could - change the CDR to first create them on the stack and then move - the data to TSS we could achieve better performance for small - messages. - </ol> - - - <li>Features:</li> - <ol> - <li><p>Implement DP-CORBA specification</p></li> - - <li><p>Implement TII specification.</p></li> - </ol> - -</ul> -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -<!-- ============================================================ --> -<a name="completed"><h3>Completed Work:</h3></a> - -<!-- ************************************************************ --> -<!-- Please make sure you append new items at the end of the list --> -<!-- ************************************************************ --> -<ul> - <li><p> Implemented a connection timeout policy in the ORB. This - is useful for applications to set a timeout value associated - with connection establishment. The name of the policy is - <code>TAO::CONNECTION_TIMEOUT_POLICY_TYPE</code> and is - proprietary to TAO. It comes as a prt of the TAO_Messaging - library. Please see - <code>$TAO_ROOT/tests/Connection_Timeout</code> for an example - of how to use this feature.<p> - </li> - - <li><p> Implemented non-blocking connects with three different - strategies for connection establishment. The details of the - strategies and the related documentation can be found <A - href="../Options.html">here</a>.</p> - </li> - - <li><p> Deprecated the option -ORBConnectionCachingStrategy. The - option -ORBConnectionPurgingStrategy fills in the role of the - deprecated strategy.</p> - </li> - - <li><p> Deprecated the option -ORBResources.</p></li> - - <li><p> The connectors have been moved to the lanes.</p> </li> - - <li><p> Fixed stack recursion problems that occurs, when a thread - flushing a reply by entering the reactor starts processing - incoming requests.</p> - </li> - - <li><p> Fixed connection handling and connection closing problems, - when a write call to a remote host fails. </p> - </li> - - <li> <p> Moved the allocators used for allocating memory for the - incoming data path to the lanes. Only allocators on the - incoming data path are moved into the lanes. Allocators on the - outgoing data path are still on a per-orb basis. Since the - outgoing data path uses memory from the TSS, moving them to - the lanes is not necessary. - </p> - </li> - <li><p> Added an option, -ORBSingleReadOptimization that allows - users to turn on or turn off the single read - optimization. This is useful for RTCORBA server threads to - avoid priority inversions. Buffering messages and sending - notifications to the reactor, that does not know or honour - priority could lead to priority inversions. - </p> - </li> - - <li><p> Several changes were made to utilize the new memory management mechanisms - of Event Handlers in TAO. Previously, both the connection handlers and - the transports had their own reference counting mechanism and - independent lifetimes. The reference counting was inadequate - since it was not originated at the Reactor and the independent - lifetimes unnecessarily completed protocol specific transport - code. <p> - - The changes couple the lifetime of the connection handler with - that of the transport and utilizes the reference count in the - base ACE_Event_Handler class. This allowed us to remove several - hacks throughout TAO code which were designed to prevent (or - delay) crashes. Several extra checks and unnecessary locks were - also removed. <p> - - All of the following protocols were updated: DIOP, IIOP, - SCIOP, SHMIOP, SSLIOP, UIOP, UIPMC. </p> - </li> - - <li><p> Support for the ORB methods create_value_tc, create_component_tc, - create_event_tc, create_home_tc and create_recursive_tc added. </p> - </li> - -</ul> -<!-- --------------------- --> -<a href="#toc">Back to TOC</a> -<!-- --------------------- --> - -</BODY> -</HTML> diff --git a/TAO/docs/releasenotes/rtc10_sched.html b/TAO/docs/releasenotes/rtc10_sched.html deleted file mode 100644 index 526290b7a8f..00000000000 --- a/TAO/docs/releasenotes/rtc10_sched.html +++ /dev/null @@ -1,290 +0,0 @@ -<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> -<!-- $Id$ --> -<html> -<head> - <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> - <meta name="Author" content="Venkita Subramonian"> - <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]"> - <title>RTCORBA 1.0 Scheduling Service</title> -</head> -<body> - -<center> -<h2> -RTCORBA 1.0 Scheduling Service</h2></center> - -<p><br>Matt Murphy <murphym@cs.uri.edu> -<br>University of Rhode Island -<p>This is an implementation of the RTCORBA 1.0 Scheduling Service. Per -section 3 of the RTCORBA 1.0 specification (OMG), the scheduling service -is comprised of two local interfaces, a ClientScheduler and a ServerScheduler. -<br> -<h3> -Build Issues:</h3> -Run tao_idl -I $TAO_ROOT/ RTCosScheduling.pidl. -Run make -f Makefile.RTCosScheduling from ../ -<br> -<h3> -Synopsis:</h3> -The RTCosScheduler allows clients to schedule tasks according to scheduling -information determined a priori. This scheduling information is stored -in a config file so that both the client and the server has access to it. -(If the client and server exists on different nodes then place a copy of -the config file on each node.) -<p>Per the RTCORBA 1.0 spec, clients use a ClientScheduler object and servers -use a ServerScheduler object to schedule activities on the system. -Since each may or may not use its scheduler, there are four possible scenarios -in which the system may run. These are: -<p>1. Client uses ClientScheduler, Server uses ServerScheduler. In -this case the system follows the rules set forth in the "Scheduling Service" -section of this document below. -<p>2. Client uses ClientScheduler, Server does not use ServerScheduler. -In this case activities are scheduled on the client and run at the mapped -Real Time priority set forth in the config file while executing on -the client. However, any activity on the server does not run at a -real time priority. This means that Multiprocessor Priority Ceiling -Protocol does not manage activities on the server. Currently, the -client has no way of knowing that activity on the server did not follow -the MPCP protocol. Future enhancements to the RTCORBA 1.0 scheduling -service should notify the client (perhaps through a flag to a client interceptor) -that the server did not use MPCP. Please note that this -scenario is generally not recommended as there is a strong possibility -for priority inversion or unexpected blocking in this situation since -any and all server activity that uses the ServerScheduler will run -at a higher priority that server activity that does not. Use -scenario 1 above. Here, the server's priority lowers from RTCORBA::maxPriority -to RTCORBA::minPriority and things will execute on a best effort -basis. -<p>3. Client does not use ClientScheduler, Server uses ServerScheduler. -In this case the client does not use priorities set forth in the config -file. The ServerScheduler, on the other hand, does use MPCP to schedule -execution on the server. It uses the priority sent to the server -by the client, which is the default priority that the -<br> client ran at (since the client priority was not changed -by schedule_activity(). This follows the scenario of the ServerScheduler -set forth below. Please note that it is recommended -that you use -scenario 1, above, instead so that the client sends appropriate priorities -to the server. -<p>4. Client does not use ClientScheduler, server does not use ServerScheduler. -In this case neither the client nor the server take advantage of -the RTCORBA 1.0 Scheduler. -<br> -<h3> -Scheduling Service:</h3> -ClientScheduler: -<br>Clients wishing to use the ClientScheduler to schedule activities -<br>must first create a local ClientScheduler object reference. The -<br>ClientScheduler is declared as: -<p>RTCosScheduling_ClientScheduler_i ( -<br> CORBA::ORB_var orb, /// Orb reference -<br> char* node, -/// Node the client resides on -<br> char* file); -/// Config file holding scheduling information -<br> -<p>The ClientScheduler constructor parses the config file and populates -an ACE_MAP with the activity/priority associations for the node on which -the client resides. It also constructs a ClientScheduler_Interceptor -that adds a service context the send_request interceptor that contains -the priority the client is running at when the call is made. -<p>Once initialized, calls to the ClientScheduler schedule_activity(const -char * activity_name) method will match the activity_name parameter to -the CORBA priority value in the ACE_Map. It linearly maps CORBA priority -to a local OS priority and sets the local OS priority using RT Current. -If the activity name provided is not valid (i.e. not found in the config -file), a RTCosScheduling::UnknownName exception is thrown. -<p>The ClientScheduler also registers an client side interceptor with the -orb. This ClientScheduler_Interceptor finds the CORBA priority that -the client is running at when the remote method call is made and adds this -priority to a service context for the ServerScheduler_Interceptor to use. -Initial tests find that this interceptor adds 0.00015 seconds of execution -on an Intel 3.0 GHz processor. -<br> -<h3> -ServerScheduler:</h3> -Servers that contain local objects that will accept CORBA calls must create -a local ServerScheduler object. The ServerScheduler uses TAO's PortableInterceptors -to intercept incoming client requests and schedule execution on the server. -These interceptors are registered by the ORB_Core as explained in the create_POA -method below. The ServerScheduler is defined as: -<p> RTCosScheduling_ServerScheduler_i ( -<br> char *node, /// Node the ServerScheduler -resides on -<br> char *file, /// Config file holding -scheduling information -<br> char *shared_file, /// File used for shared -memory -<br> int numthreads); /// Number of threads -to create in the threadpool -<p>During initialization, the ServerScheduler finds the appropriate node -information in the config file and stores resources (key) on the node and -the appropriate priority ceiling (value) in a map. It also reads -in the base priority for the resource. -<p>The ServerScheduler constructor then registers the PortableInterceptors -necessary to scheduler execution on the server. It also set up the -linear mapping policy and a reference to the RT Current object, both of -which are used for adjusting the server's local OS priority when using -the priority ceiling control protocol. -<p>Once the ServerScheduler object is constructed, users may create an -orb and establish any non real time POA policies they wish to install by -calling the ServerScheduler's create_POA method. -<p>ServerScheduler's create_POA method creates a real time POA that will -set and enforce all non-real time policies. This method also sets -the real time POA to enforce the Server Declared Priority Model Policy -and creates a threadpool responsible for executing calls to the server. -Server Declared Priority Model is used so that the server threads may run -at a high enough priority to intercept requests as soon as they come in. -If Client Propagated Priority Ceilings were used, incoming requests would -not be intercepted until all existing servant execution is completed. -This is because MPCP elevates the priority of servant execution to be higher -than the client priorities. -<p>Recall that the number of threads in the threadpool was supplied by -the ServerScheduler constructor. The create_POA method is defined -as: -<p> virtual ::PortableServer::POA_ptr create_POA ( -<br> PortableServer::POA_ptr parent, -/// Non RT POA parent -<br> const char * adapter_name, /// -Name for the POA -<br> PortableServer::POAManager_ptr a_POAManager, -/// Manager for the POA -<br> const CORBA::PolicyList & policies /// -List of non RT policies -<br> ACE_ENV_ARG_DECL) -<br> ACE_THROW_SPEC (( -<br> CORBA::SystemException -<br> , PortableServer::POA::AdapterAlreadyExists -<br> , PortableServer::POA::InvalidPolicy -<br> )); -<br> -<p>Once a RT POA has been created, schedule_object is called to store CORBA -Object references (key) with a name (value) in an ACE_MAP. An -<br>RTCosScheduling::UnknownName exception is thrown if the schedule_object -name parameter is not found in the resource map (i.e. it was not in the -<br>config file.) The schedule_object method is declared as: -<p> virtual void schedule_object ( -<br> CORBA::Object_ptr obj, /// A CORBA object -reference -<br> const char * name /// Name to -associate with obj -<br> ACE_ENV_ARG_DECL) -<br> ACE_THROW_SPEC (( -<br> CORBA::SystemException -<br> , RTCosScheduling::UnknownName -<br> )); -<br> -<p>Once all objects that will receive client requests have been scheduled -using schedule_object, clients are free to make calls on those objects. -The scheduling service interceptors catch these calls and perform the necessary -priority ceiling control measures to ensure that the calls are executed -in the appropriate order. The ServerScheduler_Interceptor receive_request -method intercepts all incoming request immediately since it is set to run -at RTCORBA::maxPriority (the highest priority on the server OS). -It then gets the client priority sent in the service context as well as -the resource ceiling for the object and the base priority for the server. -<br>Initial tests indicate that the receive_request interceptor takes around -0.002 seconds to complete on an Intel 3.0 GHz processor. -<p>Given these values it is able to use the Multiprocessor Priority Ceiling -Protocol to schedule execution on the server to handle the request. -MPCP schedules all global critical sections at a higher priority than tasks -on the local processor by adding the client priority to the base priority -of the servant, then adding the resource ceiling of the resource to the -base priority to find the appropriate priority ceiling. For more information -about MPCP, please refer to the book "Real Time Systems", By Jane Liu (2000). -<p>Please not that the locking mechanisms are stored in shared memory on -the server. This means that the locks cannot be stored in linked -lists and are therefore manipulated using memory offsets. The total -number of locks that may be stored in shared memory is currently set at -1024. -<p>When remote execution is complete the send_reply interceptor resets -the thread to listen at RTCORBA::maxPriority and removes the task form -the Invocation -<br>list. Initial test indicate that the send_reply interceptor takes -0.000075 seconds to complete on an Intel 3.0 GHz processor. -<br> -<h3> -Scheduling Service Config File:</h3> -The scheduling service config file holds the information necessary to schedule -the system. Task and resource ceiling information is stored for each -of the nodes as follows: -<p>Node 1 /// The node name is 1 -<p>Resources: -<br>BP 6000 /// The base priority for -the resource -<br>Server1 1000 /// A list of resources and their priority -ceiling -<br>Server2 2000 -<br>END /// The end of the resource list -<p>Tasks: /// A list of tasks that will execute on the -node -<br>Client1 1000 -<br>Client2 3000 -<br>Client3 5000 -<br>END /// The end of the task list. -<p>Please note that these associations are tab delimited. Please -do not include comments in the scheduling service config file. The -priorities associated -<br>with each task and resource are considered to be CORBA priorities, -and will be mapped to local OS level priorities using the Linear Mapping -<br>model. Per the OMG RT CORBA spec, CORBA priorities have a valid -range up to 32767, where a larger value indicates a higher priority. -The current -<br>config file assumes that the Multiprocessor Priority Ceiling Protocol -is used. -<br> -<h3> -Known Issues:</h3> -TAO does not currently support request buffering, and there are no immediate -plans to do so. Consequently, the RT CORBA 1.0 Scheduling Service -is -<br>limited in that it will only function properly in systems that do not -require request buffering on the servant side. -<p>There is a bug in TAO in which mapped priorities are mapped a second -time when using Client Propagated Priority Ceiling Protocol. This -in effect -<br>lowers the priority that the servant receives. This happens to -each priority, so there should be no effect on the system. -<p>The config file assumes CORBA priorities in the range of 0 to 32767. -The Linear Priority Mapping Manager will map these to valid local OS priorities. -Take care though, in determining the priority range in the config file, -as low numbers or numbers very close in value may produce priority inversion -and other issues. For example, if the CORBA priorities used for three -tasks are 100 200 300, these will all map to OS priority 1 in on some real -time Linux systems. Please take this into -<br>account when determining the CORBA priority range to use. -<p>The 1.0 Scheduling service currently works with one orb and one POA. -If someone tries to install more than one scheduling service (client or -server side) on a single POA, then it should not add a second interceptor. -Please use a single scheduling service per POA. Furthermore, there -is a bug when more than one orb is created, an invalid policy exception -is thrown during the second call to create_POA. This bug is actively -being investigated. In the meantime please use the scheduling service -with one ORB. -<br> -<h3> -Future Enhancements:</h3> -ACE_XML -<br>The current RT CORBA 1.0 Scheduling Service uses a private method to -read the config file. This will soon be replaced with a new XML based -config -<br>file using ACE_XML to parse the config file. -<p>Priority Lanes -<br>Although not currently implemented, Priority Lanes and Thread Borrowing -may increase performance as they would help to prevent lower priority tasks -from exhausting all threads. This is considered a possible future -enhancement. -<p>Client Interceptor -<br>A client interceptor that sends a flag to notify the server interceptor -if schedule_activity() was used to set the client priority. If schedule_activity() -was not used, then the server should probably not try and schedule server -execution using MPCP. Doing so adds competition to other method calls -by other client requests that were scheduled with schedule_activity(). -<br> -<h3> -References</h3> -The Object Management Group, Real Time CORBA 1.0 Specification, www.omg.org -<br>Liu, Jane, Real Time Systems, Prentice Hall, 2000 -<br> -</body> -</html> diff --git a/TAO/docs/releasenotes/trader.html b/TAO/docs/releasenotes/trader.html deleted file mode 100644 index 0d392bafffb..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"> - <!-- $Id$ --> -<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>ACE_TRY -{ - TAO_ORB_Manager orb_manager; - orb_manager.init (argc, argv, ACE_TRY_ENV); - ACE_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 (), ACE_TRY_ENV); - ACE_CHECK_ENV; -} -ACE_CATCHANY -{ - ACE_TRY_ENV.print_exception ("Failed to bootstrap to a trader"); -} -ACE_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); - ACE_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 ())); - ACE_TRY - { - CORBA::Boolean is_dynamic = prop_eval.is_dynamic_property (k); - ACE_CHECK_ENV; - - value = prop_eval.property_value(k, env); - ACE_CHECK_ENV; - - if (value != 0) - CORBA::Any::dump (*value); - } - ACE_CATCHANY - { - ACE_DEBUG ((LM_DEBUG, "Error retrieving property value.\n")); - } - ACE_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); -ACE_CHECK_ENV_RETURN (_env, -1); -CosTrading::Register_var register_if = lookup_if->register_if (_env); -ACE_CHECK_ENV_RETURN (_env, -1); -CosTrading::TypeRepository_ptr obj = this->trader_->type_repos (_env); -CosTradingRepos::ServiceTypeRepository_var str = - CosTradingRepos::ServiceTypeRepository::_narrow (obj, _env); -ACE_CHECK_ENV_RETURN (_env, -1); - -ACE_TRY - { - // Attempt to export the offer. - offer_id = - register_id->export (object_ref, type, props, ACE_TRY_ENV); - ACE_CHECK_ENV; - } -ACE_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); - ACE_CHECK_ENV_RETURN (_env, 0); - - // Now we'll try again to register the offer. - offer_id = reg->export (object_ref, type, this->tprops_, _env); - ACE_CHECK_ENV_RETURN (_env, 0); - - ACE_TRY_ENV.clear (); - } -ACE_CATCHANY - { - // Sigh, all our efforts were for naught. - ACE_RETHROW_RETURN (0); - } -ACE_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) - ACE_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) - ACE_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); -ACE_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 (ACE_TRY_ENV); -ACE_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>ACE_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 (ACE_TRY_ENV); -ACE_CHECK_ENV; - -CosTrading::Register_var register_if = - lookup_if->register_if (ACE_TRY_ENV); -ACE_CHECK_ENV; - -admin_if->list_offers (10, - CosTrading::OfferIdSeq_out (offer_id_seq), - CosTrading::OfferIdIterator_out (offer_id_iter), - ACE_TRY_ENV); -ACE_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], ACE_TRY_ENV); - ACE_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), - ACE_TRY_ENV); - ACE_CHECK_ENV; - - CORBA::ULong offers = id_seq->length (); - for (CORBA::ULong i = 0; i < offers; i++) - { - register_if->withdraw (id_seq[i], ACE_TRY_ENV); - ACE_CHECK_ENV; - } - - delete id_seq; - } - while (any_left); - - offer_id_iter->destroy (ACE_TRY_ENV); - ACE_CHECK_ENV; - } -} -ACE_CATCHANY -{ - // Handle Errors. -} -ACE_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>ACE_TRY - { - CosTrading::Link_var link_if = lookup_if->link_if (ACE_TRY_ENV); - ACE_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, - ACE_TRY_ENV); - ACE_CHECK_ENV; - - our_link->add_link ("Bootstrap_Trader", - lookup_if.in (), - CosTrading::always, - CosTrading::always, - ACE_TRY_ENV); - } -ACE_CATCHANY -{ - // Handle Errors. -} -ACE_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)); -ACE_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> diff --git a/TAO/docs/rtcorba/architecture.html b/TAO/docs/rtcorba/architecture.html deleted file mode 100644 index b06460a079d..00000000000 --- a/TAO/docs/rtcorba/architecture.html +++ /dev/null @@ -1,117 +0,0 @@ -<html> - -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>TAO Real-Time Architecture</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -</head> - -<body> - -<h3 align="center">TAO Real-Time Architecture </h3> -<p>This page describes and compares the two main ORB designs we considered for -supporting Real-Time CORBA 1.0 in TAO. The first design, codenamed <i>reactor-per-lane</i> -and shown in Figure 1, was chosen for our initial implementation. The -second design, <i>queue-per-lane</i>, might also get implemented in the future, -as a part of a project evaluating alternative ORB architectures for Real-Time -CORBA. </p> -<h3 align="center">Design I: Reactor-per-Lane</h3> -In this design, each Threadpool Lane has its own reactor, acceptor, connector -and connection cache. Both I/O and application-level processing for a -request happen in the same threadpool thread: there are no context switches, and -the ORB does not create any internal threads. Objects registered with any -Real-Time POA that does not have the <i>ThreadpoolPolicy</i> are serviced by <i>default -threadpool</i>, which is a set of of all the application threads that invoked -<CODE>orb->run ()</CODE>. -<p align="center"><img border="0" src="reactor-per-lane.gif" width="407" height="333"></p> -<p align="center">Figure 1: Reactor-per-lane</p> -<p>When a Real-Time POA is creating an IOR, it includes one or more of its -threadpool's acceptor endpoints into that IOR according to the following -rules. If the POA's priority model is <i>server declared</i>, we use the -acceptor from the lane whose priority is equal to the priority of the target -object. If the -priority model is <i> client propagated,</i> all endpoints from the POA's -threadpool are included into the IOR. Finally, if the <i>PriorityBandedConnectionPolicy</i> -is set, then endpoints from the threadpool lanes with priorities falling into one of the specified -priority bands are selected. The endpoints, selected according to the -rules above, and their corresponding priorities are stored in IORs using a special -<i>TaggedComponent </i><CODE>TAO_TAG_ENDPOINTS</CODE>. During each -invocation, to obtain a connection to the server, the client-side ORB selects -one of these endpoints based on the effective policies. For example, if the object has -<i> client propagated</i> priority -model, the ORB selects the endpoint whose priority is equal to the priority of the client thread making the -invocation. If on the client-side, during invocation, or on the -server-side, during IOR creation, an endpoint of the right priority is not available, it -means the system has not been configured properly, and the ORB throws an exception. -The design and rules described above ensure that when a threadpool with lanes is -used, client requests are processed by the thread of desired priority from very -beginning, and priority inversions are minimized.</p> -<p>Some applications need less rigid, more dynamic environment. They do -not have the advanced knowledge or cannot afford the cost of configuring all of the -resources ahead of time, and have a greater tolerance for priority -inversions. For such applications, threadpools <i> without</i> lanes are a way to go. -In TAO, threadpools without lanes have different semantics that their <i>with-lanes</i> -counterparts. Pools without lanes have a single acceptor endpoint used in -all IORs, and their threads change priorities on the fly, as necessary, to -service all types of requests.</p> -<h3 align="center">Design II: Queue-per-Lane</h3> -In this design, each threadpool lane has its own request queue. There is a separate -I/O layer, which is shared by all lanes in all threadpools. The I/O layer has one -set of resources - reactor, connector, connection cache, and I/O thread(s) - for each priority -level used in the threadpools. I/O layer threads perform I/O processing -and demultiplexing, and threadpool threads are used for application-level request -processing. -<p align="center"><img border="0" src="queue-per-lane.gif" width="387" height="384"></p> -<p align="center">Figure 2: Queue-per-lane</p> -<p>Global acceptor is listening for connections from clients. Once a -connection is established, it is moved to the appropriate reactor during the -first request, once its priority is known. Threads in each lane are blocked on -condition variable, waiting for requests to show up in their queue. I/O -threads read incoming requests, determine their target POA and its threadpool, -and deposit the requests into the right queue for processing. </p> -<h3 align="center">Design Comparison</h3> -<i>Reactor-per-lane</i> advantages: -<ul> - <li><b>Better performance</b><br> - Unlike in <i>queue-per-lane</i>, since each request is serviced in one - thread, there are no context switches, and there are opportunities for stack and TSS optimizations.</li> - <li><b>No priority inversions during connection establishment</b><i><br> - </i>In <i>reactor-per-lane</i>, threads accepting connections are the same - threads that will be servicing the requests coming in on those connections, <i>i.e.</i>, - priority of the accepting thread is equal to the priority of requests on the - connection. In <i>queue-per-lane</i>, - however, because of a global acceptor, there is no differentiation between - high priority and low priority clients until the first request.</li> - <li><b>Control over all threads with standard threadpool API<br> - </b>In <i>reactor-per-lane,</i> the ORB does not create any threads of its - own, so application programmer has full control over the number and - properties of all the threads with the Real-Time CORBA Threadpool - APIs. <i>Queue-per-lane</i>, on the other hand, has I/O layer threads, - so either a proprietary API has to be added or application programmer will - not have full control over all the thread resources..</li> -</ul> -<p> -<i>Queue-per-lane</i> advantages:</p> -<ul> - <li><b>Better feature support and adaptability</b><br> - <i>Queue-per-lane</i> supports ORB-level request buffering, while <i>reactor-per-lane</i> - can only provide buffering in the transport. With its two-layer - structure, <i>queue-per-lane</i> is a more decoupled design than <i>reactor-per-lane</i>, - making it easier to add new features or introduce changes </li> - <li><b>Better scalability</b> <br> - Reactor, connector and connection cache are <i>per-priority</i> resources in - <i>queue-per-lane</i>, and <i>per-lane</i> in <i>reactor-per-lane</i>. - If a server is configured with many threadpools that have similar lane - priorities, <i>queue-per-lane</i> might require significantly fewer of the - above-mentioned resources. It also uses fewer acceptors, and its IORs - are a bit smaller.</li> - <li><b>Easier piece-by-piece integration into the ORB<br> - </b>Ease of implementation and integration are important practical - considerations in any project. Because of its two-layer structure, <i>queue-per-lane</i> - is an easier design to implement, integrate and test piece-by-piece.</li> -</ul> -<hr> -<p><i>Last modified: $Date$</i></p> -</body> -</html> diff --git a/TAO/docs/rtcorba/content.html b/TAO/docs/rtcorba/content.html deleted file mode 100644 index 0e0f6b68f89..00000000000 --- a/TAO/docs/rtcorba/content.html +++ /dev/null @@ -1,44 +0,0 @@ -<html> - -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>TAO Real-Time CORBA Documentation Table of Content</title> -<base target="main"> -</head> - -<body> - -<h3 align="center">TAO Real-Time CORBA Documentation </h3> - -<ol> - <li><a href="status.html#intro">Intro</a></li> - <ul> - <li><a href="status.html#supported">Supported Features</a></li> - <li><a href="status.html#unsupported">Unsupported Features</a></li> - <li><a href="status.html#future">Future Work</a></li> - </ul> - </li> - <li><a href="omg_issues.html">Issues with the Real-Time CORBA 1.0 Specification</a></li> - <li><a href="architecture.html">TAO Real-Time Architecture</a></li> - <li><a href="features.html">Real-Time Features Documentation</a><ul> - <li><a href="features.html#enabling">Enabling Real-Time features</a></li> - <li><a href="features.html#deprecated">Migrating from - TAO::Client_Priority_Policy</a> </li> - <li><a href="features.html#mappings">Priority Mappings</a></li> - <li><a href="features.html#defaults">ORB Default Policies</a></li> - <li><a href="features.html#threadpools"> Threadpools</a></li> - <li><a href="features.html#valid_configurations">Priority Policies</a> </li> - <li><a href="features.html#explicit_bind">Explicit Binding</a></li> - <li><a href="features.html#protocols">Protocol Policies</a></li> - <li><a href="features.html#diffserv">Diffserv Support</a></li> - </ul> - </li> - <li><a href="issues.html">Known Bugs and Issues</a></li> - <li><A - HREF="http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html">Performance and Papers</A></li> - <li><a href="faq.html">FAQ</a> </li> -</ol> - -</body> -</html> diff --git a/TAO/docs/rtcorba/faq.html b/TAO/docs/rtcorba/faq.html deleted file mode 100644 index ab446b2620b..00000000000 --- a/TAO/docs/rtcorba/faq.html +++ /dev/null @@ -1,40 +0,0 @@ -<html> - -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>TAO Real-Time CORBA Frequently Asked Questions</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -</head> - -<body> - -<h3><a name="top">Frequently Asked Questions</a></h3> - -<p><strong><a href="#Q1">1. Question</a><br> -<a href="#Q2">2. Question</a></strong></p> - -<hr> - -<p><a name="Q1">Q1</a>.</p> - -<p>A1.</p> - -<p><a href="#top">[back]</a></p> - -<hr> - -<p><a name="Q2">Q2</a>.</p> - -<p>A2.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<i> - -<p>Last modified: $Date$ </i></p> - -<p> </p> -</body> -</html> diff --git a/TAO/docs/rtcorba/features.html b/TAO/docs/rtcorba/features.html deleted file mode 100644 index d360ee31c2d..00000000000 --- a/TAO/docs/rtcorba/features.html +++ /dev/null @@ -1,843 +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.77 [en] (Windows NT 5.0; U) [Netscape]"> - <title>TAO Real-Time CORBA Features Documentation</title> -<!-- $Id$ --> -</head> -<body> - -<center> -<h3> -Features Documentation</h3></center> -This page is not a tutorial on Real-Time CORBA, but is rather a supplement -to the specification, covering all implementation-specific details. Sample -code exercising RTCORBA features can be found in -<tt>$TAO/tests/RTCORBA/</tt>. -We hope to have tutorial-style examples available in the near future. -<h3> -<a NAME="enabling"></a>Enabling Real-Time CORBA features</h3> -In order to use features from the Real-Time CORBA 1.0 specification in -TAO, a RT-CORBA client application must link with the RTCORBA library; -a RT-CORBA server application must link with the RTCORBA library and the -RTPortableServer libraries. Since some features in RT-CORBA depend on the -messaging specification, all code must be compiled with <tt>TAO_HAS_CORBA_MESSAGING</tt> -set to -<tt>1</tt>. This macros are defined in -<tt>$TAO/tao/orbconf.h</tt> -<p>By default, both Real-Time CORBA and Messaging are enabled in TAO unless -Minimum CORBA support is turned on, <i>i.e.</i>, -<tt>TAO_HAS_MINIMUM_CORBA</tt> -is set to <tt>1</tt>. -<h3> -<a NAME="mappings"></a>Priority Mappings</h3> -TAO provides three Priority Mappings: Direct, Linear, and Continuous. If -no mapping is specified, Direct Priority Mappings will be used. Note that -Continuous was previously referred to as Direct. -<dl> -<dt> -<b>Direct</b></dt> - -<dd> -Maps CORBA priorities directly to native priorities.</dd> - -<dt> -<b>Linear</b></dt> - -<dd> -Maps each individual native priority to a contiguous range of CORBA priorities, -so that the complete CORBA priority range is used up for the mapping. See -<tt>$TAO_ROOT/tao/RTCORBA/Linear_Priority_Mapping.cpp -</tt>for -more details.</dd> - -<dt> -<b>Continuous</b></dt> - -<dd> -Maps the first <i>n</i> CORBA priorities to the range of native priorities, -where <i>n</i> is the number of native priorities. The lowest native priority -is mapped to CORBA priority 0, next higher native priority is mapped to -CORBA priority 1, and so on. Since in all the operating systems where TAO -is supported the native priority set contains less than 32767 priorities, -part of the CORBA priority range is left unused. Consider NT Direct priority -mapping as an example. NT native priorities -15 -2 -1 0 1 2 15 are mapped -to CORBA priorities 0 1 2 3 4 5 6, respectively, and the rest of the CORBA -priority range is not used.</dd> -</dl> -Priority mappings implement the rules for mapping CORBA priority range -(from 0 to 32767) into the native OS priority range and vice versa. However, -in some operating systems, the the native OS priority range depends on -the scheduling policy being used. That's why when specifying a priority -mapping, scheduling policy must be specified as well. Below, we describe -how to configure TAO to use a particular priority mapping and scheduling -policy. Note, in some operating systems super user privileges are required -for use of some of the scheduling policies. -<p>By default TAO uses Direct priority mapping and -<tt>SCHED_OTHER</tt> -scheduling policy. There are two ways for an application to override these -settings: -<ol> -<li> -<tt>svc.conf</tt> file can be used to select a mapping and a scheduling -policy the ORB will use. (This method does not allow the specification -of user-defined mappings.) Config file should contain the following options:</li> - -<br> -<p> -<br> -<br> -<p><tt>static RT_ORB_Loader "-ORBPriorityMapping -<i>mapping_type</i> -ORBSchedPolicy -<i>sched_policy</i>"</tt> -<p>where valid values for <i>mapping_type</i> are <tt>continuous</tt>, <tt>linear</tt> and <tt>direct,</tt> -and<i> </i>valid values for <i>sched_policy</i> are <tt>SCHED_OTHER</tt>, -<tt>SCHED_FIFO</tt> -and <tt>SCHED_RR</tt>. -<li> -<i>TAO::PriorityMappingManager</i> can be used to 1) override the default -priority mapping and scheduling policy with another ORB-defined mapping/scheduling -policy combination, 2) install a user-defined priority mapping, 3) obtain -a reference to the priority mapping object used by the ORB. Code excerpts -below demonstrate how to perform each of these tasks.</li> - -<br> -<p> -<br> -<br> -<p>Obtaining Priority Mapping Manager: -<br><tt>object = orb->resolve_initial_references ("PriorityMappingManager");</tt> -<br><tt>TAO::PriorityMappingManager_var mapping_manager =</tt> -<br><tt>TAO::PriorityMappingManager::_narrow (object.in ());</tt> -<p>Overriding priority mapping/policy in effect with another ORB-defined -mapping/policy combination: -<br><tt>#include "tao/RTCORBA/Continuous_Priority_Mapping.h"</tt> -<br><tt>#include "tao/RTCORBA/Linear_Priority_Mapping.h"</tt> -<br><tt>#include "tao/RTCORBA/Direct_Priority_Mapping.h"</tt> -<br><tt>...</tt> -<p><tt>RTCORBA::PriorityMapping *pm =</tt> -<br><tt>new TAO_Continuous_Priority_Mapping (policy);</tt> -<br>or -<br><tt>new TAO_Linear_Priority_Mapping (policy);</tt> -<br>or -<br><tt>new TAO_Direct_Priority_Mapping (policy);</tt> -<br><tt>mapping_manager->mapping (pm);</tt> -<br><tt>...</tt> -<br>where policy is <tt>SCHED_OTHER, SCHED_FIFO</tt> or -<tt>SCHED_RR.</tt> -Priority Mapping Manager takes the ownership of the priority mapping object. -<p>Overriding the default with user-defined priority mapping: -<br><tt>My_Mapping *foo = new My_Mapping;</tt> -<br><tt>mapping_manager->mapping (foo);</tt> -<br>where <i>My_Mapping</i> must inherit from <i>RTCORBA::PriorityMapping</i> -(a typedef for <i>TAO_Priority_Mapping</i> class) located in -<tt>$TAO/tao/Priority_Mapping.h</tt> -<p>Obtaining a pointer to the priority mapping object being used by the -ORB: -<br><tt>RTCORBA::PriorityMapping *pm =</tt> -<br><tt>mapping_manager->mapping ();</tt> -<br>Mapping manager retains the ownership of the priority mapping object.</ol> - -<h3> -<a NAME="defaults"></a>ORB Default Policies</h3> -Real-Time CORBA 1.0 does not specify ORB defaults for the policies it defines, -leaving it up to implementations. Below is a summary TAO defaults. -<br> -<table BORDER CELLPADDING=7 WIDTH="100%" > -<tr> -<td ALIGN=CENTER WIDTH="31%"><b>Policy</b></td> - -<td ALIGN=CENTER WIDTH="69%"><b>Default</b></td> -</tr> - -<tr> -<td WIDTH="31%"><i>ServerProtocolPolicy</i></td> - -<td WIDTH="69%">All protocols that are loaded by the ORB by default (e.g., -IIOP) and any explicitly specified by the user (e.g., SHMIOP), in the order -they were loaded, with their default properties. See <a href="#protocols">Protocol -Policies</a> section for more details.</td> -</tr> - -<tr> -<td WIDTH="31%"><i>ClientProtocolPolicy</i></td> - -<td WIDTH="69%">None</td> -</tr> - -<tr> -<td WIDTH="31%"><i>ThreadpoolPolicy</i></td> - -<td WIDTH="69%">None. If no ThreadpoolPolicy policy is specified during -POA creation, the default thread-pool will be used for that POA.</td> -</tr> - -<tr> -<td WIDTH="31%"><i>PriorityModelPolicy</i></td> - -<td WIDTH="69%">None</td> -</tr> - -<tr> -<td WIDTH="31%"><i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="69%">None</td> -</tr> - -<tr> -<td WIDTH="31%"><i>PrivateConnectionPolicy</i></td> - -<td WIDTH="69%">None</td> -</tr> - -<tr> -<td WIDTH="31%">Priority Mapping</td> - -<td WIDTH="69%">Direct mapping with <tt>SCHED_OTHER</tt> scheduling policy. -See <a href="#mappings">Priority Mappings</a> section for more details.</td> -</tr> -</table> - -<h3> -<a NAME="threadpools"></a>Threadpools</h3> - -<ul> -<li> -ThreadPools are now fully supported. Endpoint priorities are no longer -supported.</li> -<li> -By default dynamic RTCorba threads live forever after they are created. -When using the <code>RTORBDynamicThreadIdleTimeout</code> from the -<code>RT_ORB_Loader</code> it -can be specified that the dynamic threads should end after a given -idle time. Timeout must be specified in microseconds, 0 means the threads -will stay alive forever. -</ul> - -<h3> -<a NAME="valid_configurations"></a>Priority Policies</h3> -The table below lists all possible configurations of policies involving -priorities, and summarizes the semantics of each configuration. -<br> -<table BORDER CELLPADDING=4 WIDTH="100%" > -<tr> -<td ALIGN=CENTER WIDTH="33%"><b>Configuration</b></td> - -<td ALIGN=CENTER WIDTH="33%"><b>Valid values</b></td> - -<td ALIGN=CENTER WIDTH="34%"><b>Semantics</b></td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes, -<br>no <i>PriorityModelPolicy</i>, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">Invalid.</td> - -<td WIDTH="34%">None.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes + -<br><tt>SERVER_DECLARED</tt> model, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> -must be equal to the priority of one of the threadpool lanes. (Same goes -for priorities of all the objects registered with the target POA).</td> - -<td WIDTH="34%">All processing is done at the servant's priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes + -<br><tt>CLIENT_PROPAGATED</tt> model, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">Priority of the invoking client thread must be equal to -the priority of one of the threadpool lanes.</td> - -<td WIDTH="34%">All processing is done at the client-propagated priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes + -<br><i>PriorityBandedConnectionPolicy</i>, -<br>no <i>PriorityModelPolicy</i></td> - -<td WIDTH="33%">Invalid.</td> - -<td WIDTH="34%">None.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes + -<br><tt>SERVER_DECLARED</tt> model + -<br><i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> -must be equal to the priority of one of the threadpool lanes. (Same goes -for priorities of all the objects registered with the target POA). In addition, -each of the priority bands must cover at least one of the threadpool lane -priorities.</td> - -<td WIDTH="34%">All processing is done at the servant's priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool with lanes + -<br><tt>CLIENT_PROPAGATED</tt> model + -<br><i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">Priority of the invoking client thread must fall into one -of the priority bands. In addition, each of the priority bands must cover -at least one of the threadpool lane priorities.</td> - -<td WIDTH="34%">All processing is done at the threadpool lane priority -which matches the priority band used by the client.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes, -<br>no <i>PriorityModelPolicy</i>, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">All valid CORBA priorities.</td> - -<td WIDTH="34%">All processing is done at the threadpool's default priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes + -<br><tt>SERVER_DECLARED</tt> model, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">All valid CORBA priorities.</td> - -<td WIDTH="34%">Request I/O and demultiplexing processing is done at the -threadpool's default priority. Application level processing is done at -the servant's priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes + <tt>CLIENT_PROPAGATED</tt> model, -<br>no <i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">All valid CORBA priorities.</td> - -<td WIDTH="34%">Request I/O and demultiplexing processing is done at the -threadpool's default priority. Application level processing is done at -the client-propagated priority.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes + -<br><i>PriorityBandedConnectionPolicy</i>, -<br>no <i>PriorityModelPolicy</i></td> - -<td WIDTH="33%">Invalid.</td> - -<td WIDTH="34%">None.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes + -<br><tt>SERVER_DECLARED</tt> model + -<br><i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%"><i>Server_priority</i> attribute of the <i>PriorityModelPolicy</i> -must fall into one of the priority bands. (Same goes for priorities of -all the objects registered with the target POA).</td> - -<td WIDTH="34%">Request I/O and demultiplexing processing is done at the -threadpool's default priority. Application level processing is done at -the servant's priority. In this case, <i>PriorityBandedConnectionPolicy</i> -is used to restrict the allowed priority values for the servant.</td> -</tr> - -<tr> -<td WIDTH="33%">Threadpool without lanes + -<br><tt>CLIENT_PROPAGATED</tt> model + -<br><i>PriorityBandedConnectionPolicy</i></td> - -<td WIDTH="33%">Priority of the invoking client thread must fall into one -of the priority bands.</td> - -<td WIDTH="34%">Request I/O and demultiplexing processing is done at the -threadpool's default priority. Application level processing is done at -the client-propagated priority. In this case, <i>PriorityBandedConnectionPolicy</i> -is used to restrict the allowed priority values for the client.</td> -</tr> -</table> - -<h3> -<a NAME="explicit_bind"></a>Explicit Binding</h3> -<tt>Object::_validate_connection ()</tt> method establishes a connection, -if one doesn't already exist, and verifies policy overrides for the <i>invoking -thread/ its priority/ target object</i> combination. To establish all connections -ahead of time, application must call <tt>_validate_connection ()</tt> for -<b>all</b><i>thread/ -priority/ object</i> combinations that will be used. -<h3> -<a NAME="protocols"></a>Protocol Policies</h3> -In addition to <i>TCPProtocolProperties</i> defined by the Real-Time CORBA -specification, TAO provides configurable properties for each protocol it -supports. Below is a summary of all protocol properties available in TAO. -<ul> -<li> -<b>IIOP</b></li> - -<br>Protocol <i>ProfileId</i>: 0 -<br>Transport properties interface name: <i>RTCORBA::TCPProtocolProperties</i> -(standard) -<br>Implementation class name: <i>TAO_TCP_Properties</i> -<table BORDER CELLPADDING=4 HEIGHT="150" > -<tr> -<td ALIGN=CENTER HEIGHT="19"><b>Protocol Properties Attribute</b></td> - -<td ALIGN=CENTER HEIGHT="19"><b>Default Value</b></td> -</tr> - -<tr> -<td HEIGHT="19">long <i>send_buffer_size</i></td> - -<td ALIGN=LEFT HEIGHT="19"><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> -</tr> - -<tr> -<td HEIGHT="19">long <i>recv_buffer_size</i></td> - -<td ALIGN=LEFT HEIGHT="19"><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> -</tr> - -<tr> -<td HEIGHT="19">boolean <i>keep_alive</i> (not yet supported)</td> - -<td ALIGN=LEFT HEIGHT="19"><tt>1</tt></td> -</tr> - -<tr> -<td HEIGHT="19">boolean <i>dont_route</i> (not yet supported)</td> - -<td ALIGN=LEFT HEIGHT="19"><tt>0</tt></td> -</tr> - -<tr> -<td HEIGHT="19">boolean <i>no_delay</i></td> - -<td ALIGN=LEFT HEIGHT="19"><tt>1</tt></td> -</tr> -</table> - -<li> -<b>UIOP</b></li> - -<br>Protocol <i>ProfileId</i>: 0x54414f00U -<br>Transport properties interface name: <i>RTCORBA::UnixDomainProtocolProperties</i> -(TAO-specific) -<br>Implementation class name: <i>TAO_Unix_Domain_Properties</i> -<table BORDER CELLPADDING=4 > -<tr> -<td ALIGN=CENTER><b>Protocol Properties Attribute</b></td> - -<td ALIGN=CENTER><b>Default Value</b></td> -</tr> - -<tr> -<td>long <i>send_buffer_size</i></td> - -<td><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> -</tr> - -<tr> -<td>long <i>recv_buffer_size</i></td> - -<td><tt>ACE_DEFAULT_MAX_SOCKET_BUFSIZ</tt></td> -</tr> -</table> - -<li> -<b>SHMIOP</b></li> - -<br>Protocol <i>ProfileId</i>: 0x54414f02U -<br>Transport properties interface name: <i>RTCORBA::SharedMemoryProtocolProperties</i> -(TAO-specific) -<br>Implementation class name: <i>TAO_SMEM_Properties</i> -<table BORDER CELLPADDING=4 > -<tr> -<td ALIGN=CENTER><b>Protocol Properties Attribute</b></td> - -<td ALIGN=CENTER><b>Default Value</b></td> -</tr> - -<tr> -<td>long <i>preallocate_buffer_size</i></td> - -<td>not yet supported</td> -</tr> - -<tr> -<td>string <i>mmap_filename</i></td> - -<td>not yet supported</td> -</tr> - -<tr> -<td>string <i>mmap_lockname</i></td> - -<td>not yet supported</td> -</tr> -</table> -</ul> -Real-Time CORBA 1.0 does not define how protocol properties are created. -<i>TAO_Protocol_Factory</i> -class can be used to create default <i>ProtocolProperties</i> for a particular -protocol given its <i>ProfileId</i>: -<p><tt>class TAO_Protocol_Properties_Factory</tt> -<br><tt>{</tt> -<br><tt>public:</tt> -<p><tt>static RTCORBA::ProtocolProperties*</tt> -<br><tt>create_transport_protocol_property (IOP::ProfileId id);</tt> -<p><tt>static RTCORBA::ProtocolProperties*</tt> -<br><tt>create_orb_protocol_property (IOP::ProfileId id);</tt> -<br><tt>};</tt> -<p>Alternatively, concrete <i>ProtocolProperties</i> implementation classes -can be instantiated directly as needed. -<p>The table below summarizes how protocol policies overrides affect protocol -selection and configuration in TAO. -<br> -<table BORDER CELLPADDING=4 > -<tr> -<td ALIGN=CENTER><b>Policy</b></td> - -<td ALIGN=CENTER><b>ORB default</b></td> - -<td ALIGN=CENTER><b>Override levels that have impact on protocol selection</b></td> - -<td ALIGN=CENTER><b>Override levels that have impact on protocol configuration</b></td> -</tr> - -<tr> -<td><i>ServerProtocolPolicy</i></td> - -<td>All protocols loaded into the ORB, in the order they were loaded.</td> - -<td>ORB -<br>POA</td> - -<td>ORB -<br>(If no protocol properties are specified at the ORB level, default -protocol configurations are used.)</td> -</tr> - -<tr> -<td><i>ClientProtocolPolicy</i></td> - -<td>None</td> - -<td>ORB -<br>Current -<br>Object</td> - -<td>ORB -<br>(If no protocol properties are specified at the ORB level, default -protocol configurations are used.)</td> -</tr> -</table> - -<p>NOTE: <tt>-ORBSndSock</tt> and <tt>-ORBRcvSock</tt> ORB options have -no effect when RTCORBA is enabled. -<p>Protocol policies do not depend on any other Real-Time CORBA features -and can be used alone. In fact, we plan to make protocol policies available -outside RTCORBA, and better integrate them with the Pluggable Protocols -framework in the near future. -<br> -<hr> -<h3> -<a NAME="diffserv"></a>Diffserv Support</h3> - -<p>Though the RT-CORBA specification details the real-time ORB, thread -priorities, and application scheduling requirements, it is less -explicit about the communication transport and the underlying -network priorities. Our research involved using Differentiated Services -technology to prioritize the RT-CORBA traffic in the network. This -effort required two essential enhancements to the TAO ORB. First, we -provided an efficient and flexible way of setting the DSCP codepoints -in the data packets, which is done by extending the ORB protocol -properties. DSCP codepoints can dynamically change, based on many -factors like QoS feedback received from external QoS monitoring -resources or even a change in the application policy. Second, we -provide a mechanism to map the RT-CORBA priorities to the Diff-Serv -network priorities. The detials of the implementation follows. -<dl> -<dt> -<b>Modifications to RTCORBA.pidl</b></dt> - -<br> -<ul> -<li> -<b>TCP Protocol Properties extension</b></li> - -<br> -<dd> -The TCP protocol properties interface was extended to add a flag, enable_network_priority. -When this flag is set to 1 the RTCORBA priority is mapped to network priority -(diffserv codepoint - DSCP) and this priority is set on the GIOP requests -and replies. When the flag is not set no network priorities are set on -the GIOP requests and replies and are hence best effort.</dd> - -<p><tt>local interface TCPProtocolProperties : ProtocolProperties</tt> -<br><tt>{</tt> -<br><tt>attribute long send_buffer_size;</tt> -<br><tt>attribute long recv_buffer_size;</tt> -<br><tt>attribute boolean keep_alive;</tt> -<br><tt>attribute boolean dont_route;</tt> -<br><tt>attribute boolean no_delay;</tt> -<br><tt>attribute boolean enable_network_priority;</tt> -<br><tt>};</tt> -<br> -<li> -<b>Network Priority Mapping Interfaces</b></li> - -<dd> -<p>Support was added for mapping RTCORBA priority to Network Priority. It -is similar to the RTCORBA to native thread priority mapping.</dd> - -<p><tt>typedef long NetworkPriority;</tt> -<br><tt>native NetworkPriorityMapping;</tt></ul><br> - -<dt> -<b>Usage</b></dt> - -<br> -<ul> -<li> -<b>Client - Setting DSCP on the GIOP Requests</b></li> - -<br><br> -<dd> -1. <i>Create TCP protocol properties</i> - The enable_network_priority -flag implies the setting/unsetting of the network priority.</dd> - -<p><tt>RTCORBA::TCPProtocolProperties_var tcp_properties =</tt> -<br><tt> rt_orb->create_tcp_protocol_properties (send_buffer_size,</tt> -<br><tt> -recv_buffer_size,</tt> -<br><tt> -1, //keep alive</tt> -<br><tt> -0, //don't route</tt> -<br><tt> -1, //no delay</tt> -<br><tt> -enable_network_priority);</tt> -<p>2. <i>Create TCP Protocol Properties Policy</i> -<p><tt>RTCORBA::ProtocolList protocols;</tt> -<br><tt>protocols.length (1);</tt> -<br><tt>protocols[0].protocol_type = 0; //IIOP</tt> -<br><tt>protocols[0].transport_protocol_properties =</tt> -<br><tt> RTCORBA::ProtocolProperties::_duplicate (tcp_properties.in -());</tt> -<br><tt>protocols[0].orb_protocol_properties =</tt> -<br><tt> RTCORBA::ProtocolProperties::_nil ();</tt> -<p><tt>CORBA::PolicyList policy_list;</tt> -<br><tt>policy_list.length (1);</tt> -<br><tt>policy_list[0] =</tt> -<br><tt> rt_orb->create_client_protocol_policy (protocols);</tt> -<p>3.<i> Set TCP Protocol Properties Policy</i> -<p><b>ORB Level</b> - This implies that the tcp protocol properties set -will apply to every invocation made with this ORB. -<p><tt>CORBA::Object_var object =</tt> -<br><tt>orb->resolve_initial_references ("ORBPolicyManager");</tt> -<br><tt>CORBA::PolicyManager_var policy_manager =</tt> -<br><tt> CORBA::PolicyManager::_narrow (object.in ());</tt> -<br><tt>policy_manager->set_policy_overrides (policy_list,</tt> -<br><tt> -CORBA::SET_OVERRIDE);</tt> -<p><b>THREAD Level</b> - This implies that the tcp protocol properties -set will apply to all the invocations made in the corresponding thread -only. All other invocations will have the TCP protocol properties set at -the ORB level. -<p>orb->orb_core ()->policy_current ().set_policy_overrides (policy_list, -<br> -CORBA::SET_OVERRIDE); -<p><b>OBJECT Level</b> - This implies that the tcp protocol properties -set will apply to the invocations made on the corresponding object only. -<p><tt>CORBA::Object_var object = server->_set_policy_overrides (policy_list,</tt> -<br><tt> -CORBA::SET_OVERRIDE);</tt> -<p><tt>server = Test::_narrow (object.in ()); //server is the CORBA Object</tt> -<p>The above steps can be applied repeatedly to create and set TCP protocol -properties on the client to enable/disable network priority on the GIOP -requests. Since the TCP protocol properties are updated per invocation -the most recently set policy will apply. -<br> -<li> -<b>Server - Setting DSCP on the GIOP Replies</b></li> - -<br> -<dd> -1. <i>Create the TCP protocol properties</i> - The enable_network_priority -flag implies the setting/unsetting of the network priority.</dd> - -<p><tt>RTCORBA::TCPProtocolProperties_var tcp_properties =</tt> -<br><tt> rt_orb->create_tcp_protocol_properties (send_buffer_size,</tt> -<br><tt> -recv_buffer_size,</tt> -<br><tt> -1, //keep alive</tt> -<br><tt> -0, //don't route</tt> -<br><tt> -1, //no delay</tt> -<br><tt> -enable_network_priority);</tt> -<p>2. <i>Create TCP Protocol Properties Policy</i> -<p><tt>RTCORBA::ProtocolList protocols;</tt> -<br><tt>protocols.length (1);</tt> -<br><tt>protocols[0].protocol_type = 0; //IIOP</tt> -<br><tt>protocols[0].transport_protocol_properties =</tt> -<br><tt> RTCORBA::ProtocolProperties::_duplicate (tcp_properties.in -());</tt> -<br><tt>protocols[0].orb_protocol_properties =</tt> -<br><tt> RTCORBA::ProtocolProperties::_nil ();</tt> -<br> -<p><tt>CORBA::PolicyList policy_list;</tt> -<br><tt>policy_list.length (1);</tt> -<br><tt>policy_list[0] =</tt> -<br><tt> rt_orb->create_server_protocol_policy (protocols);</tt> -<p>3. <i>Create POA with Diffserv enabled</i> -<p><tt>CORBA::PolicyList poa_policy_list;</tt> -<br><tt>poa_policy_list.length (1);</tt> -<br><tt>poa_policy_list [0] =</tt> -<br><tt> rt_orb->create_server_protocol_policy (protocols);</tt> -<p><tt>PortableServer::POA_var poa_with_ds =</tt> -<br><tt>root_poa->create_POA ("POA_WITH_DS",</tt> -<br><tt> -poa_manager.in (),</tt> -<br><tt> -poa_policy_list );</tt> -<p>All the servants that want network priority set on their replies should -register with this POA. -<p>NOTE - The POA policy can be set only once. This implies that all replies -sent from the POA that has the network priority set will have the DSCP -set on them. In order to unset the network priority one has to use a different -POA without the network priority set on it. -<br> </ul> - -<dt> -<b>Network Priority Mapping</b></dt> - -<br> -<ul> -<li> -<b>NetworkPriorityMapping interface</b></li> - -<br> -<dd> -The RTCORBA to network priority mapping framework is similar to the RTCORBA -to native thread priority mapping framework. As mentioned in section 2.1.2 -this is implemented by providing the native interface NetworkPriorityMapping. -The native interface is implemented in the RTCORBAC.h as: - -<p><tt>typedef TAO_Network_Priority_Mapping -NetworkPriorityMapping;</tt></dd> - -<p><tt>Where TAO_Network_Priority_Mapping is defined as:</tt> -<p><tt>class TAO_Network_Priority_Mapping</tt> -<br><tt>{</tt> -<br><tt>public:</tt> -<br><tt> virtual CORBA::Boolean to_network (RTCORBA::Priority -corba_priority,</tt> -<br><tt> -RTCORBA::NetworkPriority &network_priority) = 0;</tt> -<br><tt> virtual CORBA::Boolean to_CORBA (RTCORBA::NetworkPriority -network_priority,</tt> -<br><tt> -RTCORBA::Priority &corba_priority) = 0;</tt> -<br><tt>};</tt> -<p>The methods to_network (…) and to_corba (…) can be implemented differently -for different mapping algorithms that can be defined by the application. -<br> -<li> -<b>Default Network Priority Mappings</b></li> - -<br> -<dd> -TAO implements the default Linear Mapping from RTCORBA to Diffserv Codepoint -mapping. Further mappings may be added to TAO. The application can choose -these TAO supported mappings through the Service Configurator (svc.conf) -files with the following entry:</dd> - -<p>static RT_ORB_Loader "-ORBSchedPolicy SCHED_FIFO -ORBScopePolicy PROCESS --ORBPriorityMapping direct <i>-ORBNetworkPriorityMapping Linear</i>" -<br> -<li> -<b>Network Priority Mapping Manager</b></li> - -<br> -<dd> -A NetworkPriorityMappingManager is defined in TAO to manage the Network -Priority Mapping.</dd> - -<p><tt>typedef TAO_Network_Priority_Mapping_Manager NetworkPriorityMappingManager;</tt> -<p><tt>Where TAO_Network_Priority_Mapping_Manager is:</tt> -<p><tt>class TAO_RTCORBA_Export TAO_Network_Priority_Mapping_Manager :</tt> -<br><tt>{</tt> -<br><tt>public:</tt> -<br><tt> TAO_Network_Priority_Mapping_Manager (RTCORBA::NetworkPriorityMapping -* mapping);</tt> -<br><tt> void mapping (RTCORBA::NetworkPriorityMapping -* mapping);</tt> -<br><tt> RTCORBA::NetworkPriority_Mapping *mapping (void);</tt><tt></tt> -<p><tt>private:</tt> -<br><tt> TAO_Network_Priority_Mapping *mapping_;</tt> -<br><tt>};</tt> -<p>The application developer can add his custom network priority mappings -as described in section 2.3.3 using the NetworkPriorityMappingManager. -<br> -<li> -<b>Custom Network Priority Mapping</b></li> - -<br> -<dd> -In order to implement a custom network priority mapping the application -developer should implement the methods of the TAO_Network_Priority_Mapping -class. E.g:</dd> - -<p><tt>class TAO_Custom_Network_Priority_Mapping :</tt> -<br><tt>public TAO_Network_Priority_Mapping</tt> -<br><tt>{</tt> -<br><tt> virtual CORBA::Boolean to_network (RTCORBA::Priority -corba_priority,</tt> -<br><tt> -RTCORBA::NetworkPriority &network_priority);</tt> -<br><tt> virtual CORBA::Boolean to_CORBA (RTCORBA::NetworkPriority -network_priority,</tt> -<br><tt> -RTCORBA::Priority &corba_priority);</tt> -<br><tt>};</tt> -<p>This custom Network Priority Mapping can then be loaded into the Network -Priority Mapping Manager as follows: -<p><tt># Resolve the Network priority Mapping Manager</tt> -<br><tt>CORBA::Object_var object = orb->resolve_initial_references ("NetworkPriorityMappingManager");</tt> -<br><tt>RTCORBA::NetworkPriorityMappingManager_var mapping_manager = RTCORBA::NetworkPriorityMappingManager::_narrow -(object.in ());</tt> -<p><tt># Initialize the custom priority mapping</tt> -<br><tt>TAO_Custom_Network_Priority_Mapping *cnpm = 0;</tt> -<br><tt>ACE_NEW (cnpm,</tt> -<br><tt> TAO_Custom_Network_Priority_Mapping);</tt> -<p><tt>#Load the custom network priority mapping object in the network -priority</tt> -<br><tt>#mapping manager. The user can thus add his own priority mapping.</tt> -<br><tt>mapping_manager->mapping (cnpm);</tt> -<p>This ensures that the Custom Network Priority Mapping will be used to -map the RTCORBA priority to the network priority. -</ul> -<br> -<i>Last Modified: $Date$</i></dl> - -</body> -</html> diff --git a/TAO/docs/rtcorba/index.html b/TAO/docs/rtcorba/index.html deleted file mode 100644 index 994b5dd6398..00000000000 --- a/TAO/docs/rtcorba/index.html +++ /dev/null @@ -1,23 +0,0 @@ -<html> -<!-- $Id$ --> - -<head> -<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> -<title>TAO Real-Time CORBA Documentation</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -<meta name="ProgId" content="FrontPage.Editor.Document"> -</head> - -<frameset cols="300,*"> - <frame name="contents" target="main" src="content.html" scrolling="auto"> - <frame name="main" src="status.html"> - <noframes> - <body> - - <p>This page uses frames, but your browser doesn't support them.</p> - - </body> - </noframes> -</frameset> - -</html> diff --git a/TAO/docs/rtcorba/issues.html b/TAO/docs/rtcorba/issues.html deleted file mode 100644 index 43c3e1979b0..00000000000 --- a/TAO/docs/rtcorba/issues.html +++ /dev/null @@ -1,231 +0,0 @@ -<html> - -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>Implementation Issues and Known Bugs</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -</head> - -<body> - -<h3><a name="top">Known Issues and TO-DO Items</a></h3> -<p>This page contains a list of known RTCORBA-related issues and to-do -items. The list does not include any of the reports from the bug tracking -system, so be sureto <a href="http://deuce.doc.wustl.edu/bugzilla/index.cgi">query -Bugzilla</a> for RTCORBA entries. </p> -<ol> - <li><a href="#7">Integrating protocol policies with the Pluggable Protocols framework</a></li> - <li><a href="#10">Integrating Implementation Repository with RTCORBA and PP</a></li> - <li><a href="#12">Priority Banded Connections interoperability issues</a></li> - <li><a href="#2">Removing dependencies on ORB debug output from RTCORBA tests</a></li> - <li><a href="#14">Adding RTCORBA examples</a></li> - <li><a href="#5">Improving management of Private Connections</a></li> - <li><a href="#6">Redesigning profile management to satisfy new requirements - and to provide full - support for location forwarding</a></li> - <li><a href="#11">Location forwarding with client-exposed policies</a></li> - <li><a href="#8">Moving FT endpoint selection into the endpoint selectors framework</a></li> - <li><a href="#3">Introducing guidelines for debug output in TAO</a><br> - </li> -</ol> -<hr> -<h4><a name="7">Integrating protocol policies with the Pluggable Protocols -framework</a></h4> -<p><i>RTCORBA::ServerProtocolPolicy</i> and <i>RTCORBA::ClientProtocolPolicy</i> -allow -application developers to select and configure ORB communication protocols, and -to specify preferred order of their use. This functionality has been implemented -in TAO, but is only available with RTCORBA. Since protocol management -is of interest to a large chunk of TAO users (many of whom do not need RTCORBA -otherwise), -we should make protocol policies available even when RTCORBA is not used, better -integrate them with the Pluggable Protocols framework, and provide a number of -other enhancements.</p> -<ol> - <li>Integrate protocol policies with PP framework. Make concrete <i> Protocol_Factories</i> -responsible for creating corresponding <i>ProtocolProperties</i> with default and user-specified -values (rather than having the knowledge about concrete <i>ProtocolProperties </i>embedded in the ORB). - This will enable the protocol policies to be used to -configure any pluggable protocols without having to modify the ORB code for -each protocol.<br> - </li> - <li>Make protocol policies available even when RTCORBA is not used. Once -this is done, remove (or deprecate) <i>-ORBSndSock</i>, <i>-ORBRcvSock</i>, -and <i>-ORBNodelay</i> ORB options.<br> - </li> - <li>Add support for <i>TCPProtocolProperties::dont_route</i> - in IIOP.<br> </li> - <li>Add support for protocol properties configuration in SHMIOP. (SHMIOP - properties are defined in <i>RTCORBA::SharedMemoryProtocolProperties</i>, but - are currently not supported in the protocol implementation.)</li> -</ol> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="10">Integrating Implementation Repository with RTCORBA and PP</a></h4> -<p>Current version of Implementation Repository does not work properly with -RTCORBA or Pluggable Protocols because it does not handle multiple endpoints for -one server. Once RTCORBA implementation is complete, we should look into -redesign of Implementation Repository.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="12">Priority Banded Connections interoperability issues</a></h4> -<p> - -Section 4.12.2 (Binding of Priority Banded Connection) of the RT-CORBA -spec talks about the <CODE>_bind_priority_band</CODE> implicit -operation. Clearly, this operation is not completely defined and -neither is the reply to this implicit operation. Therefore, it is -almost impossible to get interoperability between RT-ORBs with respect -to this operation. <p> - -Even if we make assumptions about the <CODE>_bind_priority_band</CODE> -implicit operation and its reply, it leads to an architecture where -there is unnecessary jitter and unpredictability because the -connection needs to be moved from the Reactor associated with the -Acceptor to the Reactor associated with correct priority. This is -either done with the <CODE>_bind_priority_band</CODE> method or with -the first request. <p> - -Because of the above mentioned issues, TAO does not use -<CODE>_bind_priority_band</CODE> operation and <CODE> -RTCorbaPriorityRange</CODE> service context during band -establishment. Instead, the server embeds a proprietary <CODE> -TAO_TAG_ENDPOINTS</CODE> tagged component into an object's IOR to let -the clients know about available priorities and corresponding -endpoints. To establish a banded connection, the client simply uses -the endpoint corresponding to the priority of interest. (See <a -href="architecture.html">TAO Real-Time Architecture</a> section for -more details.)<p> - -Once the semantics of the <CODE>_bind_priority_band</CODE> operation -have been fully described by the specification or if the application -can deal with the unpredictability of the first request, and TAO can -be redesigned to handle the additional complexity of connection -movement between the Reactors, we can change the behavior of Priority -Banded Connections by: - -<ol> - - <li>modifying client to use <CODE>bind_priority_band</CODE> - operation and <CODE> RTCorbaPriorityRange </CODE> service context - during <CODE>Object::_validate_connection()</CODE> </li> - - <li>modifying server to move a connection to the appropriate reactor - once it receives <CODE> bind_priority_band </CODE>request and/or - <CODE> RTCorbaPriorityRange </CODE> service context</li> - - <li>modifying client to store and look up connections based on - address + priority range rather than just based on address - alone</li> </ol> - -<p><a href="#top">[back]</a></p> - -<hr> - -<h4><a name="2">Removing dependencies on ORB -debug output from RTCORBA tests</a></h4> -<p>Some of the RTCORBA tests rely on ORB debugging output for checking whether -something works. This is <i> very</i> <i> brittle</i> since ORB developers frequently -add/remove/modify debugging messages, causing tests to 'break', and increasing -amount of maintenance effort required. Yet, we somehow need to verify that <i>internally</i> the ORB behaves as we expect, <i>e.g.</i>, a particular transport protocol -is used to carry out an invocation. It may be possible to achieve this without -depending on ORB debug messages by using Portable Interceptors or some other -similar mechanism. For example, we could write several interceptors, which would -obtain and print information of interest for the test. We -should look into this.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="14">Adding RTCORBA examples</a></h4> -<p>We do have tests for RTCORBA features, but what we also need are some -examples. Use case-driven examples illustrating how certain features help -satisfy various requirements. Examples that would help users understand -when to use various features.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="5">Improving management of Private Connections</a></h4> -<p>Currently, when the object that has private connections is destroyed, its -connections remain in the cache. We need to implement cleanup of private -connections on object destruction. If such cleanup is expensive, we may -want to have it controlled by an option.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="6">Redesigning profile management to satisfy new requirements and -to provide full -support for location forwarding</a></h4> -<p>Current client profile management code needs to change for the -following reasons:</p> -<ol> - <li>Original design assumed that all threads using the same object reference - would want to use the same profile for making an invocation. Hence, certain - state, <i>i.e.</i>, <CODE>profile_in_use, profile_sucess and forward_profiles, - </CODE> - is stored per <i>Stub</i>. This assumption no longer holds true, <i>e.g.</i>, - different threads may have different policies set, and would want to use - different profiles based on those policies. This is at least the case with - RTCORBA, where different threads may, for example, want to use different - protocols. It may also be the case in other scenarios. So, we should not keep - the state per <i>Stub</i>.</li> - <li>Current design does not properly support location forwarding more than one - level deep. And with certain policy configurations, location - forwarding is not supported at all.</li> - <li>Current interfaces are very polluted: many tiny functions with similar - names calling into each other, comments in <i> .h</i> files outdated, comments in - <i> .cpp</i> files mostly absent.</li> - <li>Lack of thorough test suite.</li> -</ol> -<p>Also, redesign of profile management is a good time to add support for -<CODE>TAG_ALTERNATE_IIOP</CODE> (multiple endpoints per profile).</p> -<p>Bala is familiar with profile management code, and has agreed to act as a -consultant/guide when somebody tackles this item.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="11">Location forwarding with client-exposed policies</a></h4> -<p>When an object is forwarded, a new set of profiles is received, and they can -potentially include different client-exposed policies. Currently, we don't handle this case, -<i>i.e.</i>, the set of client-exposed policies from the object's original IOR is -used for its complete lifetime. This item is related to the <a href="#6">profile -management</a> issue.</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="8">Moving FT endpoint selection into the endpoint selector -framework</a></h4> -<p>Selection of endpoints for invocations in TAO is strategized, with strategies for -different policy combinations located in <i>Invocation_Endpoint_Selectors.*</i> -Bala -may want to make FT-based endpoint selection one of the available strategies. -(Currently it's not part of the endpoint selectors framework.)</p> - -<p><a href="#top">[back]</a></p> - -<hr> -<h4><a name="3">Introducing guidelines for debug output in TAO</a></h4> -<p>Speaking of ORB debug output, there is not much consistency about it in TAO: -not in the use of ORB debug levels, not in the style and detail of debug messages. It is probably a good idea to come up with a short list of -guidelines for debugging messages - this would make the output more useful (if -the guidelines are followed, of course ;-) )</p> - -<p><a href="#top">[back]</a></p> - -<hr> - -<i> - -<p>Last modified: $Date$ </i></p> -<p></p> -</body> -</html> diff --git a/TAO/docs/rtcorba/omg_issues.html b/TAO/docs/rtcorba/omg_issues.html deleted file mode 100644 index bb49722b205..00000000000 --- a/TAO/docs/rtcorba/omg_issues.html +++ /dev/null @@ -1,103 +0,0 @@ -<html> - -<!-- $Id$ --> -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>Issues with OMG Real-Time CORBA 1.0 Specification</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -</head> - -<body> - -<h3>Issues with Real-Time CORBA 1.0 Specification</h3> - -This document lists what we believe to be the shortcomings of the -Real-Time CORBA 1.0 specification, which we uncovered while implementing it in TAO. -All items on this page refer to <a href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">ptc/99-05-03</a>, which was -the basis for our implementation. This material will be submitted to the -OMG. -<h3> - -Unnecessary <i>ClientProtocolPolicy</i> complexity</h3> -<p> - -<i>ClientProtocolPolicy</i> can be set on either client or server. Section 4.8.5 -in CORBA 2.4 cautions against defining policies that can be set -in both places: -<blockquote><br> - If the <b><font FACE="Arial" SIZE="2">Policy </font></b> can be -used with <b><font FACE="Arial" SIZE="2">POA </font></b>creation -to tune <b><font FACE="Arial" SIZE="2">IOR </font></b>contents -and can also be specified (overridden) in the client, specify how to reconcile the policy's -presence from both the client and server. It is strongly recommended to avoid this -case! As an exercise in completeness, most <b><font FACE="Arial" SIZE="2">POA </font></b>policies -can probably be extended to have -some meaning in the client and vice versa, but this does not help make usable -systems, it just makes them more complicated without adding really useful -features. -There are very few cases where a policy is really appropriate to specify in -both places, and for these policies the interaction between the two must be -described. </blockquote> -<p>While the specification does describe what happens if <i>ClientProtocolPolicy</i> -is set on both client and server, it is not clear that being able to set the -policy on the server-side adds any useful functionality. With <i>ServerProtocolPolicy, -</i>the server already has the ability to specify which protocols and in what -order can be used by clients for invocations. So, <i>ClientProtocolPolicy</i> -should be made a pure client policy, to reduce the complexity of the -system. A related issue, which becomes moot if the policy is made pure -client, is whether <CODE>nil</CODE> <i>ProtocolProperties</i> are allowed in <i>ClientProtocolPolicy</i>, -and, if so, how are they encoded into a <i>TaggedComponent</i> if the policy is -set on the server-side.</p> -<h3>Lack of standard APIs for managing Priority Mappings and Priority Transforms</h3> -<p>The specification does not define APIs for setting and getting Priority Mappings and Priority Transforms, -leaving it up to ORB implementations. These APIs should be standardized in -order for application code to be portable. -</p> -<h3> -Policy configurations ambiguities</h3> -<p>The specification defines a number of policies involving priorities, and -describes some of their interaction. However, it does not completely -specify the validity and semantics of <i>all</i> possible combinations of those -policies. For example, does the combination of Server Declared Priority -Model with server-set Priority Banded Connections make sense? For all values? -If the purpose of Priority Banded Connections is to avoid priority inversions, -then why would we ever want to use <i>PriorityModelPolicy</i> without <i>PriorityBandedConnectionPolicy</i>? -And, if we would <i>always</i> want to use Priority Banded Connections, why does -there need to be a policy, why can't banded connections be a mechanism the ORB -uses internally as needed, transparent to the user? </p> -<p>What is clear from the spec is the availability of certain policies, what is -not clear is what exactly using each one of those policies achieves - in other -words, when and why different combinations of them are appropriate. </p> -<h3>Lack of thread resources model</h3> -<p> Section 4.12.2 of the specification says the following about server ORB and -priority band establishment: <cite>"if the priority band -is inconsistent with the ORB's priority configuration then the ORB shall raise a -INV_POLICY system exception". </cite>However, the specification -never defines what is meant by <i>the ORB's priority configuration,</i> leaving -it up to implementations. One implementation, for example, might use -Threadpool threads for servicing banded connections, and <i>consistency with the -ORB's configuration</i> would mean availability of a threadpool lane with -priority matching band's priority range. Another implementation might be -spawning separate threads for servicing banded connections, and <i>consistency -with the ORB's configuration</i> would be automatic. With these two -implementations, a band that will cause exception in the first implementation -will work just fine in the second. The specification does not provide a -model of ORB thread resources: it provides APIs for creating Threadpools, but -does not describe how the threadpool threads are used. I/O threads are -never even mentioned. On one hand, this lack of a resource model is -beneficial: it allows greater freedom and variety of implementations. But, -on the other hand, it hurts portability, since a configuration might work with -one real-time ORB implementation but not another. Also, bounding priority inversions -is a quality of implementation: there is no explicit requirement for I/O threads to run at the same priority as request processing threads.</p> - -<p>In summary, we believe that Real-Time CORBA 1.0 specification is a good -start, but needs some work, especially in regards to resolving -ambiguities. Currently, applications must depend on many implementation details. -For example, a policy combination providing certain semantics in one ORB can -provide different semantics or be invalid when used in another ORB, with both -ORBs being compliant with the specification. </p> - -<hr> -<p><i>Last Modified: $Date$</i></p> -</body> -</html> diff --git a/TAO/docs/rtcorba/queue-per-lane.gif b/TAO/docs/rtcorba/queue-per-lane.gif Binary files differdeleted file mode 100644 index cff639fc568..00000000000 --- a/TAO/docs/rtcorba/queue-per-lane.gif +++ /dev/null diff --git a/TAO/docs/rtcorba/reactor-per-lane.gif b/TAO/docs/rtcorba/reactor-per-lane.gif Binary files differdeleted file mode 100644 index 37f2195acdb..00000000000 --- a/TAO/docs/rtcorba/reactor-per-lane.gif +++ /dev/null diff --git a/TAO/docs/rtcorba/status.html b/TAO/docs/rtcorba/status.html deleted file mode 100644 index 781617616b7..00000000000 --- a/TAO/docs/rtcorba/status.html +++ /dev/null @@ -1,131 +0,0 @@ -<html> -<!-- $Id$ --> - -<head> -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> -<title>Status of Real-Time CORBA Support in TAO</title> -<meta name="GENERATOR" content="Microsoft FrontPage 4.0"> -</head> - -<body> - -<h3><a name="intro">Real-Time CORBA Support in TAO</a> </h3> -<a name="status"> - -<p>Support for <a href="http://www.omg.org">OMG</a> <a -href="http://cgi.omg.org/cgi-bin/doc?ptc/99-05-03">Real-Time CORBA 1.0 -specification</a> has been added to TAO. For an overview of Real-time -CORBA features, please see the <A -HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html#rt">C/C++ Users -Journal columns</A> written by <A -HREF="http://www.cs.wustl.edu/~schmidt/">Douglas Schmidt</A> and <A -HREF="http://www.iona.com/hyplan/vinoski/">Steve Vinoski</a>. For a -detailed design discussions and results of empirical performance -analyzes of TAO's Real-time CORBA implementation, please see the <A -HREF="http://www.cs.wustl.edu/~schmidt/doc-group.html">DOC group's</a> -<A -HREF="http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html">Real-time -CORBA research page</A>. - -<p>As usual, questions, comments, and contributions should be posted -to the <a href="news:comp.soft-sys.ace">comp.soft-sys.ace</a> -newsgroup, and bug reports can be submitted either through our -web-based <a -href="http://ace.cs.wustl.edu/bugzilla/index.cgi">bug-tracking -system</a> (best) or by filling out the <A -HREF="../../PROBLEM-REPORT-FORM">TAO_ROOT/PROBLEM-REPORT-FORM</A> -and posting it to the newsgroup. Please indicate "RTCORBA" -in the component field when submitting a bug report. </p> - -<p>Points of contact for the project are: - -<ul> - <li><a href="mailto:corsaro@cs.wustl.edu">Angelo Corsaro</a> - collocation and policy - encoding into ior</li> - <li><a href="mailto:irfan@cs.wustl.edu">Irfan Pyarali</a> - POA threadpools and RT POA</li> - <li><a href="mailto:marina@cs.wustl.edu">Marina Spivak</a> - all other features and online - documentation </li> - <li><a href="mailto:yamuna@oomworks.com">Yamuna Krishnamurthy</a> - Diffserv support in RTCORBA </li> -</ul> - -<h3><a name="supported">Supported Features</a></h3> - -<p>Following is the complete list of features from the Real-Time CORBA 1.0 specification -that are currently supported in TAO. (These do not include <a href="#in progress">work -in progress</a>). - -<ul> - <li>Real-Time ORB</li> - <li>Real-Time POA</li> - <li>Real-Time Current</li> - <li>Priority Mappings</li> - <li>Client_Propagated Priority Model</li> - <li>Server_Declared Priority Model</li> - <li>Server Protocol Policy</li> - <li>Client Protocol Policy</li> - <li>Priority Banded Connections</li> - <li>Explicit Binding</li> - <li>Private Connections</li> - <li>Invocation Timeout</li> - <li>RT Mutex</li> - <li>POA Threadpools</li> -</ul> - -<h3><a name="unsupported">Unsupported Features</a></h3> - -<p>The following features are not currently supported, and there are no immediate plans -for their implementation: - -<ul> - <li>POA Threadpool request buffering</li> - <li>POA Threadpool thread borrowing </li> - <li>Priority Transforms</li> - <li>ORBinit command-line option</li> -</ul> - -<h3><a name="future">Future Work</a></h3> - -<ol> - - <li>Currently, persistent objects are not supported for RT POAs. We - need to add this feature.</li> - - <li>Currently, purging of connection only happens for the lane of - the thread that runs out of connection. We need to change this - such that we allow system wide purging.</li> - - <li>Currently, all user-created threads are part of the default - thread pool. There is nothing done to separate out these threads - into different (implicit) lanes based on their priorities. We may - need to add this separation to get better/predictable behavior - with respect to sharing of resources across threads of different - priorities.</li> - - <li>Currently, some CDR memory pools are global. We should - reevaluate them to see which of them can be made a per-lane - resource.</li> - - <li>Improve current RT CORBA implementation through benchmarking and - optimizations, resolving known bugs and issues, adding examples, - and other enhancements.</li> - - <li>Implement an alternative real-time orb architecture using a - <em>queue-per-lane</em> approach, as described in the <a - href="architecture.html">TAO Real-Time Architecture</a> - section. In this approach, each threadpool lane owns a queue, - while I/O resources are being shared among all the threadpool - lanes of the same priority within a server. Strategize TAO to use - either <em>queue-per-lane</em> or <em>reactor-per-lane</em> - implementation, and compare the two.</li> - - <li>As both real-time and fault tolerance implementations mature - separately, explore issues in combining them, and, ultimately, - enable TAO to provide applications with both real-time and fault - tolerance support at the same time. </li> </ol> - -<hr> -<i> - -<p>Last modified: $Date$</i></p> -</body> -</html> diff --git a/TAO/docs/tao.css b/TAO/docs/tao.css deleted file mode 100644 index 67c9baefb84..00000000000 --- a/TAO/docs/tao.css +++ /dev/null @@ -1,4 +0,0 @@ -BODY { - background: white; - color: black; -} diff --git a/TAO/docs/tutorials/Makefile.am b/TAO/docs/tutorials/Makefile.am deleted file mode 100644 index 324e1e3c1ed..00000000000 --- a/TAO/docs/tutorials/Makefile.am +++ /dev/null @@ -1,13 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -SUBDIRS = \ - Quoter - diff --git a/TAO/docs/tutorials/Quoter/AMI/Handler_i.cpp b/TAO/docs/tutorials/Quoter/AMI/Handler_i.cpp deleted file mode 100644 index 1167c78c3e0..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Handler_i.cpp +++ /dev/null @@ -1,82 +0,0 @@ -// -// $Id$ -// - -#include "Handler_i.h" -#include "ace/streams.h" - -Single_Query_Stock_Handler_i:: - Single_Query_Stock_Handler_i (int *response_count) - : response_count_ (response_count) -{ -} - -void -Single_Query_Stock_Handler_i::get_price_and_names (CORBA::Double ami_return_val, - const char *symbol, - const char *full_name) - throw (CORBA::SystemException) -{ - cout << "The price of one stock in \"" - << full_name << "\" (" << symbol << ") is " - << ami_return_val << endl; - (*this->response_count_)++; -} - -void -Single_Query_Stock_Handler_i:: - get_price_and_names_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - // We ignore the exception, but this counts as a reponse, otherwise - // the application would not finish. - cerr << "Exception raised while querying stock price" - << endl; - (*this->response_count_)++; -} - - -void -Single_Query_Stock_Handler_i::get_symbol (const char *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - get_symbol_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i::get_full_name (const char *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - get_full_name_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i::price (double) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - price_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} diff --git a/TAO/docs/tutorials/Quoter/AMI/Handler_i.h b/TAO/docs/tutorials/Quoter/AMI/Handler_i.h deleted file mode 100644 index fd3e78ec36e..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Handler_i.h +++ /dev/null @@ -1,43 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIALS_QUOTER_AMI_CLIENT_HANDLER_I_H -#define TAO_TUTORIALS_QUOTER_AMI_CLIENT_HANDLER_I_H - -#include "QuoterS.h" - -class Single_Query_Stock_Handler_i : public POA_Quoter::AMI_Single_Query_StockHandler -{ -public: - Single_Query_Stock_Handler_i (int *response_count); - - void get_price_and_names (CORBA::Double ami_return_val, - const char *symbol, - const char *full_name) - throw (CORBA::SystemException); - - void get_price_and_names_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void get_symbol(const char *) - throw (CORBA::SystemException); - void get_symbol_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void get_full_name (const char *) - throw (CORBA::SystemException); - void get_full_name_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void price (double) - throw (CORBA::SystemException); - void price_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - -private: - - int *response_count_; -}; - -#endif /* TAO_TUTORIALS_QUOTER_AMI_CLIENT_HANDLER_I_H */ diff --git a/TAO/docs/tutorials/Quoter/AMI/Makefile.am b/TAO/docs/tutorials/Quoter/AMI/Makefile.am deleted file mode 100644 index 06b7f62661a..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Makefile.am +++ /dev/null @@ -1,134 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_IDL = ACE_ROOT=$(ACE_ROOT) TAO_ROOT=$(TAO_ROOT) $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDL_DEP = $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDLFLAGS = -Ge 1 -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -I$(srcdir) -g $(ACE_BUILDDIR)/apps/gperf/src/gperf -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_AMI_Idl.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING - -BUILT_SOURCES = \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -CLEANFILES = \ - Quoter-stamp \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -QuoterC.cpp QuoterC.h QuoterC.inl QuoterS.cpp QuoterS.h QuoterS.inl: Quoter-stamp - -Quoter-stamp: $(srcdir)/Quoter.idl $(TAO_IDL_DEP) - $(TAO_IDL) $(TAO_IDLFLAGS) -GC $(srcdir)/Quoter.idl - @touch $@ - - -noinst_HEADERS = \ - Quoter.idl - -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Makefile.Quoter_AMI_Client.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) - -client_SOURCES = \ - Handler_i.cpp \ - QuoterC.cpp \ - QuoterS.cpp \ - client.cpp \ - Handler_i.h - -client_LDADD = \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Makefile.Quoter_AMI_Server.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) - -server_SOURCES = \ - QuoterC.cpp \ - QuoterS.cpp \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/AMI/Quoter.idl b/TAO/docs/tutorials/Quoter/AMI/Quoter.idl deleted file mode 100644 index 80cfa1661d1..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Quoter.idl +++ /dev/null @@ -1,49 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; - - interface Single_Query_Stock : Stock { - double get_price_and_names (out string symbol, - out string full_name); - }; -}; diff --git a/TAO/docs/tutorials/Quoter/AMI/Quoter_AMI.mpc b/TAO/docs/tutorials/Quoter/AMI/Quoter_AMI.mpc deleted file mode 100644 index b19033fbef3..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Quoter_AMI.mpc +++ /dev/null @@ -1,34 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*idl): taoidldefaults, ami { - IDL_Files { - Quoter.idl - } - custom_only = 1 -} - -project(*client) : taoexe, portableserver, ami, exceptions { - after += *idl - source_files { - client.cpp - Handler_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} - -project(*server) : taoserver, ami, exceptions { - after += *idl - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} diff --git a/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.cpp deleted file mode 100644 index a2323a6be36..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.cpp +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () - : rhat_ ("RHAT", "RedHat, Inc.", 210), - msft_ ("MSFT", "Microsoft, Inc.", 91) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this (); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.h deleted file mode 100644 index c0e51d1b3ea..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Stock_Factory_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/AMI/Stock_i.cpp b/TAO/docs/tutorials/Quoter/AMI/Stock_i.cpp deleted file mode 100644 index 776ce01a806..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Stock_i.cpp +++ /dev/null @@ -1,43 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} - -CORBA::Double -Quoter_Stock_i::get_price_and_names (CORBA::String_out symbol, - CORBA::String_out full_name) - throw (CORBA::SystemException) -{ - symbol = CORBA::string_dup (this->symbol_.c_str ()); - full_name = CORBA::string_dup (this->full_name_.c_str ()); - return this->price_; -} - diff --git a/TAO/docs/tutorials/Quoter/AMI/Stock_i.h b/TAO/docs/tutorials/Quoter/AMI/Stock_i.h deleted file mode 100644 index 27163f9d2a0..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/Stock_i.h +++ /dev/null @@ -1,35 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Single_Query_Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - CORBA::Double get_price_and_names (CORBA::String_out symbol, - CORBA::String_out full_name) - throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/AMI/client.cpp b/TAO/docs/tutorials/Quoter/AMI/client.cpp deleted file mode 100644 index fcb8a8f26da..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/client.cpp +++ /dev/null @@ -1,85 +0,0 @@ -// -// $Id$ -// - -#include "Handler_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 3) { - cerr << "Usage: " << argv[0] - << " Factory_IOR symbol symbol..." << endl; - return 1; - } - - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Use the first argument to create the factory object reference, - // in real applications we use the naming service, but let's do - // the easy part first! - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Create and activate the handler... - int response_count = 0; - Single_Query_Stock_Handler_i handler_i (&response_count); - Quoter::AMI_Single_Query_StockHandler_var handler = - handler_i._this (); - - // Send all the requests, careful with error handling - int request_count = 0; - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var tmp = - factory->get_stock (argv[i]); - Quoter::Single_Query_Stock_var stock = - Quoter::Single_Query_Stock::_narrow (tmp.in ()); - if (CORBA::is_nil (stock.in ())) { - cerr << "Cannot get single query interface for <" - << argv[i] << ">" << endl; - } - - stock->sendc_get_price_and_names (handler.in ()); - request_count++; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - while (response_count < request_count - && orb->work_pending ()) { - orb->perform_work (); - } - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/AMI/index.html b/TAO/docs/tutorials/Quoter/AMI/index.html deleted file mode 100644 index 359ede5a6fa..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/index.html +++ /dev/null @@ -1,233 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Asynchronous Method Invocation - CORBA for impatient clients</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Asynchronous Method Invocation - CORBA for impatient clients</h3> - - <P>Our <A HREF="../Simple/Client/index.html">simple client</A> - illustrated how to use the traditional CORBA synchronous method - invocation to query a number of stock prices. - Suppose that we had to query hundreds of stock prices, for - example, during the initialization of a complex market analysis - tool. - In that case sending the requests in sequence is going to yield - poor performance; we are not taking advantage of the natural - parallelism in distributed systems, since we are waiting for the - first response to come back before sending the next query. - Traditionally this problem has been attacked using either - <CODE>oneway</CODE> calls or multiple threads. Both approaches can - work, but they have some disadvantages: - multi-threading programming can be hard and error-prone, - oneways are unreliable and require callback interfaces to return - the stock value. - Recently the OMG approved the CORBA Messaging specification - that extends the basic invocation model to include asynchronous - calls. - Unlike the old deferred synchronous model, the new model uses - the IDL compiler and the SII to achieve type safety and improved - performance, but the application does not block waiting for a - response. Instead, it gives the ORB a reference to a reply - handler that will receive the response asynchronously. - The specification also defines a polling interface that we will - not discuss as TAO does not implement it. - </P> - - <P>For this problem we will extend the IDL interface to include a - new operation: - </P> -<PRE> - interface Single_Query_Stock : Stock { - double get_price_and_names (out string symbol, - out string full_name); - }; -</PRE> - <P>This will simplify some of the examples. - </P> - - <P>The first step is to generate the stubs and skeletons with - support for the callback AMI. We do this with the <CODE>-GC</CODE> - flag: - </P> -<PRE> -$ $ACE_ROOT/TAO/TAO_IDL/tao_idl -GC Quoter.idl -</PRE> - <P>You may want to take a brief look at the generated client side - interface. - The IDL compiler adds new methods to the <CODE>Quoter::Stock</CODE> - interface. In particular pay attention to this operation: - </P> -<PRE> - virtual void sendc_get_price_and_names ( - AMI_Single_Query_StockHandler_ptr ami_handler - ) - ACE_THROW_SPEC (( - CORBA::SystemException - )); -</PRE> - <P>This is the operation used to send a request asynchronously. The - response is received in the handler object. This is a regular - CORBA object with the following IDL interface: - </P> -<PRE> -interface AMI_Single_Query_StockHandler { - void get_price_and_names (in double ami_return_val, - in string symbol, - in string full_name); -}; -</PRE> - <P>You don't have to write this IDL interface. The IDL compiler - automatically generates the so-called <EM>implied IDL</EM> - constructs from your original IDL. - Notice how the arguments are generated. The first argument is - simply the return value, then the output arguments show up, but - as <EM>input</EM> only since the handler has to receive the - reply. - </P> - - <H3>Implementing the reply handler</H3> - - <P>We will have to implement a servant for this new IDL interface - so we can receive the reply, - exactly as we do for servers: - </P> -<PRE> -class Single_Query_Stock_Handler_i : public POA_Quoter::AMI_Single_Query_StockHandler -{ -public: - Single_Query_Stock_Handler_i (int *response_count) - : response_count_ (response_count) {} - - void get_price_and_names (CORBA::Double ami_return_val, - const char *symbol, - const char *full_name) - throw (CORBA::SystemException) - { - std::cout << "The price of one stock in \"" - << full_name << "\" (" << symbol << ") is " - << ami_return_val << std::endl; - *this->response_count_++; - } - -private: - int *response_count_; -}; -</PRE> - <P>The <CODE>response_count_</CODE> field will be used to - terminate the client when all the responses are received. - </P> - - <H3>Sending asynchronous method invocations</H3> - - <P>The handler servant is activated as any other CORBA object: - </P> -<PRE> - int response_count = 0; - Single_Query_Stock_Handler_i handler_i (&response_count); - Quoter::AMI_Single_Query_StockHandler_var handler = - handler_i._this (); -</PRE> - <P>and now we change the loop to send all the requests at once: - </P> -<PRE> - int request_count = 0; - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var tmp = - factory->get_stock (argv[i]); - Quoter::Single_Query_Stock_var stock = - Quoter::Single_Query_Stock::_narrow (tmp.in ()); - - stock->sendc_get_price_and_names (handler.in ()); - request_count++; - } -</PRE> - <P>after the loop we wait until all the responses have arrived: - </P> -<PRE> - while (response_count < request_count - && orb->work_pending ()) { - orb->perform_work (); - } -</PRE> - - <H3>Exercise 1</H3> - - <P>Complete the <CODE>client.cpp</CODE> file. Does this client play - the server role too? If not, what is the role with respect to - the handler servant? If you think it is a server too, what - should you do about the POA? - </P> - <P>You can use the following files to complete your implementation: - the <A HREF="Quoter.idl">Quoter.idl</A>, - <A HREF="Handler_i.h">Handler_i.h</A>, - <A HREF="Handler_i.cpp">Handler_i.cpp</A>, - <A HREF="Makefile">Makefile</A>. - Remember that the simple client main program - (located - <A HREF="../Simple/Client/client.cpp">here</A>) - is a good start. - </P> - - <H4>Solution</H4> - <P>Look at - <A HREF="client.cpp">client.cpp</A> file. It should - not be much different from yours. - </P> - - <H3>Testing</H3> - - <P>A simple server is provided, based on the - <A HREF="../Simple/Server/index.html">simple server</A> - from the introduction. - As before, you need the following files: - <A HREF="Stock_i.h">Stock_i.h</A>, - <A HREF="Stock_i.cpp">Stock_i.cpp</A>, - <A HREF="Stock_Factory_i.h">Stock_Factory_i.h</A> - <A HREF="Stock_Factory_i.cpp">Stock_Factory_i.cpp</A> - and <A HREF="server.cpp">server.cpp</A>. - </P> - - <H2>Configuration</H2> - - <P>So far we have used the default configuration in TAO, - but AMI works better with some fine tuning. For example, - by default TAO uses a separate connection for each outstanding - request. With SMI this is a very good strategy, as separate - threads can send concurrent requests without any shared - resources, - but this approach does not scale well with AMI, as it would - create too many connections. - The solution is to change the strategy to share connections. - All we need to do is create a - <A HREF="svc.conf">svc.conf</A> file with the following - contents: - </P> -<PRE> -static Client_Strategy_Factory "-ORBTransportMuxStrategy MUXED" -</PRE> - <P>There are many other configuration options, all of them - documented in - <A HREF="http://ace.cs.wustl.edu/cvsweb/ace-latest.cgi/ACE_wrappers/TAO/docs/Options.html">Options.html</A>, - in - <A HREF="http://ace.cs.wustl.edu/cvsweb/ace-latest.cgi/ACE_wrappers/TAO/docs/configurations.html">configurations.html</A>, - and in the Developer's Guide available from - <A HREF="http://www.theaceorb.com/">OCI</A>. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Thu Mar 29 16:04:44 PST 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/AMI/server.cpp b/TAO/docs/tutorials/Quoter/AMI/server.cpp deleted file mode 100644 index 9d4c01d9a74..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/server.cpp +++ /dev/null @@ -1,46 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i; - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Put the object reference as an IOR string - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - - // Print it out! - cout << ior.in () << endl; - - orb->run (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/AMI/svc.conf b/TAO/docs/tutorials/Quoter/AMI/svc.conf deleted file mode 100644 index 9fb75aeb0dd..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/svc.conf +++ /dev/null @@ -1,4 +0,0 @@ -# -# $Id$ -# -static Client_Strategy_Factory "-ORBTransportMuxStrategy MUXED" diff --git a/TAO/docs/tutorials/Quoter/AMI/svc.conf.xml b/TAO/docs/tutorials/Quoter/AMI/svc.conf.xml deleted file mode 100644 index b8377b00cda..00000000000 --- a/TAO/docs/tutorials/Quoter/AMI/svc.conf.xml +++ /dev/null @@ -1,8 +0,0 @@ -<?xml version='1.0'?> -<!-- Converted from ./docs/tutorials/Quoter/AMI/svc.conf by svcconf-convert.pl --> -<ACE_Svc_Conf> - <!-- --> - <!-- $Id$ --> - <!-- --> - <static id="Client_Strategy_Factory" params="-ORBTransportMuxStrategy MUXED"/> -</ACE_Svc_Conf> diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Consumer_i.h b/TAO/docs/tutorials/Quoter/Event_Service/Consumer_i.h deleted file mode 100644 index 819c4ed0cb5..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Consumer_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIALS_QUOTER_EVENT_SERVICE_CONSUMER_I_H -#define TAO_TUTORIALS_QUOTER_EVENT_SERVICE_CONSUMER_I_H - -#include <orbsvcs/CosEventCommS.h> -#include <orbsvcs/CosEventChanneAdminC.h> - -class Stock_Consumer : public POA_CosEventComm::PushConsumer { -public: - Stock_Consumer (); - - void connect (CosEventChanneAdmin::ConsumerAdmin_ptr consumer_admin); - - void push (const CORBA::Any& data ACE_ENV_ARG_DECL_NOT_USED); - void disconnect_push_consumer (ACE_ENV_SINGLE_ARG_DECL_NOT_USED); - -private: -}; - -#endif /* TAO_TUTORIALS_QUOTER_EVENT_SERVICE_CONSUMER_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Makefile.am b/TAO/docs/tutorials/Quoter/Event_Service/Makefile.am deleted file mode 100644 index 6636df72e21..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Makefile.am +++ /dev/null @@ -1,127 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_IDL = ACE_ROOT=$(ACE_ROOT) TAO_ROOT=$(TAO_ROOT) $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDL_DEP = $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDLFLAGS = -Ge 1 -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -I$(srcdir) -g $(ACE_BUILDDIR)/apps/gperf/src/gperf -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_Event_Service_Idl.am - -BUILT_SOURCES = \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -CLEANFILES = \ - Quoter-stamp \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -QuoterC.cpp QuoterC.h QuoterC.inl QuoterS.cpp QuoterS.h QuoterS.inl: Quoter-stamp - -Quoter-stamp: $(srcdir)/Quoter.idl $(TAO_IDL_DEP) - $(TAO_IDL) $(TAO_IDLFLAGS) $(srcdir)/Quoter.idl - @touch $@ - - -noinst_HEADERS = \ - Quoter.idl - -## Makefile.Quoter_Event_Service_Client.am - -if BUILD_EXCEPTIONS -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -DTAO_HAS_TYPED_EVENT_CHANNEL - -client_SOURCES = \ - QuoterC.cpp \ - Stock_Consumer.cpp \ - client.cpp \ - Stock_Consumer.h - -client_LDADD = \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosEvent_Skel.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosEvent.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif BUILD_EXCEPTIONS - -## Makefile.Quoter_Event_Service_Server.am - -if BUILD_EXCEPTIONS -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -DTAO_HAS_TYPED_EVENT_CHANNEL - -server_SOURCES = \ - QuoterC.cpp \ - QuoterS.cpp \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosEvent_Skel.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosEvent.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Quoter.idl b/TAO/docs/tutorials/Quoter/Event_Service/Quoter.idl deleted file mode 100644 index 34d81177658..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Quoter.idl +++ /dev/null @@ -1,54 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; - - struct Event { - double price; - string symbol; - string full_name; - }; - - interface Modify_Stock : Stock { - void set_price (in double new_price); - }; -}; diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Quoter_Event_Service.mpc b/TAO/docs/tutorials/Quoter/Event_Service/Quoter_Event_Service.mpc deleted file mode 100644 index a98f1720c63..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Quoter_Event_Service.mpc +++ /dev/null @@ -1,33 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*idl) : taoidldefaults, anytypecode { - IDL_Files { - Quoter.idl - } - custom_only = 1 -} - -project(*client) : orbsvcsexe, portableserver, event, event_skel, naming, minimum_corba, exceptions { - after += *idl - source_files { - client.cpp - Stock_Consumer.cpp - QuoterC.cpp - } - IDL_Files { - } -} - -project(*server) : orbsvcsexe, portableserver, event, event_skel, naming, minimum_corba, exceptions { - after += *idl - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.cpp b/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.cpp deleted file mode 100644 index 2e156b24642..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.cpp +++ /dev/null @@ -1,53 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Consumer.h" -#include "QuoterC.h" -#include "ace/streams.h" - -Stock_Consumer::Stock_Consumer () -{ -} - -void -Stock_Consumer::connect (CosEventChannelAdmin::EventChannel_ptr event_channel) -{ - CosEventChannelAdmin::ConsumerAdmin_var consumer_admin = - event_channel->for_consumers (); - - this->supplier_proxy_ = - consumer_admin->obtain_push_supplier (); - - CosEventComm::PushConsumer_var myself = this->_this (); - this->supplier_proxy_->connect_push_consumer (myself.in ()); -} - -void -Stock_Consumer::disconnect () -{ - // Do not receive any more events... - this->supplier_proxy_->disconnect_push_supplier (); -} - -void -Stock_Consumer::push (const CORBA::Any& data - ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - Quoter::Event *event; - if ((data >>= event) == 0) - return; // Invalid event - - cout << "The new price for one stock in \"" - << event->full_name.in () - << "\" (" << event->symbol.in () - << ") is " << event->price << endl; -} - -void -Stock_Consumer::disconnect_push_consumer (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - this->supplier_proxy_ = CosEventChannelAdmin::ProxyPushSupplier::_nil (); -} diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.h b/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.h deleted file mode 100644 index d5de84958cd..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Consumer.h +++ /dev/null @@ -1,31 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIALS_QUOTER_EVENT_SERVICE_STOCK_CONSUMER_H -#define TAO_TUTORIALS_QUOTER_EVENT_SERVICE_STOCK_CONSUMER_H - -#include <orbsvcs/CosEventCommS.h> -#include <orbsvcs/CosEventChannelAdminC.h> - -class Stock_Consumer : public POA_CosEventComm::PushConsumer { -public: - Stock_Consumer (); - - void connect (CosEventChannelAdmin::EventChannel_ptr event_channel); - // Connect to the event channel, using <consumer_admin> - - void disconnect (); - // Disconnect from the event channel. - - void push (const CORBA::Any& data ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - void disconnect_push_consumer (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - -private: - CosEventChannelAdmin::ProxyPushSupplier_var supplier_proxy_; - // The supplier proxy. -}; - -#endif /* TAO_TUTORIALS_QUOTER_EVENT_SERVICE_STOCK_CONSUMER_H */ diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.cpp deleted file mode 100644 index a04c3ab1e3d..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.cpp +++ /dev/null @@ -1,90 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "Stock_i.h" -#include "ace/streams.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - try { - CORBA::Object_var tmp = - this->stock_factory_poa_->id_to_reference (oid.in ()); - return Quoter::Stock::_narrow (tmp.in ()); - } - catch (PortableServer::POA::ObjectNotActive &) { - throw Quoter::Invalid_Stock_Symbol (); - } -} - -void -Quoter_Stock_Factory_i::destroy_stock_objects () -{ - if (!CORBA::is_nil (this->stock_factory_poa_.in ())) - return; - - this->stock_factory_poa_->destroy (1, 1); - this->stock_factory_poa_ = PortableServer::POA::_nil (); -} - -void -Quoter_Stock_Factory_i::load_stock_objects ( - PortableServer::POA_ptr poa, - PortableServer::POAManager_ptr poa_manager, - CosEventChannelAdmin::SupplierAdmin_ptr supplier_admin) -{ - if (!CORBA::is_nil (this->stock_factory_poa_.in ())) - return; - - CORBA::PolicyList policies (2); - policies.length (2); - - policies[0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - policies[1] = - poa->create_implicit_activation_policy (PortableServer::NO_IMPLICIT_ACTIVATION); - - this->stock_factory_poa_ = - poa->create_POA ("Stock_Factory_POA", - poa_manager, - policies); - - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - while (!cin.eof () && cin.peek () != EOF) { - const int max_symbol_length = 8; - char symbol[max_symbol_length]; - const int max_full_name_length = 64; - char full_name[max_full_name_length]; - double price; - - cin.getline (symbol, max_symbol_length, '\n'); - cin.getline (full_name, max_full_name_length, '\n'); - cin >> price; - cin.ignore (1, '\n'); - - Quoter_Stock_i *stock = - new Quoter_Stock_i (symbol, full_name, price); - - PortableServer::ServantBase_var servant = stock; - - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - this->stock_factory_poa_->activate_object_with_id (oid.in (), - servant.in ()); - stock->connect (supplier_admin); - } -} diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.h deleted file mode 100644 index 47ac82f0003..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_Factory_i.h +++ /dev/null @@ -1,27 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_FACTORY_I_H - -#include "QuoterS.h" -#include <orbsvcs/CosEventChannelAdminS.h> - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - void load_stock_objects (PortableServer::POA_ptr poa, - PortableServer::POAManager_ptr poa_manager, - CosEventChannelAdmin::SupplierAdmin_ptr supplier_admin); - void destroy_stock_objects (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - PortableServer::POA_var stock_factory_poa_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_FACTORY_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.cpp deleted file mode 100644 index 37126ff41f2..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.cpp +++ /dev/null @@ -1,66 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : supplier_personality_ (this) -{ - this->data_.symbol = symbol; - this->data_.full_name = full_name; - this->data_.price = price; -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->data_.symbol.in ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->data_.full_name.in ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->data_.price; -} - -void -Quoter_Stock_i::set_price (CORBA::Double new_price) - throw (CORBA::SystemException) -{ - this->data_.price = new_price; - if (CORBA::is_nil (this->consumer_proxy_.in ())) - return; - - CORBA::Any event; - event <<= this->data_; - this->consumer_proxy_->push (event); -} - -void -Quoter_Stock_i::disconnect_push_supplier (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - // Forget about the consumer it is not there anymore - this->consumer_proxy_ = - CosEventChannelAdmin::ProxyPushConsumer::_nil (); -} - -void -Quoter_Stock_i::connect (CosEventChannelAdmin::SupplierAdmin_ptr supplier_admin) -{ - this->consumer_proxy_ = - supplier_admin->obtain_push_consumer (); - CosEventComm::PushSupplier_var supplier = - this->supplier_personality_._this (); - this->consumer_proxy_->connect_push_supplier (supplier.in ()); -} - diff --git a/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.h b/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.h deleted file mode 100644 index b4c619e1a6a..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/Stock_i.h +++ /dev/null @@ -1,38 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_I_H - -#include "QuoterS.h" -#include <orbsvcs/CosEventCommS.h> -#include <orbsvcs/CosEventChannelAdminC.h> - -class Quoter_Stock_i - : public virtual POA_Quoter::Modify_Stock -{ -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - void set_price (CORBA::Double new_price) throw (CORBA::SystemException); - - void disconnect_push_supplier (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - - void connect (CosEventChannelAdmin::SupplierAdmin_ptr supplier_admin); - -private: - Quoter::Event data_; - - CosEventChannelAdmin::ProxyPushConsumer_var consumer_proxy_; - - POA_CosEventComm::PushSupplier_tie<Quoter_Stock_i> supplier_personality_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_EVENT_SERVICE_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Event_Service/client.cpp b/TAO/docs/tutorials/Quoter/Event_Service/client.cpp deleted file mode 100644 index 43abc2992c9..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/client.cpp +++ /dev/null @@ -1,54 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Consumer.h" -#include <orbsvcs/CosNamingC.h> -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("CosEventService"); - - CORBA::Object_var ec_object = - naming_context->resolve (name); - - // Now downcast the object reference to the appropriate type - CosEventChannelAdmin::EventChannel_var ec = - CosEventChannelAdmin::EventChannel::_narrow (ec_object.in ()); - - Stock_Consumer stock_consumer_i; - stock_consumer_i.connect (ec.in ()); - - orb->run (); - - stock_consumer_i.disconnect (); - - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Event_Service/ec.conf b/TAO/docs/tutorials/Quoter/Event_Service/ec.conf deleted file mode 100644 index 395b9a6c724..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/ec.conf +++ /dev/null @@ -1,3 +0,0 @@ -# $Id$ -# static EC_Factory "-ECfiltering null" -# -ECproxyconsumerlock thread " #-ECproxysupplierlock thread" # -ECsupplierfiltering per-supplier" diff --git a/TAO/docs/tutorials/Quoter/Event_Service/ec.conf.xml b/TAO/docs/tutorials/Quoter/Event_Service/ec.conf.xml deleted file mode 100644 index f6fed99198b..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/ec.conf.xml +++ /dev/null @@ -1,7 +0,0 @@ -<?xml version='1.0'?> -<!-- Converted from ./docs/tutorials/Quoter/Event_Service/ec.conf by svcconf-convert.pl --> -<ACE_Svc_Conf> - <!-- $Id$ --> - <!-- static EC_Factory "-ECfiltering null" --> - <!-- -ECproxyconsumerlock thread " #-ECproxysupplierlock thread" # -ECsupplierfiltering per-supplier" --> -</ACE_Svc_Conf> diff --git a/TAO/docs/tutorials/Quoter/Event_Service/index.html b/TAO/docs/tutorials/Quoter/Event_Service/index.html deleted file mode 100644 index 8b60f5ec91c..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/index.html +++ /dev/null @@ -1,408 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>TAO's COS Event Service</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>TAO's COS Event Service</h3> - - <P>To poll the values of stocks constantly just to - check if they have changed is not an efficient or scalable - solution. - We want to be informed when the price changes so we can take - appropriate action. - We could devise our own call back mechanism, but this kind of - task is easier to achieve using the CORBA Event Service. - </P> - - <H3>Defining the Event Type</H3> - - <P>We need to define an IDL <CODE>struct</CODE> that will carry - our event data. - Of course we want to include the stock price, its symbol and - maybe its full name in the event: - </P> -<PRE> - struct Event { - double price; - string symbol; - string full_name; - }; -</PRE> - <P>We also extend the <CODE>Stock</CODE> interface so we can - modify the value: - </P> -<PRE> - interface Modify_Stock : Stock { - void set_price (in double new_price); - }; -</PRE> - - <H3>Getting the Price Changes</H3> - - <H3>Connecting as a consumer</H3> - - <P>Connecting as a consumer is a similar process, but we will use - the more traditional inheritance based approach instead of TIE. - First let us define the consumer object: - </P> -<PRE> -class Stock_Consumer : public POA_CosEventComm::PushConsumer { -public: - Stock_Consumer (); - - void push (const CORBA::Any& data TAO_ENV_ARG_DECL); - void disconnect_push_consumer (TAO_ENV_SINGLE_ARG_DECL); - - // details omitted -}; -</PRE> - <P>Let us ignore the strange <CODE>TAO_ENV_ARG_DECL</CODE> - arguments and concentrate on the implementation. - The <CODE>disconnect_push_consumer()</CODE> method is invoked by - the Events Service when it is disconnecting, - for example, because it was shut down before the Consumer got a - chance to disconnect itself. - The <CODE>push()</CODE> method is invoked by the Events Service - whenever some event is sent by a supplier. - Let's take a look at this method. - First we need to extract the event data from the any: - </P> -<PRE> -void -Stock_Consumer::push (const CORBA::Any& data - TAO_ENV_ARG_DECL_NOT_USED) -{ - Quoter::Event *event; - if ((data >>= event) == 0) - return; // Invalid event -</PRE> - <P>Notice that the extraction can fail: anys can store all IDL - data types, and only at extraction time are the types checked. - Also notice that we use a pointer to the event; - the CORBA rules are that variable sized structures, - i.e., structures that contain elements of variable size, - such as strings, - are extracted by reference. - We do <STRONG>not</STRONG> need to manage this memory, - the ORB will destroy it for us. - Now we can print out the new stock price: - </P> -<PRE> - std::cout << "The new price for one stock in \"" - << event->full_name.in () - << "\" (" << event->symbol.in () - << ") is " << event->price << std::endl; -} -</PRE> - - <P>So what was the <CODE>TAO_ENV_ARG_DECL</CODE> about? After - all it was not used. TAO services must support platforms - without support for native C++ exceptions. On those platforms - the CORBA specification defines an <EM>alternate mapping</EM> - where all the operations use an extra argument to return any - exceptions. - Notice that the TAO IDL compiler supports both mappings. We have - been using the standard one so far! It is only if your C++ - compiler does not support exceptions that you need to use - the alternative mapping. - </P> - <P>Notice that on platforms with native C++ exception support we - can safely ignore the extra argument, - and use the usual mechanisms to catch and throw exceptions. - For more information on how to use the alternative mapping and - how to write portable code for both environments check - <A HREF="../../../../../docs/exceptions.html">Using - ACE try macros for CORBA programming</A>. - </P> - - <P>Going back to our example, - when the event channel disconnects we receive a callback, too. - At that point we want to forget about the original connection: - </P> -<PRE> -void -Stock_Consumer::disconnect_push_consumer (TAO_ENV_SINGLE_ARG_DECL_NOT_USED) -{ - this->supplier_proxy_ = CosEventChannelAdmin::ProxyPushSupplier::_nil (); -} -</PRE> - <P>But why do we need to have a connection to the event channel in - the first place? All we want is to receive events. The - connection to the event channel will let you disconnect - gracefully, so the event channel does not have to maintain - resources for old consumers. - For example, - we could implement a method such as: - </P> -<PRE> -void -Stock_Consumer::disconnect () -{ - // Do not receive any more events... - this->supplier_proxy_->disconnect_push_supplier (); -} -</PRE> - - <H4>How to connect to the event channel</H4> - - <P>Connecting to the event channel is a 3 step process. - First we obtain a factory used by all the consumers that want to - connect. - Next we obtain a supplier proxy, so we can report when - we do not want any more events. - Finally we connect to the proxy to start receiving events. - </P> - <P>We will assume that we are using the naming service or - something similar to obtain a reference to the event service: - </P> -<PRE> - CORBA::Object_var tmp = naming_context->resolve (name); - CosEventChannelAdmin::EventChannel_var event_channel = - CosEventChannelAdmin::EventChannel::_narrow (tmp); -</PRE> - <P>Now we use the event channel to obtain the factory used for - consumer connections: - </P> -<PRE> - CosEventChannelAdmin::ConsumerAdmin_var consumer_admin = - event_channel->for_consumers (); -</PRE> - <P>And use the factory to obtain a proxy: - </P> -<PRE> -void -Stock_Consumer::connect (CosEventChannelAdmin::ConsumerAdmin_ptr consumer_admin) -{ - this->supplier_proxy_ = - consumer_admin->obtain_push_supplier (); -</PRE> - <P>And finally we connect: - </P> -<PRE> - CosEventComm::PushConsumer_var myself = this->_this (); - this->supplier_proxy_->connect_push_consumer (myself.in ()); -} -</PRE> - - <H3>Notifying the Price Changes</H3> - - <P>We will now examine how the suppliers generate events. - Let us look at an implementation of the - <CODE>Modify_Stock</CODE> interface: - </P> -<PRE> -class Quoter_Modify_Stock_i : public POA_Quoter::Modify_Stock { -public: - Quoter_Modify_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - void set_price (CORBA::Double new_price) - throw (CORBA::SystemException); - -private: - Quoter::Event data_; - - CosEventChannelAdmin::ProxyPushConsumer_var consumer_proxy_; -}; -</PRE> - <P>Notice how we use the IDL structure to maintain the data. This - is just to make the code a little shorter. - The <CODE>consumer_proxy_</CODE> object is just like - the <CODE>supplier_proxy_</CODE> discussed above, - except that we also use it to send the events. - The start of the <CODE>set_price()</CODE> method will look like - this: - </P> -<PRE> -void -Quoter_Stock_i::set_price (CORBA::Double new_price) - throw (CORBA::SystemException) -{ - this->data_.price = new_price; -</PRE> - <P>Next we prepare the event. The COS Events Service uses a CORBA - any to send all the data, like this: - </P> -<PRE> - CORBA::Any event; - event <<= this->data_; -</PRE> - <P>Finally we send the event to the consumer: - </P> -<PRE> - this->consumer_proxy_->push (event); -} -</PRE> - - <H3>Connecting to the Event Service as a Supplier</H3> - - <P>Sending the event was easy. Connecting to the Event Channel - as a supplier is very similar to the connection as a consumer. - We will need a <CODE>CosEventComm::PushSupplier</CODE> object. - This is a good application of the TIE objects: - </P> -<PRE> -class Quoter_Stock_i : public POA_Quoter::Modify_Stock { -public: - // some details removed... - - void disconnect_push_supplier (TAO_ENV_SINGLE_ARG_DECL_NOT_USED); - -private: - POA_CosEventComm::PushSupplier_tie < Quoter_Stock_i > supplier_personality_; -}; -</PRE> - <P>The <CODE>PushSupplier_tie</CODE> is a template generated by - the IDL compiler. It implements the - <CODE>CosEventComm::PushSupplier</CODE> interface, - but it actually just forwards all the calls to its single - template argument. - For example, in this case the - <CODE>disconnect_push_supplier</CODE> call is implemented as: - </P> -<PRE> -template<class T> void -POA_CosEventComm::PushSupplier_tie < T >::disconnect_push_supplier () -{ - this->ptr_->disconnect_push_supplier (); -} -</PRE> - <P>The <CODE>ptr_</CODE> field is actually a pointer to the - template argument, - so we don't have to implement a separate class just to receive a - disconnect callback, we can use the same - <CODE>Modify_Stock_i</CODE> class to do it. - </P> - - <P>Going back to the connection code, first we gain access to the - Event Service, for example using the naming service: - </P> -<PRE> - CORBA::Object_var tmp = naming_context->resolve (name); - CosEventChannelAdmin::EventChannel_var event_channel = - CosEventChannelAdmin::EventChannel::_narrow (tmp); -</PRE> - <P>Now we use the event channel to obtain the factory used for - supplier connections: - </P> -<PRE> - CosEventChannelAdmin::SupplierAdmin_var supplier_admin = - event_channel->for_suppliers (); -</PRE> - <P>And use the factory to obtain a proxy: - </P> -<PRE> - this->consumer_proxy_ = - supplier_admin->obtain_push_consumer (); -</PRE> - <P>And finally we use our supplier personality to connect to the - consumer proxy: - </P> -<PRE> - CosEventComm::PushSupplier_var supplier = - this->supplier_personality_._this (); - this->consumer_proxy_->connect_push_supplier (supplier); -</PRE> - - <P>Finally we implement the disconnect callback: - </P> -<PRE> -void -Quoter_Stock_i::disconnect_push_supplier (TAO_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - // Forget about the consumer. It is not there anymore - this->consumer_proxy_ = - CosEventChannelAdmin::ProxyPushConsumer::_nil (); -} -</PRE> - - <H3>Exercise 1</H3> - - <P>Implement a consumer that receives the price update events. - </P> - <P>The - <A HREF="Stock_Consumer.h">header file</A> - is already provided, - along with a sample - <A HREF="client.cpp">client.cpp</A>. - And other support files - <A HREF="Quoter.idl">Quoter.idl</A>, - <A HREF="GNUMakefile">Makefile</A>, - <A HREF="Stock_i.h">Stock_i.h</A>, - <A HREF="Stock_i.cpp">Stock_i.cpp</A>, - <A HREF="Stock_Factory_i.h">Stock_Factory_i.h</A>, - <A HREF="Stock_Factory_i.cpp">Stock_Factory_i.cpp</A>, - and <A HREF="server.cpp">server.cpp</A>. - </P> - - <H4>Solution</H4> - - <P>Compare your solution with - <A HREF="Stock_Consumer.cpp">Stock_Consumer.cpp</A>. - </P> - - <H4>Testing</H4> - - <P>To test your changes you need to run four programs, - first TAO's Naming Service: -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -m 1 -</PRE> - <P>The CORBA Event Service - </P> -<PRE> -$ $TAO_ROOT/orbsvcs/CosEvent_Service/CosEvent_Service -</PRE> - - <P>Now you can run your client: -<PRE> -$ client -</PRE> - <P>and finally the server: - </P> -<PRE> -$ server AAAA MSFT RHAT < stock_list.txt -</PRE> - <P>Here is the - <A HREF="stock_list.txt">stock_list.txt file</A>. - </P> - - <H3>Exercise 2</H3> - - <P>Run the same configuration as above, - but this time run multiple clients and servers: - </P> -<PRE> -$ client -$ client -$ server AAAA BBBB < stock_list1.txt -$ server ZZZZ YYYY < stock_list2.txt -</PRE> - <P>Do the clients receive all the events from both servers? What - if you don't want to receive all the events, for example, - because you are only interested in certain stocks? - </P> - <P>Here are the - <A HREF="stock_list.txt">stock_list1.txt</A> - and - <A HREF="stock_list.txt">stock_list2.txt</A> - files. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 13:59:59 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Event_Service/server.cpp b/TAO/docs/tutorials/Quoter/Event_Service/server.cpp deleted file mode 100644 index 56b0532a42c..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/server.cpp +++ /dev/null @@ -1,104 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "orbsvcs/CosNamingC.h" -#include "ace/streams.h" -#include "ace/OS_NS_unistd.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i; - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Get the Naming Context reference - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - // Create and initialize the name. - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("Stock_Factory"); - - // Bind the object - naming_context->rebind (name, stock_factory.in ()); - - // Resolve the Event Service - name[0].id = CORBA::string_dup ("CosEventService"); - - CORBA::Object_var ec_object = - naming_context->resolve (name); - - // Now downcast the object reference to the appropriate type - CosEventChannelAdmin::EventChannel_var ec = - CosEventChannelAdmin::EventChannel::_narrow (ec_object.in ()); - - CosEventChannelAdmin::SupplierAdmin_var supplier_admin = - ec->for_suppliers (); - - stock_factory_i.load_stock_objects (poa.in (), - poa_manager.in (), - supplier_admin.in ()); - - // **************************************************************** - - for (int j = 0; j != 1000; ++j) { - for (int i = 1; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - stock_factory->get_stock (argv[i]); - - CORBA::String_var full_name = stock->full_name (); - - // Get the price - CORBA::Double price = stock->price (); - - Quoter::Modify_Stock_var modify_stock = - Quoter::Modify_Stock::_narrow (stock.in ()); - modify_stock->set_price (price + 1); - - cout << "Set the price of " - << full_name.in () - << " to " << price + 1 << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - ACE_Time_Value tv (0, 500000); - ACE_OS::sleep (tv); - } - } - - stock_factory_i.destroy_stock_objects (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Event_Service/stock_list.txt b/TAO/docs/tutorials/Quoter/Event_Service/stock_list.txt deleted file mode 100644 index d30a0c0255a..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/stock_list.txt +++ /dev/null @@ -1,84 +0,0 @@ -MSFT -Microsoft Inc. -91 -RHAT -RedHat Inc. -210 -AAAA -The AAAA Company -100 -BBBB -The BBBB Company -101 -CCCC -The CCCC Company -102 -DDDD -The DDDD Company -103 -EEEE -The EEEE Company -104 -FFFF -The FFFF Company -105 -GGGG -The GGGG Company -106 -HHHH -The HHHH Company -107 -IIII -The IIII Company -108 -JJJJ -The JJJJ Company -109 -KKKK -The KKKK Company -110 -LLLL -The LLLL Company -111 -MMMM -The MMMM Company -112 -NNNN -The NNNN Company -113 -OOOO -The OOOO Company -114 -PPPP -The PPPP Company -115 -QQQQ -The QQQQ Company -116 -RRRR -The RRRR Company -117 -SSSS -The SSSS Company -118 -TTTT -The TTTT Company -119 -UUUU -The UUUU Company -120 -VVVV -The VVVV Company -121 -WWWW -The WWWW Company -122 -XXXX -The XXXX Company -123 -YYYY -The YYYY Company -124 -ZZZZ -The ZZZZ Company -125 diff --git a/TAO/docs/tutorials/Quoter/Event_Service/stock_list1.txt b/TAO/docs/tutorials/Quoter/Event_Service/stock_list1.txt deleted file mode 100644 index 183bd57af64..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/stock_list1.txt +++ /dev/null @@ -1,48 +0,0 @@ -RHAT -RedHat Inc. -210 -AAAA -The AAAA Company -100 -BBBB -The BBBB Company -101 -CCCC -The CCCC Company -102 -DDDD -The DDDD Company -103 -EEEE -The EEEE Company -104 -FFFF -The FFFF Company -105 -GGGG -The GGGG Company -106 -HHHH -The HHHH Company -107 -IIII -The IIII Company -108 -JJJJ -The JJJJ Company -109 -KKKK -The KKKK Company -110 -LLLL -The LLLL Company -111 -MMMM -The MMMM Company -112 -NNNN -The NNNN Company -113 -OOOO -The OOOO Company -114 diff --git a/TAO/docs/tutorials/Quoter/Event_Service/stock_list2.txt b/TAO/docs/tutorials/Quoter/Event_Service/stock_list2.txt deleted file mode 100644 index 2592fdbc073..00000000000 --- a/TAO/docs/tutorials/Quoter/Event_Service/stock_list2.txt +++ /dev/null @@ -1,36 +0,0 @@ -MSFT -Microsoft Inc. -91 -PPPP -The PPPP Company -115 -QQQQ -The QQQQ Company -116 -RRRR -The RRRR Company -117 -SSSS -The SSSS Company -118 -TTTT -The TTTT Company -119 -UUUU -The UUUU Company -120 -VVVV -The VVVV Company -121 -WWWW -The WWWW Company -122 -XXXX -The XXXX Company -123 -YYYY -The YYYY Company -124 -ZZZZ -The ZZZZ Company -125 diff --git a/TAO/docs/tutorials/Quoter/Makefile.am b/TAO/docs/tutorials/Quoter/Makefile.am deleted file mode 100644 index 9a0053b5806..00000000000 --- a/TAO/docs/tutorials/Quoter/Makefile.am +++ /dev/null @@ -1,19 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -SUBDIRS = \ - AMI \ - Event_Service \ - On_Demand_Activation \ - RT_Event_Service \ - idl \ - Simple \ - Naming_Service - diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Makefile.am b/TAO/docs/tutorials/Quoter/Naming_Service/Makefile.am deleted file mode 100644 index fd4e2356bae..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Makefile.am +++ /dev/null @@ -1,88 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_Naming_Service_Client.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -I$(srcdir)/../idl \ - -I../idl - -client_SOURCES = \ - client.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -client_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Makefile.Quoter_Naming_Service_Server.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -I$(srcdir)/../idl \ - -I../idl - -server_SOURCES = \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Quoter_Naming_Service.mpc b/TAO/docs/tutorials/Quoter/Naming_Service/Quoter_Naming_Service.mpc deleted file mode 100644 index 797e2569292..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Quoter_Naming_Service.mpc +++ /dev/null @@ -1,32 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*client) : orbsvcsexe, portableserver, naming, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../idl - } - includes += ../idl - - source_files { - client.cpp - } -} - -project(*server) : orbsvcsexe, portableserver, naming, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../idl - } - includes += ../idl - - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - } -} diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.cpp deleted file mode 100644 index a2323a6be36..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.cpp +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () - : rhat_ ("RHAT", "RedHat, Inc.", 210), - msft_ ("MSFT", "Microsoft, Inc.", 91) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this (); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.h deleted file mode 100644 index c0e51d1b3ea..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_Factory_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.cpp deleted file mode 100644 index 6149cb79c36..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.cpp +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.h b/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.h deleted file mode 100644 index 9c9607415a2..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/Stock_i.h +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/client.cpp b/TAO/docs/tutorials/Quoter/Naming_Service/client.cpp deleted file mode 100644 index c26cf41b26c..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/client.cpp +++ /dev/null @@ -1,73 +0,0 @@ -// -// $Id$ -// - -#include "QuoterC.h" -#include <orbsvcs/CosNamingC.h> -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 2) { - cerr << "Usage: " << argv[0] - << "symbol symbol..." << endl; - return 1; - } - - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("Stock_Factory"); - - CORBA::Object_var factory_object = - naming_context->resolve (name); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Now get the full name and price of the other arguments: - for (int i = 1; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - factory->get_stock (argv[i]); - - // Get its name, put it on a _var so it is automatically - // released! - CORBA::String_var full_name = stock->full_name (); - - // Now get the price - CORBA::Double price = stock->price (); - - cout << "The price of a stock in \"" - << full_name.in () << "\" is $" - << price << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - // Finally destroy the ORB - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/index.html b/TAO/docs/tutorials/Quoter/Naming_Service/index.html deleted file mode 100644 index 345ba22be93..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/index.html +++ /dev/null @@ -1,260 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>TAO's Naming Service</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>TAO's Naming Service</h3> - - <P>So far we have used <CODE>string_to_object()</CODE> and - <CODE>object_to_string()</CODE> to bootstrap the client. - If the system is going to be used in a truly distributed - environment, we cannot count on having a shared file system or on - the user to type the IOR to initialize the client. - CORBA has several location services that can be used for that - purpose. The simplest of them is the CORBA Naming Service. - There are many good tutorials on how to use the Naming Service, - and Henning and Vinoski discuss the issue in detail in their - book. - </P> - <P>In this section we will cover very simple uses of the Naming - Service, but we will concentrate on how to configure and - bootstrap the Naming Service itself! Including TAO's support for - the Interoperable Naming Service. - </P> - - <H3>Registering an Object in the Naming Service</H3> - - <P>First we modify the server to register the stock factory with - the naming service. - We need to include the right header: - </P> -<PRE> -#include "orbsvcs/CosNamingC.h" -</PRE> - <P>We recall that we activate the stock factory using: - </P> -<PRE> - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); -</PRE> - <P>We need to obtain a reference to the Naming Service; this is - done using the <CODE>resolve_initial_references()</CODE> call: - </P> -<PRE> - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); -</PRE> - <P>Next we initialize the name that we will assign to the objects. - The naming service uses a sequence of structures for the name -- - think of it as a pathname decomposed into its directories. - In this case we will use a simple name. - In production environments some better organized hierarchy may - be imposed. - First create and initialize the sequence: - </P> -<PRE> - CosNaming::Name name (1); - name.length (1); -</PRE> - <P>Now we initialize the name: - </P> -<PRE> - name[0].id = CORBA::string_dup ("Stock_Factory"); -</PRE> - <P>Now we are ready to register the object reference in the naming - service: - </P> -<PRE> - naming_context->bind (name, stock_factory.in ()); -</PRE> - <P>Notice that <CODE>bind()</CODE> fails if the name is already in - the naming service. You may want to use <CODE>rebind()</CODE> to - override any values already there. - </P> - - <H3>Looking up the Object</H3> - - <P>Now the client can use the Naming Service to locate the object. - Instead of relying on the command line, - we have to perform the same calls to locate the naming service - and initialize the name of the object we want to look up: - </P> -<PRE> - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("Stock_Factory"); -</PRE> - <P>Now we can resolve the name:</P> -<PRE> - CORBA::Object_var factory_object = - naming_context->resolve (name); - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); -</PRE> - <P>And then we can use the object as before. - </P> - - <H3>Exercise 1</H3> - - <P>Complete the changes to the <CODE>server.cpp</CODE> file. - </P> - <P>You can use the following files to complete and test your - implementation: - <A HREF="../Simple/Quoter.idl">Quoter.idl</A>, - <A HREF="Makefile">Makefile</A>, - <A HREF="../Simple/Server/Stock_i.h">Stock_i.h</A>, - <A HREF="../Simple/Server/Stock_i.cpp">Stock_i.cpp</A>, - <A HREF="../Simple/Server/Stock_Factory_i.h">Stock_Factory_i.h</A> - <A HREF="../Simple/Server/Stock_Factory_i.cpp">Stock_Factory_i.cpp</A>. - - For more fun you can modify the original - <A HREF="../Simple/Client/client.cpp">client.cpp</A> file, too. - What about the first argument? Do we need the IOR now? - </P> - - <H4>Solution</H4> - - <P>Compare your solution with - <A HREF="client.cpp">client.cpp</A> - and <A HREF="server.cpp">server.cpp</A>. They should be very similar. - </P> - - <H4>Testing</H4> - - <P>To test your changes you need to run four programs. First - configure TAO's naming service lookup protocol to use a - unique port in your LAN. - Something based on your user id is a good idea, - for example: - </P> -<PRE> -$ setenv NameServicePort `expr 10000 + $uid` -</PRE> - <P>Now we can start the Naming Service provided with TAO: - </P> -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -</PRE> - <P>and your server: - </P> -<PRE> -$ server -</PRE> - <P>and finally the client: - </P> -<PRE> -$ client MSFT RHAT RHAT MSFT -</PRE> - - <H2>Finding the Naming Service</H2> - - <P>So how does TAO find the naming service? Until recently there - was no standard way to configure how the Naming Service was - bootstrapped. In TAO we decided to use IP multicast to locate - the server. The multicast protocol is very simple minded, but - works well in small LANs where there are not many naming - services running. - To avoid problems when multiple naming services run in the same - LAN, you must assign a different multicast port to each one, - as shown above. - </P> - <P>Unfortunately the protocol shown above does not work across - multiple LANs, and it is hard to ensure that there are no - conflicts in the assignment of multicast ports. - TAO supports the Interoperable Naming Service specification - that provides several mechanisms to control the behavior of the - <CODE>resolve_initial_references()</CODE> call. - For example, you can ask the Naming Service to dump its IOR to a - file, as in: - </P> -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -o ns.ior -</PRE> - <P>and then use the <CODE>-ORBInitRef</CODE> to that IOR - instead of the multicast protocol: - </P> -<PRE> -$ server -ORBInitRef NameService=`cat ns.ior` -</PRE> - <P>or even better use the <CODE>file:</CODE> scheme to read the - file directly: - </P> -<PRE> -$ server -ORBInitRef NameService=file://ns.ior -</PRE> - <P>but this still assumes that there is a shared filesystem - between the hosts, or that the user will copy the file across - the network. If we know what host and port the Naming Service - is using to accept IIOP requests, then we can use the - <CODE>corbaloc:</CODE> scheme: - </P> -<PRE> -$ server -ORBInitRef NameService=corbaloc:iiop:ace.cs.wustl.edu:12345/NameService -</PRE> - <P>In fact, controlling the host and port of any TAO program, - including the Naming Service, is easy. Just use the - <CODE>-ORBEndPoint</CODE> option: - </P> -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -ORBEndPoint iiop://ace.cs.wustl.edu:12345 -</PRE> - <P>Of course, this only works if you are running the program in - <CODE>ace.cs.wustl.edu</CODE> and the <CODE>12345</CODE> port is - free. You can use the magic port number <CODE>0</CODE> to let - the ORB find a free port. In fact, that is exactly what TAO does - by default. - Finally, you can use multiple <CODE>-ORBEndPoint</CODE> options - to listen on multiple endpoints. This is very useful for - multi-hosted machines. - </P> - - <H3>Exercise 2</H3> - - <P>Try using different approaches to find the Naming Service. Also - try to run the server with an invalid IOR for the naming - service. What happens if the server and client pick different - naming services through their multicast protocol? What happens - if they are not configured consistently with respect to their - Naming Service? - </P> - - <H3>Persistence</H3> - - <P>What happens if the naming service is killed between the object - registration and the lookup? By default TAO's Naming Service is - <STRONG>not</STRONG> persistent, but it is a matter of using a - flag to save its state on a file: -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -f name_service.dat -</PRE> - </P> - - <P>Notice that this is little use unless your services are - persistent too, or can be automatically restarted. That is the - role of the - <A HREF="http://ace.cs.wustl.edu/cvsweb/ace-latest.cgi/ACE_wrappers/TAO/docs/implrepo/index.html">Implementation Repository</A>. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 14:09:33 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Naming_Service/server.cpp b/TAO/docs/tutorials/Quoter/Naming_Service/server.cpp deleted file mode 100644 index 86d293611bc..00000000000 --- a/TAO/docs/tutorials/Quoter/Naming_Service/server.cpp +++ /dev/null @@ -1,55 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "orbsvcs/CosNamingC.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i; - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Get the Naming Context reference - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - // Create and initialize the name. - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("Stock_Factory"); - - // Bind the object - naming_context->bind (name, stock_factory.in ()); - - orb->run (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.cpp deleted file mode 100644 index 1167c78c3e0..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.cpp +++ /dev/null @@ -1,82 +0,0 @@ -// -// $Id$ -// - -#include "Handler_i.h" -#include "ace/streams.h" - -Single_Query_Stock_Handler_i:: - Single_Query_Stock_Handler_i (int *response_count) - : response_count_ (response_count) -{ -} - -void -Single_Query_Stock_Handler_i::get_price_and_names (CORBA::Double ami_return_val, - const char *symbol, - const char *full_name) - throw (CORBA::SystemException) -{ - cout << "The price of one stock in \"" - << full_name << "\" (" << symbol << ") is " - << ami_return_val << endl; - (*this->response_count_)++; -} - -void -Single_Query_Stock_Handler_i:: - get_price_and_names_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - // We ignore the exception, but this counts as a reponse, otherwise - // the application would not finish. - cerr << "Exception raised while querying stock price" - << endl; - (*this->response_count_)++; -} - - -void -Single_Query_Stock_Handler_i::get_symbol (const char *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - get_symbol_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i::get_full_name (const char *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - get_full_name_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i::price (double) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} - -void -Single_Query_Stock_Handler_i:: - price_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException) -{ - throw CORBA::NO_IMPLEMENT (); -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.h b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.h deleted file mode 100644 index b595d53be86..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Handler_i.h +++ /dev/null @@ -1,43 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIALS_QUOTER_ONDEMAND_CLIENT_HANDLER_I_H -#define TAO_TUTORIALS_QUOTER_ONDEMAND_CLIENT_HANDLER_I_H - -#include "QuoterS.h" - -class Single_Query_Stock_Handler_i : public POA_Quoter::AMI_Single_Query_StockHandler -{ -public: - Single_Query_Stock_Handler_i (int *response_count); - - void get_price_and_names (CORBA::Double ami_return_val, - const char *symbol, - const char *full_name) - throw (CORBA::SystemException); - - void get_price_and_names_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void get_symbol(const char *) - throw (CORBA::SystemException); - void get_symbol_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void get_full_name (const char *) - throw (CORBA::SystemException); - void get_full_name_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - - void price (double) - throw (CORBA::SystemException); - void price_excep (::Messaging::ExceptionHolder *) - throw (CORBA::SystemException); - -private: - - int *response_count_; -}; - -#endif /* TAO_TUTORIALS_QUOTER_AMI_CLIENT_HANDLER_I_H */ diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Makefile.am b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Makefile.am deleted file mode 100644 index 29035de8f99..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Makefile.am +++ /dev/null @@ -1,146 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_IDL = ACE_ROOT=$(ACE_ROOT) TAO_ROOT=$(TAO_ROOT) $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDL_DEP = $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDLFLAGS = -Ge 1 -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -I$(srcdir) -g $(ACE_BUILDDIR)/apps/gperf/src/gperf -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_On_Demand_Activation_Idl.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING - -BUILT_SOURCES = \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -CLEANFILES = \ - Quoter-stamp \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -QuoterC.cpp QuoterC.h QuoterC.inl QuoterS.cpp QuoterS.h QuoterS.inl: Quoter-stamp - -Quoter-stamp: $(srcdir)/Quoter.idl $(TAO_IDL_DEP) - $(TAO_IDL) $(TAO_IDLFLAGS) -GC $(srcdir)/Quoter.idl - @touch $@ - - -noinst_HEADERS = \ - Quoter.idl - -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Makefile.Quoter_On_Demand_Activation_Client.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs - -client_SOURCES = \ - Handler_i.cpp \ - QuoterC.cpp \ - QuoterS.cpp \ - client.cpp \ - Handler_i.h - -client_LDADD = \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Makefile.Quoter_On_Demand_Activation_Server.am - -if BUILD_AMI -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs - -server_SOURCES = \ - QuoterC.cpp \ - QuoterS.cpp \ - Stock_Factory_Locator_i.cpp \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_Locator_i.h \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING -endif BUILD_AMI - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter.idl b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter.idl deleted file mode 100644 index 80cfa1661d1..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter.idl +++ /dev/null @@ -1,49 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; - - interface Single_Query_Stock : Stock { - double get_price_and_names (out string symbol, - out string full_name); - }; -}; diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter_On_Demand_Activation.mpc b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter_On_Demand_Activation.mpc deleted file mode 100644 index 650bdc9d832..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Quoter_On_Demand_Activation.mpc +++ /dev/null @@ -1,35 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*idl): taoidldefaults, ami { - IDL_Files { - Quoter.idl - } - custom_only = 1 -} - -project(*client) : taoexe, portableserver, naming, ami, minimum_corba, exceptions { - after += *idl - source_files { - client.cpp - Handler_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} - -project(*server) : taoserver, naming, ami, minimum_corba, exceptions { - after += *idl - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - Stock_Factory_Locator_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.cpp deleted file mode 100644 index ab075fcfcf7..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.cpp +++ /dev/null @@ -1,61 +0,0 @@ -// $Id$ - -#include "Stock_Factory_Locator_i.h" -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_Locator_i:: -Quoter_Stock_Factory_Locator_i (CORBA::ORB_ptr orb) - : orb_ (CORBA::ORB::_duplicate (orb)) -{ -} - -PortableServer::Servant -Quoter_Stock_Factory_Locator_i::preinvoke (const PortableServer::ObjectId &oid, - PortableServer::POA_ptr, - const char *, - void * & cookie - ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException, PortableServer::ForwardRequest) -{ - - // Check to see if the object ID is valid - try { - - // Get the ObjectID in string format - CORBA::String_var oid_str = - PortableServer::ObjectId_to_string (oid); - - // Check if the ObjectId is valid - if (strcmp (oid_str.in (), "Quoter/Stock_Factory") != 0) { - // Create the required servant - PortableServer::Servant servant = - new Quoter_Stock_Factory_i (); - cookie = servant; - - return servant; - } - else { - throw CORBA::OBJECT_NOT_EXIST (); - } - - } catch (const CORBA::BAD_PARAM &) { - throw CORBA::OBJECT_NOT_EXIST (); - } -} - -void -Quoter_Stock_Factory_Locator_i::postinvoke (const PortableServer::ObjectId &, - PortableServer::POA_ptr, - const char *, - void * cookie, - PortableServer::Servant servant - ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - - // Delete the servant as it is no longer needed. - PortableServer::Servant my_servant = (PortableServer::Servant) cookie; - if (servant == my_servant) - delete servant; - -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.h b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.h deleted file mode 100644 index 4f3a9666ba2..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_Locator_i.h +++ /dev/null @@ -1,39 +0,0 @@ -// -// $Id$ -// - -#ifndef STOCK_FACTORY_LOCATOR_I_H -#define STOCK_FACTORY_LOCATOR_I_H - -#include "tao/ORB.h" -#include "tao/PortableServer/PortableServer.h" -#include "tao/PortableServer/ServantLocatorC.h" - -class Quoter_Stock_Factory_Locator_i : public PortableServer::ServantLocator -{ - public: - Quoter_Stock_Factory_Locator_i (CORBA::ORB_ptr orb); - - // Preinvoke function - virtual PortableServer::Servant preinvoke (const PortableServer::ObjectId &oid, - PortableServer::POA_ptr poa, - const char * operation, - void * & cookie - ACE_ENV_ARG_DECL_WITH_DEFAULTS) - throw (CORBA::SystemException, PortableServer::ForwardRequest); - - // Postinvoke function - virtual void postinvoke (const PortableServer::ObjectId & oid, - PortableServer::POA_ptr poa, - const char * operation, - void * cookie, - PortableServer::Servant servant - ACE_ENV_ARG_DECL_WITH_DEFAULTS) - throw (CORBA::SystemException); - - private: - CORBA::ORB_var orb_; - -}; - -#endif /* STOCK_FACTORY_LOCATOR_I_H */ diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.cpp deleted file mode 100644 index b32249cb8fd..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.cpp +++ /dev/null @@ -1,21 +0,0 @@ -// $Id$ - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - Quoter_Stock_i *rhat = new Quoter_Stock_i ("RHAT", "RedHat, Inc.", 210); - return rhat->_this (); - } else if (strcmp (symbol, "MSFT") == 0) { - Quoter_Stock_i *msft = new Quoter_Stock_i ("MSFT", "Microsoft, Inc.", 91); - return msft->_this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.h deleted file mode 100644 index 27103cce23b..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_Factory_i.h +++ /dev/null @@ -1,19 +0,0 @@ -// -// $Id$ -// -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - - diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.cpp deleted file mode 100644 index 4e23bb6e618..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.cpp +++ /dev/null @@ -1,46 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} - -CORBA::Double -Quoter_Stock_i::get_price_and_names (CORBA::String_out symbol, - CORBA::String_out full_name) - throw (CORBA::SystemException) -{ - symbol = CORBA::string_dup (this->symbol_.c_str ()); - full_name = CORBA::string_dup (this->full_name_.c_str ()); - - return this->price_; -} - - - diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.h b/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.h deleted file mode 100644 index 27163f9d2a0..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/Stock_i.h +++ /dev/null @@ -1,35 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Single_Query_Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - CORBA::Double get_price_and_names (CORBA::String_out symbol, - CORBA::String_out full_name) - throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/client.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/client.cpp deleted file mode 100644 index fcb8a8f26da..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/client.cpp +++ /dev/null @@ -1,85 +0,0 @@ -// -// $Id$ -// - -#include "Handler_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 3) { - cerr << "Usage: " << argv[0] - << " Factory_IOR symbol symbol..." << endl; - return 1; - } - - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Use the first argument to create the factory object reference, - // in real applications we use the naming service, but let's do - // the easy part first! - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Create and activate the handler... - int response_count = 0; - Single_Query_Stock_Handler_i handler_i (&response_count); - Quoter::AMI_Single_Query_StockHandler_var handler = - handler_i._this (); - - // Send all the requests, careful with error handling - int request_count = 0; - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var tmp = - factory->get_stock (argv[i]); - Quoter::Single_Query_Stock_var stock = - Quoter::Single_Query_Stock::_narrow (tmp.in ()); - if (CORBA::is_nil (stock.in ())) { - cerr << "Cannot get single query interface for <" - << argv[i] << ">" << endl; - } - - stock->sendc_get_price_and_names (handler.in ()); - request_count++; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - while (response_count < request_count - && orb->work_pending ()) { - orb->perform_work (); - } - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/index.html b/TAO/docs/tutorials/Quoter/On_Demand_Activation/index.html deleted file mode 100644 index 63e4fa14445..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/index.html +++ /dev/null @@ -1,280 +0,0 @@ - -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Servant Managers</title> - <!-- $Id$ --> - </head> - - <body text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h1>Servant Managers</h1> - <P>In our <a href=../AMI/index.html>previous example</a>, we - extended our <a href=../Simple/Client/client.cpp>simple client</a> - using synchronous method invocation to handle asynchronous - requests: Asynchronous Method Invocation by using - the reply handlers. - </P> - <P>In applications which have many objects, activating - all of them all the time would be unnecessary - and also might require too much memory or too many database - lookups. For such applications, the POA provides an option - for the application to supply servant managers that can - dynamically supply servants on a per-request basis. - </P> - <p> A servant manager is a call-back object that the application - registers with a POA. When the POA attempts to determine the - servant associated with a particular request, it calls back the - application's servant manager to obtain the servant. To be able - to register a servant manager with the POA, the - <CODE>RequestProcessingPolicyValue</CODE>, which controls the - matching of requests to servants, is to be set to - <CODE>USE_SERVANT_MANAGER</CODE>. - </P> - <P>There are two types of servant managers depending on whether the POA - retains the associations of objects to servants in its Active - Object Map or not. This is determined by the value of the - <CODE>ServantRetentionPolicy</CODE> set when the - POA is created. If the value of this policy is set as RETAIN, - the POA retains the associations, and if the policy value is set - to be NON_RETAIN, the POA doesn't retain any associations between - the object and the servant. - </P> - <P>For a POA with the RETAIN value, the servant manager must - activate the servant associated with the object. This would need - the servant manager object to support the ServantActivator - interface. In the case of a POA with the NON_RETAIN value set, - our servant manager object should be able to locate the servant - for the requested object and then invoke it. - </P> - <P>In this example, let's use a servant locator to locate the - servant associated with our Stock_Factory object when a request - is invoked on this object. - </P> - <H3>The Stock Factory Locator Implementation</H3> - <P>Our implementation of the Stock_Factory_Locator_i will help - us find the Quoter_Stock_Factory servant. - </P> - <P>A servant Locator interface provides two operations: preinvoke - and postinvoke. The preinvoke operation is invoked to obtain the - servant to dispatch the request to. The servant returned by - the preinvoke is used only for a single request. The postinvoke - operation is later invoked to destroy the servant created by the - preinvoke operation. - </P> - <PRE> - #include "tao/corba.h" - - class Quoter_Stock_Factory_Locator_i : public POA_PortableServer::ServantLocator - { - public: - Quoter_Stock_Factory_Locator_i (CORBA::ORB_ptr orb); - - // Preinvoke function - virtual PortableServer::Servant preinvoke (const PortableServer::ObjectId &oid, - PortableServer::POA_ptr poa, - const char * operation, - void * & cookie) - throw (CORBA::SystemException, PortableServer::ForwardRequest); - - // Postinvoke function - virtual void postinvoke (const PortableServer::ObjectId & oid, - PortableServer::POA_ptr poa, - const char * operation, - void * cookie, - PortableServer::Servant servant) - throw (CORBA::SystemException); - - private: - CORBA::ORB_var orb_; - }; - </PRE> - <P>In the implementation of the <CODE>preinvoke</CODE> operation, we check if - the object ID is valid and then check for the servant we want to - create and create and return the requested servant. - <PRE> - <PRE> - PortableServer::Servant - Quoter_Stock_Factory_Locator_i::preinvoke (const PortableServer::ObjectId &oid, - PortableServer::POA_ptr poa, - const char * operation, - void * & cookie) - throw (CORBA::SystemException, PortableServer::ForwardRequest) - { - - try { - - // Get the ObjectID in string format - CORBA::String_var oid_str = - PortableServer::ObjectId_to_string (oid); - - // Check if the ObjectId is valid - if (strcmp (oid_str.in (), "Quoter/Stock_Factory") != 0) { - // Create the requested servant. - PortableServer::Servant servant = - new Quoter_Stock_Factory_i (); - - cookie = servant; - - return servant; - } - else { - throw CORBA::OBJECT_NOT_EXIST (); - } - - }catch (const CORBA::BAD_PARAM &) { - throw CORBA::OBJECT_NOT_EXIST (); - } - </PRE> - <P>The implementation of the <CODE>postinvoke</CODE> operation is - simple. We just destroy the servant which we created by the - <CODE>preinvoke</CODE> operation. The <CODE>Cookie IDL - type</CODE> which is a parameter in both these operations - helps associate the invocation of <CODE>preinvoke</CODE> with - its <CODE>postinvoke</CODE> operation. - </P> - <PRE> - void - Quoter_Stock_Factory_Locator_i::postinvoke (const PortableServer::ObjectId &oid, - PortableServer::POA_ptr poa, - const char * operation, - void * cookie, - PortableServer::Servant servant) - throw (CORBA::SystemException) - { - - // Delete the servant as it is no longer needed. - PortableServer::Servant my_servant = (PortableServer::Servant) cookie; - if (servant == my_servant) - delete servant; - } - </PRE> - <H3> Server Implementation </H3> - <P>Our first steps would be to create a new POA from the RootPOA - with the <CODE>USE_SERVANT_MANAGER</CODE> value for the - <CODE>RequestProcessingPolicy</CODE> and <CODE>NON_RETAIN</CODE> - for the <CODE>ServantRetentionPolicy</CODE>. - </P> - <PRE> - CORBA::PolicyList policies (3); - policies.length (3); - - // Assign the polices - policies [0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - - policies [1] = - poa->create_request_processing_policy - (PortableServer::USE_SERVANT_MANAGER); - - policies [2] = - poa->create_servant_retention_policy (PortableServer::NON_RETAIN); - - // Create the POA with these policies - PortableServer::POA_var child_poa = - poa->create_POA ("childPOA", - poa_manager.in (), - policies); - - // Destroy the policy objects - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - </PRE> - <P> The policy values are assigned, the <CODE>childPOA</CODE> is - created with these policies, and later these policy objects can be - deleted, as a copy of these objects is made by the - <CODE>create_POA</CODE> and we would not need these objects any more. - </P> - <P> Now that we have the POA which can support servant managers, - the next step would be to create a servant for the servant - locator object, activate it to obtain its reference, and set it as - the servant manager with the childPOA. - </P> - <PRE> - // Create a Stock_Factory_Locator servant - Quoter_Stock_Factory_Locator_i servant_locator_i(orb.in ()); - - // Need to activate a servant_manager object in the Root POA - PortableServer::ServantLocator_var servant_locator = - servant_locator_i._this (); - - // Set the SM with the childPOA - child_poa->set_servant_manager (servant_locator.in ()); - </PRE> - <P>Now that we have set the servant manager with the childPOA, the - next step would be to create a reference with the user-created - ID in the childPOA which uses the Quoter_Stock_Factory_Locator_i. - The <CODE>create_reference_with_id</CODE> operation lets us - create the required object without actually creating its servant. - The application supplies the ObjectId which signifies the - identity of the object in the application domain. - </P> - <PRE> - // Get the Object Id - PortableServer::ObjectId_var child_oid = - PortableServer::string_to_ObjectId ("childFoo"); - - //Create the Object without creating the servants - CORBA::Object_var stock_factory = - child_poa->create_reference_with_id (child_oid.in (), - "IDL:Quoter/Stock_Factory:1.0"); - </PRE> - <P>After this, as before, let's put this object reference as an IOR - string and print it out. - </P> - <PRE> - // Put the object reference as an IOR string - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - - // Print it out! - std::cout << ior.in () << std::endl; - </PRE> - <H3>Excercise</H3> - <P>Modify the <a href="../Simple/Server/server.cpp">server.cpp</a> in - the simple server to use servant managers and locators. Use - these files to help complete the implementation. - <a href="Stock_Factory_Locator_i.h">Stock_Factory_locator_i.h</a> - <a href="Stock_Factory_Locator_i.cpp">Stock_Factory_locator_i.cpp</a> - <a href="Makefile">Makefile</a>. - </P> - <H3>Solution</H3> - <P>Look at the <a href="server.cpp">server.cpp</a> file. It should not - be much different from yours. - </P> - <H3>Testing</H3> - <P>A client which uses request handlers is provided: - <a href="../AMI/client.cpp">client.cpp</a>. As before the - following files are provided. - <a href="../AMI/Quoter.idl">Quoter.idl</a> - <a href="../On_Demand_Activation/Stock_i.h">Stock_i.h</a> - <a href="../On_Demand_Activation/Stock_i.cpp">Stock_i.cpp</a> - <a href="Stock_Factory_i.h">Stock_Factory_i.h</a> - <a href="Stock_Factory_i.cpp">Stock_Factory_i.cpp</a> - <a href="../AMI/Handler_i.h">Handler_i.h</a> and - <a href="../AMI/Handler_i.cpp">Handler_i.cpp</a>. - </P> - <H3>More Reading</H3> - <P>The - <P>The <A HREF="http://www.triodia.com/staff/michi-henning.html">Henning</A> and - <A HREF="http://www.iona.com/hyplan/vinoski/">Vinoski</A> - <A HREF="http://www.iona.com/hyplan/vinoski/#book">CORBA book</A> - discusses POA policies in detail. Likewise, the Schmidt and Vinoski - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html">columns </A> - in C++ Report also include several articles about the POA. Finally, - the <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a> - distribution includes - <A HREF="../../../../examples/POA">examples</A> that illustrate how to use the POA policies. - </P> - <hr> - <address><a href="mailto:pgontla@ece.uci.edu">Priyanka Gontla</a></address> - <!-- Created: Mon May 1 11:08:56 PDT 2000 --> - <!-- hhmts start --> -Last modified: Tue Apr 24 17:50:17 CDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/On_Demand_Activation/server.cpp b/TAO/docs/tutorials/Quoter/On_Demand_Activation/server.cpp deleted file mode 100644 index bf880a31793..00000000000 --- a/TAO/docs/tutorials/Quoter/On_Demand_Activation/server.cpp +++ /dev/null @@ -1,79 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_Locator_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - CORBA::PolicyList policies (3); - policies.length (3); - - // Assign the polices - - policies[0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - - policies [1] = - poa->create_request_processing_policy (PortableServer::USE_SERVANT_MANAGER); - - policies [2] = - poa->create_servant_retention_policy (PortableServer::NON_RETAIN); - - // Create the POA with these policies - PortableServer::POA_var child_poa = - poa->create_POA ("childPOA", - poa_manager.in (), - policies); - - // Destroy the policy objects - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - // Create a Stock_Factory_Locator - PortableServer::ServantLocator_var servant_locator = - new Quoter_Stock_Factory_Locator_i (orb.in ()); - - // Set the SM with the childPOA - child_poa->set_servant_manager (servant_locator.in ()); - - PortableServer::ObjectId_var child_oid = - PortableServer::string_to_ObjectId ("childFoo"); - - CORBA::Object_var stock_factory = - child_poa->create_reference_with_id (child_oid.in (), - "IDL:Quoter/Stock_Factory:1.0"); - - - // Put the object reference as an IOR string - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - - // Print it out! - cout << ior.in () << endl; - - orb->run (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Admin.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Admin.cpp deleted file mode 100644 index 77bac1c8ab1..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Admin.cpp +++ /dev/null @@ -1,100 +0,0 @@ -// $Id$ - -// ACE header files -#include "ace/Get_Opt.h" - -// local header files -#include "DistributorC.h" - -static const char *ior = "file://StockDistributor.ior"; -static const char *option = "start"; -static const char *rate = "1"; - -int parse_args (int argc, char *argv[]) -{ - ACE_Get_Opt get_opts (argc, argv, "o:r:bs"); - int c; - - while ((c = get_opts ()) != -1) - { - switch (c) - { - case 'o': - ior = get_opts.opt_arg (); - break; - case 'r': - option = "rate"; - rate = get_opts.opt_arg (); - break; - case 'b': - option = "start"; - break; - case 's': - option = "stop"; - break; - case '?': - default: - ACE_ERROR_RETURN ((LM_ERROR, - "usage: %s\n" - "-o <Distributor IOR> (the ior file of stock distributor (default is file://StockDistributor.ior)) \n" - "-r <rate> (set the distribution rate to 'n' milliseconds (default is 1)) \n" - "-b (start the stock distributor) \n" - "-s (stop the stock distributor) \n" - "\n", - argv [0]), - -1); - } - } - - return 0; -} - -int main (int argc, char *argv[]) -{ - if (parse_args (argc, argv) != 0) - return 1; - - try - { - // Initialiaze the ORB. - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - - // Read and destringify the Stock_Distributor object's IOR. - CORBA::Object_var obj = orb->string_to_object (ior); - - // Narrow the IOR to a Stock_Distributor object reference. - Stock::StockDistributor_var stock_distributor = Stock::StockDistributor::_narrow(obj); - if (CORBA::is_nil (stock_distributor.in ())) - { - ACE_ERROR_RETURN ((LM_DEBUG, - "Nil StockDistributor object reference <%s>\n", - ior), - 1); - } - - if (ACE_OS::strcmp (option, "stop") == 0) - { - ACE_DEBUG ((LM_DEBUG, "Stop the stock distributor.\n")); - stock_distributor->stop (); - } - else if (ACE_OS::strcmp (option, "rate") == 0) - { - ACE_DEBUG ((LM_DEBUG, "Set the distribution notification rate to %d seconds.\n", atoi (rate))); - stock_distributor->notification_rate (atoi (rate)); - } - else - { - ACE_DEBUG ((LM_DEBUG, "Start the stock distributor.\n")); - stock_distributor->start (); - } - - orb->destroy (); - } - catch (CORBA::Exception &ex) - { - ACE_PRINT_EXCEPTION (ACE_ANY_EXCEPTION, - "Exception caught:"); - return 1; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Broker.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Broker.cpp deleted file mode 100644 index f8c39b0f9f0..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Broker.cpp +++ /dev/null @@ -1,112 +0,0 @@ -// $Id$ - -// ACE header files -#include "ace/Get_Opt.h" - -// local header files -#include "Broker_i.h" -#include "Distributor_i.h" -#include "Stock_PriorityMapping.h" - -static const char *ior = "file://StockDistributor.ior"; -static const char *priority_level = "2"; -static const char *stock_name = "IBM"; - -int parse_args (int argc, char *argv[]) -{ - ACE_Get_Opt get_opts (argc, argv, "o:p:n:"); - int c; - - while ((c = get_opts ()) != -1) - { - switch (c) - { - case 'o': - ior = get_opts.opt_arg (); - break; - case 'p': - priority_level = get_opts.opt_arg (); - break; - case 'n': - stock_name = get_opts.opt_arg (); - break; - case '?': - default: - ACE_ERROR_RETURN ((LM_ERROR, - "usage: %s\n" - "-o <Distributor IOR> (default is file://StockDistributor.ior) \n" - "-p <Priority> (default is 2) \n" - "-n <Stock name> (default is IBM) \n" - "\n", - argv [0]), - -1); - } - } - - return 0; -} - -int main (int argc, char *argv[]) -{ - if (parse_args (argc, argv) != 0) - return 1; - - try - { - // Initialiaze the ORB. - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - - // Get a reference to the RootPOA. - CORBA::Object_var obj = orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = PortableServer::POA::_narrow (obj); - - // Activate the POAManager. - PortableServer::POAManager_var mgr = poa->the_POAManager (); - mgr->activate (); - - // Create an instance of the <StockBroker>. - static const RTCORBA::Priority priority = static_cast<RTCORBA::Priority> (atoi (priority_level)); - Stock_StockBrokerHome_i stock_broker_home (orb, stock_name, priority); - Stock::StockBroker_var stock_broker = stock_broker_home.create (); - if (CORBA::is_nil (stock_broker.in ())) - { - ACE_ERROR_RETURN ((LM_DEBUG, - "Nil StockBroker object reference <%s>\n", - ior), - 1); - } - - // Read and destringify the Stock_Distributor object's IOR. - obj = orb->string_to_object (ior); - - // Narrow the IOR to a Stock_Distributor object reference. - Stock::StockDistributor_var stock_distributor = Stock::StockDistributor::_narrow(obj); - if (CORBA::is_nil (stock_distributor.in ())) - { - ACE_ERROR_RETURN ((LM_DEBUG, - "Nil StockDistributor object reference <%s>\n", - ior), - 1); - } - - // Connect the <stock_quoter> to the <stock_broker>. - Stock::StockQuoter_var stock_quoter = stock_distributor->provide_quoter_info (); - stock_broker->connect_quoter_info (stock_quoter); - - // Create a new consumer; initialize it; subscribe to the notification service. - Stock::StockNameConsumer_var consumer = stock_broker->get_consumer_notifier (); - stock_distributor->subscribe_notifier (consumer, priority); - - // Run the event loop. - ACE_DEBUG ((LM_DEBUG, "*** message: ready to receieve stock information...\n")); - orb->run (); - orb->destroy (); - } - catch (CORBA::Exception &ex) - { - ACE_PRINT_EXCEPTION (ACE_ANY_EXCEPTION, - "Exception caught:"); - return 1; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Broker.idl b/TAO/docs/tutorials/Quoter/RTCORBA/Broker.idl deleted file mode 100644 index 63b7a6d1c99..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Broker.idl +++ /dev/null @@ -1,47 +0,0 @@ -/** -* @file Broker.idl -* @author William Otte <wotte@dre.vanderbilt.edu> -* Shanshan Jiang <shanshan.jiang@vanderbilt.edu> -* $Id$ -* Contains IDL definitions for the Stock Broker in the Publish/Subscribe Real-time CORBA -* Stock Quoter Service. -*/ - -#ifndef QUOTER_BROKER_IDL -#define QUOTER_BROKER_IDL - -#include "Common.idl" - -module Stock -{ - /** - * @class StockBroker - * @brief Provides interfaces for stock broker clients. - */ - interface StockBroker - { - /// Factory operation to return StockNameConsumer object reference. - StockNameConsumer get_consumer_notifier (); - - /// Connects the broker to a supplied Quoter object reference. - void connect_quoter_info (in StockQuoter c); - - /// Disconnects a the quoter connection. - StockQuoter disconnect_quoter_info (); - - /// Gets the current quoter connection. - StockQuoter get_connection_quoter_info (); - }; - - /** - * @class StockBrokerHome - * @brief Interface that aids in managing StockBroker lifecycles. - */ - interface StockBrokerHome - { - /// Create a StockBroker object. - StockBroker create (); - }; -}; - -#endif diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.cpp deleted file mode 100644 index 1862e32a133..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.cpp +++ /dev/null @@ -1,123 +0,0 @@ -// $Id$ - -// TAO headers -#include "tao/RTPortableServer/RTPortableServer.h" - -// local headers -#include "Broker_i.h" -#include "Stock_PriorityMapping.h" -#include "Stock_Database.h" - -// Implementation skeleton constructor -Stock_StockBroker_i::Stock_StockBroker_i (CORBA::ORB_ptr orb, - const char *stock_name, - RTCORBA::Priority priority) - : quoter_ (Stock::StockQuoter::_nil()), - consumer_ (0) -{ - // Get a reference to the <RTORB>. - CORBA::Object_var obj = orb->resolve_initial_references ("RTORB"); - RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (obj.in ()); - - // Create a <CORBA::PolicyList> for the child POA. - CORBA::PolicyList consumer_policies (1); - consumer_policies.length (1); - - // Create a <SERVER_DECLARED> priority model policy. - consumer_policies[0] = rt_orb->create_priority_model_policy (RTCORBA::SERVER_DECLARED, - Stock_PriorityMapping::MEDIUM); - - // Create a child POA with SERVER_DECLARED policies. The name of the - // POA will be <Stock_StockDistributorHome>. Any instances of the - // Stock_StockDistributor_i created via the create() method will be - // activated under this POA. - PortableServer::POA_var poa = this->_default_POA()->create_POA ( - "StockNameConsumer_POA", PortableServer::POAManager::_nil (), consumer_policies); - - consumer_policies[0]->destroy (); - - // Narrow the POA to a <RTPortableServer::POA>. - RTPortableServer::POA_var rt_poa = RTPortableServer::POA::_narrow (poa); - - // Activate the <consumer_> with the specified <priority>. - this->consumer_ = new Stock_StockNameConsumer_i (this->_this (), stock_name); - PortableServer::ServantBase_var nameconsumer_owner_transfer = this->consumer_; - rt_poa->activate_object_with_priority (this->consumer_, priority); -} - -// Implementation skeleton destructor -Stock_StockBroker_i::~Stock_StockBroker_i (void) -{ -} - -::Stock::StockNameConsumer_ptr Stock_StockBroker_i::get_consumer_notifier () - throw (::CORBA::SystemException) -{ - Stock::StockNameConsumer_var consumer = this->consumer_->_this (); - return consumer._retn(); -} - -void Stock_StockBroker_i::connect_quoter_info (::Stock::StockQuoter_ptr c) - throw (::CORBA::SystemException) -{ - this->quoter_ = Stock::StockQuoter::_duplicate (c); -} - -::Stock::StockQuoter_ptr Stock_StockBroker_i::disconnect_quoter_info () - throw (::CORBA::SystemException) -{ - Stock::StockQuoter_var old_quoter = this->quoter_; - this->quoter_ = Stock::StockQuoter::_nil(); - return old_quoter._retn (); -} - -::Stock::StockQuoter_ptr Stock_StockBroker_i::get_connection_quoter_info () - throw (::CORBA::SystemException) -{ - return Stock::StockQuoter::_duplicate (this->quoter_); -} - -// Implementation skeleton constructor -Stock_StockBrokerHome_i::Stock_StockBrokerHome_i (CORBA::ORB_ptr orb, - const char *stock_name, - RTCORBA::Priority priority) - : broker_ (0) -{ - // Register the necessary factories and mappings with the specified - // <orb>. If we neglect to perform these registrations then the app - // will not execute. - Stock::StockName_init *stockname_factory = new Stock::StockName_init; - orb->register_value_factory (stockname_factory->tao_repository_id (), - stockname_factory); - - Stock::Cookie_init *cookie_factory = new Stock::Cookie_init; - orb->register_value_factory (cookie_factory->tao_repository_id (), - cookie_factory); - - Stock_PriorityMapping::register_mapping (orb); - - // Because the broker has nothing to do with any of the RTCORBA - // mechanisms, we can register it under the <default_POA>. - try - { - this->broker_ = new Stock_StockBroker_i (orb, stock_name, priority); - PortableServer::ServantBase_var broker_owner_transfer = this->broker_; - this->_default_POA ()->activate_object (this->broker_); - } - catch (PortableServer::POA::ServantAlreadyActive &) { - // we only catch this exception and let any other exception - // propogate to the upper level. - } -} - -// Implementation skeleton destructor -Stock_StockBrokerHome_i::~Stock_StockBrokerHome_i (void) -{ -} - -::Stock::StockBroker_ptr Stock_StockBrokerHome_i::create () - throw (::CORBA::SystemException) -{ - Stock::StockBroker_var broker = this->broker_->_this (); - return broker._retn(); -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.h b/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.h deleted file mode 100644 index d8fb12c8095..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Broker_i.h +++ /dev/null @@ -1,116 +0,0 @@ -// $Id$ - -/** - * @file Broker_i.h - * @author Shanshan Jiang <shanshan.jiang@vanderbilt.edu> - */ - -#ifndef BROKERI_H_ -#define BROKERI_H_ - -// local headers -#include "Common_i.h" -#include "BrokerS.h" - -#if !defined (ACE_LACKS_PRAGMA_ONCE) -#pragma once -#endif /* ACE_LACKS_PRAGMA_ONCE */ - -/** - * @class Stock_StockBroker_i - * @brief This class defined the Stock Broker client. - */ -class Stock_StockBroker_i - : public virtual POA_Stock::StockBroker -{ -public: - /** - * Constructor. - * - * @param orb - * @param stock_name The name of the stock that the Stock Broker client is interested in. - * @param priority The priority of this Stock Broker client. - */ - Stock_StockBroker_i (CORBA::ORB_ptr orb, - const char *stock_name, - RTCORBA::Priority priority); - - /// Destructor - virtual ~Stock_StockBroker_i (void); - - /** - * Return the StockNameConsumer object created by the Constructor. - * - * @return Returns a StockNameConsumer object reference. - */ - virtual ::Stock::StockNameConsumer_ptr get_consumer_notifier () - throw (::CORBA::SystemException); - - /** - * Duplicate a StockQuoter object using the StockQuoter object reference "c" in the argument. - * - * @param c A StockQuoter object reference. - */ - virtual void connect_quoter_info (::Stock::StockQuoter_ptr c) - throw (::CORBA::SystemException); - - /** - * Destroy the StockQuoter object and return it. - * - * @return Returns the destroyed StockQuoter object reference. - */ - virtual ::Stock::StockQuoter_ptr disconnect_quoter_info () - throw (::CORBA::SystemException); - - /** - * Return the StockQuoter object. - * - * @return Returns the StockQuoter object reference that has been created by connect_quoter_info (). - */ - virtual ::Stock::StockQuoter_ptr get_connection_quoter_info () - throw (::CORBA::SystemException); - -private: - /// A StockQuoter object reference that is used to get detailed stock information. - Stock::StockQuoter_var quoter_; - - /// A StockNameConsumer object that is used to get notification of updates. - Stock_StockNameConsumer_i *consumer_; -}; - -/** - * @class Stock_StockBrokerHome_i - * @brief This class defined the Stock Broker home. - */ -class Stock_StockBrokerHome_i - : public virtual POA_Stock::StockBrokerHome -{ -public: - /** - * Constructor. - * Register the necessary factories and mappings with the specified orb and - * Create a new instance of the StockBroker object. - * - * @param orb - */ - Stock_StockBrokerHome_i (CORBA::ORB_ptr orb, - const char *stock_name, - RTCORBA::Priority priority); - - /// Destructor - virtual ~Stock_StockBrokerHome_i (void); - - /** - * Return the StockBroker object created by the Constructor. - * - * @return The StockBroker object created by the Constructor. - */ - virtual ::Stock::StockBroker_ptr create () - throw (::CORBA::SystemException); - -private: - /// The StockDistributor object created by its home. - Stock_StockBroker_i *broker_; -}; - -#endif /* BROKERI_H_ */ diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Common.idl b/TAO/docs/tutorials/Quoter/RTCORBA/Common.idl deleted file mode 100644 index 9ff78a5c611..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Common.idl +++ /dev/null @@ -1,67 +0,0 @@ -/** -* @file Common.idl -* @author William Otte <wotte@dre.vanderbilt.edu> -* Shanshan Jiang <shanshan.jiang@vanderbilt.edu> -* $Id$ -* Contains common IDL definitions in the Publish/Subscribe Real-time CORBA -* Stock Quoter Service. -*/ - -#ifndef QUOTER_COMMON_IDL -#define QUOTER_COMMON_IDL - -module Stock -{ - exception Invalid_Stock - { - }; - - /// Contains information about a single stock. - struct StockInfo - { - string name; - long high; - long low; - long last; - }; - - /// Used to communicate an available update. - valuetype StockName - { - public string name; - }; - - valuetype Cookie - { - public string cookie_id; - }; - - interface Trigger - { - void start (); - void stop (); - }; - - /** - * @class StockNameConsumer - * @brief Callback interface used by the distributor to notify brokers of updates. - */ - interface StockNameConsumer - { - void push_StockName (in StockName the_stockname); - }; - - /** - * @class StockQuoter - * @brief Provides an interface for brokers to get detailed stock information. - */ - interface StockQuoter - { - /// Returns detailed stock information to brokers. - /// @param stockname A valid name for a stock. - /// @returns Completed stockinfo struct. - StockInfo get_stock_info (in string stock_name) raises (Invalid_Stock); - }; -}; - -#endif diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.cpp deleted file mode 100644 index 51fc0b28fb2..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.cpp +++ /dev/null @@ -1,79 +0,0 @@ -// $Id$ - -// local headers -#include "Common_i.h" -#include "Stock_Database.h" - -// Implementation skeleton constructor -Stock_StockNameConsumer_i::Stock_StockNameConsumer_i (Stock::StockBroker_ptr parent, - const char *stock_name) - : parent_ (Stock::StockBroker::_duplicate (parent)), - stock_name_ (CORBA::string_dup (stock_name)) -{ -} - -// Implementation skeleton destructor -Stock_StockNameConsumer_i::~Stock_StockNameConsumer_i (void) -{ -} - -void Stock_StockNameConsumer_i::push_StockName (::Stock::StockName *the_stockname) - throw (::CORBA::SystemException) -{ - // Verify the <parent_> is valid. There is no need to continue processing - // any information if there is not <parent_> attached to the object. The - // <parent_> is needed to retrieve the <quoter>. - if (CORBA::is_nil (this->parent_)) - return; - - // Verify this is the correct stock. If this is not the stock that we are - // interested in then we need to stop and return control to the client/ - // server. - if (ACE_OS::strcmp (this->stock_name_, the_stockname->name ()) != 0) - return; - - // Get the quoter for the connection. - ACE_DEBUG ((LM_DEBUG, "*** message: getting the quoter connection\n")); - Stock::StockQuoter_var quoter = this->parent_->get_connection_quoter_info (); - - try - { - // Request more information from the quoter. - ACE_DEBUG ((LM_DEBUG, "*** message: requesting the stock info from the quoter\n")); - Stock::StockInfo_var stock_info = quoter->get_stock_info (the_stockname->name()); - - // Display the current value of the stock. - ACE_DEBUG ((LM_DEBUG, "Current value of %s is $%d\n", - the_stockname->name (), stock_info->last)); - } - catch (Stock::Invalid_Stock &e) - { - ACE_PRINT_EXCEPTION (e, "Stock exception: invalid stock name: "); - } - catch (CORBA::Exception &ex) - { - ACE_PRINT_EXCEPTION (ex, "Stock_StockNameConsumer_i::push_StockName: "); - } -} - -// Implementation skeleton constructor -Stock_StockQuoter_i::Stock_StockQuoter_i (void) -{ -} - -// Implementation skeleton destructor -Stock_StockQuoter_i::~Stock_StockQuoter_i (void) -{ -} - -::Stock::StockInfo *Stock_StockQuoter_i::get_stock_info (const char * stock_name) - throw (::CORBA::SystemException, ::Stock::Invalid_Stock) -{ - ACE_DEBUG ((LM_DEBUG, "*** message: requesting stock_info from the database\n")); - - Stock::StockInfo *stock = STOCK_DATABASE->get_stock_info (stock_name); - - if (stock == 0) - throw Stock::Invalid_Stock(); - return stock; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.h b/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.h deleted file mode 100644 index 77e829366b1..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Common_i.h +++ /dev/null @@ -1,86 +0,0 @@ -// $Id$ - -/** - * @file Common_i.h - * @author Shanshan Jiang <shanshan.jiang@vanderbilt.edu> - */ - -#ifndef COMMONI_H_ -#define COMMONI_H_ - -// local headers -#include "CommonS.h" -#include "BrokerS.h" - -// TAO headers -#include "tao/RTCORBA/RTCORBA.h" - -// STL headers -#include <string> - -#if !defined (ACE_LACKS_PRAGMA_ONCE) -#pragma once -#endif /* ACE_LACKS_PRAGMA_ONCE */ - -/** - * @class Stock_StockNameConsumer_i - * @brief This class is used as a callback interface used by the - * distributor to notify brokers of updates. - */ -class Stock_StockNameConsumer_i - : public virtual POA_Stock::StockNameConsumer -{ -public: - /** - * Constructor. - * - * @param parent The parent StockBroker object reference of the StockNameConsumer object. - * @param stock_name The name of the stock that the parent StockBroker object need to listen to. - */ - Stock_StockNameConsumer_i (Stock::StockBroker_ptr parent, - const char *stock_name); - - /// Destructor. - virtual ~Stock_StockNameConsumer_i (void); - - /** - * Push an event to the consumer. - * - * @param the_stockname The name of the stock that will be provided to the parent StockBroker object. - */ - virtual void push_StockName (::Stock::StockName *the_stockname) - throw (::CORBA::SystemException); - -private: - /// Parent of the StockNameConsumer object. - Stock::StockBroker_var parent_; - - /// Name of the stock to listen to. - CORBA::String_var stock_name_; -}; - -/** - * @class Stock_StockQuoter_i - * @brief This class is used by brokers to get detailed stock information. - */ -class Stock_StockQuoter_i - : public virtual POA_Stock::StockQuoter -{ -public: - /// Constructor. - Stock_StockQuoter_i (void); - - /// Destructor. - virtual ~Stock_StockQuoter_i (void); - - /** - * Get detailed stock information. - * - * @param stock_name The name of the stock whose detailed info is needed. - * @throw ::Stock::Invalid_Stock - */ - virtual ::Stock::StockInfo * get_stock_info (const char *stock_name) - throw (::CORBA::SystemException, ::Stock::Invalid_Stock); -}; - -#endif /* COMMONI_H_ */ diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.cpp deleted file mode 100644 index 0c941b50bcb..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.cpp +++ /dev/null @@ -1,97 +0,0 @@ -// $Id$ - -// ACE header files -#include "ace/Get_Opt.h" - -// local header files -#include "Distributor_i.h" - -static const char *ior = "StockDistributor.ior"; -static const char *rate = "1"; - -int parse_args (int argc, char *argv[]) -{ - ACE_Get_Opt get_opts (argc, argv, "o:r:"); - int c; - - while ((c = get_opts ()) != -1) - { - switch (c) - { - case 'o': - ior = get_opts.opt_arg (); - break; - case 'r': - rate = get_opts.opt_arg (); - break; - case '?': - default: - ACE_ERROR_RETURN ((LM_ERROR, - "usage: %s\n" - "-o <Distributor IOR> (default is file://StockDistributor.ior) \n" - "\n", - argv [0]), - -1); - } - } - - return 0; -} - -int main (int argc, char *argv[]) -{ - if (parse_args (argc, argv) != 0) - return 1; - - try - { - // Initalize the ORB. - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - - // Get the RootPOA. - CORBA::Object_var obj = orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = PortableServer::POA::_narrow (obj.in ()); - ACE_ASSERT (!CORBA::is_nil (obj)); - - // Activate the POAManager. - PortableServer::POAManager_var mgr = poa->the_POAManager (); - mgr->activate (); - - // Create the factory object. Create a <Stock::StockDistributor>. - Stock_StockDistributorHome_i stock_distributor_home (orb); - Stock::StockDistributor_var stock_distributor = stock_distributor_home.create (); - if (CORBA::is_nil (stock_distributor.in ())) - { - ACE_ERROR_RETURN ((LM_DEBUG, - "Nil StockDistributor object reference <%s>\n", - ior), - 1); - } - - // Write the object reference for the <stock_distributor> to a file - // so the <StockBroker> can read it when it's bootstrapping. - CORBA::String_var str = orb->object_to_string (stock_distributor.in ()); - FILE *output_file= ACE_OS::fopen (ior, "w"); - if (output_file == 0) - ACE_ERROR_RETURN ((LM_ERROR, - "Cannot open output file for writing IOR: %s\n", - ior), - 1); - ACE_OS::fprintf (output_file, "%s", str.in ()); - ACE_OS::fclose (output_file); - - stock_distributor->notification_rate (atoi (rate)); - - // Enter into the event looping. - ACE_DEBUG ((LM_DEBUG, "*** message: ready for transmission...\n")); - orb->run (); - orb->destroy (); - } - catch (CORBA::Exception &ex) - { - ACE_PRINT_EXCEPTION (ex, "Admin: "); - - return 1; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.idl b/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.idl deleted file mode 100644 index e40be03854d..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor.idl +++ /dev/null @@ -1,51 +0,0 @@ -/** -* @file Distributor.idl -* @author William Otte <wotte@dre.vanderbilt.edu> -* Shanshan Jiang <shanshan.jiang@vanderbilt.edu> -* $Id$ -* Contains IDL definitions for the Distributor in the Publish/Subscribe Real-time CORBA -* Stock Quoter Service. -*/ - -#ifndef QUOTER_DISTRIBUTOR_IDL -#define QUOTER_DISTRIBUTOR_IDL - -#include "Common.idl" -#include "tao/RTCORBA/RTCORBA_include.pidl" - -module Stock -{ - /** - * @class StockDistributor - * @brief Provides interfaces for stock distributor server. - */ - interface StockDistributor : Trigger - { - /// Event source operation to establish connectivity. - /// @param c An object reference to the consumer the distributor should notify - /// @returns A cookie used to identify the subscription. - Cookie subscribe_notifier (in Stock::StockNameConsumer c, in RTCORBA::Priority priority); - - /// Opteration to discontinue connectivity. - /// @param ck The cookie that identifies the connection to be terminated. - Stock::StockNameConsumer unsubscribe_notifier (in Cookie ck); - - /// Factory operation to return StockQuoter object reference. - StockQuoter provide_quoter_info (); - - /// Controls rate of updates. - attribute long notification_rate; - }; - - /** - * @class StockDistributorHome - * @brief Interface that aids in managing StockDistributor lifecycles. - */ - interface StockDistributorHome - { - /// Create a StockDistributor object. - StockDistributor create (); - }; -}; - -#endif diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.cpp deleted file mode 100644 index af66ceafd96..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.cpp +++ /dev/null @@ -1,249 +0,0 @@ -// $Id$ - -// ACE headers -#include "ace/OS_NS_unistd.h" - -// TAO headers -#include "tao/RTPortableServer/RTPortableServer.h" - -// local headers -#include "Distributor_i.h" -#include "Stock_PriorityMapping.h" -#include "Stock_Database.h" - -// STL headers -#include <strstream> - -// Implementation skeleton constructor -Stock_StockDistributor_i::Stock_StockDistributor_i (CORBA::PolicyList &policy_list) - : rate_(3000), - active_ (false), - quoter_ (0) -{ - // Create a child POA with CLIENT_PROPAGATED policies. The name of the - // POA will be <StockQuoter_POA>. Any instances of the - // Stock_StockQuoter_i created by this Stock_StockDistributor_i object - // will be activated under this POA. - PortableServer::POA_var poa = this->_default_POA()->create_POA ( - "StockQuoter_POA", PortableServer::POAManager::_nil (), policy_list); - - // _narrow () the POA to a RTPortableServer::POA. - RTPortableServer::POA_var rt_poa = RTPortableServer::POA::_narrow (poa); - - // Create a new instance of the <quoter_> under it's own personal - // POA. But the POA shares the <threadpool> with other POA's as well. - this->quoter_ = new Stock_StockQuoter_i; - PortableServer::ServantBase_var quoter_owner_transfer = this->quoter_; - rt_poa->activate_object (this->quoter_); - - // Seed the random number generator - ACE_OS::srand (time (0)); -} - -// Implementation skeleton destructor -Stock_StockDistributor_i::~Stock_StockDistributor_i (void) -{ - this->active_ = false; -} - -::Stock::Cookie * Stock_StockDistributor_i::subscribe_notifier (::Stock::StockNameConsumer_ptr c, - ::RTCORBA::Priority priority) - throw (::CORBA::SystemException) -{ - // Get mutual exclusion of the <subscribers_list_>. - ACE_GUARD_RETURN (ACE_RW_Thread_Mutex, g, lock_, 0); - - // Generate an unique id for the cookie. - std::ostrstream cookie_id; - cookie_id << "COOKIE:" << time (0) << "_" << ACE_OS::rand () << std::ends; - - // Create a new cookie object; initialize its value. - Stock::Cookie_var cookie = new OBV_Stock::Cookie (cookie_id.str ()); - - // Insert the cookie into the <subscribers_list_>. - std::pair <CookieMap::iterator, bool> result = - this->subscribers_list_.insert (std::make_pair (cookie->cookie_id (), - std::make_pair (Stock::StockNameConsumer::_duplicate (c), priority))); - - if (result.second == true) - { - return cookie._retn(); - } - - return 0; -} - -::Stock::StockNameConsumer_ptr Stock_StockDistributor_i::unsubscribe_notifier (::Stock::Cookie *ck) - throw (::CORBA::SystemException) -{ - // Get mutual exclusion of the <subscribers_list_>. - ACE_GUARD_RETURN (ACE_RW_Thread_Mutex, g, lock_, 0); - - // Search for the <cookie> in the <subscribers_list_>. - CookieMap::iterator iter = this->subscribers_list_.find (ck->cookie_id ()); - - // Verify we have located the <cookie>. - if (iter == this->subscribers_list_.end ()) - return Stock::StockNameConsumer::_nil (); - - // Erase the mapping from the <subscribers_list_>. - Stock::StockNameConsumer_var consumer = iter->second.first; - this->subscribers_list_.erase (iter); - - // Return the StockNameConsumer to the client. - return Stock::StockNameConsumer::_duplicate (consumer); -} - -::Stock::StockQuoter_ptr Stock_StockDistributor_i::provide_quoter_info () - throw (::CORBA::SystemException) -{ - Stock::StockQuoter_var quoter = this->quoter_->_this (); - return quoter._retn(); -} - -::CORBA::Long Stock_StockDistributor_i::notification_rate () - throw (::CORBA::SystemException) -{ - return this->rate_; -} - -void Stock_StockDistributor_i::notification_rate (::CORBA::Long notification_rate) - throw (::CORBA::SystemException) -{ - this->rate_ = notification_rate; -} - -void Stock_StockDistributor_i::start () - throw (::CORBA::SystemException) -{ - if (!this->active_) - { - this->active_ = true; - - this->activate (THR_NEW_LWP | THR_JOINABLE, 1); - } -} - -void Stock_StockDistributor_i::stop () - throw (::CORBA::SystemException) -{ - this->active_ = false; -} - -// Implementation skeleton constructor -Stock_StockDistributorHome_i::Stock_StockDistributorHome_i (CORBA::ORB_ptr orb) - : distributor_ (0) -{ - // Register the necessary factories and mappings with the specified - // <orb>. If we neglect to perform these registrations then the app - // will not execute. - Stock::StockName_init *stockname_factory = new Stock::StockName_init; - orb->register_value_factory (stockname_factory->tao_repository_id (), - stockname_factory); - - Stock::Cookie_init *cookie_factory = new Stock::Cookie_init; - orb->register_value_factory (cookie_factory->tao_repository_id (), - cookie_factory); - - Stock_PriorityMapping::register_mapping (orb); - - // Initialize the database - STOCK_DATABASE->activate (THR_NEW_LWP | THR_JOINABLE, 1); - - // Get a reference to the <RTORB>. - CORBA::Object_var obj = orb->resolve_initial_references ("RTORB"); - RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (obj.in ()); - - // Create a <CORBA::PolicyList> for the child POA. - CORBA::PolicyList stock_distributor_policies (2); - stock_distributor_policies.length (2); - - // Create a <CLIENT_PROPOGATED> priority model policy. - stock_distributor_policies[0] = - rt_orb->create_priority_model_policy (RTCORBA::CLIENT_PROPAGATED, - Stock_PriorityMapping::MEDIUM); - - // Create a threadpool with lanes for the distributor. Since the brokers - // will have various priorities, create a lane for each priority. - RTCORBA::ThreadpoolLanes lanes (5); lanes.length (5); - for (CORBA::ULong i = 0; i < lanes.length (); ++i) { - lanes[i].lane_priority = static_cast<RTCORBA::Priority> (i); - lanes[i].static_threads = 5; - lanes[i].dynamic_threads = 2; - } - - RTCORBA::ThreadpoolId threadpool_id = - rt_orb->create_threadpool_with_lanes (1024 * 10, lanes, false, false, 0, 0); - stock_distributor_policies[1] = rt_orb->create_threadpool_policy (threadpool_id); - - // Create a child POA with CLIENT_PROPAGATED policies. The name of the - // POA will be <StockDistributor_POA>. Any instances of the - // Stock_StockDistributor_i created via the create() method will be - // activated under this POA. - PortableServer::POA_var poa = this->_default_POA()->create_POA ( - "StockDistributor_POA", PortableServer::POAManager::_nil (), stock_distributor_policies); - - // Create a new instance of the <Stock_StockDistributor_i>. Then activate - // the <distributor> under the located POA. This will cause the objec - // to have the CLIENT_PROPAGATED policies. - RTPortableServer::POA_var rt_poa = RTPortableServer::POA::_narrow (poa); - - try - { - this->distributor_ = new Stock_StockDistributor_i (stock_distributor_policies); - PortableServer::ServantBase_var distributor_owner_transfer = this->distributor_; - rt_poa->activate_object (this->distributor_); - } - catch (RTPortableServer::POA::ServantAlreadyActive &) - { - } - - stock_distributor_policies[0]->destroy (); - stock_distributor_policies[1]->destroy (); -} - -// Implementation skeleton destructor -Stock_StockDistributorHome_i::~Stock_StockDistributorHome_i (void) -{ -} - -::Stock::StockDistributor_ptr Stock_StockDistributorHome_i::create () - throw (::CORBA::SystemException) -{ - Stock::StockDistributor_var distributor = this->distributor_->_this (); - return distributor._retn(); -} - -int Stock_StockDistributor_i::svc (void) -{ - // Continue looping while the stock distributor is active. - while (this->active_) - { - ACE_DEBUG ((LM_DEBUG, "*** message: transmitting data to the StockNameConsumer...\n")); - - ACE_GUARD_RETURN (ACE_RW_Thread_Mutex, g, lock_, 0); - - // Push the information to all the consumers. - Stock_StockDistributor_i::CookieMap::iterator iter; - - for (iter = this->subscribers_list_.begin (); - iter != this->subscribers_list_.end (); - ++iter) - { - try - { - // Tell the database to push its information to the <consumer>. - STOCK_DATABASE->publish_stock_info (iter->second.first); - } - catch (CORBA::Exception &ex) - { - ACE_PRINT_EXCEPTION (ex, "Stock_StockDistributor_i::svc: "); - } - } - - // Sleep for the specified amount of seconds. The notification - // rate is in milliseconds. - ACE_OS::sleep(this->notification_rate ()); - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.h b/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.h deleted file mode 100644 index 89d0f20a882..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Distributor_i.h +++ /dev/null @@ -1,158 +0,0 @@ -// $Id$ - -/** - * @file Distributor_i.h - * @author Shanshan Jiang <shanshan.jiang@vanderbilt.edu> - */ - -#ifndef DISTRIBUTORI_H_ -#define DISTRIBUTORI_H_ - -// ACE headers -#include "ace/Task.h" - -// local headers -#include "Common_i.h" -#include "DistributorS.h" - -// STL headers -#include <map> - -#if !defined (ACE_LACKS_PRAGMA_ONCE) -#pragma once -#endif /* ACE_LACKS_PRAGMA_ONCE */ - -/** - * @class Stock_StockDistributor_i - * @brief This class defined the Stock Distributor server. - */ -class Stock_StockDistributor_i - : public ACE_Task_Base, - public virtual POA_Stock::StockDistributor -{ -public: - /** - * Constructor. - * - * @param orb - * @param policy_list The policy list use to create StockQuoter_POA. - */ - Stock_StockDistributor_i (CORBA::PolicyList &policy_list); - - /// Destructor - virtual ~Stock_StockDistributor_i (void); - - /** - * Insert StockNameConsumer object and its priority into the StockDistributor - * object's subscribers' map. - * - * @param c The StockNameConsumer object to be inserted into the StockDistributor - object's subscribers' map. - * @param priority The priority of the StockNameConsumer object. - * @return A Cookie object that records this subscription. - */ - virtual ::Stock::Cookie * subscribe_notifier (::Stock::StockNameConsumer_ptr c, ::RTCORBA::Priority priority) - throw (::CORBA::SystemException); - - /** - * Erase the StockNameConsumer object from the StockDistributor object's subscribers' map. - * - * @param ck The Cookie object that records the subscription. - * @param The reference of the StockNameConsumer object that has been erased. - */ - virtual ::Stock::StockNameConsumer_ptr unsubscribe_notifier (::Stock::Cookie *ck) - throw (::CORBA::SystemException); - - /** - * Return the StockQuoter object created by the Constructor. - * - * @return A StockQuoter object created by this StockDistributor object. - */ - virtual ::Stock::StockQuoter_ptr provide_quoter_info () - throw (::CORBA::SystemException); - - /** - * Get the notification_rate attribute. - * - * @return The notification_rate attribute. - */ - virtual ::CORBA::Long notification_rate () - throw (::CORBA::SystemException); - - /** - * Set the notification_rate attribute. - * - * @param notification_rate The value of notification_rate attribute that need to be set. - */ - virtual void notification_rate (::CORBA::Long notification_rate) - throw (::CORBA::SystemException); - - /** - * Set the active state of the StockDistributor object to true and create a thread - * to publish the stock information to the Stock Broker clients. - */ - virtual void start () - throw (::CORBA::SystemException); - - /** - * Set the active state of StockDistributor object to false. - */ - virtual void stop () - throw (::CORBA::SystemException); - -private: - virtual int svc (void); - - /// Notification rate for distributor in milliseconds. - CORBA::Long rate_; - - /// The map that stores the subscribed StockNameConsumer object. - typedef std::map <const char *, - std::pair <Stock::StockNameConsumer_ptr, - RTCORBA::Priority> > CookieMap; - CookieMap subscribers_list_; - - /// The StockQuoter object created by this StockDistributor object. - Stock_StockQuoter_i *quoter_; - - /// ACE_RW_Thread_Mutex. - ACE_RW_Thread_Mutex lock_; - - /// The active state of the StockDistributor object. - bool active_; -}; - -/** - * @class Stock_StockDistributorHome_i - * @brief This class defined the Stock Distributor home. - */ -class Stock_StockDistributorHome_i - : public virtual POA_Stock::StockDistributorHome -{ -public: - /** - * Constructor. - * Register the necessary factories and mappings with the specified orb and - * Create a new instance of the StockDistributor object. - * - * @param orb - */ - Stock_StockDistributorHome_i (CORBA::ORB_ptr orb); - - /// Destructor - virtual ~Stock_StockDistributorHome_i (void); - - /** - * Return the StockDistributor object created by the Constructor. - * - * @return The StockDistributor object created by the Constructor. - */ - virtual ::Stock::StockDistributor_ptr create () - throw (::CORBA::SystemException); - -private: - /// The StockDistributor object created by its home. - Stock_StockDistributor_i *distributor_; -}; - -#endif /* DISTRIBUTORI_H_ */ diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/StockQuoter.mpc b/TAO/docs/tutorials/Quoter/RTCORBA/StockQuoter.mpc deleted file mode 100644 index 7f20a9b18d3..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/StockQuoter.mpc +++ /dev/null @@ -1,60 +0,0 @@ -// $Id$ - -// -*- MPC -*- -// $Id: StockQuoter.mpc -// $author: Shanshan Jiang <shanshan.jiang@vanderbilt.edu> -// Contains project definitions for the Publish/Subscribe Real-time CORBA -// Stock Quoter Service. - -project(*Admin): rt_client, stl { - libs += TAO_Valuetype - - Idl_Files { - } - - after = *Distributor *Broker - - Source_Files { - CommonC.cpp - DistributorC.cpp - Admin.cpp - } -} - -project(*Distributor): rt_server, stl { - libs += TAO_Valuetype - - Source_Files { - Common_i.cpp - Distributor.cpp - Distributor_i.cpp - Stock_Database.cpp - Stock_PriorityMapping.cpp - } - - Header_Files { - Common_i.h - Distributor_i.h - Stock_Database.h - Stock_PriorityMapping.h - } -} - -project(*Broker): rt_server, stl { - libs += TAO_Valuetype - - Source_Files { - Common_i.cpp - Broker.cpp - Broker_i.cpp - Stock_Database.cpp - Stock_PriorityMapping.cpp - } - - Header_Files { - Common_i.h - Broker_i.h - Stock_Database.h - Stock_PriorityMapping.h - } -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.cpp deleted file mode 100644 index a5b54378e49..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.cpp +++ /dev/null @@ -1,96 +0,0 @@ -// $Id$ - -// ACE headers -#include <ace/OS_NS_unistd.h> - -// local headers -#include "Stock_Database.h" - -// -// Stock_Database -// -Stock_Database::Stock_Database (void) -{ - const char *stock_names [] = {"MSFT", "INTEL", "IBM"}; - - Stock::StockInfo_var stock_info; - - for (int i = 0; i < sizeof (stock_names) / sizeof (const char *); ++i) - { - stock_info = new Stock::StockInfo; - - stock_info->name = stock_names[i]; - stock_info->high = 70 + (ACE_OS::rand () % 30); - stock_info->last = 65 + (ACE_OS::rand () % 15); - stock_info->low = 60 + (ACE_OS::rand () % 20); - - this->stock_map_.insert (std::make_pair (std::string (stock_names[i]), stock_info)); - } -} - -// -// get_stock_info -// -Stock::StockInfo * Stock_Database::get_stock_info (const char *name) -{ - // Locate the <stock_name> in the database. - ACE_DEBUG ((LM_DEBUG, "*** message: searching the stock_map_ for the stock_name\n")); - StockMap::iterator iter = this->stock_map_.find (std::string (name)); - - if (iter == this->stock_map_.end()) - return 0; - - ACE_DEBUG ((LM_DEBUG, "*** message: returning stock_info to the client\n")); - - Stock::StockInfo_var stock_info = new Stock::StockInfo; - stock_info->name = std::string (iter->second->name).c_str (); - stock_info->high = iter->second->high; - stock_info->last = iter->second->last; - stock_info->low = iter->second->low; - - return stock_info._retn();; -} - -// -// publish_stock_info -// -void Stock_Database::publish_stock_info (Stock::StockNameConsumer_ptr consumer) -{ - Stock::StockName_var stock_name = new OBV_Stock::StockName; - - for (StockMap::iterator iter = this->stock_map_.begin (); - iter != this->stock_map_.end(); ++iter) - { - stock_name->name (iter->first.c_str()); - consumer->push_StockName (stock_name); - } -} - -int Stock_Database::svc (void) -{ - while (true) - { - for (Stock_Database::StockMap::iterator iter = this->stock_map_.begin (); - iter != this->stock_map_.end (); ++iter) - { - // Determine whether the stock has increased of decreased. - int mult = ACE_OS::rand (); - mult = mult % 2 == 0 ? 1 : -1; - - // Determine the amount of change of the stock. We will only permi - // a 5 point change at a time. - int delta = mult * (ACE_OS::rand () % 5); - - // Calculate the new values for the stock. - iter->second->last += delta; - if (iter->second->last < iter->second->low) - iter->second->low = iter->second->last; - else if (iter->second->last > iter->second->high) - iter->second->high = iter->second->last; - } - - // Sleep for one second. - ACE_OS::sleep (1); - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.h b/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.h deleted file mode 100644 index d952dfa4cde..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_Database.h +++ /dev/null @@ -1,65 +0,0 @@ -// $Id$ - -/** - * @file Stock_Database.h - * @author Shanshan Jiang <shanshan.jiang@vanderbilt.edu> - */ - -#ifndef STOCK_DATABASE_H_ -#define STOCK_DATABASE_H_ - -// ACE headers -#include "ace/Task.h" - -// local headers -#include "Common_i.h" - -// STL headers -#include <map> - -/** - * @class Stock_Database - * @brief This class is used to install, update and publish the information of - * all the stocks. It uses the singleton design pattern. - */ -class Stock_Database: public ACE_Task_Base -{ -public: - /// Constructor. - Stock_Database (void); - - /// Destructor. - //Stock_Database (void); - - /** - * Create a StockInfo object stored in the database with the given name. - * - * @param name The name of the stock. - * @return A StockInfo object. - */ - Stock::StockInfo *get_stock_info (const char *name); - - /** - * This function is called by the Stock Distributor server's thread function - * to notify the Stock Broker client the state change of the stock it interested in. - * - * @param consumer The StockNameConsumer object reference. - */ - void publish_stock_info (Stock::StockNameConsumer_ptr consumer); - - /** - * This function is used to calculate the new high, low and last values - * for each stock in the stock database randomly. - */ - virtual int svc (void); - -private: - /// Stock map. - typedef std::map<std::string, Stock::StockInfo_var> StockMap; - StockMap stock_map_; -}; - -typedef ACE_Singleton<Stock_Database, ACE_Thread_Mutex> Stock_Database_Singleton; -#define STOCK_DATABASE Stock_Database_Singleton::instance() - -#endif // !defined STOCK_DATABASE_H_ diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.cpp b/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.cpp deleted file mode 100644 index 023da22185a..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.cpp +++ /dev/null @@ -1,36 +0,0 @@ -// $Id$ - -// local headers -#include "Stock_PriorityMapping.h" - -// TAO headers -#include "tao/RTCORBA/Priority_Mapping_Manager.h" - -// -// Stock_PriorityMapping -// -Stock_PriorityMapping::Stock_PriorityMapping (void) - : TAO_Continuous_Priority_Mapping (5) -{ -} - -// -// ~Stock_PriorityMapping -// -Stock_PriorityMapping::~Stock_PriorityMapping (void) -{ -} - -// -// register_mapping -// -void Stock_PriorityMapping::register_mapping (CORBA::ORB_ptr orb) -{ - // Get the PriorityMappingManager. - CORBA::Object_var obj = orb->resolve_initial_references ("PriorityMappingManager"); - TAO_Priority_Mapping_Manager_var manager = TAO_Priority_Mapping_Manager::_narrow (obj); - - // Create an instance of my mapping and install it. - RTCORBA::PriorityMapping *my_mapping = new Stock_PriorityMapping; - manager->mapping (my_mapping); -} diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.h b/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.h deleted file mode 100644 index 7e5ee7b8bd1..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/Stock_PriorityMapping.h +++ /dev/null @@ -1,48 +0,0 @@ -// $Id$ - -/** - * @file Stock_PriorityMapping.h - * @author Shanshan Jiang <shanshan.jiang@vanderbilt.edu> - */ - -#ifndef STOCK_PRIORITYMAPPING_ -#define STOCK_PRIORITYMAPPING_ - -// TAO headers -#include "tao/RTCORBA/Continuous_Priority_Mapping.h" - -/** - * @class Stock_PriorityMapping - * @brief Defines the runtime priority mappings used in this application. - * - * This class defines the priority mappings used by the stock objects. We - * are using the TAO_Continuous_Priority_Mapping class as a base class - * because it provides the necessary mappings of CORBA::Priority values - * to CORBA::NativePriority values when there is only a limited number - * of CORBA::Priority values. - */ -class Stock_PriorityMapping : - public TAO_Continuous_Priority_Mapping -{ -public: - /// Default constructor. - Stock_PriorityMapping (void); - - /// Default destructor. - virtual ~Stock_PriorityMapping (void); - - /// Stock priorities. - enum Priority - { - VERY_LOW = 0, - LOW = 1, - MEDIUM = 2, - HIGH = 3, - VERY_HIGH = 4 - }; - - /// Register mapping. - static void register_mapping (CORBA::ORB_ptr orb); -}; - -#endif // !defined STOCK_PRIORITYMAPPING_ diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/broker.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/broker.html deleted file mode 100644 index dc7e11fc538..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/broker.html +++ /dev/null @@ -1,150 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Stock Broker implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Stock Broker implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<h3>Implementation of StockBrokerHome interface</h3> - -This interface is used to create StockBroker objects. <P> -The Stock_StockBrokerHome_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockBrokerHome class. <P> - -<h4>Implementing the Constructor</h4> - -The main steps of this function are described as follows: <P> - -<li>Register the necessary factories and mappings with the specified orb.</li> - -<PRE> - Stock::StockName_init *stockname_factory = new Stock::StockName_init; - orb->register_value_factory (stockname_factory->tao_repository_id (), - stockname_factory - ACE_ENV_ARG_PARAMETER); - - Stock::Cookie_init *cookie_factory = new Stock::Cookie_init; - orb->register_value_factory (cookie_factory->tao_repository_id (), - cookie_factory - ACE_ENV_ARG_PARAMETER); - - Stock_PriorityMapping::register_mapping (orb); -</PRE> - -<li>Create a new instance of the StockBroker object. And because the broker has nothing to do with the RTCORBA -mechanisms, we can activate it under the default POA. The "stock_name" and "priority" are in the arguments of -the Constructor.</li> - -<PRE> - broker_ = new Stock_StockBroker_i (orb, stock_name, priority); - PortableServer::ServantBase_var broker_owner_transfer = broker_; - _default_POA ()->activate_object (broker_); -</PRE> - -<h4>Implementing the create () member function</h4> - -Return the StockBroker object created by the Constructor. - -<PRE> - return Stock::StockBroker::_duplicate (broker_->_this ()); -</PRE> - -<hr><h3>Implementation of StockBroker interface</h3> - -This interface is used for Stock Broker client. <P> -The Stock_StockBroker_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockBroker class. <P> - -<h4>Implementing the Constructor</h4> - -<PRE> - Stock_StockBroker_i (CORBA::ORB_ptr orb, const char *stock_name, RTCORBA::Priority priority) - : quoter_ (Stock::StockQuoter::_nil()), consumer_ (0) -</PRE> - -The "quoter_" and "consumer_" are two private members of the Stock_StockBroker_i class. They stand -for the StockQuoter object that is used to get detailed stock information and the StockNameConsumer -object that is used to get notification of updates. <P> - -The main steps of this function are described as follows: <P> - -<li>Get a reference to the RTORB.</li> - -<li>Initialize a CORBA::PolicyList object.</li> - -<li>Create a SERVER_DECLARED priority model policy and add it into the former CORBA::PolicyList object.</li> - -<li>Create a child POA using the former CORBA::PolicyList and narrow it to RTPOA.</li> - -<li>Create a new instance of the StockNameConsumer object with the specified name and activate it -under the former RTPOA with the specified priority.</li> - -<PRE> - CORBA::Object_var obj = orb->resolve_initial_references ("RTORB"); - RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (obj.in ()); - - CORBA::PolicyList consumer_policies (1); - consumer_policies.length (1); - - consumer_policies[0] = rt_orb->create_priority_model_policy (RTCORBA::SERVER_DECLARED, - Stock_PriorityMapping::MEDIUM); - - PortableServer::POA_var poa = this->_default_POA()->create_POA ( - "StockNameConsumer_POA", PortableServer::POAManager::_nil (), consumer_policies); - - RTPortableServer::POA_var rt_poa = RTPortableServer::POA::_narrow (poa); - - consumer_ = new Stock_StockNameConsumer_i (_this (), stock_name); - PortableServer::ServantBase_var nameconsumer_owner_transfer = consumer_; - rt_poa->activate_object_with_priority (consumer_, priority); -</PRE> - -<h4>Implementing the get_consumer_notifier () member function</h4> - -Return the StockNameConsumer object created by the Constructor. - -<PRE> - return Stock::StockNameConsumer::_duplicate (consumer_->_this ()); -</PRE> - -<h4>Implementing the connect_quoter_info () member function</h4> - -Duplicate a StockQuoter object using the StockQuoter object reference "c" in the argument. - -<PRE> - quoter_ = Stock::StockQuoter::_duplicate (c); -</PRE> - -<h4>Implementing the disconnect_quoter_info () member function</h4> - -Destroy the StockQuoter object and return it. - -<PRE> - Stock::StockQuoter_var old_quoter = quoter_; - quoter_ = Stock::StockQuoter::_nil(); - return old_quoter._retn (); -</PRE> - -<h4>Implementing the get_connection_quoter_info () member function</h4> - -Return the StockQuoter object. - -<PRE> - return Stock::StockQuoter::_duplicate (quoter_); -</PRE> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/common.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/common.html deleted file mode 100644 index d6731600142..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/common.html +++ /dev/null @@ -1,76 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Common implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Common implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<h3>Implementation of StockNameConsumer interface</h3> - -This interface is used as a callback interface used by the Stock Distributor server to -notify Stock Broker clients of updates. <P> -The Stock_StockNameConsumer_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockNameConsumer class. <P> - -<h4>Implementing the Constructor</h4> - -<PRE> - Stock_StockNameConsumer_i (Stock::StockBroker_ptr parent, const char *stock_name) - : parent_ (Stock::StockBroker::_duplicate (parent)), - stock_name_ (CORBA::string_dup (stock_name)) -</PRE> - -The "parent_" and "stock_name_" are two private members of the Stock_StockNameConsumer_i class. They stand for the -parent broker of the StockNameConsumer object and the name of the stock to listen to respectively. <P> - -<h4>Implementing the push_StockName () member function</h4> - -The main steps of this function are described as follows: <P> - -<li>Verify the "parent_" private member is valid.</li> <P> - -<li>Verify this is the correct stock: Check if the StockName parameter in this function is equal to -the "stock_name_" private member. If this is not the stock that we are interested in then we need to stop -and return.</li> <P> - -<li>Get the quoter for the connection.</li> - -<PRE> - Stock::StockQuoter_var quoter = parent_->get_connection_quoter_info (); -</PRE> - -<li>Request more information from the quoter.</li> - -<PRE> - Stock::StockInfo_var stock_info = quoter->get_stock_info (the_stockname->name()); -</PRE> - -<hr><h3>Implementation of StockQuoter interface</h3> - -This interface is used by brokers to get detailed stock information. <P> -The Stock_StockQuoter_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockQuoter class. <P> - -<h4>Implementing the get_stock_info () member function</h4> - -<PRE> - Stock::StockInfo *stock = STOCK_DATABASE->get_stock_info (stock_name); -</PRE> - -Call the get_stock_info () function of Stock_Database instance. - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/database.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/database.html deleted file mode 100644 index a8727566a9b..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/database.html +++ /dev/null @@ -1,68 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Stock Database definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Stock Database definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> The Stock Database class is used to install, update and publish the information of all the stocks. It uses the -singleton design pattern.<P> - -<PRE> - typedef ACE_Singleton<Stock_Database, ACE_Thread_Mutex> Stock_Database_Singleton; - #define STOCK_DATABASE Stock_Database_Singleton::instance() -</PRE> - -ACE_Singleton simply ensures that we create one single instance of the Stock_Database class at runtime, -even if multiple threads all try to create one at the same time. - -<h3>Implementing the Constructor</h3> - -The main steps of this function are described as follows: <P> - -<li>Create an array of stock names.</li> <P> - -<li>Create a StockInfo object for each stock with the corresponding stock name and initialize -its high, low and last values randomly.</li> <P> - -<li>Insert the StockInfo objects into stock map, using the stock name as the key.</li> <P> - -<hr><h3>Implementing the get_stock_info () function</h3> - -The main steps of this function are described as follows: <P> - -<li>Locate the stock in the stock database with the same stock name given in the argument.</li> <P> - -<li>Create a StockInfo object of the former stock and return it.</li> <P> - -<hr><h3>Implementing the publish_stock_info () function</h3> - -This function is called by the Stock Distributor server's thread function to notify the Stock Broker client -the state change of the stock it interested in. <P> -For each stock in the stock database, do the following steps: <P> - -<li>Initialze the StockName object with the name of the stock.</li> <P> - -<li>Call the push_StockName () function of StockNameConsumer object (given in the argument), -using the former StockName object.</li> <P> - -<hr><h3>Implementing the svc () function</h3> - -This function will be run when the stock database is started. This function is used to -calculate the new high, low and last values of each stock in the stock database. <P> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/distributor.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/distributor.html deleted file mode 100644 index 510f7403f84..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/distributor.html +++ /dev/null @@ -1,186 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Stock Distributor implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Stock Distributor implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<h3>Implementation of StockDistributorHome interface</h3> - -This interface is used to create StockDistributor objects. <P> -The Stock_StockDistributorHome_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockDistributorHome class. <P> - -<h4>Implementing the Constructor</h4> - -The main steps of this function are described as follows: <P> - -<li>Register the necessary factories and mappings with the specified orb.</li> - -<PRE> - Stock::StockName_init *stockname_factory = new Stock::StockName_init; - orb->register_value_factory (stockname_factory->tao_repository_id (), - stockname_factory - ACE_ENV_ARG_PARAMETER); - - Stock::Cookie_init *cookie_factory = new Stock::Cookie_init; - orb->register_value_factory (cookie_factory->tao_repository_id (), - cookie_factory - ACE_ENV_ARG_PARAMETER); - - Stock_PriorityMapping::register_mapping (orb); -</PRE> - -<li>Initialize the Stock database.</li> - -<PRE> - STOCK_DATABASE->activate (THR_NEW_LWP | THR_JOINABLE, 1); -</PRE> - -<li>Create a CORBA::PolicyList for the child POA.</li> - -This step include several sub-stpes: -<OL> -<li> Get a reference to the RTORB.</li> -<li> Initialize a CORBA::PolicyList object.</li> -<li> Create a CLIENT_PROPOGATED priority model policy and add it into the former CORBA::PolicyList object.</li> -<li> Create a threadpool with lanes for the distributor. Since the brokers have various priorities, -create a lane for each priority.</li> -<li> Create a thread pool policy using the former threadpool and add it into the former CORBA::PolicyList object.</li> -<li> Create a child POA using the former CORBA::PolicyList and narrow it to RTPOA.</li> -</OL> - -<PRE> - CORBA::Object_var obj = orb->resolve_initial_references ("RTORB"); - RTCORBA::RTORB_var rt_orb = RTCORBA::RTORB::_narrow (obj.in ()); - - CORBA::PolicyList stock_distributor_policies (2); - stock_distributor_policies.length (2); - - stock_distributor_policies[0] = rt_orb->create_priority_model_policy (RTCORBA::CLIENT_PROPAGATED, - Stock_PriorityMapping::MEDIUM); - - RTCORBA::ThreadpoolLanes lanes (5); - lanes.length (5); - for (CORBA::ULong i = 0; i < lanes.length (); i ++) - { - lanes[i].lane_priority = i; - lanes[i].static_threads = 5; - lanes[i].dynamic_threads = 2; - } - RTCORBA::ThreadpoolId threadpool_id = rt_orb->create_threadpool_with_lanes (1024 * 10, lanes, false, false, 0, 0); - stock_distributor_policies[1] = rt_orb->create_threadpool_policy (threadpool_id); - - PortableServer::POA_var poa = _default_POA()->create_POA ("StockDistributor_POA", - PortableServer::POAManager::_nil (), - stock_distributor_policies); - - RTPortableServer::POA_var rt_poa = RTPortableServer::POA::_narrow (poa); -</PRE> - -<li>Create a new instance of the StockDistributor object using the former CORBA::PolicyList. -Then activate it under the former RTPOA. </li> - -<PRE> - distributor_ = new Stock_StockDistributor_i (orb, stock_distributor_policies); - PortableServer::ServantBase_var distributor_owner_transfer = distributor_; - rt_poa->activate_object (distributor_); -</PRE> - -<h4>Implementing the create () member function</h4> - -Return the StockDistributor object created by the Constructor. - -<PRE> - return Stock::StockDistributor::_duplicate (distributor_->_this ()); -</PRE> - -<hr><h3>Implementation of StockDistributor interface</h3> - -This interface is used for Stock Distributor server. <P> -The Stock_StockDistributor_i class is generated automatically by the IDL compiler (using the -GI flag), -which is a subclass of POA_Stock::StockDistributor class. <P> - -<h4>Implementing the Constructor</h4> - -<PRE> - Stock_StockDistributor_i (CORBA::ORB_ptr orb, CORBA::PolicyList &policy_list) - : rate_(3000), active_ (false), quoter_ (0) -</PRE> - -The "rate_", "active_" and "quoter_" are three private members of the Stock_StockDistributor_i class. They stand -for the notification rate and the active state of the StockDistributor object and the StockQuoter object created by -the StockDistributor object. <P> - -The main steps of this function are described as follows: <P> - -<li>Create a child POA with the policies in the argument and narrow it to RTPOA.</li> <P> - -<li>Create a new instance of the StockQuoter object and activate it under the former RTPOA.</li> <P> - -<li>Seed the random number generator.</li> <P> - -<h4>Implementing the subscribe_notifier () member function</h4> - -The main steps of this function are described as follows: <P> - -<li>Get the thread mutex of the subscriber map.</li> <P> - -<li>Generate an unique id and use it to create a new Cookie object.</li> <P> - -<li>Insert the Cookie object as well as the StockNameConsumer object and its priority into the -StockDistributor object's subscriber map.</li> <P> - -<li>Return the Cookie object.</li> <P> - -<h4>Implementing the unsubscribe_notifier () member function</h4> - -The main steps of this function are described as follows: <P> - -<li>Get the thread mutex of the subscriber map.</li> <P> - -<li>Search for the Cookie object in the argument in the StockDistributor object's subscriber map.</li> <P> - -<li>Erase the Cookie object from the StockDistributor object's subscribers' map.</li> <P> - -<li>Return the StockNameConsumer object related to the erased Cookie object.</li> <P> - -<h4>Implementing the provide_quoter_info () member function</h4> - -Return the StockQuoter object created by the Constructor. - -<PRE> - return Stock::StockQuoter::_duplicate (quoter_->_this ()); -</PRE> - -<h4>Implementing the start () member function</h4> - -Set the active state of the StockDistributor object to true and create a thread to publish the stock information -to the Stock Broker clients. <P> - -The main steps of this thread function are described as follows: <P> -While the state of the StockDistributor object is active, continue the following looping: -<OL> -<li> Publish the stock information to all the StockNameConsumer objects.</li> -<li> Sleep for the specified amount of seconds given in the notification rate.</li> -</OL> - -<h4>Implementing the stop () member function</h4> - -Set the active state of StockDistributor object to false. - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/idl.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/idl.html deleted file mode 100644 index d4ec3788432..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/idl.html +++ /dev/null @@ -1,216 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>IDL Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>IDL Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> Note: All the IDL definitions are included in the Stock module: -<PRE> -// IDL schema definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service. -module Stock -{ - ... -}; -</PRE> - -<h3>Common</h3> - -This IDL file (Common.idl) contains all the exception(s), struct(s), value type(s) and -common interface(s) used by the Stock Quoter Publisher/Subscriber Real-time CORBA Service. The -generated lib of this idl file will be linked by all the other projects in the system. <P> - -<li><h4>Defining the IDL exception</h4></li> - -<PRE> -exception Invalid_Stock {}; -</PRE> - -This exception is used when the needed stock does not exist in the stock database. <P> - -<li><h4>Defining the IDL struct</h4></li> - -<PRE> -struct StockInfo -{ - string name; - long high; - long low; - long last; -}; -</PRE> - -This struct contains the information about a stock. The items in this struct denote the -name, highest value, lowest value and last value of the stock respectively. <P> - -<li><h4>Defining the IDL value types</h4></li> - -Unlike CORBA Objects (which are passed by reference), instances of CORBA valuetype are -always passed by value. Like CORBA structs, they can contain state in the form of fields. -Unlike structs, however, they can have user-defined operations and support inheritance. <P> - -<PRE> -valuetype StockName -{ - // Name of the stock. - public string name; -}; -</PRE> - -This value type is used in the communication between stock distributor server and stock -broker client to handle the callback from distributor server whenever the value of a stock -the stock broker client interested in changes. <P> - -<PRE> -valuetype Cookie -{ - public string cookie_id; -}; -</PRE> - -This value type is used to record the subscription relationship between stock distributor -server and stock broker client. It can also be used to unsubscribe the stock broker clien -from the stock distributor server. <P> - -<li><h4>Defining the common IDL interfaces</h4></li> - -<PRE> -interface Trigger -{ - void start (); - void stop (); -} -</PRE> - -This interface is inherited by the stock distributor interface because it need to be run as -a daemon that can be started and stopped by a system administrator. <P> - -<PRE> -interface StockNameConsumer -{ - // Push an event to the consumer. - void push_StockName (in StockName the_stockname); -}; -</PRE> - -This interface is used as a callback interface used by the distributor to notify brokers of updates. <P> - -<PRE> -interface StockQuoter -{ - StockInfo get_stock_info (in string stock_name) raises Invalid_Stock; -}; -</PRE> - -This interface is used by brokers to get detailed stock information. <P> - -<hr><h3>Broker</h3> - -This IDL file (Broker.idl) contains IDL definitions for the Stock Broker in the -Publish/Subscribe Real-time CORBA Stock Quoter Service. <P> - -<li><h4>Defining the IDL interfaces</h4></li> - -<PRE> -interface StockBroker -{ - // Factory operation to return StockNameConsumer object reference. - StockNameConsumer get_consumer_notifier (); - - // Event sink operations to perform connectivity. - void connect_quoter_info (in StockQuoter c); - StockQuoter disconnect_quoter_info (); - StockQuoter get_connection_quoter_info (); -}; -</PRE> - -This is the interface definition for Stock Broker client. <P> -The get_consumer_notifier() operation returns an object reference to the StockNameConsumer interface -shown earlier. When the stock quoter system is initialized, this factory operation will be used to -return the StockNameConsumer object that belongs to the Stock Broker object. <P> -These connect_quoter_info(), disconnect_quoter_info(), and get_connection_quoter_info() operations -are used to connect the StockBroker with the StockQuoter object that's provided by the StockDistributor -interface describe next. <P> - -<PRE> -interface StockBrokerHome -{ - StockBroker create (); -}; -</PRE> - -This is the interface definition for Stock Broker Home. -This factory reduces the bookkeeping that CORBA applications must do to create and manage their objects. <P> - -<hr><h3>Distributor</h3> - -This IDL file (Distributor.idl) contains IDL definitions for the Stock Distributor in the -Publish/Subscribe Real-time CORBA Stock Quoter Service. <P> - -<li><h4>Defining the IDL interfaces</h4></li> - -<PRE> -interface StockDistributor : Trigger -{ - // Event source operations to establish connectivity. - Cookie subscribe_notifier (in Stock::StockNameConsumer c); - Stock::StockNameConsumer unsubscribe_notifier (in Cookie ck); - - // Factory operation to return StockQuoter object reference. - StockQuoter provide_quoter_info (); - - attribute long notification_rate; -}; -</PRE> - -This is the interface definition for Stock Distributor server. <P> -The subscribe_notifier() and unsubscribe_notifier() operations are to subscribe/unsubscribe StockBroker -objects that consume the StockName events published by the StockDistributor. <P> -The provide_quoter_info() factory operation returns object references that StockBroker consumers can -use to obtain more information about a particular stock. <P> -The notification_rate attribute stands for the notification frequency that the Stock Distributor server used -to communicate with the Stock Broker client. <P> - -<PRE> -interface StockBrokerHome -{ - StockBroker create (); -}; -</PRE> - -This is the interface definition for Stock Distributor Home. -This factory reduces the bookkeeping that CORBA applications must do to create and manage their objects. <P> - -<hr><h3>Compiling the IDL files and generating the stub, skeleton and implementation files</h3> - -To generate the helper files you need to invoke the IDL compiler, like this: <P> - -<PRE> -tao_idl Common.idl -tao_idl -GI Broker.idl -tao_idl -GI Distributor.idl -</PRE> - -The "-GI" flag is used to generate the frames for the implmentation files (*I.h and *I.cpp). You can -change the names of the files into *_i.h and *_i.cpp because the next time you run the IDL compiler, -these implemention files (*I.h and *I.cpp) will be overwritten by the newly generated implemention files -(with the same file names). <P> - -However, you don't need to do this often, in fact you rarely have to do it at all because this can be handled -by <A HREF="mpc.html">writing and using a mpc file</A>. <P> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/index.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/index.html deleted file mode 100644 index 54c74b9744c..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/index.html +++ /dev/null @@ -1,50 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> This tutorial introduces how to implement a Stock Quoter Publisher/Subscriber Real-time CORBA Service. <P> - -<OL> -<LI><A HREF="idl.html"> -IDL Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="mpc.html"> -MPC Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="run.html"> -Execution programs for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="database.html"> -Stock Database definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="prioritymapping.html"> -Stock Priority Mapping definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="common.html"> -Common implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="broker.html"> -Stock Broker implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> - -<LI><A HREF="distributor.html"> -Stock Distributor implementation for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</A> -</OL> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/mpc.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/mpc.html deleted file mode 100644 index 1ab5e2fd99e..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/mpc.html +++ /dev/null @@ -1,104 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>MPC Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>MPC Definitions for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> Note: For more information about how to writing and using a mpc file, please refer to -<A HREF="http://download.ociweb.com/MPC/MakeProjectCreator.pdf">here</A>. <P> - -This MPC file (StockQuoter.mpc) contains all the projects used by the Stock Quoter Publisher/Subscriber -Real-time CORBA Service. <P> - -<li><h4>Defining the Distributor project</h4></li> - -<PRE> -project(*Distributor): rt_server, stl { - libs += TAO_Valuetype - - Source_Files { - Common_i.cpp - Distributor.cpp - Distributor_i.cpp - Stock_Database.cpp - Stock_PriorityMapping.cpp - } - - Header_Files { - Common_i.h - Distributor_i.h - Stock_Database.h - Stock_PriorityMapping.h - } -} -</PRE> - -This project is used as a Stock Distributor server which monitors a real-time stock feed database -and whenever the value of a stock changes, it publishes an event to interested stock brokers. It can -alse provide the detailed information about a stock required by a Stock Broker client.<P> - -<li><h4>Defining the Broker project</h4></li> - -<PRE> -project(*Broker): rt_server, stl { - libs += TAO_Valuetype - - Source_Files { - Common_i.cpp - Broker.cpp - Broker_i.cpp - Stock_Database.cpp - Stock_PriorityMapping.cpp - } - - Header_Files { - Common_i.h - Broker_i.h - Stock_Database.h - Stock_PriorityMapping.h - } -} -</PRE> - -This project is used as a Stock Broker client which subscribes with a Stock Distributor server -to receive notification events whenever a stock value of interest to them changes. It can -alse receive the detailed information about a stock by invoke a Stock Distributor server.<P> - -<li><h4>Defining the Admin project</h4></li> - -<PRE> -project(*Admin): rt_client, stl { - libs += TAO_Valuetype - - Idl_Files { - } - - after = *Distributor *Broker - - Source_Files { - CommonC.cpp - DistributorC.cpp - Admin.cpp - } -} -</PRE> - -This project is used as a system administrator to start, stop the Stock Distributor server -and change the notification rate of it. <P> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/prioritymapping.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/prioritymapping.html deleted file mode 100644 index b43a556f2ca..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/prioritymapping.html +++ /dev/null @@ -1,57 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Stock Priority Mapping definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Stock Priority Mapping definition for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> The Stock Database class defines the priority mappings used by the stock objects.<P> - -<h3>Defining the Priority enum</h3> - -We define five levels of prioriies as follows: <P> - -<PRE> - enum Priority - { - VERY_LOW = 0, - LOW = 1, - MEDIUM = 2, - HIGH = 3, - VERY_HIGH = 4 - }; -</PRE> - -<hr><h3>Implementing the register_mapping () function</h3> - -The main steps of this function are described as follows: <P> - -<li>Get the Priority Mapping Manager.</li> <P> - -<PRE> - CORBA::Object_var obj = orb->resolve_initial_references ("PriorityMappingManager"); - TAO_Priority_Mapping_Manager_var manager = TAO_Priority_Mapping_Manager::_narrow (obj); -</PRE> - -<li>Create an instance of Stock Priority Mapping object and install it.</li> <P> - -<PRE> - RTCORBA::PriorityMapping *my_mapping = new Stock_PriorityMapping; - manager->mapping (my_mapping); -</PRE> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RTCORBA/docs/run.html b/TAO/docs/tutorials/Quoter/RTCORBA/docs/run.html deleted file mode 100644 index 42b11f9adb4..00000000000 --- a/TAO/docs/tutorials/Quoter/RTCORBA/docs/run.html +++ /dev/null @@ -1,117 +0,0 @@ -<!-- $Id$ --> - -<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> -<html> -<head> - <title>Execution programs for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</title> -</head> - -<body - text = "#000000" - link = "#000fff" - vLink= "#ff0f0f" - aLink = "#0000ff" - bgColor = "#ffffff"> - -<hr><h2>Execution programs for the Stock Quoter Publisher/Subscriber Real-time CORBA Service</h2><hr> - -<P> There are three execution programs (*.cpp files that have the main () functions) in this system: -Distributor, Broker and Admin. Each of them belongs to the corresponding project defined in the -StockQuoter.mpc file. <P> - -<h3>Building the Distributor program</h3> - -The Distributor.cpp file is used for this purpose. It contains the main () function and is used to generated the -Distributor execution file. The main steps in this file are described as follows: <P> - -<li>Initalize the ORB.</li> <P> - -<li>Get the RootPOA.</li> <P> - -<li>Activate the POAManager.</li> <P> - -<li>Create a Distributor factory object, which will then create a Distributor object.</li> -<PRE> - Stock_StockDistributorHome_i stock_distributor_home (orb); - Stock::StockDistributor_var stock_distributor = stock_distributor_home.create (); -</PRE> - -<li>Write the object reference for the Distributor object to a file so other projects -can read it when they are bootstrapping.</li> <P> - -<li>Set the rate of the Distributor object.</li> <P> - -<li>Enter into the event looping.</li> <P> - -<hr><h3>Building the Broker program</h3> - -The Broker.cpp file is used for this purpose. It contains the main () function and is used to generated the -Broker execution file. The main steps in this file are described as follows: <P> - -<li>Initalize the ORB.</li> <P> - -<li>Get the RootPOA.</li> <P> - -<li>Activate the POAManager.</li> <P> - -<li>Extract the command-line arguments, which give the stock name and the priority of the Broker objec -(actually, the priority of the StockNameConsumer object that the Broker object contains).</li> <P> - -<li>Create a Broker factory object, which will then create a Broker object.</li> -<PRE> - Stock_StockBrokerHome_i stock_broker_home (orb, stock_name, priority); - Stock::StockBroker_var stock_broker = stock_broker_home.create (); -</PRE> - -<li>Read and destringify the Distributor object's IOR and narrow it to a Distributor object reference.</li> <P> - -<li>Connect the Quoter object to the Broker object.</li> -<PRE> - Stock::StockQuoter_var stock_quoter = stock_distributor->provide_quoter_info (); - stock_broker->connect_quoter_info (stock_quoter); -</PRE> - -<li>Create a new consumer; initialize it; subscribe it to the notification service.</li> -<PRE> - Stock::StockNameConsumer_var consumer = stock_broker->get_consumer_notifier (); - Stock::Cookie *cookie = stock_distributor->subscribe_notifier (consumer, priority); -</PRE> - -<li>Enter into the event looping.</li> <P> - -<hr><h3>Building the Admin program</h3> - -The Admin.cpp file is used for this purpose. It contains the main () function and is used to generated -Admin execution file. The main steps in this file are described as follows: <P> - -<li>Initalize the ORB.</li> <P> - -<li>Read and destringify the Distributor object's IOR and narrow it to a Distributor object reference.</li> <P> - -<li>Call the operations of StockDistributor interface:</li> -<PRE> - start: Start the distributor. - stop: Stop the distributor. - rate: Change the notification rate of the distributor. -</PRE> - -<hr><h3>Running the Stock Quoter Service</h3> - -When executing the programs, they should be executed in the following order: - -<PRE> - Distributor - Broker - Admin -</PRE> - -You can run more than one Broker program at the same time. Each of them should be given different stock name -that it is interested in. All the stock information is installed in the <A HREF="database.html">Stock Database</A>. -The number of stocks can easily be extended by adding items to the stock_names array of -the Stock Database constuctor. <P> - -<hr><b>Email: </b><a href="mailto:"</a<ADDRESS>shanshan.jiang@vanderbilt.edu</ADDRESS> - -</body> - -</html> diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Makefile.am b/TAO/docs/tutorials/Quoter/RT_Event_Service/Makefile.am deleted file mode 100644 index 5fcd5c51cc1..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Makefile.am +++ /dev/null @@ -1,145 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_IDL = ACE_ROOT=$(ACE_ROOT) TAO_ROOT=$(TAO_ROOT) $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDL_DEP = $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDLFLAGS = -Ge 1 -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -I$(srcdir) -g $(ACE_BUILDDIR)/apps/gperf/src/gperf -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_RT_Event_Service_Idl.am - -BUILT_SOURCES = \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -CLEANFILES = \ - Quoter-stamp \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl - -QuoterC.cpp QuoterC.h QuoterC.inl QuoterS.cpp QuoterS.h QuoterS.inl: Quoter-stamp - -Quoter-stamp: $(srcdir)/Quoter.idl $(TAO_IDL_DEP) - $(TAO_IDL) $(TAO_IDLFLAGS) $(srcdir)/Quoter.idl - @touch $@ - - -noinst_HEADERS = \ - Quoter.idl - -## Makefile.Quoter_RT_Event_Service_Client.am - -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS -if !BUILD_ACE_FOR_TAO -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs - -client_SOURCES = \ - QuoterC.cpp \ - Stock_Consumer.cpp \ - client.cpp \ - Stock_Consumer.h - -client_LDADD = \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent_Serv.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent_Skel.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_Svc_Utils.la \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif !BUILD_ACE_FOR_TAO -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING - -## Makefile.Quoter_RT_Event_Service_Server.am - -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS -if !BUILD_ACE_FOR_TAO -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs - -server_SOURCES = \ - QuoterC.cpp \ - QuoterS.cpp \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent_Serv.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent_Skel.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_Svc_Utils.la \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif !BUILD_ACE_FOR_TAO -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter.idl b/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter.idl deleted file mode 100644 index 34d81177658..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter.idl +++ /dev/null @@ -1,54 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; - - struct Event { - double price; - string symbol; - string full_name; - }; - - interface Modify_Stock : Stock { - void set_price (in double new_price); - }; -}; diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter_RT_Event_Service.mpc b/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter_RT_Event_Service.mpc deleted file mode 100644 index 15cb6b2be5b..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Quoter_RT_Event_Service.mpc +++ /dev/null @@ -1,33 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*idl): taoidldefaults, anytypecode { - IDL_Files { - Quoter.idl - } - custom_only = 1 -} - -project(*client) : orbsvcsexe, portableserver, rtevent_serv, naming, minimum_corba, exceptions { - after += *idl - source_files { - client.cpp - Stock_Consumer.cpp - QuoterC.cpp - } - IDL_Files { - } -} - -project(*server) : orbsvcsexe, portableserver, rtevent_serv, naming, minimum_corba, exceptions { - after += *idl - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - QuoterS.cpp - QuoterC.cpp - } - IDL_Files { - } -} diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.cpp b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.cpp deleted file mode 100644 index 395e31bf6b0..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.cpp +++ /dev/null @@ -1,60 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Consumer.h" -#include "QuoterC.h" -#include "ace/streams.h" - -Stock_Consumer::Stock_Consumer () -{ -} - -void -Stock_Consumer::connect (RtecEventChannelAdmin::EventChannel_ptr event_channel, - const RtecEventChannelAdmin::ConsumerQOS &subscriptions) -{ - RtecEventChannelAdmin::ConsumerAdmin_var consumer_admin = - event_channel->for_consumers (); - - this->supplier_proxy_ = - consumer_admin->obtain_push_supplier (); - - RtecEventComm::PushConsumer_var myself = this->_this (); - this->supplier_proxy_->connect_push_consumer (myself.in (), - subscriptions); -} - -void -Stock_Consumer::disconnect () -{ - // Do not receive any more events... - this->supplier_proxy_->disconnect_push_supplier (); -} - -void -Stock_Consumer::push (const RtecEventComm::EventSet &data - ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - for (CORBA::ULong i = 0; i != data.length (); ++i) { - const RtecEventComm::Event &e = data[i]; - - Quoter::Event *event; - if ((e.data.any_value >>= event) == 0) - continue; // Invalid event - - cout << "The new price for one stock in \"" - << event->full_name.in () - << "\" (" << event->symbol.in () - << ") is " << event->price << endl; - } -} - -void -Stock_Consumer::disconnect_push_consumer (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - this->supplier_proxy_ = - RtecEventChannelAdmin::ProxyPushSupplier::_nil (); -} diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.h b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.h deleted file mode 100644 index a82044836bc..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Consumer.h +++ /dev/null @@ -1,33 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIALS_QUOTER_RT_EVENT_SERVICE_STOCK_CONSUMER_H -#define TAO_TUTORIALS_QUOTER_RT_EVENT_SERVICE_STOCK_CONSUMER_H - -#include <orbsvcs/RtecEventCommS.h> -#include <orbsvcs/RtecEventChannelAdminC.h> - -class Stock_Consumer : public POA_RtecEventComm::PushConsumer { -public: - Stock_Consumer (); - - void connect (RtecEventChannelAdmin::EventChannel_ptr event_channel, - const RtecEventChannelAdmin::ConsumerQOS &subscriptions); - // Connect to the event channel, using <consumer_admin> and - // <subscriptions> - - void disconnect (); - // Disconnect from the event channel. - - void push (const RtecEventComm::EventSet& data ACE_ENV_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - void disconnect_push_consumer (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - -private: - RtecEventChannelAdmin::ProxyPushSupplier_var supplier_proxy_; - // The supplier proxy. -}; - -#endif /* TAO_TUTORIALS_QUOTER_RT_EVENT_SERVICE_STOCK_CONSUMER_H */ diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.cpp deleted file mode 100644 index 206338a5159..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.cpp +++ /dev/null @@ -1,90 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "Stock_i.h" -#include "ace/streams.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - try { - CORBA::Object_var tmp = - this->stock_factory_poa_->id_to_reference (oid.in ()); - return Quoter::Stock::_narrow (tmp.in ()); - } - catch (PortableServer::POA::ObjectNotActive &) { - throw Quoter::Invalid_Stock_Symbol (); - } -} - -void -Quoter_Stock_Factory_i::destroy_stock_objects () -{ - if (!CORBA::is_nil (this->stock_factory_poa_.in ())) - return; - - this->stock_factory_poa_->destroy (1, 1); - this->stock_factory_poa_ = PortableServer::POA::_nil (); -} - -void -Quoter_Stock_Factory_i::load_stock_objects ( - PortableServer::POA_ptr poa, - PortableServer::POAManager_ptr poa_manager, - RtecEventChannelAdmin::SupplierAdmin_ptr supplier_admin) -{ - if (!CORBA::is_nil (this->stock_factory_poa_.in ())) - return; - - CORBA::PolicyList policies (2); - policies.length (2); - - policies[0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - policies[1] = - poa->create_implicit_activation_policy (PortableServer::NO_IMPLICIT_ACTIVATION); - - this->stock_factory_poa_ = - poa->create_POA ("Stock_Factory_POA", - poa_manager, - policies); - - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - while (!cin.eof () && cin.peek () != EOF) { - const int max_symbol_length = 8; - char symbol[max_symbol_length]; - const int max_full_name_length = 64; - char full_name[max_full_name_length]; - double price; - - cin.getline (symbol, max_symbol_length, '\n'); - cin.getline (full_name, max_full_name_length, '\n'); - cin >> price; - cin.ignore (1, '\n'); - - Quoter_Stock_i *stock = - new Quoter_Stock_i (symbol, full_name, price); - - PortableServer::ServantBase_var servant = stock; - - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - this->stock_factory_poa_->activate_object_with_id (oid.in (), - servant.in ()); - stock->connect (supplier_admin); - } -} diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.h deleted file mode 100644 index c30c68e2a69..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_Factory_i.h +++ /dev/null @@ -1,27 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_FACTORY_I_H - -#include "QuoterS.h" -#include <orbsvcs/RtecEventChannelAdminS.h> - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - void load_stock_objects (PortableServer::POA_ptr poa, - PortableServer::POAManager_ptr poa_manager, - RtecEventChannelAdmin::SupplierAdmin_ptr supplier_admin); - void destroy_stock_objects (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - PortableServer::POA_var stock_factory_poa_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_FACTORY_I_H */ diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.cpp b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.cpp deleted file mode 100644 index a042bbcb1ac..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.cpp +++ /dev/null @@ -1,125 +0,0 @@ -// $Id$ - -#include "Stock_i.h" -#include <orbsvcs/Event_Utilities.h> - -///derive a class from the tie template class to release itself by ref_count -class MyTieStock:public POA_RtecEventComm::PushSupplier_tie<Quoter_Stock_i> -{ - friend class Quoter_Stock_i; - ACE_Atomic_Op<TAO_SYNCH_MUTEX, long> ref_count_; - -protected: - MyTieStock (Quoter_Stock_i *tp, - CORBA::Boolean release) - : POA_RtecEventComm::PushSupplier_tie<Quoter_Stock_i> (tp,release), - ref_count_(0) {} - -public: - virtual void _add_ref (ACE_ENV_SINGLE_ARG_DECL) - { - ++this->ref_count_; - } - - virtual void _remove_ref (ACE_ENV_SINGLE_ARG_DECL) - { - CORBA::ULong new_count = --this->ref_count_; - - if (new_count == 0) - delete this; - } -}; - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : supplier_personality_ (*new MyTieStock (this, 0)) -{ - this->data_.symbol = symbol; - this->data_.full_name = full_name; - this->data_.price = price; -} - -Quoter_Stock_i::~Quoter_Stock_i (void) -{ - if (consumer_proxy_.in ()) - consumer_proxy_->disconnect_push_consumer (); -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->data_.symbol.in ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->data_.full_name.in ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->data_.price; -} - -void -Quoter_Stock_i::set_price (CORBA::Double new_price) - throw (CORBA::SystemException) -{ - this->data_.price = new_price; - if (CORBA::is_nil (this->consumer_proxy_.in ())) - return; - - // Create the event - RtecEventComm::EventSet event (1); - event.length (1); - RtecEventComm::Event &e = event[0]; - - // Initialize the header - const char *symbol = this->data_.symbol; - e.header.type = int(symbol[0]) << 24; - e.header.type |= int(symbol[1]) << 16; - e.header.type |= int(symbol[2]) << 8; - e.header.type |= int(symbol[3]); - e.header.source = 1; - - // Initialize the payload - e.data.any_value <<= this->data_; - - // Push it - this->consumer_proxy_->push (event); -} - -void -Quoter_Stock_i::disconnect_push_supplier (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - // Forget about the consumer it is not there anymore - this->consumer_proxy_ = - RtecEventChannelAdmin::ProxyPushConsumer::_nil (); -} - -void -Quoter_Stock_i::connect (RtecEventChannelAdmin::SupplierAdmin_ptr supplier_admin) -{ - this->consumer_proxy_ = - supplier_admin->obtain_push_consumer (); - RtecEventComm::PushSupplier_var supplier = - this->supplier_personality_._this (); - - const char *symbol = this->data_.symbol; - CORBA::ULong type = int(symbol[0]) << 24; - type |= int(symbol[1]) << 16; - type |= int(symbol[2]) << 8; - type |= int(symbol[3]); - - CORBA::ULong source = 1; - ACE_SupplierQOS_Factory publications; - publications.insert (source, type, 0, 1); - - this->consumer_proxy_->connect_push_supplier (supplier.in (), - publications.get_SupplierQOS ()); -} - diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.h b/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.h deleted file mode 100644 index 91b781df2ee..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/Stock_i.h +++ /dev/null @@ -1,39 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_I_H - -#include "QuoterS.h" -#include <orbsvcs/RtecEventCommS.h> -#include <orbsvcs/RtecEventChannelAdminC.h> - -class Quoter_Stock_i - : public virtual POA_Quoter::Modify_Stock -{ -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - ~Quoter_Stock_i (void); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - void set_price (CORBA::Double new_price) throw (CORBA::SystemException); - - void disconnect_push_supplier (ACE_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException); - - void connect (RtecEventChannelAdmin::SupplierAdmin_ptr supplier_admin); - -private: - Quoter::Event data_; - - RtecEventChannelAdmin::ProxyPushConsumer_var consumer_proxy_; - - POA_RtecEventComm::PushSupplier_tie<Quoter_Stock_i> &supplier_personality_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_RT_EVENT_SERVICE_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/client.cpp b/TAO/docs/tutorials/Quoter/RT_Event_Service/client.cpp deleted file mode 100644 index 8bdaab076a8..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/client.cpp +++ /dev/null @@ -1,73 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Consumer.h" -#include <orbsvcs/CosNamingC.h> -#include <orbsvcs/Event_Utilities.h> -#include "ace/streams.h" -#include "ace/OS_NS_string.h" -#include "tao/Exception.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("EventService"); - - CORBA::Object_var ec_object = - naming_context->resolve (name); - - // Now downcast the object reference to the appropriate type - RtecEventChannelAdmin::EventChannel_var ec = - RtecEventChannelAdmin::EventChannel::_narrow (ec_object.in ()); - - ACE_ConsumerQOS_Factory qos; - qos.start_disjunction_group (); - - for (int i = 1; i != argc; ++i) { - if (ACE_OS::strlen (argv[i]) < 4) - continue; - - CORBA::ULong type = - ((int(argv[i][0]) << 24) - | (int(argv[i][1]) << 16) - | (int(argv[i][2]) << 8) - | int(argv[i][3])); - - qos.insert_type (type, 0); - } - - Stock_Consumer stock_consumer_i; - stock_consumer_i.connect (ec.in (), qos.get_ConsumerQOS ()); - - orb->run (); - - stock_consumer_i.disconnect (); - - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &ex) { - cerr << "CORBA exception raised!" << ex << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/index.html b/TAO/docs/tutorials/Quoter/RT_Event_Service/index.html deleted file mode 100644 index d664c603331..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/index.html +++ /dev/null @@ -1,385 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>TAO's RT Event Service</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>TAO's RT Event Service</h3> - - <P>We have already explored how to use - <A HREF="../Event_Service/index.html"> - TAO's COS Event Service - </A> - to receive updated stock prices, - but what if we are not interested in all the stocks? - One approach is to use multiple event channels, each one - carrying different traffic. - For example, - each event channel could carry only a subset of the stocks. - In this section we will explore another solution, - using TAO's real-time Event Service to perform filtering for us. - TAO's real-time Event Service can do many other things, - like preserving priority end-to-end, - using multicast to conserve network resources, - generating timeout and interval events, - and it can collaborate with TAO's Scheduling Service to - analyze the schedulability of your system. - </P> - - <H3>Getting the Price Changes</H3> - - <P>For this example we will use the same data structures that we - used in the previous example, - i.e., the events will be identical. - TAO's RT Event Service can be configured to carry your events in - a type-safe manner, - or you can use custom marshaling to send non-IDL structures in - the event, - but it is easier to use it like the COS Event Service first. - </P> - - <H3>Connecting as a consumer</H3> - - <P>Connecting as a consumer is very similar. Some of the base - classes and signatures change, but it is basically the same - idea: - First let us define the consumer object: - </P> -<PRE> -class Stock_Consumer : public POA_RtecEventComm::PushConsumer { -public: - Stock_Consumer (); - - void push (const RtecEventComm::EventSet& data TAO_ENV_ARG_DECL_NOT_USED); - void disconnect_push_consumer (TAO_ENV_SINGLE_ARG_DECL_NOT_USED); - - // details omitted -}; -</PRE> - <P>Notice that we receive an event set instead of a single event. - The event channel can use this feature to queue multiple events - and push them in a single operation. - First we need to extract the event data from the any: - </P> -<PRE> -void -Stock_Consumer::push (const RtecEventComm::EventSet &data - TAO_ENV_ARG_DECL_NOT_USED) -{ - for (CORBA::ULong i = 0; i != data.length (); ++i) { - RtecEventComm::Event &e = data[i]; - - Quoter::Event *event; - if ((e.data.any_value >>= event) == 0) - continue; // Invalid event -</PRE> - <P>Notice that the events have more structure, - they have a clearly separated header and data, - and the data has more than just an any. - The header is used to provide filtering, and - the event data field can be configured at compile time to carry - whatever IDL structures you want. - Now we can print out the new stock price: - </P> -<PRE> - std::cout << "The new price for one stock in \"" - << event->full_name.in () - << "\" (" << event->symbol.in () - << ") is " << event->price << std::endl; -} -</PRE> - - <P>We also need to implement the disconnect callback: - </P> -<PRE> -void -Stock_Consumer::disconnect_push_consumer (TAO_ENV_SINGLE_ARG_DECL_NOT_USED) -{ - this->supplier_proxy_ = CosEventChannelAdmin::ProxyPushSupplier::_nil (); -} -</PRE> - <P>As with the COS Event Channel we can voluntarily disconnect, - too: - </P> -<PRE> -void -Stock_Consumer::disconnect () -{ - // Do not receive any more events... - this->supplier_proxy_->disconnect_push_supplier (); -} -</PRE> - - <H4>How to connect to the RT event channel</H4> - - <P>Connecting to the RT event channel is very similar to - connecting to the regular event channel. - The only difference is that we must specify the events that we - want to receive. This is described using a fairly complex IDL - structure, but TAO provides a helper class to generate it. - We will assume that we are using the naming service or - something similar to obtain a reference to the event service: - </P> -<PRE> - CORBA::Object_var tmp = naming_context->resolve (name); - RtecEventChannelAdmin::EventChannel_var event_channel = - RtecEventChannelAdmin::EventChannel::_narrow (tmp); -</PRE> - <P>Now we use the event channel to obtain the factory used for - consumer connections: - </P> -<PRE> - RtecEventChannelAdmin::ConsumerAdmin_var consumer_admin = - event_channel->for_consumers (); -</PRE> - <P>And use the factory to obtain a proxy: - </P> -<PRE> -void -Stock_Consumer::connect (RtecEventChannelAdmin::ConsumerAdmin_ptr consumer_admin) -{ - this->supplier_proxy_ = - consumer_admin->obtain_push_supplier (); -</PRE> - <P>Now we list the events that we want to receive. - We use a simple algorithm to assign an event type to each stock - symbol: - </P> -<PRE> - CORBA::ULong rhat_event_type = - (int('R') << 24) | (int('H') << 16) | (int('A') << 8) | int('T'); - CORBA::ULong aaaa_event_type = - (int('A') << 24) | (int('A') << 16) | (int('A') << 8) | int('A'); -</PRE> - <P>Now we create the subscription: - </P> -<PRE> - ACE_ConsumerQOS_Factory subscriptions; - subscriptions.insert_type (rhat_event_type, 0); - subscriptions.insert_type (aaaa_event_type, 0); -</PRE> - <P>And connect to the proxy: - </P> -<PRE> - RtecEventComm::PushConsumer_var myself = this->_this (); - this->supplier_proxy_->connect_push_consumer ( - myself.in (), - subscriptions.get_ConsumerQOS ()); -} -</PRE> - - <H3>Notifying the Price Changes</H3> - - <P>As with the COS Event Channel example we will make our - implementation of the <CODE>Modify_Stock</CODE> interface - generate events whenever the price changes: - </P> -<PRE> -class Quoter_Modify_Stock_i : public POA_Quoter::Modify_Stock { -public: - Quoter_Modify_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - void set_price (CORBA::Double new_price) - throw (CORBA::SystemException); - - void disconnect_push_supplier (TAO_ENV_SINGLE_ARG_DECL_NOT_USED); - -private: - Quoter::Event data_; - - RtecEventChannelAdmin::ProxyPushConsumer_var consumer_proxy_; - - POA_RtecEventComm::PushSupplier_tie < Quoter_Stock_i > supplier_personality_; -}; -</PRE> - <P>The implementation of the <CODE>set_price()</CODE> method is - very similar. - First we store the new price: - </P> -<PRE> -void -Quoter_Stock_i::set_price (CORBA::Double new_price) - throw (CORBA::SystemException) -{ - this->data_.price = new_price; -</PRE> - <P>Next we prepare the event. - This time we must create a sequence, but we just have one - element in it: - </P> -<PRE> - RtecEventComm::EventSet event (1); - event.length (1); -</PRE> - <P>We set the event type based on the stock symbol: - </P> -<PRE> - RtecEventComm::Event &e = event[0]; - const char *symbol = this->data_.symbol; - e.header.type = - ((int(symbol[0]) << 24) - | (int(symbol[1]) << 16) - | (int(symbol[2]) << 8) - | int(symbol[3])); - e.header.source = 1; -</PRE> - <P>The event source is not used in this example, but it must be - non-zero. Now we can set the data: - </P> -<PRE> - e.data.any_value <<= this->data_; -</PRE> - <P>and send the event to the event channel: - </P> -<PRE> - this->consumer_proxy_->push (event); -} -</PRE> - - <H3>Connecting to the Event Service as a Supplier</H3> - - <P>As in the COS Event Channel case we need a supplier personality - to connect to it. - We gain access to the Event Service, for example using the - naming service: - </P> -<PRE> - CORBA::Object_var tmp = naming_context->resolve (name); - RtecEventChannelAdmin::EventChannel_var event_channel = - RtecEventChannelAdmin::EventChannel::_narrow (tmp); -</PRE> - <P>Now we use the event channel to obtain the factory used for - supplier connections: - </P> -<PRE> - RtecEventChannelAdmin::SupplierAdmin_var supplier_admin = - event_channel->for_suppliers (); -</PRE> - <P>And use the factory to obtain a proxy: - </P> -<PRE> - this->consumer_proxy_ = - supplier_admin->obtain_push_consumer (); -</PRE> - <P>We build our publications so the event channel can match - consumers and suppliers based on their common events: - </P> -<PRE> - const char *symbol = this->data_.symbol; - CORBA::ULong type = - ((int(symbol[0]) << 24) - | (int(symbol[1]) << 16) - | (int(symbol[2]) << 8) - | int(symbol[3])); - CORBA::ULong source = 1; - ACE_SupplierQOS_Factory publications; - publications.insert_type (type, source, 0, 1); -</PRE> - <P>Finally we connect to the consumer proxy: - </P> -<PRE> - RtecEventComm::PushSupplier_var supplier = - this->supplier_personality_._this (); - this->consumer_proxy_->connect_push_supplier (supplier); -</PRE> - - <P>The implementation of the disconnect callback is as before: - </P> -<PRE> -void -Quoter_Stock_i::disconnect_push_supplier (TAO_ENV_SINGLE_ARG_DECL_NOT_USED) - throw (CORBA::SystemException) -{ - // Forget about the consumer it is not there anymore - this->consumer_proxy_ = - RtecEventChannelAdmin::ProxyPushConsumer::_nil (); -} -</PRE> - - <H3>Exercise 1</H3> - - <P>Implement a consumer that receives the price update events, - </P> - <P>The - <A HREF="Stock_Consumer.h">header file</A> - is already provided, - along with a sample - <A HREF="client.cpp">client.cpp</A>. - And other support files - <A HREF="../Event_Service/Quoter.idl">Quoter.idl</A>, - <A HREF="GNUMakefile">Makefile</A>, - <A HREF="Stock_i.h">Stock_i.h</A>, - <A HREF="Stock_i.cpp">Stock_i.cpp</A>, - <A HREF="Stock_Factory_i.h">Stock_Factory_i.h</A>, - <A HREF="Stock_Factory_i.cpp">Stock_Factory_i.cpp</A>, - and <A HREF="server.cpp">server.cpp</A>. - </P> - - <H4>Solution</H4> - - <P>Compare your solution with - <A HREF="Stock_Consumer.cpp">Stock_Consumer.cpp</A>. - </P> - - <H4>Testing</H4> - - <P>To test your changes you need to run three programs, - first TAO's Naming Service: -<PRE> -$ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -</PRE> - <P>then run TAO's Real-time Event Service - </P> -<PRE> -$ $TAO_ROOT/orbsvcs/Event_Service/Event_Service -</PRE> - - <P>Now you can run your client: -<PRE> -$ client AAAA CCCC -</PRE> - <P>and finally the server: - </P> -<PRE> -$ server MSFT BBBB CCCC < stock_list.txt -</PRE> - <P>Here is the - <A HREF="../Event_Service/stock_list.txt">stock_list.txt file</A>. - </P> - - <H3>Exercise 2</H3> - - <P>Run the same configuration as above, - but this time run multiple clients and servers: - </P> -<PRE> -$ client AAAA MSFT -$ client PPPP -$ server AAAA < stock_list1.txt -$ server QQQQ < stock_list2.txt -</PRE> - <P>Do the clients receive all the events from both servers? - </P> - <P>Here are the - <A HREF="../Event_Service/stock_list1.txt">stock_list1.txt</A> - and - <A HREF="../Event_Service/stock_list2.txt">stock_list2.txt</A> - files. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Wed May 16 10:13:34 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/RT_Event_Service/server.cpp b/TAO/docs/tutorials/Quoter/RT_Event_Service/server.cpp deleted file mode 100644 index 3660fc9b82d..00000000000 --- a/TAO/docs/tutorials/Quoter/RT_Event_Service/server.cpp +++ /dev/null @@ -1,104 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "orbsvcs/CosNamingC.h" -#include "ace/streams.h" -#include "ace/OS_NS_unistd.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i; - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Get the Naming Context reference - CORBA::Object_var naming_context_object = - orb->resolve_initial_references ("NameService"); - CosNaming::NamingContext_var naming_context = - CosNaming::NamingContext::_narrow (naming_context_object.in ()); - - // Create and initialize the name. - CosNaming::Name name (1); - name.length (1); - name[0].id = CORBA::string_dup ("Stock_Factory"); - - // Bind the object - naming_context->rebind (name, stock_factory.in ()); - - // Resolve the Event Service - name[0].id = CORBA::string_dup ("EventService"); - - CORBA::Object_var ec_object = - naming_context->resolve (name); - - // Now downcast the object reference to the appropriate type - RtecEventChannelAdmin::EventChannel_var ec = - RtecEventChannelAdmin::EventChannel::_narrow (ec_object.in ()); - - RtecEventChannelAdmin::SupplierAdmin_var supplier_admin = - ec->for_suppliers (); - - stock_factory_i.load_stock_objects (poa.in (), - poa_manager.in (), - supplier_admin.in ()); - - // **************************************************************** - - for (int j = 0; j != 1000; ++j) { - for (int i = 1; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - stock_factory->get_stock (argv[i]); - - CORBA::String_var full_name = stock->full_name (); - - // Get the price - CORBA::Double price = stock->price (); - - Quoter::Modify_Stock_var modify_stock = - Quoter::Modify_Stock::_narrow (stock.in ()); - modify_stock->set_price (price + 1); - - cout << "Set the price of " - << full_name.in () - << " to " << price + 1 << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - ACE_Time_Value tv (0, 500000); - ACE_OS::sleep (tv); - } - } - - stock_factory_i.destroy_stock_objects (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Client/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/Client/Makefile.am deleted file mode 100644 index dd3addbb2f3..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Client/Makefile.am +++ /dev/null @@ -1,49 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - - -## Makefile.Quoter_Simple_Client.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS = client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(srcdir)/../../idl \ - -I../../idl - -client_SOURCES = \ - client.cpp - -client_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Simple/Client/Quoter_Simple_Client.mpc b/TAO/docs/tutorials/Quoter/Simple/Client/Quoter_Simple_Client.mpc deleted file mode 100644 index d1f999594f1..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Client/Quoter_Simple_Client.mpc +++ /dev/null @@ -1,12 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project : taoexe, portableserver, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific(automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Client/client.cpp b/TAO/docs/tutorials/Quoter/Simple/Client/client.cpp deleted file mode 100644 index 0715a3539fe..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Client/client.cpp +++ /dev/null @@ -1,67 +0,0 @@ -// -// $Id$ -// - -// Include the generated names.... -#include "QuoterC.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 3) { - cerr << "Usage: " << argv[0] - << " Factory_IOR symbol symbol..." << endl; - return 1; - } - - // Use the first argument to create the factory object reference, - // in real applications we use the naming service, but let's do - // the easy part first! - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Now get the full name and price of the other arguments: - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - factory->get_stock (argv[i]); - - // Get its name, put it on a _var so it is automatically - // released! - CORBA::String_var full_name = stock->full_name (); - - // Now get the price - CORBA::Double price = stock->price (); - - cout << "The price of a stock in \"" - << full_name.in () << "\" is $" - << price << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - // Finally destroy the ORB - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Client/index.html b/TAO/docs/tutorials/Quoter/Simple/Client/index.html deleted file mode 100644 index 9aef82da78d..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Client/index.html +++ /dev/null @@ -1,316 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Introduction - A very simple client</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Introduction - A very simple client</h3> - - <P>We will start with a reasonably simple IDL interface: we want - to build a stock quoter server, some interface to query the - prices of stock. To make life interesting we will use a - different CORBA object for each stock. This may sound like - overkill, but it will motivate a number of elements that are - interesting to learn at the start. - </P> - - <H3>Defining the IDL interfaces</H3> - - <P>At the very least we want an operation to query the stock - price, as in: - </P> -<PRE> - interface Stock { - double price (); - }; -</PRE> - <P>but stocks usually have symbols and full names, so why not add - a couple of attributes to query them: - </P> -<PRE> - interface Stock { - double price (); - - readonly attribute string symbol; - readonly attribute string full_name; - }; -</PRE> - <P>We also need some interface to gain access to the - <CODE>Stock</CODE> object references from their symbols. - Usually we call this kind of interface a <EM>Factory</EM>, - and it looks like this: - </P> -<PRE> - interface Stock_Factory { - Stock get_stock (in string stock_symbol); - }; -</PRE> - <P>Notice how arguments have a <EM>direction</EM>: they are - qualified as <EM>input only (<CODE>in</CODE>)</EM>, - <EM>output only (<CODE>out</CODE>)</EM>, - or <EM>input-output (<CODE>inout</CODE>)</EM> arguments. - There is a problem, though: what happens if the stock symbol is - invalid? The CORBA way is to raise an exception: - </P> -<PRE> - exception Invalid_Stock_Symbol {}; -</PRE> - <P>and then make the exception part of the - <CODE>Stock_Factory</CODE> interface: - </P> -<PRE> - interface Stock_Factory { - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; -</PRE> - - <P>Finally we put all these IDL constructs in a module to avoid - namespace pollution to obtain the - <A HREF="../Quoter.idl">Quoter.idl</A> file. - </P> - - <H3>The Generated Files</H3> - - <P>Let's take a minute to look at the generated code. - You don't need to do this often, in fact you rarely have to do - it at all. But doing it once is educative and can demystify the - role of the IDL compiler. - </P> - <P>To generate the code you must - invoke the IDL compiler, like - this: - </P> -<PRE> -$ $ACE_ROOT/TAO/TAO_IDL/tao_idl Quoter.idl -</PRE> - <P>The complete documentation of the IDL compiler and its options - are included in - <A HREF="../../../../compiler.html">compiler.html</A>. - Naturally this file is included in the distribution. - </P> - - <P>TAO generates 9 files for each IDL file. - <CODE>QuoterC.h</CODE>, <CODE>QuoterC.i</CODE> - and <CODE>QuoterC.cpp</CODE> contain the client-side interfaces. - Notice that the inline functions are in a separate file so you - can optionally compile them out-of-line for smaller code. - Pure clients only need to link the object file - generated from <CODE>QuoterC.cpp</CODE>. - </P> - <P> - Similarly, <CODE>QuoterS.h</CODE>, <CODE>QuoterS.i</CODE> - and <CODE>QuoterS.cpp</CODE> contain the server-side - <EM>skeletons</EM>. Servers must link the object files generated - from <CODE>QuoterS.cpp</CODE> <STRONG>and</STRONG> <CODE>QuoterC.cpp</CODE>. - </P> - <P> - Finally, <CODE>QuoterS_T.h</CODE>, <CODE>QuoterS_T.i</CODE> - and <CODE>QuoterS_T.cpp</CODE> contain the <EM>TIE</EM> classes. - These are the standard (after the CORBA 2.2 spec) skeletons based - on composition instead of inheritance. - They are in separate files only because some compilers cannot - handle mixed template and non-template code in the same source - file. You <STRONG>do not</STRONG> need to compile these files on any - platform. - However, the files are required to compile - <CODE>QuoterS.cpp</CODE>. - Also notice that if your platform does not support namespaces, - then you may be unable to use the TIE approach for some IDL - interfaces. - </P> - - <P>All the extensions and suffixes discussed above can be modified - using options of the IDL compiler; check the documentation for - more details. Notice, though, that you should use consistent - extensions across your project, otherwise you may have problems - with some <CODE>#include</CODE> directives in your IDL source. - </P> - - <H3>Building a simple client</H3> - - <P>With our simple IDL interface ready, we want to start with a - simple client. The first thing to do in any CORBA client or - server is initialize the ORB: - </P> -<PRE> -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); -</PRE> - <P>IDL supports variable-length types whose sizes are not known - at compile time, hence they must be dynamically allocated at run - time. <CODE>_var</CODE> types relieve us of the explicit memory - management of the variable-length types and thus hide the - differences between fixed and variable-length structured types. - </P> - <P>Since the ORB initialization can fail, and in fact, any CORBA - operation can raise a <CODE>CORBA::SystemException</CODE> we use - a <CODE>try/catch</CODE> block to check for any failures. - Needless to say, this is very naive; some failures can be - temporary, and we should have a better way to recover from - errors, but this is enough for our example. - In consequence, at the end of <CODE>main()</CODE> we catch all - kinds of CORBA exceptions: - </P> -<PRE> - } - catch (CORBA::Exception &ex) { - std::cerr << "CORBA exception raised!" << std::endl; - } - return 0; -} -</PRE> - <P>We must not forget that the ORB is a resource that must be - released by the application. Until CORBA 2.3 there was no - standard way to do this. TAO has adopted the new specification, - so our client should really look like this: - </P> -<PRE> -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // the real code goes here! - - orb->destroy (); - } - catch (CORBA::Exception &ex) { - std::cerr << "CORBA exception raised!" << std::endl; - } - return 0; -} -</PRE> - - <P>Just a few words about the ORB name: The spec requires the ORB - to return the same ORB pointer if the same ORB id is used in - <CODE>CORBA::init</CODE>, and - the implementation is free to return the same pointer even if - different ids are used. - Usually this is not a problem, as most applications instantiate a - single ORB. TAO is one of the few CORBA implementations that - actually supports multiple ORB pointers. This can be important - for real-time applications where each ORB executes at a different - priority. - </P> - - <P>Now that we have the ORB pointer, we can start bootstrapping the - application. Normally we would use the Naming Service, - Trading Service, or the Interoperable Naming Service to locate - the stock factory, but for simplicity, let us use just an IOR - string passed in the first argument. - </P> - <P>The easiest way is to use the first argument to get the string, - and then use <CODE>string_to_object()</CODE> to convert it into an - object reference: - </P> -<PRE> - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); -</PRE> - <P>The <CODE>_narrow()</CODE> is used to test if a reference - is of the specified type. If the reference is of the specified - type, it returns a non-nil reference, else it returns a nil. - </P> - <P>There are a few interesting things about TAO: First, it supports - the <CODE>file:</CODE> scheme for object references, so the first - argument could be <CODE>file://a_file_name</CODE>. In that case, - the ORB will open the file named <CODE>"a_file_name"</CODE> and - read the IOR from that file. - TAO also supports the <CODE>corbaloc:</CODE> scheme, for example - <CODE>corbaloc:iiop:1.1@ace.cs.wustl.edu:12345/Stock_Factory</CODE>. - So using a string can be a very powerful bootstrapping protocol. - </P> - <P>Before we go any further, at this point we are using interfaces - generated by the IDL compiler, so we must include the correct - header file! - </P> -<PRE> -#include "QuoterC.h" -</PRE> - Notice that this is all you need to include; the IDL compiler - generates code that includes all the required internal header - files. - When you use TAO services, don't forget to include their - corresponding header files too. - </P> - - <P>Another interesting TAO feature is the support for - <CODE>_unchecked_narrow()</CODE>. - This is part of the CORBA Messaging specification and - essentially performs the same work as <CODE>_narrow()</CODE>, - but it does not check the types remotely. - If you have compile time knowledge that ensures the correctness - of the narrow operation, it is more efficient to use the - unchecked version. - </P> - - <P>Now we can use the rest of the arguments to obtain the stock - objects: - </P> -<PRE> - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - factory->get_stock (argv[i]); -</PRE> - - <H3>Exercise 1</H3> - - <P>Complete the client implementation. It should be easy at this - point, but it will give you a chance to set up your environment - and become familiar with the basics of building a TAO - application. - </P> - <P>You don't need to do everything. - The <A HREF="../Quoter.idl">Quoter.idl</A> file and - a <A HREF="GNUmakefile.Quoter_Simple_Client">Makefile</A> - are provided. Just - implement the <CODE>client.cpp</CODE> file. - Cut & paste the ORB initialization code, and anything you find - useful from above (you can even cheat and look at the solution, - but it is going to be some really boring 30 minutes if you do!). - </P> - - <H4>Solution</H4> - - <P>Look at the - <A HREF="client.cpp">client.cpp</A> file; it should - not be much different from yours. Count the number of lines in - your client, the idl file and the <CODE>QuoterC.*</CODE> files. Do - you want to write all that code over again? - </P> - - <H3>Testing</H3> - - <P>To test this application we need a server working, a - good excuse to go to the next - <A HREF="../Server/index.html">lesson</A> in the tutorial. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 14:55:08 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Makefile.am deleted file mode 100644 index be1c8727300..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Makefile.am +++ /dev/null @@ -1,105 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_Simple_Impl_Repo_Client.am - -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -I$(srcdir)/../../idl \ - -I../../idl - -client_SOURCES = \ - client.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -client_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_Svc_Utils.la \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING - -## Makefile.Quoter_Simple_Impl_Repo_Server.am - -if BUILD_CORBA_MESSAGING -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(TAO_ROOT)/orbsvcs \ - -I$(TAO_BUILDDIR)/orbsvcs \ - -I$(srcdir)/../../idl \ - -I../../idl - -server_SOURCES = \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_IORTable.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_CosNaming.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_RTEvent.la \ - $(TAO_BUILDDIR)/orbsvcs/orbsvcs/libTAO_Svc_Utils.la \ - $(TAO_BUILDDIR)/tao/libTAO_Messaging.la \ - $(TAO_BUILDDIR)/tao/libTAO_PI.la \ - $(TAO_BUILDDIR)/tao/libTAO_CodecFactory.la \ - $(TAO_BUILDDIR)/tao/libTAO_Valuetype.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS -endif BUILD_CORBA_MESSAGING - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Quoter_Simple_Impl_Repo.mpc b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Quoter_Simple_Impl_Repo.mpc deleted file mode 100644 index e15b2b37572..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Quoter_Simple_Impl_Repo.mpc +++ /dev/null @@ -1,32 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*client) : taoexe, portableserver, rtevent, naming, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl - - source_files { - client.cpp - } -} - -project(*server) : taoserver, rtevent, naming, iortable, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl - - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - } -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.cpp deleted file mode 100644 index a2323a6be36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.cpp +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () - : rhat_ ("RHAT", "RedHat, Inc.", 210), - msft_ ("MSFT", "Microsoft, Inc.", 91) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this (); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.h deleted file mode 100644 index c0e51d1b3ea..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_Factory_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.cpp deleted file mode 100644 index 6149cb79c36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.cpp +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.h b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.h deleted file mode 100644 index 9c41dff6ee0..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/Stock_i.h +++ /dev/null @@ -1,33 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/client.cpp b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/client.cpp deleted file mode 100644 index 0715a3539fe..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/client.cpp +++ /dev/null @@ -1,67 +0,0 @@ -// -// $Id$ -// - -// Include the generated names.... -#include "QuoterC.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 3) { - cerr << "Usage: " << argv[0] - << " Factory_IOR symbol symbol..." << endl; - return 1; - } - - // Use the first argument to create the factory object reference, - // in real applications we use the naming service, but let's do - // the easy part first! - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Now get the full name and price of the other arguments: - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - factory->get_stock (argv[i]); - - // Get its name, put it on a _var so it is automatically - // released! - CORBA::String_var full_name = stock->full_name (); - - // Now get the price - CORBA::Double price = stock->price (); - - cout << "The price of a stock in \"" - << full_name.in () << "\" is $" - << price << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - // Finally destroy the ORB - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/index.html b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/index.html deleted file mode 100644 index df534fe1a6e..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/index.html +++ /dev/null @@ -1,177 +0,0 @@ -<!Doctype HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Implementation Repository</title> - <!-- $Id$ --> - </head> - - <body text = "#000000" - link="#000fff" - vlink="#ffofof" - bgcolor="#ffffff"> - - <h3>Implementation Repository</h3> - <P> In the previous example, the client must contact the server - at least once. If the server has been moved to a different host or - port, or if the server is down, binding between the client and - the server fails. Indirect binding through an external location - broker like the Implementation Repository solves this problem. - </P> - <P>An implementation repository maintains a data structure known - as a server table to keep track of the servers. It maintains a - registry of known servers, records which server is currently - running on which host and at which port number, and starts - servers on demand if they are registered to do so. - </P> - <P> When a server - creates a persistent reference, it sets the address and port - number in the profile body of the IOR to point at the - implementation repository that is responsible for the server. - When a client uses this IOR, it gets connected to the - implementation repository, provided the implementation - repository is not down. The repository decodes this IOR and uses - the POA name from the object key to index into its server - table. The repository replies with the current addressing - information of the actual server. The client now sends the - request to the actual server. - </P> - <P>In this example, let's proceed to modify our previous stock - factory example to support indirect binding through an - implementation repository. - </P> - <P>The only thing we have to do for this is to register our - childPOA with the implementation repository. - </P> - <PRE> - orb->_tao_add_to_IOR_table ("childPOA", stock_factory.in ()); - </PRE> - <P> Then, we stringify all the object references as usual and - print them out. - </P> - <PRE> - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - </PRE> - <H3>Exercise</H3> - Modify the <a href=../Server/server.cpp>server.cpp</a> in the simple - server to create the persistent child POA. - You can use the same - <a href=../Quoter.idl>Quoter.idl</a> - <a href=../Server/Stock_i.h>Stock_i.h</a> - <a href=../Server/Stock_i.cpp>Stock_i.cpp</a> - <a href=../Server/Stock_Factory_i.h>Stock_Factory_i.h</a> - <a href=../Server/Stock_Factory_i.cpp>Stock_Factory_i.cpp</a> - <a href=../Client/client.cpp>Client.cpp</a> - You can use this <a href=GNUmakefile.Quoter_Simple_Impl_Repo_Server>Makefile</a>. - <H3>Solution</H3> - Compare your server.cpp with <a href = server.cpp>server.cpp</a> file. - - <H3>Testing</H3> - <P>To test your changes, you need to run four programs. The first - step is to start up the Implementation Repository provided - with TAO. The Implementation Repository is split into one locator at least - one activator. The locator provides the interface visible - to the application intending to use the repository (in our case, - the client), while the activators do the real work of activating - and maintaining servers. - </P> - - <P>First, we start the locator. We need to dump the IOR of the ImplRepo_Service to a file, - so that both the activator and the client can find the locator. - </P> - <PRE> - $ $TAO_ROOT/orbsvcs/ImplRepo_Service/ImplRepo_Service -o implrepo.ior -d 0 -ORBobjrefstyle URL & - </PRE> - - <P>Second, we start the activator, pointing it to the locator's IOR file. - </P> - <PRE> - $ $TAO_ROOT/orbsvcs/ImplRepo_Service/ImR_Activator -ORBInitRef ImplRepoService=file://implrepo.ior - - ImR Activator: Starting doc.ece.uci.edu - ImR Activator: Registered with ImR. - </PRE> - - <P> Next, we need to register our server with the implementation - repository. We can use the - <CODE>$TAO_ROOT/orbsvcs/ImplRepo_Service/tao_imr</CODE> - application provided with TAO to add our server to the server - database in the implementation repository. - </P> - <PRE> - $ $TAO_ROOT/orbsvcs/ImplRepo_Service/tao_imr -ORBInitRef - ImplRepoService=file://implrepo.ior add childPOA -c - "./server -ORBUseIMR 1 -ORBobjrefstyle URL -ORBInitRef - ImplRepoService=file://implrepo.ior" - - Successfully registered server <childPOA> - </PRE> - <p> On Windows platforms, use this command instead to register the server - in the implementation repository - </p> - <PRE> - $ACE_ROOT/bin/tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior - add childPOA -c "./server -ORBUseIMR 1 -ORBobjrefstyle URL - -ORBInitRef ImplRepoService=file://implrepo.ior" - </PRE> - <P> We specify the <CODE>-ORBInitRef</CODE> option to use the IOR in - the <CODE>implrepo.ior</CODE> file and the <CODE>-ORBUseIMR</CODE> - option to tell the server to use the IMR for notification of its - startup and shutdown. - </P> - <P>The next step is to generate a simple IOR for our server - to be used with the IMR, using the - <CODE>ior</CODE> option, and write it to <CODE>stock_factory.ior</CODE>. - - </P> - <PRE> - $tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior ior - childPOA -f stock_factory.ior - - corbaloc:iiop:1.1@doc.ece.uci.edu:2690/childPOA - </PRE> - <P> From now, the implementation repository is all set to keep - track of our server and do the needful on a method invocation - on our server. - </P> - <P> Now, execute the client as usual. - </P> - <PRE> - ./client file://stock_factory.ior MSFT RHAT - - The price of a stock in "Microsoft, Inc." is $91 - The price of a stock in "RedHat, Inc." is $210 - </PRE> - <P> For testing the persistency of the POA, let's shut down the - server and then run the client. - </P> - <PRE> - $tao_imr -ORBInitRef ImplRepoService=file://implrepo.ior - shutdown childPOA - - Successfully shutdown server <childPOA> - - ./client file://stock_factory.ior MSFT RHAT - - The price of a stock in "RedHat, Inc." is $210 - The price of a stock in "Microsoft, Inc." is $91 - </PRE> - <H3>More Reading</H3> - <P>More information on Implementation Repository is - <A HREF="../../../../../docs/implrepo/index.html">here</A>. - </P> - <P>The <A HREF="http://www.triodia.com/staff/michi-henning.html">Henning</A> and <A HREF="http://www.iona.com/hyplan/vinoski/">Vinoski</A> - <A HREF="http://www.iona.com/hyplan/vinoski/#book">CORBA book</A> discusses POA policies in detail. Likewise, - the Schmidt and Vinoski - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html">columns</A> in C++ Report also include several articles about the POA. Finally, - the <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</A> - distribution includes <A HREF="../../../../../examples/POA">examples</A> that illustrate how - to use the POA policies. - </P> - <hr> - <address><a href="mailto:pgontla@ece.uci.edu">Priyanka Gontla</a></address> -<!-- Created: Wed Mar 29 17:35:30 PST 2000 --> -<!-- hhmts start --> -Last modified: Sat May 19 17:19:07 CDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/server.cpp b/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/server.cpp deleted file mode 100644 index 096cdc27d7c..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Impl-Repo/server.cpp +++ /dev/null @@ -1,107 +0,0 @@ -// $Id$ - -//=========================================================================== -// -// = FILENAME -// server.cpp -// -// = DESCRIPTION -// In this example, -// - Example showing the working of implementation repository. -// -// = AUTHOR -// Priyanka Gontla -// -//============================================================================ - -#include "Stock_Factory_i.h" -#include "tao/IORTable/IORTable.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - - // Initialze the ORB. - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - - // Get a reference to the RootPOA. - CORBA::Object_var obj = orb->resolve_initial_references ("RootPOA"); - - // Get the POA_var object from Object_var. - PortableServer::POA_var root_poa = - PortableServer::POA::_narrow (obj.in ()); - - // Get the POAManager of the RootPOA. - PortableServer::POAManager_var poa_manager = - root_poa->the_POAManager (); - - poa_manager->activate (); - - // Policies for the childPOA to be created. - CORBA::PolicyList policies; - policies.length (2); - - policies[0] = - root_poa->create_id_assignment_policy (PortableServer::USER_ID); - policies[1] = - root_poa->create_lifespan_policy (PortableServer::PERSISTENT); - - - // Create the childPOA under the RootPOA. - PortableServer::POA_var child_poa = - root_poa->create_POA ("childPOA", - poa_manager.in (), - policies); - - // Destroy the policy objects - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - // Create an instance of class Quoter_Stock_Factory_i. - Quoter_Stock_Factory_i stock_factory_i; - - // Get the Object ID. - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId ("Stock_Factory"); - - // Activate the Stock_Factory object. - child_poa->activate_object_with_id (oid.in (), - &stock_factory_i); - - // Get the object reference. - CORBA::Object_var stock_factory = - child_poa->id_to_reference (oid.in ()); - - CORBA::Object_var table_object = - orb->resolve_initial_references ("IORTable"); - - // Stringify all the object referencs. - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - - IORTable::Table_var adapter = - IORTable::Table::_narrow (table_object.in ()); - if (CORBA::is_nil (adapter.in ())) - { - ACE_ERROR ((LM_ERROR, "Nil IORTable\n")); - } - else - { - CORBA::String_var ior = - orb->object_to_string (stock_factory.in ()); - - adapter->bind ("childPOA", ior.in ()); - } - - orb->run (); - - // Destroy POA, waiting until the destruction terminates. - root_poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised !" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Makefile.am deleted file mode 100644 index b66ca814609..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Makefile.am +++ /dev/null @@ -1,55 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - - -## Makefile.Quoter_Simple_ImprovedServer.am - -if BUILD_EXCEPTIONS -if !BUILD_MINIMUM_CORBA - -noinst_PROGRAMS = server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(srcdir)/../../idl \ - -I../../idl - -server_SOURCES = \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif !BUILD_MINIMUM_CORBA -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Quoter_Simple_ImprovedServer.mpc b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Quoter_Simple_ImprovedServer.mpc deleted file mode 100644 index fda3b450dd6..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Quoter_Simple_ImprovedServer.mpc +++ /dev/null @@ -1,10 +0,0 @@ -// $Id$ -project : taoserver, minimum_corba, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl -} diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.cpp deleted file mode 100644 index 156bb8991de..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.cpp +++ /dev/null @@ -1,27 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i (PortableServer::POA_ptr poa) - : stock_factory_poa_ (PortableServer::POA::_duplicate (poa)) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - try { - CORBA::Object_var tmp = - this->stock_factory_poa_->id_to_reference (oid.in ()); - return Quoter::Stock::_narrow (tmp.in ()); - } - catch (PortableServer::POA::ObjectNotActive &) { - throw Quoter::Invalid_Stock_Symbol (); - } -} diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.h deleted file mode 100644 index fcd68a45587..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_Factory_i.h +++ /dev/null @@ -1,30 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_FACTORY_I_H - -#include "QuoterS.h" - -#if defined(_MSC_VER) -#pragma warning(push) -#pragma warning(disable:4250) -#endif /* _MSC_VER */ - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (PortableServer::POA_ptr stock_factory_poa); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - PortableServer::POA_var stock_factory_poa_; -}; - -#if defined(_MSC_VER) -#pragma warning(pop) -#endif /* _MSC_VER */ - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_FACTORY_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.cpp deleted file mode 100644 index 6149cb79c36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.cpp +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.h b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.h deleted file mode 100644 index 55e0530d057..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/Stock_i.h +++ /dev/null @@ -1,43 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -#if defined(_MSC_VER) -#pragma warning(push) -#pragma warning(disable:4250) -#endif /* _MSC_VER */ - -class Quoter_Stock_i - : public virtual POA_Quoter::Stock -{ -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#if defined(_MSC_VER) -#pragma warning(pop) -#endif /* _MSC_VER */ - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_IMPROVEDSERVER_STOCK_I_H */ diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/index.html b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/index.html deleted file mode 100644 index a7a85151b77..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/index.html +++ /dev/null @@ -1,342 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Introduction - Improving the Server</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Introduction - Improving the Server</h3> - - <P>In this section we will improve over the - <A HREF="../Server/index.html">simple server</A> described - before. - We will discuss how to use POA policies to assign our own object - ids. - </P> - - <P>In our previous example we used two fields of the - <CODE>Quoter_Stock_Factory_i</CODE> to represent the stock quotes. - If we wish to create hundreds of stock objects this approach - would not scale. We need to use some collection to keep track of - the Stock objects, possibly indexed by the stock symbol. - One solution is to use an STL map or something similar, but this - is clearly wasteful. After all, the ORB is also keeping a - collection of objects, indexed by the object ids. - If we only could choose the ids ourselves, then our problem would - be solved. - The good news is that the POA allows this, - the bad news is that we must create a child POA for that. - Why? Because the Root POA ids are assigned by the ORB, and we - don't want to conflict with those. - Furthermore, creating a separate POA is easier to manage, as - multiple components of the application can get their own POA, - that they can treat as a private namespace. - </P> - - <H3>Child POA creation</H3> - - <P>As before, we gain access to the RootPOA: - </P> -<PRE> - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); -</PRE> - <P>Now we create the policies for the child poa. - In this case we want the <CODE>USER_ID</CODE> policy so we can - assign our own ids. - We also want the <CODE>NO_IMPLICIT_ACTIVATION</CODE> policy, to - have more control over additions to our POA. - The POA has more policies that we can control, but we will use - the defaults in this example. - There are many examples in <CODE>$TAO_ROOT/examples/POA/</CODE> that - show how to use other policies in the POA. - </P> - <P>The policies are stored in a sequence, so we first create the - sequence and initialize its length: - </P> -<PRE> - CORBA::PolicyList policies (2); - policies.length (2); -</PRE> - <P>now we create the policies: - </P> -<PRE> - policies[0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - policies[1] = - poa->create_implicit_activation_policy (PortableServer::NO_IMPLICIT_ACTIVATION); -</PRE> - <P>now we can create the child POA; - </P> -<PRE> - PortableServer::POA_var stock_factory_poa = - poa->create_POA ("Stock_Factory_POA", - poa_manager.in (), - policies); -</PRE> - <P>Notice that we shared the POA manager with the RootPOA, so we - only need to use a single POA manager to control the state of - both. - The new POA makes a copy of the policies, so we need to destroy - them to avoid memory leaks: - </P> -<PRE> - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } -</PRE> - - <H3>Activating objects in the child POA</H3> - - <P>Now we must use this POA to activate the stock objects. - To keep the example simple, we will assume that we read the list - of stocks from the stdin, as in: - </P> -<PRE> - while (!std::cin.eof () && std::cin.peek () != EOF) { - const int max_symbol_length = 8; - char symbol[max_symbol_length]; - const int max_full_name_length = 64; - char full_name[max_full_name_length]; - double price; - - std::cin.getline (symbol, max_symbol_length, '\n'); - std::cin.getline (full_name, max_full_name, '\n'); - std::cin >> price; - std::cin.ignore (1, '\n'); - - // The interesting stuff goes here! - } -</PRE> - <P>For each trio of symbol, full name, and price, we create a stock - implementation object: - </P> -<PRE> - PortableServer::ServantBase_var servant = - new Quoter_Stock_i (symbol, full_name, price); -</PRE> - <P>The <CODE>ServantBase_var</CODE> acts like an auto pointer and - will take care of deallocation in case there is an exception. - This time we cannot use <CODE>_this()</CODE> to activate the servant - though, because we want to create our own ids: - </P> -<PRE> - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); -</PRE> - <P>and then activate the object with that id: - </P> -<PRE> - stock_factory_poa->activate_object_with_id (oid.in (), - servant.in ()); -</PRE> - <P>Be careful not to invoke <CODE>_this()</CODE> on any of these - objects, as that would activate them in the RootPOA, ending with - two activations! It is perfectly legal to activate the same - servant multiple times in different POAs (and sometimes even in - the same POA!), but this is not what we want in this case. - </P> - - <H3>Modifying the Stock Factory</H3> - - <P>Now we need to implement a different version of the stock - factory. We pass a reference to the child POA into the constructor - and keep a reference to it: - </P> -<PRE> -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory -{ -public: - Quoter_Stock_Factory (PortableServer::POA_ptr stock_factory_poa) - : stock_factory_poa_ (PortableServer::POA::_duplicate (stock_factory_poa)) - {} - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - PortableServer::POA_var stock_factory_poa_; -}; -</PRE> - <P>Notice that we duplicate the POA, following the usual CORBA - memory rules for input arguments. Since the constructor is not a - CORBA operation, we could use any rules we wished, but it is less - confusing if we stick to the CORBA set. - </P> - <P>The implementation of the <CODE>get_stock</CODE> operation is more - interesting. First we create an object id based on the symbol: - </P> -<PRE> -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); -</PRE> - <P>next we look up that object id in the POA: - </P> -<PRE> - try { - CORBA::Object_var tmp = - this->stock_factory_poa_->id_to_reference (oid.in ()); -</PRE> - <P>then narrow the object reference to the right type and return - it: - </P> -<PRE> - return Quoter::Stock::_narrow (tmp.in ()); - } -</PRE> - <P>If the symbol was invalid, the POA will not find the right - object id and raise an exception: - </P> -<PRE> - catch (PortableServer::POA::ObjectNotActive &) { - throw Quoter::Invalid_Stock_Symbol (); - } -} -</PRE> - - <H3>Memory management for the Stock objects</H3> - - <P>So far we have not discussed memory management for servants. - This is a good opportunity to do it, because the stock objects - are completely controlled by the POA. - The POA provides reference counting for the Servants. You are - <STRONG>not</STRONG> required to use reference counting, but if - you do, most of the memory management is extremely simple. - So why is reference counting not used all the time? Because some - applications do not require it. For example, - our previous simple server did not require any complex memory - management, as the objects were all created on the stack. - </P> - - <P>To use the reference counting features in the POA, you must - override the <CODE>_add_ref()</CODE> and <CODE>_remove_ref()</CODE> - methods, to increase and decrease the reference count. Once the - count reaches 0, you can safely remove the object (but remember - to start the count at 1!). - Implementing these methods in a thread safe way is a tedious - task. To simplify the task, we use a mixin with the - <CODE>PortableServer::RefCountServantBase</CODE> class, as in: - </P> -<PRE> -class Quoter_Stock_i - : public virtual POA_Quoter::Stock, - public virtual PortableServer::RefCountServantBase -{ -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - // as before -}; -</PRE> - <P>TAO's implementation of the <CODE>RefCountServantBase</CODE> is - even thread safe, so you can use this technique in your - multi-threaded servers to dynamically destroy objects. - You simply delegate control to the POA. - Once you deactivate the object, the POA will only invoke - <CODE>_remove_ref()</CODE> once all the threads performing calls on - an object terminate, - so the object is not removed if it is still in use. - Just remember to increment the reference count if you need to - use it, too. - </P> - - <H3>Exersice</H3> - - <P>Modify the following files in the simple server as follows: - <UL> - <LI> <A HREF="../Server/Stock_i.h">Stock_i.h</A>: - Use the reference counted servant to control memory management. - </LI> - <LI> <A HREF="../Server/Stock_Factory_i.h">Stock_Factory_i.h</A>: - Apply the changes described above to use a child POA with the - appropriate policies. - </LI> - <LI> <A HREF="../Server/Stock_Factory_i.cpp">Stock_Factory_i.cpp</A>: - Apply the changes described above to use a child POA with the - appropriate policies. - </LI> - <LI> <A HREF="../Server/server.cpp">server.cpp</A>: - Create the child POA, - initialize the stock objects from the stdin, and create the - right stock factory class. - </LI> - </UL> - You can use the same - <A HREF="../Quoter.idl">Quoter.idl</A>, - <A HREF="../Server/Stock_i.cpp">Stock_i.cpp</A> - and - <A HREF="GNUmakefile.Quoter_Simple_ImprovedServer">Makefile</A> - </P> - - <H4>Solution</H4> - - <P>Compare your solution with the following files: - <UL> - <LI> <A HREF="Stock_i.h">Stock_i.h</A> - </LI> - <LI> <A HREF="Stock_i.cpp">Stock_i.cpp</A> - </LI> - <LI> <A HREF="Stock_Factory_i.h">Stock_Factory_i.h</A> - </LI> - <LI> <A HREF="Stock_Factory_i.cpp">Stock_Factory_i.cpp</A> - </LI> - <LI> <A HREF="server.cpp">server.cpp</A> - </LI> - </UL> - </P> - - <P>Does this solution scale when the number of stock symbols is in - the thousands or millions? Find out about Servant Locators and - Servant Activators in the POA! - </P> - - <H3>Testing</H3> - - <P>A sample - <A HREF="stock_list.txt">input file</A> - is available. You can use the - <A HREF="../Client/index.html">simple client</A> to check the - results, - as follows: -<PRE> -$ server < stock_list.txt > ior_file -$ client file://ior_file AAAA BBBB MSFT RHAT CCCC -</PRE> - Also test invalid symbols! - </P> - - <H3>More Reading</H3> - - <P>The <A -HREF="http://www.triodia.com/staff/michi-henning.html">Henning</A> and -<A HREF="http://www.iona.com/hyplan/vinoski/">Vinoski</A> <A HREF="http://www.iona.com/hyplan/vinoski/#book">CORBA book</A> discusses POA policies in detail. Likewise, - the Schmidt and Vinoski - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html">columns - </A> - in C++ Report also include several articles about the POA. Finally, - the <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html">TAO</a> distribution includes - <A -HREF="../../../../../examples/POA">examples</A> -that illustrate how to use the POA policies. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 18:11:01 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/server.cpp b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/server.cpp deleted file mode 100644 index 06692da309e..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/server.cpp +++ /dev/null @@ -1,86 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "Stock_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - CORBA::PolicyList policies (2); - policies.length (2); - - policies[0] = - poa->create_id_assignment_policy (PortableServer::USER_ID); - policies[1] = - poa->create_implicit_activation_policy (PortableServer::NO_IMPLICIT_ACTIVATION); - - PortableServer::POA_var stock_factory_poa = - poa->create_POA ("Stock_Factory_POA", - poa_manager.in (), - policies); - - for (CORBA::ULong i = 0; i != policies.length (); ++i) { - policies[i]->destroy (); - } - - while (!cin.eof () && cin.peek () != EOF) { - const int max_symbol_length = 8; - char symbol[max_symbol_length]; - const int max_full_name_length = 64; - char full_name[max_full_name_length]; - double price; - - cin.getline (symbol, max_symbol_length, '\n'); - cin.getline (full_name, max_full_name_length, '\n'); - cin >> price; - cin.ignore (1, '\n'); - - PortableServer::ServantBase_var servant = - new Quoter_Stock_i (symbol, full_name, price); - - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId (symbol); - - stock_factory_poa->activate_object_with_id (oid.in (), - servant.in ()); - } - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i (stock_factory_poa.in ()); - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Put the object reference as an IOR string - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - // Print it out! - cout << ior.in () << endl; - - orb->run (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl - << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/stock_list.txt b/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/stock_list.txt deleted file mode 100644 index d30a0c0255a..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/ImprovedServer/stock_list.txt +++ /dev/null @@ -1,84 +0,0 @@ -MSFT -Microsoft Inc. -91 -RHAT -RedHat Inc. -210 -AAAA -The AAAA Company -100 -BBBB -The BBBB Company -101 -CCCC -The CCCC Company -102 -DDDD -The DDDD Company -103 -EEEE -The EEEE Company -104 -FFFF -The FFFF Company -105 -GGGG -The GGGG Company -106 -HHHH -The HHHH Company -107 -IIII -The IIII Company -108 -JJJJ -The JJJJ Company -109 -KKKK -The KKKK Company -110 -LLLL -The LLLL Company -111 -MMMM -The MMMM Company -112 -NNNN -The NNNN Company -113 -OOOO -The OOOO Company -114 -PPPP -The PPPP Company -115 -QQQQ -The QQQQ Company -116 -RRRR -The RRRR Company -117 -SSSS -The SSSS Company -118 -TTTT -The TTTT Company -119 -UUUU -The UUUU Company -120 -VVVV -The VVVV Company -121 -WWWW -The WWWW Company -122 -XXXX -The XXXX Company -123 -YYYY -The YYYY Company -124 -ZZZZ -The ZZZZ Company -125 diff --git a/TAO/docs/tutorials/Quoter/Simple/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/Makefile.am deleted file mode 100644 index dbb1885fecd..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Makefile.am +++ /dev/null @@ -1,17 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -SUBDIRS = \ - Client \ - Impl-Repo \ - ImprovedServer \ - Persistent \ - Server - diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/Persistent/Makefile.am deleted file mode 100644 index 1e20d49fdfa..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Makefile.am +++ /dev/null @@ -1,82 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - -noinst_PROGRAMS = - -## Makefile.Quoter_Simple_Persistent_Client.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += client - -client_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(srcdir)/../../idl \ - -I../../idl - -client_SOURCES = \ - client.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -client_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Makefile.Quoter_Simple_Persistent_Server.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS += server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(srcdir)/../../idl \ - -I../../idl - -server_SOURCES = \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Quoter_Simple_Persistent.mpc b/TAO/docs/tutorials/Quoter/Simple/Persistent/Quoter_Simple_Persistent.mpc deleted file mode 100644 index c8c3a2ad4ae..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Quoter_Simple_Persistent.mpc +++ /dev/null @@ -1,32 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*client) : taoexe, portableserver, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl - - source_files { - client.cpp - } -} - -project(*server) : taoserver, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl - - source_files { - server.cpp - Stock_Factory_i.cpp - Stock_i.cpp - } -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.cpp deleted file mode 100644 index a2323a6be36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.cpp +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () - : rhat_ ("RHAT", "RedHat, Inc.", 210), - msft_ ("MSFT", "Microsoft, Inc.", 91) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this (); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.h deleted file mode 100644 index c0e51d1b3ea..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_Factory_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.cpp deleted file mode 100644 index 6149cb79c36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.cpp +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.h b/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.h deleted file mode 100644 index 9c41dff6ee0..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/Stock_i.h +++ /dev/null @@ -1,33 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/client.cpp b/TAO/docs/tutorials/Quoter/Simple/Persistent/client.cpp deleted file mode 100644 index 0715a3539fe..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/client.cpp +++ /dev/null @@ -1,67 +0,0 @@ -// -// $Id$ -// - -// Include the generated names.... -#include "QuoterC.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - - // There must be at least two arguments, the first is the factory - // name, the rest are the names of the stock symbols we want to - // get quotes for. - if (argc < 3) { - cerr << "Usage: " << argv[0] - << " Factory_IOR symbol symbol..." << endl; - return 1; - } - - // Use the first argument to create the factory object reference, - // in real applications we use the naming service, but let's do - // the easy part first! - CORBA::Object_var factory_object = - orb->string_to_object (argv[1]); - - // Now downcast the object reference to the appropriate type - Quoter::Stock_Factory_var factory = - Quoter::Stock_Factory::_narrow (factory_object.in ()); - - // Now get the full name and price of the other arguments: - for (int i = 2; i != argc; ++i) { - try { - // Get the stock object - Quoter::Stock_var stock = - factory->get_stock (argv[i]); - - // Get its name, put it on a _var so it is automatically - // released! - CORBA::String_var full_name = stock->full_name (); - - // Now get the price - CORBA::Double price = stock->price (); - - cout << "The price of a stock in \"" - << full_name.in () << "\" is $" - << price << endl; - } - catch (Quoter::Invalid_Stock_Symbol &) { - cerr << "Invalid stock symbol <" - << argv[i] << ">" << endl; - } - } - - // Finally destroy the ORB - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/index.html b/TAO/docs/tutorials/Quoter/Simple/Persistent/index.html deleted file mode 100644 index f87e26e2f1c..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/index.html +++ /dev/null @@ -1,375 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Persistent Objects</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Introduction - Improving the Server</h3> - - <P>In this section, we will improve the - <!-- @@ Priyanka: I think the HTML spec requires you to use - quotes for all URLs - --> - <A HREF="../Server/server.cpp"> - simple server - </A> - which we have developed before. We will use POA policies - to create an object with a persistent object reference. - </P> - <P> - The characteristics of a POA are controlled via POA policies - that are specified when the POA is created. - POA policies all have the same form: their values are specified - at creation time using an enumerated type. - In our example we will use the <CODE>LifeSpanPolicy</CODE> - that controls how the lifetime of object references relates to - the lifetime of the POAs that generate the object references - and the <CODE>IdAssignmentPolicy</CODE> that controls how - object ids are assigned. - </P> - - <P> - CORBA Objects that can live irrespective of any particular - process in which they are created or activated are called - <EM>Persistent Objects</EM>. - Likewise, - shorter-lived objects whose lifetimes are bound to the - lifetime of the POA in which they are created are called - <EM>Transient Objects</EM>. - Notice that this has nothing to do with the state of the object: - an application can create transient objects to access some - persistent information maintained in a database. - For example, - such objects can represent a different session or transaction view - of the data. - Similarly, some persistent object references may have no state - or no persistent state. - For example, a logging facility is persistent because it is - always available, but it may maintain no state or simply cache - some state for the current activation. - In general, though, - objects that have persistent state are accessed throught - persistent object references. - </P> - <P> - The standard life span policy for the RootPOA is - <CODE>TRANSIENT</CODE>. - This means that any application that needs to support persistent - objects must create at least another POA with the Persistent - life span policy. - In our example we will create two policies for this child POA. - One policy is the <CODE>LifeSpanPolicy</CODE> which we will set - to be <CODE>PERSISTENT</CODE>. - Usually applications that create persistent object references - also set the <CODE>IdAssignmentPolicy</CODE>, - so they can assign the object ids in a predictable way, - consistent across server activations. - It is possible, but very unusual, to use system ids with - persistent object references. - </P> - <!-- - <P>A POA identifies its object by an object identifier, specified - using the ObjectId type, defined in the PortableServer module. - Within the scope of a POA, all Object IDs must be unique. - An application can either supply its own ObjectID or have the - POA create object identifiers for it. - This Object identification is controlled by the IdAssignmentPolicy. If - the policy value is set to be <CODE>USER_ID</CODE>, the application has - the choice. Otherwise, if this policy value is set to be - <CODE>SYSTEM_ID</CODE>, the RootPOA creates the ObjectIDs. - Let's give our - application a choice for the creation of its Object's IDs. - </P> - --> - <P>For more about POA and its policies, - please refer to - "Advanced CORBA Programming with C++" - by Henning and Vinoski. - The TAO distribution also includes many examples on how to use - the POA and its policies in the - <CODE>$TAO_ROOT/examples/POA</CODE> - directory. - </P> - - <H3>Child POA Creation</H3> - - <P> - As before, we first initialize the ORB, - and obtain a reference to the Root POA. - </P> - <PRE> - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - </PRE> - - <P> - Next we get the <CODE>POAManager</CODE> of the <CODE>RootPOA</CODE> - and use it to activate the <CODE>RootPOA</CODE> - </P> - <PRE> - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - - poa_manager->activate (); - </PRE> - - <P> - Now we create a <CODE>LifeSpanPolicy</CODE> - object with the <CODE>PERSISTENT</CODE> value: - <PRE> - // Create a PERSISTENT LifespanPolicy object - PortableServer::LifespanPolicy_var lifespan = - poa->create_lifespan_policy (PortableServer::PERSISTENT); -</PRE> - <P> - and next we create an <CODE>IdAssignmentPolicy</CODE> object with - the <CODE>USER_ID</CODE> value: - </P> -<PRE> - // Create a USER_ID IdAssignmentPolicy object - PortableServer::IdAssignmentPolicy_var idassignment = - poa->create_id_assignment_policy (PortableServer::USER_ID); - </PRE> - <P>Next we can initialize the sequence of policies: - </P> - <PRE> - CORBA::PolicyList polices (2); - policies.length (2); - policies[0] = - PortableServer::IdAssignmentPolicy::_duplicate (idassignment); - policies[1] = - PortableServer::LifespanPolicy::_duplicate (lifespan); - </PRE> - <!-- @@ Priyanka: I noticed that you used "let's" and "doesn't" - several times, I understand that it is not good style for - professional looking documents, then again it may be my fault, - because I was really loose on the first set of tutorials. - --> - <P>Child POAs are created using the <CODE>create_POA</CODE> - operation on the parent POA. - </P> - <PRE> - PortableServer::POA_var child_poa = - poa->create_POA ("childPOA", - poa_manager.in (), - policies); - </PRE> - <P>The values which we pass to this <CODE>create_POA</CODE> operation are - the name of the child POA, the POAManager of the child POA, and the - <CODE>CORBA::PolicyList</CODE>. - We can create a child controlled by a new - <CODE>POAManager</CODE> by passing - a <CODE>nil</CODE> reference, - but commonly the <CODE>POAManager</CODE> of the parent is used. - </P> - <P>Finally, we can now destroy the life span policy and id assignment - policy objects, since they are no longer needed. The - <CODE>create_POA</CODE> operation will make a copy of the objects in the - policy list and the newly created POA will refer to the copies of the - objects passed to the <CODE>create_POA</CODE>. - </P> - <PRE> - idassignment->destroy (); - lifespan->destroy (); - </PRE> - - <H3>Activating Objects in the child POA </H3> - - <P>Now that we have created a new POA, let's use this POA to activate the - stock objects. The first step would be to create an instance of the - stock factory implementation. - <PRE> - // Create a servant of class Quoter_Stock_Factory_i - Quoter_Stock_Factory_i stock_factory_i; - </PRE> - <P> - Objects can be activated explicitly using the - <CODE>activate_object_with_id ()</CODE> - operation. - This operation has two input parameters: - id of the object and a pointer to the servant that implements - it. - We create the id using a helper function: - </P> - <PRE> - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId ("Stock_Factory"); - </PRE> - <P>Next, we can activate the "Stock_Factory" object: - </P> - <PRE> - child_poa->activate_object_with_id (oid.in (), - &stock_factory_i); - </PRE> - <P> - This operation does not return the object reference of the new - object, - but we can use the <CODE>id_to_reference</CODE> operation - to obtain the object reference: - </P> - <PRE> - CORBA::Object_var stock_factory = - child_poa->id_to_reference (oid.in ()); - </PRE> - <P>As before, we convert the object reference into an IOR string - so that the client can use it. - </P> - <PRE> - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - std::cout << ior.in () << std::endl; - </PRE> - <P>As we know already, the final step before a client's request can - get processed would be to run the ORB event loop. Last, we destroy - the POA, waiting until the destruction terminates. - </P> - <PRE> - orb->run (); - - // Destroy the POA - poa->destroy (1,1); - orb->destroy (); - </PRE> - - <H3>Exercise</H3> - - Modify the <a href=../Server/server.cpp>server.cpp</a> in the simple - server to create the persistent child POA. - You can use the same - <a href=../Quoter.idl>Quoter.idl</a> - <a href=../Server/Stock_i.h>Stock_i.h</a> - <a href=../Server/Stock_i.cpp>Stcok_i.cpp</a> - <a href=../Server/Stock_Factory_i.h>Stock_Factory_i.h</a> - <a href=../Server/Stock_Factory_i.cpp>Stock_Factory_i.cpp</a> - You can use this <a href=Makefile>Makefile</a>. - <H3>Solution</H3> - Compare your server.cpp with - <a href="server.cpp"> - server.cpp - </a> file. - - <H3>Testing</H3> - You can use the <a href=../Client/client.cpp>client.cpp</a> to check - the results, as follows: - <PRE> - $ ./server -ORBEndPoint iiop://localhost:12345 > server.ref & - </PRE> - - <P>Normally the ORB selects a listening endpoint at random. - This is inadequate for applications with persistent object - references because the references will become invalid if the - server restarts in a new listening endpoint. - In TAO we can control the listening endpont(s) using the - <!-- @@ Priyanka: can you add a URL for the document that - describes all the ORB options? - --> - <CODE>-ORBEndPoint</CODE> option. - For example, for the IIOP protocol, - the endpoint information contains the name or IP address of the - host and a free TCP port number. - In the next - <A HREF="../Impl-Repo/index.html"> - tutorial - </A> - we will learn how we can use the - <!-- @@ Priyanka: can you add a URL for the document that - describes the implementation repository? - --> - Implementation Repository to work with persistent object - references without setting the listening endpoint explicitly. - </P> - <P> The client is executed as usual: - </P> - <PRE> - $ ./client file://server.ref MSFT RHAT - </PRE> - <P>For testing the persistency of the POA, let's kill the server. Then - direct the object reference into a new foo.ref. - </P> - <PRE> - $ kill %1 - $ ./server -ORBEndPoint iiop://localhost:12345 > foo.ref & - [2] 6941 - </PRE> - <P>If we run the client again, we must get the result from the server - as before. - </P> - <PRE> - $ ./client file://server.ref MSFT RHAT - </PRE> - <P>What happens if we don't tell the server to listen from the - same port? - Let's try to run the new server as usual: - </P> - <PRE> - $ ./server > server.ref & - [1] 23897 - $ ./client file://server.ref MSFT RHAT - The price of a stock in "RedHat, Inc." is $210 - The price of a stock in "Microsoft, Inc." is $91 - $ kill %1 - $ ./server > foo.ref & - [2] 23908 - $ ./client file://server.ref MSFT RHAT - CORBA exception raised!TRANSIENT (IDL:omg.org/CORBA/TRANSIENT:1.0) - </PRE> - <!-- @@ Priyanka: check my comments on what a TRANSIENT exception - means - --> - <P>A CORBA TRANSIENT exception is raised. - This indicates that some of the resources required to perform - the request are not available. - In this case the client ORB cannot find the server on the - expected port number. - Without an Implementation Repository the client ORB cannot - locate the server in its new port. - It has to assume that the server is temporarly down, - and could be restarted in the future, - thus the TRANSIENT exception. - </P> - - <H3>More Reading</H3> - - <P>The - <A HREF="http://www.triodia.com/staff/michi-henning.html"> - Henning - </A> - and - <A HREF="http://www.iona.com/hyplan/vinoski/"> - Vinoski - </A> - <A HREF="http://www.iona.com/hyplan/vinoski/#book"> - CORBA book - </A> discusses POA policies in detail. - Likewise, the Schmidt and Vinoski - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html"> - columns - </A> - in C++ Report also include several articles about the POA. - Finally, the - <A HREF="http://www.cs.wustl.edu/~schmidt/TAO.html"> - TAO - </A> - distribution includes several - <A HREF="../../../../../examples/POA"> - examples - </A> - that illustrate how to use the POA policies. - </P> - - <hr> - <address><a href="mailto:pgontla@ece.uci.edu">Priyanka Gontla</a></address> -<!-- Created: Wed Mar 1 20:29:59 PST 2000 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 18:09:33 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Simple/Persistent/server.cpp b/TAO/docs/tutorials/Quoter/Simple/Persistent/server.cpp deleted file mode 100644 index 06f5d6282cb..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Persistent/server.cpp +++ /dev/null @@ -1,99 +0,0 @@ -// $Id$ - -//=========================================================================== -// -// = FILENAME -// server.cpp -// -// = DESCRIPTION -// -// In this example, a new POA (childPOA) is created and its -// policy is set so that it object references are persistent. -// -// = AUTHOR -// Priyanka Gontla <pgontla@ece.uci.edu> -// -//============================================================================ - -#include "Stock_Factory_i.h" -#include "ace/streams.h" - -int main (int argc, char *argv[]) -{ - try { - - // Initialze the ORB. - CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); - - // Get a reference to the RootPOA. - CORBA::Object_var obj = orb->resolve_initial_references ("RootPOA"); - - // Get the POA_var object from Object_var. - PortableServer::POA_var root_poa = - PortableServer::POA::_narrow (obj.in ()); - - // Get the POAManager of the RootPOA. - PortableServer::POAManager_var poa_manager = - root_poa->the_POAManager (); - - poa_manager->activate (); - - // Create a USER_ID IdAssignmentpolicy object. - PortableServer::IdAssignmentPolicy_var idassignment = - root_poa->create_id_assignment_policy (PortableServer::USER_ID); - - // Create a PERSISTENT LifespanPolicy object. - PortableServer::LifespanPolicy_var lifespan = - root_poa->create_lifespan_policy (PortableServer::PERSISTENT); - - // Policies for the childPOA to be created. - CORBA::PolicyList policies; - policies.length (2); - - policies[0] = - PortableServer::IdAssignmentPolicy::_duplicate (idassignment.in ()); - - policies[1] = - PortableServer::LifespanPolicy::_duplicate (lifespan.in ()); - - // Create the childPOA under the RootPOA. - PortableServer::POA_var child_poa = - root_poa->create_POA ("childPOA", - poa_manager.in (), - policies); - - // Destroy policy objects. - idassignment->destroy (); - lifespan->destroy (); - - // Create an instance of class Quoter_Stock_Factory_i. - Quoter_Stock_Factory_i stock_factory_i; - - // Get the Object ID. - PortableServer::ObjectId_var oid = - PortableServer::string_to_ObjectId ("Stock_Factory"); - - // Activate the Stock_Factory object. - child_poa->activate_object_with_id (oid.in (), - &stock_factory_i); - - // Get the object reference. - CORBA::Object_var stock_factory = - child_poa->id_to_reference (oid.in ()); - - // Stringify all the object referencs. - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - // Print them out ! - cout << ior.in () << endl; - - orb-> run (); - - // Destroy POA, waiting until the destruction terminates. - root_poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised !" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Quoter.idl b/TAO/docs/tutorials/Quoter/Simple/Quoter.idl deleted file mode 100644 index 3129da38a4b..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Quoter.idl +++ /dev/null @@ -1,44 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; -}; diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Makefile.am b/TAO/docs/tutorials/Quoter/Simple/Server/Makefile.am deleted file mode 100644 index 553f4e013be..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Makefile.am +++ /dev/null @@ -1,53 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_ROOT = $(top_srcdir) - - -## Makefile.Quoter_Simple_Server.am - -if BUILD_EXCEPTIONS - -noinst_PROGRAMS = server - -server_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -I$(srcdir)/../../idl \ - -I../../idl - -server_SOURCES = \ - Stock_Factory_i.cpp \ - Stock_i.cpp \ - server.cpp \ - Stock_Factory_i.h \ - Stock_i.h - -server_LDADD = \ - $(top_builddir)/docs/tutorials/Quoter/idl/libQuoter_Idl_Lib.la \ - $(TAO_BUILDDIR)/tao/libTAO_PortableServer.la \ - $(TAO_BUILDDIR)/tao/libTAO_AnyTypeCode.la \ - $(TAO_BUILDDIR)/tao/libTAO.la \ - $(ACE_BUILDDIR)/ace/libACE.la - -endif BUILD_EXCEPTIONS - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Quoter_Simple_Server.mpc b/TAO/docs/tutorials/Quoter/Simple/Server/Quoter_Simple_Server.mpc deleted file mode 100644 index dc8789b784c..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Quoter_Simple_Server.mpc +++ /dev/null @@ -1,12 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project : taoserver, exceptions { - libs += Quoter_Idl_Lib - after += Quoter_Idl_Lib - - specific (automake) { - includes += $(srcdir)/../../idl - } - includes += ../../idl -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.cpp deleted file mode 100644 index a2323a6be36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.cpp +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" - -Quoter_Stock_Factory_i::Quoter_Stock_Factory_i () - : rhat_ ("RHAT", "RedHat, Inc.", 210), - msft_ ("MSFT", "Microsoft, Inc.", 91) -{ -} - -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this (); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.h b/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.h deleted file mode 100644 index c0e51d1b3ea..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_Factory_i.h +++ /dev/null @@ -1,23 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H - -#include "Stock_i.h" - -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory { -public: - Quoter_Stock_Factory_i (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_FACTORY_I_H */ - diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.cpp b/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.cpp deleted file mode 100644 index 6149cb79c36..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.cpp +++ /dev/null @@ -1,32 +0,0 @@ -// -// $Id$ -// - -#include "Stock_i.h" - -Quoter_Stock_i::Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price) - : symbol_ (symbol), - full_name_ (full_name), - price_ (price) -{ -} - -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} - -char * -Quoter_Stock_i::full_name () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->full_name_.c_str ()); -} - -CORBA::Double -Quoter_Stock_i::price () throw (CORBA::SystemException) -{ - return this->price_; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.h b/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.h deleted file mode 100644 index 61889a69b63..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/Stock_i.h +++ /dev/null @@ -1,34 +0,0 @@ -// -// $Id$ -// - -#ifndef TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H -#define TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H - -#include "QuoterS.h" -#include <string> - -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); - -private: -#if defined (HPUX) && (ACE_HAS_STANDARD_CPP_LIBRARY == 0) - string symbol_; - string full_name_; -#else - std::string symbol_; - std::string full_name_; -#endif /* HPUX */ - CORBA::Double price_; -}; - -#endif /* TAO_TUTORIAL_QUOTER_SIMPLE_SERVER_STOCK_I_H */ - - diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/index.html b/TAO/docs/tutorials/Quoter/Simple/Server/index.html deleted file mode 100644 index 92f4a5f90ba..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/index.html +++ /dev/null @@ -1,355 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Introduction - A very simple server</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Introduction - A very simple server</h3> - - <P>Now that we know how to implement a - <A HREF="../Client/index.html">simple client</A>, we need to - implement a server to test it out. - We have to provide implementations for both the <CODE>Stock</CODE> - and <CODE>Stock_Factory</CODE> interfaces, - and then create an executable that incorporates those implementations. - </P> - - <H3>Implementing the <CODE>Stock</CODE> interface</H3> - - <P>To keep things simple, let's implement a <CODE>Stock</CODE> - object with a fixed price. The constructor will receive all the - parameters: - </P> -<PRE> -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - Quoter_Stock_i (const char *symbol, - const char *full_name, - CORBA::Double price); - -private: - std::string symbol_; - std::string full_name_; - CORBA::Double price_; -}; -</PRE> - <P>In a server, CORBA objects and functions are implemented and - represented by programming language data and functions. These - programming entities that implement and represent CORBA objects - are called <I>servants</I>. <I>Object Adapters</I> link the world of - CORBA objects to the world of programming language servants. They - provide services for creation of CORBA objects and their object - references and for dispatching requests to the appropriate - servants. - </P> - <P>Notice the name of the base class. TAO implements the CORBA 2.2 - specification, which includes the Portable Object Adapter (hence - the POA prefix). This new Object Adapter fixes many problems - with the previous versions of the CORBA specification, where the - so-called Basic Object Adapter was used. Unfortunately, the - specification was ambiguous and lead to incompatible (yet - compliant) implementations. - Code based on the POA, and conforming to the CORBA 2.2 - specification, is almost completely portable, - the only incompatibilities arising from the names of the - generated header files and and other minor things. - Those problems can be easily wrapped in helper classes, and the - file names can be controlled through IDL compiler options in - most cases. - </P> - <P>A server application may contain multiple POA instances, but all - server applications have at least one POA called the <I>RootPOA</I>. - <P>We have to implement the operations and attributes: - </P> -<PRE> -class Quoter_Stock_i : public POA_Quoter::Stock { -public: - // some details omitted - char *symbol () throw (CORBA::SystemException); - char *full_name () throw (CORBA::SystemException); - CORBA::Double price () throw (CORBA::SystemException); -}; - -// In the .cpp file: -char * -Quoter_Stock_i::symbol () throw (CORBA::SystemException) -{ - return CORBA::string_dup (this->symbol_.c_str ()); -} -</PRE> - <P>The other attributes and methods are similar, so we don't - reproduce them here. - </P> - <P>The first question is what are those <CODE>throw()</CODE> - specifications doing there? Any CORBA operation or attribute - can raise a <CODE>CORBA::SystemException</CODE>. The IDL compiler - must generate a throw specification that includes the CORBA - system exceptions and any user exceptions listed in the - <CODE>raise</CODE> clause. In turn, the C++ specification requires - that any derived classes cannot add exceptions to a throw - specification, so you must have a throw specification in your - methods, either including <CODE>CORBA::SystemException</CODE> or - empty. - </P> - - <H4>Memory management rules for arguments</H4> - - <P>It is important to copy the strings before returning them, - because the ORB will use <CODE>CORBA::string_free</CODE> to release - them. The rationale is that over the network, the string must be - copied anyway, hence, the client must be responsible for releasing - the received string. When both client and servers are in the same - address space the ORB can optimize the path and invoke the server - operation directly, without marshaling or demarshaling. If the - client is going to work with both local and remote servers, it - should always expect to own the string. In consequence, the server - implementation must always allocate a copy and return the copy, - because the server-side must also work identically for local and - remote clients. The memory management rules in CORBA are a bit - subtle, but there are some simple rules to follow: - <UL> - <LI>You must make a copy of the memory that you return. The - caller is going to release it. - </LI> - <LI>Conversely, you must release the memory returned to you. The - callee made a copy. - </LI> - <LI>You don't own the memory that you receive as input - arguments, - you can only use it for the duration of the call. - You must make a copy if you want to hold a reference to it - after you return. - </LI> - </UL> - The complete memory management rules can be found in the Henning and - Vinoski book or the CORBA specification. - </P> - - <P>Typing all this code seems tedious. Can't the IDL compiler - help with this? After all, it seems as if the method declarations - are completely specified! The answer is yes, TAO's IDL compiler - can generate empty implementations that you can modify. Simply - use the <KBD>-GI</KBD> option: -<PRE> -$ $ACE_ROOT/TAO/TAO_IDL/tao_idl -GI Quoter.idl -</PRE> - The empty implementations are generated in the - <CODE>QuoterI.h</CODE> and <CODE>QuoterI.cpp</CODE> files. - Be advised that the <CODE>-GI</CODE> option overwrites these files - every time, so it is better to copy your implementation to - another file. - </P> - - <H3>The Stock Factory implementation</H3> - - <P>Our first implementation of the factory will serve only two - stocks, "RHAT" and "MSFT": - </P> -<PRE> -class Quoter_Stock_Factory_i : public POA_Quoter::Stock_Factory -{ -public: - Quoter_Stock_Factory (); - - Quoter::Stock_ptr get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol); - -private: - Quoter_Stock_i rhat_; - Quoter_Stock_i msft_; -}; -</PRE> - - <P>The implementation of the <CODE>get_stock()</CODE> method is - simple, just compare the symbol name and return the appropriate - object reference: - </P> -<PRE> -Quoter::Stock_ptr -Quoter_Stock_Factory_i::get_stock (const char *symbol) - throw (Quoter::Invalid_Stock_Symbol) -{ - if (strcmp (symbol, "RHAT") == 0) { - return this->rhat_._this(); - } else if (strcmp (symbol, "MSFT") == 0) { - return this->msft_._this (); - } - throw Quoter::Invalid_Stock_Symbol (); -} -</PRE> - - <P>So what is that <CODE>_this()</CODE> method? In the POA mapping - the client-side stubs and server-side skeletons are not related - through inheritance. You must either explicitly activate the - servant (your implementation object) or use <CODE>_this()</CODE> to - activate it with its default POA. <CODE>_this()</CODE> creates and - registers a CORBA object under the RootPOA, and returns the created - object reference for the new object. We will discuss more about - explicit and implicit activation later, but at this point it is - important to remove any thoughts about converting pointers to - servants to object references or vice-versa, it just does not - work that way. - </P> - - <H3>Implementing a CORBA server</H3> - - <P>Now that we have all the object implementations in place, we - must create the server executable. We start with the ORB - initialization: - </P> -<PRE> -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); -</PRE> - - <P>On startup, the ORB starts the POA in the {<em>holding state</em>}, - where all requests received are not processed until the POA is - activated. Meanwhile the requests are stored to some - implementation limit. TAO sets this limit to 0, because queueing - is a severe source of overhead and unpredictability in real-time - systems. - </P> - <P>What does this means for us? Well, we have to activate the POA. - The process is a bit tedious. First we gain access to the - RootPOA: -<PRE> - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); -</PRE> - <P><CODE>resolve_initial_references()</CODE> is used to bootstrap - all kinds of services, like the Naming Service and the Trading - Service, but it is also used to gain access to other ORB - interfaces, such as the RootPOA, the Current objects, and the - Policy Managers. - </P> - <P>Now that we have gained access to the Root POA, we must obtain - its POA manager. The POA managers provide interfaces to activate - and deactivate one or more POAs: - </P> -<PRE> - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); -</PRE> - <P>and now we activate the POA: - </P> -<PRE> - poa_manager->activate (); -</PRE> - - <P>The shutdown process is similar to the client side, but now we - must also remember to destroy the POA. Putting all the code - above together, we get: - </P> -<PRE> -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // The application code goes here! - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &ex) { - std::cerr << "CORBA exception raised!" << std::endl; - } - return 0; -} -</PRE> - - <P>Now we create an instance of our stock factory implementation - and activate it using <CODE>_this()</CODE> - </P> -<PRE> - Quoter_Stock_Factory_i stock_factory_i; - - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); -</PRE> - <P>Next we convert the object reference into an IOR string, so it - can be used by the client: - </P> -<PRE> - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - std::cerr << ior.in () << std::endl; -</PRE> - - <P>There is only one final detail. We must run the ORB event loop - to start processing requests from the client: - </P> -<PRE> - orb->run (); -</PRE> - - <P>There are many details that we have left out from this server, - such as how to terminate the event loop, how to perform servant - memory management, orderly deactivation of servants, and the fact - is that it is not very flexible, but we have covered a number - of other things, and more importantly we can test the client - now! - </P> - - <H3>Exercise 1</H3> - - <P>Flesh out the implementation. You don't have to do it from - scratch, as we provide you with the following files: - <A HREF="Stock_i.h">Stock_i.h</A>, - <A HREF="Stock_i.cpp">Stock_i.cpp</A>, - <A HREF="Stock_Factory_i.h">Stock_Factory_i.h</A> - <A HREF="Stock_Factory_i.cpp">Stock_Factory_i.cpp</A>, - <A HREF="../Quoter.idl">Quoter.idl</A> - and the always useful - <A HREF="GNUmakefile.Quoter_Simple_Server">Makefile</A> - </P> - - <H4>Solution</H4> - - <P>Compare your solution with - <A HREF="server.cpp">server.cpp</A>. - </P> - - <H3>Testing</H3> - - <P>To test this application we need a - <A HREF="../Client/index.html">client</A>. - We just run both of them: -<PRE> -$ server > ior_file -$ client file://ior_file MSFT RHAT -</PRE> - Also test invalid symbols! - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:47:01 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Apr 1 15:03:38 PDT 2001 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/Simple/Server/server.cpp b/TAO/docs/tutorials/Quoter/Simple/Server/server.cpp deleted file mode 100644 index 150b59789bc..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/Server/server.cpp +++ /dev/null @@ -1,45 +0,0 @@ -// -// $Id$ -// - -#include "Stock_Factory_i.h" -#include "ace/streams.h" - -int main (int argc, char* argv[]) -{ - try { - // First initialize the ORB, that will remove some arguments... - CORBA::ORB_var orb = - CORBA::ORB_init (argc, argv, - "" /* the ORB name, it can be anything! */); - CORBA::Object_var poa_object = - orb->resolve_initial_references ("RootPOA"); - PortableServer::POA_var poa = - PortableServer::POA::_narrow (poa_object.in ()); - PortableServer::POAManager_var poa_manager = - poa->the_POAManager (); - poa_manager->activate (); - - // Create the servant - Quoter_Stock_Factory_i stock_factory_i; - - // Activate it to obtain the object reference - Quoter::Stock_Factory_var stock_factory = - stock_factory_i._this (); - - // Put the object reference as an IOR string - CORBA::String_var ior = orb->object_to_string (stock_factory.in ()); - // Print it out! - cout << ior.in () << endl; - - orb->run (); - - // Destroy the POA, waiting until the destruction terminates - poa->destroy (1, 1); - orb->destroy (); - } - catch (CORBA::Exception &) { - cerr << "CORBA exception raised!" << endl; - } - return 0; -} diff --git a/TAO/docs/tutorials/Quoter/Simple/index.html b/TAO/docs/tutorials/Quoter/Simple/index.html deleted file mode 100644 index 3cbac4318aa..00000000000 --- a/TAO/docs/tutorials/Quoter/Simple/index.html +++ /dev/null @@ -1,29 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - <head> - <title>Introduction</title> - <!-- $Id$ --> - <META HTTP-EQUIV="Refresh" CONTENT="1; URL=../index.html"> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Introduction</h3> - - <P>The real index to the TAO tutorial is - <A HREF="../index.html">here</A>, - this page should automatically redirect you there, - if not, click on the link. - </P> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 17:57:42 CST 1999 --> -<!-- hhmts start --> -Last modified: Sun Nov 28 23:07:26 CST 1999 -<!-- hhmts end --> - </body> -</html> diff --git a/TAO/docs/tutorials/Quoter/idl/Makefile.am b/TAO/docs/tutorials/Quoter/idl/Makefile.am deleted file mode 100644 index 5670be7df9e..00000000000 --- a/TAO/docs/tutorials/Quoter/idl/Makefile.am +++ /dev/null @@ -1,80 +0,0 @@ -## Process this file with automake to create Makefile.in -## -## $Id$ -## -## This file was generated by MPC. Any changes made directly to -## this file will be lost the next time it is generated. -## -## MPC Command: -## ../bin/mwc.pl -type automake -noreldefs TAO.mwc - -ACE_BUILDDIR = $(top_builddir)/.. -ACE_ROOT = $(top_srcdir)/.. -TAO_BUILDDIR = $(top_builddir) -TAO_IDL = ACE_ROOT=$(ACE_ROOT) TAO_ROOT=$(TAO_ROOT) $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDL_DEP = $(TAO_BUILDDIR)/TAO_IDL/tao_idl -TAO_IDLFLAGS = -Ge 1 -Wb,pre_include=ace/pre.h -Wb,post_include=ace/post.h -I$(TAO_ROOT) -I$(srcdir) -g $(ACE_BUILDDIR)/apps/gperf/src/gperf -TAO_ROOT = $(top_srcdir) - -## Makefile.Quoter_Idl_Lib.am - -BUILT_SOURCES = \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl \ - QuoterS_T.cpp \ - QuoterS_T.h \ - QuoterS_T.inl - -CLEANFILES = \ - Quoter-stamp \ - QuoterC.cpp \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.cpp \ - QuoterS.h \ - QuoterS.inl \ - QuoterS_T.cpp \ - QuoterS_T.h \ - QuoterS_T.inl - -QuoterC.cpp QuoterC.h QuoterC.inl QuoterS.cpp QuoterS.h QuoterS.inl QuoterS_T.cpp QuoterS_T.h QuoterS_T.inl: Quoter-stamp - -Quoter-stamp: $(srcdir)/Quoter.idl $(TAO_IDL_DEP) - $(TAO_IDL) $(TAO_IDLFLAGS) -Wb,export_macro=QUOTER_COMMON_Export -Wb,export_include=quoter_common_export.h -GT $(srcdir)/Quoter.idl - @touch $@ - -noinst_LTLIBRARIES = libQuoter_Idl_Lib.la - -libQuoter_Idl_Lib_la_CPPFLAGS = \ - -I$(ACE_ROOT) \ - -I$(ACE_BUILDDIR) \ - -I$(TAO_ROOT) \ - -I$(TAO_BUILDDIR) \ - -DQUOTER_COMMON_BUILD_DLL - -libQuoter_Idl_Lib_la_SOURCES = \ - QuoterC.cpp \ - QuoterS.cpp - -noinst_HEADERS = \ - Quoter.idl \ - QuoterC.h \ - QuoterC.inl \ - QuoterS.h \ - QuoterS.inl \ - QuoterS_T.cpp \ - QuoterS_T.h \ - QuoterS_T.inl \ - quoter_common_export.h - -## Clean up template repositories, etc. -clean-local: - -rm -f *~ *.bak *.rpo *.sym lib*.*_pure_* core core.* - -rm -f gcctemp.c gcctemp so_locations *.ics - -rm -rf cxx_repository ptrepository ti_files - -rm -rf templateregistry ir.out - -rm -rf ptrepository SunWS_cache Templates.DB diff --git a/TAO/docs/tutorials/Quoter/idl/Quoter.idl b/TAO/docs/tutorials/Quoter/idl/Quoter.idl deleted file mode 100644 index b707539eea3..00000000000 --- a/TAO/docs/tutorials/Quoter/idl/Quoter.idl +++ /dev/null @@ -1,56 +0,0 @@ -// -// $Id$ -// - -module Quoter -{ - exception Invalid_Stock_Symbol {}; - // Used to report an invalid stock name - - // Forward declare the Stock interface - interface Stock; - - interface Stock_Factory - { - // = TITLE - // A factory class for the stock quoter interfaces - // - // = DESCRIPTION - // Return the Quoter interfaces based on their names - // - Stock get_stock (in string stock_symbol) - raises (Invalid_Stock_Symbol); - }; - - interface Stock - { - // = TITLE - // A simple interface to query the name and price of stock - // - // = DESCRIPTION - // Return the price and name of a single stock - // - - readonly attribute string symbol; - // Get the stock symbol. - - readonly attribute string full_name; - // Get the name. - - double price (); - // Get the price - - }; - - // used by the event service - struct Event { - double price; - string symbol; - string full_name; - }; - - interface Modify_Stock : Stock { - void set_price (in double new_price); - }; - -}; diff --git a/TAO/docs/tutorials/Quoter/idl/Quoter_idl.mpc b/TAO/docs/tutorials/Quoter/idl/Quoter_idl.mpc deleted file mode 100644 index cc97a77a069..00000000000 --- a/TAO/docs/tutorials/Quoter/idl/Quoter_idl.mpc +++ /dev/null @@ -1,7 +0,0 @@ -// -*- MPC -*- -// $Id$ - -project(*Lib) : taoexe, portableserver { - dynamicflags += QUOTER_COMMON_BUILD_DLL - idlflags += -Wb,export_macro=QUOTER_COMMON_Export -Wb,export_include=quoter_common_export.h -GT -} diff --git a/TAO/docs/tutorials/Quoter/idl/quoter_common_export.h b/TAO/docs/tutorials/Quoter/idl/quoter_common_export.h deleted file mode 100644 index fa39fda25f1..00000000000 --- a/TAO/docs/tutorials/Quoter/idl/quoter_common_export.h +++ /dev/null @@ -1,40 +0,0 @@ - -// -*- C++ -*- -// $Id$ -// Definition for Win32 Export directives. -// This file is generated automatically by generate_export_file.pl -// ------------------------------ -#ifndef QUOTER_COMMON_EXPORT_H -#define QUOTER_COMMON_EXPORT_H - -#include "ace/config-all.h" - -#if defined (TAO_AS_STATIC_LIBS) -# if !defined (QUOTER_COMMON_HAS_DLL) -# define QUOTER_COMMON_HAS_DLL 0 -# endif /* ! QUOTER_COMMON_HAS_DLL */ -#else -# if !defined (QUOTER_COMMON_HAS_DLL) -# define QUOTER_COMMON_HAS_DLL 1 -# endif /* ! QUOTER_COMMON_HAS_DLL */ -#endif - -#if defined (QUOTER_COMMON_HAS_DLL) && (QUOTER_COMMON_HAS_DLL == 1) -# if defined (QUOTER_COMMON_BUILD_DLL) -# define QUOTER_COMMON_Export ACE_Proper_Export_Flag -# define QUOTER_COMMON_SINGLETON_DECLARATION(T) ACE_EXPORT_SINGLETON_DECLARATION (T) -# define QUOTER_COMMON_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) ACE_EXPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) -# else /* QUOTER_COMMON_BUILD_DLL */ -# define QUOTER_COMMON_Export ACE_Proper_Import_Flag -# define QUOTER_COMMON_SINGLETON_DECLARATION(T) ACE_IMPORT_SINGLETON_DECLARATION (T) -# define QUOTER_COMMON_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) ACE_IMPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) -# endif /* QUOTER_COMMON_BUILD_DLL */ -#else /* QUOTER_COMMON_HAS_DLL == 1 */ -# define QUOTER_COMMON_Export -# define QUOTER_COMMON_SINGLETON_DECLARATION(T) -# define QUOTER_COMMON_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) -#endif /* QUOTER_COMMON_HAS_DLL == 1 */ - -#endif /* QUOTER_COMMON_EXPORT_H */ - -// End of auto generated file. diff --git a/TAO/docs/tutorials/Quoter/index.html b/TAO/docs/tutorials/Quoter/index.html deleted file mode 100644 index d910ceafd98..00000000000 --- a/TAO/docs/tutorials/Quoter/index.html +++ /dev/null @@ -1,97 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> -<html> - - <head> - <title>Building a Stock Quoter with TAO - A Tutorial</title> - <!-- $Id$ --> - </head> - - <BODY text = "#000000" - link="#000fff" - vlink="#ff0f0f" - bgcolor="#ffffff"> - - <h3>Building a Stock Quoter with TAO - A Tutorial</h3> - - <P>The tutorial is organized around a single application, which - allows client applications to obtain stock quotes from a quote - service. This application is based on a series of - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html">Object Interconnections</A> - columns written by - <A HREF="http://www.cs.wustl.edu/~schmidt/">Doug Schmidt</A> - and <A HREF="http://www.iona.com/hyplan/vinoski/">Steve Vinoski</A> - for the - <A HREF="http://www.cs.wustl.edu/~schmidt/report.html">C++ Report</A> - magazine. - </P> - - <P>This tutorial builds up from simple client and server - applications to explore advanced TAO features, such as - <A HREF="http://www.cs.wustl.edu/~schmidt/report-doc.html#ami"> - asynchronous method invocation</A>, - <A HREF="http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col19.pdf"> - reliable oneways</A>, - the <A HREF="http://www.cs.wustl.edu/~schmidt/PDF/JSAC-98.pdf"> - real-time Events Service</A>, - the <A HREF="../../INS.html"> - Interoperable Naming Service</A> - support and much more. - </P> - - As you go through the tutorial, feel free to check out the source - files for which links are provided. If you choose to build and - run the example, however, use the files which are part of - the TAO source you <A - HREF="http://deuce.doc.wustl.edu/Download.html">download</a>. You can - find those source files in <CODE>$TAO_ROOT/docs/tutorials/Quoter</CODE>, - where there's also a Makefile to build them with. Downloading the files - individually from these links may result in source that does not build - since the online tutorials may use a different version of - ACE+TAO. <P> - - <HR> - - <OL> - <LI><A HREF="Simple/Client/index.html"> - Introduction - A very simple client</A> - </LI> - <LI><A HREF="Simple/Server/index.html"> - Introduction - A very simple server</A> - </LI> - <LI><A HREF="Simple/ImprovedServer/index.html"> - Introduction - Improving the server via POA policies for - explicit activation and user-defined object ids</A> - </LI> - <LI><A HREF="Simple/Persistent/index.html"> - Introduction - Improving the server via POA policies for - persistent object references</A> - </LI> - <LI><A HREF="Simple/Impl-Repo/index.html"> - Implementation Repository</A> - </LI> - <LI><A HREF="Naming_Service/index.html"> - TAO's Naming Service</A> - </LI> - <LI><A HREF="AMI/index.html"> - Asynchronous Method Invocation - CORBA for impatient clients</A> - </LI> - <LI><A HREF="On_Demand_Activation/index.html"> - On_Demand_Activation</A> - </LI> - <LI><A HREF="Event_Service/index.html"> - TAO's COS Event Service</A> - </LI> - <LI><A HREF="RT_Event_Service/index.html"> - TAO's RT Event Service</A> - </LI> - <li><a href="RTCORBA/docs/index.html" >RTCORBA</a></li> - </OL> - - <hr> - <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address> -<!-- Created: Sat Nov 27 15:25:06 CST 1999 --> -<!-- hhmts start --> -Last modified: Fri Aug 27 13:04:01 CDT 2004 -<!-- hhmts end --> - </body> -</html> |
