----------------------------------------------------
Running CorbaScript on top of Orbix 2000 release 1.0
----------------------------------------------------

If your Orbix 2000 product is not installed into default directories,
don't forget to set the IT_PRODUCT_DIR, IT_CONFIG_DIR, IT_CONFIG_DOMAINS_DIR,
IT_LICENSE_FILE, IT_IDL_CONFIG_FILE environment variables before using
CorbaScript. From an Unix C-shell, set them as following:

	setenv Orbix2000Path /export/corba/Orbix2000

	setenv IT_PRODUCT_DIR ${Orbix2000Path}/SunOS
	setenv IT_CONFIG_DIR ${Orbix2000Path}
	setenv IT_CONFIG_DOMAINS_DIR ${Orbix2000Path}
	setenv IT_LICENSE_FILE ${Orbix2000Path}/licenses.txt
	setenv IT_IDL_CONFIG_FILE ${Orbix2000Path}/SunOS/orbix_art/1.0/etc/idl.cfg

------------------------------------------
CorbaScript and Orbix 3.x compatibilities.
------------------------------------------

Currently, CorbaScript can not be directly compiled on top of
the Orbix 3.x/C++ product (and also not on top of OrbixWeb because
it is a Java ORB and CorbaScript is written in C++ ;).

Orbix 3.x will be supported natively when IONA will want to provide
a product that fully and correctly implements dynamic CORBA mechanisms
(DII, DSI, DynAny, Any, TypeCode, IFR).

Anyway, you could compile CorbaScript with the great Orbix 2000 product!

However CorbaScript can access to CORBA objects implemented on top of Orbix
through IIOP. But the Orbix implementation of IIOP could be different and
incompatible with other IIOP implementations :-( I don't know all possible
problems (see news groups).

Then, the following is a scenario to use CorbaScript on your Orbix objects:

- compile ORBacus/C++ (or other ORBs).
- compile CorbaScript for ORBacus.
- use CorbaScript commands (scripts envi.ORB.*) to start the Interface
  Repository and Name Service of ORBacus (command cssh_install).
- load the IDL files of your Orbix objects into the Interface Repository
  (command ir_load).

Way 1: Binding to an object by an IOR.

- obtain the IOR of one of your Orbix objects.
- start CorbaScript and enter the following instructions
  >>> o = CORBA.Object("IOR:here.is.the.IOR.of.an.Orbix.object")
  >>> o
  TheIDLInterface("IOR:....")
  >>> o._type
  ...
  >>> o.an_operation(the_parameters)

Way 2: Binding to an object by the Name Service.

- load the CosNaming.idl into the started Interface Repository.
- obtain the IOR of the root NamingContext of your Orbix Name Service.
- start CorbaScript and type
  >>> ns = CORBA.Object("IOR:here.is.the.IOR.of.the.Orbix.root.NamingContext")
  >>> o = ns.resolve ( [ [ "an_id", "a_kind" ] ] )
  >>> o

Way 3: The last solution but not the least;)

- load the CosNaming.idl into the started Interface Repository.
- obtain the IOR of the root NamingContext of your Orbix Name Service.
- store this IOR into the $CS_CONFIG_HOMEDIR/NameService.IOR file.
- start CorbaScript and type
  >>> ns = CORBA.ORB.resolve_initial_references("NameService")
  >>> o = ns.resolve ( [ [ "an_id", "a_kind" ] ] )
  >>> o

In this last scenario, you could store the IOR into the 'OrbixNameService.IOR'
file and add into the 'InitialServices' file a line with 'OrbixNameService'.
So now you have access to the two Name Services.

  >>> ns_of_ORBacus = CORBA.ORB.resolve_initial_references("NameService")
  >>> ns_of_Orbix = CORBA.ORB.resolve_initial_references("OrbixNameService")

The problems in these scenarios could be:
* IIOP incompatibilities between Orbix and ORBacus.
* Orbix coding of IORs.

Please report us any success or problem with these scenarios.
