summaryrefslogtreecommitdiff
path: root/docs/tutorials/022/page05.html
diff options
context:
space:
mode:
Diffstat (limited to 'docs/tutorials/022/page05.html')
-rw-r--r--docs/tutorials/022/page05.html130
1 files changed, 0 insertions, 130 deletions
diff --git a/docs/tutorials/022/page05.html b/docs/tutorials/022/page05.html
deleted file mode 100644
index 5b14622b2c4..00000000000
--- a/docs/tutorials/022/page05.html
+++ /dev/null
@@ -1,130 +0,0 @@
-<!-- $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>