1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
|
<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/CosEvent</CODE></TD></TR>
<TR>
<TD>Real-time 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>
<TR>
<TD>Time Service</TD><TD><CODE>orbsvcs/Time</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>CosEvent_Service</LI>
<LI>Event_Service</LI>
<LI>Naming_Service</LI>
<LI>Scheduling_Service</LI>
<LI>Trading_Service</LI>
<LI>Time_Service</LI>
<LI>ImplRepo_Service *(see below)*</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 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>CosEC_Basic</CODE></TD>
<TD>Test the basic functionality of the standard Event
Service.
</TD>
</TR>
<TR>
<TD><CODE>CosEC_Multiple</CODE></TD>
<TD>Simple example that connects multiple consumers and/or
suppliers to the standard event service. It can be used to
show how composing a standard event-service and the
real-time event service provides filtering capabilities.
</TD>
</TR>
<TR>
<TD><CODE>EC_Basic</CODE></TD>
<TD>Test the basic functionality of the real-time Event
Service.
</TD>
</TR>
<TR>
<TD><CODE>EC_Custom_Marshal</CODE></TD>
<TD>Show how the Real-time event service can send user
defined data using custom marshaling.
</TD>
</TR>
<TR>
<TD><CODE>EC_Mcast</CODE></TD>
<TD>Multiple real-time event channels can communicate using
multicast, this example shows how to do it.
</TD>
</TR>
<TR>
<TD><CODE>EC_Multiple</CODE></TD>
<TD>Connect two Real-time Event Channels using the
<CODE>EC_Gateway</CODE>,
measure latency, utilization and minimum spacing.
</TD>
</TR>
<TR>
<TD><CODE>EC_Throughput</CODE></TD>
<TD>Measure throughput and latency for collocated and remote
real-time event services.
</TD>
</TR>
<TR>
<TD><CODE>Event_Latency</CODE></TD>
<TD>Test the Real-time Event Service and measure end-to-end latency,
it also uses the Scheduling and Naming services.</TD></TR>
<TR>
<TD><CODE>ImplRepo</CODE></TD>
<TD>Tests used to test the functionality of the
Implementation Repository Service.</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</CODE></TD>
<TD>Tests for the Trading Service.</TD></TR>
<TR>
<TD><CODE>Time</CODE></TD>
<TD> A test for the Time 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>
|
