The heart of the Tweek software system implements the Observer pattern [Gam95]. This design pattern is used to define the relationship between the Java GUI (observer) and the C++ application (subject). Within this section, we explain how the subject and observer are used. Moving beyond the subject/observer pattern, we also explain the Subject Manager and the CORBA Manager. These four components make up the entirety of the C++ design.

CORBA, the Common Object Request Broker Architecture, is a powerful tool for distributed programming. It is a language-independent standard specified by the Object Management Group (OMG). Many CORBA implementations, both free and commercial, exist for a wide variety of languages (e.g., C, C++, Java, Perl, Python, and Smalltalk). CORBA allows communication between software written in any programming language running on any operating system on any hardware architecture. It handles all serialization and de-serialization of objects and method parameters so that programmers do not have to worry about endian issues and other system incompatibilities.

Before going further with the discussion of CORBA in Tweek, readers must be familiar with some terminology. In CORBA, the physical object to which references are made is called a servant. The servant is an instance of some class that implements an interface and derives from CORBA::Object (or org.omg.CORBA.Object in Java). The actual details of servant implementations are postponed for later sections. For now, it is important to remember that there will be an object located in physical memory on some machine, and references will be made to that object through CORBA. Users acquire references by looking up the object by name in what is known as the CORBA Naming Service. The Naming Service has objects registered within its database, and clients request references from the database. When the reference is made available, methods may be invoked on it. Since the physical object resides in another memory space, this will create network traffic, though it is entirely transparent to the programmer.

CORBA uses Object Request Brokers (ORBs) to manage locally registered objects and to communicate with remote objects. The remote objects are managed by ORBs that reside locally on the machines that have the servants. Two ORBs communicate with each other using a standard protocol. In this case, that protocol is the Internet Inter-ORB Protocol (IIOP). IIOP is a new addition to Version 2.3 of the CORBA standard. It allows two ORBs written by different vendors to communicate and inter-operate. This capability is crucial to the correct functionality of Tweek and many other CORBA-based software systems.

Within the scope of Tweek, CORBA is used to enable transparent communication between C++ applications and the Tweek Java GUI. C++ objects registered with a local ORB are made available to the Java GUI through the Subject Manager. Beyond this, CORBA exists mostly "behind the scenes" so that developers of Tweek-based software do not have to learn very much about CORBA. Programmers must understand the Interface Definition Language, however, and this is explained next.

There are four types of Beans that may be loaded by the Tweek Java GUI. They are categorized based on functionality and what is known about them in advance. The following lists the four categories in order of decreasing a priori knowledge.

All JavaBeans loaded by the Tweek Java GUI are describe by at least one XML file. The XML file can contain information about many Beans or about a single Bean. The XML file itself is a “beanlist” document. The four Bean categories, described above, each have an XML element that has children giving information about the specific Bean. The elements are <service>, <viewer>, <guipanel>, and <generic>.

All Bean XML entries must contain a <file> element. Through its source attribute, this element provides the path to the JAR file that contains the full Bean code. When specifying the JAR file path, environment variables may be used. They must use the syntax ${ENV_VAR} (the curly braces are required). The class element gives the fully qualified name of the class stored within the JAR file that will be instantiated. The extension .class must not be specified. This is to allow the use of serialized classes which have the extension .ser. The Tweek Bean-loading code will figure out what is available and take the right actions.

In addition to the <file> element, a <dependencies> element may be specified. Dependencies of the Bean may be named as external JAR files or other Beans may be listed therein. The <dependencies> element may contain zero of more elements of type <jar> and/or <bean>. The <jar> element has a single attribute, path, which gives the path (a semi-colon separated list of directories) where the JAR file may be found. The contents of the <jar> element defines the name of the JAR file. The <bean> element's contents defines the name of the Bean that the current Bean depends on.

Of the four Bean categories, the XML for Panel Beans can contain the most information. In addition to the previously mentioned elements, Panel Bean entries may have two optional elements: <tree> and <icon>. The element <tree> specifies the path within the Bean tree hierarchy where the Panel Bean will be placed. The path is given as a /-separated list of directories. If the named path does not exist when the Bean is loaded, it will be created. The element <icon> names a custom icon for the Bean and a tool-tip. An example of a Panel Bean XML entry is shown in Example 2.1, “PlexusGraphView.xml snippet”. Note that this is not the full file—it is only the <guipanel> element for a single Bean.

<guipanel name="Graph View">
  <file name="${PLX_BASE_DIR}/share/plexus/beans/PlexusGraphView.jar" 
        class="plx.graphview.GraphView" />
  <tree path="/" />
  <dependencies>
    <jar path="${PLX_BASE_DIR}/share/plexus/beans">openjgraph.jar</jar>
    <jar path="${PLX_BASE_DIR}/share/plexus/beans">jgraph.jar</jar>
    <jar path="${PLX_BASE_DIR}/share/plexus/beans">PlexusComm.jar</jar>
  </dependencies>
  <icon source="jar:file:${PLX_BASE_DIR}/share/plexus/beans/PlexusGraphView.jar!/plx/graphview/icon.gif"
        tooltip="Plexus Network Graph Visualization" />
</guipanel>

This shows the use of all the elements that may be children of <guipanel>. Note that the source attribute of <icon> gets its icon image using a JAR URL.

Another example XML file is shown in Example 2.2, “Viewers.xml”. This is the actual file used to load the two Viewer Beans that come with the Tweek distribution. This is a complete file containing two Viewer Bean entries.

<?xml version="1.0" encoding="UTF-8"?>
<beanlist xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="http://www.vrjuggler.org/tweek/xsd/1.1/beanlist.xsd">
  <viewer name="Tree Viewer">
    <file name="${TWEEK_BASE_DIR}/share/tweek/beans/Viewers.jar" 
          class="org.vrjuggler.tweek.treeviewer.BeanTreeViewer" />
  </viewer>
  <viewer name="Icon Viewer">
    <file name="${TWEEK_BASE_DIR}/share/tweek/beans/Viewers.jar" 
          class="org.vrjuggler.tweek.iconviewer.BeanIconViewer" />
  </viewer>
</beanlist>

To create a custom subject implementation, you must derive from two classes: the abstract class that defines the custom interface and tweek::SubjectImpl. Referring back to the interface shown in Example 3.2, “CustomSubject.idl”, the basic C++ class declaration would appear as follows:

Example 4.1. CustomSubjectImpl.h

  1 #ifndef _CUSTOM_SUBJECT_IMPL_H_
    #define _CUSTOM_SUBJECT_IMPL_H_
    
    #include <tweek/CORBA/SubjectImpl.h>
  5 #include <CustomSubject.h>
    
    namespace mymod
    {
    
 10 class CustomSubjectImpl : public POA_mymod::CustomSubject,      
                              public tweek::SubjectImpl             
    public:
       CustomSubjectImpl() : mValue(0.0f)
       {
 15       ;
       }
    
       virtual ~CustomSubjectImpl()
       {
 20       ;
       }
    
       virtual float getValue();                                    
    
 25    virtual void setValue(float v);                              
    
       mymod::CustomSubject_ptr _this()                             
       {
          return POA_mymod::CustomSubject::_this();
 30    }
    
    private:
       float mValue;
    };
 35 
    }
    
    #endif

	Here we declare our parent classes, POA_mymod::CustomSubject and tweek::SubjectImpl. The first is code generated by the IDL compiler, and the second is included as part of the Tweek C++ API. Both are necessary for this custom interface to work correctly as a Tweek subject.
	These two declarations correspond to the CustomSubject interface defined in Example 3.2, “CustomSubject.idl”. The implementations of these methods are not shown here, but they are required for the code to compile. That is, the declarations in POA_mymod::CustomSubject are pure virtual methods, and an instance of mymod::CustomSubjectImpl cannot be created unless these methods are implemented.
	Overriding the method named _this() is required due to the diamond inheritance tree created by deriving from POA_mymod::CustomSubject and tweek::SubjectImpl. Both of these classes derive from tweek::Subject. The _this() method plays a critical role in the CORBA communication, and it is imperative that it return the correct type to the caller when invoked on a servant instance. Without this override, the returned type will be tweek::Subject_ptr, and attempts to narrow to mymod::CustomSubject_ptr will fail. Note the namespaces used on this method. The return type is mymod::CustomSubject_ptr, which corresponds to the namespace in which the classes CustomSubjectImpl and CustomSubject are defined. To get the actual value to return, POA_mymod::CustomSubject (one of the two parent classes) is used.

The implementations of getValue() and setValue() are fairly obvious, though they are presented here for the sake of completeness. Note, however, that setValue() changes the state of the subject, and thus any observers must be notified of the change. The implementations are shown in the following example.

#include <CustomSubjectImpl.h>

namespace mymod
{

float CustomSubjectImpl::getValue()
{
   return mValue;
}

void CustomSubjectImpl::setValue(float v)
{
   mValue = v;
   tweek::SubjectImpl::notify();
}

}

The key point to note is the call to tweek::SubjectImpl::notify() in the setValue() implementation. In general, anything that modifies the state of the subject requires that this method be invoked. Note also that the method is fully qualified so that we are sure to call the correct implementation.

Initializing the CORBA Manager is straightforward, but it does require exception handling. If the exceptions are not handled correctly, applications will abort if an exception is thrown but not caught. Refer to a C++ reference for more information about exceptions and exception handling in C++.

The following example shows a main() function for an application that performs all the Tweek initialization steps. We separate the discussion into two parts: one part for the CORBA Manager and one part for the Subject Manager (discussed in the next section).

Example 4.3. TweekApp.cpp

  1 #include <vpr/vpr.h>
    #include <vpr/Thread/Thread.h>
    #include <vpr/Util/Debug.h>
    #include <tweek/CORBA/CorbaManager.h>                         
  5 
    #include <CustomSubjectImpl.h>                                
    
    /**
     * This application starts the CORBA server for the C++ side
 10  * of the test.
     */
    int main(int argc, char* argv[])
    {
       tweek::CorbaManager mgr;                                   
 15 
       // The first thing we have to do is initialize the Tweek
       // CORBA Manager.  If this fails, we're out of luck.
       try                                                        
       {
 20       if ( mgr.init("example", argc, argv).success() )        
          {
             vpr::ReturnStatus status;
    
             // Once the CORBA Manager is initialized, we need
 25          // to create a Subject Manager.  This will hold our
             // CustomSubject object.
             try
             {
                status = mgr.createSubjectManager();
 30 
                // If we were able to create the Subject Manager,
                // now we register our objects with it.
                if ( status.success() )
                {
 35                // First, create real instances of the C++
                   // object that will be the CORBA servant.  This
                   // must be allocated on the heap.
                   mymod::CustomubjectImpl* custom_subj =
                      new mymod::CustomSubjectImpl();
 40 
                   // Now we try to register the subject and give
                   // it a symbolic, easy-to-remember name.
                   try
                   {
 45                   mgr.getSubjectManager()->
                         registerSubject(slider_subj, "CustomSubject");
                   }
                   catch (...)
                   {
 50                   vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                         << "Failed to register subject\n"
                         << vprDEBUG_FLUSH;
                   }
    
 55                // We are done with our pointer to the servant.
                   slider_subj->_remove_ref();
                }
             }
             catch (CORBA::Exception& ex)
 60          {
                vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                   << "Caught an unknown CORBA exception when "
                   << "trying to register!\n" << vprDEBUG_FLUSH;
             }
 65 
             if ( ! status.success() )
             {
                vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                   << "Failed to register Subject Manager instance\n"
 70                << vprDEBUG_FLUSH;
             }
    
             std::cout << "Press 'x' to exit" << std::endl;
             char input;
 75 
             // Loop forever so that we can act sort of like
             // a server.
             while ( 1 )
             {
 80             std::cin >> input;
                if ( input == 'x' )
                {
                   break;
                }
 85             else
                {
                   vpr::System::msleep(100);
                }
             }
 90       }
          else
          {
             vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                << "CORBA failed to initialize\n"
 95             << vprDEBUG_FLUSH;
          }
       }
       catch (...)                                               
       {
100       vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
             << "Caught an unknown exception!\n"
             << vprDEBUG_FLUSH;
       }
    
105    vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
          << "Exiting\n" << vprDEBUG_FLUSH;
    
       return 0;
    }

	These two headers are typically needed. The first includes the declaration of the Tweek CORBA Manager, and the second is the subject implementation declaration, shown in Example 4.1, “CustomSubjectImpl.h”.
	In order to use CORBA through Tweek, the CORBA Manager must be created and initialized. Any number of these may be created, but in general, only one is needed per application. Here, we declare an instance of tweek::CorbaManager on the stack.
	Next, we must initialize the CORBA Manager using the method tweek::CorbaManager::init(). The first argument provides a unique (ideally) identifier for the local Portable Object Adapter (POA). The second and third arguments are argc and argv respectively. They come in through the argument list of main() and represent the command-line arguments. Any arguments relevant to ORB initialization are removed from argv, and argc is decremented accordingly (it is passed by reference).
	To ensure that no exceptions go uncaught, we enclose the bulk of main() in a try/catch block that catches any exception. This is handled by the argument list passed to the catch block, (...). This is the equivalent of catching java.lang.Exception in Java.

To demonstrate use of the Subject Manager, we begin by revisiting the main() function examined in the previous section. This time, we will focus our attention on the code related to the Subject Manager only. We will also explain how to use the extended API of the Subject Manager implementation.

It is important to know that the Subject Manager is a CORBA object that can be accessed by remote code. In the following example, the methods used are defined in the class tweek::SubjectManagerImpl, the C++ implementation of the tweek::SubjectManager interface. The details of how the Subject Manager is handled through CORBA are largely irrelevant for most users of Tweek. Simply bear in mind that the Subject Manager is accessibly remotely and that it simplifies the use of CORBA in general.

Subject Manager Initialization

In order to use the Tweek Subject Manager, it must be initialized. Each CORBA Manager should have a single Subject Manager associated with it. If not, use of Tweek will be much more difficult because the CORBA Manager and the Subject Manager together hide most of the details relating to the use of CORBA. The following example shows how to initialize the Subject Manager using the CORBA Manager object created earlier.

Example 4.4. TweekApp.cpp

  1 #include <vpr/vpr.h>
    #include <vpr/Thread/Thread.h>
    #include <vpr/Util/Debug.h>
    #include <tweek/CORBA/CorbaManager.h>
  5 
    #include <CustomSubjectImpl.h>
    
    /**
     * This application starts the CORBA server for the C++ side of
 10  * the test.
     */
    int main(int argc, char* argv[])
    {
       tweek::CorbaManager mgr;
 15 
       // The first thing we have to do is initialize the Tweek
       // CORBA Manager.  If this fails, we're out of luck.
       try
       {
 20       if ( mgr.init("corba_test", argc, argv).success() )
          {
             vpr::ReturnStatus status;
    
             // Once the CORBA Manager is initialized, we need to
 25          // create a Subject Manager.  This will hold our
             // CustomSubject object.
             try
             {
                status = mgr.createSubjectManager();              
 30 
                // If we were able to create the Subject Manager,
                // now we register our objects with it.
                if ( status.success() )
                {
 35                // First, create real instances of the C++
                   // object that will be the CORBA servant.  This
                   // must be allocated on the heap.
                   mymod::CustomubjectImpl* custom_subj =
                      new mymod::CustomSubjectImpl();             
 40 
                   // Now we try to register the subject and give
                   // it a symbolic, easy-to-remember name.
                   try
                   {
 45                   mgr.getSubjectManager()->
                         registerSubject(custom_subj,
                                         "CustomSubject");        
                   }
                   catch (...)
 50                {
                      vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                         << "Failed to register subject\n"
                         << vprDEBUG_FLUSH;
                   }
 55 
                   // We are done with our pointer to the servant.
                   custom_subj->_remove_ref();
                }
             }
 60          catch (CORBA::Exception& ex)
             {
                vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                   << "Caught an unknown CORBA exception when "
                   << "trying to register!\n"
 65                << vprDEBUG_FLUSH;
             }
    
             if ( ! status.success() )
             {
 70             vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                   << "Failed to register Subject Manager instance\n"
                   << vprDEBUG_FLUSH;
             }
    
 75          std::cout << "Press 'x' to exit" << std::endl;
             char input;
    
             // Loop forever so that we can act sort of like
             // a server.
 80          while ( 1 )                                          
             {
                std::cin >> input;
                if ( input == 'x' )
                {
 85                break;
                }
                else
                {
                   vpr::System::msleep(100);
 90             }
             }
          }
          else
          {
 95          vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
                << "CORBA failed to initialize\n" << vprDEBUG_FLUSH;
          }
       }
       catch (...)
100    {
          vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
             << "Caught an unknown exception!\n" << vprDEBUG_FLUSH;
       }
    
105    vprDEBUG(vprDBG_ALL, vprDBG_CRITICAL_LVL)
          << "Exiting\n" << vprDEBUG_FLUSH;
    
       return 0;
    }

	After the COBRA Manager has been initialized successfully, the Tweek Subject Manager must be created. We do this by invoking the method tweek::CorbaManager::createSubjectManager() on our tweek::CorbaManager instance.
	Once we have a valid Subject Manager, we must register subjects with it in order for object references to be passed out by CORBA. This creates the servant to which mymod::CustomSubject references will be made.
	Once the servant is created, it is registered with the Subject Manager. The Subject Manager will activate the servant within the POA so that references to it can be created and returned to clients. We register it with the symbolic name “CustomSubject” that can be referenced later by remote objects.
	After the subject is registered, all the work is done. This simple application now just waits for clients to request references. It will exit when the user enters 'x'.

Note that all the code relating to the Subject Manager is enclosed within another try/catch block. This block only catches exceptions of type CORBA::Exception. Anything more general is caught by the larger try/catch block.

The GUI Library contains the heart of the Tweek Java GUI. Indeed, this library is what contains the Tweek Java GUI, and it makes use of all the other Tweek Java libraries to do its job. In general, there is not much code in this library that is of interest to Bean developers. The lone exception is the singleton org.vrjuggler.tweek.gui.MessagePanel. This class provides access to the message panel at the bottom of the Tweek Java GUI layout. Tweek Bean authors can make use of this singleton to post messages to that panel for users of the Tweek GUI to see. In most cases, this should be the preferred method of printing status messages rather than using System.out.print*() or System.err.print*() simply because users of the GUI may not have easy access to the console to see the messages printed there. The GUI Library is found in $TWEEK_BASE_DIR/share/tweek/java/Tweek.jar.

The Bean Library is provided to help simplify the process of loading and managing JavaBeans. The internal handling of JavaBeans performed by the Tweek Java GUI uses classes in this library to communicate with other objects when Beans are loaded, instantiated, removed, etc. The Bean Library is found in $TWEEK_BASE_DIR/share/tweek/java/TweekBeans.jar.

The Event Library is used by the GUI Library (i.e., by the Tweek Java GUI) to inform Panel Beans about GUI events. This includes events such as GUI iconification, GUI closing, and the gaining and losing of focus by the GUI. The Event Library is found in $TWEEK_BASE_DIR/share/tweek/java/TweekEvents.jar.

An interesting part of the Event Library is the Event Listener Registry. Historically, the Tweek Java GUI has performed automatic, run-time registration of Beans as event listeners based on the interface(s) that the Beans implement. That is not always convenient, however. For example, a Panel Bean author may want to use utility classes as event listeners rather than the Panel Bean itself. In this case, the utility classes can be registered manually with the Tweek Java GUI using the Event Listener Registry.

The Network Library abstracts the use of CORBA by the Tweek Java GUI^[2]. It includes the CORBA Service class that handles all ORB and remote reference management, and it has all the Java classes generated by the IDL-to-Java compiler when the Tweek Java API was compiled. Beyond this, it includes the event listener interface for Tweek Beans that wish to be notified of network connection and disconnection events. The Network Library is found in $TWEEK_BASE_DIR/share/tweek/java/TweekNet.jar.

The Bean Delivery Library makes use of the Bean Library and the Network Library to allow JavaBeans to be transferred across the network. More specifically, a remote subject, most likely written in C++, can “push” JavaBeans to the Tweek GUI where they can be handled as though they were loaded from the local disk. The Bean Delivery Library is found in $TWEEK_BASE_DIR/share/tweek/java/TweekEventDelivery.jar.

In this example, we explain how to develop a simple Tweek interface. The goal is to have a “collaborative” slider in a Java GUI component. The value displayed by the slider is retained by a C++ application so that multiple independent sliders can show the same value. The steps explained here are highly representative of the normal steps to be followed when using the Tweek Java and C++ APIs. The structure of the following sections lays out the order of the steps taken. An example makefile that goes along with the code presented can be found in the section called “SliderSubject” of Appendix A, Compiling Example Code. The full source for the examples presented in this section can be found in $TWEEK_BASE_DIR/share/test/NetworkTestBean.

The Subject

To begin, the subject interface must be defined in IDL and implemented in C++. The interface itself will be “compiled” into Java and C++ code. Both ends of the communication channels must know the interface in order for the references to be used, thus requiring the generation of code for both languages.

Creating the Interface

Creating an IDL interface involves writing an IDL file. For this example, we will be storing an integer variable in a C++ servant. The Java GUIs will need to read and write the value, so we need two methods: getValue() and setValue(). The type being passed between ORBs will be long, a 32-bit integer. Depending on the target language, this will map to the corresponding type of the same size.

Example 6.1. SliderSubject.idl

  1 #ifndef _NETWORK_TEST_SLIDER_SUBJECT_IDL_    
    #define _NETWORK_TEST_SLIDER_SUBJECT_IDL_    
    
    #include <tweek/idl/Subject.idl>             
  5 
    module networktest                           
    {
       interface SliderSubject : tweek::Subject  
       {
 10       void setValue(in long val);            
          long getValue();                       
       };
    };
    
 15 #endif                                       
    

	IDL files are run through the C preprocessor so that they may include external files. To prevent including the same source multiple times, the file must be enclosed in the traditional preprocessor protection block. This is exactly what is done in C/C++ header files.
	All Tweek subject IDL files must include tweek/idl/Subject.idl. This is required so that the interface being defined can inherit from tweek::Subject.
	Typically, using a module to contain the interface is recommended. Using a module defines a Java package and a C++ namespace (named networktest in this case).
	The definition of the subject interface must inherit from tweek::Subject. If this is not done, there is no way that the subject interface will plug into the Subject Manager.
	This simple interface has only two functions: setValue() and getValue(). The method getValue() takes a single read-only parameter of type long; getValue() returns a value of the same type.

The file SliderSubject.idl must be “compiled” by an IDL compiler. For use with Tweek, the interface must be compiled into Java and C++ code. The generated Java code will be used solely for communicating with CORBA networktest.SliderSubject references. The generated C++ code will be extended to provide an implementation of the networktest::SliderSubject interface. (The implementation will be a CORBA servant object to which references will be made by remote Java code.)

Implementing the Interface in C++

After running an IDL compiler to generate the stub CORBA code, the interface must be implemented. In particular, there will be pure virtual methods in SliderSubject.h that must be implemented. The implementing class will be the CORBA servant holding the actual data visualized in the Java GUI slider.

Example 6.2. SliderSubjectImpl.h

  1 #ifndef _SLIDER_SUBJECT_IMPL_H_
    #define _SLIDER_SUBJECT_IMPL_H_
    
    #include <tweek/tweekConfig.h>
  5 
    #include <vector>
    
    #include <tweek/CORBA/SubjectImpl.h>                           
    #include <SliderSubject.h>                                     
 10 
    namespace networktest                                          
    {
    
    /**
 15  * This class is an extension to the base Tweek SubjectImpl class.
     * It uses multiple inheritance with that class and with the
     * generated CORBA class corresponding to the IDL for
     * SliderSubject.
     */
 20 class SliderSubjectImpl
        : public POA_networktest::SliderSubject                    
        , public tweek::SubjectImpl
    {
    public:
 25    SliderSubjectImpl()
          : tweek::SubjectImpl(), mValue(0)
       {
          /* Do nothing. */ ;
       }
 30 
       virtual ~SliderSubjectImpl()
       {
          /* Do nothing. */ ;
       }
 35 
       /**
        * Sets this subject's internal value.
        */
       virtual void setValue(long value);                          
 40 
       /**
        * Returns this subject's internal value.
        */
       virtual long getValue();                                    
 45 
       /**
        * This overriding method is needed so that the correct type
        * is returned when the _this() method is invoked.  Without
        * this method, an object of type tweek::Subject_ptr would
 50     * be returned.
        *
        * XXX: It may be possible to remove this requirement in
        * the future.
        */  
 55    networktest::SliderSubject_ptr _this()                      
       {
          return POA_networktest::SliderSubject::_this();
       }
    
 60 private:
       long mValue;   /**< Our value */                            
    };
    
    } // End of networktest namespace
 65 
    
    #endif /* _SLIDER_SUBJECT_IMPL_H_ */

	These files will always be included by implementations of Tweek subject derived classes. The first contains the declaration for the basic Tweek subject implementation. The second contains the C++ code generated from the Tweek Observer.idl file.
	This header is generated by the IDL compiler from SliderSubject.idl. In particular, it defines the class from which networktest::SliderSubjectImpl must inherit.
	In SliderSubject.idl, shown in Example 6.1, “SliderSubject.idl”, the interface is in the networktest module. In the C++ implementation code, the module name corresponds to a namespace.
	The interface implementation class must inherit from the IDL-generated class POA_networktest::SliderSubject and from tweek::SubjectImpl.
	POA_networktest::SliderSubject defines two pure virtual methods that must be implemented. These correspond to the methods in SliderSubject.idl.
	As of this writing, all subject implementations must contain an overriding version of the _this() method. This is due to the use of multiple inheritance. Note the return type and the return statement. These will vary for each subject implementation based on the name of the IDL-defined interface.
	This is the actual value being stored by the C++ servant.

In SliderSubjectImpl.h, the most important parts to note are the use of multiple inheritance, the declarations of the SliderSubject interface methods, and the implementation of _this(). The implementations of setValue() and getValue() are shown next in Example 6.3, “SliderSubjectImpl.cpp”.

Example 6.3. SliderSubjectImpl.cpp

  1 #include <vpr/Util/Debug.h>
    #include <SliderSubjectImpl.h>                   
    
    namespace networktest
  5 {
    
    void SliderSubjectImpl::setValue(long value)
    {
       mValue = value;                               
 10 
       // Notify any observers that our value has changed.  This is very
       // important.
       tweek::SubjectImpl::notify();                 
    }
 15 
    long SliderSubjectImpl::getValue()
    {
       return mValue;                                
    }
 20 
    } // End networktest namespace

	Include the class declaration file, shown in Example 6.2, “SliderSubjectImpl.h”.
	When invoked, the remote caller will pass a long value, and this saves the result into the servant's storage.
	Because the subject's state has been modified, all attached observers must be notified. This is a very important step that must be taken in this method. Note that it invokes the notify() method of the parent class.
	Observers will invoke this method when requesting the current mValue.

The Observer

The observer does not define its own specialized IDL interface. Instead, it makes use of the existing Tweek basic observer (tweek.ObserverPOA in Java). The method update() must be implemented. The remainder of the observer implementation is centered around communication with a SliderSubject object reference. All observer code is written in Java. The only C++ code for observers is part of the Tweek library, and it is generated entirely by the IDL compiler.

Implementing the Observer in Java

For every subject interface defined in IDL, a corresponding observer class must be written in Java. Without an observer, there is no way for the Java and C++ sides to conduct useful two-way communication. At best, the Java GUI could request a subject reference and manipulate the C++ application through the reference, but the communication would be entirely one-way.

In Example 6.4, “SliderObserverImpl.java”, we show the complete Java implementation of an observer corresponding to the tweek::SliderSubject interface defined earlier. (The JavaBean that uses this observer is explained in the section called “The JavaBean”.) The main focus of this observer is to update its contained JSlider whenever the state of the corresponding subject changes.

Example 6.4. SliderObserverImpl.java

  1 package networktest;
    
    import javax.swing.DefaultBoundedRangeModel;
    import javax.swing.JSlider;
  5 import tweek.*;
    
    /**
     * Implementation of the Observer side of the Tweek
     * Subject/Observer pattern.  It must extend tweek.ObserverPOA
 10  * so that instances of this class can be registered as CORBA
     * servants.  In addition, CORBA references to the servants must
     * be capable of being attached to remote subjects.
     */
    public class SliderObserverImpl extends ObserverPOA            
 15 {
       public SliderObserverImpl(JSlider slider,                   
                                 SliderSubject subject)
       {
          mSlider        = slider;
 20       mSliderSubject = subject;
       }
    
       /**
        * Implements the required method in tweek.ObserverPOA.  The
 25     * remote subject will invoke this method whenever it is
        * notified of a change.
        */
       public void update()                                        
       {
 30       // If we have a valid slider object, we need to update
          // its value to whatever our subject has.
          if ( mSlider != null )
          {
             DefaultBoundedRangeModel model =
 35             (DefaultBoundedRangeModel) mSlider.getModel();
             model.setValue(mSliderSubject.getValue());            
             mSlider.repaint();
          }
       }
 40 
       /**
        * Detaches this observer from our subject.  This is needed
        * when shutting down a CORBA connection.
        */
 45    public void detach()
       {
          mSliderSubject.detach(this._this());                     
       }
    
 50    private SliderSubject mSliderSubject = null;
       private JSlider       mSlider        = null;
    }

	As an observer, this class must derive from tweek.ObserverPOA. This class is generated by the IDL compiler and is part of the Tweek Network Library (see the section called “Network Library”).
	The constructor for this observer takes two arguments: a JSlider object reference and a networktest.SliderSubject object reference. The observer needs the latter argument so that it can query state information from the subject when notified of state changes. This is part of the subject/observer design pattern [Gam95].
	As stated, all observers must implement