Interoperability with non-Oracle ORBs

You can interoperate with Oracle8i from a client that uses another vendor's ORB. To do so, the vendor must provide the functionality that Oracle8i uses by being part of the database: functions such as session-based connections, extended CosNaming functions, and the login protocol. To provide this functionality, your ORB vendor must work with Oracle's Product Management to provide libraries for you.

All client-side functionality has been packaged into aurora_client.jar. This JAR file has been broken into two JAR files for interoperating with your ORB vendor:

• aurora_orbindep.jar--includes ORB independent features, such as JNDI

• aurora_orbdep.jar--includes Oracle ORB dependent functionality, such as session-based communication, the login protocol, and security context

Your ORB vendor needs to provide you the aurora_orbdep.jar file. Thus, you include their aurora_orbdep.jar file and the Oracle-provided aurora_orbindep.jar file to replace aurora_client.jar.

Note: If you do not remove aurora_client.jar file from your CLASSPATH, you will be using Oracle's classes, instead of your ORB vendor's classes.

The aurora_orbdep.jar includes the following functionality:

Function	Description
login	The login protocol performs the challenge/response protocol for authenticating the client to the database. See "IIOP Security" for more information.
bootstrap	The boot service obtains key services, such as CosNaming.
extended CosNaming	The Aurora ORB extended CosNaming to automatically instantiate an object upon first lookup.
Session IIOP	Session IIOP is implemented to allow one client connect to more than a single IIOP session at the same time. See Chapter 3, "Configuring IIOP Applications" for more information.
Credentials	The security context interceptor for the credential type of authentication.

Java Client using Oracle ORB

You perform the following if you choose to use the Oracle-provided ORB on your client:

1. Put aurora_client.jar in a directory that exists in the CLASSPATH.

2. Compile and run your CORBA application.

Java Client using non-Oracle ORB

You perform the following if you choose to use another vendor's ORB on your client:

1. Put aurora_orbindep.jar in a directory that exists in the CLASSPATH.

2. Contact your ORB vendor to receive their aurora_orbdep.jar.

3. Put their aurora_orbdep.jar in a directory that exists in the CLASSPATH.

4. Compile and run your CORBA application.

   Note: If you do not remove aurora_client.jar file from your CLASSPATH, you will be using Oracle's classes, instead of your ORB vendor's classes.

C++ Client Interoperability

With C++ clients, the ORB vendor must provide the aurora_client.jar file functionality in shared libraries. The vendor will make use of Oracle-provided C++ login protocol for authentication. All clients are required to authenticate themselves to the database. One of the methods for authenticating is through the login protocol.

The login protocol is an Oracle-specific design, used for logging in to a database by providing a username and password to authenticate the client. The following example shows how to write a sample C++ CORBA client to Oracle8i. This example uses the Visigenics C++ ORB for its client-side ORB.

Example 5-7 C++ client using login protocol to authenticate

The following C++ client uses the Visigenics C++ ORB for the client-side ORB. Your implementation can be different, depending on the type of ORB you use.

#include <Login.h>
#include <oracle_orbdep.h>

// set up host, port, and SID
char *sid = NULL;
char *host = argv[1];
int port = atol(argv[2]);
if(argc == 4) sid = argv[3];

// set up username, password, and role
wchar_t *username = new wchar_t[6];
username[0] = 's';  
username[1] = 'c';  
username[2] = 'o';  
username[3] = 't';  
username[4] = 't';  
username[5] = '\0';  

wchar_t *password = new wchar_t[6];
password[0] = 't';  
password[1] = 'i';  
password[2] = 'g';  
password[3] = 'e';  
password[4] = 'r';  
password[5] = '\0'; 

wchar_t *role = new wchar_t[1];
role[0] = '\0';

// Get the Name service Object reference 
AuroraServices::PublishingContext_ptr rootCtx = NULL;

// Contact Visibroker's boot service for initializing
rootCtx = VisiCppBootstrap::getNameService (host, port, sid);
  
// Get the pre-published login object reference
AuroraServices::PublishedObject_ptr loginPubObj = NULL;    
AuroraServices::LoginServer_ptr serv = NULL;
CosNaming::NameComponent *nameComponent = new CosNaming::NameComponent[2];

nameComponent[0].id = (const char *)"etc";
nameComponent[0].kind = (const char *)"";
nameComponent[1].id = (const char *)"login";
nameComponent[1].kind = (const char *)"";

CosNaming::Name *name1 = new CosNaming::Name(2, 2, nameComponent, 0);

// Lookup this object in the Name service
CORBA::Object_ptr loginCorbaObj = rootCtx->resolve (*name1);

// Make sure it is a published object
loginPubObj = AuroraServices::PublishedObject::_narrow (loginCorbaObj);

// create and activate this object (non-standard call)
loginCorbaObj = loginPubObj->activate_no_helper ();
serv = AuroraServices::LoginServer::_narrow (loginCorbaObj);
      
// Create a client login proxy object and authenticate to the DB
oracle_orbdep *_visi = new oracle_orbdep(serv);
Login login(_visi);
boolean res = login.authenticate(username, password, role);

IIOP Transport Protocol

If, when using another vendor's ORB, the ORB vendor does not support session-based IIOP, you can use a regular IIOP port. Any client that uses a regular IIOP transport can not access multiple sessions.

To configure a non-session-based IIOP listener, you must do the following:

1. Configure the MTS_DISPATCHERS parameter to oracle.aurora.server.GiopServer instead of oracle.aurora.server.SGiopServer.

   mts_dispatchers="(protocol=tcp | tcps) 
   
   	(presentation=oracle.aurora.server.GiopServer)"
   
   

2. Set the TRANSPORT_TYPE property to ServiceCtx.IIOP, as shown below:

   Hashtable env = new Hashtable();
   
   env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
   
   env.put(Context.SECURITY_PRINCIPAL, user);
   
   env.put(Context.SECURITY_CREDENTIALS, password);
   
   env.put(Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
   
   env.put("TRANSPORT_TYPE", ServiceCtx.IIOP);
   
   Context ic = new InitialContext(env);
   
   

   Note: Instead of setting the TRANSPORT_TYPE property, you can use the -iiop option on any of the command-line tools. If your client is directing the request to a dispatcher, you must also provide the regular IIOP port within the service name on the command-line.

---