2001.07.11 Service Model Telecon Notes

Servicemodel Telecon, July 11, 2001
Updated: July 17, 2001 11:55 - Page Maintained by Allan Doyle

Present

Terry Fisher
Mike Adair
Lou Reich
Barry O'Rourke
Yonsook Enloe
Ananth Rao
George Percivall
Benoit Borlee
Archie Warnock
Peter Vretanos
Arliss Whiteside
John Davidson
Allan Doyle
Ron Lake
Jeff de La Beaujardiere
Jim Stephens
Larry Bouzane
Richard Martell
Jeff Harrison
Sandra Johnson

Agenda in black, discussion during telecon in blue, action items in red

** Before telecon starts, everyone should review definition of terms on service model website.
See latest at http://www.intl-interfaces.net/servicemodel/wsdl_note/note.html

1. Schedule next telecon - Wed July 18 at 11am EDT, 15:00 GMT

2. Review definitions of terms - list on service model website
-- just flag which ones still have issues/ambiguities

Lots of fragments - we don't have a unified view of the world - e.g. bits and pieces of things like WSDL for WFS, Catalog docs, etc.

John Davidson's material is more unified. Use it as a framework to pull this together better.

We should not lose sight of the data issue and the service content issue.

Action - Allan to post George's figure from the 19119 editing session. Done, click here.

Action - Allan, et. al. review John's UML figure 2, section 4.

Pull together a Glossary (actually use John's document). Have to end up with something that's consistent. Have to be careful about mixing UML with WSDL with xxx terms. Action: Allan & John D with help from Peter V. by July 16

RFQ Release July 25 - have to make sure we have a set of things that will not get reversed as we continue past the RFQ release.
Action - everyone. Comments needed on GSM revisions by July 18, will discuss during telecon.

(15 min)

3. Use Case -- need to form one that revolves around integrated data and service catalog access

We should identify questions of interest that need to be answered. Use telecon time to start this, then expand via email

* user identifies data of interest
* then finds services for data
* what metadata needed for user to discover data & service
* what metadata needed for system support of services & data
* how to catalog data services beyond WMS/WFS/WCS (ad hoc services)

-- how to validate use case with science users -- We can ask if Terry & Ken can hold telecon with science user types and get questions answered? (The idea is for us to build use cases and see if scientists like them.)

Use cases in the works: Lou Reich, Terry Fisher, ECHO team, can we get one from Doug Nebert?

Lou's has reprojection and other "dataless" services. It's focus is the WTF-GOFC area.

Action - Terry & others to supply his by Monday July 16 [Terry's (supplied by Mike Adair) is here (pdf) and here (doc)]

Keep whole list informed about progress in use cases.

(30 min)

4. Task items - confirm earlier discussions on what people volunteered to do -- get additional volunteers.
Give status on what has been accomplished so far.
Note any technical issues

Progress and thoughts on
WSDL instantiation of WFS (Polexis and CubeWerx have tried)
WSDL instantiation of WMS (Jeff DLB to try with someone else's help. Ananth also working on this. We have a team!)
WSDL instantiation of WCS (John Evans is working on this.)

Peter to work on integration of WSDL and GetCapabilities. Response to GetCapabilities will include a WSDL structure.

See Jeff's experiences below.

See Peter's WFS WSDL.

Action - Peter to look at Jeff's stuff and start a thread on the list that we can learn from. (See email thread "WSDL discussion with Jeff")

Lou suggests looking at UDDI.org for a paper/tutorial on WSDL for TModel

Lou thinks there's still a lot of uncertainty about how to deal with data/content if we were to not have a GetCapabilities for services at the content level. How would catalogs look? This seems like a big hole that we have to come to grips with in John's GSM paper.

Action - Allan, John, et.al. make sure this gets discussed properly in the GSM paper.

One way to deal with this is to have the data in a data catalog and have pointers to services in the metadata for the data. We need to work this out - in use cases?!?

We still have to articulate both the data centric and service centric views. Lou wants to make sure that we have a wholistic data/service interaction paradigm before we start the OWS in September.

Where do the following fit into a type hierarchy/object model/ taxonomy?
WFS, WMS, WCS, Catalog, View Service

Peter went through an exercise of building several services (gazetteer, etc.) out of a WFS-like set of interfaces. This is by moving the WFS-like interfaces up a level into a "Web Object Server" and then subclassing them. GFS Pilot went down this path a bit earlier this year. This is an area where we'd like Ionic to help with their modeling expertise (Serge?!)

Action - John to supply pointers [Done: This is where the schema for WFS, WMS, Gazetteer, Geoparser, Geocoder and LOF interfaces/encodings can be found: http://www.opengis.net/schema.htm. These were developed primarily for the GFSPP Interoperability Program initiative that was completed in March.]

Are WMS/WVS a different branch of the tree from WFS, Catalog, etc? (Because they have a rendering component).

We still need a leader for this modeling activity - ask Serge. Work party so far (John, George, Lou, Peter) Status report at next telecon.

Action - George to post his extraction of service taxonomy from the RFT July 11. (Adopted [pdf, doc], Future [pdf, doc])

Action - Peter to post an inheritance tree (just the branch involving the WFS [updated based on email on July.12]) by Friday July 13.

Action - Telecon for Object modeling on Tuesday July 17 (Service type hierarchy)

Make sure people know there are several parts to this. 1. Service Taxonomy 2. Functional inheritance of objects

Harry to supply additional input to taxonomy.

Data/Service views affect the modeling.

Service Chaining will also affect the modeling. There's some reason to believe that service chaining will encourage finer-grained interfaces/operations.

Catalog ops & responses -- we were getting close to something with brief/summary/full, I thought...

Brief "Brief" was acceptable to all. Summary and Full were not satisfactory. Compusult was looking at Summary and reworked the use case to make summary be less like full. More work on this during July 23rd week.

Action - Jeff DLB will keep canonical copy of the XML. Jeff to publish URL for them by July 16.

Jeff to keep both the currently implemented as well as the proposed/working copies. Week of July 23 - Compusult and Jeff DLB can both devote time to this.

Look at Lou's Catalog Paper (Word version). (PDF version)

OWS RFQ will have more info on catalogs. How do we connect that work to servicemodel and Catalog WG/RWG? Make sure Harry get's Lou's work. Make sure Lou looks at Harry's material...

(1 hr)

5. Review of outstanding issues & work items
(10 min)

Minutes

See the blue parts in the text above.

Jeff Lansing sent this in on Saturday for our viewing:

Hi,

Since I will be away next week and won't be able to participate in the telecon, I
would like to comment on my efforts to produce a wsdl description for a WFS.

I spent some time downloading and installing the web services toolkit and IDE from
ibm. I found all of it completely useless.

The schema for the http binding is not easy to use. (At least I haven't gotten it to
work yet.)

I have yet to find any examples of wsdl descriptions that I have been able to get to
validate against the wsdl schema. (Perhaps someone could help with this.)

Even if and when you have a wsdl description that validates against the schema (or
perhaps some repaired version of it), you still don't have much. The real test is what
a wsdl processor will do with it. But of course there are no wsdl processors for the
http binding.

The reason why you still don't have much is that wsdl uses names for its reference
system. For example, if I declare:

<definitions xmlns:wfs="http://www.opengis.net/namespaces/wfs">
   <import namespace="http://www.opengis.net/namespaces/wfs"
   location="http://www.opengis.net/namespaces/wfs/GetCapabilitiesRequest.xsd"/>
   <message name="GetCapabilitiesRequest">
       <part name="body" element="wfs:GetCapabilities"/>
   </message>
</definitions>

there is nothing in the schema that connects any of these pieces together. Not even
the wfs namespace declaration matters to the wsdl schema. "wfs:GetCapabilities" is
just a name. Everything is left for the wsdl processor to check.

The real work in making a wsdl description is in getting the bindings to the
operations right. There will have to be (I think) separately named operations for each
of GetCapabilities, DescribeFeatureType, etc. that is supported, both for POST and for
GET (if both of those are supported).

Since a wsdl description is server and service specific, having an XSL stylesheet that
would convert a capabilities response to a wsdl description would be a very nice thing
to have.

Once you have the wsdl description for a service (eg. a WFS), you still need a
GetCapabilities response to find out what features are available. Even simple
information such as this is already too high level for wsdl to handle.

I don't know if this counts as making "any significant progress in the area of WSDL",
but perhaps it's an insignificant start.