IOM CORBA Support

This section documents the IOM CORBA support for Release 8.2 of SAS Integration Technologies. This feature allows you to use a CORBA ORB on your server platform and communicate with client ORBs using the Internet Inter-ORB Protocol (IIOP). IIOP is the communications protocol that is used between CORBA-compliant ORBs. Software components that use CORBA-compliant ORBs are interoperable. This means that you can develop your client application for any platform (using any supported language for that platform) and use any commercially available CORBA-compliant ORB for that platform to access the services on an IOM server.

Software Requirements

The IOM CORBA support has the following software requirements for your server platform:

• NT Version 4.0 or higher
• IONA Orbix2000 for C++

Release 8.2 of SAS Integration Technologies introduces CORBA support for IONA Technologies Orbix2000 for C++. We anticipate that future releases will include support for additional server platforms.

The client machines also need a fully compliant CORBA 2.0 ORB. SAS has successfully used the following ORBs:

• IONA Orbix2000

• The ORB in JDK 1.2

  Note: See restrictions below on using SAS DateTime values.

Configuring the IONA Implementation Repository

IOM CORBA support is provided with SAS Integration Technologies software as two executables. When you install the SAS system for the Windows NT platform and include Integration Technologies, the executables are installed as $sasroot/inttech/sasexe/orbitsrv.exe and $sasroot/inttech/sasexe/sasorbit.exe. When launched as part of IONA's ITADMIN implementation repository tool, the orbitsrv executable handles all of the details of starting an IOM server that uses the Orbix2000 ORB.

To use the SAS IOM CORBA server within an IONA implementation repository, the server administrator must configure the repository with the following IONA ITADMIN commands:

process create -activator server_node/it_activator
               -startupmode on_demand -dir "$sasroot"
               -pathname "$sasroot\\inttech\\sasexe\\orbitsrv.exe" sasspawn

orbname create -process sasspawn sas.spawner.auto

poa create -orbname sas.spawner.auto sas_spawner_autopoa

Notes:

• server_node is the node where the IONA activator is found. $sasroot is the base directory of the SAS installation. Note: The quotes are required as shown.

• The Portable Object Activator (POA) must be named "sas_spawner_autopoa". The other variable names can be modified as long as they remain constant throughout configuration.

• These commands can be placed in a "TCL" script for repeated use, but to avoid redefinition, place the following command at the beginning of the script:

  process remove -deep sasspawn
  

• ITADMIN supports an -args parameter to the process create command. Although it is not necessary to use arguments, you can use this option to pass properly formatted SAS system options to the server. The following examples passes a SAS configuration file:

  -args "--config C:/temp2/sasv8new.cfg"
  

  Please see the IONA Administrator's Guide and the ITADMIN help for more information on the proper syntax for using the -args parameter.

• You can also use the -args parameter to pass additional options to the IOM server. The following example illustrates this use:

  -args "--public -IORfile C:\\temp2\\sasauto.ior"
  

  where:
  • The public option specifies that the CreateObject method may be used instead of the CreateObjectWithUserID method to acquire a workspace. The server normally requires clients to be authenticated via the CreateObjectWithUserID method, but the -public option bypasses client authentication.

  • The IORfile option specifies the path and filename of the file where the server will write the IOR. By default, this file is written to $sasroot/SASAuto.ior. You will need to provide this filename (or its contents) to clients so that they can access the server.

For more information on ITADMIN, see the IONA Orbix2000 Administrator's Guide.

Accessing the Server From the Client

In the COM, the IOM Bridge for COM, or the IOM Bridge for Java environments, there are factory methods available to create a workspace on the IOM server using a logical name for the server. To access an IOM server using IIOP, you use an Interoperable Object Reference (IOR) to obtain an IIOMFactory object on the IOM server. (The IOR is a standard way of encapsulating IP name, port, and class ID to identify the object server that you want to communicate with.) The IIOMFactory object is then used to create workspaces.

Below is a C++ example of creating a workspace object on an IOM CORBA server. The program first reads the IOR from the file (IOR_file_name) where the server wrote it during startup. Note that this is a stringified IOR and must be converted to an object before it can be used to get the workspace.

  CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
  char IORstring[1024];

  char IOR_file_name[512];

  /* The variable IOR_file_name must be initialized
     to the path and filename that was specified with
     the -IORgen switch when the server was started */

  FILE *fp = fopen(IOR_file_name, "r");
  fgets(IORstring, 1024, fp);
  fclose(fp);

  CORBA::Object* str_object = orb->string_to_object(IORstring);
  SASIOMDefs::IIOMFactory_var IOMFactory = SASIOMDefs::IIOMFactory::_narrow(str_object);
  SAS::IWorkspace_var IWorkspace = IOMFactory->CreateObjectWithUserID("domain\\username", "password");

As discussed above, the CreateObject method can be used if the -public option is set. However, authentication and access rights assignment are bypassed.

You need to generate the appropriate stubs and headers using your own IDL compiler. The CORBA IOM IDL files are installed as part of the base SAS system and can be found in the following zip file:

$sasroot/core/sasmisc/iomjava.zip

This zip file contains the following IDL files:

• sasevorb.idl (events)
• SASIOMDefs.idl (factory and types)
• sasorb.idl (components)

From this point, once you have the workspace interface, your application accesses the IOM server the same way regardless of whether you're using the IIOP or the IOM Bridge protocol.

Restrictions

The IOM CORBA support in Release 8.2 has the following restrictions:

• Currently, there is no documented data access interface to an IOM server. If you are developing your application using Java, then you can use the Java Database Connectivity (JDBC) standard. If you are not using Java, then the IOM server will need to provide the results back to the client using some other mechanism. The XML engine within the LIBNAME statement is the best option for most applications.

• The SAS IOM server uses a 64 bit (longlong) value for DateTime. A client cannot use methods involving DateTime unless their ORB supports CORBA IDL "unsigned long long" (64-bit integer) properly.