|
Figure 1
|
|
Figure 2
|
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.”
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”.
All thread and connection behavior is fully configurable. See “Managing threads and connections” for details on how VisiBroker manages threads and connections.
|
•
|
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.
|
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.
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.
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.
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.
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.
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.
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.
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.