IONA Support - IONA Knowledge Base - What issues should I be aware of, when porting my code from Orbix 3.0.1 to Orbix 3.3?

Home > Support > Knowledge Base > ... > Core Concepts > Binding > Document 2746.149

[2746.149] What issues should I be aware of, when porting my code from Orbix 3.0.1 to Orbix 3.3?

« Back to Category

Created on: Aug 24, 2000 6:00 PM
Keywords:	_bind migration upgrade
Categories:	Orbix, Installation, Configuration and Tuning, Binding, Deployment and Management
Language:	English
Product Details:	Orbix C++ 3.0.1 <==> 3.3

Rating: Not Rated

Printer Friendly

Orbix 3.3 is intended to be backward-compatible to Orbix 3.0.1, so a 3.0.1 client should be relatively unaffected by the upgrade of a server to 3.3. There are a few points to watch, however, if the client is upgraded; these focus primarily on the _bind() function. Note that you can avoid such concerns by using resolve_initial_references(), the Naming Service, the Trader Service, or an application-level factory/finder interface in your application; this is a prudent option, the _bind() feature is not available in Orbix 2000.

The following is a brief description of the differences in implementation between Orbix 3.0.1 and Orbix 3.3, and of how the migration to Orbix 3.3 can be achieved by programmers.

The _bind() command:

The _bind() command has already been deprecated, but in Orbix 3.3 it is actually changed: It must be fully qualified, that is have both a complete marker/server string and a hostname supplied. An example follows, to show how you can fully qualify your _bind() commands, to make porting to Orbix 3.3 much easier:

        X_var myX = X::_bind("markerX:servernameX", "hostnameX")

In addition, no polymorphic binds will be allowed in Orbix 3.3. This means that you must take care in specifying the type of object to be used; To demonstrate, let us say that interface X above derives from interface O: In Orbix 3.0.1 the client may use a base interface type, to call bind on an object derived from that type; the interface name can, therefore, be any base interface of the target object. Therefore, where the client calls

        O_var myO = X::_bind

...and if the server has an instance of object X, this call is successful. In Orbix 3.3, if you want to access an object of type O on the server, you must use an O_var and a call to O::_bind(). The same is true for type X. All you need do for safe binding in Orbix 3.3 is follow that rule.

Consequences of the Fully Qualified (FQ) bind:

Basically, the functionality of _bind() will stay, but it must include more specific parameters and types. If this is done, the application should have little or no trouble in porting to Orbix 3.3. What is more, the Orbix 3.0.1 features of anonymous, implied-server, and locator binds are allowed by Orbix 3.3; you only need qualify the command to avoid polymorphic binds (which will not work), or if you wish for the client to run on Orbix 3.3. This is because Orbix 3.3, while different from 3.0.1, is intended to be backward-compatible: Therefore, a 3.3 server will accept calls from a 3.0.1 client, in the usual 3.0.1 format, but demands the new format if the client is built on Orbix 3.3.

A pre-Orbix3.3 client can use FQ bind, without modifying the client.

A pre-Orbix3.3 client can omit host name and server name without modifying the client, as these parameters are resolved on the client.

A pre-Orbix3.3 client can omit the marker (anonymous bind) without modifying the client, provided the environment variable Orbix.ENABLE_ANON_BIND_SUPPORT is set to TRUE on the server (note that setting it to FALSE improves Orbix 3.3 speed). This is the most common of the esoteric bind modes, so backward compatibility should ease migration while allowing users to eventually take advantage of the Orbix 3.3 performance improvements related to FQ bind.

A pre-Orbix3.3 client cannot use polymorphic bind. The Orbix 3.3 server will return a CORBA::INV_OBJREF SystemException. This case will require the client to be modified.

The CORBA::LocatorClass and the utilities which edited the serverhosts and servergroup files have been removed from the Orbix Locator, as their functionality is marginal when a fully qualified bind is used.

Non-native C++ Exceptions:

Only native C++ exceptions are supported. This means that exceptions are not raised via the CORBA::Environment variable argument, and hence the TRY/CATCH macros are no longer supported. Note that the COBRA::Environment variable is still used, as it is the mechanism to pass a per-call timeout value, if such functionality is needed. Programmers should search the client and server source code for TRY/CATCH macros and convert these to use C++ try/catch.

As the macros have been removed, so have the following functions: If you are using them in your client or server, they will (effectively) always return true, when used with Orbix 3.3:

        CORBA::Boolean CORBA::ORB::nativeExceptions()
        CORBA::Boolean CORBA::ORB::nativeExceptions(Boolean)

Other functions removed in Orbix 3.3:

The old-style TIE and DEF_TIE macros have been removed, leaving just the later version. This should not apply to any code written for Orbix 3.0.1, but should it do so, programmers can replace any macro of form DEF_TIE(Account, Account_i) or TIE(Account, Account_i) with that of form DEF_TIE_Account(Account_i) or TIE_Account(Account_i) respectively.

The other functions removed, due primarily to the fact that they are no longer useful, are:

        CORBA::NatExcResetter
        void CORBA::Environment::propagate()
        void CORBA::Environment::acknowledge()
        CORBA::Boolean COBRA::Environment::uncaught()
        void Request::mk_arg(CORBA::TypeCode_ptr, void*)

Some undocumented APIs have also been removed from CORBA::Object, as they are no longer meaningful. All the usual APIs for CORBA::Object, as described in the Orbix 3.0.1 documentation, still exist.

A new Threading Model:

The internal threading model is being adjusted in Orbix 3.3; the only significant point in this respect is that the mt.h and thread.cxx source files are no longer shipped with product. This will not, however, affect most applications.

Functions split in Orbix 3.3:

The defaultTxTimeout function has been clearly split into an accessor and a modifier; this should not affect most client code.

Also, the CORBA::Environment public data members have been made private, and accessor/modifier method pairs provided, as follows:

CORBA::Request* CORBA::Environment::m_request is now

        CORBA::Request* CORBA::Environment::request();
        void CORBA::Environment::request(COBRA::Request*);

CORBA::ULong CORBA::Environment::m_timeout is now

        CORBA::ULong CORBA::Environment::timeout() const;
        void COBRA::Environment::timeout(CORBA::ULong val);

Summary:

Most of the above should not affect the introduction of an Orbix 3.3 server to a set of Orbix 3.0.1 clients, with the exception of the need to eliminate polymorphic binds. If your code involves some of the above, or/and if you wish to upgrade your client, you will need to take some care in porting the code, but should still have a minimum of difficulty in completing the migration. Should you need assistance, a more detailed account of the above will be available at the time of the release of Orbix 3.3, from the Customer Services team and from Sales Representatives of IONA Technologies.