[20] APPLICATION ARCHITECTURES
(Part of the CORBA FAQ, Copyright © 1996)

[20.1] DOES CORBA DEFINE HIGH LEVEL APPLICATION ARCHITECTURES?

[Recently added first paragraph (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]

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.

[ Top | Bottom | Previous section | Next section ]

[20.2] DO COMMON APPLICATION ARCHITECTURES EXIST?

[Recently rewrote first paragraph for clarity (7/1997). Click here to go to the next FAQ in the “chain” of recent changes]

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 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 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.

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.