diff options
Diffstat (limited to 'TAO/docs/orbsvcs.html')
| -rw-r--r-- | TAO/docs/orbsvcs.html | 181 |
1 files changed, 0 insertions, 181 deletions
diff --git a/TAO/docs/orbsvcs.html b/TAO/docs/orbsvcs.html deleted file mode 100644 index f16fcafd7b5..00000000000 --- a/TAO/docs/orbsvcs.html +++ /dev/null @@ -1,181 +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>). - For this reason all the services stubs are grouped in one - library. - This library is located in - <CODE>$TAO_ROOT/orbsvcs/orbsvcs</CODE>. - Usually the include path is only <CODE>$TAO_ROOT/orbsvcs</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></TR> - <TR> - <TD>A/V Streams Service</TD><TD><CODE>orbsvcs/AV</CODE></TD></TR> - <TR> - <TD>Concurrency Service</TD><TD><CODE>orbsvcs/Concurrency</CODE></TD></TR> - <TR> - <TD>Event Service</TD><TD><CODE>orbsvcs/Event</CODE></TD></TR> - <TR> - <TD>LifeCycle Service</TD><TD><CODE>orbsvcs/LifeCycle</CODE></TD></TR> - <TR> - <TD>Logging Service</TD><TD><CODE>orbsvcs/Log</CODE></TD></TR> - <TR> - <TD>Naming Service</TD><TD><CODE>orbsvcs/Naming</CODE></TD></TR> - <TR> - <TD>Property Service</TD><TD><CODE>orbsvcs/Property</CODE></TD></TR> - <TR> - <TD>Scheduling Service</TD><TD><CODE>orbsvcs/Sched</CODE></TD></TR> - <TR> - <TD>Trading Service</TD><TD><CODE>orbsvcs/Trader</CODE></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. - The binaries in question are located in - <CODE>$TAO_ROOT/orbsvcs</CODE>, and the list includes: - </P> - - <UL> - <LI>Concurrenty_Service</LI> - <LI>Dump_Schedule</LI> - <LI>LifeCycle_Service</LI> - <LI>Event_Service</LI> - <LI>Naming_Service</LI> - <LI>Scheduling_Service</LI> - <LI>Trading_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>Finally the tests and example programs are located in - <CODE>$TAO_ROOT/orbsvcs/tests</CODE>; - once more each may involves more than a single binary, - so each one is kept in its own directory; - the following list describes the contents of each one: - </P> - - <P> - <TABLE BORDER="2" - CELLSPACING="2" - CELLPADDING= "0"> - <TR> - <TH>Test directory</TH> - <TH>Purpose</TH></TR> - <TR> - <TD><CODE>AVStreams</CODE></TD> - <TD>A complete A/V server and client.</TD></TR> - <TR> - <TD><CODE>Concurrency</CODE></TD> - <TD>Test the Concurrency Service.</TD></TR> - <TR> - <TD><CODE>Event_Latency</CODE></TD> - <TD>Test the Event Service and measure end-to-end latency, - it also uses the Scheduling and Naming services.</TD></TR> - <TR> - <TD><CODE>EC_Multiple</CODE></TD> - <TD>Connect two Event Channels using the - <CODE>EC_Gateway</CODE>, - measure latency, utilization and minimum spacing.</TD></TR> - <TR> - <TD><CODE>Logger</CODE></TD> - <TD>An example logging service using the Naming Service to - locate a factory.</TD></TR> - <TR> - <TD><CODE>Naming</CODE></TD> - <TD>An advanced test of the Naming Service.</TD></TR> - <TR> - <TD><CODE>Property</CODE></TD> - <TD>Testing for the Property Service.</TD></TR> - <TR> - <TD><CODE>Sched</CODE></TD> - <TD>A test of the Scheduling Service.</TD></TR> - <TR> - <TD><CODE>Simple_Naming</CODE></TD> - <TD>A very simple Naming Service test.</TD></TR> - <TR> - <TD><CODE>Simulator</CODE></TD> - <TD>Prototype implementation of DOVE (DOVE Agent, DOVE - Browser, DOVE MIB, DOVE Application). The DOVE Agent - consists of the Event Channel, which is then connected to - a DOVE Browser implemented in Java.</TD></TR> - <TR> - <TD><CODE>Trading_Service</CODE></TD> - <TD>Implementation of the Trading Service.</TD></TR> - </TABLE> - </P> - - <H2>SEE ALSO</H2> - - <P>You may you 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:coryan@macarena.cs.wustl.edu">Carlos O'Ryan</a></address> - </body> -</html> |