CORBA 2.x Publish/Subscribe CORBA Stock Quoter Service (Assignment 2)

Overview

One way to avoid the problems with request/response polling is to employ a variant of the Publisher/Subscriber architectural pattern from POSA1. In this pattern, publishers generate events that are transmitted to one or more subscribers, who can then take further action depending on the events they receive and their internal state. The overall flow of information in our latest incarnation of the stock quoter system thus works as follows:

1. Stock broker clients subscribe with a stock distributor server to receive notification events whenever a stock value of interest to them changes.

2. The stock distributor server monitors a real-time stock feed database.

3. Whenever the value of a stock changes, the distributor publishes an event to interested stock brokers.

4. If stock brokers are interested in learning more details about a stock whose value has changed, they can invoke an operation on the stock distributor to receive more information.

CORBA IDL 2.x Specification

Step 1: Defining the Stock Quoter Interfaces using IDL 2.x Types. You will start by defining some interfaces and other types using IDL 2.x features. All of these types will be defined in a module called Stock, i.e.:

// IDL schema definition for Stock Quoter publisher/subscriber service.
module Stock
{
  exception Invalid_Stock {};
  // Feel free to add other exceptions as you see fit.

  // ...

	interface StockQuoter {
          StockInfo get_stock_info (in string stock_name) raises Invalid_Stock;
	};

       struct StockInfo {
         string name;
         long high;
         long low;
         long last;
         // ...
       };

The stock distributor itself runs as a daemon that can be started and stopped by a system administrator. The following Trigger interface instructs the stock distributor to perform these control operations:

	interface Trigger { 
          void start ();
          void stop ();
	}

Step 2: Defining the Stock Quoter Interfaces Using IDL 2.x Types. Now that we've illustrated the core IDL 2.x types in our stock quoter system, we'll show how they are combined together using IDL 2.x interfaces. We start with the valuetype data type that objects can use to communicate using CCM's publisher/subscriber event mechanism. Whenever a stock value changes, the stock distributor will publish the following valuetype containing the name of the stock:

valuetype StockName { 
  // Name of the stock.
  public string name; 
};

You will next write an interface implemented by the stock broker to handle callbacks from the stock distributor.

interface StockNameConsumer 
{
  // Push an event to the consumer.
  void push_StockName (in StockName the_stockname);
};

interface StockBroker
{
  // Factory operation to return StockNameConsumer object reference.
  StockNameConsumer get_consumer_notifier ();

  // Event sink operations to perform connectivity.
  void connect_quoter_info  (in StockQuoter c);
  StockQuoter disconnect_quoter_info ();
  StockQuoter get_connection_quoter_info ();
};

These connect_quoter_info(), disconnect_quoter_info(), and get_connection_quoter_info() operations are also used connect the StockBroker with the StockQuoter object that's provided by the StockDistributor interface describe next.

The StockDistributor object has the following IDL 2.x interface description:

interface StockDistributor : Trigger 
{
  // Event source operations to establish connectivity.
  Cookie subscribe_notifier (in Stock::StockNameConsumer c);
  Stock::StockNameConsumer unsubscribe_notifier (in Cookie ck);

  // Factory operation to return StockQuoter object reference.
  StockQuoter provide_quoter_info ();

  attribute long notification_rate;
};

Stock::StockNameConsumer_var consumer = stockBroker->get_consumer_notifier ();
stockDistributor->subscribe_notifier (consumer.in ());

Stock::StockQuoter_var quoter = stockDistributor->provide_quoter_info ();
stockBroker->connect_quoter_info (quoter.in ());

Step 3: Use IDL 2.x Features to Manage the Creation of Objects. Instances of the StockBroker and StockDistributor objects can be created at startup time via factories.

interface StockBrokerHome 
{
  StockBroker create ();
}; 
 
interface StockDistributorHome
{
  StockDistributor create ();
}; 

You will use the TAO CORBA IDL compiler to translate these IDL interfaces into stubs and skeletons. The stock distributor application (which you must write) will use the stubs as a proxy to publish StockNames the stock broker application(s). As discussed above, the brokers can call back to the distributor to get more info on the stocks. In addition, you must also write the factory interfaces that set everything in motion.

Step 4: Implement the Main Program. You'll need to implement a main() functions for stock distributors and stock brokers that will dynamically create the appropriate instances of the factories and bootstrap objects, obtains and activates the RootPOAs, and then calls CORBA::ORB::run() method to run the application event loops. To make your life easy, applications should write their IORs to a file before it calls the ORB's run() method (later, we'll use more advanced techniques, such as a Naming Service). Client applications should read the name of the file that contains the IOR discussed above. When the client starts up, it will read the contents of this file into a string and use the CORBA::string_to_object() method to convert the string into an object reference. This object reference will then be downcast via _narrow() to an object reference for the various factories operations.

For the purposes of the assignment, you can make the driver programs very simple, i.e., you can read commands from standard input and write replies to standard output. For example, you could type the following commands to the stock distributor

% ./distributor
> rate 1 second

% ./broker tango.dre.vanderbilt.edu
> subscribe "MSFT"
Current value of MSFT is $100
Current value of MSFT is $101
...

If anything fails to work properly the programs should simply print out the appropriate exception and exit with a return status of 1. If everything works correctly, the programs should exit with a return status of 0.

Learning and Using CORBA

Concluding Remarks

Back to CS 396 home page.