Web Service Interfaces to Earth System Modeling Framework Components
Participants
Kathy Saint/ESMF Core Team, Gerhard Theurich/ESMF Core Team, Cecelia DeLuca/ESMF Core Team
For questions on this project, please contact curator@list.woc.noaa.gov.
Motivation
The climate and weather communities are increasingly being asked to interface with regional projects. The coupling within a climate model is very different from that which occurs within smaller multidisciplinary studies. Historically, the ESMF team has focused on more tightly coupled models with high frequency and high volume data exchanges but with the advent of this work, we have begun to focus on smaller systems that run on distributed, often Windows-based platforms with reduced data exchange. Our motivation is to enable ESMF to interface with these loosely coupled applications and to make it easier to run ESMF components on systems like the TeraGrid or in workflows that include visualization and data processing.
Web services are a technology that can be attached to both loose and tightly coupled applications, minimizing their differences by leveraging the Internet as a means of bridging geographic and communication barriers. Web services can be written in Java, which is a platform-independent programming language. This addresses the challenge of dealing with different operating systems. Additionally, web services follow standard protocols that are universally accepted across browsers and web server configurations. They are the equalizer for the loosely coupled application.
Approach
ESMF's approach to solving the loose coupling problem is to provide a set of classes and tools that allow a component developer to make their component web-accessible. These classes and tools include:
- A set of classes in Fortran and C++ that support socket/network access to ESMF Components
- A Process Controller application that manages client access to networked ESMF Components
- A SOAP interface that provides access to the networked ESMF Component using standard web protocols
System Architecture
The figure above describes the software architecture for ESMF Web Services. Each of the boxes represents an executable, and the color represents the language it's written in (red=Java, blue=Fortran, green= C++). The boxes within an executable are the libraries/modules involved in making a component web accessible.
The Component Service executable is the wrapper for the Component to turn it into a service, and the libesmf library provides the interface for the service.
The Process Controller executable is responsible for managing the client access to the Component Service. (The role of the Process Controller is expected to expand in the future.)
The Tomcat/axis2 executable supports the use of the SOAP protocols that provide access to the Component using web technologies. The SOAP implementation uses the Component Connector library to communicate with the Component Service (via the Process Controller) on the backend.
The Registar allows a Component Service to register itself with the web interface, so that Web clients can dynamically discover the available services. The Component List XML file is just a simple database of available Component Services.
Caveats
ESMF Web Services is still a work-in-progress and there are some limitations to the current system:
- The Component Service must be manually started and stopped. Future plans include having the Process Controller be responsible for controlling the Component Service processes.
- While data can be streamed from the web server to the client, it is not yet getting the data directly from the Component Service. Instead, the Component Service exports the data to a file which the Process Controller can read and return across a network interface. Future plans include streaming the data from the Component Service.
References
- A description of the architecture via graphs (Download PowerPoint)
- Interface and Class guide
- User's Guide
