Week 6 CORBA Programming Issues

1
Week 6 CORBA Programming Issues
2
CORBA Basics - Hello World
// IDL interface Hello void
say_hello() idl Hello.idl Creates Hello.
h Hello.cpp, Hello_skel.h Hello_skel.cpp.
3
Implementing the Server
Create class Hello_impl, derived from the
skeleton class POA_Hello, defined in the file
Hello_skel.h. // C include ltHello_skel.hgt cla
ss Hello_impl public POA_Hello, public
PortableServerRefCountServantBase public virt
ual void say_hello() throw(CORBASystemException)

4
Implementing the Server Class
// C include ltiostream.hgt include
ltOB/CORBA.hgt include ltHello_impl.hgt void
Hello_implsay_hello() throw(CORBASystemExcepti
on) cout ltlt "Hello World!" ltlt
endl OB/CORBA.h contains definitions for the
standard CORBA classes
5
Implementing the Server Main()
include ltOB/CORBA.hgt include ltHello_impl.hgt inc
lude ltfstream.hgt int run(CORBAORB_ptr) int
main(int argc, char argv) int status
EXIT_SUCCESS CORBAORB_var orb try orb
CORBAORB_init(argc, argv) status
run(orb) catch(const CORBAException) statu
s EXIT_FAILURE if(!CORBAis_nil(orb)) orb
-gt destroy() // exception handling
missing return status
6
Implementing run()
int run(CORBAORB_ptr orb) CORBAObject_var
poaObj orb -gt resolve_initial_references("RootP
OA") PortableServerPOA_var rootPoa
PortableServerPOA_narrow(poaObj) Portable
ServerPOAManager_var manager rootPoa -gt
the_POAManager() Hello_impl helloImpl new
Hello_impl() PortableServerServantBase_var
servant helloImpl Hello_var hello helloImpl
-gt _this() CORBAString_var s orb -gt
object_to_string(hello) const char refFile
"Hello.ref" ofstream out(refFile) out ltlt s ltlt
endl out.close() manager -gt activate() orb -gt
run() return EXIT_SUCCESS
7
Portable Object Adapters

• All servers need an Object Adapter
• Controls flow of messages to objects in the server

8
resolve_initial_references

• CORBA provides a standard way to bootstrap an
  object reference using of initial services,
• These are a set of unique, predefined services
  whose object references can be obtained using the
  ORB operation resolve_initial_references,
• module CORBA
• interface ORB
• typedef string ObjectId
• exception InvalidName
• Object resolve_initial_references(in ObjectId
  identifier)
• raises(InvalidName)

9
Creating the POA

• CORBA standard API resolve_initial_references
• Returns an object reference to a small number of
  well known interfaces
• We get a reference to the root POA for the ORB
• CORBAObject_var poaObj
• orb -gt resolve_initial_references("RootPOA")
• PortableServerPOA_var rootPoa
• PortableServerPOA_narrow(poaObj)
• and use that to get a POAManager reference
• PortableServerPOAManager_var manager
• rootPoa -gt the_POAManager()

10
Creating the servant

• A servant of type Hello_impl is created and
  assigned to ServantBase_var vari ble.
• The servant is then used to incarnate a CORBA
  object, using the _this() operation.
• Hello_impl helloImpl new Hello_impl()
• PortableServerServantBase_var servant
  helloImpl
• Hello_var hello helloImpl -gt _this()
• ServantBase_var and Hello_var, are smart
  pointer, i.e.servant will release their assigned
  object automatically when they go out of scope

11
_this() - what it does

• Hello_impl helloImpl new Hello_impl()
• This only creates a C object
• _this() does the following
• Hello_var hello helloImpl -gt _this()
• creates a CORBA object under the root POA
• registers helloImpl with the Root POA as the
  implementation for the CORBA object
• creates an object reference for the CORBA object
• returns the new object reference

12
Creating the Object Reference

• The client must be able to find the
  implementation object.
• This can be done by saving astringified object
  reference to file, which can be read by the
  client
• The operation object_to_string() converts a CORBA
  object reference into a string
• CORBAString_var s orb -gt object_to_string(hell
  o)
• const char refFile "Hello.ref"
• ofstream out(refFile)
• out ltlt s ltlt endl
• out.close()

13
Activating the POA

• The server process must activate the POA Manager
  to allow the Root POA to start processing
  requests,
• Informs the ORB that it is ready to accept
  requests
• manager -gt activate()
• orb -gt run()

14
Implementing the Client
include ltOB/CORBA.hgt include ltHello.hgt include
ltfstream.hgt int run(CORBAORB_ptr) int
main(int argc, char argv) ... // Same as
for the server int run(CORBAORB_ptr
orb) const char refFile "Hello.ref" ifstream
in(refFile) char s2048 in gtgt
s CORBAObject_var obj orb -gt
string_to_object(s) Hello_var hello
Hello_narrow(obj) hello -gt say_hello() return
0
15
Get the Server Object Reference

• Needs to read it from the file created by the
  server
• const char refFile "Hello.ref"
• ifstream in(refFile)
• char s2048
• in gtgt s
• And use string_to_object to create an object
  reference and call the server method
• CORBAObject_var obj orb -gt string_to_object(s)
  
• Hello_var hello Hello_narrow(obj)
• hello -gt say_hello() // call the server

16
Object References

• Like an object pointer/reference that works
  across a network
• Contains (for IIOP)
• hostname
• port number
• object key
• When stringified, often called an FBN (big
  number)
• Semantics are similar to normal C pointers

17
Object References

• Every reference identifies exactly 1 object
  instance
• Several different references can denote the same
  object
• References
• can be nil
• can dangle
• are opaque
• strongly typed
• support late binding
• can be persistent

18
Object References

• Can be obtained in other ways
• using a name server (coming soon)
• returned by an IDL operation, ie
• // IDL
• interface A
• interface B
• A getA()

19
IDL and references - Java
Java public class A_impl extends APOA public
class B_impl extends BPOA org.omg.CORBA.ORB
orb_ A_impl a_ public B_impl(org.omg.CORBA.OR
B orb) orb_ orb a_ new
A_impl() A getA() return
a_._this(orb_)
20
IDL and references - C
class A_impl public POA_A, public
PortableServerRefCountServantBase class
B_impl public POA_B, public PortableServerRefC
ountServantBase A_impl a_ public B_impl()
a_ new A_impl() B_impl() a_ -gt
_remove_ref() virtual A_ptr getA()
throw(CORBASystemException) return a_ -gt
_this()
21
POA Functions

• All servants that use the same POA share common
  implementation characteristics, determined by the
  POAs policies.
• Each servant has exactly one POA, but many
  servants may share the same POA.
• The POA tracks the relationship between object
  references, object IDs, and servants
• POAs map between object references and the
  associated object ID and servants and map an
  incoming request onto the correct servant

22
Functions of a POA Manager

• A POA manager is associated with a POA when the
  POA is created. Thereafter, the POA manager for a
  POA cannot be changed.
• A POA manager controls the flow of requests into
  one or more POAs.
• A POA manager is in one of four possible states
• Active Requests are processed normally
• Holding Requests are queued
• Discarding Requests are rejected with TRANSIENT
• Inactive Requests are rejected

23
POA Manager State Transitions
24
Request Flow
Conceptually, incoming requests are directed
toward a particular ORB. If the ORB is accepting
requests, it passes the request to a
POA manager. The POA manager (if it is in the
active state) passes the request to a POA, which
in turn passes it to the correct servant.
25
Object Reference Contents

• Conceptually, an object reference contains the
  following information
• Repository ID (optional, identifies interface
  type)
• Addressing information (identifies a transport
  endpoint)
• Object key (identifies POA and object within the
  POA)
• The object key is in a proprietary format,
  specific to each ORB.

26
POA Policies

• Each POA is has seven policies when it is
  created.
• Policies control implementation characteristics
  of object references and servants.
• The CORBA module provides a Policy abstract base
  interface
• module CORBA
• typedef unsigned long PolicyType
• interface Policy
• readonly attribute PolicyType policy_type
• Policy copy()
• void destroy()
• typedef sequenceltPolicygt PolicyList
• // ...

27
POA Policies

• The PortableServer module contains seven
  interfaces that are derived from the
  CORBAPolicy interface
• LifespanPolicy
• IdAssignmentPolicy
• IdUniquenessPolicy
• ImplicitActivationPolicy
• RequestProcessingPolicy
• ServantRetentionPolicy
• ThreadPolicy

28
Thread Policy

• The thread policy controls whether requests are
  dispatched single-threaded (are serialized) or
  whether the ORB chooses a threading model for
  request dispatch.
• The default is ORB_CTRL_MODEL .
• enum ThreadPolicyValue
• ORB_CTRL_MODEL, SINGLE_THREAD_MODEL
• interface ThreadPolicy CORBAPolicy
• readonly attribute ThreadPolicyValue value

29
Thread Policy

• ORB_CTRL_MODEL allows the ORB to chose a
  threading model.
• This means different ORBs may exhibit different
  behavior.
• SINGLE_THREAD_MODEL serializes all requests on a
  per- POA basis.

30
Orbacus Threading Policies

• ORBACUS allows different concurrency models to be
  established for the client and server
• The client-side concurrency models are
• Blocking (default for Java/C client)
• Reactive
• Threaded
• The server-side concurrency models are
• Reactive (default for C server)
• Threaded (default for Java server)
• Thread-per-Client
• Thread-per-Request
• Thread Pool

31
Single Threaded Models

• Client - Blocking - simple synchronous request
• Client and Server - Reactive - still single
  threaded but useful for applications that are
  both clients and servers
• Without the reactive concurrency model it is not
  possible to use nested method calls in single
  threaded applications, which are absolutely
  necessary for most kinds of callbacks.

32
Reactive
Deadlock
33
Threaded Model

• A threaded client uses two separate threads for
  each connection to server, one for sending
  requests and another for receiving replies.
• A threaded server uses separate threads for
  receiving requests fromclients and sending
  replies.
• There is separate thread dedicated to accepting
  incoming connection requests, so that threaded
  server can serve more than one client at a time.
• ORBACUSs threaded server concurrency model
  allows only one active thread in the user code.

34
Thread Per Client Model

• The thread-per-client server concurrency model is
  similar to the threaded server concurrency model,
  except it allows one active thread-per-client in
  the user code
• A client is defined on a per connection basis, so
  a thread is created per client connection
• This model is still efficient as no threads need
  to be created, except when new connections are
  accepted.

35
Thread per request

• The thread-per-request server concurrency model
  creates a new thread for each client request.
• When a request arrives, a new thread is created
  and the request is executed in the user code
  using this thread. On return, the thread is
  destroyed.
• This concurrency model is inefficient because of
  the overhead involved in creating new threads for
  every request

36
Thread Pool Model

• The thread pool model uses threads from a fixed
  size pool to carry out requests
• Threads have to be created only once and can then
  be reused for other requests
• Since there are no slow thread creation
  operations after start up, the this concurrency
  model typically performs better than the
  thread-per-request model

37
Active Object Map

• Each POA with a servant retention policy of
  RETAIN (default) has an AOM. This provides a
  mapping from object IDs to servant addresses