[21] APPLICATION ARCHITECTURES
(Part of the CORBA FAQ, Copyright © 1996-99)

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

[ Top | Bottom | Previous section | Next section ]

[21.2] DO COMMON APPLICATION ARCHITECTURES EXIST?

[Recently did some wordsmithing (12/1998) and added comparisons to EJB and removed BOA reference (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

There are many common application architectures 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. This is what EJB calls an EntityBean.
• Exclusive objects: An exclusive object is an object that is referred 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 Object Adapter can be used to control the process boundaries. The deprecated BOA unshared activation policies can be used to ensure that each exclusive object lives in its own process. The POA and POA Locator can be used to control which objects are in which processes. 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. This is what EJB calls a SessionBean.

Note: Object level properties such as “non-exclusive” or “exclusive” are orthogonal to the the Object Adapter used to make the CORBA object available to the system.

OTHER ARCHITECTURAL DISTINCTIONS MADE AT THE OBJECT LEVEL:

• Stateful Objects: A stateful 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. Stateful 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 stateful object, state is specific to a given client application. Stateful non-exclusive object maintain a common state across a set of client applications. While stateful 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. In EJB, EntityBeans are implicitly stateful and SessionBeans are designated as either stateless or stateful.
• 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 stateful 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. In EJB, EntityBeans are implicitly stateful and SessionBeans are designated as either stateless or stateful.

[ Top | Bottom | Previous section | Next section ]

[21.3] CAN CORBA APPLICATIONS HAVE CALLBACKS?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

Yes. The words client and server are really only applicable in the context of a remote call. In other words, the “client process” can also receive calls on CORBA objects that it implements and hands out the references to.

Also see the section on Notification.

[ Top | Bottom | Previous section | Next section ]

 E-mail us