Home Help Center

ICE and Systems Architecture

I've been testing out ICE for RPC and the results have been pretty promising, but I've only tested a simple client/server architecture. For something more distributed, I have some questions as I'm not quite sure how to do such a system with ICE.

If I had multiple, somewhat loosely coupled, server programs/workers and I'd like to present them to client programs with a unified interface/endpoint I would think I would use a broker program in the middle. Maybe something like this 7/MDP - Majordomo Protocol - 0MQ Requests for Comments. Would ICE be a good fit for a system like this? If so, how would you go about this? Would I pass a proxy of each worker service to the client via the broker, or could I use the broker to route requests/responses back and forth?

Furthermore, I noticed that some ICE services, like ICE Grid and Glacier2, are actually executable programs. Would it be easy to automate the setup/installation of these if I wanted the install of the system to be done by clients?

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    I'm not very familiar with this MDP broker service. Typically, Ice distributed application either implement their own custom broker service or use the IceGrid allocation mechanism. I suppose if you were using this broker, you could indeed have the worker pass a proxy to one of its Ice object to the client so that the 2 can communicate with each other using Ice.

    Ice services such as IceGrid and Glacier2 are typically hosted on the "server" side, they aren't required to be installed on "client" systems. If your application would require installing those services on the server backends of a customer, I would recommend to use the OS provided mechanisms to package softwares (MSI, RPMs, etc). If using IceGrid, typically the IceGrid registry and nodes are installed as system services. Glacier2, IceStorm and servers providing services to clients are then managed by IceGrid.

    Cheers,
    Benoit.
  • ezarownyezarowny Member
    I should probably clarify some aspects of this. I don't seem to be able to edit a post though, so I will write my explanations here.

    MDP is just a pattern to be implemented; although there are implementations of it. MDP seemed like a good way to present an interface to multiple loosely-coupled programs.

    Both the server and client programs would be installed at a customer's network. The client programs would probably be just a web interface for the server programs. I should have said customer instead of client for the last time I wrote client.

    When making your own broker service how do you handle routing the correct response back to the correct client? Normally I would attach a random number as a request/response ID in the message payload but I'm not sure how to identify the client with ICE.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    First, is routing through the broker necessary? The broker could just be there to help finding an active server that can serve client's requests. Once this server is found, the client could talk directly to the server and no routing would be necessary.

    If routing is indeed necessary, there are several options. One of them could be to use the Ice::Router interface which is used by Glacier2. Other options could be to do some routing based on some extra information in the Ice context.

    You would need to provide more information on the architecture of your distributed application if you want some guidance on this.

    Cheers,
    Benoit.
Sign In or Register to comment.