icepack registry redundancy

gminorcoles

Hi,
Is it possible to run the icepack registry on more than one machine? I am concerned that having it run only on one host exposes my app to a single point of failure, as they say.

thx
George Coles

benoit

Hi,

Sorry, it's currently not possible to run the registry on multiple machines. Implementing a replicated registry is feasible but would be a bit of work. If you have any commercial interest in such a feature, please contact us at info@zeroc.com.

Benoit.

gminorcoles

Benoit,
Thanks for the response. In the past I have used Java's JINI and JavaSpaces technology, and it has some features that I think would be pretty good to have in IcePack or IceGrid, which if I am not mistaken, is the successor to IcePack?

JINI has a concept of a lookup service, and groups. A service can have attributes as well as group membership, and the lookup service can be queried by attribute, or by type, or by group (I think this is right.)

Lookup services can be reached by direct binding or you can find a lookup service via multicast IP, so you get the ability to create a federation of lookup services in many different topographical layouts. A service can register itself with a specific lookup service, or, again, multicast can be used to announce it's presence and "autojoin" the first lookup service that is found.

I apologize for imprecise and incomplete descriptions of these features of JINI, but there is a lot of information available. Artima.com is an example of a site that has a lot of Jini information. It is a good template for the types of features I think would be cool as ehancements to IcePack -- the icepack registry taking the place of the JINI lookup service.

thx
George Coles

benoit

Hi George,

gminorcoles wrote:

Benoit,
Thanks for the response. In the past I have used Java's JINI and JavaSpaces technology, and it has some features that I think would be pretty good to have in IcePack or IceGrid, which if I am not mistaken, is the successor to IcePack?

Yes, IceGrid will have most of the IcePack functionality and much more.

JINI has a concept of a lookup service, and groups. A service can have attributes as well as group membership, and the lookup service can be queried by attribute, or by type, or by group (I think this is right.)

Lookup services can be reached by direct binding or you can find a lookup service via multicast IP, so you get the ability to create a federation of lookup services in many different topographical layouts. A service can register itself with a specific lookup service, or, again, multicast can be used to announce it's presence and "autojoin" the first lookup service that is found.

I apologize for imprecise and incomplete descriptions of these features of JINI, but there is a lot of information available. Artima.com is an example of a site that has a lot of Jini information. It is a good template for the types of features I think would be cool as ehancements to IcePack -- the icepack registry taking the place of the JINI lookup service.

thx
George Coles

Thanks for the feedback and the link!

The IcePack registry lookup service is indeed quite simple right now. It was designed with simplicity in mind like the rest of Ice . So far, the lookup by identity and type appear to be the most useful lookups. An application typically retrieve a well known service by identity or type (typically a factory, manager or lookup service) and then use this object to access more of the application objects: the application specific lookup is implemented in the application itself.

We could certainly add more features to the lookup facilities provided by IcePack but we have to be carefull to keep it simple and useful for the majority of Ice applications. Anyway, thanks again for the feedback, I'll have a closer look at JINI!

Benoit.