12 OrberWeb

12.1 Using OrberWeb

OrberWeb is intended to make things easier when developing and testing applications using Orber. The user is able to interact with Orber via a GUI by using a web browser.

OrberWeb requires that the application WebTool is available and started on at least one node; if so OrberWeb can usually be used to to access Orber nodes supporting the Interoperable Naming Service. How to start OrberWeb is described in Starting OrberWeb

The OrberWeb GUI consists of a Menu Frame and a Data Frames.

The Menu Frame

The menu frame consists of:

  • Node List - which node to access.
  • Configuration - see how Orber on the current node is configured.
  • Name Service - browse the NameService and add/remove a Context/Object.
  • IFR Types - see which types are registered in IFR.
  • Create Object - create a new object and, possibly, store it in the NameService.
Figure 12.1: The Menu Frame.

Which nodes we can access is determined by what is returned when invoking [node()|nodes()]. If you cannot see a desired node in the list, you have to call net_adm:ping(Node). But this requires that the node is started with the distribution switched on (e.g. erl -sname myNode); this also goes for the node OrberWeb is running on.

The Configuration Data Frame

When accessing the Configuration page OrberWeb presents a table containing the configuration settings for the target node.

Figure 12.2: Configuration Settings.

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., [{orber_debug_level, 5}, {iiop_timeout, 60}, {giop_version, {1,2}}]. If one tries to update a parameter which may not be changed an error message will be displayed.

The IFR Data Frame

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 IFR Types in the menu frame:

Figure 12.3: Select Type.

After selecting a type all definitions of that particular type will be displayed. If no such bindings exists the table will be empty.

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.

Figure 12.4: List Registered Exceptions.

The NameService Data Frame

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.

When referencing an object or context you must use stringified NameComponents. For more information see the Interoperable Naming Service. In the following example we will use the string org/erlang/TheObjectName, where org and erlang will be contexts and TheObjectName the name the object will be bound to.

Since the NameService is empty in the beginning, the only thing we can do is creating a new context. Simply write org in the input field and press New Context. If OrberWeb was able to create the context or not, is shown in the completion message. If successful, just press the Go Back button. Now, a link named org should be listed in the table. In the right column the context type is displayed. Contexts are associated with ncontext and objects with nobject.

Figure 12.5: Add a New Context.

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 erlang link. Note, that the path is displayed in the yellow field.

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 Delete Context button will appear. A completion status message will be displayed after deleting the context.

Figure 12.6: Delete Context.

Now it is possible to bind an object using the complete name string. To find out how this is done using OrberWeb see Object Creation. For now, we will just assume that an object have been created and bound as TheObjectName.

Figure 12.7: Object Stored in the NameService.

If you follow the TheObjectName 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 org/erlang/TheObjectName.

Figure 12.8: Object Data.

OrberWeb also makes it possible to remove a binding and dispose the associated object. Pressing Unbind the binding will be removed but the object will still exist. But, if the Unbind and Dispose button is pressed, the binding will be removed and the object terminated.

The Object Creation Data Frame

This part makes it possible to create a new object and, if wanted, store it the NameService.

Figure 12.9: Create a New Object.
  • Module - 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 'Module_Interface'. But, when using OrberWeb, you shall NOT. Since we cannot create linked objects this is not an option.
  • Arguments - 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 init 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.
  • Options - the options can be the ones listed under Module_Interface 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.
  • Name String - if left empty the object will not 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 org/erlang/TheObjectName. If we choose the same name here, the listed contexts (i.e. org and erlang) must be created before we can create and bind the object to TheObjectName. If this requirement is not met, OrberWeb cannot bind the object. Hence, the object will be terminated and an error message displayed.
  • Operation to use - which option choosed will determine the behavior of OrberWeb. If you choose bind and a binding already exists an error message will be displayed and the newly started object terminated. But if you choose rebind any existing binding will over-written.

12.2 Starting OrberWeb

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:

    
erl> webtool:start().
WebTool is available at http://localhost:8888/
Or  http://127.0.0.1:8888/

Type one of the URL:s in your web-browser. If you want to access the WebTool application from different machine, just replace localhost with its name. For more information, see the WebTool documentation.

© 2010–2017 Ericsson AB
Licensed under the Apache License, Version 2.0.