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
253
254
255
256
257
258
259
260
261
262
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>Persistent Objects</title>
<!-- $Id$ -->
</head>
<BODY text = "#000000"
link="#000fff"
vlink="#ff0f0f"
bgcolor="#ffffff">
<h1>Introduction - Improving the Server</h1>
<P>In this section, we will improve the <a href = ../server.cpp>
simple server</a> which we have developed before. We will use POA policies
to create a persistent object reference. </P>
<P>
The characteristics of a POA are controlled via POA policies. These POA
policies are specified when the POA is created. POA policies have the
same form: their values are specified using an enumerated type. One such
policy is the LifeSpanPolicy.The LifespanPolicyValue can be Transient or
Persistent.
</P>
<P> CORBA objects that can live irrespective of any particular process in
which they are created or activated are called Persistent Objects.
The shorter-lived objects whose life time is bounded by the lifetime of
the POA in which they are created are called Transient Objects.
</P>
<P> The standard life span policy for the RootPOA is Transient. This means
that any application that needs to support persistent objects must create
at least another POA with the Persistent life span policy.
</P>
<P> Lets create a new child POA with the RootPOA as its
parent. We will create two policies for this childPOA. One policy is the
Life Span Policy which we will set to be Persistent. The second policy
is the Id Assignment Policy.
</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. Else, if this policy value is set to be
<CODE>SYSTEM_ID</CODE>, the RootPOA creates the ObjectIDs. Lets give our
application a choice for the creation of its Object's IDs.
</P>
<P>For more about POA and its policies, please refer Advanced CORBA
Programming with C++ by Henning and Vinoski. There are many examples in
<CODE>$TAO_ROOT/examples/POA/</CODE> that show how to use the other
policies in the POA.
</P>
<H3> Child POA Creation </H3>
As before we first initialize the ORB, get a reference to the Root POA.
<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>
Next get the POAManager of the RootPOA and activate it.
<PRE>
PortableServer::POAManager_var poa_manager =
poa->the_POAManager ();
poa_manager->activate ();
</PRE>
<P>The policies of a POA are stored in a sequence. Lets first create a
CORBA::PolicyList sequence. Since we are creating two policies, lets
initialize its length to be 2.
</P>
<PRE>
CORBA::PolicyList polices;
policies.length (2);
</PRE>
<P> Now to create a LifeSpanPolicy Object and an IdAssignmentpolicy Object.
We use the <CODE>create_lifespan_policy</CODE> operation of the Root POA
to create a LifespanPolicy object.Since we want the POA to be
<CODE>PERSISTENT</CODE>, we pass the same as its value. For creating the
IdAssignmentPolicy object, we use the
<CODE>create_id_assignment_policy</CODE> operation of the Root POA and
pass <CODE>USER_ID</CODE> as its value.
</P>
<PRE>
// Create a PERSISTENT LifespanPolicy object
PortableServer::LifespanPolicy_var lifespan =
poa->create_lifespan_policy (PortableServer::PERSISTENT);
// Create a USER_ID IdAssignmentPolicy object
PortableServer::IdAssignmentPolicy_var idassignment =
poa->create_id_assignment_policy (PortableServer::USER_ID);
</PRE>
<P>Now that we have created the respective objects, we copy our reference
to these objects into the policy list.
</P>
<PRE>
policies[0] =
PortableServer::IdAssignmentPolicy::_duplicate (idassignment);
policies[1] =
PortableServer::LifespanPolicy::_duplicate (lifespan);
</PRE>
<P> Now lets come to the actual creation of the child POA. We create a POA
by invoking the <CODE>create_POA</CODE> on the POA for which we want to
create the new child POA. Here, in our case, the RootPOA is the parent
POA and the child POA is its child. So, we will invoke the
<CODE>create_POA</CODE> operation on the RootPOA.
</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>. Here, we have the POAManager of its
parent, i.e. the RootPOAs POAManager, as the childPOA's POAManager.
</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, lets 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>Now, we have to activate it. One of the most easy ways to
activate an object is to use the POA object activation operations. One
of the two operations is the <CODE>activate_object_with_id ()</CODE>
operation. This operation has two input parameters: the Objects Id and
the servant to incarnate the object. So, for this, we have to first
get the ObjectId.
</P>
<PRE>
PortableServer::ObjectId_var oid =
PortableServer::string_to_ObjectId ("Stock_Factory");
</PRE>
<P>Here, we have used the <CODE>string_to_ObjectId</CODE> helper function
to convert the string "Stock_Factory" into an ObjectId. Now we can
activate the "Stock_Factory" object.
</P>
<PRE>
child_poa->activate_object_with_id (oid.in (),
&stock_factory_i);
</PRE>
<P>This operation doesnt return the object reference of the new object. One
way to get the object reference is to invoke the
<CODE>id_to_reference</CODE> operation on the POA after activating the
object.
</P>
<PRE>
CORBA::Object_var stock_factory =
child_poa->id_to_reference (oid.in ());
</PRE>
<P>Next, 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.And then to 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=../Simple/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://doc.ece.uci.edu:12345 > server.ref &
[1] 6933
</PRE>
<P>What we did here is telling the server ORB to listen for requests on the
interface specified by the endpoint.For example, for the IIOP protocol,
the endpoint information contains an Internet domain name or IP address
and a TCP port number, basically in
<CODE>iiop://hostname:port</CODE> format.
</P>
<P> Now, for the client part.
</P>
<PRE>
$ ./client file://server.ref MSFT RHAT
</PRE>
<P>For testing the persistency of the POA, lets kill the server. Then
direct the object reference into a new foo.ref.
</P>
<PRE>
$ kill %1
$ ./server -ORBENDPOINT iiop://doc.ece.uci.edu: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 donot tell the server to listen from the same port?
Lets compile and run as we did in our simple server.
</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>
<P> A CORBA exception is raised saying that the object is a Transient one.
Since if the port is not specified, the ORB will listen to a random empty
port each time a new request arrives. Thsi results in the object being
transient.
</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: Fri Mar 24 10:35:20 PST 2000
<!-- hhmts end -->
</body>
</html>
|
