VisiBroker for C++ Developer’s Guide : Understanding the CORBA model

Understanding the CORBA model
This section introduces VisiBroker, which comprises both the VisiBroker for C++ and the VisiBroker for Java ORBs. Both are implementations of the CORBA 3.0 specification. This section describes VisiBroker features and components.
What is CORBA?
The Common Object Request Broker Architecture (CORBA) allows distributed applications to interoperate (application-to-application communication), regardless of what language they are written in or where these applications reside.
The CORBA specification was adopted by the Object Management Group to address the complexity and high cost of developing distributed object applications. CORBA uses an object-oriented approach for creating software components that can be reused and shared between applications. Each object encapsulates the details of its inner workings by presenting a well-defined interface. Use of these interfaces, themselves written in the standardized Interface Definition Language (IDL) reduces application complexity. The cost of developing applications is reduced, because once an object is implemented and tested, it can be used over and over again.
The role of the Object Request Broker (ORB) is to track and maintain these interfaces, facilitate communication between them, and provide services to applications making use of them. The ORB itself is not a separate process. It is a collection of libraries and network resources that integrates within end-user applications, and allows your client applications to locate and use disparate objects.
The Object Request Broker in the following figure connects a client application with the objects it wants to use. The client program does not need to know whether the object it seeks resides on the same computer or is located on a remote computer somewhere on the network. The client program only needs to know the object's name and understand how to use the object's interface. The ORB takes care of the details of locating the object, routing the request, and returning the result.
Figure 1
What is VisiBroker?
VisiBroker provides a complete CORBA 3.0 ORB runtime and supporting development environment for building, deploying, and managing distributed applications for both C++ and Java that are open, flexible, and interoperable. Objects built with VisiBroker are easily accessed by Web-based applications that communicate using the Internet Inter-ORB Protocol (IIOP) standard for communication between distributed objects through the Internet or through local intranets. VisiBroker has a built-in implementation of IIOP that ensures high-performance and interoperability.
Figure 2
VisiBroker Features
VisiBroker has several key features as described in the following sections.
VisiBroker's Smart Agent (osagent) Architecture
VisiBroker's Smart Agent (osagent) is a dynamic, distributed directory service that provides naming facilities for both client applications and object implementations. Multiple Smart Agents on a network cooperate to provide load-balancing and high availability for client access to server objects. The Smart Agent keeps track of objects that are available on a network, and locates objects for client applications at object-invocation time. VisiBroker can determine if the connection between your client application and a server object has been lost (due to an error such as a server crash or a network failure). When a failure is detected, an attempt is automatically made to connect your client to another server on a different host, if it is so configured. For details on the Smart Agent see “Using the Smart Agent” and , “Client basics.”
Enhanced Object Discovery Using the Location Service
VisiBroker provides a powerful Location Service—an extension to the CORBA specification—that enables you to access the information from multiple Smart Agents. Working with the Smart Agents on a network, the Location Service can see all the available instances of an object to which a client can bind. Using triggers, a callback mechanism, client applications can be instantly notified of changes to an object's availability. Used in combination with interceptors, the Location Service is useful for developing enhanced load balancing of client requests to server objects. See “Using the Location Service”.
Implementation and Object Activation Support
The Object Activation Daemon (OAD) is the VisiBroker implementation of the Implementation Repository. The OAD can be used to automatically start object implementations when clients need to use them. Additionally, VisiBroker provides functionality that enables you to defer object activation until a client request is received. You can defer activation for a particular object or an entire class of objects on a server.
Robust thread and connection management
VisiBroker provides native support for single- and multi-threaded thread management. With VisiBroker's thread-per-session model, threads are automatically allocated on the server (per client connection) to service multiple requests, and then are terminated when each connection ends. With the thread pooling model, threads are allocated based on the amount of request traffic to and from server objects. This means that a highly active client will be serviced by multiple threads—ensuring that the requests are quickly executed—while less active clients can share a single thread and still have their requests immediately serviced.
VisiBroker's connection management minimizes the number of client connections to the server. All client requests for objects residing on the same server are multiplexed over the same connection, even if they originate from different threads. Additionally, released client connections are recycled for subsequent reconnects to the same server, eliminating the need for clients to incur the overhead of new connections to the same server.
All thread and connection behavior is fully configurable. See , “Managing threads and connections” for details on how VisiBroker manages threads and connections.
IDL compilers
VisiBroker comes with three IDL compilers that make object development easier:
idl2java: The idl2java compiler takes IDL files as input and produces the necessary client stubs and server skeletons in Java.
idl2cpp: The idl2cpp compiler takes IDL files as input and produces the necessary client stubs and server skeletons in C++.
idl2ir: The idl2ir compiler takes an IDL file and populates an interface repository with its contents. Unlike the previous two compilers, idl2ir functions with both the C++ and Java ORBs.
See “Using IDL” and “Using Interface Repositories” for details on these compilers.
Dynamic invocation with DII and DSI
VisiBroker provides implementations of both the Dynamic Invocation Interface (DII) and the Dynamic Skeleton Interface (DSI) for dynamic invocation. The DII allows client applications to dynamically create requests for objects that were not defined at compile time. The DSI allows servers to dispatch client operation requests to objects that were not defined at compile time. See , “Using the Dynamic Invocation Interface” and , “Using the Dynamic Skeleton Interface” for more information.
Interface and implementation repositories
The Interface Repository (IR) is an online database of meta information about the VisiBroker ORB objects. Meta information stored for objects includes information about modules, interfaces, operations, attributes, and exceptions. , “Using Interface Repositories” covers how to start an instance of the Interface Repository, add information to an interface repository from an IDL file, and extract information from an interface repository.
The Object Activation Daemon is a VisiBroker interface to the Implementation Repository that is used to automatically activate the implementation when a client references the object. See , “Using the Object Activation Daemon (OAD)” for more information.
Server-side portability
VisiBroker supports the CORBA Portable Object Adapter (POA), which is a replacement for the Basic Object Adapter (BOA). The POA shares some of the same functionality as the BOA, such as activating objects, support for transient or persistent objects, and so forth. The POA also has additional functionality, such as the POA Manager and Servant Manager which create and manages instances of your objects. See “Using POAs” for more information.
Customizing the VisiBroker ORB with interceptors and object wrappers
VisiBroker's Interceptors enable developers to view under-the-cover communications between clients and servers. The VisiBroker Interceptors are Micro Focus’s proprietary interceptors. Interceptors can be used to extend the VisiBroker ORB with customized client and server code that enables load balancing, monitoring, or security to meet the specialized needs of distributed applications. See “Using Portable Interceptors” for information.
VisiBroker also includes the Portable Interceptors, based on the OMG standardized feature, that allow you to write portable code for interceptors and use it with different vendor ORBs. For more information, refer to the CORBA 3.0 specification.
VisiBroker's object wrappers allow you to define methods that are called when a client application invokes a method on a bound object or when a server application receives an operation request. See “Using object wrappers” for information.
Event Queue
The event queue is designed as a server-side only feature. A server can register the listeners to the event queue based on the event types that the server is interested in, and the server processes those events when the need arises. Refer to the section “Event Queue” for more information.
Backing stores in the Naming Service
The new interoperable Naming Service integrates with pluggable backing stores to make its state persistent. This ensures easy fault tolerance and failover functionality in the Naming Service. See “Using the VisiNaming Service” for more information.
GateKeeper
The GateKeeper allows client programs to issue operation requests to objects that reside on a web server and to receive callbacks from those objects, all the while conforming to the security restrictions imposed by web browsers. The Gatekeeper also handles communication through firewalls and can be used as an HTTP daemon. It is fully compliant with the OMG CORBA Firewall Specification. For more information see the VisiBroker GateKeeper Guide.
VisiBroker CORBA compliance
VisiBroker 8.5 is compliant with version 3.0 of the CORBA specification from the Object Management Group (OMG). All changes between the earlier version 2.6 and version 3.0 are implemented. Note that VisiBroker:
For more details, refer to the CORBA specification located at http://www.omg.org/.
VisiBroker Development Environment
VisiBroker can be used in both the development and deployment phases. The development environment includes the following components:
Programmer's tools
The following tools are used during the development phase:
CORBA services tools
The following tools are used to administer CORBA services during development:
Administration Tools
The following tools are used to administer the VisiBroker ORB during development:
Interoperability with VisiBroker
Applications created with VisiBroker for Java can communicate with object implementations developed with VisiBroker for C++. Likewise, for applications created with VisiBroker for C++, these applications can also communicate with objects implementations developed with VisiBroker for Java. For example, if you want to use Java application on VisiBroker for C++, simply use the same IDL you used to develop your Java application as input to the VisiBroker IDL compiler, supplied with VisiBroker for C++. You may then use the resulting C++ skeletons to develop the object implementation. To use the C++ application on VisiBroker for Java, repeat the process. However, you will use the VisiBroker IDL complier with VisiBroker for Java instead.
Also, object implementations written with VisiBroker for Java will work with clients written in VisiBroker for C++. In fact, a server written with VisiBroker for Java will work with any CORBA-compliant client; a client written with VisiBroker for Java will work with any CORBA-compliant server. This also applies to any VisiBroker for C++ object implementations.
Interoperability with other ORB products
CORBA-compliant software objects communicate using the Internet Inter-ORB Protocol (IIOP) and are fully interoperable, even when they are developed by different vendors who have no knowledge of each other's implementations. VisiBroker's use of IIOP allows client and server applications you develop with VisiBroker to interoperate with a variety of ORB products from other vendors.
IDL to C++ Mapping
VisiBroker conforms with the OMG IDL/C++ Language Mapping Specification. See “IDL to C++ mapping” for a summary of VisiBroker's current IDL to C++ language mapping, as implemented by the idl2cpp compiler.
For more information about the mapping specification, refer to the OMG IDL/C++ Language Mapping Specification.