The SCOOP Service-Oriented Architecture wbr Executive Summary

SCOOP Architecture Team DRAFT – 6 Nov 2005 The SCOOP Service-Oriented Architecture Executive Summary Coastal and ocean observations provide critical information for protecting human lives and property from marine hazards, enhancing national and homeland security, predicting global climate change, improving ocean health, and providing for the protection, sustainable use, and enjoyment of ocean resources. While the technology currently exists to integrate data gathered from a variety of sensors deployed on buoys, gliders, ships, and satellites, implementation of a sustained, national Integrated Ocean Observation System (IOOS) is overdue and should begin immediately.” (U.S. Commission on Ocean Policy, 2004). The U.S. Commission on Ocean Policy, quoted above, provides a concise and relevant rationale for implementing a national Integrated Ocean Observing System (IOOS). The National Office for Integrated and Sustained Observations, Ocean.US, is currently responsible for planning the IOOS, including developing an implementation plan and a data management and communications (DMAC) plan. The SURA Coastal Ocean Observing and Prediction (SCOOP) program is helping to implement the goals of the IOOS and the plans developed by Ocean.US by laying the foundation for a broad effort to support community collaboration on shared scientific goals. The SCOOP program is an outgrowth of a vision proposed by SURA University Trustees, and endorsed by the Southern Governors Association in February 2002. The vision was to create an open access network of distributed sensors and linked computer models for the southeastern coastal zone. SURA is uniquely suited to implement this vision by bringing together the extensive and widely dispersed intellectual talent of the coastal science and computer science communities at SURA universities to address the challenges of creating such a network. The concept of a service-oriented architecture is both an outgrowth of the early advances in information technology that enabled SURAnet1 and a framework for future evolution of the World Wide Web. The concept is also increasingly recognized by the Ocean.US DMAC Steering Team as a framework for creating the IOOS. The SCOOP service-oriented architecture reflects the combined effort of a team of coastal and computer scientists from SURA institutions working for over a year to implement the initial elements of the system. Each stage in the incremental implementation revisits design requirements that reflect lessons learned in earlier stages. The basis for system requirements are being developed from a set of core use cases that reflect both the research and operational needs of an information system that can integrate environmental observations with predictive models. Common elements of the various use cases are organized into modular components that interact with one another through well-defined application programming interfaces (APIs). The basic system components include numerical models, information catalogs, distributed archives, computing resources and network 1 Southeastern Universities Research Association NETwork. It provides networking services for a variety of industries. SURAnet was one of the United States largest regional internet providers. It was acquired by BBN in 1994. 1 SCOOP Architecture Team DRAFT – 6 Nov 2005 infrastructure. Coordination of these system components and management of multi-purpose workflows is accomplished by using best-of-breed technologies (proprietary or open source) based on open standards. The distributed nature of the system components leads to a heavy emphasis on web services. The SCOOP service-oriented architecture will provide a costeffective a framework for broad collaboration that can be operated, maintained, improved and utilized for both research and applications. 2 SCOOP Architecture Team DRAFT – 6 Nov 2005 1 Introduction The most recent major initiative at the Southeastern Universities Research Association (SURA) is the SURA Coastal Ocean Observing and Prediction (SCOOP) program. The SCOOP program is implementing community information services and technologies to advance the sciences of environmental prediction and hazard planning for our nation’s coasts. The first step toward achieving this vision is to help integrate the diverse data flows from a variety of ongoing efforts in coastal ocean observing. The second step is to incorporate these data flows into an openaccess, scalable, modular and distributed real-time environmental prediction system. This document motivates and describes the underlying service-oriented architecture for this community resource. The key design philosophy involves breaking the overall system into a set of modular components and standardizing interfaces that connect them together. This produces a system comprised of a collection of components, each providing a set of services or functionality that can be used to achieve multiple goals. This approach will enable teams of scientists from different disciplines and different institutions to work together to achieve goals that they would not likely achieve on their own. 1.1 Meeting a National Need The death toll and costly damage caused by Hurricanes Katrina and Rita emphasize the need to improve our nation’s ability to rapidly assess, predict, and mitigate the impacts of large storms. As part of a relatively broad goal of rapid environmental assessment and prediction, we must improve our ability to quickly and accurately measure and forecast phenomena such as storm surge and waves. Equally important, we must assure that these capabilities readily support the practical requirements for hazard planning and response. The SCOOP service-oriented architecture will provide the capability to achieve these goals. Toward this end, the SCOOP infrastructure will support short-term forecasts, integrate models with real-time observations, and serve results based on standards that enable access, interpretation, and incorporation into decision-support tools. Moreover, the architecture will support design requirements for a national infrastructure of distributed sensors and predictive models that integrate regional and national observing systems along the coasts. This concept supports the President’s Ocean Action Plan and implements OceanUS principles for coastal systems that can become part of a Global Earth Observing System of Systems (GEOSS). 1.2 Practical Requirements for Environmental Prediction Emergency-response managers need information in advance of potentially catastrophic events. Accurate predictions can either mitigate the costs of disaster recovery or obviate the cost of unnecessary preparation. The information that impacts risk management usually involves measures of uncertainty about the future, and therein lies the challenge. Estimating the probability distribution of future environmental impacts is much more difficult than creating the single best forecast. They are related goals but the huge demands on High Performance Computing (HPC) arise in estimating uncertainty about future events. Estimating the associated probability distributions requires ensemble-modeling techniques, which means that computer simulations must be run not once, but many hundreds or thousands of times – once for each plausible outcome. The other challenge of real-time prediction involves integration of 3 SCOOP Architecture Team DRAFT – 6 Nov 2005 observational data from the myriad federal, regional, and local ocean observing programs. Aggregation and coordination need to be timely and reliable. The SCOOP program will address these challenges by creating an open-access infrastructure that will allow communities of scientists to work together to predict coastal hazards of all kinds. The initial focus on inundation from storms and hurricanes is intended to be extensible to a range of environmental phenomena. 1.3 Innovating Operational Systems The SCOOP service-oriented architecture involves a collection of modular components, each providing well-defined functionality and communicating with the other components across standardized interfaces. As with most modern distributed systems, the SCOOP architecture relies heavily on web-service interfaces to manage secure resources and data flows across the relatively insecure Internet. This is arguably the only cost-effective way to implement a comprehensive “system of systems” for observing and predicting the environment on a national or global scale. Moreover, the approach can solve a problem typical of many “operational” systems, namely, their inability to innovate. The practices of modularizing components and standardizing interfaces allows system components to be updated or replaced incrementally and in a “plug-andplay” fashion, without impact on other components or overall system operation. Achieving this goal requires breaking down stovepipes at a variety of levels, which can involve substantial initial effort. But the benefits can greatly outweigh the costs because of the resulting combination of innovation potential and practical application. With this approach, operational systems can become the focus for ongoing research and development by teams of coastal and computer scientists each working in complementary ways on a common architecture. The SCOOP vision is to support operational needs while becoming simultaneously interoperable with the various NSF-funded research programs that emphasize other disciplines in environmental science, including meteorology (LEAD), hydrology (CUAHSI), ecology (NEON), geology (GEON). Similarly, the SCOOP program should provide a coastal component to augment the global goals of the ORION program. 2 Design Requirements Design requirements are developed by considering a range of possible use cases. Extreme events will trigger ensemble calculations that bring all available resources to bear on the immediate needs of hazard response. The same system will support ongoing forecasts for use in day-to-day maritime operations. A retrospective mode with requisite data archives will support coastal research on past events. And a development and testing mode will support research, simulation and innovation of operational capabilities. These multi-mode requirements affect all aspects of the architecture, from computational resource scheduling to data archive, access, and transport. 2.1 Real-time ensemble prediction Real-time, ensemble prediction is a central focus because it introduces some of the biggest technical challenges for the architecture, as well as some of the biggest potential benefits. These techniques are increasingly common in weather forecasting, but they remain relatively uncommon for most other disciplines of environmental prediction. Two related premises drive the emphasis within SCOOP. First, real-time, ensemble-modeling techniques are fundamental to 4 SCOOP Architecture Team DRAFT – 6 Nov 2005 advancing our nation’s capacity for environmental prediction, and second, the enormous technical challenges can be overcome with a community infrastructure. The specific synthetic wind-ensemble use case considered here builds on information made available by the NOAA National Hurricane Center (NHC). NHC warnings are typically produced at 6-hour intervals over the lifespan of a hurricane. These warnings are commonly displayed as “probability cones” showing the likely zone of impact for several days into the future. Every time the NHC issues a warning, it will trigger the following automated sequence of events within the SCOOP architecture: 1. Synthetic wind-ensemble generation: The NHC-warning parameters are used to create an ensemble of forecast wind fields. Each of these wind fields represents a plausible set of forecast winds over the entire region of interest for several days into the future. A realistic scenario might involve an ensemble of tens to hundreds of such forecasts. The entire ensemble represents a probability distribution for winds that is consistent with the basic parameters from the NHC. 2. Each forecast wind field is used as input for numerical predictions of storm surge and wave fields. Each individual element in this ensemble of surge and wave predictions involves a numerical calculation that could take many hours on large supercomputer cluster, especially if the surge model predicts inundation with street-level resolution over large regions. Consequently, each of these predictions is farmed out to the distributed network available computational resources. 3. Results from each of the predictions in the ensemble are then aggregated for analysis. Results include maps that show the probability of inundation with detail down to the names of streets. 4. For verification, all relevant and available observations are aggregated and compared with predictions, which provides a real-time measure of accuracy and quality for the predictions. Many of these data flows exist within NOAA, but others may reside in USGS or other federal, regional, or local systems. 5. The results of the analysis are visualized and disseminated in a form that can be readily incorporated into decision-support tools used by emergency-response personnel. The value of the end product depends critically on the speed with which the complete chain of events completes. A break in any link in the chain can block the flow and leave the end users without the information they need. 2.2 Retrospective analyses Research, development, and testing require analysis of historical events. The SCOOP architecture will support these needs as well. As a typical use case, consider comparison of two different models for storm surge. The associated workflow might involve the following sequence of events: 1. A researcher previews and selects a collection of storm events for study. 2. Inputs into the analysis include the best-available historical wind fields, forecasts that were available during the storm, and the range of observations available from that time period for verification. 5 SCOOP Architecture Team DRAFT – 6 Nov 2005 3. Each of the two different surge and/or wave models are run with the available forcing inputs. 4. The model predictions are aggregated and compared with one another and with the observations using preview tools available in the system. 5. The results themselves are made available to the researcher for subsequent custom analyses, and stored in the archives for future use. Information relating to historical events exists in a wide variety of places and is increasingly available with dynamic mechanisms. A big challenge involves making these data discoverable and accessible. The notion of a single, centralized database does not make sense largely because of the management costs of centralization. However, a system that connects and documents existing distributed archives is very attractive. Innumerable research scenarios could lead to this type of use case. Various types of model intercomparison could involve different algorithms, spatial resolution or forcing inputs. The architecture should be capable of keeping track of such detail and document provenance of the various inputs and observations. 2.3 Continuous forecasts Not all predictive scenarios are event driven as with the wind-ensemble use case described above, nor do they require ensemble modeling techniques. For example, moderate winds can effect water level variations in ports and harbors. Predictions of this effect can be critically important for large ships that transit with less than a meter of clearance over the bottom. Similarly, the US Coast Guard is in the process of rolling out a new computer-based search and rescue software suite that depends on predictions of coastal water velocities on a 24/7/365 basis. The model and data translation and transport infrastructure, as well as model results running within SCOOP, provide exactly the type of data streams needed by this application. The SCOOP infrastructure supports continuous forecasts that meet these operational requirements. 2.4 Multi-disciplinary inundation In addition to storm surge and waves that have damaging effects on the coastal zone, the inundation problem can be dominated by precipitation and terrestrial hydrology. Thus, a comprehensive inundation prediction capability includes use cases with models developed in the hydrologic and/or meteorology disciplines. Although the individual components for such disciplines will differ in detail, the service-oriented architecture will readily accommodate them by allowing addition of new system components relevant to other kinds of models, model output, and analysis, as well as new services that facilitate coordination of the components for various specific workflows. This type of extensibility is a basic feature of the architecture. 2.5 Requirements Individual components of the SCOOP architecture modularize the functionality that is common to all use cases. Modularization facilitates subsequent organization and management of the components in a various ways needed to support the multiple use cases. These components include: • Coastal models that predict phenomena such as storm surge, wind waves and inundation, 6 SCOOP Architecture Team • • • • • • DRAFT – 6 Nov 2005 User interfaces that can be tailored to the needs of the users, Visualization tools that facilitate quick analysis of products, Data access, management and catalog services that support input and output to predictive or retrospective models, as well as comparison with observations, Translation and transport services that assure compatibility between the various data flows, regardless of their sources and destinations, Computing resources that can be organized to turn around huge jobs as quickly as possible, Archive services that store and document results. The next section provides a high-level overview of the architecture that implements these components and satisfies these requirements. 7 SCOOP Architecture Team DRAFT – 6 Nov 2005 3 SCOOP Architecture – Overview Layer diagrams provide a hierarchical framework for describing the basic functionality of a service-oriented architecture. The layer diagram in Figure 1 provides a high-level overview of the SCOOP architecture. Each layer in the stack comprises a set of components. The various components within each layer provide functionality that connects adjacent layers. The connections can be made in a variety of ways in order to support any number of different use cases. Figure 1: SCOOP Architecture -- Layer Diagram The uppermost “user-interface layer” interacts directly with end users and end-user tools, isolating them from the complexities of the underlying system architecture. Components in this layer may be tailored to the workflows of one or more specific use cases. Examples include web portals that spawn user-customized workflows and decision-support tools that automatically ingest information products from pre-configured workflows. The “application and tools layer” contains the various numerical models for predicting and analyzing environmental phenomena. This layer also includes data translation and visualization toolkits, and the actual workflow-configuration tools. Components within this layer generally interact with one another in a fashion that is coordinated by the workflow tools. The “management layer” enables workflows by coordinating components in the applications and tools layer and assuring that they have the necessary resources. In this role, the management layer coordinates access to physical resources in the system. Management services generally 8 SCOOP Architecture Team DRAFT – 6 Nov 2005 vary from one use case to another. Thus, management components need to be flexible and readily configurable to accommodate a range of possible workflows. The “resource-access layer” provides standard protocols that connect the management layer to physical computing, storage, and network resources. These protocols are particularly important for facilitating management of the distributed resources. Components include a combination of middleware protocols (e.g., Globus and WSRF), Web-service and data-transport protocols (e.g., SOAP and LDM), and lower-level networking protocols (e.g., TCP/IP and HTTP). The protocols in this layer can be further decomposed into sub layers, which results in protocol stacks (e.g., SOAP, HTTP, TCP, and IP). This sub-layer structure for resource access contrasts with the relatively complex interactions that occur in the application and tools layer. The “resources layer” includes all the physical resources for computing, storage, and network connectivity. For SCOOP, physical resources will be distributed over the Internet. Distribution introduces special challenges. For example, the importance and complexity of the cross-cutting components increases as compared to a system that resides on a single cluster of computers sitting behind a firewall. Also, resource-management challenges arise in heterogeneous environments, for example, when different hardware platforms require different operating systems. Virtualization interfaces within the resource-access layer provide an increasingly popular technique for dealing with such heterogeneities, but there is no panacea. Cross-cutting components provide functionality that spans multiple layers. In general, such cross-cutting components provide ancillary services that enable management-layer tasks. 4 SCOOP Scenarios in a Service Oriented Architecture Figures 2 & 3 show various SCOOP architecture components assembled into process chains (i.e., workflows) that perform the first two use cases described in Section 2. 4.1 Real-time ensemble prediction Figure 2 represents the event-driven ensemble prediction. Individual components have been color-coded to reflect their position within the layer diagram in Figure 1. A National Hurricane Center (NHC) warning initiates the sequence of events by triggering creation of the synthetic wind ensemble. These wind data enter the workflow through the resource-access layer. The winds are pushed into the transport layer as indicated by the thick solid arrow in the lower-left corner of the Figure. In general, the thick solid arrows reflect the workflow, dashed arrows indicate data flow (data include wind forecasts, model results and observations), and think solid arrows indicate management-service interactions. Monitoring and workflow services (not explicit in the Figure) assure that winds pass through a translation filter so that they can be used by the storm-surge model. At the same time, the wind ensemble is placed on the archive (archive services) and registered in the SCOOP catalog (catalog services). 9 SCOOP Architecture Team DRAFT – 6 Nov 2005 Figure 2: Real time event-driven ensemble prediction visualized on a web browser. The initiating event – the arrival of the forecast-wind ensemble – triggers the sequence of events that spawn the model runs. The sequence includes translation filters that assure that models can ingest the data. Archive services push the data into distributed archives and assure that these entries are registered in the SCOOP catalog. The resource selection service (i.e., resource management) identifies and selects the available computational resources, and launches the model runs across the distributed resources. Meanwhile, observation data are obtained from the appropriate source locations and/or archive. This resource-management task is facilitated by catalog services. As model results are generated, they are also pushed to the archives and to various verification and analysis tools. The Figure shows verification/validation services, which filter the model results so they can be compared with observation data. Finally, visualization services are used to render the model results and model-observation comparisons for display on the OpenIOOS web site (www.Openioos.org). 4.2 Retrospective analyses Figure 3 shows the workflow for the retrospective analysis described in Section 2.2. In this scenario, the sequence of events is initiated through the end-user interface (upper left), which specifies the desired outcome; the detailed sequence of actions and component interactions is determined by a workflow tool and the management layer. In this case, the wind fields are obtained from an archive service, which interacts with catalog services to locate and retrieve the historical fields via the resource-access layer. At each stage, transport services play a key role in the interaction of different remote components, and these interactions are implemented with Web services and supported by data transfer. The translation service delivers the winds in the form required by each of the coastal model components. 10 SCOOP Architecture Team DRAFT – 6 Nov 2005 For each model run there is a resource-selection process. Once the available resources are selected, the data and applications are staged to the appropriate locations. The transport services move the model results to the archives and to the verification and validation components. Figure 3: Retrospective analysis initiated by a scientist for research purposes. The remainder of the sequence looks like the wind-ensemble use case. That is, catalog and archive services are used to deliver the observational data for analysis and verification of the model results. For preview purposes and preliminary analyses, the verification/validation service extracts data points from the model results at locations corresponding to observation data points, and both sets of data are delivered to the analysis application (these capabilities are currently working on the OpenIOOS.org web site). The complete results are available for more detailed analysis by the user. 5 Architecture Components – Detail 5.1 5.1.1 Cross-cutting Components Directory Directory components provide services that enable discovery and location of data and resources throughout the system. The SCOOP Catalog, for example, includes a relational database that serves as a knowledge base for the wide variety of information to be shared among SCOOP users. The Catalog includes high level descriptions of SCOOP data collections (these can be published to national catalogs and clearinghouses), file-name conventions used within the program, information needed to access particular data streams, general characteristics and configuration parameters for SCOOP-enabled models, and metadata necessary to document model runs. In addition to this higher level information, the Catalog maintains an inventory of distributed data files (both observations and model results) and their locations, whether they reside in the SCOOP archives or with data providers external to the SCOOP architecture. 11 SCOOP Architecture Team DRAFT – 6 Nov 2005 The SCOOP Catalog can support many other SCOOP components. For example, future workflow orchestration tools may query the catalog several times for a specific use case to determine initialization parameters for a particular model and the location of wind forcing and observational data collections. Furthermore, SCOOP data and model products will be registered with the Catalog to provide a dynamic inventory to support automated query methods in other applications. These kinds of inventory services will be used to automatically configure the OpenIOOS portal as new products come on line. Additional directory services will be developed to support computing resources at the different SCOOP partner sites allowing an increasingly interoperable computational grid. These services, will, for example, support automated discovery of available computational resources, maintain shared information on authorized SCOOP users (e.g., grid certificates), and enable distributed shared capabilities. In the future, these directory services will allow SCOOP workflows to leverage data and model products in other discipline-specific projects (e.g., LEAD). 5.1.2 Monitoring Real-time and operational aspects of the system demand monitoring at all levels of the architecture stack. The associated monitoring services support a variety of management tasks. Monitoring allows the overall system to react to changing environments. For example, if the application is running on a resource that becomes overloaded or undergoes failure, unanticipated delays in completion could making the forecast product irrelevant for operational needs. In such practical applications where jobs must complete in time, monitoring services allow resourcemanagement services to anticipate the problem and spawn the jobs on an underutilized part of the system. Multi-layer monitoring allows these system components to respond to changes that could arise in the coastal environment as well, for example, if a hurricane were to suddenly divert to an area that required a different set of environmental prediction tools. 5.1.3 Security Firewall issues cause problems with data sharing, but security requirements increase substantially with sharing of physical resources for storage or computing, especially when the resources are distributed across multiple institutions. The SCOOP architecture will adopt community standards for these purposes. Work needs to be done to implement compatible authentication processes across multiple institutions, including maintenance of a federated directory service for authentication and authorization. The bridge certificate authority implemented as part of the NSF National Middleware Initiative at SURA and the Internet2 Shibboleth project serve as good examples of implementations available for consideration. Security policies will be brought into compliance with federal policy and specifications as standards emerge and software becomes available. 5.2 User-Interface Layer The user-interface layer serves as the typical user-entry point with several levels of sophistication that can be customized for specific users. Web sites and portals provide simple and easy-to-use access to a diverse set of tools including compute and data access. Workflow GUIs and command-line tools provide advanced users with mechanisms to access the resources and data from existing scripts and workflow tools. Web service application programming 12 SCOOP Architecture Team DRAFT – 6 Nov 2005 interfaces (APIs) provide standardized access to the widest variety of services available for custom use. The SCOOP portal and other interaction tools will provide access to models, computing resources, data and archives serve as a collaboration platform for scientists to share data and models enable management of user accounts, certificates and policies initiate authorization-based capabilities for model, data and back-end resources provide tools for workflow orchestration, data and information search, data visualization The targeted users include scientists, students and governmental decision makers. Custom decision-support tools from state and federal agencies will leverage open community-standard interfaces, such as those developed by the Open Geospatial Consortium (OGC). More and more tools are being developed to be OGC-compliant clients, and so will readily “plug into” the SCOOP product streams. 5.3 5.3.1 Application and Tools Layer Models and Analysis Tools Numerical prediction models and analysis software – the tools that implement a coastal science knowledge base built upon decades of research and development – provide the core components of the application and tools layer. Numerical models need to be retrofitted with standardized interfaces for input and output data streams, or wrapped with data-translation capabilities that serve the same purpose. Either approach allows multiple different models to be interchanged in a “plug-and-play” fashion. The goal here is to allow the SCOOP infrastructure to promote an open approach to community modeling and model intercomparison, as opposed to implementing or advocating a single community model. 5.3.2 Data translation The SCOOP architecture will accommodate coupling, nesting and general interoperability of numerical models developed and run by different research groups. The architecture can pass data between models, that is, the output of one model may become the input to another. To make this work with minimal impact on the model code, data-translation and filter services operate on data as they are transported between the modeling applications. These services include format conversion, region and parameter subsets, point extraction and re-gridding. Data translation services are available regardless of the point of origin (e.g., external to SCOOP or archived in the SCOOP catalogs). These services will be user-configurable to enable interactive workflows. Standardized interfaces for translation modules facilitate chaining together of the multiple components. Users will be able to (1) select from a list of available source data products, (2) select from a list of available translation functions and (3) submit the process as a workflow with the results being available either through the SCOOP transport system or at a repository location. 5.3.3 Visualization Visualization of SCOOP data products can be accomplished with any number of tools. Scientists will want the data and modeling results made available for their favorite analysis tools. In addition, the SCOOP architecture includes standardized interfaces and services for previewing 13 SCOOP Architecture Team DRAFT – 6 Nov 2005 results or meeting the needs of decision-support tools. The SCOOP program has found OGC specifications to be particularly useful for such purposes. The proof-of-concept test-bed Web site, OpenIOOS.org provides browser-accessible examples. Thick clients such as NASA’s World Wind are available as OGC-compliant data-visualization tools. We will also connect to published APIs that enable visualization by thick-client software such as Google Earth or Web mapping tools such as Google Maps. The SCOOP program will continue its emphasis on Web-based mapping standards and Geographic Information Systems (GIS) that facilitate display of high resolution digital elevation models (DEMs), land use/land cover databases, and other base layers that are needed to support visualization with street-level resolution. In some cases, and especially for time series, these mapping standards must be supplemented other mechanisms. For example, a simple filter for model output and an associated SOAP Application Programming Interfaces (API) has been implemented to support display of time series on the OpenIOOS web site. 5.4 Management Layer Components in the management layer allow users and applications to access and coordinate all aspects of the system. Collectively, the components assure that applications and tools have all necessary inputs, and that outputs are documented appropriately as they go to their intended destinations. Components in the management layer use protocols of the resource-access layer to manage data flows to and from the underlying physical resources. 5.4.1 Application Management One of the biggest challenges for distributed systems involves managing heterogeneous application environments. Even commonly available operating systems (e.g. Linux) can involve a variety of different kernels, distributions, libraries, packages and configurations. This heterogeneity can require that applications be re-configured to run correctly on each one, which can take hours of debugging and development. The associated administrative problems lead many operational environments to standardize on a single system configuration, which then becomes a form of stovepipe. An alternative approach is to engineer applications with portability in mind, which is standard practice for high quality open source software-development projects. The SCOOP program will accommodate heterogeneous resources by using directory services to document application characteristics and manage application environments. This will enable resource management to select compatible options for specific applications among all available resources. 5.4.2 Resource Management Resource-management components coordinate the distributed (physical and virtual) resources to support various applications that run on the system. Application requirements must be carefully mapped to resource providers’ expectations of how their resources will be used. The policies relate to resource availability and job scheduling, and must be compatible and prioritized in relation to the often distinct needs of local systems. The resource manager is critically dependent on services provided by the cross-cutting monitoring components. Monitoring enables dynamic scheduling decisions, which can impact overall system performance and reliability. Ensemble-modeling with deadline constraints, for example, can place severe demands on a gridcomputing environment. Resource must be selected from the available pool based on real-time 14 SCOOP Architecture Team DRAFT – 6 Nov 2005 measures of performance and reliability. The resource-selection process uses directory service to obtain dynamic load information. The combined characteristics of individual machines and running applications affect the selection process. Unanticipated bottlenecks in data flow or CPU availability need to be constantly monitored so that alternative resource options can be selected on the fly. Resource policies for many specific SCOOP scenarios need to be developed and tested. For example, in situations where the completion time is critical (i.e., the forecast is required more urgently), the ensemble-member selection, resource allocation and optimization must be done more carefully. Some of the resource-management techniques that have been identified as part of SCOOP use cases include: Replicating model runs to ensure at least one of the runs completes in time, Assigning relative priority to individual runs and allocating resources accordingly, Dynamically acquiring more resources as needed (e.g., from SURAGrid or TeraGrid), Real-time monitoring of the computing environments and adapting operations to exploit additional resources when they become available, Optimizing data movement between resources, Setting resource policies for coupled modeling. 5.4.3 Data Management Data management encompass a range of services need to coordinate observations and model input and output. These data will reside in a variety of places, including the SCOOP archives, the OpenIOOS database cache, and the myriad data providers external to the SCOOP program. Data management relies heavily on the SCOOP Catalog and associated directory services. The datamanagement component coordinates with resource management to assure that data make it to their intended destinations as efficiently as possible. 5.4.4 Archive management The SCOOP infrastructure and its data sources are sufficiently complex and distributed that concept of a single, centralized archive will quickly become impractical. Rather than create a centralized archive with copies of data from distributed systems, the goal is to establishing dynamic and standardized connections to existing repositories whenever possible and wherever they reside. At the same time, products created by SCOOP users will need to be archived with SCOOP resources, which will satisfy the requirement of enabling intercomparison of different models, or the need to compared results to observations in both real-time and retrospective calculations. In this sense, the SCOOP archives will provide the backbone for a variety of scenarios. The operational requirements can involve metrics and contingencies for reliability, failover and availability. The individual archive sites may hold limited file-level metadata, which can be supplemented by Catalog Services. Archives services will register and maintain accurate information about their data inventories at the SCOOP Catalog. Each archive will provide access services using several alternative methods (e.g. LDM, GridFTP, scp, etc) in order to meet the needs of the file requestor. 15 SCOOP Architecture Team 5.4.5 Workflow management DRAFT – 6 Nov 2005 As the SCOOP architecture matures and supports more complex use cases, workflow tools will become increasingly important These tools provide a coordinated mechanism to manage resources, data and application tasks. Some tools can provide an integrated environment that coordinates with the resource management toolset, provides the end-user workflow editing capabilities, executes model runs (including access control management), and visualization of on-demand workflow management. In the long run, complete workflow orchestration with one or more management tools will need to be integrated into the SCOOP Program. In the short term, the specific requirements for such a tool remain unclear. To the extent that the architecture is implemented with open community standards (e.g., W3C-compliant web services) and APIs remain stable, then a variety of workflow tools should be readily adapted as the need arises. At present, there are several options: TAMU has a fairly mature Web-based workflow tool developed for the oil industry, Indiana University’s workflow composer (developed as part of the NSF Linked Environments for Atmospheric Discovery program); Pegasus, a workflow system developed in the GriPhyN project; Wildfire; Kepler, developed by the ecological community; Taverna. 5.5 Resource Access Layer The Resource Access Layer provides the protocols that are needed to access the compute, storage and network resources. SCOOP leverages existing community protocols and tools such as web services, Globus grid services, etc. Some of these technologies reflect stable standards, while others are in relatively rapid state of development. The SCOOP architecture will adopt relatively hardened technologies to support practical and coastal research applications. New technologies will be adopted as they mature and as the need arises, and the system will support research and development of new technologies. In general, components that lie above the management layer in the stack need not change when such innovations occur in the resourceaccess layer. Thus, end users and applications may sense the benefit from changes in the lower layers, but they will have to do anything to accommodate those changes, thanks to the isolating effects of the layer architecture. This section provides a high-level description that groups various protocols into three categories: data transport, web services and virtualization. This categorization is somewhat arbitrary. As mentioned earlier in this document, a more detailed description of the resource-access layer would warrant further decomposition of the resource-access layer in the stack diagram (Figure 1) into a series of sub layers. 5.5.1 Data Transport Data transport protocols allow management components to retrieve and/or archive data using SCOOP storage and network resources. The user and applications need not concern themselves with the detailed mechanisms of data transport. Selection among the variety of options depends on the specific requirements. Options include the traditional File Transfer Protocol (FTP) which can move files from one location to another, the relatively high performance and secure GridFTP, and the OPeNDAP technology for server-side subsampling as an economic alternative to transferring large files. All of these technologies are in use with the present SCOOP architecture. 16 SCOOP Architecture Team DRAFT – 6 Nov 2005 The requirements of real-time prediction differ substantially from those of historical analyses, so different methods of data access and data transport may be necessary. The Local Data Manager (LDM) is a noteworthy option that has been implemented within SCOOP. LDM is an Internet “push” technology with an associated subscription service. The LDM was developed in the meteorology-research community and has been applied successfully to operational applications in weather prediction on a national and global scale. Within SCOOP, LDM moves data files to a variety of modeling locations as quickly as possible and triggers subsequent workflows. 5.5.2 Web Services A number of SCOOP services rely on web services that conform to the World Wide Web Consortium (W3C) standards. These services enable machine-to-machine interactions with XML technologies. For example, the Simple Object Access Protocol (SOAP) provides a particularly flexible set of capabilities that greatly simplify creation and maintenance of APIs for use in connecting components and managing resources. Web services become especially powerful when matched with community specifications with content relevant to coastal applications, such as those developed by the Open Geospatial Consortium (OGC). The geographic content included in OGC specifications have proven especially valuable for visualization and data-transport services such as those used to implement the OpenIOOS.org portal. As a standards-development body that includes academic, government and private-sector partners, the OGC is becoming increasingly useful and popular for coastal applications. Web services provide a general and flexible mechanism for implementing a variety of services and APIs. Unlike LDM, common web services typically employ “data-pull” strategies, which are usually adequate for retrospective analyses. Typical interactions involve “state-less” or one-timeonly interactions. State-less interactions turn out to be fairly limiting for many types of resource access, and there are numerous mechanisms for adding the property to web service interactions. The Globus Alliance is supporting development of the Web Service Resource Framework (WSRF) in an effort to standardize conventions for managing state so that applications can discover, inspect, and interact in standard and interoperable ways. The SCOOP architecture can readily adopt these kinds of standards for development and/or operational applications, as appropriate. 5.5.3 Virtualization Virtualization provides a relatively new approach to resource access that is being investigated by the grid community, as represented by the Globus Alliance and the Global Grid Forum (GGF). These protocols help cope with an overarching problem of heterogeneous resources in grid computing that arises when diverse sets of users seek to use resources from a diverse set of providers. Virtualization is one approach to dealing with this challenge that is being investigated in a development mode within the SCOOP architecture. The virtualization strategy is to decouple the software environment where applications execute (i.e., at the operating system level) from the software environment of the hosting physical resource. Resource-management components can request virtual resources through a virtual machine (VM) management service. This management service takes the specification of a virtual machine’s configuration and allows for creation, configuration, and termination of virtualmachine instances at run time. The service is based on two subsystems, one that serves as a 17 SCOOP Architecture Team DRAFT – 6 Nov 2005 front-end at a domain to take requests for virtual machines from clients, and a back-end component that is deployed on every virtualized resource to support dynamic management of VMs. While virtualization does impose overhead on the execution time of applications, these are typically small (around 5%) for CPU-intensive programs. In essence, virtual machine environments are configured independently from the software of a physical resource. For example, a virtual machine can run an operating system that is configured in an entirely different way from the physical machine. Provided that the hosting resources can support a virtual machine, which can itself pose a challenge, virtualization provides the ability for an application to be configured once, and deployed on many different resources while maintaining the resource provider’s expectations of how the resource is used. This extra layer of isolation from the physical resources can also be used to enhance security. 5.6 Resources Layer The resources layer includes the collection of physical resources for computation, networking and storage. Any one of the use cases described in Section 2 can introduce enormous demands on physical resources. However, as a shared community resource and as an operational tool, resource requirements could grow by several orders of magnitude. At present, the SCOOP architecture has been deployed at over a half dozen SURA institutions. The intention is to leverage established Grid activities such as SURAgrid, the Open Science Grid (www.OpenScienceGrid.org) and others, as appropriate. The SCOOP architecture design and implementation will allow these resource capabilities to be added incrementally. There will be challenges in doing so, but those challenges can be addressed without affecting existing applications. Likewise, recent developments around the country that are producing large amounts of Optical networking capabilities such as the National Lambda Rail (NLR) and Internet2, and various state-wide network projects such as the Louisiana Optical Network Initiative. These ultra-fast networks will greatly improve the performance and reliability as the SCOOP program grows. 6 Conclusions The SCOOP architecture is being implemented incrementally. The objective is to freeze overall system upgrades on 12-month cycle, and then revisit system requirements in light of operational achievements and system capabilities. Subsequent development and implementation is based on the most recent benchmark. Consistent with this approach, Version 2.0 of the SCOOP architecture was in place as of July 1, 2005. The OpenIOOS.org showed the predicted surge in New Orleans and Mississippi in advance of Katrina making landfall. Version 3.0 of the SCOOP architecture will be ready on July 1, 2006. This incremental approach mimics the so-called spiral implementation model used for enterprise systems engineering in industry. Details of the SCOOP implementation plan have not been included here. Another critical and overarching design principle involves adoption and implementation of open community standards. This is critical to assuring an effective partnership between the academic, governmental, private sectors. Partners must be committed to the notion that standards enable innovation, and that open standards enable partnership. More and more businesses are adopting this approach all the time (e.g., Google and Amazon through their published APIs). This principle should be contrasted with the concept of open source software, which can 18 SCOOP Architecture Team DRAFT – 6 Nov 2005 disenfranchise the private sector and marginalize the enterprise information systems already in place at many government agencies. The goal is neither to force such partners to adopt use open source software, nor to force them to make their software open source. Rather, the goal is to achieve interoperability among heterogeneous systems through the adoption of open standards for information exchange that can be implemented with either open source or proprietary solutions. As the system matures, operations and management needs will change. The small number of universities involved in the initial stages of deployment is growing to accommodate interest on behalf of interested scientists and institutions. Details of the associated governance of such a growing program have yet to be worked out, but the goal is to nurture broad participation in a range of focused activities that leverage and/or contribute to the underlying infrastructure. The goal is to also to leverage and interoperate with other systems as they come on line. In this sense, operations and management will involve processes that encourage community participation in both use and evolution of the system. The vision is a coastal analog of the Jefferson Lab (JLab). However, whereas JLab requirements involve a bricks-and-mortar facility, the SCOOP architecture supports a “virtual organization” comprised of partners that collectively make up a distributed national lab for research and applications. 19