Note on WSDL, etc.
Last updated, July 17, 2001-- Allan Doyle

At the Service Model Ad Hoc, we looked at WSDL and decided that we should make a concerted effort to try using it prior to the beginning of the OGC Web Services Initiative, still due to start in September. The reason we chose WSDL is because our current service model work was lacking a model. (Hard to believe I'm even saying that, eh?). WSDL provides the beginnings of a model and it has the advantage of having a lot of people thinking about it. I believe that if we try to use WSDL and later decide it was not the right thing for us, we will not suffer much since it's going to force us to think about the abstract problem anyway.

What we all need to realize is that WSDL does not solve any of the hard problems. It does provide us with a few things, though. These include terminology and a way to describe the abstract properties of web services interfaces. We will still need to do the following hard parts (more info on these comes later in this note).

1. Metadata (whether we wind up calling it service metadata, operation metadata, port type metadata, etc.).
• We still have to decide what is important about a service, how to describe a service in a way that lets users/"customers" distinguish between services when they are trying to pick which one to use, and so on.
• We have to decide how to package this metadata into the available WSDL structures.
  
  
2. Catalog issues.
• How to harvest the WSDL into a catalog.
• What are the result types one can get from a catalog.
• What is the content of those result types.
• How to integrate data catalogs with service catalogs
• Use cases!
  
  
3. Controlled Vocabularies
• In looking at WSDL and in thinking about the metadata issues, we are still faced with the need for controlled vocabularies and a means for dealing with them. In particular, we need to adopt an operation naming convention that says that similarly-named operations, even when part of different port types, should mean similar kinds of things. E.g. a "Catalog.Footprint" operation and a "WMS.Footprint" operation both ought to be somehow related in terms of functionality.
  
  
4. Object modeling
• What is the actual type hierarchy?
• How do we map concepts like Class/Method into the WSDL structure of PortType/Operation?
• Can we use multiple inheritance?
  
  
5. Implementing & Testing
   • Who can build meaningful test cases for this out of WMS, WFS, catalog, client, etc. parts?
   • Interestingly (and unfortunately) the WSDL 1.1 document is vaguest in the area of HTTP bindings with examples that themselves seem inconsistent.

    

I'd like to get people to volunteer for these areas and would like to know what kind of time commitment you think you can provide to this effort.

Analyzing the WSDL model

From WDSL section 1, we learn that a Port Type is a collection of Operations, from various other parts of the document we see that Operations are characterized (as far as WSDL is concerned) by what messages they can take as input or produce as output. Thus we have Figure 1.

A Binding is used to relate a Port Type to a specific Port (Port and Endpoint are the same thing) via a network address (typically a URI) as in Figure 2. A Service is a collection of related endpoints (i.e, Ports). We could debate the meaning of the word related, but at its absolute weakest, the relationship among Ports in a Service is strictly that they are all members of the Service.

If we contrast this with A, B, and B' of an earlier discussion, we see that WSDL's model is closer to A. [Note that the major difference between A and B/B' is whether a subclass of an interface has to implement all operations of the superclass (A) or not (B) as depicted in the diagrams.] In terms of OO terminology, a PortType would be a Class and an Operation would be a Method. A Service would be a set of Methods accessible via a Port with a mapping to the "wire" defined by a Binding. (Some material from Craig Bruce's email to the servicemodel list on May 9, 2001.)

More observations on the table. Topic 12's definition of an Interface seems to combine the notion of Port and Port Type. A, B, and B' did not include the notion of Port at all.

Details about the 5 topics follow (where I was able to collect them in short order)

Metadata

• We still have to decide what is important about a service, how to describe a service in a way that lets users/"customers" distinguish between services when they are trying to pick which one to use, and so on.
• We have to decide how to package this metadata into the available WSDL structures.

Catalog issues

• How to harvest the WSDL into a catalog.
• What are the result types one can get from a catalog.
• What is the content of those result types.
• How to integrate data catalogs with service catalogs
  • How do we connect the large data holdings and the catalogs that describe them with the services that are appropriate for those data holdings?
• Stateless Catalog Use Cases have been collected here.
  • We need more specific use cases, perhaps right down to the level of finding a Landsat scene, then using that scene in a service or set of services. I.e. from the application level, not from the higher level model point of view.
    

Controlled Vocabularies

• In looking at WSDL and in thinking about the metadata issues, we are still faced with the need for controlled vocabularies and a means for dealing with them. In particular, we need to adopt an operation naming convention that says that similarly-named operations, even when part of different port types, should mean similar kinds of things. E.g. a "Catalog.Footprint" operation and a "WMS.Footprint" operation both ought to be somehow related in terms of functionality.
  
  

Object modeling

• What is the actual type hierarchy?
• How do we map concepts like Class/Method into the WSDL structure of PortType/Operation?
• Can we use multiple inheritance?
  

Jeff Lansing's Case Study on Web View Service {rtf, pdf}

Craig Bruce wrote:

   > My cheat sheet on UML modelling [1] says that a derived (sub) class is
   > the "specialization" of a base (super) class, and a base class    is the
   > "generalization" of a derived class. I agree that the meaning    of the term
   > "specialization" is confusing.
   > 
   > [1] http://www.holub.com/class/oo_design/uml.html

Lou Reich's work on Catalog vs. WFS {ppt, pdf}

The whole A, B, B' discussion may need to be revisited in light of WSDL... The votes so far were

BAE Systems - B'
Compusult - B' but revisit later
CubeWerx - B (but later there's email that would support A)
Polexis - A
DSTO - B'
CSC - A
Int'l Interfaces - B' (originally, but now leaning towards A, having looked at WSDL)

Implementing & Testing

• Who can build meaningful test cases for this out of WMS, WFS, catalog, client, etc. parts?
• Interestingly (and unfortunately) the WSDL 1.1 document is vaguest in the area of HTTP bindings with examples that themselves seem inconsistent.

GLUE - worth a look? (email from Stephane Fellah on May 8, 2001)