Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

CORBA Application Wizard - An Introduction

0.00/5 (No votes)
19 Sep 2004 1  
An Application Wizard making it easier to start using CORBA in your Console and Windows Applications

Introduction

The CORBA Application Wizard is meant for programmers that are, like me, CORBA beginners. The AppWizard is meant to aid in the study of CORBA by getting rid of the tedious job of always having to enter the same boilerplate code over and over again e.g. the initialization of the CORBA orb. Instead one can concentrate on the finer details of CORBA. This article mainly deals with the requirements needed to use this application wizard. At the end of the article are some implementation methods that might be interesting for beginners that want to write their own application wizards.

Background

This Application Wizard has grown out of a sudden interest in CORBA (Common Object Request Broker Architecture) that started about a two years ago. After posting a request for the possibility of having CORBA articles placed in CodeProject and with a reply that I should write some articles to get started, I decided to do just that.

I started reading the book Advanced CORBA Programming with C++ by Michi Henning and Steve Vinoski, where most of the code used to set up the ORB appeared to be boilerplate. So instead of always typing in the same code over and over again this AppWizard was created to do the dirty work for me.

WARNING

This is a work ( of art ;-) ) in progress !!!

Not all options available in this Application Wizard will function properly. The options available will change as the Wizard is thoroughly tested and as requests for new features are received. I also plan to add new features to the Application Wizard as I become more familiar and experienced with using CORBA.

Using CORBA in an MFC or Win32 Application has not yet been tested so results are as yet unknown. I have not yet seen any examples of a MFC or Win32 Application making use of CORBA but in my opinion the CDocument-derived class in a MFC Application can probably contain the CORBA boilerplate code.

You might ask why I have posted this article if the AppWizard isn't yet complete. Well I started on the Application Wizard a year ago and at least this way I am forced to work on it and complete it.

Requirements and Setting Up

To be able to use this Application Wizard one needs to have both ACE (ADAPTIVE Communication Environment) and TAO (The Ace Orb) installed and built on your computer. The source code for ACE and TAO can be downloaded from www.cs.wustl.edu/~schmidt/ACE and www.cs.wustl.edu/~schmidt/TAO respectively.

Set the ACE_ROOT and TAO_ROOT environment variables by adding the following lines to your Autoexec.bat file:

  1. SET PATH=%PATH%;E:\ACE_Wrappers\bin
  2. SET ACE_ROOT=E:\ACE_Wrappers
  3. SET TAO_ROOT=E:\ACE_Wrappers\Tao\Tao

Complete installation instructions can be found in the documentation provided with the source code for ACE and TAO.

After selecting Options from the Tools menu, the Options dialog appears. Click on the Directories tab and show the directories for the include files. Add the directories, as the image below shows, encircled in red:

Then show the directories for the executable files and add the directory highlighted below.

where E:\ is the drive where the source code for ACE and TAO has been saved and ACE and TAO have been built.

Installation

To install the CORBA Application Wizard just download the zip file containing the DLL and then copy the files after decompression into the directory where all the other Wizards are located, i.e.

C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Template

Getting Started

After selecting the Projects tab of the New dialog, click on CORBA AppWizard and type in a suitable project name.

Then click on the OK button. The first step of the Application Wizard will appear. For a more detailed explanation of how to use the CORBA Application Wizard see the tutorial Using the CORBA Application Wizard.

Points of Interest

Below are some items that might be of interest to those that are new to creating Application Wizards.

Option interdependency

Some of the steps have options that are only enabled when certain options are selected in previous steps. For example if the user selects to create an application acting as a server in step 2, then the Dynamic Skeleton Interface option is enabled and the Dynamic Invocation Interface option is disabled in step 6. If the user selects to create an application acting as a client in step 2, then the Dynamic Invocation Interface option is enabled and the Dynamic Skeleton Interface option is disabled in step 6.

All the various options available in each step are initialised in the OnInitDialog function of the corresponding dialog. This is fine if the user doesn't suddenly change his mind and go back a few steps to select a different option. If the user selected the server option in step 2 and has reached step 6 then as stated above the Dynamic Skeleton Interface option is enabled. However if he decides to go back to step 2 and selects the client option then on reaching step 6, the Dynamic Skeleton Interface option will still be enabled. This is because the OnInitDialog function is only called once and that is when the dialog is created. The dialogs representing each step aren't created when there is movement between the various steps, because all the dialogs have already been created in the constructor of the CDialogChooser class. In the constructor an array of pointers is set up with each array element pointing to a specific dialog:

CDialogChooser::CDialogChooser()
{
  m_pDlgs[0] = NULL;

  m_pDlgs[1] = new CCustom1Dlg;

  m_pDlgs[2] = new CCustom2Dlg;

  m_pDlgs[3] = new CCustom3Dlg;

  m_pDlgs[4] = new CCustom4Dlg;

  m_pDlgs[5] = new CCustom5Dlg;

  m_pDlgs[6] = new CCustom6Dlg;

  m_nCurrDlg = 0;
}

To get the OnInitDialog function to be called again, thus enabling the correct options, one needs to have the respective dialog created as the step comes active. This is done by the following code in the Next function:

// Use the internal array to determine the next step.

CAppWizStepDlg* CDialogChooser::Next(CAppWizStepDlg* pDlg)
{
  ASSERT(0 <= m_nCurrDlg && m_nCurrDlg < LAST_DLG);
  ASSERT(pDlg == m_pDlgs[m_nCurrDlg]);

  //Delete the current dialog and create the next one

  m_nCurrDlg++;
  int pos = m_nCurrDlg;
  switch (m_nCurrDlg)
  {
     case 1 : m_pDlgs[m_nCurrDlg] = new CCustom1Dlg;
      break;
    case 2 : delete m_pDlgs[--pos]; //prevent memory leak

      m_pDlgs[pos] = NULL;
      m_pDlgs[m_nCurrDlg] = new CCustom2Dlg;
      break;
   
      .... //The same for cases 3 to 6

  }
  return m_pDlgs[m_nCurrDlg];
}

The same goes for the Back function:

// Use the internal array to determine the previous step.

CAppWizStepDlg* CDialogChooser::Back(CAppWizStepDlg* pDlg)
{
  ASSERT(1 <= m_nCurrDlg && m_nCurrDlg <= LAST_DLG);
  ASSERT(pDlg == m_pDlgs[m_nCurrDlg]);
  m_nCurrDlg--;
  int pos = m_nCurrDlg;
  switch (m_nCurrDlg)
  {
    case 1 : delete m_pDlgs[++pos]; //prevent memory leak

      m_pDlgs[pos] = NULL;
      m_pDlgs[m_nCurrDlg] = new CCustom1Dlg;
      break;
   
      .... //The same for cases 2 to 5

         
    case 6 : m_pDlgs[m_nCurrDlg] = new CCustom6Dlg;
      break;
  }
  return m_pDlgs[m_nCurrDlg];
}

Looping macro

In CCustom3Dlg one can enter the name of more than one interface. These are saved in the dictionary under a macro NAME_x. The count of the total number of interfaces are stored in another macro INTERFACES, which can be used in $$BEGINLOOP. If the names Quoter and QuoterFactory are stored in the dictionary under the macros NAME_0 and NAME_1 respectively, with the number 2 stored in INTERFACES then the following:

$$BEGINLOOP(INTERFACES)
  interface $$NAME$$
  {
    
  };

$$ENDLOOP

will become

  interface Quoter
  {
  
  };
  
  interface QuoterFactory
  {
  
  };

Still to do

Additional features to be added:

  • Support for Dynamic CORBA
  • Support for CORBAServices
  • IDL compiler options

If it is possible:

  • Add a new project to the workspace created, so that when the workspace is eventually displayed it will contain two projects.
    This is for when the user selects the "Server and Client" option.
  • Add folders and their relative files to the newly added project.

References and Further Information

History

  • 3 November 2003 - First public release.
  • 12 October 2002 - Started developing and writing the Application Wizard.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here