Monolithic Systems and Mainframes

•In the beginning (or close to it), there was the mainframe. Along with it
came hierarchical database systems and dumb terminals, also known as
green screens. Mainframes usually cost a great deal to maintain but
were capable of serving large numbers of users and had the advantage
(or disadvantage, depending on one’s point of view) of being centrally
managed.
•Software systems written for mainframes were often monolithic—that
is, the user interface, business logic, and data access functionality were
all contained in one large application. Because the dumb terminals used
to access mainframes didn’t do any of their own processing, the entire
application ran in the mainframe itself, thus making the monolithic
architecture reasonable
Typical monolithic application
architecture
 The Revolution: Client/Server
Architecture
• Client/server applications typically distributed the components of the
application so that the database would reside on the server (whether a
UNIX box or mainframe), the user interface would reside on the client,
and the business logic would reside in either, or both, components. When
changes were made to parts of the client component, new copies of the
client component (usually executables or a set of executables) had to be
distributed to each user. With the advent of multitier client/server
architecture (discussed in the next section), the “original” client/server
architecture
Two-tier client/server architecture.
 The Evolution: Multitier Client/Server
• The client/server architecture was in many ways a revolution from the old
way of doing things. Despite solving the problems with mainframe-based
applications, however, client/server was not without faults of its own.
• For example, because database access functionality (such as embedded
database queries) and business logic were often contained in the client
component, any changes to the business logic, database access, or even
the database itself, often required the deployment of a new client
component to all the users of the application.
• Usually, such changes would break earlier versions of the client
component, resulting in a fragile application.
• The problems with the traditional client/server (now often called “two-
tier” client/server) were addressed by the multitier client/server
architecture. Conceptually, an application can have any number of tiers,
but the most popular multitier architecture is three-tier, which partitions
the system into three logical tiers: the user interface layer, the business
rules layer, and the database access layer.
• Multitier client/server reduces application fragility by providing more
insulation and separation between layers. The user
• interface layer communicates only with the business rules layer, never
directly with the database access layer. The business
• rules layer, in turn, communicates with the user interface layer on one
side and the database access layer on the other. Thus,
• changes in the database access layer will not affect the user interface
layer because they are insulated from each other. This
• architecture enables changes to be made in the application with less
likelihood of affecting the client component (which,
• remember, has to be redistributed when there are any changes to it).
 Distributed Systems
• The next logical step in the evolution of application architectures is the
distributed system model. This architecture takes the
• concept of multitier client/server to its natural conclusion. Rather than
differentiate between business logic and data access,
• the distributed system model simply exposes all functionality of the
application as objects, each of which can use any of the
• services provided by other objects in the system, or even objects in other
systems. The architecture can also blur the
• distinction between “client” and “server” because the client components
can also create objects that behave in server-like
• roles. The distributed system architecture provides the ultimate in
flexibility.
• The distributed system architecture achieves its flexibility by encouraging (or
enforcing) the definition of specific component interfaces. The interface of a
component specifies to other components what services are offered by that
component and how they are used. As long as the interface of a component
remains constant, that component’s implementation can change dramatically
without affecting other components.
• For example, a component that provides customer information for a company
can store that information in a relational database. Later, the application
designers might decide that an object oriented database would be more
appropriate. The designers can make any number of changes to the
component’s implementation—even sweeping changes such as using a
different type of database—provided that they leave the component’s
interface intact. Again, as long as the interface of that component remains the
same, the underlying implementation is free to change.
• New Term: An interface defines the protocol of communication between two
separate components of a system. (These components can be separate
processes, separate objects, a user and an application—any separate entities
that need to communicate with each other.)
• The interface describes what services are provided by a component and the
protocol for using those services. In the case of an object, the interface can be
thought of as the set of methods defined by that object, including the input
and output parameters. An interface can be thought of as a contract; in a
sense, the component providing an interface promises to honor requests for
services as outlined in the interface.
• Distributed systems are really multitier client/server systems in which the
number of distinct clients and servers is potentially large. One important
difference is that distributed systems generally provide additional services,
such as directory services, which allow various components of the application
to be located by others. Other services might include a transaction monitor
service, which allows components to engage in transactions with each other.
• New Term: Directory services refers to a set of services that enable
objects—which can be servers, businesses, or even people—to be located
by other objects. Not only can the objects being looked up differ in type,
but the directory information itself can vary as well.
• For example, a telephone book would be used to locate telephone
numbers and postal addresses; an email directory would be used to locate
email addresses. Directory services encompass all such information,
usually grouping together related information (for example, there are
separate volumes of the yellow pages for different cities; contents of each
volume are further divided into types of businesses).
• New Term: A transaction monitor service oversees transactions on behalf
of other objects. A transaction, in turn, is an operation or set of
operations that must be performed atomically; that is, either all objects
involved in the transaction must commit the transaction (update their
own records) or all objects involved must abort the transaction (return to
their original state before the transaction was initiated).
• The result is that whether a transaction commits or aborts, all involved
objects will be in a consistent state. It is the job of a transaction monitor
to provide transaction-related services to other objects.
 Why CORBA?
• Distributed systems rely on the definition of interfaces between
components and on the existence of various services (such as directory
registration and lookup) available to an application. CORBA provides a
standard mechanism for defining the interfaces between components as
well as some tools to facilitate the implementation of those interfaces
using the developer’s choice of languages.
• In addition, the Object Management Group (the organization responsible
for standardizing and promoting CORBA) specifies a wealth of standard
services, such as directory and naming services, persistent object services,
and transaction services.
• Each of these services is defined in a CORBA-compliant manner, so they
are available to all CORBA applications. Finally, CORBA provides all the
“plumbing” that allows various components of an application—or of
separate applications—to communicate with each other.
• New Term: The capabilities of CORBA don’t stop there. Two features that
CORBA provides—features that are a rarity in
• the computer software realm—are platform independence and language
independence. Platform independence means that
• CORBA objects can be used on any platform for which there is a CORBA
ORB implementation (this includes virtually all
• modern operating systems as well as some not-so-modern ones).
Language independence means that CORBA objects and
• clients can be implemented in just about any programming language.
Furthermore, CORBA objects need not know which
• language was used to implement other CORBA objects that they talk to.
Soon you will see the components of the CORBA
• architecture that make platform independence and language
independence possible.
 Socket Programming
• New Term: In most modern systems, communication between machines, and
sometimes between processes in the same
• machine, is done through the use of sockets. Simply put, a socket is a channel through
which applications can connect with
• each other and communicate. The most straightforward way to communicate between
application components, then, is to use
• sockets directly (this is known as socket programming), meaning that the developer
writes data to and/or reads data from a
• socket.
• The Application Programming Interface (API) for socket programming is rather low-
level. As a result, the overhead
• associated with an application that communicates in this fashion is very low. However,
because the API is low-level, socket
• programming is not well-suited to handling complex data types, especially when
application components reside on different
• types of machines or are implemented in different programming languages. Whereas
direct socket programming can result in
• very efficient applications, the approach is usually unsuitable for developing complex
applications.
 Remote Procedure Call (RPC)
• New Term: One rung on the ladder above socket programming is Remote
Procedure Call (RPC). RPC provides a functionoriented
• interface to socket-level communications. Using RPC, rather than directly
manipulating the data that flows to and
• from a socket, the developer defines a function—much like those in a
functional language such as C—and generates code
• that makes that function look like a normal function to the caller. Under
the hood, the function actually uses sockets to
• communicate with a remote server, which executes the function and
returns the result, again using sockets.
• Because RPC provides a function-oriented interface, it is often much
easier to use than raw socket programming. RPC is also
• powerful enough to be the basis for many client/server applications.
Although there are varying incompatible
• implementations of RPC protocol, a standard RPC protocol exists that is
readily available for most platforms.
 OSF Distributed Computing
Environment (DCE)
• The Distributed Computing Environment (DCE), a set of
standards pioneered by the Open Software Foundation (OSF),
• includes a standard for RPC. Although the DCE standard has
been around for some time, and was probably a good idea, it
• has never gained wide acceptance and exists today as little
more than an historical curiosity
Microsoft Distributed Component
Object Model (DCOM)
Java Remote Method Invocation (RMI)
• The tour of exploring CORBA alternatives stops with Java Remote Method
Invocation (RMI), a very CORBA-like architecture with a few twists. One
advantage of RMI is that it supports the passing of objects by value, a
feature not (currently) supported by CORBA.
• A disadvantage, however, is that RMI is a Java-only solution; that is, RMI
clients and servers must be written in Java. For all-Java applications—
particularly those that benefit from the capability to pass objects by value
—RMI might be a good choice, but if there is a chance that the application
will later need to interoperate with applications written in other
languages, CORBA is a better choice.
• Fortunately, full CORBA implementations already exist for Java, ensuring
that Java applications interoperate with the rest of the CORBA world.
 CORBA History
Introducing the Object Management Group
(OMG)
• The Object Management Group (OMG), established in 1989 with eight
original members, is a 760-plus-member organization whose charter is to
“provide a common architectural framework for object-oriented
applications based on widely available interface specifications.”
• That’s a rather tall order, but the OMG achieves its goals with the
establishment of the Object Management Architecture (OMA), of which
CORBA is a part. This set of standards delivers the common architectural
framework on which applications are built.
• Very briefly, the OMA consists of the Object Request Broker (ORB)
function, object services (known as CORBA services), common facilities
(known as CORBA facilities), domain interfaces, and application objects.
CORBA’s role in the OMA is to implement the Object Request Broker
function.
 CORBA 1.0
• Following the OMG’s formation in 1989, CORBA 1.0 was introduced and
adopted in December 1990. It was followed in early 1991 by CORBA 1.1,
which defined the Interface Definition Language (IDL) as well as the API
for applications to communicate with an Object Request Broker (ORB).
revision appeared shortly before CORBA 2.0, which with its added
features quickly eclipsed the 1.x revisions.
• The CORBA 1.x versions made an important first step toward object
interoperability, allowing objects on different machines, on different
architectures, and written in different languages to communicate with
each other.
 CORBA 2.0 and IIOP
• CORBA 1.x was an important first step in providing distributed object
interoperability, but it wasn’t a complete specification. Although it
provided standards for IDL and for accessing an ORB through an
application, its chief limitation was that it did not specify a standard
protocol through which ORBs could communicate with each other. As a
result,
• a CORBA ORB from one vendor could not communicate with an ORB from
another vendor, a restriction that severely limited interoperability among
distributed objects.
• Enter CORBA 2.0. Adopted in December 1994, CORBA 2.0’s primary
accomplishment was to define a standard protocol by which ORBs from
various CORBA vendors could communicate.
• This protocol, known as the Internet Inter-ORB Protocol (IIOP,
pronounced “eye-op”), is required to be implemented by all vendors who
want to call their products CORBA 2.0 compliant.
• Essentially, IIOP ensures true interoperability among products from
numerous vendors, thus enabling CORBA applications to be more vendor-
independent. IIOP, being the Internet Inter-ORB Protocol, applies only to
networks based on TCP/IP, which includes the Internet and most
intranets.
 CORBA Architecture Overview
• First of all, CORBA is an object-oriented architecture. CORBA objects
exhibit many features and traits of other object oriented systems,
including interface inheritance and polymorphism.
• What makes CORBA even more interesting is that it provides this
capability even when used with non object-oriented languages such as C
and COBOL, although CORBA maps particularly well to object-oriented
languages like C++ and Java.
• New Term: Interface inheritance is a concept that should be familiar to
Objective C and Java developers. In the contrasting implementation
inheritance, an implementation unit (usually a class) can be derived from
another.
• By comparison, interface inheritance allows an interface to be derived
from another. Even though interfaces can be related through inheritance,
the implementations for those interfaces need not be.
 The Object Request Broker (ORB)
• Fundamental to the Common Object Request Broker Architecture is the
Object Request Broker, or ORB. (That the ORB acronym appears within
the CORBA acronym was just too much to be coincidental.) An ORB is a
software component whose purpose is to facilitate communication
between objects.
• It does so by providing a number of capabilities, one of which is to locate a
remote object, given an object reference. Another service provided by the
ORB is the marshaling of parameters and return values to and from
remote method invocations.
Interface Definition Language (IDL)
• Another fundamental piece of the CORBA architecture is the use of the
Interface Definition Language (IDL). IDL, which specifies interfaces
between CORBA objects, is instrumental in ensuring CORBA’s language
independence.
• Because interfaces described in IDL can be mapped to any programming
language, CORBA applications and components are thus independent of
the language(s) used to implement them.
• In other words, a client written in C++ can communicate with a server
written in Java, which in turn can communicate with another server
written in COBOL, and so forth.
• One important thing to remember about IDL is that it is not an
implementation language. That is, you can’t write applications in IDL. The
sole purpose of IDL is to define interfaces; providing implementations for
these interfaces is performed using some other language.
 The CORBA Communications Model
• New Term: CORBA uses the notion of object references (which in
CORBA/IIOP lingo are referred to as Interoperable Object References, or
IORs) to facilitate the communication between objects.
• When a component of an application wants to access a CORBA object, it
first obtains an IOR for that object. Using the IOR, the component (called a
client of that object) can then invoke methods on the object (called the
server in this instance)
• In CORBA, a client is simply any application that uses the services of a
CORBA object; that is, an application that invokes a method or methods
on other objects. Likewise, a server is an application that creates CORBA
objects and makes the services provided by those objects available to
other applications.
• CORBA ORBs usually communicate using the Internet Inter-ORB Protocol
(IIOP). Other protocols for inter-ORB communication exist, but IIOP is fast
becoming the most popular, first of all because it is the standard, and
second because of the popularity of TCP/IP (the networking protocols
used by the Internet), a layer that IIOP sits on top of.
• CORBA is independent of networking protocols, however, and could (at
least theoretically) run over any type of network protocols. For example,
there are also implementations of CORBA that run over DCE rather than
over TCP/IP, and there is also interest in running CORBA over ATM and
SS7.
 The CORBA Object Model
• In CORBA, all communication between objects is done through object
references (again, these are known as Interoperable Object References, or
IORs, if you’re using IIOP). Furthermore, visibility to objects is provide only
through passing references to those objects; objects cannot be passed by
value (at least in the current specification of CORBA).
• In other words, remote objects in CORBA remain remote; there is
currently no way for an object to move or copy itself to another location.
 CORBA Clients and Servers
• Like the client/server architectures, CORBA maintains the notions of
clients and servers. In CORBA, a component can act as both a client and as
a server.
• Essentially, a component is considered a server if it contains CORBA
objects whose services are accessible to other objects. Likewise, a
component is considered a client if it accesses services from some other
CORBA object.
• Of course, a component can simultaneously provide and use various
services, and so a component can be considered a client or a server,
depending on the scenario in question.
 Stubs and Skeletons
• When implementing CORBA application components, you will encounter
what are known as client stubs and server skeletons. A client stub is a
small piece of code that allows a client component to access a server
component.
• This piece of code is compiled along with the client portion of the
application. Similarly, server skeletons are pieces of code that you “fill in”
when you implement a server.
• You don’t need to write the client stubs and server skeletons themselves;
these pieces of code are generated when you compile IDL interface
definitions.
 The Object Request Broker (ORB)
• a fundamental part of the Common Object Request Broker architecture is
the Object Request Broker (ORB).
• The concept of an ORB is this: When an application component wants to
use a service provided by another component, it first must obtain an
object reference for the object providing that service.
• After an object reference is obtained, the component can call methods
on that object, thus accessing the desired services provided by that
object. (The developer of the client
• component knows at compile time which methods are available from a
particular server object.)
• The primary responsibility of the ORB is to resolve requests for object
references, enabling application components to establish connectivity
with each other.
 Marshaling
• After an application component has obtained a reference to an object
whose services the component wants to use, that component can invoke
methods of that object.
• Generally, these methods take parameters as input and return other
parameters as output. Another responsibility of the ORB is to receive the
input parameters from the component that is calling the method and to
marshal these parameters.
• What this means is that the ORB translates the parameters into a format
that can be transmitted across the network to the remote object. (This is
sometimes referred to as an on-the-wire format.)
• The ORB also unmarshals the returned parameters, converting them from
the on-the-wire format into a format that the calling component
understands
• New Term: Marhsaling refers to the process of translating input parameters to a
format that can be transmitted across a network.
• Unmarshaling is the reverse of marshaling; this process converts data from the
network to output parameters.
• An On-the-wire format specifies the format in which data is transmitted across the
network for the marshaling and unmarshaling processes.
• The entire marshaling process takes place without any programmer intervention
whatsoever.
• A client application simply invokes the desired remote method—which has the
appearance of being a local method, as far as the client is concerned— and a result
is returned (or an exception is raised), again, just as would happen with a local
method.
• The entire process of marshaling input parameters, initiating the method
invocation on the server, and unmarshaling the return parameters is performed
automatically and transparently by the ORB.
 Platform Independence
• A product of the marshaling/unmarshaling process is that, because
parameters are converted upon transmission into a platform-independent
format (the on-the-wire format is provided as part of the CORBA
specification) and converted into a platform-specific format upon
reception, the communication between components is platform-
independent.
• This means that a client running on, for instance, a Macintosh system can
invoke methods on a server running on a UNIX system. In addition to
independence of operating system used, differences in hardware (such as
processor byte ordering, or endianness) are also
• rendered irrelevant because the ORB automatically makes these
conversions as necessary.
• In essence, any differences in platforms—be it operating system,
endianness, word size, and so on—are accounted for by the ORB.
• Note again that the process of marshaling and unmarshaling parameters
is handled completely by the ORB, entirely transparent to both the client
and server. Because the entire process is handled by the ORB, the
developer need not concern himself with the details of the mechanism by
which the parameters are marshaled and unmarshaled
 ORB Summary
• Because the concept of the ORB is central to an understanding of the
CORBA architecture, it is important to make sure that you grasp the ORB
concepts. To summarize the purpose of the ORB, its responsibilities are as
follows:
• • Given an object reference from a client, the ORB locates the
corresponding object implementation (the server) on behalf of the client.
(Note that it is the responsibility of the client to obtain an object
reference in the first place, through a process you’ll learn later.)
• • When the server is located, the ORB ensures that the server is ready to
receive the request.
• • The ORB on the client side accepts the parameters of the method being
invoked and marshals (see the next section) the parameters to the
network.
• • The ORB on the server side unmarshals (again, see the next section) the
parameters from the network and delivers them to the server.
• • Return parameters, if any, are marshaled/unmarshaled in the same way.
• The major benefit offered by the ORB is its platform-independent
treatment of data; parameters can be converted on-the-fly between
varying machine formats as they are marshaled and unmarshaled.
Interface Definition Language (IDL)
• If the concept of the Object Request Broker is one cornerstone of the
CORBA architecture, the Interface Definition Language (IDL) is the other.
IDL, as its name suggests, is the language used to define interfaces
between application components.
• Note that IDL is not a procedural language; it can define only interfaces,
not implementations. C++ programmers can think of IDL definitions as
analogous to header files for classes; a header file typically does not
contain any implementation of a class but rather describes that class’s
interface.
• Java programmers might liken IDL definitions to definitions of Java
interfaces; again, only the interface is described—no implementation is
provided.
• New Term: The Interface Definition Language (IDL) is a standard language
used to define the interfaces used by CORBA objects.
• The IDL specification is responsible for ensuring that data is properly
exchanged between dissimilar languages. For example, the IDL long type
is a 32-bit signed integer quantity, which can map to a C++ long
(depending on the platform) or to a Java int.
• It is the responsibility of the IDL specification—and the IDL compilers that
implement it—to define such data types in a language-independent way.
 Language Independence
• The IDL language is part of the standard CORBA specification and is
independent of any programming language.
• It achieves this language independence through the concept of a
language mapping. The OMG has defined a number of standard language
mappings for many popular languages, including C, C++, COBOL, Java, and
Smalltalk.
• Mappings for other languages exist as well; these mappings are either
nonstandard or are in the process of being standardized by the OMG.
• New Term: A language mapping is a specification that maps IDL language
constructs to the constructs of a particular programming language. For
example, in the C++ language mapping, the IDL interface maps to a C++
class.
• Language independence is a very important feature of the CORBA
architecture. Because CORBA does not dictate a
• particular language to use, it gives application developers the freedom to
choose the language that best suits the needs of their
• applications. Taking this freedom one step further, developers can also
choose multiple languages for various components of
• an application. For instance, the client components of an application
might be implemented in Java, which ensures that the
• clients can run on virtually any type of machine. The server components
of that application might be implemented in C++ for
• high performance. CORBA makes possible the communication between
these various components.
 The CORBA Communications Model
• In order to understand CORBA, you must first understand its role in a
network of computing systems. Typically, a computer network consists of
systems that are physically connected (although the advent of wireless
network technology might force us to revise our understanding of what
“physically connected” means).
• This physical layer provides the medium through which communication
can take place, whether that medium is a telephone line, a fiber-optic
cable, a satellite uplink, or any combination of networking technologies.
• Somewhere above the physical layer lies the transport layer, which
involves protocols responsible for moving packets of data from one point
to another.
• In this age of the Internet, perhaps the most common transport protocol
in use is TCP/IP (Transmission Control Protocol/Internet Protocol).
• Most Internet-based applications use TCP/IP to communicate with each
other, including applications based on FTP (File Transfer Protocol), Telnet
(a host communication protocol), and HTTP (Hypertext Transport
Protocol, the basis for the World Wide Web).
• Somewhere above the physical layer lies the transport layer, which
involves protocols responsible for moving packets of data
• from one point to another. In this age of the Internet, perhaps the
most common transport protocol in use is TCP/IP
• (Transmission Control Protocol/Internet Protocol). Most Internet-
based applications use TCP/IP to communicate with each
• other, including applications based on FTP (File Transfer Protocol),
Telnet (a host communication protocol), and HTTP
• (Hypertext Transport Protocol, the basis for the World Wide Web).
 Inter-ORB Protocols
• So how does CORBA fit into this networking model? It turns out that the
CORBA specification is neutral with respect to network protocols; the
CORBA standard specifies what is known as the General Inter-ORB
Protocol (GIOP), which specifies, on a high level, a standard for
communication between various CORBA ORBs and components.
• GIOP, as its name suggests, is only a general protocol; the CORBA
standard also specifies additional protocols that specialize GIOP to use a
particular transport protocol.
• For instance, GIOP-based protocols exist for TCP/IP and DCE (the Open
Software Foundation’s Distributed Computing Environment protocol).
Additionally, vendors can (and do) define and use proprietary protocols
for communication between CORBA components.
• New Term: The General Inter-ORB Protocol (GIOP) is a high-
level standard protocol for communication between ORBs.
• Because GIOP is a generalized protocol, it is not used
directly; instead, it is specialized by a particular protocol
that would
• then be used directly.
• New Term: The Internet Inter-ORB Protocol (IIOP) is a
specialization of the GIOP. IIOP is the standard protocol for
• communication between ORBs on TCP/IP based networks.
An ORB must support IIOP (but can support other
additional
• protocols) in order to be considered CORBA 2.0-compliant
CORBA and the Networking Model
 The CORBA Object Model
• Every object-oriented architecture features an object model, which
describes how objects are represented in the system.
• Of course, CORBA, being an object-oriented architecture, has an object
model as well. Because CORBA is a distributed architecture, however, its
object model probably differs somewhat from the traditional object
models with which most readers are familiar (such as C++’s or Java’s
object model).
• Three of the major differences between the CORBA object model and
traditional models lie in CORBA’s “semi-transparent” support for object
distribution, its treatment of object references, and its use of what are
called object adapters—particularly the Basic Object Adapter (BOA). You
will now explore these concepts in greater depth.
 Object Distribution
• To a CORBA client, a remote method call looks exactly like a local method
call, thanks to the use of client stubs (a concept you’ll explore later in this
chapter).
• Thus, the distributed nature of CORBA objects is transparent to the users
of those objects; the clients are unaware that they are actually dealing
with objects which are distributed on a network.
 Object References
• In a distributed application, there are two possible methods for one
application component to obtain access to an object in another process.
One method is known as passing by reference, illustrated in Figure 2.4. In
this method,
• the first process, Process A, passes an object reference to the second
process, Process B. When Process B invokes a method on that object, the
method is executed by Process A because that process owns the object.
(The object exists in the memory and process space of Process A.)
• Process B only has visibility to the object (through the object reference),
and thus can only request that Process A execute methods on Process B’s
behalf. Passing an object by reference means that a process grants
visibility of one of its objects to another process while retaining ownership
of that object
• New Term: When an object is passed by reference, the object itself
remains “in place” while an object reference for that object is passed.
Operations on the object through the object reference are actually
processed by the object itself.
• The second method of passing an object between application components
is known as passing by value and is depicted in Figure 2.5.
• In this method, the actual state of the object (such as the values of its
member variables) is passed to the requesting component (typically
through a process known as serialization).
• When methods of the object are invoked by Process B, they are executed
by Process B instead of Process A, where the original object resides.
Furthermore, because the object is passed by value, the state of the
original object is not changed; only the copy (now owned by Process B) is
modified.
• Generally, it is the responsibility of the developer to write the code that
serializes and deserializes objects (although this capability is built into
some languages, such as Java)
• New Term: When an object is passed by value, the object’s state is copied
and passed to its destination, where a new copy of the object is
instantiated. Operations on that object’s copy are processed by the copy,
not by the original object.
• Serialization refers to the encoding of an object’s state into a stream, such
as a disk file or network connection. When an object is serialized, it can be
written to such a stream and subsequently read and deserialized, a
process that converts the serialized data containing the object’s state
back into an instance of the object
 Basic Object Adapters (BOAs)
• The CORBA standard describes a number of what are called object
adapters, whose primary purpose is to interface an object’s
implementation with its ORB.
• The OMG recommends that new object adapter types be created only
when necessary and provides three sample object adapters: the Basic
Object Adapter (BOA), which you will concentrate on, and the Library
Object Adapter and Object-Oriented Database Adapter, both of which are
useful for accessing objects in persistent storage.
• (The CORBA specification describes these object adapters in greater
detail.) Again, you will concern yourself only with the Basic Object
Adapter, by far the most commonly used object adapter.
• The BOA provides CORBA objects with a common set of methods for
accessing ORB functions.
• These functions range from user authentication to object activation to
object persistence.
• The BOA is, in effect, the CORBA object’s interface to the ORB. According
to the CORBA specification, the BOA should be available in every ORB
implementation, and this seems to be the case with most (if not all)
CORBA products available.
 Server Activation Policies
• One particularly important (and useful) feature of the BOA is its object
activation and deactivation capability. The BOA supports four types of
activation policies, which indicate how application components are to be
initialized. These activation policies include the following:
• • The shared server policy, in which a single server (which in this context
usually means a process running on a machine) is shared between
multiple objects
• • The unshared server policy, in which a server contains only one object
• • The server-per-method policy, which automatically starts a server when
an object method is invoked and exits the server when the method
returns
• • The persistent server policy, in which the server is started manually (by
a user, batch job, system daemon, or some other external agent)
• New Term: A server activation policy indicates how that particular
server is intended to be accessed; for example, if there is a single
server used by all clients, or a new instance of the server should be
started for each client, and so on.
• This variety of activation policies allows an application architect to
choose the type of behavior that makes the most sense fora
particular type of server.
• For instance, a server requiring a length of time to initialize itself
might work best as a persistent server, because the necessary
initialization time would adversely affect the response time for that
server.
• On the other hand, a server that starts up quickly upon demand
might work well with the server-per-method policy.
• Note:It is worth noting here that the term persistent server has nothing to
do with the common use of the term persistent, which refers to the
capability of an object to store its state in some sort of nonvolatile storage
facility such as a database of disk files.
• A persistent server does not necessarily store its state in persistent
storage (although it could); in this case, the term merely implies that the
server runs persistently or, in other words, continuously.
 CORBA Clients and Servers
• Traditionally, in a client/server application, the server is the component,
or components, that provides services to other components of the
application. A client is a component that consumes services provided by a
server or servers.
• The architecture of a CORBA application is no different; generally, certain
components of an application provide services that are used by other
components of the application.
• Not surprisingly, the general terms client and server refer to these
components of a CORBA application. When considering a single remote
method invocation, however, the roles of client and server can be
temporarily reversed because a CORBA object can participate in multiple
interactions simultaneously.
• In a CORBA application, any component that provides an implementation
for an object is considered a server, at least where that object is
concerned. If a component creates an object and provides other
components with visibility to that object
• (in other words, allows other components to obtain references to that
object), that component acts as a server for that object; any requests
made on that object by other components will be processed by the
component that created the object.
• Being a CORBA server means that the component (the server) executes
methods for a particular object on behalf of other components (the
clients).
• Frequently, an application component can provide services to other
application components while accessing services from other components.
In this case, the component is acting as a client of one component and as
a server to the other components see Figure 2.6).
• In fact, two components can simultaneously act as clients and servers to
each other. To understand this situation, consider the following scenario
(illustrated in Figure 2.7): The first component, Component A, receives a
reference to an object created by a second component, Component B,
and calls a method on that object. Here, Component A acts as a client and
Component B acts as a server.
• Now assume that as a parameter of the method called, Component A
passes a reference to an object that it has created (and thus provides an
implementation for the object).
• Assume further that Component B now calls some method on that object.
For this particular method invocation, Component A acts as a server,
whereas Component B acts as a client.
• The two components have not changed their overall roles in the
application, but they have temporarily reversed their roles as client and
server. Therefore, from this example you see that in a CORBA application,
the terms client and server might depend on the context of the method
being called and in which component that method’s object resides.
• One last point to consider in the terminology of clients and servers: Although an
application component can function as both a client and a server, it is nevertheless
typical to label such a component as one or the other (not both).
• In the preceding example, assume that for the most part, Component A calls
methods on
• objects owned by Component B. As illustrated in the example, some (or even all)
of these method calls can pass object references to Component B, which can then
make calls through those object references back to Component A.
• Although Component A is acting as a server for these method calls, because the
overall function of the component is to use services provided by Component B,
and only provides objects as arguments to methods in Component B, you might
very well refer to Component A as the client and to Component B as the server.
Methods called in this way are generally referred to as client callback methods, or
simply callbacks.
• Callbacks are especially important given CORBA’s current lack of pass-byvalue
capability; the capability to pass objects by value, when it becomes available, will
eliminate the need for many callbacks.
• New Term: Client callback method, or simply
callback, is a generic term given to a method
that is implemented by a client
• and called by a server. Callbacks essentially
make a client
 Stubs and Skeletons
• After a developer creates component interface definitions using IDL, he or
she processes the resulting IDL files with an IDL compiler. The IDL compiler
generates what are known as client stubs and server skeletons.
• Client stubs and server skeletons serve as a sort of “glue” that connects
language-independent IDL interface specifications to language-specific
• implementation code.
• Client stubs for each interface are provided for inclusion with clients that
use those interfaces. The client stub for a particular interface provides a
dummy implementation for each of the methods in that interface. Rather
than execute the server functionality, however, the client stub methods
simply communicate with the ORB to marshal and unmarshal parameters.
• New Term: A client stub, which is generated by the IDL compiler, is
a small piece of code that makes a particular CORBA server
interface available to a client.
• A server skeleton, also generated by the IDL compiler, is a piece of
code that provides the “framework” on which the server
implementation code for a particular interface is built.
• On the other side, you have server skeletons, providing the
framework upon which the server is built. For each method of an
interface, the IDL compiler generates an empty method in the
server skeleton.
• The developer then provides an implementation for each of these
methods. Figure 2.8 illustrates how client stubs and server
skeletons fit into a CORBA application.