![[Previous]](../pics/prev.gif){kind=small}
![[Contents]](../pics/toc.gif){kind=small}
![[Next]](../pics/next.gif){kind=small}
![[IONA Technologies]](../pics/iona.gif){kind=small}
_CORBA.Orbix object (defined in package IE.Iona.Orbix2). By default, _CORBA.Orbix is an object of type BOA (defined in package IE.Iona.Orbix2.CORBA) which is necessary for the implementation of servers. As described in Chapter 3, "OrbixWeb Configuration" of the OrbixWeb Reference Guide, client programmers may chose to configure _CORBA.Orbix as an object of type ORB from which BOA inherits. An exhaustive listing of the API to both class
ORB and class BOA is available in Part II, "Class and Interface Reference" of the OrbixWeb Reference Guide. The purpose of this chapter is to familiarise the reader with some of the elements of OrbixWeb made configurable by this API.
16.1 Obtaining Initial References
Some services and, in particular, the Interface Repository and the CORBAservices,1 can only be used by first obtaining an object reference to an object through which the service can be used. The Naming Service provides a general purpose facility for doing this, but of course some way then needs to be defined to obtain a reference to an initial naming context within which a name can be resolved.
module CORBA {
interface ORB {
// Relevant definitions.
typedef string ObjectId;
typedef sequence <ObjectId> ObjectIdList;
exception InvalidName {};
ObjectIdList list_initial_services();
Object resolve_initial_references
(in ObjectId identifier)
raises (InvalidName);
};
};
OrbixWeb implements the operation resolve_initial_references(). The method which implements this operation is defined as follows:
// Java // in package IE.Iona.Orbix2.CORBA, // in class ORB. public _ObjectRef resolve_initial_references (String serviceName) throws SystemException;Only a small group of names are understood by
resolve_initial_references(). In fact, only the string "NameService" is currently supported. The operation resolve_initial_references() returns an Interoperable Object Reference (IOR), which must be converted to the correct object type.
The daemon process awaits client requests using two well-known TCP/IP ports: one port is assigned to communications with clients using the Orbix protocol, the other to clients using IIOP. Before a client can contact a given OrbixWeb daemon, the client must be aware of the port value for that process for the required protocol.
By default, the daemon's Orbix protocol port is set to 1570, while its IIOP port is set to 1571. A client can update its settings for these values using one of the following methods:
_CORBA.IT_ORBIXD_PORT and _CORBA.IT_ORBIXD_IIOP_PORT in a non-default class Configure, as described in Chapter 3, "OrbixWeb Configuration" of the OrbixWeb Reference Guide.
orbixweb.orbixd_port and orbixweb.orbixd_iiop_port properties as follows:
java -Dorbixweb.orbixd_port=<Orbix port>
-Dorbixweb.orbixd_iiop_port=<IIOP port> <Client class>
ORB.setHostPort() with a new port number as parameter. The method ORB.getHostPort() can be invoked to retrieve a client's current Orbix protocol port setting.
BOA provides several event processing methods in addition to impl_is_ready(). These methods give a programmer more control over handling of server events such as operation requests, and connections and disconnections from clients.The relevant methods are
processNextEvent(), processEvents() and obj_is_ready(). A server can also test whether or not there is an outstanding event using isEventPending().
ORB.connectionTimeOut(). Under some circumstances,
connectionTimeOut() has no effect–for example, if the server's host is known but is down or unreachable, a TCP/IP connect can block for a considerable time depending on the target operating system.
The method
ORB.maxConnectRetries() can be used to set the maximum number of retries that should be attempted. The default number is ten.
When a server exits while a client is still connected, the next invocation by the client will raise an OrbixWeb system exception of type
COMM_FAILURE. If the client attempts another invocation, OrbixWeb will automatically try to re-establish the connection. This default behaviour can be changed using the function ORB.noReconnectOnFailure(), with a parameter value true.In the non-default case, all client attempts to contact a server subsequent to closure of the communications channel will raise a
COMM_FAILURE system exception.
If a programmer anticipates that a program will connect to a much larger number of objects than the default size, the method
ORB.reSizeObjectTable() can be used to resize the table.
To address these issues, OrbixWeb supports the collocation of client and server within the same address space. If a target object is found in an application's local address space, subsequent calls on the object will be very efficient, since direct Java method calls will be used to the IDL implementation code, and the OrbixWeb runtime classes will be bypassed.
collocated() method on the _CORBA.Orbix object as follows:
// Java import IE.Iona.Orbix2._CORBA; ... boolean prev = _CORBA.Orbix.collocated (true);Note that the previous collocation setting is returned.
If collocation is set then OrbixWeb will never try to bind to an object outside of the caller's address space. If an object is not found in the caller's address space,
_bind() will raise an INV_OBJREF exception.Calls to
collocated(true) will normally be made during the initialisation of a combined client and server. However, collocation can be unset (thereby reinstating remote binding) at any time by calling collocated(false).
// Java import IE.Iona.Orbix2._CORBA; ... boolean isOn = _CORBA.Orbix.collocated ();This returns a
boolean value true if collocation is set, and returns false otherwise.
_bind() raises an exception if the object on which the _bind() is attempted does not exist in the specified server. Doing so requires OrbixWeb to ping the desired object (the ping operation is defined by OrbixWeb and it has no effect on the target object). The pinging will cause the target server process to be activated if necessary, and will confirm that this server recognises the target object. Pinging can be disabled using ORB.pingDuringBind(), passing false to the parameter pingOn.A programmer may wish to disable pinging to improve efficiency by reducing the overall number of remote invocations.
Note that if
pingDuringBind(false) is called:
_bind() to an unavailable object will not immediately raise an exception, but subsequent requests using the object reference returned from _bind() will fail by raising a system exception (of type INV_OBJREF).
_bind(), then the _bind() will not itself make any remote calls; it simply sets up a proxy with the required fields.
_bind() does not interact with that server to determine if the required object exists within it.
ORB.defaultTxTimeout(), which takes the new timeout value as a parameter and returns the old timeout value (if one exists). The value set by this method is ignored when making a connection between a client and a server. It comes into effect only when this connection has been established.
By default, no OrbixWeb operation call has a timeout.
System.out print stream. Three levels of diagnostics are provided:|
Level
|
Output
|
|---|---|
|
0
|
No diagnostics
|
|
1
|
Simple diagnostics (this is the default)
|
|
2
|
Full diagnostics
|
The level can be set by passing the appropriate level value to the method
ORB.setDiagnostics().The full diagnostic messages have the form:
[hour:minute:second.millisecond server@host event-description]where an event is generally an operation request.