Lesson 4	The CORBA client
Objective	Learn more about CORBA Clients

CORBA Client(Stubs, Services)

In the previous lesson, we took a good look at how Stubs provide much of the functionality associated with CORBA to clients.
The following series of images below will expand on that knowledge as we learn more about CORBA clients.

Corba Consumer

1) At the basic level, a CORBA Client simply wishes to obtain services from a Corba server.

2) The CORBA Stub does most of the work, so the client may remain simple.

3) We have already started to explore the CORBA development proces, this illustrates the rest of the process for clients.

Corba Fundamentals

4) The CORBA architect creates an IDL file, the Stub is produced when the IDL is run through an ORB vendors IDL pre-processor, and the CORBA client uses the Stub to write and compile the client. The files that must be written by developers are highlighted in yellow.

Simple Producer/Consumer Example

Assume we have a simple queue class:

template<class T> class Queue {
public:
void enqueue(const T & item);
T dequeue();
};

Producer threads read items from somewhere and place them on the queue by calling enqueue.
Consumer threads fetch items from the queue by calling dequeue.
The queue is a critical region and the consumer threads must be suspended when the queue is empty.

#include <list >
template<class T> class Queue {
public:
void enqueue(const T & item) {
m_q.push_back(item);
}
T dequeue() {
T item = m_q.front();
m_q.pop_front();
return item;
}
private:
list<T> m_q;
};

#include <list >
#include <JTC/JTC.h >
template<class T> class Queue : JTCMonitor {
 public:
  void enqueue(const T & item) {
   JTCSynchronized lock(*this);
   m_q.push_back(item);
   notify();
  }
  T dequeue() {
   JTCSynchronized lock(*this);
   while (m_q.size() == 0) {
    try {
     wait();
    } catch (const JTCInterruptedException & ) {
   }
  }
  T item = m_q.front();
  m_q.pop_front();
  return item;
 }
 private:
 list<T> m_q;
};

CORBA Specified Dynamic Invocation Interface (DII)

There may be times when the client developer does not have access to the Stub when the client is created or, in a broader view, a client may not want to make CORBA requests of a server that does not exist when the client is written. These problems are solved by the CORBA Specified Dynamic Invocation Interface (DII). The DII allows a client to learn at runtime about the operations supported by a server, and to create requests, without a Stub, that are sent directly to the ORB. From there, the requests are forwarded to the server.

The client queries the CORBA-specified <em>Interface Repository</em> to retrieve data about the interface and its operations. — Figure 3.4.1: The client queries the CORBA-specified *Interface Repository* to retrieve data about the interface and its operations.

Figure 3.4.2: Communication between the Dynamic Invocation Interface and the Client The client then builds a raw request, submits the request directly to the ORB via the DII (which takes the place of the Stub), and the request is handled as normal by the ORB.

Figure 3.4.3: Client communicates with server by means of 1) Stub and 2) Dynamic Invocation Interface.

CORBA clients may communicate with servers using Stubs or DII, or a combination of the two.
Now that we understand the fundamentals of how a CORBA client is constructed and used, we will next focus on the server side of CORBA.