IceStorm Just the Basics

phil++

Hello!

I am new to Ice and would like to ask some basic questions about IceStorm. The IceStorm producer/subscriber model is exactly what I am looking for a sampling application I am investigating.

1) Is the natural implementation model of an IceStorm service "one shared library for each service"? Can a single .so implement several services?

2) Can a producer be configured, or programmed, not to run if there are no subscribers? I don't want to sample data on the server if no one is interested.

3) If I want to produce topic messages (sample data) at different rates for different subscribers, must I create (simplistically) a "fast" topic and a "slow" topic?

4) Is it possible for a client to create a server-side object instance and then have that instance run as an IceStorm service? Suppose I want fine, client-side control of what the server producer actually does?

Phil

matthew

1) Is the natural implementation model of an IceStorm service "one shared library for each service"? Can a single .so implement several services?

The IceStorm service is is placed in single shared library which is then hosted by an IceBox container. If you yourself write IceBox services then you can bundle them however you like. I don't see a particular advantage, however, in putting more than one service in a single shared library. I do see lots of disadvantages tho.

2) Can a producer be configured, or programmed, not to run if there are no subscribers? I don't want to sample data on the server if no one is interested.

This is not possible. Suppliers are entirely decoupled from producers and one is not aware of the other.

3) If I want to produce topic messages (sample data) at different rates for different subscribers, must I create (simplistically) a "fast" topic and a "slow" topic?

That is one way. Another solution is for the slow subscriber to discard events. A better solution is event filtering which IceStorm does not yet support.

4) Is it possible for a client to create a server-side object instance and then have that instance run as an IceStorm service? Suppose I want fine, client-side control of what the server producer actually does?

I don't understand what you mean by "IceStorm service", nor "server producer" here.

IceStorm service to me means a implementation of the IceStorm interface bundled as a shared library suitable for hosting with IceBox.

In general a client and server are roles that applications play in a distributed object system. A client calls on a server, and a server receives invocations made a client. Your applications can be a pure client (that is make only invocations upon servers), a pure server (that is only receive invocations from clients), or both (both make and receive applications). Most non-trivial applications are both clients & servers.

I hope that helps! If I didn't answer your questions please clarify what you mean

phil++

Thanks for your response. Sorry, my use of Ice nomenclature isn't quite accurate yet since I'm just getting started. I would like to clarify what I meant to ask with regards to questions 1 and 4 above.

When I said "IceStorm service" I really meant to refer to a _publisher_, i.e. an object that interacts with subscribers via IceStorm. So, for question 1, I meant to ask about how to package _publishers_. I note in the demos for IceStorm, the publishers are all executables. If, for example, I wish to "publish" 3 topics, which are related to each other, would I create three, independent executables, or would I create three shared libraries, or can I bundle the three topics together into one executable or shared library?

For question 4, I meant to describe a situation in which the client creates and starts the publisher as an initial step. The publisher then interacts with IceStorm normally and the client can then subscribe to its topic(s).

For example, initially there is no weather publisher running on the server. I want the client to create a weather publisher that will monitor the weather in Toronto and report every 30 minutes (i.e. create weather object, parameters 'Toronto' and 30). Upon successful creation of said publisher, the client can subscribe to its topic and begin receiving weather updates for the parameters specified. Hope that's clearer.

xdm

question 4)

1) define a WeatherServer interface in slice that's permits you mage the WheatherMonitors. define a WheatherObserver interfaz in slice that has and operation for each event you what to send.

/**
  * The data we send about weather
  **/

class WeatherInfo{
  long timestampt;
  int temperature;
  int humidity;
  int coLevel;
  //More data we send here
};


/**
  * The data we store about each monitor.
  **/
class WeatherMonitorData{
     Ice::Identity id;
     bool started;
     int frequency;
     string city;
};
sequence<WeatherMonitorData> WeatherMonitorDataSeq;


/**
 * Interface for manage Wheather Monitors
 **/
 interface IWeatherMonitor{
         void start();
         void stop();
         void setFrequency(int mseconds);
         void setCity(string cityCode);
         WeatherMonitorData getData();
 };

interface IWeatherObserver{
        /**
          * When a monitor is configured to run call this method in is IceStorm::Topic
           **/ 
        void sendWeatherInfo(WeatherInfo info);
};

 interface IWeatherServer{
        /**
          * Create monitor with same parameters 
          **/
         IWeatherMonitor* createWeatherMonitor(int frequency,string city);
        /**
          * Remove a monitor
          **/
         void removeWeatherMonitor(Ice::Identity id);
       /**
         * Search monitors in your server with same params
          **/
       WeatherMonitorDataSeq searchWeatherMonitors(Ice::StringSeq cities,int limit,int offset);
 };

2) implement the WeatherServer.
when you call createMonitor on server create a new servant that implements IWeatherMonitor in it's implementation programatic create a new IceStormTopic using the IceStorm::TopicManager interface.

You must want use a default servant locator for manage your servants - Read about this in Ice Handbook chapter 32-7 , or maybe Freeze::Evictor is better for your use case.

Create a new topic for your WeatherMonitor. Topic name must be unique, you can use de id.name attribute for this.

        try{
            topicPx = _topicManager->create(id.name);
        }catch(const Ice::Exception& ice_e){
            std::cerr<<"file "<<__FILE__<<" line "<<__LINE__<<" "<<ice_e<<std::endl;
        }

3) send the weather info to IceStorm subscrivers

    Ice::ObjectPrx obj = topicPx->getPublisher();
    if(!obj->ice_isDatagram()){
        obj = obj->ice_oneway();
    }
    IWeatherObserverPrx publishers = IWeatherObserverPrx::uncheckedCast(obj);
    publishers->sendWeatherInfo(theWeatherInfo);

4) Your clients can use the search function for view available monitors and then subscribe to IceStorm.

Hope this help

phil++

Yes, that is the idea!

Create a servant that also implements a publisher interface to IceStorm. It might also be desirable to create easy-to-search topics, such as:

"weather-toronto-30"

so that clients can find running publishers with minimal effort.

I can see some potential problems also, such as:

creation of redundant servants
destruction of servants that currently have active subscribers
etc.

At least it is conceptually possible, which answers my question.

Thanks.

matthew

Generally its better if you can hide the details of how you use IceStorm from both the publisher and subscriber. What xdm suggested looks good! You can also check out the chat series of articles in the Connections newsletter and you might also want to look counter demo (demo/IceStorm/counter).