VEMInterface Implementation

  An AFE requests a service by calling the requestService() method on its workspace reference. The AFE passes a reference to itself, the well-known name of the service, and a special Filter object. Passing the requester of the service enables the VEM to keep state on each AFE. It also allows application designers to, in effect, build a service providing object that gets services on behalf of all AFEs in the suite. The Filter object was designed to simplify the attribute/value logic specification. At this time, only the ``AND'' function is provided, e.g., a service must have ``attr1=val1'' & ``attr2=val2''. The Filter class will be enhanced in the future to allow arbitrary logic specifications. An example code segment showing service request is:

  Filter filter = new Filter();
  filter.addElement("height","low");
  filter.addElement("speed","slow");
  workspace.requestService(this, 
      "my_service", filter);

The requestService() implementation in the VEM class does the following list of actions. Note that not all exception paths are included in the list.

1. If a null filter was passed in, the VEM creates one. A special attribute/value pair (`type'/`Service') is added. The type attribute was added because the Metis Directory Service contains both services and AFEs.
2. The VEM checks its internal state to see if the AFE is a known service user.
3. If the AFE is not a known service user, its authorization is checked to ensure that the AFE has the credentials needed to use the Metis system. If it passes the check, it is added to the VEM internal state. Otherwise, the requestService() throws an exception.
4. The VEM checks its internal state to see if the AFE has previously asked for the same service. If so, it returns the associated ServiceInfo object.
5. The lookUpService() method is called on the directory client and the returned list is wrapped in a ServiceInfo object.
6. The VEM checks the validity of the ServiceInfo object. The object will be invalid if the directory search could not find any services, e.g., if the service was unknown or if the user did not have access to the those registered. An exception is thrown if the ServiceInfo is invalid. A timestamp is also added to the new ServiceInfo object. The ServiceInfo object is then added to the VEM internal state and returned to the AFE.

The object class, ServiceInfo, returned by the requestService() method maintains the information returned by the directory lookup. For the reference implementation, the locations of the services are stored within the ServiceInfo object as URLs. The class provides accessor methods for AFEs to use.

The AFE uses the ServiceInfo object to get to the service. During its use, the service could fail. The AFE, when it detects such an occurrence, can request a replacement service by calling the recoverService() method on its workspace, passing it a reference to itself, and the ServiceInfo it used to get the previous service. The workspace delegates the request to its VEM object. The VEM class's recoverService() implementation does the following list of actions. Again, not all exception paths are included.

1. Add the currently accessed service to the blacklisted services maintained in the ServiceInfo object. This blacklist is simply a means of tracking which of the services returned by the directory lookup have been used, and failed.
2. See if there is another service known in the ServiceInfo that has not yet been used. If so, setup that service, make it the current service in the ServiceInfo object, and return back the same ServiceInfo object.
3. Otherwise, save the timestamp and the current blacklist. The timestamp is important in later steps. The blacklist is needed because more services may be available than those returned during the previous directory lookup(s). That is, the blacklist transcends the partitioning done by the lookup; It is used to capture the AFEs access to ALL relevant services.
4. Request the directory client to do a new lookup, passing it the blacklist, and wrapping the return list in a new ServiceInfo object.
5. If the ServiceInfo object is valid, then there were other services as yet unused by the AFE that met its requirements. Copy back the timestamp and the blacklist. Return the ServiceInfo object to the AFE.
6. If the ServiceInfo is invalid one of two scenarios could have happened. First, the current sweep through all possible services may have finished. If so, a new sweep is started by clearing the blacklist and creating a new timestamp. Second, there may be no more services available, even though they may still be registered with the directory service. One way for this scenario to happen is if there is a network partition that does not affect access to the Metis Directory Service but that interferes with access to the servers that the services are running on. It is detected by noting that the time required to finish a sweep is less than a pre-configured time determined by the system administrator.
7. If no new services are available, VEM repeats steps 4 through 6 one more time. If, even after the retry, it cannot satisfy the request then it displays an error message.