Brunel Home EuroView Home Deliverables

8. Procurement

8.1 Evaluating Server Software

Ensure that software adheres to standard protocols and that interoperability has been demonstrated and proven. If interoperability is of sufficient quality then you should be able to select from a range of products. This means, for example, that you?ll have the freedom to purchase server and client software from different vendors. Similarly you?ll be able to choose products that match available platforms, which will be useful if your organization is a mixed hardware environment. As well as allowing you to select different products to match different needs, it means that other organizations can access your directory using their software. Most vendors submit their software to interoperability tests and you should ask for the results of these.

Although it is tempting to apply a `shopping list' of features that you know about, you should only worry about functionality that you really need. Many offerings based on the X.500 standard, for example, will not actually implement the entire standard, only a practically useful subset. In cases where a future need has been identified, a complete access control system let`s say, ensure that a commitment to future development exists. Unfortunately, such promises are easy to make and even easier to break! Looking at current vendor roadmaps may be the best, or only option.

Here are some of the areas that you will need to check on for functionality, interoperability and performance:

• Database read performance. Ask for demonstrations that show how well the product performs with large databases. The ability to run a search quickly through a large number of entries is important. You will also need to note down how well servers cope when large numbers of users are connected.
• Access control and, if required, strong authentication. If possible ensure that configuration tools for access control are present, otherwise security management will be a scripting job and therefore require special work.
• Replication. DSA performance is especially important if extensive data shadowing is required. If the DSA slows appreciably during shadow update operations then service levels will be reduced.
• Are any data loading or synchronisation tools supplied with the server? Will they interface directly onto your existing databases, or does an intermediate conversion process need to be defined?

Interoperability is again important. The freedom to mix and match is fundamental as it improves accessibility and ensures that many different applications can make use of the service (and thus increase its value).

Desktop integration is high on the list of plus points. User interfaces will ideally work with the applications staff are using now, e.g. word processors, calendar/diary managers and e-mail interfaces. Again, clients that employ non-proprietary methods of integration are advisable as these will co-operate more easily with standard software.

It may be appropriate to look at clients specific to an application. E-mail interfaces in particular may have an associated directory component that is capable of accessing your service. Latest versions of the popular communication suites from Netscape, Lotus and Microsoft are examples.

The following general requirements should be addressed:

• Functionality

• Look and Feel

• Will the client support the types of searches required? Are search algorithms and filters configurable in terms of the attributes that the user can search on?
• Does the client support browsing? How are size limits handled by the browsing interface?
• Is the client capable of supporting all of the attributes that the organization requires? (E.g. does the client support `labeledURI', `photo', etc.?) Is it capable of presenting the information in the required (user-friendly) format?
• Will the client integrate with the desktop in a standard way? MAPI, for example, is an address book API under Windows that many e-mail interfaces support. Are there any other (possibly proprietary) ways of pasting addresses into the recipient field? The more generic the integration method the greater the range of applications that will be able to talk to the interface.
• Does it support LDAP or is it a pure DAP/X.500 implementation? Though DAP interfaces have some advantage over LDAP, e.g. DAP can support strong authentication, LDAP tools are more widespread and off the shelf packages are available.
• Does the client run on the specific platform(s) required by our organization? Will it preserve the local look and feel?
• Is secure access provided? If so does it support strong authentication (or something similar)?
• Does the client provide data management functionality? If so, does it support the required level of functionality (i.e. addition, deletion, modification and renaming of entries)?
• Is the client configurable for access to the global directory? Will it handle references to external DSAs?

Begin by estimating levels of usage, using this to determine the hardware requirement. It's probably better to overestimate somewhat in order to allow for future growth and to allow for underestimates. Also be wary that relying on vendor produced figures may not provide a realistic assessment of software performance under real world conditions - such as how things run under a peak load, or over a period of days and months.

Other factors are the level of resilience required and the overall size of the database. If resilience is an issue then backup machines may be needed.

It may be possible to combine a directory service with other services on the same machine, but the demands of each service must be considered if service is to be maintained.