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
|
$Id$
The test in this directory utilizes the Interface Repository
as might be done in an application. This test is also the
only one in this suite that makes use of the Interface
Repository administration executable 'tao_ifr'.
The test must be run by executing the Perl scrip 'run_test.pl'.
The order of events is as follows:
(1) The Interface Repository service is started.
(2) The server proces is started. The server makes
available an object reference to an interface
called 'inventory', which exists in a namespace
called 'warehouse', and contains an operation
called 'getCDinfo'. The operation takes an IN
argument which is a string representing the
artist's name, and INOUT argument which is a
string representing the album title, and an OUT
argument which is a float representing the price.
The operation returns a boolean value indicating
whether or not the particular CD is in stock. All
this iformation is contained in the IDL file
'test.idl'.
(3) The Interface Repository administration executable
'tao_ifr' is executed on test.idl, which adds the
information in test.idl to the repository.
(4) The client process is started. The client performs
the following actions:
(a) Locates the Interface Repository by calling
resolve_initial_references ("InterfaceRepository"),
and narrowing.
(b) Gets the IOR of the target object. In a real
application, this would probably be done
through the Naming Service, but here the
IOR is read from the file where it was
stored by the server.
(c) The client then makes several calls to the
repository, first searching for an object
with the name 'warehouse'. Once this is
found, the client checks to see if 'warehouse'
may contain other objects. If so, it gets a
list of all the objects 'contained' by
warehouse which are interfaces. Each inteface's
name is checked to find one called 'inventory'.
Then the client gets a list of all inventory's
operations. Each of these is checked to find
one called 'getCDinfo'. The client then gets
the return type and a list of the operation's
parameters by querying the operation repository
object.
(d) The client creates a DII request pseudo-object,
sets its return type and adds parameters
according to the information extracted from
the operation repository object. Notice that
the client does not have the correct string for
the album title, but one that is commonly used
by people when referring to that album. The
server will try to be smart about this, and
match a substring of the given album title with
a substring of the real album title, returning
the corrected album title if it finds a match.
(e) The client invokes the DII request and displays
the results.
(5) The server is shut down.
(6) tao_ifr is again invoked on test.idl, this time with
the '-r' option, which removes the objects coresponding
to the contents of the IDL file from the repository.
(7) The repository is shut down.
By default, the client will call _get_interface() on the target
object to get its InterfaceDef from the respository, and then
query the IntefaceDef object to get information about its
operations and their parameters. If the command line option -n
is passed to the client (or to the Perl script), the client will
resolve the repository by a call to
orb->resolve_initial_references ("InterfaceRepository") and use
information it has (through some unspecified means) about the
local name of the interface and of its containing module,
to search the repository for the InterfaceDef of the target object,
and from there acquire the rest of the information the same way as
in the default case.
If the default method is used, the call to CORBA::Object::_get_interface()
requires that the server (specifically the generated skeleton code)
know about the TAO_IFR_Client library, since the implementation of
this method is not found in the TAO library, requiring as it does the
knowledge of the rather large IFR client interface. To dynamically load
the TAO_IFR_Client library (assuming it has been compiled), the
header file ACE_ROOT/TAO/tao/IFR_Client/IFR_Client_Adapter_Impl.h is
included in the application (in test_i.h) and TAO_IFR_Client added to
the list of linked libraries. This will force the static Initializer
function in the library to initialize all the IFR typecodes and to
load the library. Applications that don't need to call _get_interface
don't need to link this library and can thus keep the server-side
footprint smaller.
More information about the Interface Repository can be found in
TAO/docs/releasenotes/index.html.
|
