~

IELSEVIER

COMPUTERNETWORKSand

ISDN SYSTEMSComputer Networks and ISDN Systems 28 (1996) 543-550

Providing multiple external views on directory user interfaces

Rui J.P. José, António Costa, Joaquim Macedo, Vasco Freitas *Departamento de lnformática, Universidade do Minha, P-4709 Braga, Portugal

Abstract

Although there are many types of Directory User Interfaces they ali tend to give to their users the same globalview of the Directory. However, a typical user will only be interested in some portion of the total Directory database.Providing such specific view might be done for instance by restricting the default DUA display to a subset of objectclasses or attribute types meaningful to a particular application.

The work described in this paper is not about interface styles or user friendliness. It is about defining mechanismsthat allow for users to easily setup several configurations based on the information they intend to access. Theyshould be adaptable to a variety of interfaces and, to demonstrate that, as well as raising some practicalimplementation issues, two interfaces based on these concepts are presented: A windows LDAP DUA and a WWWto X.500 gateway.

Directory interfaces adopting this model are expected to help users make more advanced uses of the Directoryand at the same time not need such a good knowledge of X.SOOand its operations.

Keywords: Directory services; User interfaces; X.500

1. Introduction

The X.SOOprotocol is very powerful and in theopinion of many people, excessively powerful,due to the complexity that such a flexibility im-plies. Without entering into such discussions thereis however one point that must be stressed. Theusers of the Directory rarely use the great major-ity of the functionalities that they have at theirdisposal.

A typical interaction, irrespective of the inter-face being used, consists of very simple opera-tions usually performed without any parameters.Even an experienced DSA manager using a pow-

* Corresponding author. E-mail: vf@uminho.pt.

0169-7552/96/$15.00 @ 1996 EIsevier Science B.V. AlI rights reservedSSDIO169-7552(95)00083-6

erful interface like dish 1 will tend to work insuch a rudimentary manner by using simple /istand show operations. ln so doing, the user isoverwhelmed with more information, in terms ofnumber of entries and attributes per entry, thanhe can handle or even need, which he could haveavoided should he had used a correctlyparametrized operation.

Superfluous information makes the user's taskmuch more difficult. The alternative approach ofwriting one single well parametrized commandthat would return less but more significant infor-mation has important disadvantages:

1 dish is part of QUIPU, the UCL X,500 implementation[1].

544 R.J.P. José et ai. / Computer Networks and ISDN Systems 28 (1996) 543-550

. It requires a perfect knowledge of the interfacecommands and their parameters.

. It requires knowledge of the Directory schemain terms of attributes and object classes used,matching types or possible values for someattributes.

. It must be done every time the request isneeded which may be tedious and a potentialcause for mistakes. Therefore, at least for themost common queries, some kind of automa-tion that reliefs users from these burdensshould be included in the functionality of theinterface.

2. The externa} view

Although the Directory is not a general pur-pose database [2], it is, nevertheless, a Databaseand therefore it has many common aspects withtraditional general purpose DBMSs 2. These sys-tems are usually based upon a 3-layer architec-ture as illustrated in Fig. 1, known asANSljSPARC architecture [3] in which:. The internallevel is the one closest to physical

storage i.e., it is the one concerned with theway the data is physically stored.

. The conceptual leveI hides the details of physi-cal storage structures and concentrates on de-scribing entities, data types and relationships.The conceptuallevel is a representation of theentire information content of the database

. The externaI leve! is concerned with the waythe data is viewed by individual users. Eachview typically presents in an adequate way thepart of the database that a particular user isinterested in and hides the rest of the databasefrom that user.If one tries to adapt this architecture to the

Directory, one may easily associate the internalleveI with the data as is stored in DSAs 3 like forinstance in an EDB 4 formato

2 Database Managernent Systerns.

3 Directory Systern Agent.

4 Entry Data Block, the forrnat used by quipu DSAs tostore inforrnation.

v;ewn

Externallevei

Concepluallevei

InternalleveiSto"d Database

Fig. 1. ANSI/SPARC architecture.

As for the conceptual leveI it seems to matchvery well with the presentation of that data in astructure know as DIT 5.

Finally there is the externallevel which corre-sponds to the information being presented to ause r by a DUI 6. The ANSljSPARC term for anindividual user's view is an external view [5]. Anexternal view, therefore, is the content of thedatabase as seen by some particular user (that is,to that user the external view is the database).For example, a receptionist could see the Direc-tory as an ordered list of people entries contain-ing telephone and room numbers.

3. The conceptual interface

External views are important specially in aglobal service like the Directory and there areseveral ways of providing them on Directory in-terfaces. The most obvious is by creating special-ized programs. This is not very common howeversince it requires a perfectly stable service. AX.500 capablemail reader with a Directory Inter-face for retrieving mail addresses could be men-tioned as an example.

A more feasible alternative is to create genericinterfaces which can be configured to work in

5 Directory Inforrnation Tree.6 Directory Use r Interface. The terrn DUI will be used

instead of DUA (Directory User Agent) since the later rnayirnp!y an assurnption that the agent is ab!e to "ta!k" a validX.SOO protoco! [4].

R.J.P. José et ai. / Computer Networks and ISDN Systems 28 (J996) 543-550

many different ways. They exploit the fact thatmany applications tend to fall into a small num-ber of rather stereotyped patterns. Therefore theycan be tailored to suit some service specific re-quirements by simply providing values for a fewconfiguration parameters.

In a more or less complex way, almost allDUIs have some kind of configuration which isusually set at installation time. This method ofsetup has very little flexibility because it does nottake into account the information being con-sulted. Even when there is only one single user hemay need to access many different types of infor-mation. If he only disposes of a possible configu-ration then it must be made generic enough toserve all those access patterns.

A much more useful method would allow forseveral more precise setups oriented at specificapplications. In fact, the setup is much moreinfluenced by what is being consuIted than bywho is consulting so the user should be given thepossibility to personalize his setup in a number ofways. The conceptual interface will therefore al-low for several choices of service oriented config-urations.

In order to take advantage of the power ofX.SOOwithout running into the problems of com-plexity mentioned earlier on, the DUI will havethe ability to store several configurations in apersistent way.

Thus the user may refer to previously preparedcomplex setups by simply choosing the appropri-ate configuration.

In order to make it easier to describe how toconfigure a display of information, it is consid-ered that the conceptual interface has at leasttwo types of display formats both of them appear-ing either simuItaneously in different display ar-eas or, alternatively, in the same display area.They are. The display of a group of entries in a short

formal. This display format will be called listview.

. The display of an single entry in a longerformat or even the complete display. This dis-play format will be called entry view.The list view is often used to select an entry to

be displayed in the entry view.

545

4. The external schema

Each external view is defined by means of anexternal schema, which basically consists of a setof meta-information elements or configurationvariables. The defined meta-information ele-ments and their values will determine the viewpresented to the useI. These elements howeverare all optional and the total absence of configu-ration will simply correspond to the conceptualview of the Global Directory Service.

Then, what should a representative set ofmeta-information elements be? An answer to thisquestion has to account for both the actual userrequirements and the protocol and interface ca-pabilities. To simplify the inc1usion of both in-puts, the elements are c1assified into two layers.The first one will have a direct correspondance tothe protocol operation parameters on top of whicha second layer with more abstract elements maybe implemented. The latter eleménts are moreappropriate for users but in most cases must bemapped onto the elements of the lower level.

The choice between using only the elements ofone leveI or a combination of both can only bemade in the context of a particular implementa-tion.

4.1. Low levei elements

Since most DUAs and X.500 gateways cur-rently available are based on LDAP [6] and thefunctionalities of this protocol may also be foundin the X.SOO, our model is also based on theLDAP protocol. As a consequence, the elementsdescribed match the. parameters of the LDAPsearch operation.

Therefore, at the low leveI, an external schemawill be defined by the configuration of the follow-ing variables or meta-information elements:. initial DIT position. scope. filter. attributes (a list of the attributes to be re-

turned from each entry found). service elements (eg. sizelimit, timelimit or

derefAliases).

546 R.J.P. José et ai. / Computer Networks and ISDN Systems 28 (1996) 543-550

4.2. High leveI elements

AIthough very powerful, the low leveI elementsare not very adequate for user manipulation andthey provide no layout information. Therefore itis desirable to have the possibility of specifying aX.SOOservice in terms of higher leveI elements.During operation most of these elements will bemapped onto lower leveI elements as shown inFig.2.

High leveI elements are nearer the user andwhat is perception of a service definition mightbe. Instead of dealing with filters or other proto-col related parameters, a user defines a service byproviding answers to questions such as What arethe only object classes that should make part oJ myservice universe? or What are the essential at-tributes that ali the objects must have in arder to beincluded in my service universe?

A first set af high leveI elements has to do withdata access. Its goal is to define the subset of theX.SOOinformation that will constitute the serviceumverse:. Mandatory object classes: this service element,

when defined, determines that only objects ofthe indicated classes should be considered asbelonging to the service universe. This elementis mapped onto the low leveI element filter byadding a condition like objectClass =ClasseType for each mandatory class. For in-stance if person and role were defined asmandatory object classes then a condition ob-jectClass = person ar objectClass = role would

Data access

High levei elements ~---.------Low levei elements

( SCOPE

be automatically included in the filter of everysearch operation. As a consequence, only en-tries of those object classes or sub-classes wouldbe returned. Browse operations however couldbuild a filter that also allowed for the return ofNonLeaf objects in order to maintain naviga-bility.

. Mandatory attributes : if defined, establish thatonly entries containing at least one of theseattributes will be considered as part of theservice universe. Once again a browse opera-tion may be the exception by including Non-Leaf entries. If one intended to define anexternal schema for a telephone directory ser-vice, the attributes telephoneNumber and Jac-simileTelephoneNumber would be good candi-dates for mandatory attributes. The mappingonto the lower leveI elements would beachieved by adding to the filter the conditiontelephoneNumber = * ar facsimileTelepho-neNumber = *. In this way, entries not contain-ing any of these attributes would not be re-turned.A second set of high leveI elements concerns

data presentation. They configure the display ofservice data to the user in some appropriatefashion. The choices made here will affect thefunctioning of the list view and the entry viewreferred to in the description of the conceptualinterface discussed in Section 3:. Entries sorting method: defines the order in

which entries are listed in a list view by select-ing the attributes used to determine that order.

Datapresentation

~

possible mapping

~

:---1 OUKIINb I probable mappingIII~-----------------------III,I,

(DIT POSITION ) ( SERVICE ]ELEMENTS

Fig. 2. Mapping high leveI onto low leveI configuration variables.

R.I.P. José et ai. / Compu ter Networks and ISDN Systems 28 (1996) 543-550

In principIe, because there is no way of con-trolling the order in which entries are re-turned, this is not mapped into any lower leveielement and must be implemented by theclient. In order that a sorting operation bepossible, an implementation decision mightchoose to force the return of the attributesselected as sorting keys by including them inthe low level element attributes to get.

. Displayed attributes: this variable gives an indi-cation on the attributes that should be dis-played when presenting entries. An orderedlist may be used to give an additional indica-tion of the appropriate order in which to pre-sent these attributes. This will be mapped intothe lower levei element attributes to get. Thereshould be one for entry views and another forlist views.

. Hidden attributes: in some cases it may besimpler to indicate which attributes should notbe displayed. This is a very useful facility if oneintends to specify a rather generic service but

. wants to hide attributes that are considered ofno interest to the application, like, for in-stance, administrative attributes. In principie itapplies only to entry views.

. Naming style: when presenting an entry's name,different styles may be adopted. At least 3styles should be allowed: DN for the full Dis-tinguished Name, RDN for the entry's RelativeDistinguished Name and BaseDN which is anincomplete DN starting from the DN of theoperation base objecto The use of UserFriendlyNaming [7] may also be considered which wouldincrease the possible values for this variable.Although name style configuration may be ap-plied to entry views it may be more use fui inlist views.

. Attribute labels: the aim is to choose someschema to indicate what labels will be used toidentify the names of the attributes to the user.The basic approach consists of just indicatingwhether attribute labels should or should notbe presented. A more elaborated mechanismmay include a choice among several languagesor any other criteria. The external schemashould allow different values for list and entryviews.

547

5. Implementation of the model

The elements referred to so far are only thoseconsidered to be more generic and which do notcompromise the model with any particular imple-mentation. It is important to notice however thatwhen it comes to a particular implementationmany other meta-information elements may beincluded using the same concepts as long as theymake sense in that particular contexto

Some of such elements were not included inthe general model because they depend too muchon the interface programs being used. An exam-pIe of such an element would be that whichconcerns cache parameterization.

Other elements are not clearly application spe-cific and therefore it should be an implementa-tion decision whether to associate them with acertain external view or noto

A good example is a LDAP server. In principleit would be configured on a per installation basisbut there might be some advantages in doing soon a service basis. For example, to choose aserver that is nearer to the information to beconsulted, and therefore faster, or to distributecomplete configurations among beginner users.

5.1. Document oriented DUA

The dodua implementation has been pro-grammed in Windows. The service concept isimplemented through the use of document files.Each document stores the meta-information asso-ciated with a certain service. Accessing a givenservice is achieved by opening the correspondingfile. A user working with dodua can have severalpersonal documents each one tailored to a spe-cific information domain.

The document approach has two great advan-tages, namely:. A user is completely free to create whatever

documents he considers he may need.. A manager can use his knowledge of Directory

Services in general and of his organization inparticular to create complex documents whichmay then be distributed among users. WhenDUAs are installed they may already include aset of documents enabling novice users to im-

548 R.J.P. José et aI. / Computer Networks and ISDN Systems 28 (1996) 543-550

zecuzarcoWWWwepviriatovegaum-dns-secum-dnstermX6termX5termX4

jfm[~H

o=Universidade de Lisboa. c'o=Universidade de Coimbra.o=Laboratorio Nacional de Ero=INESC. c=PTo=Gestao do Servico de Dire.o=Fundacao de Calculo Cient,

Fig. 3. A sample dodua screen with three open documents.

mediately access X.SOOinformation in such anintuitive way as opening a file.Another advantage of the use of documents as

the basis for meta-information is the large amountof meta-information they allow to store. The cur-rent dodua implementation goes far beyond theelements defined in the previous section. In eachdocument it includes meta-information likeLDAP servers, a service name and description,user information, several hotlists, cache parame-ters and parameters of program behavior.

The document model might even go beyondmeta-information and support downloading of in-formation itself like in the SWIX 7 implementa-tion.

Fig. 3 shows a sample dodua screen.

5.2. Service oriented Web gateway

SOW is an adaptation of the web500gw 8. Newoperations were added to support the notion of

7 SWIX is developed at UMDAC (Umdac, Umea Univer-sitet, Sweden).

8 web500gw was written by Frank Richter, Technical Uni-versity of Chemnitz-Zwickau, Germany.

multiple services. These new operations work witha special URL format in which the query string isused to carry meta-information variables. Thelack of an accepted URL syntax for the X.500protocol led us to define our own syntax. Thissyntax however is stilI under development andother related work like the one used in the SOLO[8] project is also being considered. The querystring syntax is a list of configuration variables inthe format variableLabel = variableValue sepa-rated by the / signo Some variables alIow forseveral values which must be separated by acomma like in the folIowing example:...MandOb = person/LiAttr

= teIephoneNumber ,mailThe available variables alIow the user to define

the service information universe by settingmandatory objects or attributes and by specifyinga generic fiIter and operation scope. They alsoallow to setup the display of information in termsof displayed attributes and respective labels foreither entry view or list view. When the resuItingpage is returned, its DN links also come with thesame meta-information appended in the querystring. In so doing service parameters are kept forthe time of a user session.

RJ.P. José et aI. / Computer Network.<; and ISDN Systems 28 (1996) 543-550

A possible scenario for this gateway is aCWIS 9 in which instead of the generic link toX.500 information severallinks could be set up tomore specific services like the classical telephonedirectory or a list of host computers. More detailsabout SOW are available at:

(URL:http:j jinfo.uminho.ptj -ruijsow.html)

6. Conclusions

Our experience with a user defined serviceinterface has shown that, after aIl, it is nice tohave the X.500 world on your desktop but it is alot of weight to be there at the same time, spe-cialIy when alI one wants is to get hold of thetelephone number of someone working in one'sbuilding. The provision of adequate views istherefore an essential element in the design ofDUIs and can be specialIy useful to support di-rectory applications that have reached a certainstability in terms of users and information con-tent.

The model described seems to obviate to someof the problems which have been pointed out asthe cause of the little use of network applications[9]:. It gives the users a method of producing ser-

vices that respond to their requirements.. There is no conflict between complexity and

flexibility in terms of protocol operation. Al-though they remain related, it is easy to set theright balance by defining more or less complexservices.

. The X.500 protocol becomes more hidden fromusers.The updating of information is not considered

in this paper because not enough experimentalwork has been done yet in this area. Howeverthere are some obvious benefits that could be

9 Campus Wide Information System.

S49

gained with the extension of this model to updateoperations like the inclusion of templates on theservice definition.

The concepts described can also be extendedto other types of interfaces like report generatorapplications similar to the ones that exist in mostDatabase Systems.

Refereuces

[1] Robbins, C. and Kille, S., The ISO Development Environ-ment: User's Manual. Version 7.0, X-Tell Services Ltd.,UCL, 1991.

[2] CCITT BIue Book, Data Communications Networks -Directory - Recommendations X.500-X.521, ITU, 1988.

[3] Elmasri, R., Fundamentais of Database Systems, BenjaminCummings, Menlo Park, Calif.

[4] Barker, P., DUA Metrics, RFC 1431, UCL, February1993.

[5] Date, c.J., Database Systems, Addison-Wesley, Reading,Mass.

[6] Kille, S., Yeong, W. and Howes, T., X.SOOLightWeightDirectory Access Protocol, RFC 1487, Performance Sys-tems International, University of Michigan, ISODE Con-sortium, July 1993.

[7] Hardcastle-Kille, S.E., Using the OSI Directory to AchieveUser Friendly Naming, Draft Document OSI-DS 24, UCL,January 1992. Work in Progress from the OSI DirectoryServices (OSI-DS) Working Group of the IETF.

[8] Zahm, A, Huitema, c., Pays, P-A and Woermann, A,Simple Object Look-up Protocol (SOLO), NetworkingWorking Group, October 1994, Internet-Draft, INRIA, TSE3X.

[9] Waugh, A, Where are the Network Applications?, Tech-nical Report, CSIRO Division of Information Technology,1994.

Rui José graduated in Systems andInformatics Engineering in 1993 atthe University of Minho, Braga, Por-tugal, and is currently finishing up hisMasters Thesis with the ComputerCommunications Group of the De-partment of Informatics. He has beeninvolved in several projects on X.SOO,WWW and Information Services.

550 R.J.P. José et aI. / Computer Networks and ISDN Systems 28 (1996) 543-550

Antônio Costa is Assistant Lecturer inComputer Communications at theUniversity of Minha,. Braga, Portugal.He graduated in Systems and Infor-matics Engineering in 1992 at thisuniversity and is currently pursuingpost-graduate studies in network in-formation services and protocols. Hehas been involved in several R&D

projects under contract with theComputer Communications group inthis area.

Joaquim Macedo is a Lecturer ofComputer Communications at theUniversity of Minha, Braga, Portugal.He graduated in Electronics andTelecommunications Engineering in1983 at the University of AgostinhoNeto, Angola, and received his Mas-ters degree from the University afMinha in 1993. From 1990 until 1994he participated in several technicalworking groups for the establishmentof the Portugese National R&D Net-

work, the RCCN, and was particularly active in the develop-ment of X.500 Directory Services. He is currently doingresearch for a Doctoral degree where his interests concernnetworked information and directory services and protocols.

Vasco Freitas is Associate Professorof Computer Communicatians at theUniversity of Minha, Braga, Portugal.He graduated in electronic andtelecommunications engineering in1972 at the University of LourencaMarques and received his M.Sc. andPh.D. degrees from the University ofManchester (UK) in 1977 and 1980respectively. From 1989 untill994, ona partialleave from his university, hewas appointed a member of the Board

of Directors of the Portugese National Foundation for Scien-tific Computing, where he had the opportunity to foster theestablishment of the Portugese R&D Network (RCCN). Herepresented the national networking initiatives for R&D inthe RARE Association, DANTE and Ebone from their begin-nings until recently. Currently, his interests concern net-worked information services and protocols and the specifica-tion, modelling and prototyping of communication protocols.