Subject: CORBA FAQ (part 2)
Date: 9 Sep 1997 04:06:57 GMT
X-Trace: news.cerf.net 873778017 10087 (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/part2
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.


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

      [9] Why Use Distributed Objects
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[9.1] What is a Distributed Object?

A distributed object is an object that can be accessed remotely.  This means
that a distributed object can be used like a regular object, but from anywhere
on the network.  An object is typically considered to encapsulate data and
behavior.  The location of the distributed object is not critical to the user
of the object.  A distributed object might provide its user with a set of
related capabilities.  The application that provides a set of capabilities is
often referred to as a service.  A Business Object might be a local object or a
distributed object.  The term business object refers to an object that performs
a set of tasks associated with a particular business process.



[9.2] Are all Distributed Objects CORBA Objects?

No.

A CORBA object is an object that obeys certain rules and which can be accessed
via a particular protocol.  A CORBA object is frequently also a distributed
object, but it doesn't have to be.

A distributed object is not necessarily a CORBA object.  A distributed object
might be a C++ object that can be accessed via a socket, RPC, or telephony. In
order for a distributed object to be a CORBA object, it must be declared in
IDL.  The object can be implemented in a variety of programming languages.



[9.3] Why should I develop Applications with Distributed Objects?

For lots of reasons:

* Distributed objects might be used to share information across applications or
  users.
* Distributed objects might be used synchronize  activity across several
  machines.
* Distributed objects might be used to increase performance associated with a
  particular task.
* Distributed objects might be used to connect applications running on PCs with
  information managed by UNIX processes or mainframes databases.
* Distributed objects might be used to allow people in different cities to
  contributed to a particular business process.
* Distributed objects can allow business processes to be modified or re-
  implemented without altering applications that use the distributed objects.
* Distributed objects are a way to distribute computing horsepower across a
  network of computers, which makes it easier to accommodate unpredictable
  growth.  Centralized approaches frequently fail in such environments.



[9.4] How are Distributed Objects actually implemented?

Typically a company will start by modeling their business processes.  Next, the
company will determine which business processes should be implemented as local
objects and which should be implemented as distributed objects.  Usually, the
company will leverage a tool-kit that simplifies the distribution of those
objects.  There are many issues associated with simplifying distribution of
objects.  The tool-kit might also enhance the distribution with robust set of
communication features.  A company might select a particular CORBA
implementation, and build their distributed objects on top of the third party
package.  The CORBA vendor simplifies distribution by implementing all
low-level network development.  An IDL compiler will process interface
definition files into client and server side base classes.  These base classes
use low level network APIs (such as TCP/IP) to communicate.  The vendor will
most likely provide daemon processes that facilitate communication, the
spawning of processes, the spawning of objects, and the storage of IDL used by
a running system.  A number of other utilities might also be provided. These
could include debuggers, interface browsers or communication monitors.



[9.5] Should all my Objects be Distributed?

Nope.

Not every business object should be distributed.  Distribution implies network
overhead and management overhead.  Distribution of all business objects can
lead to severe performance problems.  Distribution can provide many benefits,
but should only be used where specific goals are achieved.  You must first ask
why you need to do distributed objects[9].




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

      [10] Why Use CORBA
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[10.1] What is the Basic Functionality provided by CORBA?

At the most basic level, CORBA is a standard for distributed objects.  CORBA
allows an application to request an operation to be performed by a distributed
object and for the results of the operation to be returned back to the
application making the request.  The application communicates with the
distributed object that is actually performing the operation.  This is basic
client/server functionality, where a client issues a request to a server and
the server responds back to the client.  Data can pass from the client to the
server and is associated with a particular operation on a particular object.
Data is then returned back to the client in the form of a response.



[10.2] What Advantages does CORBA provide?

* CORBA supports many existing languages.  CORBA also supports mixing these
  languages within a single distributed application.
* CORBA supports both distribution and Object Orientation.
* CORBA is an industry standard.  This creates competition among vendors and
  ensures that quality implementations exist.  The use of the CORBA standard
  also provides the developer with a certain degree of portability between
  implementations.  Note: application source is not 100% portable between
  different CORBA products.
* CORBA provides a high degree of interoperability.  This insures that
  distributed objects built on top of different CORBA products can communicate.
  Large companies do not need to mandate a single CORBA product for all
  development.
* Over 600 companies back CORBA, including hardware companies, software
  companies, and cable companies, phone companies, banks, etc.



[10.3] What other types of Distributed Systems does CORBA compete with?

* DCE[13] (under construction)
* DCOM[12]
* RPC (remote procedure calls)
* Shared memory based interaction
* Named Pipe communication
* Socket level programming
* Message Queuing
* Other IPC (inter-process communication) mechanisms
* Database tables, triggers and polling




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

      [11] How to do Client/Server with CORBA
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[11.1] How can CORBA enable Client/Server Communication?

A server is defined as an Interface in CORBA IDL.  Data passing between the
client and the server is defined as IDL structures, sequences, etc.  The IDL is
compiled with an IDL compiler and the generated code is included within the
client and server processes.  The server implements a particular interface. The
implementation is the distributed object.  Clients communicate with the object
through an object reference.  When an operation is performed on the object
reference, network communication occurs, operation parameters are sent to the
server and the actual distributed object executes the operation.  It then
returns any appropriate data to the client.



[11.2] Do any Client/Server Limitations exist with CORBA?

Depends on the specific vendor and product offering, but there is nothing in
the standard that you will find terribly onerous.

Some applications want to make distributed requests, but not wait for the
response.  Ideally, they want to be notified when the response is available.
Threads can be used to allow applications to make more than one request or to
continue performing other tasks while waiting for a response, but the thread
making a request is blocked until the response is available.  CORBA
communication is basically a synchronous request/response.  This is true for
all static invocations.  Dynamic invocations do support a deferred request
response.  This means that an application can issue a request and poll for the
response. CORBA communication can be used to notify applications when responses
associated with earlier requests are available.  This can lead to a more
complex application architecture.




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

      [12] Choosing between CORBA and DCOM
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[12.1] I use Microsoft products; Why should I use CORBA and not DCOM?

DCOM is a Microsoft specific distribution solution.  CORBA products are
available from over 20 different vendors.  CORBA products support Microsoft and
non Microsoft operating systems.  CORBA is an excellent mechanism to bridge
between Microsoft desk tops and UNIX servers.



[12.2] Must I choose between DCOM and CORBA?

No.  Distributed applications can be developed using both CORBA and DCOM.  For
example, client application might be developed to access a set of OLE
automation objects, and OLE automation objects might in turn access CORBA
objects running on a non-Microsoft platform such a UNIX.  The OMG has defined a
COM<->CORBA interworking specification which standardizes this sort of
bridging.



[12.3] Is CORBA more Mature than DCOM?

CORBA has existed since 1990.  Commercial implementations have been available
since 1992.  DCOM was made available in beta form in 1996.  CORBA has had more
time to mature.  There are also a large number of different companies
developing CORBA ORBs.  This level of competition increases the robustness of
CORBA solutions on the whole.



[12.4] What Advantages does DCOM have over CORBA?

DCOM is well suited to front-end application development.  If entire
distributed application runs under Microsoft platforms, DCOM might be a good
choice.  DCOM can also be used with CORBA.  The question is not always should I
use DCOM or CORBA[12.2]?




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

      [13] Choosing between CORBA and DCE
      (Part of the CORBA FAQ, Copyright (C) 1996)

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

  (Under Construction; Please Be Patient!)




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

      [14] How Real/Mature is CORBA?
      (Part of the CORBA FAQ, Copyright (C) 1996)

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

  (Under Construction; Please Be Patient!)




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

      [15] How does CORBA relate to doing Internet/Intranet Applications?
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[15.1] Can CORBA Objects be accessed by Web Based Applications?

Yep.

There is a number of ways that CORBA objects can be accessed from web based
applications.

* Java applets can be downloaded via web based applications.  These Java
  applets are capable of directly accessing CORBA objects via IIOP.  There are
  a number of Java based ORBs available on the market.  By introducing CORBA
  communication into a Java applet, arbitrary CORBA services can be accessed
  directly.  These services can be developed in any language supported by CORBA
  or on top of any CORBA product that supports IIOP.
* Pure HTML based application are capable of accessing CORBA objects via CGI
  gateways. Arbitrary unknown CORBA objects can be accessed by a single
  pre-compiled client application via Dynamic Invocation.  A pre-compiled
  application can dynamically generate HTML pages based upon results obtained
  from arbitrary invocation of operations.  This solution has the advantage of
  being based only upon HTML, it is not specific to a particular web browser.
* A similar approach to the CGI CORBA gateway described above, can allow CORBA
  objects to be accessed without the performance impact associated with process
  spawning.  A plug-in can be developed for a particular browser which enables
  it to speak directly to any CORBA object through IIOP.
* Web servers from Netscape and Oracle are beginning to to support IIOP
  directly.  This means that in addition to supporting HTTP, FTP access and
  news group access, they will be capable of accessing any CORBA object capable
  of supporting IIOP.




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

      [16] How to do Notification with CORBA
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[16.1] Can CORBA Allow Servers to cause Client Side Events or Notifications?

CORBA communication is inherently asymmetric.  Request messages originate from
clients and responses originate from servers.  The important thing to realize
is that a CORBA server is a CORBA object and a CORBA client is a CORBA stub.  A
client application might use object references to request remote service, but
the client application might also implement CORBA objects and be capable of
servicing incoming requests.  Along the same lines, a server process that
implements CORBA objects might have several object references that it uses to
make requests to other CORBA objects.  Those CORBA objects might reside in
client applications.  By implementing a CORBA object within an client
application, any process that obtains its object reference can "notify" it by
performing an operation on the client-located object.




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

      [17] Why would I use CORBA Services
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[17.1] Does CORBA support functionality other than Request/Response?

Oh, yes.  Lots of good stuff.

CORBA defines roughly 15 different services.  These services augment the basic
CORBA architecture[27.1].  These services are horizontal application services.
They apply to different types of applications.  These include naming, events,
lifecycle, transactions, security, persistence, etc.  Application functionality
can be greatly enhanced by leveraging available services.  At one level, the
basic CORBA architecture provides distribution of objects.  Implementing the
objects is left up to software developers.  The CORBA services represent a set
of pre-implemented distributed objects that software developers will typically
need.



[17.2] Why would I use the CORBA Name Service?

Because it is the most flexible and easy-to-use way to find and use objects.

The CORBA name service provides a mechanism to obtain an object reference.
Applications first obtain an object reference to a name context.  This might
occur by calling ORB::resolve_initial_references("NameService").  Once
obtained, applications can call the resolve() operation on the name context.
The call to resolve will return an object reference to from a logical name.
This assumes that a distributed object has been named within the name context.
Once the application obtains the object reference they can make distributed
invocations of operations on it.  By using the name service to obtain object
references, applications do not need to concern themselves with the actual
location of a distributed object.



[17.3] Why would I use the CORBA Lifecycle Service?

To handle the messy but essential administrative aspects of working with
distributed objects.

The CORBA lifecycle service allows an application to request the ORB to create,
destroy or move and object within the network.  Applications can create or
destroy objects explicitly or implicitly.  Objects can be created or referenced
by application factories.  The CORBA lifecycle service allows applications to
explicitly create or destroy distributed objects in a standard fashion.



[17.4] Why would I use the CORBA Event Service?

Because you will need it sooner or later, and it's no fun writing your own.

The CORBA event service provides a framework, in the form of an IDL interface,
to support notification of events between applications.  Events are generated
and responded to at a coarse grained level.  The event service relies on a
"channel" to manage creation of and response to events.  Applications are aware
of every event that occurs on a given channel.  The event service is anonymous.
This means that an application might be notified of an event on a channel but
the application will not know the origin of the event.




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

      [18] Architectural Choices --- Concurrent vs. Distributed vs. Decoupled
      (Part of the CORBA FAQ, Copyright (C) 1996)

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

  (Under Construction; Please Be Patient!)




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

      [19] Asynchronous Communications
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[19.1] Why would Applications require Asynchronous Communications?

Performance is the most common reason.

Applications that perform a series of tasks that must be done sequentially
cannot benefit from asynchronous communication.  Applications that make only
short duration remote operations have little need for asynchronous
communication. Asynchronous communication can allow an application to perform
addition tasks instead of waiting for tasks to complete.  Applications that
have a number of tasks that can be performed in any order can often benefit
from distributed asynchronous communication. This becomes more important for
applications that call lengthy remote operations.  In order to benefit from
asynchronous communication, an application must be able to perform some task
after the request is issued but before the response is available.  Tasks might
include prompting for additional user input, displaying information, or making
additional remote operation requests. Typical asynchronous communication
candidates include applications that need to perform several lengthy database
queries or complex calculations.



[19.2] Does CORBA support Asynchronous Communication?

Kind of.  At the lowest level CORBA supports two modes of communication:

* A synchronous request/response which allows an application to make a request
  to some CORBA object and then wait for a response.
* A deferred synchronous request/response which allows an application to make a
  request to some CORBA object.  An empty result will be returned immediately
  to the application.  It can then perform other operations and later poll the
  ORB to see if the result has been made available.

At the lowest level, the CORBA deferred synchronous communication does allow a
certain degree of asynchronous communication.  Polling for responses represents
only one form of asynchronous communication.  Other more sophisticated
asynchronous communication can only be achieved by developing an architecture
on top of the lowest levels of CORBA.



[19.3] Are Application Threading and Asynchronous Communication related?

Theoretically, no.  They come from different families but hang out together a
lot.  Each has its own identity, but sometimes they can work together to make
things go much more smoothly.

Applications that wish to perform multiple concurrent tasks can use multiple
threads instead of multiple asynchronous or deferred requests.  Just as the
distribution of operations across processes can allow for concurrent
processing, performing tasks in different threads can allow for concurrent
processing.  Distribution supports concurrent processing across a network and
threading supports concurrent processing within a particular machine.  An
application that needs to perform concurrent distributed requests can issue
requests in different threads or issue asynchronous requests.  The use of
threading adds an additional set of complexities synchronization issues to the
development process.



[19.4] Are there Important Forms of Asynchronous Communication that Aren't
       Supported Directly by CORBA?

Yeah, but you can fake it pretty easily.

While CORBA does support a deferred synchronous request/response, it does not
directly support a distributed requests with a callback driven response.  A
callback driven response allows an application to perform an operation on a
distributed object, associate a callback with the response, continue with other
processing.  When the server responds, the associated callback is automatically
executed within the original caller's application.




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

      [20] Application Architectures
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[20.1] Does CORBA define High Level Application Architectures?

No, it's infrastructure.  Which is good because the history of high-level "one
size fits all" architectures hasn't been very good, has it?

CORBA provides low level request/response communication.  It also provides
general services that are implemented on top of request/response communication.
The actual architecture used within a given application is not defined by
CORBA.  CORBA leaves these decisions up the application architect.



[20.2] Do Common Application Architectures Exist?

There are many common application architecture that can be used within a CORBA
based application.  Some architectures are related to the way in which a CORBA
object is referenced, and a few of these are described below.

Non-Exclusive Objects vs. Exclusive Objects:

* Non-Exclusive Objects: A non-exclusive object is typically used to provide a
  common service to many client applications.  A server process creates a
  single instance of a distributed object.  This object can be named or is
  defined as an initial service.  Clients obtain an object reference to the
  CORBA object by using the CORBA name service[17.2] or by calling
  ORB::resolve_initial_references().  The non-exclusive object also provides an
  excellent mechanism to share data or information between connected clients.
* Exclusive objects: An exclusive object is an object that is refereed to by
  only one client application.  Exclusive object can live in their own server
  process or many exclusive objects can live in the same server process. The
  BOA unshared activation policies[38.2] can be used to ensure that each
  exclusive object lives in its own process.  Exclusive objects can ensure that
  no data or event conflict exists between clients. For example, let us assume
  that a CORBA object will perform a lengthy database query.  By deploying the
  exclusive object in its own process, client applications will completely
  control the behavior of the server.  The combination of an exclusive object
  and the unshared activation policy ensure that a server can provide its total
  attention to its client.  The CORBA object will never need to share server
  side processing with some other CORBA object. It is the responsibility of the
  applications to ensure that an exclusive object is refereed to by only one
  client application.

Note: Object level properties such as "non-exclusive" or "exclusive" are
orthogonal to the BOA activation policies[38.2].

Other Architectural Distinctions made at the Object Level:

* Stated Objects: A stated object is an object that maintains and changes
  internal state over time.  If an object consists of data and methods, a
  stated object is an object who maintains and alters its data during the
  invocation of its methods.  Stated objects can exhibit behavior that varies
  based upon what the object has already done.  For example, a get_next_item()
  method maintains returns the next item each time it is called.  This behavior
  is enabled by saving state associated with the current record.  State is
  specific to the object.  Different objects in the same server process
  maintain their own state.  In the case of an exclusive stated object, state
  is specific to a given client application.  Stated non-exclusive object
  maintain a common state across a set of client applications.  While stated
  objects are very powerful, server-side failures can present problems.  For
  example, let us assume that a client is scrolling through a set of records
  maintained by a CORBA object.  If the CORBA server fails its state could be
  lost.  The CORBA object is capable of being reactivated but the appropriate
  record would not be returned when the get_next_item() operation was called.
  Client applications might need to recreate their state within the new object.
  Another option would be for the object to persist its state and retrieve its
  state upon reactivation.
* Stateless Objects: A stateless object is an object that does not maintain any
  internal state specific to the invocation of methods.  Stateless objects are
  not suitable for all applications.  Stateless objects may perform the same
  functions as a stated object.  They might require "state" information to be
  passed as parameters.  Stateless objects can allow for more flexibility with
  respect to fail- over, scaling across servers or dynamic load balancing. In
  the case of failure, servers and objects can be easily reactivate without
  worrying about prior state changes. With stateless objects, a client can
  perform operations on any object of the correct type.  This means that it is
  possible for a collection of servers supporting the same interface to
  servicing clients.  This can increase system scaling dramatically.




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

      [21] Object References
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[21.1] What is an Object Reference?

A transient, opaque handle that identifies an object instance in your ORB.  An
object reference is the identifier needed to invoke methods on objects.

Object references are not global identifiers that are valid across all machines
in a distributed network.  Their scope is limited to your local ORB.



[21.2] Why a Handle rather than a "Hard" Address?

CORBA is a dynamic environment and objects move around in an unpredictable
manner. You need a soft locator rather than something static and brittle.



[21.3] For How Long is an Object Reference Valid?

Only during the session while your client is connected to the ORB.  If a target
object moves during a session, the ORB will provide the equivalent of a
transparent forwarding mechanism.



[21.4] What if I want a Persistent Reference?

Stringify the object reference and save it in a persistent medium.  But, we
have to warn you, you're about to get into deep water.  Maybe you should just
skip to the section on Naming Service, unless you want to be an "expert".



[21.5] I want to be an expert. How do I Stringify an Object Reference?

Use object_to_string(), and reverse the process using string_to_object().
There is some magic in string_to_object(); it not only does the necessary
string-to-pointer conversion, it ensures that you get a currently valid object
reference that is equivalent to the original reference that was stringified
(i.e., both refer to the same object instance).



[21.6] What is the Format of an Object Reference?

We can't tell you because there is no standard for this. OMG wanted to give ORB
implementers as much freedom as possible to develop efficient, possibly
platform-dependent schemes.  Thus, the references are opaque and should be
thought of as an interface without regard for their implementation.



[21.7] Who creates Object References?

Some ORB calls such as resolve_initial_references() and string_to_object()
generate an object reference.  The object it refers to might or might not exist
(the act of using the object reference can result in the creation of the actual
object).

Also, a factory might create an object reference by creating an object
implementation within the same process.  The factory could generate the object
reference and cause an object to be created (as above), or the factory could
obtain the object reference from some other source (NameService,
TraderService).



[21.8] How do I Compare References?

Use is_equivalent(), but don't take it too seriously.  This method never lies
to you, if it says two references are equivalent, then they are. But they might
be equivalent but not identical and is_equivalent() can potentially return
false.  See the October 1996 column by Steve Vinoski and Doug Schmidt in C++
Report.



[21.9] Great. What other Surprises are there with is_equivalent()?

Remember that is_equivalent() is invoked on one of the two objects, and there
are cases where this can cause deadlock.  The following example illustrates how
this can happen on one particular single-threaded ORB that won't allow a server
to invoke a method on the client (contributed by Jeff Stewart,
jstewart+@andrew.cmu.edu; used with permission):

Suppose a server receives updates from cached clients and then has to update
all clients except for the one that reported (updating the reporting client
would cause a deadlock on this ORB). So, as the server iterates through its
client list it must ensure that it does not invoke the reporting client.  But
it can't use is_equivalent() because this will eventually cause an invocation
on the reporting client just to do the is_equivalent() check, inadvertently
creating a deadlock.



[21.10] Is that All of the Bad News about is_equivalent()?

Not really.  You also have to remember that it typically requires network
traffic.  It's easy to fall into the wishful thinking that the ORB can handle
is_equivalent() for you, but, in general, it doesn't.



[21.11] So why don't we just Compare Stringified References?

First, the object may have moved in between the times that its references were
stringified, so the strings may not be identical.  Also, there are potential
problems if you have multiple vendors because stringified object references can
be quite ORB-specific.



[21.12] This sounds Too Complicated. Should I just learn DCOM instead?

No, not at all.  We've taken you into the depths of a topic that has deep
philosophical roots, which has been the focus of arguments for many years. Most
people never need this kind of knowledge.  We warned you earlier, didn't we?
And you just had to know, didn't you?



[21.13] Why do you say, "Most people never need this kind of knowledge"?

From a practical standpoint, these considerations don't come up all that often,
even for people who have to work at this level.  Fortunately, most users can
merely use the Naming Service and work with (essentially) character strings for
names, and avoid all the complexity above.



[21.14] Then why did you just Drag us through the Mud?

You're the one who wanted to be an expert. We just wanted to raise your
awareness so that you'll think twice when comparing object references. Besides,
this is a good way to illustrate how CORBA requires a little learning on your
part.



[21.15] How are Object References declared in C?

The IDL compiler will generate code that typedefs your interface to a
CORBA_Object.



[21.16] How are Object References handled in C++?

Two ways, _var and _ptr.  The idea behind _var is to force automatic memory
management, where allocation is off of the stack and memory is returned when
the object reference goes out of scope. On the other hand, _ptr object
references require specific management, including freeing memory at the
appropriate time.



[21.17] When do I use _var instead of _ptr?

Use _var when you can, because they are simpler.  Use _ptr when you have to,
usually for performance reasons.  Sometimes there are critical windows you
can't afford to let the system take over memory management.  As a very rough
guide, think about _ptr when you have many fine-grained objects and known
timing or performance problems.



[21.18] What if I want to invoke Methods on an Object in another ORB?

Then you need to know about interoperable object references (IOR).



[21.19] Does an IOR have a Defined Format and, if so, Why?

Yes, because this is something that inherently requires cooperation between
different vendors and ORBs.  Ordinary object references exist within an ORB so
there was no compelling reason to standardize formats.



[21.20] What is the Format of an IOR?

The specific details can be found at the OMG web site, and probably shouldn't
matter to you.  But it doesn't hurt to know that an IOR consists of a type ID
and one or more tagged profiles.



[21.21] What is a Tag?

A tag indicates the protocol ID from the most recent protocol change as the IOR
flowed from its home ORB to your local ORB (we'll discuss what this is all
about when we get into more detail on bridges and interoperability), and is
something that is registered with OMG; for instance, IIOP[40] has an ID of
zero.



[21.22] What is a Profile?

A high-performance way for an ORB to tell another ORB what it needs to know to
use the IOR properly.  There are two types, single- and multiple-component.
Both typically contain information about the presence of ORB services such as
Transaction Service.



[21.23] What is the Difference between the two Types of Profiles?

It depends.  Profiles are defined by the people who developed the protocol and
registered its tag with OMG.  IIOP[40] uses a single-component profile, while
DCE CIOP uses a multiple-component profile.



[21.24] Why did you say that the Specific Details Probably Shouldn't Matter?

You'll probably never need them because you'll probably never see an example of
an IOR.  These only exist in the nether world between ORBs.



[21.25] But how does my program use an IOR?

It doesn't.  Your local ORB creates a local proxy for the remote object
represented by the IOR.  All your program ever sees directly is the object
reference for the proxy.  The ORB takes care of everything else.



[21.26] This Expert Stuff isn't so tough. What about Stringifying an IOR?

You never learn, do you?  Let's discuss this at another time.  When you are in
a position where you need this knowledge, you won't be getting your information
from this document.  In the meantime, learn all about Naming Service.




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

      [22] Factories and Factory Finders
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[22.1] What is a Factory?

A factory is a CORBA Object that returns another CORBA object via one of its
CORBA operations.  There are many different types of factories with many
different purposes.  In fact, the OMG has defined several services that are
actually factories.



[22.2] What are some typical types of factories?

There are several types of factories:

* Generic:  A generic factory is a factory (CORBA Object) that is capable of
  returning other CORBA Objects.  These CORBA Objects are generic.  This means
  that they can be of any type, rather than a specific type.  The
  SomeFactory::GenericCreate() operation causes the SomeFactory interface to be
  a generic factory.  The NamingContext object defined as part of the CORBA
  Naming Service is a classic example of a generic factory.
* Specific:  A specific factory is a factory (CORBA Object) that is capable of
  returning a specific type of pre-defined CORBA Object. The
  SomeFactory::SpecificCreate() operation causes the SomeFactory interface to
  be a specific (or typed) factory.
* In-process:  An in-process factory is a factory which is implemented in the
  same process as the object which is created or managed by it.
* Out-process: An out-process factory is a factory which is implemented in a
  process different from the one of the object which is created or managed by
  it.

    //IDL

    interface AnObject {       boolean ping();     };

    interface SomeFactory {       CORBA::Object GenericCreate();       AnObject
    SpecificCreate();     };



[22.3] Does the CORBA specification define any specific capabilities for a
       factory object?

The CORBA Lifecycle specification defines a GenericFactory interface from which
all factories should inherit, but this is not required.  The CORBA
specification also defines a factory for factories, known as a factory finder.
The factory finder is a just a CORBA factory which act as a factory for other
factory interfaces.




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

      [23] Reference Counting Architectures
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[23.1] What is a distributed reference counting architecture?

Distributed reference counting is something typically performed either by a
remote object, the factory for the remote object or possibly by the ORB itself.
The key concept is that something is tracking the number of connections to a
particular remote object.  The counter is incremented when a new reference to
the remote object is created.  The counter is decremented when  a reference to
the remote object is destroyed.  The idea is that by looking at the counter,
one can determine if the remote object is still in use.



[23.2] Why would an application implement a distributed reference counting
       architecture?

There are several reasons why reference counting might be important.

* Clean-up: An application might like to know that a remote object no longer
  has active references.   The typical reason is that object that are no longer
  in use can be removed from memory.  This allows resources associated with a
  remote object to be reclaimed.   This is especially important if a distinct
  remote object exists for each client application.
* Reporting:  In many cases it might be helpful to know the usage patterns for
  a particular remote object.  Without reference counting, an object could only
  report the total number of method invocations performed.  Information
  regarding the number of connected clients or average usage per client would
  only be available  if a reference counting architecture was in place.
* Load Balancing:  In some cases, a client might gain access to a remote object
  via an out-of-process factory.  The goal of the factory might be to support
  clients via a pool of remote objects hosted on different machines. The
  factory can choose which remote object to return based on actual usage.
  Reference counting might be one mechanism for determining a remote object's
  "load".



[23.3] Does CORBA support distributed reference counting architectures?

CORBA does not directly support distributed reference counting.  This was a
conscious decision on  the part of its designers.  While CORBA does not
directly support reference counting, it is possible to build reference counting
into a particular distributed object architecture.   This can be done through
an explicit session management facility which can be exposed through factories
or other remote interfaces.  While it is possible to design reference counting
into an application, it is the burden of the application designer/developer to
ensure that such an approach is implemented correctly.



[23.4] What problems might be associated with a distributed reference counting
       architecture?

The designers of the CORBA specification chose not to support distributed
reference counting for several specific reasons.

* Error prone:  Distributed reference counting relies upon the developer to
  properly increment and decrement the reference counting mechanism.  Failure
  to do so can result in disappearing objects or orphaned objects that have no
  users.
* Performance problems:  In some cases, clients terminate abnormally without
  properly releasing references.  This results in reference counts not being
  decremented.  In order to survive such situations without leaving remote
  object orphaned,  objects must occasionally ping clients to determine if they
  are alive.  This can result in excessive network traffic and cause
  performance problems.
* No support for persistent object references:   CORBA allows object references
  to be stringified, stored, and objectified without losing their remote
  context.  An object reference can be considered valid even if its connection
  terminates or if the remote object is destroyed.  Supporting both persistent
  object references and reference counting is very difficult since counting
  stringified object references may not be possible.

Some distributed frameworks such as DCOM are built around a distributed
reference counting architecture.



[23.5] Is there an alternative to distributed reference counting architectures?

Yes: connection-less architectures.

With a connection-less architecture, an object does not "know" any thing about
the object references which refer to it, including the number of references.
This is the style found most often on the World Wide Web.




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

      [24] Performance Issues
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[24.1] Can CORBA Applications be Tuned for Better Performance?

Darn right.  There are a number of ways to tune CORBA applications for better
performance.

* Remember that distribution should only be used if a reason to do so exists.
  Distribution does not make sense for the sake of distribution.  If
  distribution does not serve a purpose then it should be avoided.  Avoiding
  excessive distribution can result in better performance.  Care should be
  taken when introducing distribution into an applications object model.
* IDL interfaces can be tuned to minimize network latency.  Invoking remote
  operations requires transmitting data across the network.  Network
  performance is typically optimized by ensuring adequate bandwidth.  Once the
  required bandwidth is achieved raw network performance cannot be increased.
  One key to tuning an IDL interface is to reduce the number of network
  transfers that need to occur.  Calling an operation that returns 100 bytes
  might take 5 milliseconds.  Calling an operation that returns 200 bytes of
  data might take around 6 milliseconds.  Calling 2 operations that return 100
  bytes might take a total of 10 milliseconds.  One key to tuning IDL
  operations is to avoid implementing several get operations and to combine
  them into a single get operation which returns the appropriate combination of
  data.
* Caching results of remote operations can avoid network overhead associated
  with calling the same remote methods more than once.  Many applications can
  perform remote operations upon startup rather than during normal usage.
  Users are often more willing to wait at startup time rather than during
  application usage.
* Many performance problems are associated with serialization and blocking
  conditions.  For example, Let us assume that clients will be making remote
  operations to a single server.  A single client's request causes the server
  to block for a extended period of time, the entire client community might
  have to wait.  Make sure that multiple distributed operations are not
  becoming serialized within a single server process.  Utilize multiple server
  processes or threaded servers instead.



[24.2] Do Different CORBA Implementations perform at Significantly Different
       Levels?

Wow, you bet they can.

Different CORBA implementations can vary significantly in performance.  Good
implementations should be fairly similar since network performance defines the
maximum achievable performance characteristics.  Network latency does represent
the significant portion of distributed invocation latency.



[24.3] What Types of Performance should I be Concerned With?

There are many different performance characteristics that are important.
Performance should also scale linearly as connections or objects increase.
While raw throughput between one client and one server is important, it is not
the only or the most critical characteristic.  Many characteristics of the
CORBA implementation should be considered.  As always, actual application
requirements to the relative importance of these different characteristics.
With the high speed nature of most CORBA implementations, raw client/server
throughput is often not a bottleneck.  It is also important that factors such
as the number of operations does not slow down individual remote invocations. A
lists of some important performance characteristics is listed below.

* Scalability across connected client applications.
* Scalability across objects within a CORBA server.
* Raw throughout between one client and one server.
* Activation time of server processes.
* Activation time of CORBA objects.
* Streaming time for different IDL types.
* Connection time associated with the first remote operation, _narrow call,
  _is_a call etc.
* Minimum memory consumed by a CORBA object.
* Number of file descriptors consumed by a complex network of distributed
  objects.




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

      [25] Interoperability Overview
      (Part of the CORBA FAQ, Copyright (C) 1996)

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

  (Under Construction; Please Be Patient!)




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

      [26] Miscellaneous Issues
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[26.1] Should I use Underscores ("_") in the Names of Interfaces and/or
       Methods?

In other words, when representing the concept of a "foreign exchange rate" in
IDL, should the IDL interface be called ForeignExchangeRate or
Foreign_Exchange_Rate?  Similarly should a method to "execute the trade" be
called executeTheTrade() or execute_the_trade()?

There are many stylistic issues that boil down to "I think it looks better this
way or that way."  But from a development/maintenance cost perspective, these
have little if any value.  However there are some nits that can bite you if you
choose one over the other.

If you expect to interoperate with Smalltalk, the underscore can create an
ambiguity, particularly if you mix the two styles.  For example, the IDL names
execute_the_trade() and executeTheTrade() both are mapped into the Smalltalk
name executeTheTrade(), which could create an ambiguity if the styles are
mixed.  In this case, it is best to avoid the underscores.

Similarly if you expect to interoperate with the C language, the IDL :: token
is mapped to an _ in C, which can create ambiguities.  In this case it is best
to avoid the underscores.

It's a small point, to be sure, but it can catch up to you in the long run.




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

      [27] Basic CORBA Architecture
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[27.1] What is the basic CORBA architecture?

The CORBA architecture is designed to support the distribution of objects
implemented in a variety of programming languages.  This is achieved by
defining an interface definition language that can be mapped to a number of
existing languages.  IDL is used to define the services offered by a particular
distributed object.  CORBA defines a wire protocol for making requests to an
object and for the object to respond to the application making the request. The
IIOP protocol[40] ensures interoperability between client applications and
server based objects.  CORBA then extends on this basic set of functionality by
defining a set of low level services.  These services are required by
applications regardless of the exact nature of the applications. These services
are defined in CORBA IDL.  CORBA vendors preprocess the service IDL and then
implement the service with varying degrees of robustness.




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

      [28] CORBA Objects
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[28.1] How are CORBA Objects Defined?

CORBA objects are defined as Interfaces in IDL.



[28.2] What Capabilities do CORBA Objects Possess?

CORBA objects support operations that take and return simple and complex IDL
types.




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

      [29] Pseudo Objects
      (Part of the CORBA FAQ, Copyright (C) 1996)

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

  (Under Construction; Please Be Patient!)




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

      [30] Interface Definition Language (IDL)
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[30.1] What is the purpose of IDL?

IDL stands for Interface Definition Language.  Its purpose is to define the
capabilities of a distributed service along with a common set of data types for
interacting with those distributed services.  IDL meets a number of objectives:

* Language Independence:
* Distributed service specification:
* Definition of complex data types:
* Hardware Independence:



[30.2] Do I program in IDL?

No, it is an interface language.  Applications are not programmed in IDL. IDL
is used to define two basic types of entities:

* Complex Data types shared between clients and servers:  IDL supports 8 basic
  data types and allows complex data types to be composed of the basic types.
* Capabilities of Distributed  Objects (CORBA Interfaces):



[30.3] Is IDL a Specification Language, an Implementation Language, or Both?

A specification language.

IDL makes a strong separation between the specification of an object and the
implementation of that object.  Programmers who use the interface of an object
have no idea whatsoever how that object is implemented.  For example, the
object doesn't even need to be implemented using an OO programming language.

This is called "Separation of Interface from Implementation," and is a very
important concept in OO in general and in CORBA in particular.



[30.4] Does my implementation need to use Inheritance just because my IDL
       intrerface uses Inheritance?

Nope.

Even though a CORBA interface might utilize inheritance, the object
implementation is not required to utilize inheritance.  For example, given the
following two IDL interfaces:

    interface Base           { void f(); };     interface Derived : Base { void
    g(); };

Suppose interface Base is implemented by class Base_impl and interface Derived
is implemented by class Derived_impl.  The key insight of this FAQ is that
class Derived_impl does not need to inherit from class Base_impl.  For example,
Derived_impl could implement method f() directly, or it could contain a pointer
to a Base_impl object and delegate f() to that object, or it could use some
other technique.

This is an example of the separation of interface from implementation[30.3].



[30.5] How do I express Aggregation in IDL?

The aggregation of two objects is a very common OO design concept.  Aggregation
is also known as has-a and contains.

Since IDL doesn't support "public data," a programmer that is using an IDL
interface cannot tell whether an aggregation is actually implemented using
aggregation or by some other technique.  In other words, IDL is a specification
language that separates interface from implementation[30.3].  In particular,
IDL does not support implementation constructs such as aggregation.

However logical aggregation is supported by IDL: IDL lets you specify an
operation that returns another interface, and this second interface could
represent an object that is logically contained within the first object.
Whether it's actually implemented using aggregation or not is an implementation
issue, not a specification issue, and the implementer can do it either way
without requiring any changes to the IDL interface.

Note that DCOM[12] directly supports aggregation since DCOM combines
implementation issues with specification issues.  The COM<->CORBA interworking
specification[12.2] actually maps aggregation to and from inheritance (CORBA
IDL supports inheritance directly, and DCOM supports aggregation directly).




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

      [31] Skeletons and Implementation Objects
      (Part of the CORBA FAQ, Copyright (C) 1996)

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



[31.1] How does a CORBA Object provide its services?

A CORBA Object provides a set of services to its object references.  In
addition to the ORB and BOA, the CORBA Object requires two additional entities
in order to respond to requests.  First, something must listen for requests,
next something must perform the operation, and third, something must issue the
proper response based upon the results of the operation. These tasks are
performed by the skeleton and the object implementation. Conceptually, the
implementation object provides the actual operation "know-how" and the skeleton
provides the networking "know-how".  The skeleton and implementation, combine
with the ORB and the BOA to support the full behavior of the particular CORBA
Object.



[31.2] How are the skeleton and implementation object combined?

* Derived: In the derived approach, the implementation object "is" also a
  skeleton.  This is usually obtained via inheritance.  The ORB's IDL compiler
  would generate an appropriate skeleton class (based on the IDL interface and
  data types) and the developer would derive their own implementation class
  from it.  The skeleton is able to listen to the network,
  de-marshall/re-marshall data types, etc.  The implementation knows how and
  what to do within the body of the CORBA operations.  A CORBA server will
  simply instantiate the implementation and tell the BOA that it "is ready".
  Since the implementation "is" also a skeleton, the CORBA Object will be able
  to respond to CORBA requests.
* Delegated: In the delegated approach, The ORB's IDL compiler would generate
  an appropriate skeleton class (based on the IDL interface and data types)
  which would then delegate the actual operation execution to another class.
  The skeleton is still responsible for reading and writing to the network,
  de-marshall/re-marshall data types, etc.  The implementation knows how and
  what to do within the body of the CORBA operations.  While the implementation
  does not actually inherit from the skeleton, it still needs to implement the
  same set of minimal methods corresponding the to IDL operations.  A CORBA
  server will need to instantiate the skeleton, instantiate the implementation,
  instruct the skeleton as to the where abouts of the implementation (often
  known as TIEing the skeleton and implementation together) and the tell the
  BOA that the skeleton "is ready".

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