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
|
<!-- $Id$ -->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>ACE Tutorial 022</title>
</head>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#000FFF" VLINK="#FF0F0F">
<CENTER><B><FONT SIZE=+2>ACE Tutorial 022</FONT></B></CENTER>
<p>So, by now we have implemented our Acceptor Service: known how to
initialize, remove, suspend and resume our service. We have the
server daemon set up to run to accept requests. The only thing
that is left is the client_handler. We need to declare and define
the Client_Handler object. We will use the same <I><A
HREF="../005/Client_Handler.h">Client_Handler.h</A></I> and
<I><A HREF="../005/Client_Hander.cpp">Client_Handler.cpp</A></I>
that we used in our ACE Tutorial 005.</p>
<p>With this, we are done with everything that we want to get our
Acceptor Service dynamically configurable in addition to the
actual functionality of the Acceptor.</p>
<p>To compile, we can use the same <I><A
HREF="../005/Makefile">Makefile</A></I> that we used
previously and make appropriate changes for the new files that
we added. You could use this <I><A HREF="Makefile">Makefile</A></I>
<p>Now, lets compile it and be all set to configure our Acceptor
Service. Let us run our server to start acting as a daemon and
accept requests.</p>
<pre>$ ./server </pre>
<p>Obviously, we will want to load our service dynamically and see
if our Acceptor Service is running as we want it to. For this,
we need to make an entry in the svc.conf file.
<p>The Service Configurator framework reads the entries in the
svc.conf file in the working directory by default. According to
the entries in the svc.con file, the framework does the
needful. You could use a different name for the file like
server.conf but in that case, we need to explicitly specify to
the application the configuration file that has to be read using
the <I>-ORBSvcconf</I> option.
<p>Coming back to where we were, now we want to make an entry in
this svc.conf file to load our service. I will show you the
general format for this entry and then we will make our entry.</p>
A dynamic service could be initialized as:
<pre>dynamic service_name type_of_service * location_of_shared_lib:name_of_object "parameters" </pre>
and a static service is initialized as:
<pre> static service_name "parameters_sent_to_service_object" </pre>
<p>Lets start making our entry. The first keyword specifies if this
is a dynamic service or a static one. Since we want our service
to be a dynamically configurable one, the first parameter in our
entry will be <I>dynamic</I>. The next parameter is the name of
the service that we want to be loaded. This is the same name
that we specified in the ACE_STATIC_SVC_DEFINE macro. Since our
service name is Acceptor_Service, that becomes the second
parameter of our entry. The next argument is the type of the
service .. as we know already, there are two options:
Stream or Service_Object. And, we declared our service to be a
<I>Service_Object</I> in the ACE_STATIC_SVC_DEFINE macro. So, that
becomes the next parameter. The next entry is the location of
the shared library which has our service and that is
Acceptor_Server according to our Makefile. The next parameter is
the name of the object and finally the list of parameters that
we want to pass to our service. So, we are now erady to make our
entry in the svc.conf file to initialize our service.
<pre> dynamic Acceptor_Service Service_Object * ./Acceptor_Server:_make_Acceptor_Service () "" </pre>
<p>Now, we want to reconfigure so that our service will be
initialized. This could be done by sending a signal which would
be received eventually by the Reactor listening for requests and
it would invoke the ACE_Service::reconfigure () method which
does the reconfiguration of the services.
<pre>$ kill -1 PID_of_our_server </pre>
Now, that we know how to initialize our service and actually
initialized the service .. we could check if our service is
working good. Ofcourse, the debug statements we left in the init
method would help .. but to double check !! For this purpose, we
can use the simple client which we used in our ACE Tutorial
005. Just compile the <I><A
HREF="client/client.cpp">client.cpp</A></I> using this <A
HREF="client/Makefile">Makefile</A> and run it. You can see the
responses from the service.
<p>Now, we can check if we can suspend and resume and finally
remove the service. The entries for these functionalities are
very simple unlike the initialization entry.
<pre>$ suspend Acceptor_Service </pre>
<pre>$ resume Acceptor_Service </pre>
<pre>$ remove Acceptor_Service </pre>
<p>Lets first suspend the service by commenting out the entry for
the initialization and making the new entry for suspension in
the svc.conf file. Now, send a signal as before. The Reactor
will receive this event and suspend the service. Just to double
check, you could run our client again and see the response. </p>
<p>Now, to resume the service, the procedure is the same. Comment
out other entries and make the entry for the resumption of the
service. And finally, send a signal. Again, you could run the
client and see what is happening. But, even before running the
client, you must have noticed that as soon as you resumed the
service, you saw some response from the Acceptor_Service. This
is because, as I explained before, the Reactor will queue the
request when the service is in suspension mode and send the
service the queued requests as and when it is active again.
<p>Finally, lets remove our service.
<p>So, now we know how to implement a dynamically configurable
service and how to dynamically configure the service. </p>
<hr>
<address><a href="mailto:pgontla@ece.uci.edu">Priyanka Gontla</a></address>
<!-- Created: Fri Jan 19 10:19:46 PST 2001 -->
<!-- hhmts start -->
Last modified: Fri Jan 19 11:37:23 PST 2001
<!-- hhmts end -->
</body>
</html>
|
