blob: 220792a024141cf8681193e550f1be3dec4ab099 (
plain)
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
|
Migrating from BOA to POA
Client side:
<ul>
<li>Very little has changed, and some have not needed any changes.</li>
<li>You'll have to insure that the Makefile includes .o's for both the server
and client; this is necessary to support collocation.</li>
</ul>
Server side:
<li>POA_init() is replaced with resolve_initial_references("RootPOA") followed
by a _narrow operation.</li
<li>The implementation no longer inherits from the client-side stub; they
inherit from PortableServer::ServantBase. The implications of this are (a) if
you want a object reference for that, you must use the _this() method.</li>
<li>Object ID's are assigned by the POA unless you activate the servant with a
specific ID; IDL_Cubit has examples on how to do this.</li>
<li>Unlike the BOA, the POA explicitly addresses the temporal nature of servants
and declares that a POA can service either transient or persistent servants
(not both). The root POA's (mandated, unchangeable) policy is "transient".
The implications of this are that in order for a client to be able to
manufacture an object reference on its own and use that to access an object,
the servant for that object must be registered with a POA whose policy is
"persistent". Thus, you must create a child POA with that policy and register
the servant with that POA. NOTE: when the POA declares something as
"persistent", it is only stating that the key is valid between different runs
of the server; it makes no claims that state or anything else is persistent.</li
<ul>
<li> Servants are not automatically activated, hence you must register
them by calling some of the activate_object* methods on a POA or
calling _this() on the servant; with the latest you have no control on
the ObjectId (which sometimes is good), and the POA must support the
right policies (the RootPOA does).</li>
<li>Servant constructors use to take a <const char*> parameter to set
they object id, this is not needed now, in fact in many cases they use
to pass this argument to the skeleton class: this will fail now.</li>
</ul>
This list is not intended to be exhaustive, but should give you a good
starting point. If you find things along the way which have to change and I
didn't note them, please send them to me. Perhaps we can work together on the
ultimate migration document.
|
