Note - this note is full of very informal UML. I leave it to the UML mavens to decide how to actually describe what I'm trying to say if they feel it's worth doing right, and I thank them in advance.
1. Interface and Operation - UML tells us that an Interface is a set of named operations that characterize the behavior of an element. It further tells us that an interface defines a service offered by a class or a component. And a further little tidbit: The same operation may appear in more than one interface. If their signatures match, they must represent the same operation... The Unified Modeling Language Reference Manual.
Thus what we're doing within OGC is defining Interface Specifications. Two of them are pictured here. (A WFS Interface has more operations than this, though).
Note that these operations and interfaces are abstract. Note also that none of the three Addison-Wesley Object Technology Series books I have actually defines the term "Service".
2. A vendor will then (hopefully) take the OGC Interface Specifications and implement them. It's up to the vendor to decide how to package the interfaces in terms of software components, etc. and to construct them in such a way that they can be installed by customers. For example, CubeWerx may decide to package a WMS Interface and a WFS Interface into something called cubeserv. Note that cubeserv is a software product.
3. A customer will then (hopefully) buy the product and install it somewhere. For example CCRS has a cubeserv installed somewhere in Canada that is available to people associated with the CEOS WTF-GOFC project. This is where it gets tricky. Note that we now want to talk about CCRS as a "Service Provider". But what service are they providing? Is is a Web Map Service and a Web Feature Service? Is is a GeoConnections Service? What they call it should be up to them. The next question is, what are the "entry points" into the service(s)? Is there a single URL? A URL for the Web Map Service and one for the Web Feature Service? Or one per operation?
4. What if several "service providers" decide to cooperate in a bigger project. For instance, the WTF-GOFC project has (among others) CCRS, ESA, and NASDA, all wishing to provide Web Map Service and Web Feature Service services to a single audience. Do we have to worry about providing a layering that accomodates this in the OGC Web Services Model?
5. Conclusion on Operation, Interface, and Service. We should adopt the following view of these three terms:
If we do that, then we can move towards a situation where an OGC Web Service consists of 1 or more OGC Web Interfaces, of which WMS, WFS, etc are instances. The OGC Web Service itself must be an instance of OGC Web Interface (and would thus contain a reference to itself by aggregation -- does this work? I think so). The reason for this is so that an OGC Web Service can provide the GetCapabilities operation on itself. Thus, if I ask for GetCapabilities from an OGC Web Service, I'll get back an aggregated Capabilities response but if I ask a given interface that's provided by that service, I'll get back the capabilities for that interface.
6. Dealing with capabilities and requests.
The question then arises whether a Capabilities response should be tagged by the Interface Type (as we currently seem to be leaning) or by the Interface Instance (which is the way we should go). That way, a Service could actually have several instances of the same interface, allowing the construction of the picture in #4 above.
The reason I say we're currently leaning towards tagging by Interface Type as opposed to Interface Instance is the message Craig sent about preserving the SERVICE= parameter and the one I sent about using the INTERFACE= parameter in its place. Perhaps what we really need is an INTERFACE_ID= parameter. But maybe, just maybe, a dotted notation would be in order here:
A: Ask for the top-level capabilities. Maybe even provide an argument-free version as in the second form.
http://foo.com/mondo.cgi?OPERATION=GetCapabilities or http://foo.com/mondo-capabilities |
B: Ask for the capabilities of the interface instance "wms15" which
is probably (the capabilities would have told us this) of interface type "WMS"
http://foo.com/mondo.cgi?OPERATION=wms15.GetCapabilities |
C: Now get down to asking for a map. If we deal with interface instance instead
of interface type, we can probably omit the VERSION= if we allowed multiple
interface instances since we could dictate that any given instance must support
a single version.
http://foo.com/mondo.cgi?OPERATION=wms15.GetMap&LAYERS=roads&STYLES=..... |