The OGC Architecture SIG and OGC WWW Mapping SIG are jointly developing a Service Model that will provide the basis for the upcoming OGC Web Services Initiative. During the WMT-2 portion of IP2000, there was some initial work done on a Basic Service Model and on OGC Web Registry Services.

The figure at the left appeared in the OGC Web Services RFT.

At the February OGC meetings in Atlanta, members agreed that work on a Service Model was very important and that OGC should provide a venue for this work.

Index:

Work Items & Topics
Meetings & Teleconferences
Mailing List Information
Links
Reading List
Use Cases

Work Items & Topics

• Definitions of Terms
  • The (tentative) list of consensus definitions.
• Service Model
  • The service model is the overall model governing how we want to structure OGC Web Services. In short, we're working on an architecture where individual services have interfaces of known types, these interface types are described in service metadata, the service metadata are available to clients of the service via a "Get Capabilities" request, there are Catalogs or Service Registries that provide queryable access to collections of service metadata, there are services provided by these Catalogs/Registries that assist in maintaining the information contained in the catalog, and the interface types form an inheritance tree of interface properties.
  • There is a "Basic Service Model" that provides a minimum amount of these infrastructural elements so that we can begin gaining experience with this model
  • There is a "General Service Model" that provides a richer ability to describe and place into operation services that are cascadable or chainable and services that are loosely coupled to data sources as opposed to being tightly bound to data sources.
  • There are wider IT industry efforts underway (cf. UDDI, WSDL, NASSL, SOAP) that provide service models and architectures that we want to take advantage of and be compatible with.
  • ISO TC 211 and OGC have adopted ISO 19119 as the basis for a service model.
• Service Metadata
  • Service metadata is that information that describes a given service. There is service type metadata and there is further service instance metadata. For example, a portrayal service will have different service type metadata than a feature service. A feature service could be instantiated on Asian data and another, identical feature service could be instantiated on Antarctica; these services would have the same service type metadata but would have different service instance metadata.
  • Service metadata should take into account existing metadata standards, in particular those of ISO TC 211, OGC, and those of the particular service model we may choose.
• Capabilities Request/Response
  • A given service must provide access to its service type and service instance metadata. Historically within OGC, this is known as the "Capabilities" request and response.
• Catalog/Registry Request/Response
  • The OGC Catalog Services Interface Specification is the initial source of information regarding construction of a service registry. It describes the formulation of requests or queries into the holdings of a catalog and describes a mechanism for receiving a response.
  • Specific request and response syntax and semantics are under development to satisfy the needs of our service model. The work has primarily concerned itself with the content of the response, following the pattern developed in the FGDC Geo profile of Z39.50.
• Catalog/Registry Services
  • An OGC discussion paper on Web Registry Services following material developed during the IP2000 initiative describes the operations of a registry service. This includes the ability to make stateless queries.
  • Further services in aid of maintaining the coherency and currency of the holdings of a catalog are important additions to the OGC Catalog Services model.
• Service Types & Interface Inheritance
  • Using the service metadata and the capabilities response mechanism, we have to develop a taxonomy of service types and develop an inheritance tree of those service types.

Meetings & Teleconferences

Mailing List servicemodel@opengis.org

The mailing list for this group is maintained by the OGC Operations Staff (THANKS Greg & Roger!).

Archives are available at OGC's servicemodel archives (starting at April 10, 2001) and at Allan's servicemodel archives (starting at June 13, 2001).

Send messages to servicemodel@opengis.org to send messages to the group. To subscribe or unsubscribe, or find out who's on the list, send messages to servicemodel-request@opengis.org with the request in the "Subject:" line.

Links

Reading List

Use Cases