<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.05">
<TITLE>
The Basics
</TITLE>
</HEAD>
<BODY >
<A HREF="omniORBpy001.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="omniORBpy003.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>
<H1>Chapter 2 The Basics</H1>
<A NAME="chap:basics"></A>In this chapter, we go through three examples to illustrate the
practical steps to use omniORBpy. By going through the source code of
each example, the essential concepts and APIs are introduced. If you
have no previous experience with using CORBA, you should study this
chapter in detail. There are pointers to other essential documents you
should be familiar with.<BR>
<BR>
If you have experience with using other ORBs, you should still go
through this chapter because it provides important information about
the features and APIs that are necessarily omniORB specific.<BR>
<BR>
<A NAME="toc3"></A>
<H2>2.1 The Echo example</H2>We use an example which is similar to the one used in the omniORB
manual. We define an interface, called <TT>Example::Echo</TT>, as
follows:<BR>
<BR>
<PRE>
// echo_example.idl
module Example {
interface Echo {
string echoString(in string mesg);
};
};
</PRE>The important difference from the omniORB Echo example is that our
<TT>Echo</TT> interface is declared within an IDL module named
<TT>Example</TT>. The reason for this will become clear in a moment.<BR>
<BR>
If you are new to IDL, you can learn about its syntax in Chapter 3 of
the CORBA specification 2.3 [<A HREF="omniORBpy009.html#corba23-spec"><CITE>OMG99</CITE></A>]. For the moment, you
only need to know that the interface consists of a single operation,
<TT>echoString()</TT>, which takes a string as an argument and returns a
copy of the same string.<BR>
<BR>
The interface is written in a file, called <TT>echo_example.idl</TT>. It
is part of the CORBA standard that all IDL files should have the
extension `<TT>.idl</TT>', although omniORB does not enforce this.<BR>
<BR>
<A NAME="toc4"></A>
<H2>2.2 Generating the Python stubs</H2>
<A NAME="sec:generatingStubs"></A>From the IDL file, we use the IDL compiler, omniidl, to produce the
Python stubs for that IDL. The stubs contain Python declarations for
all the interfaces and types declared in the IDL, as required by the
Python mapping. It is possible to generate stubs dynamically at
run-time, as described in section <A HREF="omniORBpy006.html#sec:importIDL">6.12</A>, but it is more
efficient to generate them statically.<BR>
<BR>
To generate the stubs, we use a command line like<BR>
<BR>
<BLOCKQUOTE>
<TT>omniidl -bpython echo_example.idl</TT>
</BLOCKQUOTE>As required by the standard, that produces two Python
packages derived from the module name <TT>Example</TT>. Directory
<TT>Example</TT> contains the client-side definitions (and also the type
declarations if there were any); directory <TT>Example__POA</TT>
contains the server-side skeletons. This explains the difficulty with
declarations at IDL global scope; section <A HREF="#sec:globalIDL">2.7</A> explains
how to access global declarations.<BR>
<BR>
If you look at the Python code in the two packages, you will see that
they are almost empty. They simply import the
<TT>echo_example_idl.py</TT> file, which is where both the client and
server side declarations actually live. This arrangement is so that
omniidl can easily extend the packages if other IDL files add
declarations to the same IDL modules.<BR>
<BR>
<A NAME="toc5"></A>
<H2>2.3 Object References and Servants</H2>We contact a CORBA object through an <I>object reference</I>. The
actual implementation of a CORBA object is termed a <I>servant</I>.<BR>
<BR>
Object references and servants are quite separate entities, and it is
important not to confuse the two. Client code deals purely with object
references, so there can be no confusion; object implementation code
must deal with both object references and servants. You will get a
run-time error if you use a servant where an object reference is
expected, or vice-versa.<BR>
<BR>
<A NAME="toc6"></A>
<H2>2.4 Example 1 --- Colocated client and servant</H2>
<A NAME="sec:eg1"></A>In the first example, both the client and servant are in the same
address space. The next sections show how the client and servant can
be split between different address spaces.<BR>
<BR>
First, the code:<BR>
<BR>
<PRE>
1 #!/usr/bin/env python
2
3 import sys
4 from omniORB import CORBA, PortableServer
5 import Example, Example__POA
6
7 class Echo_i (Example__POA.Echo):
8 def echoString(self, mesg):
9 print "echoString() called with message:", mesg
10 return mesg
11
12 orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
13 poa = orb.resolve_initial_references("RootPOA")
14
15 ei = Echo_i()
16 eo = ei._this()
17
18 poaManager = poa._get_the_POAManager()
19 poaManager.activate()
20
21 message = "Hello"
22 result = eo.echoString(message)
23
24 print "I said '%s'. The object said '%s'." % (message,result)
</PRE>The example illustrates several important interactions among the ORB,
the POA, the servant, and the client. Here are the details:<BR>
<BR>
<H3>2.4.1 Imports</H3><DL COMPACT=compact>
<DT>Line 3<DD><BR>Import the <TT>sys</TT> module to access <TT>sys.argv</TT>.<BR>
<BR>
<DT>Line 4<DD><BR>Import omniORB's implementations of the <TT>CORBA</TT> and
<TT>PortableServer</TT> modules. The standard requires that these
modules are available outside of any package, so you can also do<BR>
<BR>
<PRE>
import CORBA, PortableServer
</PRE>Explicitly specifying omniORB is useful if you have more
than one Python ORB installed.<BR>
<BR>
<DT>Line 5<DD><BR>Import the client-side stubs and server-side skeletons generated for
IDL module <TT>Example</TT>.</DL>
<H3>2.4.2 Servant class definition</H3><DL COMPACT=compact>
<DT>Lines 7--10<DD><BR>For interface <TT>Example::Echo</TT>, omniidl produces a skeleton class
named <TT>Example__POA.Echo</TT>. Here we define an implementation
class, <TT>Echo_i</TT>, which derives from the skeleton class.<BR>
<BR>
There is little constraint on how you design your implementation
class, except that it has to inherit from the skeleton class and must
implement all of the operations declared in the IDL. Note that since
Python is a dynamic language, errors due to missing operations and
operations with incorrect type signatures are only reported when
someone tries to call those operations.</DL>
<H3>2.4.3 ORB initialisation</H3><DL COMPACT=compact>
<DT>Line 12<DD><BR>The ORB is initialised by calling the <TT>CORBA.ORB_init()</TT> function.
<TT>ORB_init()</TT> is passed a list of command-line arguments, and
an ORB identifier. The ORB identifier should be `omniORB3' or
`omniORB2', depending on which version of omniORB you are using. It is
usually best to use <TT>CORBA.ORB_ID</TT>, which is initialised to a
suitable string.<BR>
<BR>
<TT>ORB_init()</TT> processes any command-line arguments which begin with
the string `<TT>-ORB</TT>', and removes them from the argument
list. See section <A HREF="omniORBpy006.html#sec:ORBargs">6.1</A> for details. If any arguments are
invalid, or other initialisation errors occur (such as errors in the
configuration file), the <TT>CORBA.INITIALIZE</TT> exception is raised.</DL>
<H3>2.4.4 Obtaining the Root POA</H3><DL COMPACT=compact>
<DT>Line 13<DD><BR>To activate our servant object and make it available to clients, we
must register it with a POA. In this example, we use the <I>Root
POA</I>, rather than creating any child POAs. The Root POA is found with
<TT>orb.resolve_initial_references()</TT>.<BR>
<BR>
A POA's behaviour is governed by its <I>policies</I>. The Root POA has
suitable policies for many simple servers. Chapter 11 of the CORBA 2.3
specification [<A HREF="omniORBpy009.html#corba23-spec"><CITE>OMG99</CITE></A>] has details of all the POA policies
which are available.<BR>
<BR>
When omniORBpy is used with omniORB 2.8, <EM>only</EM> the Root POA is
available (and is mapped to the omniORB BOA). You cannot create child
POAs or alter policies.</DL>
<H3>2.4.5 Object initialisation</H3><DL COMPACT=compact>
<DT>Line 15<DD><BR>An instance of the Echo servant object is created.<BR>
<BR>
<DT>Line 16<DD><BR>The object is implicitly activated in the Root POA, and an object
reference is returned, using the <TT>_this()</TT> method.<BR>
<BR>
One of the important characteristics of an object reference is that it
is completely location transparent. A client can invoke on the object
using its object reference without any need to know whether the
servant object is colocated in the same address space or is in a
different address space.<BR>
<BR>
In the case of colocated client and servant, omniORB is able to
short-circuit the client calls so they do not involve IIOP. The calls
still go through the POA, however, so the various POA policies affect
local calls in the same way as remote ones. This optimisation is
applicable not only to object references returned by <TT>_this()</TT>, but
to any object references that are passed around within the same
address space or received from other address spaces via IIOP calls.</DL>
<H3>2.4.6 Activating the POA</H3><DL COMPACT=compact>
<DT>Lines 18--19<DD><BR>POAs are initially in the <I>holding</I> state, meaning that incoming
requests are blocked. Lines 18 and 19 acquire a reference to the POA's
POA manager, and use it to put the POA into the <I>active</I> state.
Incoming requests are now served.</DL>
<H3>2.4.7 Performing a call</H3><DL COMPACT=compact>
<DT>Line 22<DD><BR>At long last, we can call the object's <TT>echoString()</TT> operation.
Even though the object is local, the operation goes through the ORB
and POA, so the types of the arguments can be checked, and any mutable
arguments can be copied. This ensures that the semantics of local and
remote calls are identical. If any of the arguments (or return values)
are of the wrong type, a <TT>CORBA.BAD_PARAM</TT> exception is raised.</DL><A NAME="toc7"></A>
<H2>2.5 Example 2 --- Different Address Spaces</H2>In this example, the client and the object implementation reside in
two different address spaces. The code of this example is almost the
same as the previous example. The only difference is the extra work
which needs to be done to pass the object reference from the object
implementation to the client.<BR>
<BR>
The simplest (and quite primitive) way to pass an object reference
between two address spaces is to produce a <I>stringified</I> version
of the object reference and to pass this string to the client as a
command-line argument. The string is then converted by the client
into a proper object reference. This method is used in this
example. In the next example, we shall introduce a better way of
passing the object reference using the CORBA Naming Service.<BR>
<BR>
<H3>2.5.1 Object Implementation: Generating a Stringified Object Reference</H3>
<PRE>
1 #!/usr/bin/env python
2
3 import sys
4 from omniORB import CORBA, PortableServer
5 import Example, Example__POA
6
7 class Echo_i (Example__POA.Echo):
8 def echoString(self, mesg):
9 print "echoString() called with message:", mesg
10 return mesg
11
12 orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
13 poa = orb.resolve_initial_references("RootPOA")
14
15 ei = Echo_i()
16 eo = ei._this()
17
18 print orb.object_to_string(eo)
19
20 poaManager = poa._get_the_POAManager()
21 poaManager.activate()
22
23 orb.run()
</PRE>Up until line 18, this example is identical to the colocated case. On
line 18, the ORB's <TT>object_to_string()</TT> operation is called. This
results in a string starting with the signature `IOR:' and followed by
some hexadecimal digits. All CORBA 2 compliant ORBs are able to
convert the string into its internal representation of a so-called
Interoperable Object Reference (IOR). The IOR contains the location
information and a key to uniquely identify the object implementation
in its own address space<A NAME="text4" HREF="#note4"><SUP><FONT SIZE=2>1</FONT></SUP></A>. From the IOR, an object
reference can be constructed.<BR>
<BR>
After the POA has been activated, <TT>orb.run()</TT> is called. Since
omniORB is fully multi-threaded, it is not actually necessary to call
<TT>orb.run()</TT> for operation dispatch to happen---if the main program
had some other work to do, it could do so, and remote invocations
would be dispatched in separate threads. However, in the absence of
anything else to do, <TT>orb.run()</TT> is called so the thread blocks
rather than exiting immediately when the end-of-file is reached.
<TT>orb.run()</TT> stays blocked until the ORB is shut down.<BR>
<BR>
<H3>2.5.2 Client: Using a Stringified Object Reference</H3>
<A NAME="clnt2"></A>
<PRE>
1 #!/usr/bin/env python
2
3 import sys
4 from omniORB import CORBA
5 import Example
6
7 orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
8
9 ior = sys.argv[1]
10 obj = orb.string_to_object(ior)
11
12 eo = obj._narrow(Example.Echo)
13
14 if eo is None:
15 print "Object reference is not an Example::Echo"
16 sys.exit(1)
17
18 message = "Hello from Python"
19 result = eo.echoString(message)
20
21 print "I said '%s'. The object said '%s'." % (message,result)
</PRE>The stringified object reference is passed to the client as a
command-line argument<A NAME="text5" HREF="#note5"><SUP><FONT SIZE=2>2</FONT></SUP></A>. The client uses the ORB's
<TT>string_to_object()</TT> function to convert the string into a generic
object reference (<TT>CORBA.Object</TT>).<BR>
<BR>
On line 12, the object's <TT>_narrow()</TT> function is called to convert
the <TT>CORBA.Object</TT> reference into an <TT>Example.Echo</TT>
reference. If the IOR was not actually of type <TT>Example.Echo</TT>, or
something derived from it, <TT>_narrow()</TT> returns <TT>None</TT>.<BR>
<BR>
In fact, since Python is a dynamically-typed language,
<TT>string_to_object()</TT> is often able to return an object reference of
a more derived type than <TT>CORBA.Object</TT>. See
section <A HREF="omniORBpy003.html#sec:narrowing">3.1</A> for details.<BR>
<BR>
<H3>2.5.3 System exceptions</H3>The keep it short, the client code shown above performs no exception
handling. A robust client (and server) should do, since there are a
number of system exceptions which can arise.<BR>
<BR>
As already mentioned, <TT>ORB_init()</TT> can raise the
<TT>CORBA.INITIALIZE</TT> exception if the command line arguments or
configuration file are invalid. <TT>string_to_object()</TT> can
raise two exceptions: if the string is not an IOR (or a valid URI with
omniORB 3), it raises <TT>CORBA.BAD_PARAM</TT>; if the string looks
like an IOR, but contains invalid data, is raises
<TT>CORBA.MARSHAL</TT>.<BR>
<BR>
The call to <TT>echoString()</TT> can result in any of the CORBA system
exceptions, since any exceptions not caught on the server side are
propagated back to the client. Even if the implementation of
<TT>echoString()</TT> does not raise any system exceptions itself, failures
in invoking the operation can cause a number of exceptions. First, if
the server process cannot be contacted, a <TT>CORBA.COMM_FAILURE</TT>
exception is raised. Second, if the server process <EM>can</EM> be
contacted, but the object in question does not exist there, a
<TT>CORBA.OBJECT_NOT_EXIST</TT> exception is raised. Various events
can also cause <TT>CORBA.TRANSIENT</TT> to be raised. If that occurs,
omniORB's default behaviour is to automatically retry the invocation,
with exponential back-off.<BR>
<BR>
As explained later in section <A HREF="omniORBpy003.html#sec:narrowing">3.1</A>, the call to
<TT>_narrow()</TT> may also involve a call to the object to confirm its
type. This means that <TT>_narrow()</TT> can also raise
<TT>CORBA.COMM_FAILURE</TT>, <TT>CORBA.OBJECT_NOT_EXIST</TT>, and
<TT>CORBA.TRANSIENT</TT>.<BR>
<BR>
Section <A HREF="omniORBpy006.html#sec:exHandlers">6.10</A> describes how exception handlers can be
installed for all the various system exceptions, to avoid surrounding
all code with <TT>try</TT>...<TT>except</TT> blocks.<BR>
<BR>
<H3>2.5.4 Lifetime of a CORBA object</H3>CORBA objects are either <I>transient</I> or <I>persistent</I>. The
majority are transient, meaning that the lifetime of the CORBA object
(as contacted through an object reference) is the same as the lifetime
of its servant object. Persistent objects can live beyond the
destruction of their servant object, the POA they were created in, and
even their process. Persistent objects are, of course, only
contactable when their associated servants are active, or can be
activated by their POA with a servant manager<A NAME="text6" HREF="#note6"><SUP><FONT SIZE=2>3</FONT></SUP></A>. A reference to
a persistent object can be published, and will remain valid even if
the server process is restarted.<BR>
<BR>
A POA's Lifespan Policy determines whether objects created within it
are transient or persistent. The Root POA has the <TT>TRANSIENT</TT>
policy. (Note that since only the Root POA is available when using
omniORBpy with omniORB 2.8, it is not possible to create persistent
objects in that environment.)<BR>
<BR>
An alternative to creating persistent objects is to register object
references in a <I>naming service</I> and bind them to fixed
pathnames. Clients can bind to the object implementations at runtime
by asking the naming service to resolve the pathnames to the object
references. CORBA defines a standard naming service, which is a
component of the Common Object Services (COS) [<A HREF="omniORBpy009.html#corbaservices"><CITE>OMG98</CITE></A>],
that can be used for this purpose. The next section describes an
example of how to use the COS Naming Service.<BR>
<BR>
<A NAME="toc8"></A>
<H2>2.6 Example 3 --- Using the Naming Service</H2>
<A NAME="sec:usingNS"></A>In this example, the object implementation uses the Naming
Service [<A HREF="omniORBpy009.html#corbaservices"><CITE>OMG98</CITE></A>] to pass on the object reference to the
client. This method is far more practical than using stringified
object references. The full listings of the server and client are
below.<BR>
<BR>
The names used by the Naming service consist of a sequence of
<I>name components</I>. Each name component has an <I>id</I> and a
<I>kind</I> field, both of which are strings. All name components
except the last one are bound to <I>naming contexts</I>. A naming
context is analogous to a directory in a filing system: it can contain
names of object references or other naming contexts. The last name
component is bound to an object reference.<BR>
<BR>
Sequences of name components can be represented as a flat string,
using `.' to separate the id and kind fields, and `/' to separate name
components from each other<A NAME="text7" HREF="#note7"><SUP><FONT SIZE=2>4</FONT></SUP></A>. In our example, the Echo object
reference is bound to the stringified name
`<TT>test.my_context/ExampleEcho.Object</TT>'.<BR>
<BR>
The kind field is intended to describe the name in a
syntax-independent way. The naming service does not interpret, assign,
or manage these values. However, both the name and the kind attribute
must match for a name lookup to succeed. In this example, the kind
values for <TT>test</TT> and <TT>ExampleEcho</TT> are chosen to be
`<TT>my_context</TT>' and `<TT>Object</TT>' respectively. This is an
arbitrary choice as there is no standardised set of kind values.<BR>
<BR>
<H3>2.6.1 Obtaining the Root Context object reference</H3>
<A NAME="resolveinit"></A>The initial contact with the Naming Service can be established via the
<I>root</I> context. The object reference to the root context is
provided by the ORB and can be obtained by calling
<TT>resolve_initial_references()</TT>. The following code fragment shows
how it is used:<BR>
<BR>
<PRE>
import CosNaming
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
obj = orb.resolve_initial_references("NameService");
cxt = obj._narrow(CosNaming.NamingContext)
</PRE>Remember, omniORB constructs its internal list of initial references
at initialisation time using the information provided in the
configuration file <TT>omniORB.cfg</TT>, or given on the command
line. If this file is not present, the internal list will be empty and
<TT>resolve_initial_references()</TT> will raise a
<TT>CORBA.ORB.InvalidName</TT> exception.<BR>
<BR>
Note that, like <TT>string_to_object()</TT>,
<TT>resolve_initial_references()</TT> returns base <TT>CORBA.Object</TT>, so
we should narrow it to the interface we want. In this case, we want
<TT>CosNaming.NamingContext</TT><A NAME="text8" HREF="#note8"><SUP><FONT SIZE=2>5</FONT></SUP></A>.<BR>
<BR>
<H3>2.6.2 The Naming Service interface</H3>It is beyond the scope of this chapter to describe in detail the
Naming Service interface. You should consult the CORBA services
specification [<A HREF="omniORBpy009.html#corbaservices"><CITE>OMG98</CITE></A>] (chapter 3).<BR>
<BR>
<H3>2.6.3 Server code</H3>Hopefully, the server code is self-explanatory:<BR>
<BR>
<PRE>
#!/usr/bin/env python
import sys
from omniORB import CORBA, PortableServer
import CosNaming, Example, Example__POA
# Define an implementation of the Echo interface
class Echo_i (Example__POA.Echo):
def echoString(self, mesg):
print "echoString() called with message:", mesg
return mesg
# Initialise the ORB and find the root POA
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
poa = orb.resolve_initial_references("RootPOA")
# Create an instance of Echo_i and an Echo object reference
ei = Echo_i()
eo = ei._this()
# Obtain a reference to the root naming context
obj = orb.resolve_initial_references("NameService")
rootContext = obj._narrow(CosNaming.NamingContext)
if rootContext is None:
print "Failed to narrow the root naming context"
sys.exit(1)
# Bind a context named "test.my_context" to the root context
name = [CosNaming.NameComponent("test", "my_context")]
try:
testContext = rootContext.bind_new_context(name)
print "New test context bound"
except CosNaming.NamingContext.AlreadyBound, ex:
print "Test context already exists"
obj = rootContext.resolve(name)
testContext = obj._narrow(CosNaming.NamingContext)
if testContext is None:
print "test.mycontext exists but is not a NamingContext"
sys.exit(1)
# Bind the Echo object to the test context
name = [CosNaming.NameComponent("ExampleEcho", "Object")]
try:
testContext.bind(name, eo)
print "New ExampleEcho object bound"
except CosNaming.NamingContext.AlreadyBound:
testContext.rebind(name, eo)
print "ExampleEcho binding already existed -- rebound"
# Activate the POA
poaManager = poa._get_the_POAManager()
poaManager.activate()
# Block for ever (or until the ORB is shut down)
orb.run()
</PRE>
<H3>2.6.4 Client code</H3>Hopefully the client code is self-explanatory too:<BR>
<BR>
<PRE>
#!/usr/bin/env python
import sys
from omniORB import CORBA
import CosNaming, Example
# Initialise the ORB
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
# Obtain a reference to the root naming context
obj = orb.resolve_initial_references("NameService")
rootContext = obj._narrow(CosNaming.NamingContext)
if rootContext is None:
print "Failed to narrow the root naming context"
sys.exit(1)
# Resolve the name "test.my_context/ExampleEcho.Object"
name = [CosNaming.NameComponent("test", "my_context"),
CosNaming.NameComponent("ExampleEcho", "Object")]
try:
obj = rootContext.resolve(name)
except CosNaming.NamingContext.NotFound, ex:
print "Name not found"
sys.exit(1)
# Narrow the object to an Example::Echo
eo = obj._narrow(Example.Echo)
if (eo is None):
print "Object reference is not an Example::Echo"
sys.exit(1)
# Invoke the echoString operation
message = "Hello from Python"
result = eo.echoString(message)
print "I said '%s'. The object said '%s'." % (message,result)
</PRE><A NAME="toc9"></A>
<H2>2.7 Global IDL definitions</H2>
<A NAME="sec:globalIDL"></A>As we have seen, the Python mapping maps IDL modules to Python
packages with the same name. This poses a problem for IDL declarations
at global scope. Global declarations are generally a bad idea since
they make name clashes more likely, but they must be supported.<BR>
<BR>
Since Python does not have a concept of a global scope (only a
per-module global scope, which is dangerous to modify), global
declarations are mapped to a specially named Python package. By
default, this package is named <TT>_GlobalIDL</TT>, with skeletons in
<TT>_GlobalIDL__POA</TT>. The package name may be changed with
omniidl's <TT>-Wbglobal</TT> option, described in
section <A HREF="omniORBpy005.html#sec:Wbglobal">5.2</A>. The omniORB C++ Echo example, with IDL:<BR>
<BR>
<PRE>
interface Echo {
string echoString(in string mesg);
};
</PRE>can therefore be supported with code like<BR>
<BR>
<PRE>
#!/usr/bin/env python
import sys
from omniORB import CORBA
import _GlobalIDL
orb = CORBA.ORB_init(sys.argv, CORBA.ORB_ID)
ior = sys.argv[1]
obj = orb.string_to_object(ior)
eo = obj._narrow(_GlobalIDL.Echo)
message = "Hello from Python"
result = eo.echoString(message)
print "I said '%s'. The object said '%s'" % (message,result)
</PRE><HR WIDTH="50%" SIZE=1><DL>
<DT><A NAME="note4" HREF="#text4"><FONT SIZE=5>1</FONT></A><DD> Notice that the object key is not
globally unique across address spaces.
<DT><A NAME="note5" HREF="#text5"><FONT SIZE=5>2</FONT></A><DD> The code does not check that there is
actually an IOR on the command line!
<DT><A NAME="note6" HREF="#text6"><FONT SIZE=5>3</FONT></A><DD> The POA itself
can be activated on demand with an adapter activator.
<DT><A NAME="note7" HREF="#text7"><FONT SIZE=5>4</FONT></A><DD> There are escaping rules to cope
with id and kind fields which contain `.' and `/' characters. See
chapter <A HREF="omniORBpy004.html#chap:ins">4</A> of this manual, and chapter 3 of the CORBA
services specification, as updated for the Interoperable Naming
Service [<A HREF="omniORBpy009.html#inschapters"><CITE>OMG00a</CITE></A>].
<DT><A NAME="note8" HREF="#text8"><FONT SIZE=5>5</FONT></A><DD> If you are on-the-ball, you
will have noticed that we didn't call <TT>_narrow()</TT> when resolving the
Root POA. The reason it is safe to miss it out is given in
section <A HREF="omniORBpy003.html#sec:narrowing">3.1</A>.
</DL>
<HR>
<A HREF="omniORBpy001.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Contents"></A>
<A HREF="omniORBpy003.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
51adff6dc4cce5d695a2dcdb26f1a3d7
>
files
>
318
