Subject: CORBA FAQ (part 3)
Date: 9 Sep 1997 04:07:37 GMT
X-Trace: news.cerf.net 873778057 10211 (None) 192.102.249.3
X-Complaints-To: news@CERF.NET
Summary: Please read this before posting to comp.object.corba

Archive-name: CORBA-FAQ/part3
Posting-Frequency: monthly
URL: http://www.cerfnet.com/~mpcline/corba-faq/

AUTHORS (alphabetically): Rob Appelbaum, Marshall Cline, Mike Girou,
corba-faq@parashift.com.

COPYRIGHT: This posting is part of "CORBA FAQ."  The entire "CORBA FAQ"
document is Copyright (C) 1996 Rob Appelbaum, Marshall Cline, Mike Girou,
corba-faq@parashift.com.  All rights reserved.  Copying is permitted only under
designated situations.  For details, see section [1].

NO WARRANTY: THIS WORK IS PROVIDED ON AN "AS IS" BASIS.  THE AUTHORS PROVIDE NO
WARRANTY WHATSOEVER, EITHER EXPRESS OR IMPLIED, REGARDING THE WORK, INCLUDING
WARRANTIES WITH RESPECT TO ITS MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR
PURPOSE.


==============================================================================
==============================================================================

      [32] Object References --- Details
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[32.1] How are object references obtained by applications?

Object references allow applications to issue distributed requests.  How does
an application acquire an object reference?  CORBA provides a number of ways
for this to occur.  They basically fall into two categories, mechanisms to
obtain initial object references and mechanisms to obtain subsequent object
references.  CORBA provides two standard ways to obtain an initial object
reference:

* ORB::resolve_initial_references(string): CORBA defines a vendor specific
  mechanism for obtaining an initial set of object references.  While CORBA
  defines the interface for the mechanism, internals required to drive the
  functionality are not standardized.  CORBA specifies that an application can
  obtain an object reference by calling resolve_initial_references(), but
  vendor specific configurations files, command line arguments, of
  environmental variable might be required for the call to succeed.  Object
  references obtained in this way can most likely be implemented only within
  the same vendors ORB.
* ORB::string_to_object(string): CORBA provides a vendor independent mechanism
  for obtaining an object reference.  The string_to_object() operation returns
  an object reference directly from a particular string.  The object reference
  is actually an interoperable object reference and can thus be implemented
  within and ORB supporting IIOP[40].  Strings are basically encoded
  identifiers and are not human readable.  The string can be hard coded into an
  application, stored and retrieved from a file, or obtained through some other
  IPC mechanism.  Strings are initially created by calling object_to_string()
  on an actual object reference.

Once an application obtains an object reference, it can obtain subsequent
objects by calling any remote operations on the original object reference that
happen to return a CORBA object.  CORBA refers to an object capable of
returning an object reference as a factory.  CORBA defines two services that
are basically mechanisms by which subsequent object references can be obtained.
These are listed below:

* CORBA NameService
* CORBA TraderService




==============================================================================
==============================================================================

      [33] Language Mappings
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [34] Static Invocation
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [35] DII
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [36] DSI
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [37] IR
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [38] BOA
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[38.1] What is the BOA?

The CORBA specification defines the BOA pseudo object in PIDL.  BOA stands for
Basic Object Adapter.  The BOA's main purpose is to allow a object server to
interact with the ORB.  A server process uses the BOA to tell the ORB when an
object is ready to perform operations.



[38.2] What are the Four BOA Activation Policies for a CORBA Server?

CORBA defines four activation policies for objects.  Activation policies are
specific to the server process that "owns" the CORBA object.  The activation
policy defines how objects are created within a server process.  The BOA object
ensures that these activation policies are enforced.  Enforcement of these
rules can simplify application development.

Note: The CORBA activation policies are specific to creation.  This means that
the activation policy does not manage the connection policy of a CORBA object.
A particular un-shared server might have only one CORBA object in its address
space.  The activation policy does not forbid several client applications from
having object references that point to the same CORBA object. An application is
always free to _duplicate an object reference and pass it to some other
application.

* Shared Server: A shared server is a server process that is shared by many
  CORBA objects.  This means that a shared server could have more than one
  instance of a particular CORBA object in its address space.  This implies
  that different object references of the same type refer to different CORBA
  object implemented within the same process.
* Un-Shared Server: An un-shared server is allowed to construct at most one
  CORBA object (of a given type) within its address space.  This implies that
  different object references of the same type refer to CORBA objects
  implemented within different server processes.
* Persistent Server: A persistent server is a shared server that manages the
  activation of objects itself.  The BOA is not involved with enforcement of
  the activation policy.  A persistent server might start up at boot time and
  create a fixed number of CORBA objects of varied types.
* Per-Method Server: The per-method policy results in a separate server for
  each request made on the specified object. The BOA activates a per-method
  server for each and every request made on the object. The server runs only
  until the request has been serviced.



[38.3] Are there any other activation policies for CORBA objects?

The CORBA specification defines four activation policies[38.2] that are part of
the BOA.  Other activation policies are not explicitly defined, although many
other possible policies might be useful. Some other possible policies are
described below but since they are not part of the BOA, the policies are not
enforced.

* Limited Shared Servers: This could be a specialization of a shared server.
  Servers could support multiple object instances up to a certain limit.
* Balanced Servers: This could be a collection of unshared servers. The pool of
  servers could support a number of object references and the policy could
  demand that each server support a equal percentage of object references.




==============================================================================
==============================================================================

      [39] Interoperability --- Details
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [40] IIOP
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[40.1] What is an IOR?

An IOR is an Interoperable Object Reference.  It is a specialized object
reference.  An IOR is used by an application in the exact same way that an
object reference is used.  An IOR allows an application to make remote method
calls on a CORBA object.  Once an application obtains an IOR, it can access the
remote CORBA object via IIOP.  The CORBA object can be implemented with any
CORBA 2.0 compliant product that supports IIOP.  The application that obtains
the IOR can be developed with a different CORBA 2.0 product.  The application
constructs a GIOP message and sends it.  The IOR contains all the information
needed to route the message directly to the appropriate server.



[40.2] Are IORs obtained in the Same Manner as Object References?

Obtaining IORs is exactly the same as obtaining object references[32.1].  The
one caveat is that ORB::resolve_initial_references returns an IOR but it
usually must be implemented within the same CORBA product environment.



[40.3] Can an Application refer to Objects implemented with Multiple CORBA
       Products?

Well, they're sure supposed to be able to do so.  Here's how.

Let us assume that an application needs to access two objects.  Object A is
implemented with CORBA product Aa and object B is implemented with CORBA
product Bb.  Let us look at several scenarios:

* The front-end application will be implemented with CORBA product Aa: The
  simplest approach is for the front-end application to obtain an object
  reference to A by calling ORB::resolve_initial_references().  Since the
  front-end application is implemented with product Aa it cannot obtain an
  object reference to B by calling ORB::resolve_inital_references().  It can
  acquire the stringified object reference to B and convert it to an IOR by
  calling ORB::string_to_object().  How does it obtain the stringified object
  reference?  Object B's constructor could be implement to stringify itself and
  write the string to a file that is accessible to the front end application
  (access might be provided by NFS). Every CORBA product that supports IIOP
  should be support ORB::string_to_object().
* The front-end application will be implemented with CORBA product Cc: This
  scenario is very similar to the first.  The application can not use
  ORB::resolve_initial_references() since neither object A or B are implemented
  with product Cc.  The front end application will obtain an IOR to A and an
  IOR to B by first acquiring stringified object references.  It will then
  converting the strings to IORs by calling to ORB::string_to_object(). Every
  CORBA product that supports IIOP should be support ORB::string_to_object().
* The front-end application will be implemented with CORBA product Cc.  It will
  obtain IORs A and B from product Cc's implementation of the CORBA
  NameService. It will not need to acquire any stringified object references.
  The real question is how are IOR A and IOR B bound within product Cc's CORBA
  NameService.  The processes implementing object A and Object B must acquire
  an object reference to product Cc's CORBA NameService.  This can only occur
  by obtaining a stringified object reference to product Cc's CORBA
  NameService. How is the stringified object reference to product Cc's
  NameService initially created?  A simple application implemented with product
  Cc obtains the NameService by calling ORB::resolve_inital_references(), it
  then stringifies it by calling ORB::object_to_string(), once this has been
  done it externalizes the string so that it can be accessed by the processes
  implementing object A and B.

Note: Stringified objects cannot be exchanged using CORBA based communication.
This is your classic catch 22 situation



[40.4] Can CORBA Vendors Simplify Interoperability and the Process of Obtaining
       Other Vendor's Object References?

CORBA vendors can simplify the process of obtaining external object references
by providing small pieces of code designed only to create external IORs.  This
might be a function called ExternalORB::create_external_references(). Vendors
could provide this code to the public or directly to other ORB vendors.




==============================================================================
==============================================================================

      [41] Name Service
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[41.1] What are the IDL Interfaces defined within the COSNaming Module?

The CORBA Name Service is composed of two basic interfaces.  The NameContext
and the Binding Iterator.  Remember that since the NameContext and the Binding
Iterator are both CORBA interfaces, they are accessed via object references and
are distributed.  The NameContext contains "named" object references or other
"named" NameContexts.  It is similar to a directory that can contain named
files or other named directories.  NameContexts and Binding Iterators are
usually implemented in the same Name Server process, but this is not a
requirement.  The CORBA NameService can be constructed as a set of
interconnected NameContext objects and NameService processes.

The BindingIterator is used to iterate across object references contained
within a particular NameContext.  It basically provides a mechanism to get the
number of named object references within a NameContext.  It also provides a
next_one and a next_n operation to retrieve individual named object references
or contexts.  Continuing with the directory analogy, The BindingIterator is a
mechanism to do a ls or dir operation on a directory.



[41.2] How do I use a NameContext?

The NameContext interfaces supports two main operations, bind and resolve. Once
a NameContext object reference is obtained, it can be used to "name" some other
CORBA object, or retrieve an object reference by name.  This means that you can
call the bind method on a NameContext passing it an object reference and a
name.  This will place a named object reference into the NameContext for future
resolve calls.  If an application wishes to obtain an object reference by name
is simply obtains the appropriate NameContext and call resolve with the
particular name.  This will cause the named object reference to be returned to
the application making the resolve invocation.



[41.3] What if I Do Not Know the Name of the Object?

The CORBA NameService was designed to allow object references to be obtained by
name.  Names need to be either agreed upon between servers or clients, or
perhaps passed between components in the distributed application.  It is also
possible to use the BindingIterator interface to connect to any name object
reference.  The CORBA trading service might be more appropriate if the CORBA
NameService is too limiting.  Other architectures such as factories might be
appropriate mechanisms to obtain object references.




==============================================================================
==============================================================================

      [42] Event Service
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================

  (Under Construction; Please Be Patient!)




==============================================================================
==============================================================================

      [43] COS Lifecycle Service
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[43.1] What is the purpose of the COS Lifecycle Service?

The basic purpose of the COS Lifecycle service is to provide basic capabilities
to CORBA Objects, such as the ability to create, copy, move and destroy
themselves.  More than any other service, the COS Lifecycle service is tied to
the actual ORB implementation used to provide CORBA support.




==============================================================================
==============================================================================

      [44] Object Transaction Service
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[44.1] What is the purpose of the COS Object Transaction Service?

The COS OTS provides a mechanism for distributed CORBA Objects to participate
in a distributed transaction through a two phase commit protocol.




==============================================================================
==============================================================================

      [45] Trader Service
      (Part of the CORBA FAQ, Copyright (C) 1996)

==============================================================================
==============================================================================



[45.1] What is the purpose of the COS Trader Service?

The COS Trader Service was designed to provide access to CORBA objects based
upon capabilities as opposed to name or interface type.  The COS Trader Service
is a factory since its purpose is to return other CORBA Objects. Unlike the COS
Naming Service, a global name or identifier is NOT used to specify the CORBA
Object to return.  The Trader Service has been likened to the Yellow Pages,
while the Naming Service is more like the White Pages.

==============================================================================

[[[ END OF CORBA FAQ ]]]

==============================================================================
-- 
Marshall Cline, Ph.D., President, Paradigm Shift, Inc.
315-353-6100 (voice)
315-353-6110 (fax)
mailto:cline@parashift.com
