ADM-SOA-Presentation5-30-08

63 %
38 %
Information about ADM-SOA-Presentation5-30-08
Business-Finance

Published on December 19, 2008

Author: aSGuest7322

Source: authorstream.com

Architecture & Data Management (ADM) Working GroupMay 2008 : Architecture & Data Management (ADM) Working GroupMay 2008 SOA & Web Services Report Overview IEOS Purpose Statement : 2 IEOS Purpose Statement A core purpose of the Integrated Earth Observation System (IEOS) is to provide the widest possible access to data and information products held in a number of existing, distributed systems. Interoperability is a key to providing users effective information and data discovery, access and analysis capabilities across these heterogeneous systems and IEOS can achieve interoperability via a suite of common, standards-based service interfaces. This service-oriented architecture approach, consisting of loosely-coupled, Web-oriented services, will provide interoperability between USGEO data and information systems and user community tools and systems. What is Service-Oriented Architecture? : 3 What is Service-Oriented Architecture? A service-oriented architecture (SOA) is an information technology approach in which applications make use of loosely coupled services available over a network. When the World Wide Web serves as the network used, this is normally referred to as a Web services-based SOA. Loose coupling means that the client of a service doesn't have to know very much about the service to use it. “Loose coupling describes an approach where integration interfaces are developed with minimal assumptions between the sending/receiving parties, thus reducing the risk that a change in one application/module will force a change in another application/module.” Source: Wikipedia June 2007 http://en.wikipedia.org/wiki/ This is particularly attractive when there is a need to functionally link heterogeneous, legacy systems with newly developed or evolving systems as is the case within the IEOS. Orchestration of Web Services : 4 Orchestration of Web Services User Scenario : 5 User Scenario 1. In this initial step the researcher engages a web search engine client on her computer. Her local Web browser offers accessibility to the Internet that makes available a host of information catalogs and registries. 2. The researcher is interested in finding ocean temperature data for only a specific study site which will require a large data set to be subsetted. In this second step our researcher connects via her Web browser to a site where a Universal Description Discovery and Integration (UDDI) catalog of web services is located. 3. The UDDI catalog is searched and discovers a web service that enables subsetting of ocean data. The subsetting web service is described in a Web Services Description Language (WSDL) document that includes information for accessing and evoking the service. 4. From the WSDL description of the a subsetting service the researcher’s query accesses a web server that directs the access to a store of ocean temperature data sets held at an agency’s data archive. 5. The ocean data is stored as a satellite swath so the user query must contain needed information for the exact latitude and longitude of the area of interest and the temporal range to be covered. 6. At this point the ‘service orchestration’ begins where the subsetting service is evoked from a SOAP service made available through another server hosted by a ocean’s research group. The service to subset is brokered by the web service and the data provider. While SOAP was used in this instance other services are created using REST. 7. The requested subsetted portion of the voluminous satellite data is sent back to the researcher’s browser window. In this instance the user is able to evoke an FTP session where the actual data granule is sent from the data archive brokered by the SOAP service. Report Recommendation : 6 Report Recommendation An Internet-based, service-oriented architecture shall be used when developing interfaces to both new and legacy data and information systems contributing to IEOS. A Web services architecture is the primary technical development paradigm for IEOS. Standards-based service interfaces shall be designed to promote interoperability and allow users seamless access to USGEO data and services made available from multiple sources. IEOS Interoperability is based on: Stable Interfaces and Reliable Services The Capability to Evolve Comprehensive Metadata Developing an IEOS for USGEO : 7 Developing an IEOS for USGEO Examples of Agency Web Services implementations: Earth Observing System (EOS) Clearinghouse (ECHO): The NASA Earth Observing System Clearinghouse (ECHO) is an operational metadata registry that enables the science community to more easily discover and exchange NASA’s Earth science data and services National Model Archive and Distribution System (NOMADS): The NOAA National Model Archive and Distribution System (NOMADS) is an example of a loosely-coupled Web service portal for both peer-to-peer access and services based requests for NOAA’s model data AIRNow: The U.S. EPA, NOAA, NPS, tribal, state, and local agencies developed the AIRNow Web site to provide the public with easy access to national air quality information. The Web site offers daily Air Quality Index (AQI) forecasts as well as real-time AQI conditions for over 300 cities across the US, and provides links to more detailed State and local air quality Web site METOC Broker Language (JMBL): Joint METOC Broker Language (JMBL) is an example of a Web Services interface for meteorological and oceanographic (METOC) data and is in operational use by Navy and Air Force. JMBL defines a standard interface for a variety of METOC data including forecasts, observations and satellite data. Principles for IEOS Interoperability : 8 Principles for IEOS Interoperability 1. Multi-use: To realize the maximum benefit from every observation and product, this information must be collected, produced, documented, and maintained with the needs of all users in mind. 2. Preservation: Irreplaceable observations, data products of lasting value, and associated metadata must be well documented and maintained so that it is available to and independently understandable by all users, now and in the future. 3. Quality: Data, products and information should be of a quality sufficient to meet the requirements of society to make sound decisions. 4. Access: Full and open sharing and exchange of GEO-relevant data, metadata and products is a fundamental objective. All shared data, metadata, and products will be made available with minimum delay and at minimum cost. Data and products for scientific research and educational purposes is encouraged to be made available free of charge or at no more than the cost of reproduction. 5. Cooperation: To realize the full potential of its data each organization should work in partnership with others to make best use of existing infrastructure (observations, communication and processing facilities). 6. Security: Data, information, and products must be preserved and protected from unintended or malicious modification, unauthorized use, or inadvertent disclosure. 7. Standards: Appropriate use of widely supported standards with demonstrated benefits is vital to facilitate, management, discovery, and access services for environmental data and products. Guidelines for IEOS Interoperability : 9 Guidelines for IEOS Interoperability 1. Use a Web service-oriented architecture to develop interfaces to both new and legacy systems contributing to IEOS. Web services Architecture is the recommended paradigm for development of IEOS and Web service interfaces should be built to provide access to USGEO data, products and applications. 2. To the extent possible use the best mix of commercial, open source, free-ware, and new software and tools. The use of commercial software, software developed through open source, freeware/shareware, or government-sponsored projects to improve, modernize, or expand an existing or new data system should be of equal consideration. The criteria for evaluation of the overall software or tool proposed is the effective total life-cycle cost of development and maintenance, and if the design is appropriate to the usage for targeted end users. 3. Anticipate future data management requirements. With increasing interdisciplinary use of environmental information it is difficult to anticipate all of the possible applications of data and products. Therefore, systems should be developed with the broadest range of possible uses in mind. This requires systems to be flexible and adaptable to changing technology and user requirements while collecting and maintaining comprehensive documentation and metadata on its holdings. 4. Ensure components are deployable to a wide variety of information system architectures. The one constant in information technology is continual change. Hardware and operating system software are always evolving and information system software should be developed in a manner that ensures it can be deployed to a variety of hardware. 5. Maintain stability of services. Once a service interface is published, the interface must be stable. If the interface were changed, any applications that depend upon that service could fail. Thus, contributors of services must commit to maintaining a stable interface. 6. Follow open, recommended standards whenever they are applicable. Conclusions : 10 Conclusions The USGEO Architecture and Data Management working group has recognized the value of the widespread deployment and use of Web-based services within a SOA-approach. This is the beginnings of a service that allows access to rich data stores and information packets across all USGEO “components”. What is required today is a coordinated effort by data managers and IT experts to work toward a common solution using existing “component” systems across agencies with the cooperation of data providers. This strategy is a key to a successful system of systems for data and information services. Example Slides : 11 Example Slides NOAA National Operational Model Archive & Distribution System (NOMADS) : 12 NOAA National Operational Model Archive & Distribution System (NOMADS) 1] Users request climate and weather model output via the Web. 2] The Geospatial One-Stop (GOS) is a catalog Web service that holds the location of model data. 3] Apache/Tomcat is an industry standard for using web-based services. 4 & 5] The OPeNDAP Web Service resides within the NOMADS server and receives and fulfills requests. OPeNDAP Web service allows the representation of the data file to be encapsulated in the user selected format. 6] The SOA “REST” Service. The users receives the information and data requested. NASA EOS ClearingHOuse (ECHO) : 13 NASA EOS ClearingHOuse (ECHO) 1] A science user searches for needed satellite data from his analysis application. 2] The software application invokes a search using the ECHO granule-level metadata. 3] The ECHO system is able to broker a SOAP web service that can stitch together swath data. 4] The query passed through ECHO is then connected via a web server to the appropriate on-line data archive. 5] The satellite swath data is accessed and the SOAP service is applied bringing together 2 data files. 6] The merged file is returned to the user application where it can be viewed and analyzed. NAVY/DOD METOC : 14 NAVY/DOD METOC NAVO: Naval Oceanographic Office FNMOC: Fleet Numerical Meteorology and Oceanography Center CUS: Commander, Undersea Surveillance AFWA: Air Force Weather Agency MESIL: METOC Enterprise Service Integration Layer JMBL: Joint METOC Broker Language NOP: Naval Oceanography Portal NMDSF: Naval METOC Data Services Framework

Add a comment

Related presentations