Program Architecture

titustitus Member Titus PurdinOrganization: University of ArizonaProject: Large Binocular Telescope
What I am looking for is information concerning program (project)
structure. The simple examples that I have taken from the documentation
leave the flow of control trapped inside the ICE main module. This is
even even more true of examples using Ice::Application. The flow of
control appears to be trapped inside the 'run()' method.

I'm sure this isn't really the case. I'm sure it is my lack of experience with
Ice. Leaving Ice::Application aside, I have been able to create an 'IceClient'
object/instance and call and create a proxy in an 'init' method in that
instance. I have even been able to export that proxy and use it from
within an external module. But I really would be more comfortable if I
understood this much better.

In the words of Ralph Griswold, "The documentation is great, if you already
know what you are looking for."


Titus sends

Comments

  • stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG ✭✭✭
    Hi Titus,

    I'm afraid that your question is a bit generic. A proper architecture/ project structure heavily depends on what you want to do and what you use. For example:
    * are you aiming to a client-server-application?
    * if so, what language(s) do you use on the server side? What language(s) do you use on the client side?
    * what kind of interface will you provide (fat client, thin client, cli), i.e. what kind of interactivity will you provide?
    * what frameworks will you use?
    * do you have persistent data that needs to be mapped to Ice objects, if so, are they mapped directly or is there only a loose interdependency between persistence layer and the integration layer (Ice layer)?

    To name only a few of the questions.

    cheers,

    Stephan
  • titustitus Member Titus PurdinOrganization: University of ArizonaProject: Large Binocular Telescope
    So right....

    You are *so* right! It is vague. I'll take a shot at being more specific.
    But we are just beginning to delve into Ice. The answers to some of
    these questions aren't clear to me yet.

    We have a number of 'subsystems'. Think of them as applications. They
    need to communicate with each other. They currently sit on top of a
    'home rown' RPC facility, which is showing its age and its casual design.
    We would like to consider replacing that 'common software' level with
    and Ice implementation.

    At the moment, I am only looking at a basic RPC functionality. The XYZ
    subsystem (app) needs to say to the ABC subsystem, "open the enclosure
    doors" or "move mirror actuator number 719 in a +.017mm direction".
    This is to say that we intend to build a separate system for data requests,
    such as, "what is the temperature in the enclosure?" or "what is the current
    azmuth of the telescope".

    All of our existing code, for purposes of this discussion, is written in
    C++.

    I have a pdf depicting my (vague) idea of how it works. I am trying to
    figure out how to up load an attachment. I think I managed. Let me
    know.

    And, hey, thanks for the help.

    Titus sends
  • stephanstephan Member Stephan StapelOrganization: Stephan StapelProject: BristolNG ✭✭✭
    Thanks for the explanation.
    So from the Ice viewpoint (leaving the 'Server' out as it doesn't interoperate using Ice), you have some kind of peer-to-peer architecture?

    I basically like the layered approach, trying to minimize the influence of the Ice implementation to your own application. In case you like refactoring, it might even work to introduce such a layer to your legacy applications while still using the old RPC mechanism and then replace this layer using Ice. But clear separation into layers with refactoring might also be quite hard.

    Also I suggest to use AMI wherever possible to minimize cascaded delays such. This topic was briefly covered in some Connection articles.

    For easy lookup and looser coupling (sorry for using this term at all), using IceGrid Registry is generally a good idea and not too difficult to implement.

    Concerning the project layout, it might be a good idea to have a central /interfaces directory containing all .ice files for the entire application as well as the slice-d c++ files. If you compile all these files into a single static library, it's quite easy to link it into your application. I guess this is more or less obvious.

    Are these explanations of any help?

    cheers,

    Stephan
  • titustitus Member Titus PurdinOrganization: University of ArizonaProject: Large Binocular Telescope
    What am I missing?....

    In section 8.3.1 of the ICE documentation, on page 255, under the title
    "Using Ice::Application on the Client Side", is says, "and place the client
    code into its run() method."

    I do not want to cram an entire (legacy) application into the run() method
    of an ICE object. I want the ICE object to provide a service(s) to the appli-
    cation. But the run() method is called automatically from the (Ice::Application)
    main() routine.

    My missing connection is "how do I (syntactically) subordinate the Ice client
    to my application code, particularly in the presence of Ice::Application?

    Thanks.

    Titus sends
  • xdmxdm La Coruña, SpainAdministrators, ZeroC Staff Jose Gutierrez de la ConchaOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hello Titus

    what problem you see whith the run method.?
    AFAIK the run method is the entry point of your application when you use Ice::Application. you can structure your client application as you want.

    This code is the run method of a class that extends Ice:Application. (this create a basic Qt application)
    int Oz::Ui::HydraApp::run(int argc,char** argv){
        QApplication app(argc, argv);
        int status = EXIT_SUCCESS;
        try{
            createFactory();
            QMainWindow* mainWindow = createMainWindow();
            app.connect(&app,SIGNAL(lastWindowClosed()),&app,SLOT(quit()));
            _appController = new HydraAppController(mainWindow);
            mainWindow->show();
            status = app.exec();
        }catch(const Ice::Exception& ice_e){
            std::ostringstream os;
            os << ice_e;
            QMessageBox::warning(0, "Error", os.str().c_str());
            status = EXIT_FAILURE;
        }
        return status;
    }
    
  • titustitus Member Titus PurdinOrganization: University of ArizonaProject: Large Binocular Telescope
    Good answer...

    That is a good answer, but it is backward from what I wish to do.

    You say (forgive my pseudocode):

    class ICE {
    ......
    run() {
    MyApp myapp;

    myapp.exec();
    }
    }

    What I really want to see is the ICE Client as a component of the APP.

    I say (again forgive the brief code outline):

    class ICE {
    init() {
    ......
    }
    proxy exec() {
    get a proxy;
    return a proxy;
    }
    }


    class MyApp {
    ICE IceInstance;

    ICE.init();
    ICE.proxy = ICE.exec();
    }

    I know that there are good things about both of these approaches. I
    have actually made my approach work---as long as I don't use
    Ice::Application. Thanks for your help. I am new to ICE and sometimes
    frustrated with it. Oops sorry. I notice that the editor took out all of the
    spaces that I put into the code snippits.


    Tit us sends
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Note that you don't have to use Ice::Application if you don't like that you have to derive from it to implement run(). Ice::Application is simply a convenience class. Have a look at the Ice manual or at demo/Ice/minimal for examples on how to write your application without using Ice::Application.
Sign In or Register to comment.