TBLA Component Discovery

Mark J. Norton

May 11, 2001

Given a modular learning system which is composed of components which implement various services, how is a new service added to the system? How does a service component discover other services in the system and initiate communication with them? How is data managed in this kind of system. This document explores some possible answers to these and other questions.

This diagram is used for purposes of discussion, below. The Service Broker and Registry are intended to be standard components of all Tabula systems. The box labeled Service Comp can be considered to be a generic system component that provides one or more services. Similarly, the one labeled “Data Manager” is a system component that provides a data management service on the body of data labeled “Data Repository”. A repository can be a collection of files, files organized by directories, aggregated files such as an IMS package, or a database.


Installing a New Component

Let us assume that a new learning component has been purchased by an organization. The component is delivered to a system administrator in some transmission form. This form could be a zip file which is downloaded via the Internet, or it could be some portable data storage, such as CDROM.

How portable is the software associated with components?

We can further assume that this component is appropriate for execution in its target environment and comes with an installer of some type which assists the administrator in unpackaging the component and getting it physically onto the host learning system.

Component Registration

Several things need to happen to have a service compontent be fully installed into a learning system. Some minimal representation of the service needs to be present, such as its name and program invocation. One program needs to be well known to all possible services that can be installed: the service broker is designed to fill this role.

In addition to the service broker, another required service is the Service Registry. This component manages the Service Repository, which is a data repository containing all services currently know to the system, how to invoke them, the services they provide, and descriptions of how these services can be accessed.

It might be better to name the Service Registry at the Component Registry to avoid the confusion that component services provide services.

Registration of a component is a two-step process. When the administrator installs the component, initial registration needs to occur. This could be handled using an administration tool, or it could be done by the installer script. The second step is for the system to invoke the new component to publish its service interface. The new component communicates with the Service Registry via the service broker and publishes its services and service interfaces.

How is the service and its interfaces represented in the registry?

Service Discovery

Once a component has been registered, in theory, its services are now available to other components and users. Given a flexible user interface, making a new service available to a user is not too difficult, but how is a service discovered by another component? Some components will depend on other component to provide known services. A search engine, for example, will need to know how to work with a access manager to determine if a user can access a piece of content (etc). The search engine knows how to look for services which fill the role of an access manager, and how to handle it when such a service is not planning.

This implies classification, categorization, or some organization of services.

Servers can also be registered which extend or shadow other registered services on the learning system.

Communication and Interfacing

Loose coupling vs. tight coupling vs. direct data access.
Messaging vs. functional API vs data model API