Using TAO and OpenDDS with .NET [Part I]

INTRODUCTION

A major advantage of TAO and OpenDDS, open-source implementations of the Object Management Group's CORBA and the Data Distribution Service, is the wide variety of platforms to which they have been ported. While retaining platform neutrality is a worthy goal, the dominance of Microsoft Windows in the PC marketplace, over 90% [1] market share as of the writing of this article, encourages the use of Windows-specific features when developing for that platform.

Since the release of Visual Studio.NET in 2002, Microsoft's direction for development has been that of the .NET Framework [2]. In a manner similar to Java bytecode, high-level languages are compiled into an assembly-like intermediate language, standardized as the Common Language Infrastructure by Ecma International in ECMA-335 [3], which is then ultimately compiled and run on the target machine.

Although special languages such as C# have been created for .NET development, C++ has the ability to use the .NET Framework as well. How well-integrated C++ code is with the .NET Framework, though, is dependent upon how many code changes are made to conform to the new C++/CLI syntax. As TAO and OpenDDS are written in standard C++, this article series will show how they can be adapted to be used in a .NET application.

APPLICATION OVERVIEW

For several years, OCI has been engaged with a customer in the maintenance of a legacy data-acquisition application. Data is collected by remote sensing devices and stored in a database, and the sensing devices are managed, and the data viewed, by an application written for Microsoft Windows.

Although originally a single-user application referencing a local database, over time the application has evolved into one where multiple users can simultaneously connect to a single centralized database. If one user makes a change to the database, all other connected users must be made aware of the change so their local states can be updated.

A solution to this problem is to create a single process to manage access to the database, and to provide database change notifications to interested client applications. Having a single process interact with the database on behalf of clients, instead of allowing each client direct access to the database, ensures that no database change can be made without the system, as a whole, becoming aware of it. Additionally, abstracting the details of the database access from the clients allows the database process be moved to other hosts, or even be implemented on a different platform, without requiring more than just a reference to the new location of the database process to be changed in the configuration of the clients — no client code changes would be necessary.

TAO and OpenDDS were selected as the middleware to accomplish this task for two main reasons. The first is that it is easy to be up and running quickly — the prototype that was developed to illustrate the architecture was completed in under three days. The second is that, as both TAO and OpenDDS are open source, there are no license fees or other costs involved. The resulting application can be deployed widely without incurring a per-seat, or per-CPU, or even a development/SDK charge.

The existing legacy application interacts with a database via ADO.NET [4], a series of classes provided by the .NET Framework, which provide a uniform means of accessing various data source types. The code that uses ADO.NET is in a library, written in C#. The main application that uses this library is written in C++.

In order to solve the problem outlined above, the following architecture was designed. In this diagram, components written in C# shown with box hatching and components written in C++ shown with angled hatching.

Figure 1. Architecture

The separate application to manage the database, called the DataServer, was written. This application, in C++, uses the same C# library as before. It now, however, acts as a CORBA server, processing requests from clients to perform database operations. As operations are performed, the DataServer publishes a DDS data sample to clients to notify them of the results of the operation. DDS is used instead of the CORBA Notification Service for notifications as DDS samples are strongly typed (rather than being the CORBA Any type), plus DDS provides quality-of-service policies that the Notification Service does not. This article describes the core elements of the DataServer, as well as a client application, written in C#, that makes use of it. The client performs CORBA operation invocations, and subscribes to the DDS data samples. This article will also illustrate the use of MPC for project maintenance.

Sidebar

The code in this article was developed with Microsoft Visual Studio 2005. It was compiled against TAO version 1.6a, OpenDDS version 1.3, and MPC version 3.7.2. Inline assembly was disabled to prevent the .NET-related compiler warning C4793, as the use of __asm forces native code generation. Wide character support was enabled, as .NET uses Unicode for string representation. The build settings for these features are as follows:

// add to %ACE_ROOT%\ace\config.h
#define ACE_LACKS_INLINE_ASSEMBLY 1
#define ACE_USES_WCHAR 1

// add to %ACE_ROOT%\bin\MakeProjectCreator\config\default.features
uses_wchar=1

DataLib

The core functionality of the Data Server is provided by DataLib, a library written in C# which interacts with the database. For this example, we'll use System.Data.SQLite, a public domain SQLite ADO.NET provider.

DataLib consists of a single file, DataLib.cs, containing a single class named Database, and referencing several .NET libraries as well as System.Data.SQLite. The structure of the Database class is below. Methods are provided to open and close the database, where, for simplicity, a single database connection is used. Additional methods are provided to create, read, update and delete records in an item table, where an item has both an autogenerated numeric ID and a description. For the implementation of these methods, please see the code archive that accompanies this article.

namespace DataLib
{
    using System;
    using System.Data;
    using System.Data.SQLite;
 
    public class Database
    {
        // open and close the database connection
        public bool Open()
        public void Close()
 
        // create a new item, and return the autogenerated ID
        public bool CreateItem(string description, out Int64 id)
 
        // read the description from a specific item, given the item ID
        public bool ReadItem(Int64 id, out string description)
 
        // update the description of an item given its ID
        public bool UpdateItem(Int64 id, string description)
 
        // delete an item, given its ID
        public bool DeleteItem(Int64 id)
    }
}

DataLib PROJECT CREATION

Although the DataLib project can be created from within Visual Studio, using MPC (the Makefile, Project, and Workspace Creator) provides a number of benefits:

1. Different versions of Visual Studio can be supported with one set of project description files. Conversion of solution and project files between versions of Visual Studio is not necessary.
2. MPC project description (.mpc) files can inherit from base project (.mpb) files, allowing settings such as output directory specification or the setting of a warning level to be made in one place and applied across all projects. If these settings were changed within Visual Studio, changes would have to be made over and over again, once for each project in the solution.
3. Comments are supported in the project description files, allowing the rationale behind the various settings to be documented.
4. Often, the default settings for projects can be used without needing to change them, making project descriptions simple.

Documentation for MPC can be found here, though we will describe features of MPC that are useful for this application.

As this system will consist of several projects, we create a base project to allow settings that all projects should inherit. We also set an environment variable, DATASERVER_ROOT, to represent the top-level directory of the project. This allows us to move the entire source tree while correctly maintaining any full paths used in the project files.

The base of all projects in the workspace is named DataServerBase.mpb, and has the following contents:

// DataServerBase.mpb
project {
    specific {
        Release::install = $(DATASERVER_ROOT)/Output/Release
        Debug::install = $(DATASERVER_ROOT)/Output/Debug
 
        warning_level = 4
    }  
}

When generating projects for Visual Studio, it is important to remember that the variables set in the MPC or MPB file reflect ones set in the Visual Studio IDE. Generally, settings which correspond to strings are set directly in the MPC or MPB file, but those that represent dropdowns are set by the numeric index of the choice of interest in the dropdown. In this case, output directories are specified by name, but the warning level is set numerically to 4, which represents the choice of /W4 in the IDE.

As this project will contain different types of projects, written in different languages, it is useful to define base projects which apply to subsets of projects in the workspace. The contents of the file CSBase follows, the base for all C# projects.

// CSBase.mpb
project : DataServerBase {
    specific {
        // to avoid "Load of property 'ReferencePath' failed.  Cannot 
        // add '.' as a reference path as it is relative. Please specify 
        // an absolute path." on C# project load into the IDE
        libpaths -= .
    }
}

By default, MPC adds the current directory to the list of directories where libraries are found, though Visual Studio will generate a warning if the directory is not an absolute path. The entry above removes the current directory from the library paths. This project inherits from DataServerBase, so settings that are made in DataServerBase are applied in addition to what is in this file.

Finally, an MPC file is needed for the project itself. DataLib.mpc is as follows:

// DataLib.mpc
project : CSBase {
    // To remove the warning "Load of property 'ReferencePath' failed.  
    // Cannot add '..\lib' as a reference path as it is relative. Please 
    // specify an absolute path."
    expand(DATASERVER_ROOT) {
        $DATASERVER_ROOT
    }  
 
    lit_libs += System System.Data System.Xml
    lit_libs += System.Data.SQLite
    libpaths += $(DATASERVER_ROOT)\lib
}

The expand option causes the environment variable to be treated as an absolute path — by default, MPC converts environment variables to relative paths. As with the previous issue with libpaths, this also prevents a warning in Visual Studio from being generated when the lib subdirectory is added.

As this is a .NET application, references to various .NET assemblies must be provided, in addition to the System.Data.SQLite assembly, which provides the database connectivity. For this example, System.Data.SQLite.dll is located in the lib subdirectory off of the main project directory, and the libpaths entry adds that directory to the library path.

This project inherits from CSBase, so has all of the settings supplied by CSBase.mpb and DataServerBase.mpb.

It is interesting to note what does not need to be specified. As this is an MPC file for a C# project, you do not need to provide specific names of .cs files — all .cs files in the same directory as the MPC file are automatically included. Also, you do not need to specify a file name for the output — in this instance, MPC will use the base name of the MPC file, which is what we want.

With the project file created, the last step is to create a workspace (.mwc) file, which corresponds to the contents of the Visual Studio solution (.sln) file. DataServer.mwc, located in the project root, looks like this:

// DataServer.mwc
workspace {
    specific {
        cmdline += -language csharp
        DataLib
    }
}

For this project, DataLib.cs and DataLib.mpc are in a subdirectory named DataLib, off of the root. The workspace file specifies that the DataLib subdirectory is to be searched for MPC files, and that any MPC files found there should be treated as describing C# projects.

Running MPC on the MWC file generates the solution file. The solution file can then be opened in Visual Studio, the DataLib project compiled, and the DataLib assembly built. As this code was developed using Visual Studio 2005 (VC8), we can generate the solution file by executing:

%ACE_ROOT%\bin\mwc.pl -type vc8 DataServer.mwc

from a console prompt set to the project's root directory.

INTERFACE DEFINITION LANGUAGE (IDL)

Now that the library for data access has been developed, we can write a CORBA server which uses that library. We wish to expose the functionality of the library as a CORBA object, so an interface, described in IDL, must be created. In a subdirectory named IDL off of the root, we create a file, Database.idl, which contains that interface.

// Database.idl
interface Database
{
    boolean CreateItem(in wstring description, out long long id);
    boolean ReadItem(in long long id, out wstring description);
    boolean UpdateItem(in long long id, in wstring description);
    boolean DeleteItem(in long long id);	
};

The operations of the interface correspond to the client-accessible methods of DataLib::Database, the class defined in DataLib. The IDL types that are used in the interface correspond to the types used in C#. In particular, strings in .NET are in Unicode, so wstring is used to pass them, and as database IDs are 64-bit, long long is needed.

In the IDL subdirectory, create the file IDL.mpc to allow the file to be compiled by the TAO IDL compiler.

// IDL.mpc
project : taoidldefaults {
    IDL_Files {
        Database.idl
    }
    custom_only = 1
}

Inheriting from the taoidldefaults base project, a base project included in the TAO distribution, provides the needed infrastructure. We only need to list the IDL file in the IDL_Files section, and MPC generates the tao_idl compilation commands. We do need to indicate that the project has no executable output via the custom_only flag, however.

For this project to be added to the solution file, the workspace file, DataServer.mwc, must be modified to include the IDL directory. After the addition, DataServer.mwc looks like this:

// DataServer.mwc
workspace {
    specific {
        cmdline += -language csharp
        DataLib
    }
    IDL
}

The IDL project is not in C#, so the IDL directory is listed outside of the specific section. The compilation of this project produces the client stub and server skeleton files, DatabaseC.[cpp,h,inl] and DatabaseS.[cpp,h,inl], respectively.

DATABASE IMPLEMENTATION

With the database interface defined, we can create a C++ class that which implements the interface. We create a subdirectory off of the root named DataServer, and two files in that subdirectory, Database_i.h and Database_i.cpp. The files as presented here were based off of generated implementation files via the -GI option to tao_idl and modified accordingly. Amendments to the generated code are noted here — please see the code archive associated with this article for the full file listings.

These files define class Database_i, an implementation of the Database CORBA interface. An instance of this implementation is called a servant. As we would like the instance of the DataLib::Database class to be maintained by the server itself, we must be able to pass a reference to it to the servant. As DataLib::Database is a .NET class and Database_i is not (as it is a standard, unmanaged C++ class), a reference to the DataLib::Database object must be stored using gcroot<>, a templated helper class provided by the vcclr.h header file. We must add #include  to the top of Database_i.h, and add a class member variable to class Database_i to store the .NET reference (indicated by the caret) to DataLib::Database.

// Database_i.h
class Database_i
  : public virtual POA_Database
{
    gcroot<DataLib::Database^> database_;
...

This variable is initialized by the Database_i constructor.

// Database_i.h
Database_i(gcroot<DataLib::Database^> database);

// Database_i.cpp
Database_i::Database_i(gcroot<DataLib::Database^> database) : 
    database_(database)
{
}

In the methods of Database_i, we use the database_ member variable to reference the DataLib::Database object, such as in the implementation of CreateItem().

// Database_i.cpp
::CORBA::Boolean Database_i::CreateItem(
    const ::CORBA::WChar * description,
    ::CORBA::LongLong_out id) 
{
    System::String^ netDescription = gcnew System::String(description);
    ::CORBA::Boolean result = database_->CreateItem(netDescription, id);
    delete netDescription;
    return result;
}

Implementation of the CORBA Database interface is essentially a translation between CORBA and .NET. In this method, a string provided by CORBA is converted to a .NET String before being passed to DataLib::Database::CreateItem(). The code above also illustrates a benefit of C++/CLI. The variable netDescription is allocated on the garbage-collected heap via gcnew. It can still be determininstically freed, however, by a call to delete, as if it was an allocation made by new on the unmanaged heap. However, if an exception is thrown by the invocation of CreateItem() and delete is not called, netDescription will still be freed by the garbage collector when it executes at some point in the future.

The implementation of ReadItem() also involves string translation, but this time from .NET to CORBA.

// Database_i.cpp
::CORBA::Boolean Database_i::ReadItem (
    ::CORBA::LongLong id,
    ::CORBA::WString_out description)
{
    System::String^ netDescription;
    ::CORBA::Boolean result = database_->ReadItem(id, netDescription);
    if (result) {
        pin_ptr<const wchar_t> s = PtrToStringChars(netDescription);
        description = s;
    }
    return result;
}

The pin_ptr<> template and PtrToStringChars() function are two more Visual Studio-provided helpers to assist in dealing with .NET types in standard C++. PtrToStringChars() provides a means to directly address .NET String contents, and, as .NET strings are in Unicode, the contents are represented as an array of wchar_t. As the .NET String is on the garbage-collected heap, pin_ptr<> is used to keep the string contents from being relocated until access to it is complete. It must remain accessible until the skeleton marshals it into the GIOP reply.

The implementation of UpdateItem() and DeleteItem() are analagous to the above.

DATASERVER

With the completion of the servant, we can now implement the DataServer itself. In the file DataServer.cpp, the main() function of DataServer begins as most simple CORBA servers do.

// DataServer.cpp
int ACE_TMAIN(int argc, ACE_TCHAR *argv[]) {
    try {
        // initialize the ORB
        CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
 
        // get a reference to the RootPOA
        CORBA::Object_var obj = 
            orb->resolve_initial_references("RootPOA");
        PortableServer::POA_var poa = 
            PortableServer::POA::_narrow(obj.in());
 
        // activate the POAManager
        PortableServer::POAManager_var mgr = poa->the_POAManager();
        mgr->activate();

To create the servant, we first create an object of type DataLib::Database, open the database connection, and pass a reference to the object to the servant's constructor. In this instance, the percent sign in .NET acts somewhat like an ampersand does in standard C++ — it provides a reference to an object.

        // open the database
        DataLib::Database database;
        if (!database.Open())
            throw std::exception("Cannot open the database");
 
        // create the Database servant
        Database_i servant(%database);
        PortableServer::ObjectId_var oid = 
            poa->activate_object(&servant);
        CORBA::Object_var database_obj = poa->id_to_reference(oid.in());

There are a number of ways to provide the IOR of an object to callers, such as via a file or via the Naming Service. For this application, we use the IORTable, a TAO-specific feature which allows a client to find a server via a corbaloc URL.

        CORBA::String_var ior_str = 
            orb->object_to_string(database_obj.in());
        CORBA::Object_var tobj = 
            orb->resolve_initial_references("IORTable");
        IORTable::Table_var table = IORTable::Table::_narrow(tobj.in());
        table->bind("DataServer", ior_str.in());
        std::cout << "DataServer bound to IORTable" << std::endl;

main() ends by calling run() on the ORB instance, and by providing cleanup and error reporting.

        // accept requests from clients
        orb->run();
        orb->destroy();
    }
    catch (CORBA::Exception& ex) {
        std::cerr << "CORBA exception: " << ex << std::endl;
    }
    catch (std::exception& ex) {
        std::cerr << "Exception: " << ex.what() << std::endl;
    }
 
    return 0;
}

We next create an MPC file for the DataServer. It is slightly more complicated than previous MPC files.

// DataServer.mpc
project : taoserver, CPPBase, iortable {
    after += IDL
    after += DataLib
 
    includes += ../IDL
    Source_Files {
        Database_i.cpp
        DataServer.cpp
        ../IDL/DatabaseC.cpp
        ../IDL/DatabaseS.cpp
    }
 
    managed = 1
}

In the same way that the IDL project inherits from the taoidldefaults base project to derive behavior, TAO provides other base projects which allow features of TAO to be easily referenced by an application — these base projects set include paths, library linkages, preprocessor symbols and other configuration options so the user of TAO does not have to. As DataServer is an application that uses server components of TAO, it inherits from taoserver. It uses the IORTable, so it inherits from iortable as well — if it had used Naming Service functionality, it would have inherited from naming. We desire it to have the same attributes as other C++ applications in the solution, so it also inherits from CPPBase.

The after statements ensure that the IDL and DataLib projects are built prior to this one. As source code files are not all located in the same directory as the MPC file, we must specify them explicitly via the includes statement and the Source_Files section. Finally, the /clr compiler option must be set to allow .NET functionality to be directly used in C++ code, so managed = 1 is specified.

This project must also be added to the workspace, leading to a DataServer.mwc that looks like this:

// DataServer.mwc
workspace {
    specific {
        cmdline += -language csharp
        DataLib
    }
    IDL
    DataServer
}

We then regenerate the solution file using MPC, rebuild, and now have a working server.

SIDEBAR

As discussed in references [5] and [6], incomplete types will generate linker warning LNK4248 when compiled with /clr, and is seen with many types in TAO. For example:

warning LNK4248: unresolved typeref token (01000016) for 
    'TAO_ORB_Core'; image may not run

The actual type that will be used is defined in TAO itself, which is not compiled with /clr. In practice, this warning is harmless, though defining the symbol with an empty body in the module that generates the warning will suppress the message. Please see the file LNK4248.h in the code archive for an approach to this issue.

DataServerConnectorLib

With the server side complete, we can begin development of the client.

The DataServerConnectorLib library acts as a client of the DataServer. More specifically, the class DataServerConnector in this library makes the client-side CORBA calls to invoke methods on the server.

Although this class is implemented in C++ to make use of TAO, this class is a fully-fledged .NET type, so it can be used by the Client application, which is written in C#. For future convenience, the method Run() of this class is executed in a .NET thread to allow an ORB to continue execution independent of the code that uses DataServerConnector, and the Start() and Shutdown() methods manage this thread.

The other public methods of this class mirror the CORBA Database interface, in appropriate .NET syntax.

We start by creating the file DataServerConnectorLib.h in the DataServerConnectorLib subdirectory off of the root and add the following class definitions:

using namespace System;
using namespace System::Threading;
 
class DataServerConnectorState {
    CORBA::ORB_var orb_;
    Database_var database_;
public:
    DataServerConnectorState(CORBA::ORB_ptr orb, Database_ptr database);
    Database_ptr DatabasePtr() { return database_; }
    CORBA::ORB_ptr OrbPtr() { return orb_; }
};
 
public ref class DataServerConnector {
    DataServerConnectorState *state_;
    Thread^ thread_;
    AutoResetEvent startupEvent_;
    void Run();
    static void ThreadStart(Object^ param);
public:
    DataServerConnector();
    ~DataServerConnector();
    void Start();
    void Shutdown();
    bool CreateItem(String ^description, Int64 %id);
    bool ReadItem(Int64 id, String^% description);
    bool UpdateItem(Int64 id, String^ description);
    bool DeleteItem(Int64 id);
};

The using statements allow us to use types from various .NET assemblies without needing to specify the fully qualified names, such as Thread instead of System::Threading::Thread. The DataServerConnector class is declared as a public ref class. The public keyword indicates that the class is visible outside of the assembly; __declspec(dllexport) is not used with .NET types, as it would be with standard Windows dynamic link libraries to export symbols. The ref keyword indicates that the class is a garbage-collected .NET type, and not an unmanaged, standard C++ class.

DataServerConnectorState is, however, an unmanaged, standard C++ class. Unmanaged types (such as CORBA::ORB_var) cannot be member variables of a .NET class, but pointers to unmanaged types can be. DataServerConnectorState acts as a container for the unmanaged state of DataServerConnector.

The implementation of DataServerConnectorState is straightforward — it stores ORB and servant pointers for later use. It resides, with the implementation of DataServerConnector, in the file DataServerConnectorLib.cpp.

// DataServerConnectorLib.cpp
DataServerConnectorState::DataServerConnectorState(CORBA::ORB_ptr orb, 
    Database_ptr database) {
    orb_ = CORBA::ORB::_duplicate(orb);
    database_ = Database::_duplicate(database);
}

The Run() method contains the CORBA client implementation. Because ORB_init() requires C-style argc and argv, they must be constructed from the .NET command-line argument array, so we begin by performing that conversion, and then initialize the ORB.

// DataServerConnectorLib.cpp
void DataServerConnector::Run() {
    int argc = 0;
    wchar_t **argv = NULL;
 
    try {
        // convert .NET arguments to standard argc/argv
        array<String^>^ arguments = Environment::GetCommandLineArgs();
        argc = arguments->Length;
        argv = new wchar_t *[argc];
        for (int i=0; i<argc; i++) {
            pin_ptr<const wchar_t> arg = PtrToStringChars(arguments[i]);
            argv[i] = _wcsdup(arg);
        }
 
        CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

We now obtain an object reference to the Database object. Because the server registered the object in the IORTable, the client can locate it by passing

-ORBInitRef DataServer=
    corbaloc:iiop:server_hostname:server_port/DataServer

on its command line, and calling resolve_initial_references().

        // obtain the reference
        CORBA::Object_var database_obj = 
            orb->resolve_initial_references("DataServer");
        if (CORBA::is_nil(database_obj.in())) 
            throw std::exception("Could not get the Database IOR");
 
        // narrow the IOR to a Database object reference.
        Database_var database = Database::_narrow(database_obj.in());
        if (CORBA::is_nil(database.in()))
            throw 
              std::exception("IOR was not a Database object reference");

We now store references to the ORB and Database object for later use, run the ORB to process any requests, and perform cleanup on error. DataConnectorException, a subclass of the .NET Exception class, is defined to wrap and re-throw any exceptions that are generated. This allows native exceptions, such as CORBA::Exception to be propagated to the .NET world.

        // save the references via a pointer to an unmanaged class
        state_ = new DataServerConnectorState(orb, database);
 
        // good to go - tell the outside world
        startupEvent_.Set();
 
        // run the ORB
        orb->run();
        orb->destroy();
    }
    catch (CORBA::Exception& ex) {
        std::stringstream ss;
        ss << "Exception: " << ex;
        throw 
          gcnew DataConnectorException(gcnew String(ss.str().c_str()));
    }
    catch (std::exception& ex) {
        std::stringstream ss;
        ss << "Exception: " << ex.what();
        throw 
          gcnew DataConnectorException(gcnew String(ss.str().c_str()));
     }
}

We must also implement methods that wrap the CORBA method invocations. As translation was performed in the DataServer, we do the same, but in reverse — from .NET to CORBA. For example, CreateItem() is defined below. The .NET string is converted to a CORBA::WString via the PtrToStringChars()/pin_ptr<> combination we have used before. The CORBA::LongLong used to store the out parameter from the CreateItem() CORBA interface method is converted to a .NET Int64 to be returned to the caller. Note that the percent sign in the argument list, in this usage, acts as an out parameter. As with Run(), exceptions are propagated as the DataConnectorException type. The other wrapper methods are analagous.

// DataServerConnectorLib.cpp
bool DataServerConnector::CreateItem(String ^description, Int64 %id) {
    try {
        pin_ptr<const wchar_t> cppDescription = 
            PtrToStringChars(description);
        CORBA::WString_var desc = CORBA::wstring_dup(cppDescription);
        CORBA::LongLong cid;
        CORBA::Boolean result = 
            state_->DatabasePtr()->CreateItem(desc, cid);
        id = cid;
        return result;
    } catch (CORBA::Exception& ex) {
        std::stringstream ss;
        ss << "Exception: " << ex;
        throw 
          gcnew DataConnectorException(gcnew String(ss.str().c_str()));
    }
}

After the .NET thread management methods are added, development of the DataServerConnectorLib is complete. We now create an MPC file for it. The options specified are similar to those used in DataServer.mpc.

// DataServerConnectorLib.mpc
project : taoexe, CPPBase {
    after += IDL
    includes += ../IDL
 
    Source_Files {
        DataServerConnectorLib.cpp
        ../IDL/DatabaseC.cpp
    }
 
    managed = 1
}

We also add it to DataServer.mwc.

// DataServer.mwc
workspace {
    specific {
        cmdline += -language csharp
        DataLib
    }
    IDL
    DataServer
    DataServerConnectorLib
}

Regenerating the solution with MPC and recompiling yields a working DataServerConnectorLib.

CLIENT

The last module we will create is a GUI in C# to demonstrate the system. The GUI consists of a ListView to display messages, and a series of Buttons and TextBoxes to exercise the database methods. Please refer to the code archive for details of the GUI itself.

The implementation of the button click methods invoke the corresponding database functions — the methods exposed by the DataServerConnector class. User input into the TextBoxes associated with each button is used, as appropriate. For instance, the click handler for the Create button is as follows:

private void bCreate_Click(object sender, EventArgs e)
{
    try
    {
        // if input is blank, do nothing, else create the item
        if (String.IsNullOrEmpty(tCreateDesc.Text))
            return;
 
        // invoke the method
        long id = 0;
        if (dataConnector_.CreateItem(tCreateDesc.Text, ref id))
            Log("Item '" + tCreateDesc.Text + "' created with id " + id);
        else
            Log("Item '" + tCreateDesc.Text + "' could not be created");
    }
    catch (DataConnectorException ex)
    {
        Log(ex.Message);
    }
 
    // after completion (or failure) clear the input
    tCreateDesc.Text = "";
}

In this method, tCreateDesc is the TextBox associated with the Create button. If the user has entered text, it will be used as the item description of the item to be created. The call to DataServerConnector::CreateItem() invokes the CORBA method, the ID of the created item is returned (the ref in C# corresponds to the % in C++ in the argument list of DataServerConnector::CreateItem()), and displayed to the user in the ListView via the call to Log(). The other methods are implemented similarly.

With the code complete, we create an MPC file for the Client project, as follows:

// Client.mpc
project : CSBase {
    exename = Client
 
    after += DataServerConnectorLib
 
    specific {
        winapp = true
    }
 
    Source_Files {
        *.cs
        *.Designer.cs
    } 
 
    Source_Files {
        subtype = Form
        Client.cs
    }
 
    Resx_Files {
        generates_source = 1
        subtype = Designer
        Properties/Resources.resx
    }
 
    lit_libs += System System.Data System.Xml 
    lit_libs += System.Drawing System.Windows.Forms
}

This MPC file is more complex than we have seen so far, due to the nature of a graphical .NET application. In this project, the file Program.cs contains the C# Main() function, so unless otherwise specified, the output will be named Program.exe. We use the exename keyword to change the name of the output to Client.exe. We must specify winapp = true as, by default, MPC will create a console-based C# application, and Client is a GUI-based one. Two Source_Files sections are necessary, as the file Client.cs contains a subclass of System.Windows.Forms.Form to act as the main window of the application. Form code requires additional infrastructure (e.g., support for one or more associated resource files) that normal code files do not. The resource file Resources.resx is similar in that it has an associated autogenerated C# file that provides access to the resources it contains.

With the MPC file complete, we now add it to the workspace, yielding:

// DataServer.mwc
workspace {
    specific {
        cmdline += -language csharp
        DataLib
        Client
    }
    IDL
    DataServer
    DataServerConnectorLib
}

CONCLUSION

The following screen shots demonstrate the system. We start two Clients, as well as the DataServer (not shown). For this run, the server was run on the machine oci1373 and started with the following command (on a single line):

DataServer -ORBDottedDecimalAddresses 0 
    -ORBListenEndpoints iiop://:12346

Each of the Client instances were started with this command (on a single line):

Client -ORBDottedDecimalAddresses 0 
    -ORBInitRef DataServer=corbaloc:iiop:oci1373:12346/DataServer

We enter "My First Item" into the TextBox associated with the Create button on the first Client.

Figure 2. Client

Pressing the Create button creates the database item, and the generated ID of 1 is reflected in the ListView.

Figure 3. With Description

On the second Client, we enter the ID of 1 into the TextBox associated with the Read button.

Figure 4. Read Button

Pressing the Read button displays "My First Item" as the item description, demonstrating that the second Client has referenced the same database as the first Client.

Figure 5. Database

This article has described how to use TAO in a .NET application to implement both a CORBA client and server. The next article in this series will show how to incorporate OpenDDS to provide database notifications.

REFERENCES

• [1] Top Operating System Share Trend
  http://marketshare.hitslink.com/os-market-share.aspx?qprid=9

• [2] Framework Overview
  http://www.microsoft.com/net/overview.aspx

• [3] Standard ECMA-335 Common Language Infrastructure (CLI)
  http://www.ecma-international.org/publications/standards/Ecma-335.htm

• [4] ADO.NET
  http://msdn.microsoft.com/en-us/library/aa286484.aspx

• [5] warning LNK4248: unresolved typeref token (01000017) for '_TREEITEM'; image may not run
  http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0730e965-7299-44ca-8a95-59e2eb23d153

• [6] Linker Tools Warning LNK4248
  http://msdn.microsoft.com/en-us/library/h8027ys9%28VS.80%29.aspx