Last modified: Thu Oct 25 2001

SPOC-architecture

by
Tobias Öbrink

Table of Contents


1 Introduction

This is a document describing a proposed architecture for a service developed from the Single-Point-Of-Contact (SPOC) concept. In short the concept suggest that a single, well-known point should be used to simplify the different stages of a communication setup between persons or person-service or service-service. I will use a simple graph to help explain the concept.

Figure 1. A very simple SPOC

Here we have two users, one active and one passive. The active user is looking for aperson to ask about some strange acronym, SPOC, that he have encountered. In this valiant quest for knowledge he happen to connect to a SPOC consisting of a simple Web-server with a list of all employed at the dept. of Teleinformatics, KTH, Sweden. Except from name, the list entries also consists of

  1. a link to the employees home page, if present. A link to a cgi-script running "finger" on the employee, otherwise
  2. a link to a more or less recent photograph of the employee
  3. the employees position
  4. the employees telephone number(s)
  5. which room the employee is most frequently located in
  6. the employees email address
With the help of this list and additional information on the employees home pages, the active user hopefully will find a person to ask, and he will also know how to contact the passive user.

This of course is a very simple SPOC that also requires that the active user have access to a Web browser. A more ideally SPOC should offer a lot more information, search engines and not to forget gateways.

2 Architecture overview

The keyword in an ideally SPOC should be "Accessability". It should be possible to connect to it even by a smoke signals protocol. To achieve this (accessability, not smoke signals) the SPOC should have

  1. a well-defined physical location
  2. a well-defined network location
  3. a multitude of gateways to different communication protocols
  4. an information repository describing the SPOC architecture
  5. some reason for being
Point 1 - 3 is (I hope) quite self-explanatory. Point 4 is for making administration of the SPOC easier. Point 5 is very important.

Now, over to the proposed architecture. I would like to start with the overall functionality, which is divided into as independent modules as possible.

2.1 Functionality modules

So far I've been able to identify the following groups of functionality

Figure 2. Functionality modules in the proposed SPOC system

2.1.1 The External user Object

The External user Object is the part of the system that the Active user will use in his/hers interactions with the SPOC. Naturally the behaviour and the "look and feel" of the External user Object will vary with which media is used; an external user connected via an ordinary telephone will need a different UI than an external user connected via a direct 2.5 Gbps link with separate video, audio and data channels. Some other users may want to send a fax, or an email or connect via some text-terminal-based protocol, and some users may want to recieve responses via a different medium than was used for the request. It should be launched by the Manager as a result of a request from the contacted Gateway Object. The External user Object uses the contacted Gateway Object in its interactions with it's Active user.

2.1.2 The Internal user Object

The Internal user Object is the part of the system that will keep track of it's "Internal user". This "Internal user" could be a person or some network service (Directory Server, Web server, search engine, file server, you name it). It's only "internal" in the sense that it's within the scope of knowledge that the SPOC possess. The Internal user Object keeps updated the information regarding it's Internal user in the Information Repository.

2.1.3 The Information Repository

The Information Repository handles all information contained in the SPOC system. This includes information describing the architecture and configuration of the SPOC as well as information about Internal users, status information and messages. The Information Repository should be the most robust part of the system, because the information contained there can be used to rebuild the system automatically and because the information contained therein is the reason why people bother to use it at all.

2.1.4 The Gateway Object

The Gateway Object handles translation between the internal SPOC protocol/medium and some other protocol/medium as well as launching and managing External user Objects specific for the appropriate protocol/medium. It should be closely connected to the Manager.

2.1.5 The Manager

The Manager is the spider in the net. It should have the two first characteristics of a SPOC above. It should be closely connected to the Information Repository to be able to keep track of connections and parts in the system. It should handle requests for information from all other parts of the SPOC system and all initiation of cross-protocol/media communication. It should alsom be able to relay requests to other Managers in other SPOCs that are registered as Internal user Objects in this SPOC.

2.2 Proposed solutions

There are ofcourse a lot of ways you can map the above described functionality onto SW/HW-entities and it requires some consideration and discussion to do it efficiently and well. Here are the currently proposed solutions.

2.2.1 The External user Object

So far only an WWW-based External user Object have been considered. It should be implemented as a Java applet that can be downloaded from a WWW-gateway. It will then communicate with the Manager (and other objects in the system) through this gateway via a cgi-script or some other serverdaemon running on the same machine.

2.2.2 The Internal user Object

The Internal user Object should be a pair of intelligent agents. One on the system side and one on the user side, if possible. A third agent in the Information Repository could be used to help in accessing the user information. Three designs of the agent on the system side are currently debated:

  1. The very decentralised scheme, where the system part implementing the Internal user Object also includes all data about it's user. In this scheme, the Internal user Object is also a part of the Information Repository.
  2. The partly decentralised scheme, where the system part implementing the Internal user Object also includes all "dynamic" data about it's user. In this scheme, the Internal user Object is also a part of the Information Repository.
  3. The centralised scheme, where the system part implementing the Internal user Object provides only intelligence and is completely separate from the Information Repository.
All these schemes have their advantages:

  1. The very decentralised scheme. The Internal user Object have complete control over all data concerning it's user, the accesstime for updating the data is very low.
  2. The partly decentralised scheme. Most Directory Services tend to be optimized for "static" data and the "dynamic" data is of little interest if the part of the system running the Internal user Object is down. The accesstime for updating the dynamic data is very low.
  3. The centralised scheme. From a stability and security point of view it's preferable to have all the information in one place. Also the system part implementing the Internal user Object can be very lightweight.
All these schemes also have setbacks ofcourse:

  1. The very decentralised scheme. Can get tricky to uphold data consistency and security. The database management work, storage- and backup demand and security mechanisms introduces extra complexity in the system part and will be quite heavyweight.
  2. The partly decentralised scheme. Unfortunately the same as 1 above, even though the storage - and backup demand is lower.
  3. The centralised scheme. The communication with the Information Repository will demand some efforts to avoid becoming a bottleneck.
There's a lot of issues to consider when choosing which way to go here, and maybe we'll find additional options further on.

The other two agents have been only briefly mentioned.

2.2.3 The Information Repository

The design of the Information Repository is dependent on which scheme will be choosed for the system part of the Internal user Object above. Additionally, it will include a Directory Service containing a description of the system. Apart from the issues discussed above, there is an issue on the general architecture of the Information Repository:

  1. The decentralised scheme. The Information Repository consist of an arbitrary number of interlinked Directory Services with a well-known "entrance" consisting of links to all other directories, or links to the top directories of a tree structure.
  2. The centralised scheme. The Alta Vista approach.
And the questions involved as far as I have got in my reading:

  1. The decentralised scheme. Mostly internal indexing issues. How to support searches, listings and administration? How to handle interaction between different parts of the Information Repository that consists of different solutions, speaking different protocols and having different data structures?
  2. The centralised scheme. Scalability issues. How to avoid becoming a bottleneck?
The Directory services I've stumbled onto so far is

More study is needed.

2.2.4 Gateway Objects

An impressive amount of different gateway products between different protocols and media have been released recently. Often connected to the WWW to get publicity. My vision is to use all these gateway products to get access to the SPOC-system by as many channels as possible and allow persons and services to communicate without having to bother about media/protocol/whatever restrictions.

A Gateway Object should consist of a gateway product managed by an agent.

Currently identified Gateway Objects are:

2.2.5 The Manager

An ideal Manager would be a combined "marketplace-court-townhall" for a software agent population continuously haggling about resources and information. It should supervise the activity, solve conflicts, mediate communication and optionally run a FAQ-cache for the agents. It should be closely connected to the part of the Information Repository containing a description of the system. It could be partly distributed on other parts of the system to avoid becoming a bottleneck.

3 Additional use-cases

In addition to the example given in the Introduction above I've cooked up a few use-cases to show some possible functions. More work, reading and thought are needed.


Maintained by Tobias Öbrink