میان افزار جاوا سمفونی Java Symphony middleware

I. Documentation for the API programmer 1.) The Network Agent How to find a virtual architecture in a physical architecture? Look at the following physical architecture like created in the Shell: To create an easier to understand tree you have to remember that a node with level 3 can have children with level 2 and with level 3. So a node with level 3 is also a node with level 2 and a node with level 1. The following picture will show the example above: This representation of the tree is better to understand which virtual architectures can be found in the physically. A virtual architecture is a tree structure with working nodes only at the leafs. Look at the following example of a virtual architecture: This virtual architecture can be found in the physical architecture above, but there are more different solutions and without knowing the constraints of the nodes in the physical architecture the following solutions are possible:  V1 = N1; V2 = N2; V3 = N3  V1 = N4; V2 = N5; V3 = N2  V1 = N5; V2 = N1; V3 = N4  … there are many solutions but the following solutions are not possible:  V1 = N2; V2 = N3; V3 = N5  … The order of the nodes of the physical architecture is not important to find a virtual architecture. Only the structure to be found is important to exist in the physical architecture. The level of the root elements of the two architectures have not to be the same. The level of the physical architecture has to be higher or equal to the level of the virtual architecture. Remember the following virtual architecture can be found in the physical architecture above to: Solutions are:  V1 = N2; V2 = N3; V3 = N5  V1 = N3; V2 = N5; V3 = N2  … ۲٫) The JavaSymphony Shell JavaSymphony Shell is part of the JavaSymphony system. JS Shell is a graphical user interface designed to support the creation of a physical architecture consisting of connected JS Network Agents. This physical architecture is used by JS Applications to create virtual architectures and run distributed programs on them. If a JS application demands a virtual architecture, it will be mapped to a physical architecture that fulfils the needs of the application (see documentation for network agents for information how this is done). A physical architecture consists of nodes (Network Agents, NA’s). Nodes can be grouped under a cluster; clusters can be grouped under a site and so on (where clusters and sites are normal nodes that additionally have a cluster manager or a site manager. For being expansible, we decided to use level numbers instead of names for the hierarchy, so a node has level one, a cluster level two, a site level three and so on. The maximum level is nine. The following diagram shows a node of level three (a site) with three nodes of level two (clusters), that also have some nodes of level one under them. Remember that there are still eight network agents in this system (every higher level node has still the functionality of a normal node). Starting the JS Shell You can start the JS Shell by executing the batch file run_shell.bat in the programs main directory. This will start up the GUI and enable you to create a physical architecture. If you have already created a physical architecture and stored it in a file (see “Save Configuration”), you can use the JS Shell program to generate this stored architecture without starting the GUI by appending filename as a program argument: run_shell [filename] This will generate the architecture stored in the file, showing all information and errors as console output. The program will stop after generation. The Main Window The main window is divided into two parts. On the right side there is a list of available NA’s that can be added to a physical architecture on the left side. A NA is defined by the computer name (or IP) on witch the NA is running and the port on which the NA is listening ([computer_name]:[port]). At start-up, the default list stored in a file (serverlist.ini) will be loaded and displayed in the list window as well as the configuration stored in the file config.txt will be displayed as a tree in the left part. Of course you can load and store other lists and configuration files (see “Load Configuration”, “Load NA-List”). The List The list displays all NA’s that are currently available (marked with a green tick) as well as some other computers, where no NA is currently running on the specified port (marked with a red cross). NA’s, that are not marked could not be reached yet, they will be marked in a few seconds. You can add NA’s to the list, remove NA’s from the list and load and store lists of NA’s (see “Load NA-List). You can add an NA to the physical architecture on the left side by dragging and dropping it on the desired position in the architecture tree. The Tree The Tree window allows you to design a physical architecture consisting of NA’s. You can drag and drop NA’s in the tree around as well as remove them from the tree by dragging them to the list window. You can also load and store configurations to a file. If the design of your physical architecture is finished, you can create the physical architecture my selecting “Make Configuration” from the menu. Each NA in the tree will be contacted and the physical architecture will be created. The tree in the picture above displays two independent virtual architectures, one with root NA “agnes.par.univie.ac.at” and one with “daphne.par.univie.ac.at”. The node named “Systemroots” is just a dummy tree node and not a real NA. The first one is a NA of level three (agnes) consisting of two NA’s of level two (amanda, claire). The first one (amanda) consists of two NA’s of level one (becky, brooke), the second consists of three NA’s (darlene, dolly, edwin). The root of the second system is a NA of level five (daphne) consisting of one NA of level four (cybill) and another one of level 2 (lisa), and so on.