1. 1 Registry Services Overview J. Steven Hughes (Deputy Chair) Principal Computer Scientist NASA/JPL 17 December 2015

2. 2 Outline F DSMS Needs F Service Registry F Schema Registry F Data Element Registry

3. 3 DSMS Needs Overview F DSMS is looking for an enterprise hosted Registry Service. F DSMS Requirements Documents ä DSMS WebGDS Registry Service - Software Requirements Document (SRD), October 21, 2004, M. DeMore. ä Use Cases for the DSMS WebGDS Registry, October 14, 2004, M. DeMore.

4. 4 DSMS Needs Registry Service Components F Data Element/Data Type Registry: Provides common data dictionary information that contains element definitions and data type definitions F XML Schema Registry: Provides a versioned repository for XML schemas that describe messages, file formats, and data components. F XML Stylesheet Registry: Provides a versioned repository for XML stylesheets that perform common data translations. F Namespace/Domain Registry: Provides a controlled, hierarchical namespace/domain registry. F Service Registry: Provides a dynamic Registry for Web Services. F Model Registry: Provides a repository for information models, data relationships, and other ontological information.

5. 5 DSMS Needs High-Level View

6. 6 DSMS Needs CIO/Standards Efforts F Service Registry ä Evaluating COTS and Open Source products. F Schema Registry ä A component of the Metadata Service. ä Currently deployed in the DSMS development environment. F Data Element Registry ä A component of the Metadata Service. ä Currently deployed in the DSMS development environment.

7. 7 Service Registry What is UDDI? F The Universal Description, Discovery, and Integration (UDDI) protocol is a key member of the group of interrelated standards that comprise the Web services stack. It defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). F A Service is a software component that exports an API and provides a service for other software components on the network. The API must be such that it can be externally described to a degree sufficient for locating and using the service. In DSMS WebGDS, this generally will apply to Web services that can be described using WSDL or tModels, but the idea can be applied to other types of interfaces as well.

8. 8 Service Registry Web Services Stack

9. 9 Service Registry Standard F UDDI specifies protocols for: ä Publishing and searching services registry ä Controlling access to registry ä Distributing and delegating to other registries F Managed by OASIS standards body VERSIONYEARGOALS 1.02000 Public registry foundation 2.02003 Web services alignment and extensible taxonomies 3.02004 Flexible and secure registry interaction models

10. 10 Service Registry Products F Oracle Application Server ä Offered as an optional component. ä Minimal web-based GUI. ä Currently deployed at http://uddi.jpl.nasa.gov/.http://uddi.jpl.nasa.gov/ ä DSMS personnel have not had a chance to try it out. F Apache jUDDI ä Plays nice with Tomcat and PostgreSQL. ä Encountered problems when accessed from Java’s Web Services Developer Pack (JWSDP) example applications.

11. 11 Schema Registry Overview F This registry provides a central repository for developers and organizations to publicly submit, publish and exchange XML-based schemas. F A component of the Metadata Service. An effort currently funded by the CIO. F Interfaces ä Application Program Interface (API) F Support distributed access using CORBA/RMI F Support Java and HTTP application interfaces ä Command-Line ä Web-Based GUI F Planned Features for Future Releases ä Support for Authentication and Authorization

12. 12 Schema Registry Current Deployment F Deployed with Metadata Service release 2.0.0 ä http://metadata.jpl.nasa.gov/ on February 9 http://metadata.jpl.nasa.gov/ ä http://bayamo.jpl.nasa.gov:8080/ on March 5 (DSMS Deployment) http://bayamo.jpl.nasa.gov:8080/ F Features ä Add, remove and modify schemas and their supporting metadata in the registry. ä Metadata capture based on the Dublin Core Element Set. ä Allow for versioning and promotion of schemas. ä Capability to locate and access registered schemas. ä Provide for URL access to registered schemas. ä Provide for a web directory hierarchy for organizing schemas.

13. 13 Data Element Registry Overview F This registry provides the capability to register and manage a data element and associate it with a data dictionary. F A component of the Metadata Service. An effort currently funded by the CIO. F Interfaces ä Application Program Interface (API) F Support distributed access using CORBA/RMI F Support Java and HTTP application interfaces ä Command-Line ä Web-Based GUI F Planned Features for Future Releases ä Support for value domain ä Support for element relationships ä Support for Authentication and Authorization

14. 14 Data Element Registry Current Deployment F Deployed with Metadata Service release 2.0.0 ä http://metadata.jpl.nasa.gov/ on February 9 http://metadata.jpl.nasa.gov/ ä http://bayamo.jpl.nasa.gov:8080/ on March 5 (DSMS Deployment) http://bayamo.jpl.nasa.gov:8080/ F Features ä Based on the ISO/IEC 11179 “Information technology -- Specification and standardization of data elements”. ä Add, remove and modify data elements and their supporting attributes in the registry. ä Allow for versioning of data elements. ä Associated data elements to a data dictionary. ä Extract data elements from an imported data dictionary via the Dictionary Registry component. ä Capability to locate and access registered data elements.

15. 15 Backup

16. 16 Schema Registry New Features for 2.0.0 F New Metadata Elements ä Version, URI, Status F Version Control ä User specified via the Version element. F Web Directory Hierarchy ä Organize schema file locations based on the content of the Identifier and Version elements. F Promotion ä Promote a specific version of a schema. F Schema Validation ä Validate well formed XML and log errors. F XML Instance Validation ä Validate an XML file against an internally referenced DTD or XSD. F Schema Removal and Metadata Modification

17. 17 Requirements Overview F Priorities ä Priority 1 – Requirements that are critical for basic operations, confirmation of the WebGDS architecture, or infrastructure development. ä Priority 2 - Requirements that further develop core WebGDS capabilities, increase robustness of the operating environment, and promote open interfaces to existing key software systems. ä Priority 3 - Requirements that streamline operations, support more distributed operations, or extend capabilities for collaborative science planning and software development. ä Priority 4 – Requirements that support advanced information modeling and collaboration, or better support a component- based software architecture.

18. 18 Requirements Interface F Priority 2 ä The UDDI interface shall provide local (from the same computing host) access to the Registry. ä The UDDI interface shall provide remote (from a different computing host) access to the Registry. ä The software shall support an API compliant with the UDDI Version 2.04 Technical Specification. F Priority 4 ä The software shall support an API compliant with the UDDI Version 3.0.1 Technical Specification.

19. 19 Requirements Functional F Priority 1 ä For Service Entities, the software shall include the service interface information as part of the metadata. ä The software shall register Service interface information from an external WSDL specification. ä The software shall include a URL reference to the external interface definition as part of the metadata for the Service Entity, if such an interface definition is supplied at time of registration. F Note: It could be difficult to provide some of the above if we rely totally on UDDI. ä The software shall perform hot registration of Services, in which a “live” service registers its presence on the network at runtime. (Programmatic Only.) ä The software shall perform hot de-registration of Services, in which a live service de-registers its presence on the network at runtime. (Programmatic Only.)

20. 20 Requirements Functional (cont.) F Priority 2: ä The software shall support Services as Versioned Entities. ä The software shall register Service interface information from a tModel. ä The software shall support registration of Services through the UDDI API. ä The software shall support de-registration of Services through the UDDI API. ä The software shall support service lookup through the UDDI API. ä The software shall support retrieval and modification of Service metadata through the UDDI API. F Note: Is it necessary to require a Web Service API to the registry for functions that are provided through UDDI?