200 likes | 324 Views
OGC Data Services. Allan Doyle NASA/SGT September 14, 2000. DISCOVERY. ACCESS. VISUALIZATION. ANALYSIS. WORKFLOW. Combination. Mensuration. Portrayal. Directory. Subscription. Query/ Filter. Ordering. Notification. Reprojection & Coord. Trans. Online Access. Overlaying.
E N D
OGC Data Services Allan Doyle NASA/SGT September 14, 2000
DISCOVERY ACCESS VISUALIZATION ANALYSIS WORKFLOW Combination Mensuration Portrayal Directory Subscription Query/Filter Ordering Notification Reprojection & Coord. Trans. OnlineAccess Overlaying FormatConversion Inventory Publishing Subsetting/Subsampling AlgorithmicTransformation Mosaicking Scripting/Chaining Statistics Classification Drill-down Animation Featuresw/GeometryData Server Level 1Data Server GriddedCoverageData Server Candidate Core Data Services
Applications (viewing, editing, discovery, analysis, publishing) Catalogs & Directories Operators & Models Repositories http://ceos.org 100,50,2 300,75.4 X=56 OGC Interoperability Program(Core Architecture) Network Services & Security / E-Commerce
Applications (viewing, editing, discovery, analysis, publishing) Dynamic Portal LO Clients Viewer Clients Discovery Clients Catalogs & Directories Operators & Models Geoparse, Geocode, Geolink Service Registry Coordinate Transformation Catalog Web Map Server Repositories Web Feature Server, LO Folder & GML http://ceos.org 100,50,2 300,75.4 X=56 Web Coverage Server & IML OGC Interoperability ProgramCurrent Efforts in Web Mapping Testbed & Geospatial Fusion Services Testbed Network Services & Security / E-Commerce General Service Model & Security Demo
Data Services in WMT-2 WFS Web Feature Service interfaces Transaction Encoding OGC Common Query Language Encoding Portrayal Web Map Server Interfaces Legends & Fine-grained symbology control WCS Web Coverage Service Interfaces Imagery Markup Encoding/Interfaces S&EC Security & E-Commerce Catalog & General Model Service Metadata Encoding Catalog Interface Re-use, Service Registries, Schema Server Interface
provides provider user links to service data is named in describes describes builds loads controlled vocabulary description (metadata) maintainer negotiates proposed update references getSchema Information community populates advertises in Information Community Semantic Registry searches Catalog Service(s) client uses sends interface can use
WMT-2 Community View Server instances Corporate resources WMS Data uses Semantic Server cs CS vocabulary CTS Data cs Service Directory service instance metadata CS Data WFS register cs CS – catalog service WMS – Web Mapping Service CTS – Coordinate Transform WFS – Web Feature Service Gaz Svc Data
controlled vocab Services Instance Metadata Service Instance * Client * Data classes Data Instance Metadata Data Instance controlled vocab
Service Taxonomy/Typing Model NASSL/UDDI/??? ServicesModel OGC Services Prototype OGC service taxonomy WFS Catalog Transform Thesaurus Geocode geoparse Gazetteer
XML Distributed Applications • W3C has a mailing list - xml-dist-app • Buzzwords reign supreme • BizTalk, E-Speak… • These show promise: • SOAP - Simple Open Access Protocol • NASSL - Network Addressible Services Specification Language • IBM Web Services • UDDI - Universal Discovery Description and Integration
UDDI Universal Service Interop Protocols (these layers are not defined yet) Interop Stack Universal Discovery, Description, Integration (UDDI) Simple Open Access Protocol (XML) Extensible Markup Language (XML) Common Internet Protocols (HTTP, TCP/IP) http://www.uddi.org
What are NASSL and WDS • Network Accessible Service Specification Language - IDL in XML/Schema • Well Defined Services - Non-operational metadata in XML/Schema • Developed by IBM as an aid to their SOAP for JAVA development
NASSL - Description of a Network Accessible Service • Requires four fundamental pieces of information: • the abstract description of the function provided by the service(But this is missing from NASSL! - it's part of Web Services) • definition of the types of the data exchanged between the service provider and the client, • the specifics of how the service is accessed via one or more access protocols, • the actual endpoints at which the service is provided.
NASSL Components • A NASSL document has four parts • Three of them are required, • <interfaces> element • <implementations> element • <providers> element • One is optional • <types> element.
Interfaces Element <interfaceDef> element identifies an interface through its name attribute. It can have a variable number of <operationDef> children. <operationDef> element describes a method signature, and must have a name attribute and three optional children: <type>, specifying the return type, <parameters>, specifying the parameters list, and <exceptions> specifying possible returned exceptions. <parameterDef> element. It has a name attribute, and may have a direction attribute: IN, OUT or IN OUT. If not specified, the IN value is assumed. <type> element <exceptionDef> element, which encloses a <type> element
Implementations Element • Gives the specific implementation/protocol supports by this service • <access> element has a mandatory protocol attribute, which provides a list of the specific combinationsof transport and protocol that may be used to access this service implementation. Each value in the list belongs to an enumerated type with values such as HTTP-POST, RPC-SOAP-HTTP, RMI-IIOP • <encoding> element. Has a mandatory styles attribute represent mappings from abstract types definition to actual serialized (“on the wire”) representations of those types,
Providers Element <providerDef> element, which just specifies a list of access urls for a given implementation of the service. <endPoint> element. The the url attribute contains url of each access point.
Types Element • Type descriptions may be XML/schema encoded or use other IDLs such as OMG IDL or Microsoft IDL