1. Overall purpose
The purpose of a Z39.50  to Web  gateway is to combine the power of Z39.50 for search and retrieval from heterogenous systems with the ease of use provided by the Web. These gateways usually have to make compromise when interfacing Z39.50, a stateful protocol, with HTTP  which is stateless. The functionality and flexibility of these gateways can therefore not be compared with those of a dedicated Z39.50 client. However, the gain in ease of use and accessibility (every one has a Web browser) usually makes up for these inconveniences.
2. Brief overview of functionality
The functionality of a Z39.50 to Web gateway can be split in three distinct sets:
Set of Z39.50 Services supported
All gateways support the core services (Init, Search and Present)  although the type of records supported (MARC  , GRS-1  , SUTRS  ) varies from gateway to gateway. Some gateway support Browse, a few, more advanced services such as Sort and some extended services.
Set of communication facilities
This includes things like support for sessions, reuse of z39.50 associations, parallel search of multiple targets, etc.
Set of gateway services
This is not a finite set. It includes all the gateway functionality used to provide services not directly connected to z39.50. These can be divided in sub-sets:
Query formating and adaptation
Including processing of HTML forms (of varied complexity) and formating of queries. Support for multiple profiles.
Including the formating for various record types (*MARC, GRS-1, SUTRS) to various output formats for presentation, printing or downloading.
Facilities linked to parallel searching
This includes merging of result sets for presentation, grouping and de-duplication.
For example, storing of queries and/or records in a private set, alerts, etc.
The gateways we know all support different sub-sets of the functionality described above and some functions (e.g. reuse of z39.50 associations) can be implemented with varying efficiency by different gateways.
Following is a list of gateways with a brief description about the functionality supported. This is non-exhaustive and only includes gateways freely available as a software package. The level of information presented below varies a lot from gateway to gateway because of the lack of specific information in the documentation and sometimes the lack of documentation altogether.
Gateway package from the Europagate Consortium. Supports Search, Browse, Present (MARC), parallel search, sessions, reuse of z39.50 associations. Record presentation is handled through a TCL script. Although still in use, this package is no longer developed.
Gateway package from IndexData . Supports Search, Browse, Present (MARC, GRS-1), parallel search, reuse of z39.50 associations. Zap is template driven and runs as an apache module.
Gateway package from Technical Knowledge Center of Denmark (DTV) . Zebril was design as a replacement for Europagate and therefore supports the same functionality plus present of GRS-1 records, more advanced query formating, support for multiple profiles, result set merging. Zebril is screen driven with special tags embedded in HTML files.
Isite zgate 
Gateway package from CNIDR . Supports at least Search and present with some re-use of of z39.50 associations. The documentation does not go in-depth about the functionality provided.
Gateway package from Simon Fraser University Library. Supports at least Search, Scan, Present, Print/email formating, Result set combination, private set. There is no information about re-use of z39.50 associations but some of the functionality offered implies some kind of state/session management.
The Stanford WWW to Z39.50 Gateway 
Supports at least Search, Scan and Present. The documentation does not go in-depth about the functionality provided.
3. Strengths and weaknesses
As mentioned earlier, the strong point of using a Z39.50 to Web gateway is the combination of the strength of Z39.50 for search and retrieval and the ease of use of the Web. Z39.50 is of course not the only networked method for search databases but it is often a preferred solution because it is standard and very well deployed in the bibliographic database area. The combination with the web allow for simple user interfaces which can be developed and adapted rapidly. It also allows the running of multiple front-end (e.g. with different user interfaces) on a single set of databases forming a central system. Because of that last advantage, the Z39.50 to Web gateway is a perfect tool for system where databases are setup and maintained in collaboration but each participant would like its own front end (i.e. its own view) on the collaborative system.
The weak points are the limitations imposed by the Web which makes it very difficult to have a dynamically updated user interface. For example, when searching multiple databases, one may want to display results as soon as they come from any database and then dynamically merge in results from the slower databases. This type of operation is difficult and cumbersome to due in a pure Web environment. The use of Java  and a second communication channel  between the client and the gateway can help to bridge some of these problems. This is usually done at a cost in simplicity and ease of deployment of the resulting service.
4. Related standards
There is no standard for interfacing Z39.50 to the Web although there are a number of standard way to interface applications with a Web server. The gateways compared above make use of these standards (CGI  , Fast CGI , Apache modules , ) for interfacing the Web server.
A more relevant question may be, is there competing standard to those interfaced by these gateway. It is doubtful we can find an alternative to the Web but we could consider the following:
Complements and Alternative to HTML
Cascading Style Sheets (CSS) 
To offer better user interfaces and a better rendering of records
May be useful for record presentation mostly in combination with other technologies to allow record formating on the client side.
Could be used either in query formating, to allow the simple construction of complex queries, or in record presentation, mostly for dynamic merging of results as discussed earlier.
To allow simple user interface improvements.
Complements and Alternative to HTTP
As mentioned earlier, there is a possibility of setting up a parallel communication channel between the browser and the gateway to cover for some of the problems due to the nature of HTTP. Java RMI is just one example, there may be other, more appropriate methods.
As for Z39.50, it seems to be only standard protocol for search and retrieve of bibliographic data. There use to be some discussion about a RDF  search protocol which would have had similar properties as Z39.50. We could not find any recent information on the development of such a protocol.
5. Relevance to Renardus context
The basic RENARDUS architecture is specifies Z39.50 as the search protocoll and WWW as the user interface. This naturally makes a Z39.50-to-WWW gateway an important component in RENARDUS. The possibility to search several databases simultanously over a network opens up a lot of possible implementation options.