Novell is now a part of Micro Focus

Administration of the Novell Trader

Articles and Tips: article

ED LAUDER
Software Engineer
Java Technologies Group

01 Jan 1998


Acquaints readers with Trading functionality and what parts of that functionality can be incorporated into an Administration utility for the Trading Service.

Introduction

In the last few issues of Novell Developer Notes, developers in the Java Technologies Group have introduced a new distributed-object service. This service, a Trading Object Service, has been presented as a sort of "Yellow-Pages" for distributed objects.

For example, if you know in advance who or what company you wish to call , you would use the white pages. If you only know that you want to find a full suspension mountain bike, you would probably begin your search with the Yellow-Pages, possibly under cycling. Continuing with the Yellow-Pages analogy, the Trading Function allows users to advertise their goods and allows users to browse for goods. More accurately, the Trading Service provides the functionality for a service to register itself and the functionality for clients to discover all services that have been registered.

These articles have provided the reader a wealth of knowledge about client/server computing within the distributed object arena. In addition, these articles have shown users how to write clients to implement a Trading Service in their environment. As the user's environment becomes saturated with objects, there has been one area omitted. How does a user manage those objects? Who can gain access to those objects? Who may create additional objects? And who will be allowed to update the so-called Yellow-Pages? These are very real questions that many administrators will have to answer as their world becomes proliferated with objects.

This article is the first of a two-part feature. The intent of this first article is to acquaint the reader with what trading functionality exists and what parts of that functionality can be incorporated into an Administration utility for the Trading Service. The second article will closely describe the architecture of the Novell Administration Utility and how administrators will actually perform their object management job.

What Administration Tasks?

The answer to this question lies within open standards. From industry collaboration efforts at Object Management Group (OMG) we have a guideline of what the trading functions are and how an administration package can manage them. This open standard guideline is the OMG Trader Specification.

If you have read any of the previous trading articles, or have looked into development in the distributed object space, you have no doubt discovered the complexity of writing code and managing objects in the distributed object networks. The hope of an administration utility would be to provide the administrator some visual mechanism in which to manage the distributed objects without having to see the Trader Function APIs. This is significant, as we will see.

Trader Object Service Requirements

The following tables list the functional interfaces needed to be satisfied for a Trading Object Service.


Trading Object ServiceInterfaces

Lookup:

query

Register:

exportwithdrawdescribemodifywithdraw_using_constraintresolve

Admin:

list_offerslist_proxies

Link:

add_linkremove_linkdescribe_linklist_linksmodify_links

Proxy:

export_proxywithdraw_proxydescribe_proxy

Service TypeRepository Interfaces

ServiceTypeRepository:

add_typeremove_typelist_typesdescribe_typefully_describe_typemask_typeunmask_type

Note: This article is not intended to go into detail about each interface method. Additional Developer Notes articles cover each of the interfaces in detail.

Looking over this list, one can begin to see what type of functions could be bundled to create an administration utility. For instance, here is a list of tasks one would want to perform for the following Trader Object Service objects:


Trader
Service TypeRepository

Create TradersDelete TradersModify/Edit Trader AttributesExport (Create) OffersDelete OffersGive RightsList OffersList Offer PropertiesList ProxiesList LinksAdd/Delete/Modify Offer PropertiesMake ProxiesCreate LinksStart/Down

Create RepositoryDelete RepositoryList Bounded TradersCreate Service TypesDelete Service TypesList Service TypesGive RightsMask/Unmask Service TypesStart/Down

Administration via the Trader API

It would be too exhaustive to show implementation of all trader functionality here. However, let's take a closer look what effort would be required to complete one of these tasks. A very common task would be to add a listing into the Yellow-Pages, or in the Trading Object Service problem space, create a Service Type.

If you have been following the Trader articles you will remember the following listing.

// MyCalcServer.java - implementation of calc server

import java.util.*;

import org.omg.CosTradingRepos.ServiceTypeRepositoryPackage.*;

class myCalc extends _CalcImplBase {

     public myCalc(java.lang.String name) { super(name); }

     public myCalc() { super(); }

     public int add(int n1, int n2) { return n1+n2; }

     public int sub(int n1, int n2) { return n1-n2; }

}



public class MyCalcServer {

public static void main(String[] args) {

     try {

     // initialize the orb & boa (basic object adapter).

     org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init();

     org.omg.CORBA.BOA boa = orb.BOA_init(); 

     

      // Instantiate a calculator named calc1  

     myCalc cObj = new myCalc("calc1");

     boa.obj_is_ready(cObj);

     

     // Add a calculator type if one doesn't exist

     org.omg.CosTradingRepos.ServiceTypeRepository typeObj;

     typeObj = org.omg.CosTradingRepos.ServiceTypeRepositoryHelper.bind(orb);

     try  {

     typeObj.add_type("Calculator",

                    "calc_if", 

                    new PropStruct[0], 

                    new String[0]);

     }

     catch (ServiceTypeExists e) {System.out.println("calculator already exists");}

     catch (org.omg.CORBA.UserException e) {System.out.println(e); }

     

     // bind to trader's register interface

     org.omg.CosTrading.Register regObj;

     regObj = org.omg.CosTrading.RegisterHelper.bind(orb);



      // build property sequence with just one property entry "cost = 50"

     org.omg.CosTrading.Property[] props = new org.omg.CosTrading.Property[1];

     org.omg.CORBA.Any costAny = orb.create_any();

     costAny.insert_long(50);

     props[0] = new org.omg.CosTrading.Property("cost", costAny);



     try  {

     String offerId = regObj.export(cObj, "Calculator", props);

     } catch (org.omg.CORBA.UserException e) { System.out.println(e); }



     boa.impl_is_ready(); // Wait for incoming requests



     } catch(org.omg.CORBA.SystemException e) { System.err.println(e); }

}

}

For a detailed explanation of the entire source please read "Using the Novell Trader" in the October 1997 Novell Developer Notes. Please look at the add_type method call. In order to add a service type, the client/server program would first have to define a Service Type Repository Object and make a physical binding to the Service Type Repository Interface. Now the calling program could perform an add_type method and perform the necessary error detection. In this simple case the method is very straightforward: name, interface name, no properties, and no super types. It is with the later two parameters that this code can become "messy."

Class Administration via the TraderService Helper

Let's try another approach. The TraderService helper class is provided to wrapper most of the complexity. However, the administrator would still implement administration through programming. Here is a brief look at how adding a service type would be completed with the TraderService class.

// Get reference to TraderService

     TraderService trader = new TraderService();



     // Instantiate TraderService Type object

     TraderType calcObj = new TraderType( );



     // Set service type

     calcObj.setServiceType( "Calculator" );



     // Set interface name

     calcObj.setInterface( "calc_if" );



     // Register new Calculator Service

     trader.addServiceType(calcObj);

or :

// Get reference to TraderService

     TraderService trader = new TraderService();



     // Instantiate Type object w/ type and interface

     TraderType calcObj = new TraderType( "Calculator", "calc_if" );



     // Register new Calculator Service

     trader.addServiceType(calcObj);

Here, the administrator is adding a service type, without any properties. Adding properties becomes more straightforward with the helper class, but they must be added programmatically. For more information on the TraderService helper class please read the "Novell Trader Helper Class: TraderService" in the November 1997 issue of Developer Notes.

Administration Utility

For the above examples of adding a service type, the administrator should be provided this information via a visual mechanism without having to see the code. And that is exactly what Novell has done. Novell's solution to providing this visual mechanism was to write a Snap-in for NetWare Administrator.

The Trader and Service Type Repository Objects are modeled in NDS. That is, the base schema has been extended to include two additional object classes with associated attributes. Using the NetWare Administrator, the user can browse the NDS tree for Trader and Service Type Repository Objects.

Figure 1: Trader Snap-in for NetWare Administrator.

Now, let's add a Service Type. The user browses the NDS tree and selects the Service Type Repository object class. For this example, the name of the service Type Repository is Service Type Repository_1. With a right mouse click, and a selection on the details item, the Service Type Repository property page will be displayed. The administrator would then select the Create Service Type button. The following dialog will appear and the user will be prompted to enter data.

Figure 2: Service Type Repository page.

From this dialog, the user may add a Service Type to the Service Type Repository named Service Type Repository_1, merely by supplying the name, interface name, super type, and by creating a list of properties.

The properties for the Service Type have a name, mode, and type. The second article will go into more detail about the administration utility functionality.

The complex distributed-object programming is hidden from the user. The user can manipulate the add service type Functional Interfaces graphically. From this standpoint, an administrator could manage a three-tier distributed-object environment without having to run IDL compiliers, writing client code with generated stub files, etc. All that complexity is wrapped into a GUI.

Conclusion

As you can see, writing your own client to manage the Trading Service is possible via the basic Trader API and also via the new Novell Trader Service wrapper classes. The Administration utility, itself a client, takes the complexity of programming away from the administrator. Enabling the administrator to get his work accomplished without having to program. The administration utility also adheres to open standards.

Modeling the Trader Service with NDS provides a single point of administration for distributed objects, network objects, and system resources. NDS adds value through access controls, stability, scalability, persistence, and security. Novell hopes to be the first company to bring to market a usable Administration utility for a Full-Service Trading Object Service.

In the second Trading Service Administration article, you will see how a user would install, initialize, and configure a full-service trader via Novell's Administration Utility.

References

Object Management Group RFP5 Submission - Trading Object Service

ISO/IEC - Dis 13235-3 - Open Distributed Procressing - Trading Function-Part 3: Provision of Trading Function using OSI Directory Service

CORBA Fundamentals and Programming, Jon Siegel

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates