IceStorm and model view controller pattern

xdm

Hello

I trying to implement the model view controller pattern using IceStorm to deliver messages or events fron model objects to client views. in oder to do it I add a new interface to my base object derived from Ice::Object, create and Event class to emcapsulate events that are send and create a listener inteface that must be implemented or agreate by View objects the definitios as are follow

           module Oz
           {
              module Base
              {
                 class Event
                  {
                          // the id of the object that send the event
                          Ice::Identity objectId;
                          // a name used for diference events
                          string name; 
                  };
                  inteface EventPublisher
                  {
                         void eMit(Oz::Base::Event e);
                  };
                  
                  interface EventListener
                  {
                       // this operation create a Ices::Storm subcriber 
                       // for topic named objectId.name
                       idempotent void suscribe(Ice::Identity objectId);

                       // this operation unsuscribe object 
                       // for topic objectId.name
                       idempotent void unsuscribe(Ice::Identity objectId);
                       
                       // this opeartion is the contract betwen publisher 
                       // and subscriber object
                       idempotent void notify(Event e);
                   };
               };
            };

my problem is that i need a diferent topic for each object and this topics must be created on demand with object creation like topics are not persistent and objects are persistents. I think to diferents ways to manage this situation are

1) try to retrive a topic in objectInitializer and if topic not exist creating it the code can be as folow

void 
Oz::Base::ObjectInitializer::initializer(
       const Ice::ObjectAdapterPtr&,
       const Ice::Identity& objId,
       const std::string& ,
       const Ice::ObjectPtr& obj)
{

         /** heare I initilize topic manager code not show for simplicy **/
        try
        {
          obj->topic=topicManagerPx->retrieve(obj->getId().name);
        }
        catch(const IceStorm::NoSuchTopic& ex)
        {
                  obj->topic=topicManagerPx->create(obj->getId().name);
        }
}

2) can be a better aproach to do it this in the eMit operation if ObjectNoExistException is throw whe try to a call an operation on topic object

               void Oz::Base::eMit(Oz::Base::Event e)
                {
                           try
                           {
                                topic->notify(e);
                           }
                           catch(ObjectNoExistException& e)
                           {
                                  /*retrive topic manager code not show*/
                                 topic=topicManagerPx->create(id.name);
                                 topic->notify(e);
                           }
                }

In the client side i create a subscriber Proxy for each view and sucribe it to the correspoding model proxy.

My subscriber implementation can hold a pointer to the view object a when notifiy
operation is invoked in the subscriber in dispach the envet to the view.



can you say me if this a correct usage for IceStorm service?

what aproach can be better to ensure that s exist a topic for each object, or
any sugestion for do it in a diferent way?


In other to subscribe objects be accessible by IceStorm service is neceary configuring Glacier or Glacier2 are both valid?

it is posible to adquire topic manager via IcePack::Query i think yes but i'm not sure.

Thanks in advantage

benoit

xdm wrote:

Hello

my problem is that i need a diferent topic for each object and this topics must be created on demand with object creation like topics are not persistent and objects are persistents. I think to diferents ways to manage this situation are

Actually, topics are persistent, see section 41.3.6 of the Ice manual. Once created, the IceStorm topics will persist until you destroy them.

xdm wrote:

In the client side i create a subscriber Proxy for each view and sucribe it to the correspoding model proxy.

My subscriber implementation can hold a pointer to the view object a when notifiy
operation is invoked in the subscriber in dispach the envet to the view.

can you say me if this a correct usage for IceStorm service?

This sounds fine.

xdm wrote:

In other to subscribe objects be accessible by IceStorm service is neceary configuring Glacier or Glacier2 are both valid?

I'm not sure I understand the question, can you detail what you're trying to do here with Glacier?

xdm wrote:

it is posible to adquire topic manager via IcePack::Query i think yes but i'm not sure.

Yes, you can register the topic manager with the IcePack registry in order to access it with the IcePack::Query interface. You can either register it manually with the IcePack::Admin interface or the icepackadmin utility, or you can use the IcePack deployment mechanism to deploy your IceStorm service.

Hope this helps!

Benoit.

xdm

Hi beniot thanks for your replys

in realation to Glacier i want to say that if is posible thats IceStorm invoke topic notificatios in a client throw a glacier or glacier2 router.


for example how can i do to have a server runing IceStorm in a private network dispaching topic notificatios to a client in other private network


I think that i need configure a router in server runing IceStorm in order to clients can reach IceStorm. But I don't now what i must do in order to IceStorm can reach subscribers and scenarios is more complicated if each subscriber is in a diferent private network. How can i handle this?

thanks for all

benoit

You will need to deploy a Glacier router and modify your client to create a session with this Glacier router. You can take a look at the demo/Glacier2/callback demo to see how to modify your client to use Glacier.

Basically, your client will create the IceStorm subscriber object (like the CallbackReceiver object in the demo) and pass its proxy to the IceStorm topic through the session. When IceStorm will invoke on your subscriber, the invocations will be routed to your client transparently through the router.

If you have several private networks connected to the network where IceStorm is deployed, you'll need a Glacier router for each of these private networks.

Benoit.