Lesson 5	The CORBA server
Objective	Learn more about how CORBA servers are constructed and used.

CORBA Server Construction

At the most basic level, a CORBA server provides services to CORBA clients, often many simultaneously. The CORBA server development process is similar to CORBA client development.

As a result of running the interface definition through an IDL precompiler, Skeleton and other support files are produced. The server or Implementation developer then writes the interface implementation code. The server-side Skeleton plays a role that is similar to a client-side Stub.

Skeleton accepts CORBA Requests
The Skeleton accepts CORBA requests, performs any tasks related to data marshalling, and forwards the request to the associated CORBA server. The Skeleton performs in reverse order to handle any CORBA replies from the server. You may have noticed in the above image an Object Adapter. The Object Adapter (which most vendors have implemented as the Basic Object Adapter, or BOA) is an ambassador between the ORB and the server. The CORBA specification has also added a section describing a new Portable Object Adapter (POA).

Portable Object Adapter

The OMG, after realizing that this diverging of the BOA was becoming a problem, requested proposals for either enhancing the BOA or devising a new type of Object Adapter that would correct the problems encountered using the BOA. The result of that request is the new Portable Object Adapter (POA), which has been adopted as the Object Adapter in the CORBA specification. The POA actually deprecates the BOA and is intended to completely replace the BOA in time, but vendors are free to maintain support for the BOA, so that existing applications remain functional. The POA adds quite a bit of control and portability over and above the BOA, but because the BOA was generally easy to use programmatically, the POA may also be used in very simple ways. This avoids making the POA uselessly complex for applications that only require simple Object Adapter services.
The enhancements added by the POA include:

A more object-centric set of activation policies, which allow finer grained control of how CORBA objects may be activated to satisfy client requests
Explicit control over the threading policy to be used. When using the BOA, CORBA vendors were free to make whatever threading configuration they wished available. This is specified more strictly for the POA
Objects registered with a POA may be given default lifespan attributes as a group
A high degree of control over how CORBA requests are routed to objects, allowing sophisticated default and optimized routing models
The introduction of a root Object Adapter concept, RootPOA, that provides an interface for creation of nested POAs.

Many of the vendors have begun to include POA support into product releases and full POA support should be available in the near future. The resultant CORBA server code will enjoy much greater control over how it interacts with the Object Adapter and the ORB, as well as a higher level of interoperability.

There are different types of CORBA object adapters.
The Portable Object Adapter, or POA, is a particular type of object adapter that is defined by the CORBA specification
An object adapter that is a POA allows an object implementation to function with different ORBs.

Object Adapter

The Object Adapter helps CORBA servers by:

Assisting servers as they register their services to the ORB
Generating a unique ID called CORBA Object Reference for the server
Enabling client requests to correctly find their way to the server
Activating or deactivating the server, as required

At this point, you should have a good foundation of understanding regarding CORBA clients and CORBA servers. In the following lesson, we will take a different point of view on these topics and look at things as they relate to the ORB.
The following section discusses the CORBA server development process.

Corba Server Development Process

Here is the proper order for the CORBA development process:
The following order for the CORBA development process is generally correct.
Here's a breakdown of the typical steps involved:

Write the IDL that Describes the Interfaces
- Interface Definition Language (IDL) is used to describe the interfaces that CORBA objects will expose. This is the first step, as the IDL defines the contract between the client and the server.
Run the IDL Pre-Processor
- After writing the IDL, it must be compiled using an IDL compiler (also called an IDL pre-processor) to generate the necessary stubs and skeletons for the client and server. These are the code artifacts that both sides will use to communicate.
Develop the CORBA Server and the CORBA Client
- Once the stubs and skeletons are generated from the IDL, you can start developing the server and client.
- Server: Implements the interface defined in the IDL.
- Client: Uses the interface defined in the IDL to communicate with the server.
Compile and Run the CORBA Server
- After the server has been developed, compile the server code along with the skeletons generated by the IDL pre-processor. The server must be up and running to handle requests from clients.
Compile and Run the CORBA Client
- After the client is developed, compile the client code with the stubs generated by the IDL pre-processor. Once the client is compiled, it can be executed to interact with the server.

Summary of the Correct Process:

Write the IDL that describes the interfaces
Run the IDL pre-processor
Develop the CORBA server and the CORBA client
Compile and run the CORBA server
Compile and run the CORBA client

This sequence represents the typical steps for developing CORBA applications. Let me know if you'd like more details on any of the steps!

Interface Definition Language (IDL) If the concept of the Object Request Broker is one cornerstone of the CORBA architecture, the Interface Definition Language (IDL) is the other. IDL, as its name suggests, is the language used to define interfaces between application components. Note that IDL is not a procedural language; it can define only interfaces, not implementations. C++ programmers can think of IDL definitions as analogous to header files for classes; a header file typically does not contain any implementation of a class but rather describes that class's interface. Java programmers might liken IDL definitions to definitions of Java interfaces; again, only the interface is described and no implementation is provided. The Interface Definition Language (IDL) is a standard language used to define the interfaces used by CORBA objects.
The IDL specification is responsible for ensuring that data is properly exchanged between dissimilar languages. For example, the IDL long type is a 32-bit signed integer quantity, which can map to a C++ long (depending on the platform) or to a Java int. It is the responsibility of the IDL specification and the IDL compilers that implement it, and to define such data types in a language-independent way.