WORLD METEOROLOGICAL ORGANIZATION
COMMISSION FOR BASIC SYSTEMS

THIRD MEETING OF THE INTER-PROGRAMME TASK TEAM
ON FUTURE WMO INFORMATION SYSTEMS

FINAL REPORT

LANGEN, GERMANY, 25 - 29 JUNE 2001

DISCLAIMER

Regulation 42

Recommendations of working groups shall have no status within the Organization until they have been approved by the responsible constituent body. In the case of joint working groups the recommendations must be concurred with by the presidents of the constituent bodies concerned before being submitted to the designated constituent body.

In the case of a recommendation made by a working group between sessions of the responsible constituent body, either in a session of a working group or by correspondence, the president of the body may, as an exceptional measure, approve the recommendation on behalf of the constituent body when the matter is, in his opinion, urgent, and does not appear to imply new obligations for Members. He may then submit this recommendation for adoption by the Executive Council or to the President of the Organization for action in accordance with Regulation 9(5).

CONTENTS

1. ORGANIZATION OF THE MEETING

1.1 Opening remarks
1.2 Adoption of the agenda
1.3 Working arrangements

2. PROPOSED VISION OF FUTURE WMO INFORMATION SYSTEMS
3. REVIEW OF RELEVANT DECISIONS OF CBS-XII AND EC-LIII
4. REVIEW OF TECHNOLOGIES AND PROJECTS APPLICABLE TO FUTURE WMO INFORMATION SYSTEMS
5. PILOT PROJECTS AND FURTHER DEVELOPMENT
6. CLOSURE OF THE MEETING

The third meeting of the Inter-programme Task Team on Future WMO Information Systems was held 25-29 June 2001 in Langen, Germany.

The task team considered the guidance on Future WMO Information Systems provided by CBS-XII and EC-LIII. It felt that the functions of the three levels of centres developed at its previous meeting were in line with the guidance it had received and that no major changes were required. However, it clarified and expanded the presentation of these functions in a revised description of the Future WMO Information System included in the appendix to this report.

The experts dedicated considerable discussion to the requirements and capabilities of less developed versus more developed NMHS. They noted that NMHS span a range of capabilities and developed a proposed path to improved capabilities that NMHS could follow as WMO migrates to its future information system. It felt that small and developing NMHS with few resources should be able to deliver and receive all required information through inexpensive PC-based systems relying upon satellite broadcast and dial-up connections to the Internet. Although e-mail does not guarantee timely delivery of data, it is an extremely inexpensive solution for many small NMHS and should be recognised as a legitimate mechanism for small and/or developing NMHS to provide data to their RTH for injection into the GTS and the Future WMO Information System.

The experts reviewed current and emerging technologies that could have an impact on development of the Future WMO Information System. This included the rapid proliferation of the Internet and its associated technology, low cost satellite communication systems, and Extensible Mark-up Language (XML). Regarding open-source software, the team felt that WMO could benefit from the experience the open-source community has gained in the collaborative development of software and recommended increased efforts to involve the university and research communities in collaborative software development.

The team considered steps that should be taken to further develop the Future WMO Information Systems and reviewed possible mechanisms to conduct and evaluate pilot studies. It developed proposals for the following pilot projects.

• Use of the Internet Data Distribution system from Unidata to disseminate U.S. satellite data from Bracknell to other NMHS in Europe. The Russian Federation and South Africa will also investigate the possibility of running pilots using the IDD.
• Investigation of promising software systems that could lead to an inexpensive system that can display and manipulate meteorological and related data and products in small NMHS including: METGIS from South Africa, METCAP from Turkey and the EMWIN custom browser from the USA.
• UNIDART had the possibility to provide an important component of the future request/reply capability and the system should ensure it is compatible with the WMO metadata standard that is being developed in parallel.

The task team agreed that development should continue along three parallel paths: development of the catalogue of products, proof of concept through pilot tests and upgrade of the GTS. It developed an outline of the highest priority tasks along with estimated target dates.

The catalogue should be the highest priority since it is essential for the implementation and maintenance of a modernized WMO communications system. The WMO directory-level metadata standard should be developed by the end of 2001, followed by a implantation of pilot catalogue by third quarter of 2002.

The experts felt that it is not necessary to standardise the physical links and protocols to be used between WMO centres. Instead, there should be a number of standard protocols available that could be agreed on a bilateral basis. Approved technologies for routine dissemination for the Future WMO Information System should be selected by 2004. The target for beginning phased implementation of the Future WMO Information System would be 2006.

1.1  Opening remarks

1.1.1  The third meeting of the Inter-programme Task Team on Future WMO Information Systems opened at 0900 on Monday 25 June 2001 at the Deutscher Wetterdienst (DWD) Training and Conference Centre (BTZ) in Langen, Germany. Prof. G-R. Hoffmann (Germany), chair of the team, opened the meeting. Mr S. Mildner, on behalf of the Permanent Representative of Germany to WMO welcomed the participants to BTZ and Germany and wished them a productive and successful meeting. Mr D. McGuirk welcomed the participants on behalf of the Secretary-General and briefly outlined the objectives of the meeting.

1.2  Adoption of the agenda

1.2.1  The meeting adopted the agenda as reproduced in the beginning of this report.

2.1  The experts carefully reviewed the vision of the Future WMO Information System developed at their previous meeting. During this discussion the team considered the role of the information system as a whole and which aspects of the WMO Information System were within its remit and which were not. The team agreed that collection of information and dissemination of products within national boundaries were beyond the scope of its terms of reference and these issues were not discussed in detail in further deliberations of the meeting.

2.2  It was noted that the Future WMO Information System will continue to rely upon the WMO communication system to provide highly reliable and timely delivery of data and products. Currently, this requires a private network but this may change as public communications services evolve. Today's WMO communication system is the GTS and its evolution is being considered by the Expert Team on the Enhanced MTN.

2.3  The meeting dedicated considerable discussion to the requirements and capabilities of less developed versus more developed NMHS. Regarding the collection of information from less developed NMHS, the group felt that this consisted of relatively small data volumes, mostly of observational data and metadata as well as text-based forecasts and warnings. Although small in volume, these were primarily time-critical data.

2.4  The meeting noted that it is increasingly difficult to maintain slow analogue dedicated lines, particularly in more developed countries. In most cases where this has been a problem, the receiving RTH, was the first to experience a problem since these lines were considered to be obsolete by its telecommunications supplier. At the same time a great many NMHS now have connections to the Internet, although many, particularly in developing countries, rely upon relatively slow dial-up connections. The group noted that there are a number of major international efforts aimed at improving access to the Internet from developing countries. Therefore, it expected the connectivity of NMHS to the Internet to continue to improve.

2.5  The group was informed that a significant number of small NMHS now provide their observational data to their responsible RTH via e-mail over the Internet. This mechanism has proven to provide reliable and, for the most part, timely delivery. For small NMHS in some Regions, this currently provides the most cost-effective mechanism, in terms of technology and communications costs, to exchange their data and products with other NMHS. The experts agreed that the use of e-mail is greatly facilitated where the observations within the messages are encoded according to WMO standards. They furthermore noted that e-mail can support transmission of binary data (such as BUFR) as attachments. Use of e-mail could, therefore, contribute to the migration to table-driven binary data representation forms.

2.6  Although it must be remembered that e-mail does not guarantee timely delivery of data, it is an extremely inexpensive solution for many small NMHS. With this in mind the group had the following recommendations:

• E-mail should be recognised as a legitimate mechanism for small and/or developing NMHS to provide data to their RTH for injection into the GTS and the Future WMO Information System
• Observations sent via e-mail should be formatted in accordance with WMO standards. Where possible, BUFR format via attachments to e-mail messages could be used.

2.7  The meeting noted that more developed NMHS require a higher volume of information and products to be delivered in both real and non-real time. It agreed that these centres would likely rely upon both public and private network services to meet these requirements. These NMHS need a system that guarantees timely, reliable delivery of information, such as the current GTS. Any future system should also be flexible enough to accommodate collection of real-time data from all WMO Programmes and non-operational systems, such as research experiments, when relevant.

2.8  It is expected that less developed NMHS would require character-based data and products, graphics, and a limited amount of binary data, especially gridded model output. The experts felt that current and planned satellite broadcasts would meet the needs of the majority of small or less developed NMHS for the near future. It was expected that any additional requirements would consist of a small volume of information that could be disseminated via e-mail.

2.9  Currently, virtually all NMHS in Regions III and IV receive the necessary information via ISCS STAR4 systems and Region V and western sections of Region II are covered by EMWIN and SADIS. Within a few years, Region I will be covered by the MSG and the PUMA project as well as SADIS. The meeting recommended that NMHS that rely upon these systems should utilize the Internet as a backup delivery mechanism. Therefore, it suggested that all of the products delivered via these satellite broadcasts should also be made available via the Internet. It was pleased to note that all EMWIN products were already available and access to WAFS products is available for backup purposes.

2.10  The meeting concluded that small developing NMHS could rely upon e-mail for delivery of their own information to WMO and satellite broadcast and e-mail for collection of their required products. Thus,

2.11  Small and developing NMHS with few resources would be able to deliver and receive all required information through inexpensive PC-based systems relying upon satellite broadcast and e-mail. Thus, initially not requiring operation of a GTS message switch. The experts agreed that larger and more developed NMHS would require larger products, particularly model output and satellite products, which would require higher capacity communications. In general, existing satellite broadcasts (SADIS/ISCS, MDD) would not be sufficient and delivery via additional mechanisms would be required. These centres would require a permanent connection to the WMO communication system and/or a high-speed Internet connection and would require operation of a message switch or system with similar functionality.

2.12  The meeting emphasized that a WMO catalogue of products is essential for the implementation and maintenance of a modernized WMO communications system. The catalogue will be a core system for data product discovery, request-reply systems, and will facilitate near real-time configuration of current and future message switching and routing systems.

2.13  Noting that a catalogue of WMO products that could be searched on-line via the Internet is an essential component of the Future WMO Information System, the experts considered the required contents and capabilities of this catalogue. They agreed the catalogue should:

• Contain descriptions of all products (including data sets) routinely disseminated by the Future WMO Information System
• Contain descriptions of all other products available for exchange
  (National Centres would not be expected to contribute descriptions of the products they offer to their own users although they may find the structure of the WMO catalogue could be applied to their requirements)
• Be viewable via a Web Browser (e.g. Netscape or Internet Explorer)
• Support queries and replies in multiple official WMO languages
• Be on-line and available 24 hours per day, every day
• Be available at multiple centres so there is not a single point of failure
• Be updated and maintained in a timely manner.

2.14  The experts further agreed that for each product (including data sets) the catalogue should include:

• An abstract of the product, including the general type of data it contains
• A unique standard WMO product identifier and mapping to current GTS abbreviated headers where applicable
• The physical parameters or variables contained in the product
• The area covered by the product
• The time period covered or validity time and date
• The level of quality control / validation applied
• Whether the product can be delivered routinely (subscribed to), and whether particular authorization is required for this subscription
• Whether the product is intended for global or regional exchange
• Conditions that apply to the delivery or use of the product (including charges that may apply)
• The size of the product or its component files
• Dissemination mechanisms or media that are supported for the product
• The data representation used (the format or file type)
• For operational products the availability schedule
• Whether or not subsets of the product can be selected
• Suppliers of the product
• The originator or source of the product.

2.15  The catalogue should be accessible world-wide via a standard Internet browser but it may contain items or support functions that could be restricted to certain users or user groups.

2.16  Every Global Information System Centre (GISC) should support an entry point or portal to the catalogue. Details on the contents (such as the availability of data for a particular station at a particular time) and access to the actual data should probably be provided by a system operated and maintained by the data supplier. It may be closely associated with the catalogue of products or may be a separate system.

3.2  The team considered its new terms of reference and comments on the proposed vision that were made by the Commission and the implications of these decisions on its future work programme.

3.3  The team noted that a presentation on the Future WMO Information System was made by the president of CBS to the fifty-third session of Executive Council. In the presentation he informed the Council of new obligations that would arise under the proposal. The Council agreed that it was essential that WMO develop an information system that could cost-effectively serve all WMO Programmes. The Council asked CBS, in cooperation with the other technical commissions, to explore technological opportunities through the use of limited pilot projects and to continue to further develop the concept for the future WMO information system. The Council asked CBS to take account of the following during this development:

• NMHS in developed and developing countries are increasingly separated by a gap in technological capability. The future WMO information system should help to narrow rather than widen this gap. The technology used should, therefore, be easy to use and inexpensive to install and maintain;
• There will be a continuing need for system support and training, particularly in critical areas of Regions I and II;
• Despite any shortcomings it might have, the current WMO information system is secure and reliable. Any future system must also be secure, stable and reliable;
• The current WMO information system is organized, operated and controlled by NMHS. This presents certain advantages that need to be considered in a future information system;
• Systems and capabilities have already been established or are being planned by other WMO technical commissions.

3.4  The Council emphasized that a number of policy issues are associated with a Future WMO Information System. In particular:

• WMO objectives and policies must be considered in every WMO activity. These issues must be reflected in the organizational structure of the future WMO information system;
• The possible impact of the introduction of a future WMO information system on Members’ responsibilities and resources must be carefully studied;
• A smooth transition to the future information system must be developed to ensure there is no interruption in essential services;
• The extent to which the functions and responsibilities of existing infrastructure and centres should be used or revised should be investigated.

3.5  Although the task team felt that these policy issues were beyond its terms of reference, it considered the guidance on Future WMO Information Systems provided by Executive Council throughout its deliberations. It agreed that the functions of the three levels of centres developed at its previous meeting were in line with the guidance it had received from CBS and EC and that no major changes were required. However, it felt that the description and presentation of these functions were perhaps confusing or insufficiently detailed and should be expanded and clarified as follows:

• It should be explicitly stated that the description of the vision for the Future WMO Information System is a logical description and that one physical centre could perform the functions of all of the centres defined. Likewise, several physical centres could cooperate to perform the functions of a single logical centre.
• Specialized Product Centres may also have a responsibility to collect data and products intended for regional dissemination. To ensure this responsibility is explicit, they should be renamed Data Collection or Product Centres (DCPCs). Examples of DCPCs would include World Meteorological Centres, RSMCs, Argos, etc.
• It should be clearly noted that GISCs and DCPCs have a responsibility to ensure that they have procedures and arrangements in place to provide swift recovery or backup of their essential services in the event of an outage (due to, for example, fire or a natural disaster).
• The dissemination of routine products from GISCs should be flexible and employ a mixture of technologies. This could include satellite broadcast, multicast, and store and forward hierarchies. The latter should be more clearly illustrated in the diagram describing data and product dissemination.
• GISCs should provide facilities to collect observations from the least developed NMHS within its area of responsibility (i.e. via e-mail)
• GISCs and DCPCs should describe their products according to an agreed WMO standard and should either provide access to this catalogue of products or provide this information to another centre with this responsibility (e.g. a GISC)

3.6  The experts considered the text and diagrams used to describe the data flows in the report of the team’s previous meeting and felt that they did not adequately illustrate some aspects of this data flow. It agreed that some additional information should be provided. In particular, links indicating the flow from DCPCs to GISCs as well as an illustration of a hierarchical dissemination tree should be added to the diagrams.

3.7  These recommendations have been addressed within the revised description of the Future WMO Information System included in the appendix.

4.1  The experts reviewed current and emerging technologies that could have an impact on development of the Future WMO Information System, including technologies that were presented at the CBS Technical Conference on WMO Information Systems and Services. This included the rapid proliferation of the Internet and its associated technology (TCP/IP, routers, Web browsers), low cost satellite communication systems, including digital radio, portable programming languages (Java), Extensible Mark-up Language (XML), etc.

4.2  Extensible Mark-up Language (XML) is a relatively new language for encoding documents and data sets. XML describes a class of data objects called XML documents and partially describes the behaviour of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalised Mark-up Language [ISO 8879]. XML is rapidly being developed for a wide range of applications, including document production, dynamic creation of HyperText Mark-up Language pages (HTML), and intersystem data exchanges. XML, a tagged mark-up language similar to HTML, is the universal format for structured documents and data on the Web. XML is mainly intended to allow users to define terms and variables in their own documents, thus allowing them to encode the information of their documents or data much more precisely. The format of XML allows the XML document to be searched by an "XML aware" program or browser, permitting the dynamic processing of the data. In contrast, HTML only defines how documents should be presented for display. XML allows application programs to also determine the intended meaning of data within a document. Thus, data values within an XML document could be given meaning. For example, documents could include values defined as latitude, longitude, elevation, etc., thus enabling applications to search for documents that pertain to user-defined geographic areas.

4.3  The meeting considered the possible applicability of XML to WMO requirements in detail. It noted that XML is being widely embraced by the wider Internet community, and that many commercial software systems will include support for XML. The group agreed that the utility of XML for exchange of metadata is very clear and it was pleased to note that the CBS ET on Integrated Data Management was considering XML as an important component of its work on a WMO metadata standard.

4.4  The team also considered the possible use of XML for the exchange of data (rather than metadata). It felt that XML offered a number of capabilities that warranted further investigation, perhaps by the ET on Data Representation and Codes. In particular, they noted that XML could be used to encapsulate data encoded in WMO representation forms. This would be very useful for BUFR since the identifying information could be provided in XML so the BUFR message would not need to be decoded to determine its contents. Likewise, XML could provide an envelope to collect multiple BUFR messages. This would provide the capability to repackage the messages without having to decode them.

4.5  The experts also felt that XML has the potential functionality to provide an alternative character representation to CREX. The future of CREX should be reconsidered in this light.

4.6  The experts agreed that XML is a very important language that will have a significant impact on the transmission of information over the Internet. Standard tag names and definitions for meteorological and related parameters will be needed. A foundation for these standards already exists in the form of the WMO code manuals, especially the BUFR and GRIB tables. If WMO does not actively address this challenge then other groups in the commercial and educational communities are likely to seize the initiative and the results may not be the best solutions to WMO requirements.

4.7  The meeting noted that the bandwidth and coverage of the public Internet will continue to grow. Nonetheless, bandwidth will always be a problem. The output from numerical models, particularly ensemble prediction systems, will continue to grow. For the foreseeable future there will still be a need for transmission priorities and, therefore, limitations may be placed on what products can and can not be widely disseminated. Within the near future the concept of "defined quality of service" is likely to be offered over the Internet. This would provide guaranteed bandwidth for certain time periods, available at relatively short notice. When this service becomes widely available it may be cost effective to use this service in place of dedicated lines. This is likely to have a significant impact on how the WMO communications system is implemented and operated.

4.8  At some point in the not too distant future the WMO communications system will probably be required to evolve to recognize no difference between public and private networks. As the market changes it may not be possible to rely upon a private network being cost-effectively available. Therefore, the WMO communications system would have to be designed to operate reliably and securely over the public Internet. This would require increased attention to all aspects of security. For example, procedures would have to be put in place to protect against "denial of service" attacks.

4.9  The experts considered the proliferation of open-source software and operating systems. They noted that Linux, an open-source operating system was extremely reliable, robust and easy to install. Open-source database management systems, such as PostgreSQL are also available. The experts felt that this software development technology offered the possibility of very inexpensive yet powerful software and recommended that well-tested open-source solutions be considered whenever they are available.

4.10  The meeting noted that the wide use of UNIX, Linux and Windows has made it much easier to write software that can be easily ported to a variety of hardware. Furthermore, the Internet makes development through open-source collaboration much easier and more effective.

4.11  The group felt that WMO could benefit from the experience the open-source community has gained in the collaborative development of software, such as arbitration of proposals through expert groups assigned to specific topic areas. It noted that it was difficult for staff within NMHS to participate extensively in open-source software development given the existing pressures on their time. Thus, the experts recommended increased efforts to involve the university and research communities in collaborative software development. Universities have a large pool of talented and technologically sophisticated people who, suitably motivated, could make a significant contribution to WMO. This idea is pursued further in section 5 below.

4.12  The UCAR Unidata Office is distributing meteorological data via the internet to more than 150 universities in North America using a system called the Internet Data Distribution (IDD) system. They originated this service in 1995 and have continually improved the reliability and features of the software that is distributed at no cost to qualified members. The IDD contains TCP/IP protocols that are managed by the Local Data Manager (LDM) software that establishes and maintains data transmission between a data providing server and a local host. Transmission of data is reliable and currently handles traffic of more than 150 Gbytes daily.

4.13  The system is similar to the WMO’s Global Telecommunication System (GTS). Both systems handle data from multiple sources, are configurable, and allow any site to inject data into transmission streams. A major advantage of the IDD is that it is freely available and utilizes communication protocols that are fully supported by industry standards.

4.14  The IDD employs a ‘store and forward’ hierarchy of data flow. Data recipients establish connection with a data provider using the LDM. These recipients, in turn, supply data to other recipients, also using a LDM process. Transmission reliability is maintained during communication link outages through the use of data queues residing on each computer supplying data. Time stamps applied to each data product are used to determine those products that are transmitted to data receivers. Upon automatic notification of a re-established communication link, unsent products residing in the queue are sent to the data receiver. Currently a 2Gbyte queue is used to store data products.

4.15  The LDM ingests data products based on standard WMO message headers or other unique product headers. Using this header information and ‘pattern-action’ statements the LDM manages product storage and/or processing. Multiple processing procedures can be applied to single products. Thus, a product can be automatically printed, sent to another recipient, or sent to an external program for decoding or display.

4.16  The LDM runs on many Unix operating systems and has been tested on systems developed by IBM, DEC, HP, SGI, and SUN Microsystems. It also runs on commodity-class PCs that use the Linux operating system that offer an attractive low-cost solution for data processing. An active IDD user community is available to assist users with technical and operational questions regarding a wide range of issues. Unidata staff have an established history of providing prompt answers to those issues not resolved by the user community.

4.17  The IDD handles a wide range of data stream types that include data from the NOAAport data feed, GOES imagery, lightning reports, wind profiler data, high-resolution model output, radar data, difax products, and additional data sources supplied by Unidata members (images, tabular data, summary reports, etc). Any product encapsulated within a recognizable header is possible to send and receive.

4.18  Data transmission reliability is monitored by Unidata using near real-time graphics that give a visual display of network latencies. Under normal network conditions these latencies are normally less than 5 minutes to any point in the network. However, if problems occur that degrade performance at a particular location the system can be reconfigured within minutes to provide alternative sources to time-critical data.

4.19  Unidata continues to provide active development for the system and is looking to improve support to next generation networks (very broadband network systems), including support for Reliable Multicast Protocol, and has plans to incorporate on-demand requests for specific data products. Unidata commitment to the IDD ensures that this system will serve the needs of the meteorological data community.

4.20  Among the various hydrological programme components within WMO's Hydrological and Water Resources Programme, MED-HYCOS (Mediterranean Hydrological Cycle Observing System, http://medhycos.com ) is one of the more advanced projects in the field of new information applied to the implementation of regional hydrological information systems.

4.21  MED-HYCOS Project is one of the regional components of the global programme WHYCOS (World Hydrological Cycle Observing System), launched by WMO. The first phase of MED-HYCOS (1995-2001) was supported by the World Bank and co-ordinated by a Pilot Regional Centre hosted by Institute of Research for Development (IRD, formerly ORSTOM) in Montpellier, France.

4.22  The main objectives of the initial phase of the project MED-HYCOS were concentrated in four areas:

4.24  The main challenge of the next phase (2002-2005) will be to transfer from regional level to national level the technologies and the expertise developed during the initial phase. The expected results will be the implementation of a Mediterranean Water Resources Observatory based on distributed national databases using the newest technologies (XML, Java, etc.) and managed and updated by National Hydrological Services (NHS) themselves.

4.25  The individual HYCOS components serve primarily the needs of NHS in a specific region. Therefore, the established hydrological information systems are different using GTS or Internet. Integrated and standardised information concepts are going to be developed to serve all HYCOS components and to be linked with the Future WMO Information System.

4.26  The main aim of UNIDART (Uniform Data Request Interface) is the development of a system, which allows all interested users an on-line access to, in principle, all meteorological data and products. In its broadest sense the UNIDART system could be seen as a marketplace for meteorological data and products where there are users and providers. Both have different requirements on the marketplace and so it is with UNIDART. On the one side there exist the users. A user wants to have a user-friendly and personalised way to the data he is interested in without knowing where the data exactly comes from. Providers of data and products need to incorporate their data from multiple, disparate data sources. Further they have to agree on metadata standards in order to enable a seamless exchange of information. Finally, providers must keep the control over their data and products. They need to know who receives which data.

4.27  The requirements of the users are best realised with the concept of Enterprise Information Portals (EIP). In contrast, the requirements of the providers could be either met by Data-Warehouse systems or by servers for virtual databases.

4.28  EIPs offer a solution for providing an efficient, centralised, personalised, and cost-effective way to access and profit from structured and unstructured data within and external to the enterprise. Contextually relevant information will be delivered to each user in a customisable manner that respects the security and privacy of the individual content. EIPs were first mentioned in a Merrill Lynch report in November 1998 where they are defined as follows:

Enterprise Information Portals are applications that enable companies to unlock internally and externally stored information, and provide users a single gateway to personalised information needed to make informed business decisions.

4.29  An EIP is seen as an opportunity to consolidate, manage, analyse, and distribute applications and information across and outside of a company. It will enable the enterprise to connect all three parties participating in a process in a Web-browser environment.

4.30  UNIDART plans to use virtual databases, which can solve the problem of incorporating data and information from multiple, disparate data sources. They allow the integration of relational, network, indexed, hierarchical, object, and flat data, no matter where it resides. Further a virtual database provides users a transparent, uniform SQL interface to access the data just as if it were a standard relational database. Thus, application developers can query several data sources with one single SQL statement. The results are delivered to any application via XML, JDBC or ODBC protocol. This offers the possibility to -enable web access to legacy systems and to open enterprise information to Intranet and Internet applications.

4.31  Multicasting, the simultaneous transfer of data to multiple recipients, is becoming one of the key technologies for content distribution. Deployed today in local area and many well-managed corporate networks, it is becoming available in larger parts of the Internet -- enabling efficient distribution of information up to millions of recipients.

4.32  So far, multicast has mainly been used to distribute audio and video streams, where small amounts of packet loss do not cause a problem. It is significantly more difficult to transfer data based on the best-effort IP multicast service reliably. This makes it hard to exploit the benefits of multicasting -- significantly reducing network bandwidth requirements, minimising transfer delay and reducing the load on the transmitting servers -- for data distribution applications.

4.33  MDiS provides a multicast-enabled platform for distribution services. The core of the platform is MTP/SO, a proven multicast transport protocol based on the Internet RFC 1301. In MDiS, MTP/SO plays the same role for multicast content distribution as TCP does for the unicast FTP file transfer service. MTP/SO provides a socket-style programming interface, which facilitates its use by many applications.

4.34  The DWD is setting up a MTP/SO based multicast-service for its data-distribution. The solution will interface with the AFD (Automatic File Distributor) Software used for internal and external file-exchange.

4.35  It should be noted that multicast is currently restricted to use over private networks. The public Internet rules prohibit the use of multicast protocols but this restriction could be eliminated when technological barriers are resolved.

4.36  In the DWD there is a great demand for distributing its products from the headquarters to all its regional centres and customers. In the beginning, scripts were used to distribute files via FTP. However, this concept proved to be not very efficient and flexible. Thus the DWD decided to develop its own file distributing system AFD (Automatic File Distributor) which has the following features:

• The AFD can handle the protocols FTP and SMTP directly, which effectively means that it has its own FTP and SMTP-client. This proved to be a very important feature since it made the control and monitoring of file distribution much more flexible. Portability was also increased with this feature since there is no need to take care of any implementation dependent features of the client that comes with the implementation.
• A single configuration file with which the administrator can control the distribution of files. The configuration file holds the information about which directories the AFD has to monitor and how files are to be distributed when files appear in this directory. These files can then be distributed to more then one recipient with different options.
• It can handle parallel transfers. If a big file is currently being transferred it is still possible to send a smaller more important file in parallel. Net capacity is always limited. To overcome this limit files can be sent with a priority.
• The AFD is not required to receive files. The receiver only needs an FTP-daemon.
• When errors occur the AFD will retry until the file has been successfully transmitted or (if configured) deleted if the file has reached a certain age.
• Extensive log files are kept so that each file that has entered the AFD can be traced. It is also possible to monitor the files that each recipient receives.
• There is a very compact and efficient graphical user interface (X11) with which the administrator can monitor and control each recipient.
• The code has been written entirely in C and ported to Linux, SGI, FTX, SunOS, HPUX and SCO and is distributed under an open-source license (GPL).

4.37  There are now more then 80 installations of the AFD in the DWD which distribute three million files with 240 GBytes of data daily.

4.38  Web-Werdis (Web-Weather Request and Distribution System) is a special service of the DWD to distribute meteorological data via the Internet. The range of products is limited to essential data (ASCII or binary) and OPMET-data. All data are distributed as files (compressed or uncompressed) containing standard WMO messages. The data can be sent immediately on request or on a subscription basis using various transmission protocols such as e-mail, ftp, etc.

4.39  Web-Werdis is a distribution system without a billing tool but including the logging of transfers. The current implementation is based on classical web-programming (html, perl, javascript, cgi).

4.41  Until the availability of a more general WMO product catalogue, Web-Werdis may be used as a pilot.

5.1  The meeting considered steps that should be taken to further develop the Future WMO Information System and reviewed possible mechanisms to conduct and evaluate pilot studies. It developed the following proposals for pilot projects.

5.2  The meeting felt that the Unidata IDD showed sufficient promise that it should be evaluated through a pseudo-operational pilot project. That is, it should be used to deliver data or products that are needed for operational use but can not currently be delivered via the GTS. It considered several possible candidates for a pilot. It agreed that a pilot running in a small developing NMHS would provide valuable information on the IDD’s ability to deal with a difficult communications environment. However, it felt that this would not be the best opportunity since it would be difficult to ensure the system could be maintained and operated by staff with little or no experience with Unix or Linux.

5.3  The group agreed that the dissemination of U.S. satellite data from Bracknell to other NMHS in Europe would be an excellent opportunity to evaluate the IDD. It would give these NMHS first-hand experience with the IDD and LDM software while delivering a data product that is needed but can not presently be delivered over the GTS. The chairman agreed to pursue this idea further with other European partners.

5.4  The Russian Federation and South Africa will also investigate the possibility of running pilots using the IDD. They will arrange the details on a bilateral basis with their potential partners and the WMO Secretariat will provide assistance coordinating with Unidata if required.

5.5  The meeting agreed that there was a pressing need for an inexpensive system that could display and manipulate meteorological and related data and products in a small NMHS. The system should work on a single, standard self-contained PC and should be very easy to operate and maintain by staff with little technological expertise. The software on the system should be available at no cost and should be of "shrink-wrap" quality. That is, it should be downloadable or provided on a CD and be as easy to install and run as commercial software.

5.6  The group noted that there were a number of meteorological software systems that met several of these requirements but none that met all. It urged that promising candidates be further investigated including: METGIS from South Africa, METCAP from Turkey and the EMWIN custom browser from the USA.. South Africa agreed to provide a copy of the METGIS software to other members of the task team who will evaluate and perhaps integrate the software into a pilot request/reply system using a prototype WMO product catalogue.

5.7  The meeting felt that further work on developing specifications for such a system, evaluation of systems that could be used and integration into an operational pilot system should be undertaken and recommended that WMO seek support for a consultant to carry out this work. The team felt that such an activity would require a few months of effort.

5.8  The experts also noted that the PUMA project would be installing workstations in nearly every NMHS in Africa. They felt that this provided a unique opportunity. It should be possible to include a simple meteorological display system, to plot SYNOP data as a surface chart for example, as an additional application on these workstations. It urged team members with contacts within Eumetsat, and the Secretariat, to investigate this matter further.

5.9  The experts agreed that the UNIDART was an interesting concept that had the possibility to provide an important component of the future request/reply capability. They noted that the project was still in its formative stages and urged the development team to ensure the system that is developed is compatible with the WMO metadata standard that is being developed in parallel. It was pleased to note that the project manager of UNIDART was a member of the CBS ET on Integrated Data Management, which has been tasked to develop the metadata standard, and was thus in a position to make sure the two were compatible.

5.10  The task team considered steps that could be taken to further develop the Future WMO Information System. It agreed that development should continue along three parallel paths: development of the catalogue of products, proof of concept through pilot tests and upgrade of the GTS.

5.11  The catalogue should be the highest priority since it will be the single most important component of the future information system. The evolution of the store and forward system and implementation of the future request/reply system both depend upon the catalogue to define and manage their products. The team recommended that the ET on Integrated Data Management be tasked to develop a prototype implementation of the WMO product catalogue based upon its proposed metadata standard as a proof of concept. It also recommended that the ET on the Improved MTN and the ET on Enhanced Utilization of Telecommunication Systems take note of the development of the catalogue and should be aware that this would provide a new mechanism to manage data flow. Furthermore, over the next year or two plans for further development of the MTN and plans for the Future WMO Information System should be harmonised so that both are directed towards a common goal.

5.12  The experts felt that it is not necessary to standardise the physical links and protocols to be used between WMO centres. Instead, there should be a number of standard protocols available that could be agreed on a bilateral basis to best match the requirements and capabilities of the parties involved. For example, routine dissemination could be implemented via store and forward to some NMHS, via multicast to a second group and via satellite broadcast to others. However, there should be only a small number of standard protocols. Otherwise, the information system would become unmanageable.

5.13  The team noted that once a new technology is agreed upon, its implementation would have to proceed regionally. That is, its use would begin with a single centre acting as a source of data and products and one or more centres receiving this data stream. The use of the new system would then grow with the addition of more supplier and recipient centres. As the system is implemented "suppliers" would need to translate from the existing WMO headers and messages to the new product identifiers and files on the boundaries.

5.14  The team recommended steps toward implementation as given below.

The meeting closed on Friday 29 June 2001.

Appendix - Revised vision of the Future WMO Information System