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
|
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe PageMill 2.0 Mac">
<TITLE>Migrating from the BOA to the POA</TITLE>
</HEAD>
<BODY text = "#000000"
link="#0000ff"
vlink="#cc0000"
bgcolor="#ffffff">
<HR><P>
<H3>Migrating from BOA to POA</H3>
<UL>
<LI><EM><B>Client side</b></EM><P>
<ul>
<li>Very little has changed, and some have not needed any changes.</li><P>
<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> <P>
</ul>
<LI><EM><B>Server side</B></EM><P>
<UL>
<li>POA_init() is replaced with resolve_initial_references("RootPOA") followed
by a _narrow operation.</li><P>
<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><P>
<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><P>
<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><P>
<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><P>
<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><P>
</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. <P>
</UL>
</UL>
<hr><P>
Back to the <A
HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/index.html">TAO
documentation</A> page.
<!--#include virtual="/~schmidt/cgi-sig.html" -->
</BODY>
</html>
|