<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2001</year><year>2009</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      The contents of this file are subject to the Erlang Public License,
      Version 1.1, (the "License"); you may not use this file except in
      compliance with the License. You should have received a copy of the
      Erlang Public License along with this software. If not, it can be
      retrieved online at http://www.erlang.org/.
    
      Software distributed under the License is distributed on an "AS IS"
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
      the License for the specific language governing rights and limitations
      under the License.
    
    </legalnotice>

    <title>OrberWeb</title>
    <prepared>Nick</prepared>
    <docno></docno>
    <date>2001-11-22</date>
    <rev></rev>
    <file>ch_orberweb.xml</file>
  </header>

  <section>
    <title>Using OrberWeb</title>
    <p><c>OrberWeb</c> is intended to make things easier when developing and 
      testing applications using <c>Orber</c>. The user is able to interact
      with <c>Orber</c> via a GUI by using a web browser.</p>
    <p><c>OrberWeb</c> requires that the application <c>WebTool</c> is available and
      started on at least one node; if so <c>OrberWeb</c> can usually be used to
      to access <c>Orber</c> nodes supporting the Interoperable Naming 
      Service. How to start OrberWeb is described in
      <seealso marker="ch_orberweb#startorberweb">Starting OrberWeb</seealso></p>
    <p>The <c>OrberWeb</c> GUI consists of a <em>Menu Frame</em> and a 
      <em>Data Frames</em>.</p>

    <section>
      <title>The Menu Frame</title>
      <p>The menu frame consists of:</p>
      <list type="bulleted">
        <item><em>Node List</em> - which node to access.</item>
        <item><em>Configuration</em> - see how Orber on the current node is configured.</item>
        <item><em>Name Service</em> - browse the NameService and add/remove a Context/Object.</item>
        <item><em>IFR Types</em> - see which types are registered in IFR.</item>
        <item><em>Create Object</em> - create a new object and, possibly, store it in the NameService.</item>
      </list>
      <p></p>
      <marker id="menuframe"></marker>
      <image file="menuframe.gif">
        <icaption>The Menu Frame.</icaption>
      </image>
      <p>Which nodes we can access is determined by what is returned when invoking <c>[node()|nodes()]</c>.
        If you cannot see a desired node in the list, you have to call <c>net_adm:ping(Node)</c>.
        But this requires that the node is started with the distribution switched on
        (e.g. <c>erl -sname myNode</c>); this also goes for the node <c>OrberWeb</c> is running on.</p>
    </section>

    <section>
      <title>The Configuration Data Frame</title>
      <p>When accessing the <em>Configuration</em> page OrberWeb presents a table containing the
        <seealso marker="ch_install#config">configuration settings</seealso> for the target node.</p>
      <p></p>
      <marker id="dataframe3"></marker>
      <image file="dataframe3.gif">
        <icaption>Configuration Settings.</icaption>
      </image>
      <p>It is also possible to change those configuration parameters which can be changed when Orber
        is already started. The Key-Value pairs is given as a list of tuples, e.g.,
        <em>[{orber_debug_level, 5}, {iiop_timeout, 60}, {giop_version, {1,2}}]</em>. If one tries to update a parameter
        which may not be changed an error message will be displayed.</p>
    </section>

    <section>
      <title>The IFR Data Frame</title>
      <p>All types registered in the IFR (Interface Repository) which have an associated IFR-id
        can be viewed via the IFR Data Frame. This gives the user an easy way to confirm that
        all necessary IDL-specifications have been properly registered. All available types are
        listed when choosing <c>IFR Types</c> in the menu frame:</p>
      <p></p>
      <marker id="dataframe1"></marker>
      <image file="dataframe1.gif">
        <icaption>Select Type.</icaption>
      </image>
      <p>After selecting a type all definitions of that particular type will be displayed. If no such
        bindings exists the table will be empty.</p>
      <p>Since Orber adds definitions to the IFR when it is installed (e.g. CosNaming), not only
        types defined by the user will show up in the table. In the figure below you find the
        the NameService exceptions listed.</p>
      <p></p>
      <marker id="dataframe2"></marker>
      <image file="dataframe2.gif">
        <icaption>List Registered Exceptions.</icaption>
      </image>
    </section>

    <section>
      <title>The NameService Data Frame</title>
      <p>The NameService main purpose is to make possible to bind object references, which
        can client applications can resolve and invoke operations on. Initially, the NameService
        is empty. The most common scenario, is that user applications create Contexts and add objects
        in the NameService. OrberWeb allows the user to do the very same thing.</p>
      <p>When referencing an object or context you must use stringified NameComponents.
        For more information see the <seealso marker="ch_naming_service">Interoperable Naming Service</seealso>.
        In the following example we will use the string <em>org/erlang/TheObjectName</em>, where
        <em>org</em> and <em>erlang</em> will be contexts and <em>TheObjectName</em>
        the name the object will be bound to.</p>
      <p>Since the NameService is empty in the beginning, the only thing we can do is creating
        a new context. Simply write <em>org</em> in the input field and press <c>New Context</c>.
        If OrberWeb was able to create the context or not, is shown in the completion message. 
        If successful, just press the <c>Go Back</c> button. Now, a link named <em>org</em> should
        be listed in the table. In the right column the context type is displayed. Contexts are
        associated with <em>ncontext</em> and objects with <em>nobject</em>.</p>
      <p></p>
      <marker id="dataframe5"></marker>
      <image file="dataframe5.gif">
        <icaption>Add a New Context.</icaption>
      </image>
      <p>To create the next level context (i.e. erlang), simply follow the link and repeat the procedure.
        If done correctly, a table containing the same data as the following figure should be the result 
        if you follow the <em>erlang</em> link. Note, that the path is displayed in the yellow
        field.</p>
      <p></p>
      <p>If a context does not contain any sub-contexts or object bindings, it is possible to
        delete the context. If these requirements are met, a <c>Delete Context</c> button will appear.
        A completion status message will be displayed after deleting the context.</p>
      <p></p>
      <marker id="dataframe6"></marker>
      <image file="dataframe6.gif">
        <icaption>Delete Context.</icaption>
      </image>
      <p>Now it is possible to bind an object using the complete name string. To find out how this is
        done using OrberWeb see <seealso marker="ch_orberweb#create">Object Creation</seealso>.
        For now, we will just assume that an object have been created and bound as <em>TheObjectName</em>. </p>
      <p></p>
      <marker id="dataframe7"></marker>
      <image file="dataframe7.gif">
        <icaption>Object Stored in the NameService.</icaption>
      </image>
      <p>If you follow the <em>TheObjectName</em> link, data about the bound object will be
        presented. Note, depending on which type of object it is, the information given differs.
        It would, for example, not be possible to display a Pid for all types of objects since
        it might reside on a Java-ORB. In the figure below a CosNotification FilterFactory have
        been bound under the name <em>org/erlang/TheObjectName</em>.</p>
      <p></p>
      <marker id="dataframe8"></marker>
      <image file="dataframe8.gif">
        <icaption>Object Data.</icaption>
      </image>
      <p>OrberWeb also makes it possible to remove a binding and dispose the associated object.
        Pressing <em>Unbind</em> the binding will be removed but the object will still exist. 
        But, if the <em>Unbind and Dispose</em> button is pressed, the binding will be removed
        and the object terminated.</p>
    </section>

    <section>
      <title>The Object Creation Data Frame</title>
      <marker id="create"></marker>
      <p>This part makes it possible to create a new object and, if wanted, store it the
        NameService.</p>
      <p></p>
      <marker id="dataframe4"></marker>
      <image file="dataframe4.gif">
        <icaption>Create a New Object.</icaption>
      </image>
      <list type="bulleted">
        <item><em>Module</em> - simply type the name of the module of the object type
         you want to create. If the module begins with a capital letter, we normally must
         write <c>'Module_Interface'</c>. But, when using OrberWeb, you shall <em>NOT</em>.
         Since we cannot create linked objects this is not an option.</item>
        <item><em>Arguments</em> - the supplied arguments must be written as a single Erlang term.
         That is, as a list or tuple containing other Erlang terms. The arguments will be 
         passed to the <c>init</c> function of the object. It is, however, not possible
         to use Erlang records. If OrberWeb is not able to parse the arguments, an error message
         will be displayed. If left empty, an empty list will be passed.</item>
        <item><em>Options</em> - the options can be the ones listed under 
        <seealso marker="Module_Interface">Module_Interface</seealso> in Orber's Reference manual.
         Hence, they are not further described here. But, as an example, in the figure above
         we started the object as globally registered. If no options supplied the object
         will be started as default.</item>
        <item><em>Name String</em> - if left empty the object will <em>not</em> be registered in the 
         NameService. Hence, it is important that you can access the object in another way,
         otherwise a zombie process is created. In the previous section we used the name string
        <em>org/erlang/TheObjectName</em>. If we choose the same name here, the listed contexts
         (i.e. <em>org</em> and <em>erlang</em>) must be created <em>before</em> we can create
         and bind the object to <em>TheObjectName</em>. If this requirement is not met, OrberWeb
         cannot bind the object. Hence, the object will be terminated and an error message
         displayed.</item>
        <item><em>Operation to use</em> - which option choosed will determine the behavior of OrberWeb.
         If you choose <em>bind</em> and a binding already exists an error message will be 
         displayed and the newly started object terminated. But if you choose <em>rebind</em>
         any existing binding will over-written.</item>
      </list>
    </section>
  </section>

  <section>
    <title>Starting OrberWeb</title>
    <marker id="startorberweb"></marker>
    <p>You may choose to start OrberWeb on node, on which Orber is running or not. But
      the Erlang distribution must be started (e.g. by using -sname aNodeName). Now, all 
      you have to do is to invoke:</p>
    <code type="none">
    
erl> webtool:start().
WebTool is available at http://localhost:8888/
Or  http://127.0.0.1:8888/
    </code>
    <p>Type one of the URL:s in your web-browser. If you want to access the WebTool application
      from different machine, just replace <c>localhost</c> with its name. For more information,
      see the WebTool documentation.</p>
  </section>
</chapter>

