ICE Architectural Semantics

[titus]

As a new ICE user I have run into the following problem (or perhaps
misunderstanding). Yes, I have pursued this on the Help Center forum.

Page 255 of the documentation, under 'Using Ice::Application on the
Client Side', says, "place the client code into its run method". It says
something similar on page 254 about the server side.

This, however, forces the user application to exist as a component of the
Ice client (or server). The more intuitive structure is one in which ICE is
a component of the user application. Not that this cannot be accomplished,
but it obviates the use of Ice::Application, which is a powerful tool. Not
using Ice::Application means, as the documentation points out, having to
supply all of the initialization and signal handling code on one's own.

Consider the situation in which two (or more) user applications, call them
XYZ and ABC, need to act as both client and server. One cannot place the
code for XYZ as client into the run method of Ice::Application and also
place the code for XYZ as server into the appropriate server run method;
all of this while doing exactly the same thing for ABC!

It makes, it seems to me, no architectural sense to make any large, complex
user application subordinate to the runtime thread of the Ice::Application
run method. One would not make a game subordinate to its GUI.

Is there no way out of this quandry other than objectifying the ICE client
(or server) and including it as a component in the Application, supplying
Ice::Application functionality manually?


Titus sends

[xdm]

Hi Titus

From Ice point of view a client is a program that make a request and a server a progran that gives a response. A simple Ice server can act as a client with out extends Ice::Application. This is a common escenario in Ice world.

For example you have a FileService that use IceStorm for send events to clients. It act as a server for write read files but has the client roll when publish events in IceStorm. The service only need a Proxy to and IceStorm form publish an envent (Act as a client). Other case in my file service is the search engine. I have a SearchEngine service separate from the FileService. and a Crawler that loacate FilesToIndex in FileService and send it to SearchEngine. i run this crawler in a dedicated Thread that i create inside FileService::start

Note that any ice server can act as a client with out extra needs. When you create a proxy to other service and make a request you are an Ice Client.

As you say the advantages of use Ice::Application on client side are the inicializtion/shutdown of Ice , the Properties mechanism, and Signal Handling. I don't see any limitation in this architecture.

From my experience with Ice Ice::Application is easy to extend for any real client application needs, event when client act as a server same times.

In the other hand you can make your own application but you must need rewrite more of things Ice::Application allready provide, like Signal Handling that is not Ice Specific but needed.

Hope this help

[beagles]

Ice::Application is a convenience helper class that obviates the boiler-plate code required to initialize the Ice communicator. It is intended to simplify things for what we felt were the most common use cases, but you certainly do not have to use it. The steps required to initialize the communicator are initially described in chapter 3 of the Ice manual - "A Hello World Application". The steps are also very likely described elsewhere, as well.

[marc]

Note that since you have access to the source code of Ice::Application, you can also make your own copy (with cut&paste), rename it, and modify it in any way you wish.