09/07/07 TC

Attendees: Rich Ullman, Yonsook Enloe, Peter Leonard, Ananth Rao, Allan Doyle, John Scialdone, Glenn Cunningham, Ming-Hsiang Tsou

Next SPG telecon : Wed August 19, 2009 at 3pm ET

Action Items:

• July 16 – Allan will send Russ email about the NetCDF RFC errata and ask whether the corrected spec will be interoperable with the old spec.

Notes/Discussion :

• July 7 SPG meeting in Santa Barbara –
  • Allan reported that the web services workshop program is pretty much planned. We have enough speakers and topics for a panel discussion. The speakers and discussion topics are listed in the ESIP Federation wiki. Allan will confirm with all the speakers that they are coming.
  • Helen is looking into music night options for Wed night. Tues night is an ESIP Fed dinner.
• RFC Status
  • 3 tech notes from Chris Lynnes – Ananth reported that the review period ended with one comment. TWG will target several additional expert reviewers and request their reviews. Getting 3-5 reviews should be sufficient for a tech note.
  • DAP2 to HDF5 Mapping Tech Note –Allan reported that the TWG will send the review request to a targeted list of people – maybe the HDF5 communtiy. maybe the same people that reviewed the DAP2 RFC and the HDF5 RFC. Not appropriate for a general audience since this is a highly technical topic.
  • AURA Community Guidelines Tech Note– is being reviewed. 2 review comments so far.
  • ICARTT RFC – initial review is done. Need to constitute a TWG. Daniel will be chair of the TWG. Members for TWG – Daniel, Ed Armstrong, Peter Leonard, Glenn Cunningham
• Yonsook discussed Russ Rew’s email about an error in the NetCDF RFC. Allan will send Russ email and cc Daniel to ask if the corrected spec is interoperable with the new spec. Then a decision will be made on whether to issue new version or errata.
• Rich discussed the Data Systems in the Decadal Survey mission era workshop that Martha is hosting the end of June. The decadal survey mission teams will be invited. There will be a standards breakout at the meeting.
• Rich noted that Martha has asked how to invigorate our membership in OGC.
• This is Ming’s last telecon. His funding ended. We thank Ming for his past contributions to the SPG. If anyone is visiting San Diego, give Ming a call.
• The next SPG telecon is scheduled for Wed Aug 19th, at 3pm ET.

Following the presentations on web services at the technical session, we held a group discussion on the following themes:

• 1. Technical discussion of web services, Service Oriented Architecture, SOAP, and REST. Web services is very broad and ambiguous term. So is Service Oriented Architecture. * In service oriented architecture (SOA), get the representation which is a verb – ex: GetMap – like a function call -- need to know what the parameters are for the function call. Thus, SOA is associated with SOAP and is better for more complex processing and workflows. SOAP exposes processing.
  • REST is a resource oriented/content view – like calling a virtual product which could then result in service calls. REST is patterned after the Web itself – just access the resource. REST exposes content.
  • OGC’s current service architecture is tied to SOAP, UDDI, and ebRIM. REST is gaining adherents but is often misunderstood and is becoming a bit ambiguous also. REST usage is going up as measured by Google.
  • SOAP vs REST debate similar to the debate about CORBA vs the Web a while ago. Now we are discussing SOAP vs REST.
  • SOAP is best in some situation, e.g. WS-security, WS-addressing, orchestration, more complex services (not CRUD model), machine-to-machine communication, developers using Java and SOAP tools. SOAP suffers from RPC mindset, interoperability issues. All languages support REST because all languages support http. Can do REST from a browser. For human interfaces, need to go with REST.
  • SOAP/WSDL doesn’t require web services descriptions for its implementation. REST requires good description of the resources – good metadata is required for its implementation.
• 2.Current state of the art/state of practice items that are not yet in widespread operational use at NASA:
  • ISO 19115/19139 Metadata and XML expression
  • THREDDS 4.0 Data Server
  • NetCDF4
• 3.Current items that are in operational use at NASA, and that the SPG should solicit Standards-track RFC's for if we don’t have it already.
  • ECHO metadata model
  • ECHO user registration system
  • WMS 1.3.x
  • WCS (RSIG, MODAP)
  • NetCDF 3
  • CF-1
• 4.Items that are emerging that will impact NASA in the future, and that the SPG should solicit Technical Note-track RFC's for:
  • REST best practices (c.f. Virtual Observatories' REST guide)
  • Web services security
  • ISO 19115
• 5.Items that are still in flux but bear watching, should probably also be actively researched/tested by NASA:
  • Registries
  • Registry data models
  • OGC CSW
• 6.Convergence Roadmap - these items seem to be increasing in importance/use in the earth science domain:
  • REST (initially as "customer facing" architectural pattern);
  • ISO 19115 (slowly gaining adherents, will eventually superseding FGDC metadata when FGDC adopts 19115)
  • NetCDF4 / HDF5
  • Services and access formats layered on top of NetCDF4/HDF5 - WCS, WMS, OpenDAP, NCML, ISO, Geographic Markup Language (GML), Simple Features, Climate Science Markup Language (CSML) – a profile of GML, Observations and Measurements
• 7. Areas where NASA should engage in the OGC process:
  • Earth Systems Science working group/meteorology, hydrology, oceans
  • Metadata working group
  • Data quality working group
  • Data preservation working group
  • Specific interoperability initiatives/testbeds

NASA's benefit from participating in the OGC process would be maximized by coordinating with other agencies (NOAA, USGS, EPA) during and between OGC meetings and by cooperating with other agencies in testbed activities. Resources spent on membership help OGC to staff activities, but unless resources are also (or possibly instead) targeted directly at specific working group activities (participation at a highly technical level by civil servants or qualified industry or academic contractors working with NASA implementation projects), there is a decreased likelihood of developing highly relevant and applicable standards. Furthermore, given the international nature of the OGC, NASA should also coordinate with CEOS/WGISS and GEO/GEOSS principals relative to the OGC participation of non-US agencies.

In particular, NASA's interests would be well served by OGC progress in the areas highlighted in the Convergence Roadmap section above.

We also note that OGC's web services model is currently very closely tied to technologies and practices (Service Oriented Architecture, UDDI, SOAP) that are considered to be more relevant to internal data systems use, rather than to outward facing interfaces (i.e. those most needed in systems such as GEOSS, IEOS, etc.). There is some motion within OGC to accommodate REST architectural patterns, and this is another area where NASA can exert considerable positive influence.