Handling Exceptions

CORBA Exception Handling Concepts
1. System exceptions - which are general errors
2. User exceptions - triggered by an object

CORBA System Exceptions
example BAD_CONTEXT - An error occured while processing context objects

The Exception class provides the following public operations:

copy constructor
destructor
_narrow

Copy constructor and destructor operations automatically manage the storage associated with the exception.
The _narrow operation allows your CORBA client application to catch any type of exception and then determine its type.
The exception argument passed to the _narrow operaton is a pointer to the base class Exception. If the pointer of type SystemException, the narrow() operation returns a pointer to the exception, otherwise it returns a Null pointer.

Handling System Exceptions

try

{
//Initialize the ORB
CORBA::ORB* orb=CORBA::ORB_init(argc, argv, ORBid);

//Get a Bootstrap Object
Tobj_Bootstrap* bs= new Tobj_Bootstrap(orb, "//host:port");

//Resolve Factory Finder
CORBA::Object_var var_factory_finder_oref = bs->resolve_initial_reference("FactoryFinder");
Tobj::FactoryFinder_var var_factory_finder_ref = Tobj::FactoryFinder::_narrow(var_factory_finder_oref.in());

catch(CORBA::Exception& e)
{
cerr <<e.get_id()>< User Exceptions
The code should first check for system exceptions, and often the application cannot recover from system exception.

the sample shows how a TooManyCredits user exception would work within the scope of a transaction for registering for classes.

try
{
pointer_registrar_reference->register_for_courses(student_id, course_number_list);
catch (UniversityT::TooManyCredits& e)
{
cout <<"You cannot register for more than"<<>
}

Creating CORBA Client Applications

http://e-docs.bea.com/tuxedo/tux91/creclient/corba.htm

Steps for developing CORBA C++ client applications

1. Obtain the OMG IDL file.
2. Select the Invocation type.
3. Use the IDL compiler to compile the OMG IDL file. Generating client stubs
4. Write the CORBA C++ client application.
5. Build the CORBA C++ application

-idl command compiles the OMG IDL file and generates the client stubs required for the CORBA interface.
-The buildobjclient command constructs a CORBA C++ client application executables.

step1: Obtaining the OMG IDL file
The available interfaces and operations are provided by application designer.

step2: Selecting the Invocation Type
select static, dynamic or both.

step3: Compiling the OMG IDL File
syntax of the idl command:

idl idlfilename(s)

The IDL compiler generates a client stub(idlfilename_c.cpp) and a header file (idlfilename_c.h). You need to link these files into your CORBA client application.

step4: Writing the CORBA client Application
To get an object reference for a CORBA object and invoke operations on the object

• Intialize the BEA Tuxedo ORB.
• Establish communication with the BEA Tuxedo domain.
• Resolve initial reference to the FactoryFinder object.
• Use a factory to get an object referencefor the desired CORBA object.
• Invoke operations on the CORBA object.

a. Initializing the ORB

syntax
CORBA::ORB_var orb=CORBA::ORB_init(argc, argv, ORBid);

if CORBA client application wants to access server applications in another BEA Tuxemo domain, you need to override the default ORBid as BEA_IIOP

b. Establishing Communication with the BEA Tuxedo Domain

The CORBA client application creates a Bootstrap object.

The following code shows how to use the Bootstrap object:

Tobj_Bootstrap* bootstrap = new Tobj_Bootstrap(orb, "//host:port");

c. Resolving Initial References to the FactoryFinder Object

The client application must obtain initail references to the environmental objects that provide services for the CORBA application.
The Bootstrap object's resolve_initial_references operation can be called to obtain references environmental objects.

CORBA::Object_var var_factory_finder_oref = bootstrap.resolve_initial_references
("FactoryFinder");
Tobj::FactoryFinder_var var_factory_finder_ref = Tobj::FactoryFinder::_narrow
(factory_finder_oref.in());

d. Using the FactoryFinder Object to Get a Factory

CORBA client applications get object references to CORBA objects from factories.
To use factories, the CORBA client application must be able to locate the factory it needs. The FactoryFinder object serves this purpose.

FactoryFinder object has the following methods
-find_factories()
-find_one_factory()
-find_factories_by_id()
_find_one_factory_by_id()

syntax:
CORBA::Object_var var_registrar_factory_oref = var_factory_finder_ref->
find_one_factory_by_id(UniversityB::_tc_RegistrarFactory->id());
UniversityB::RegistrarFactory_var var_RegistrarFactory_ref = UniversityB::RegistrarFactory::_narrow(var_RegistrarFactory_oref.in() );

e. Using Factory to Get a CORBA Object

The CORBA client applications invoke operations on the CORBA object by passing a pointer to the factory and any arguments that the operation requires.

The following code invoking the get_cources_details() method on the Registrar object

UniversityB::Registrar_var var_Registrar = var_RegistrarFactory->
find_Registrar();
UniversityB::CourseDetailsList_var course_details_list = Registrar_oref->
get_course_details(CourseNumberList);

step5: Building the CORBA Client Application

Compile the code and link against the client stub.
use the buildobjclient command to construct a CORBA client application executable.

CORBA Client Application Development Concepts

http://e-docs.bea.com/tuxedo/tux91/interm/corbaprog.htm#client

BEA Tuxedo contains

1. Two programming interfaces - ATMI and CORBA C++
2. High performance C++ application server
3. A Transaction Monitor
4. Manageable back-end transaction platform.

The BEA Tuxedo software supports the following types of client applications:

CORBA C++

OMG IDL - Object Management Group (OMG) Interface Definition Language (IDL) - describe available CORBA interfaces to client applications. It is a purely declarative language. ie contains no implementation details.
Operations specified in OMG IDL can be written in and invoked from any language that provides CORBA bindings. C++ and Java are two of the supported languages.

OMG IDL-to-C++ Mapping
See The Common Object Request Broker:Architecture and Specification, Version 2.3.

Static and Dynamic Invocation
The CORBA server application cannot tell the difference between static and dynamic invocations.

static - Easiest and most common type of invocation. CORBA client application invokes operations directly on the client stubs. Static invocation is recommended for applications that know at compile time the particulars of the operations they need to invoke and can process within the synchronous nature of the invocation.

Dynamic - Enables CORBA client application to invoke operations on any CORBA object without having to know the CORBA object's interface at compile time.

Client Stubs
Client stubs providing the programming interface. The client application simply treats the stub as a local object. A CORBA client application must have a stub for each interface it plans to use.
idl command generate a client stub from the OMG IDL definition of the CORBA interface.

To create a stub file and header file from a programming language, invoke a method from within your CORBA client application to request an operation on the CORBA obejct.

Interface Repository
Contains descriptions of a CORBA object's interfaces and operations.

Static invocation do not access the Interface Repository at run time. It is included in client stub.
Dynamic invocation use the Interface Repository to learn about a CORBA object's interfaces, and invoke operations on the object.

idl2ir, ir2idl, irdel commands are used to manage the Interface Repository

Domains
grouping objects and services together as a management entity. One CORBA client applications can connect to multiple BEA Tuxedo domains using different Bootstrap objects.

Environmental Objects
It set up communication between CORBA client and server applications in a BEA Tuxedo domain.
The following are the environmental objects

1. Bootstrap
2. FactoryFinder
3. InterfaceRepository
4. SecurityCurrent
5. TransactionCurrent
6. NotificationService
7. NameService

Bootstrap - establishes communication. It also obtains object references for other environmental objects.
FactoryFinder - locates a factory, can create object references for CORBA objects.
InterfaceRepository - contains interface definitions for all the available CORBA interfaces
SecurityCurrent - used to log a CORBA client application into a BEA Tuxedo domain with the proper security credentials.
TransactionCurrent - allows a CORBA client application to participate in a transaction.
NotificationService - allows a CORBA client application to obtain a reference to theevent channel factory in the CosNotification Service.
NameService - use a namespace to resolve object references.

Bootstrap Object

Which defines the address of an IIOP Listener/Handler. The IIOP Listener/Handler is the access point to a BEA Tuxedo domain and the CORBA services provided by the domain. A list of IIOP Listener/Handlers can be supplied either as a parameter or via the TOBADDR environmental variable or a Java property. A single IIOP Listener/Handler is specified as follows

// host:port eg myserver:4000

Once the Bootstrap object is initiated, the resolve_initial_references method is invoked, passing in a string ID, to obtain a reference to an available object. The valid values for the string ID are FactoryFinder, Interface Repository, SecurityCurrent, TransactionCurrent, NotificationService, TObj_SimpleEventsService, and NameService.

Factories and the FactoryFinder Object

A factory is any CORBA object that returns an object reference to another CORBA object and registers itself with the FactoryFinder object.
The factories available to CORBA client applications are those that are registered with the FactoryFinder object by CORBA server applications at startup.

The CORBA client applications uses the following sequece of steps to obtain a reference to a CORBA object;

1. Once the Bootstrap object is created, the resolve_initial_references method is invoked to obtain the reference to the FactoryFinder object.
2. CORBA client applications query the FactoryFinder object for object references to the desired factory.
3. CORBA client applications then call the factory to obtain an object reference to the CORBA object.

Naming Conventions and BEA Tuxedo Extensions to the FactoryFinder Object
-------------------------------------------------------------------------------

InterfaceRepository Object

It offers proper set of interfaces as defined by the CORBA specification ver 2.2.
CORBA client applications that use the Dynamic Invocation Interface(DII) need to access the Interface Repository programmatically.

Security Current Object

CORBA client applications use the securityCurrent object to log on to the BEA Tuxedo domain and pass security credentials to the domain.
The following levels of authentication are provided:

TOBJ_NOAUTH - No authentication is needed. client application may still specify a username and a client appication name , but no password.
TOBJ_SYSAUTH - The CORBA client application must authenticate itself to the BEA Tuxedo domain and must specify a username, client application name, nad application password.

TransactionCurrent Object

Maintains a transactional context for the current session between the CORBA client application and the CORBA server application.
ex. initiating and terminating a transaction and getting the status of a transaction.
The transaction policies are
1. Never
The interface is not transactional. Objects created for this interface can never be involved in a transaction.
2. Optional
The interface may be transactional.
3. Always
The interface must always be part of a transaction.
4. Ignore
The interface is not transactional.

NotificationService and Tobj_SimpleEventsService Objects

Provide access to CORBA event service. The event service receives event posting messages, filters them, and distriutes them to subscribers.
A poster is a CORBA application that detects when an event of interest has occured and reports(posts) it to the event service.
A subscriber is a CORBA application that requests some notification action to be taken when an event of interest is posted.

NameService Object

CORBA client applications can locate an object by asking the CORBA Name Service to look up the name.