Atom ServiceCasting to advertise Web Services

Presenting the Proposal

The purpose of this presentation is to propose that the ESIP Federation members all begin to advertise their web-accessible services (SOAP, REST, OGC WMS/WCS/WFS, DAP, etc.) using Atom "Service Casting" feeds. In a prior DSWG telecon, Brian presented a draft Service Casting standard with some example feeds for various kinds of services. The first half of the presentation will describe the potential feed standard with some examples, solicit feedback and ideas, and then illustrate how such feeds can be: easily aggregated to create a catalog of services, presented to humans in various styles within feed readers or browser pages, and machine-parsed to automatically discover and call services (e.g. for SOAP by following a link to the WSDL file). In the second half, we will select some volunteers and create new 'service casts' (live) to advertise their services.

Original Service Casting Proposal

The original Service Casting proposal by Brian Wilson (Mar. 18, 2008) follows.

Here are two text files that describe, via a prototype *implementation*, how we could do Service Casting of the ESIP Federation's web services (SOAP, REST, OGC WMS/WCS/WFS, human GUI, etc.) by using RSS/Atom syndication feeds.

• feed.atom
• EsipFederationServices.opml

Basically, each entry in the feed would advertise a bundle of web services (e.g. SOAP services), described by a machine-readable interface description (e.g. WSDL), callable at a service endpoint URL, and accompanied by links to human-readable documentation (the alternate link). Of course, since the advertisement is a syndication feed, the service provider can update their services and re-advertise at any time.

The first file, feed.atom, contains an example service casting feed for a couple of SciFlo's data query/access services (e.g. GeoRegionQuery and FindDataById). Since these are SOAP services, the links in the entries are to the WSDL file, the service endpoint URL, and to HTML documentation for humans. You can load the Atom feed into virtually any Feed Reader software, although there will be some variations in the way an Atom entry is displayed when it contains multiple <link> tags and a <content> tag.

More details of the proposed standard are described in the comments at the bottom of the file. Basically, we have to label the services as to interface type/protocol (SOAP, REST, OGC.WMS, HUMAN). This is done by introducing an <scast:serviceType> tag in the newly created ServiceCasting namespace. Similarly, we have to reserve some new link relationship types (e.g. <link rel="scast:interfaceDescription"> so that a machine reader understands the purpose of each of the linked-to documents.

As I've indicated in the comments, there are many good reasons to choose the Atom format over RSS, including the capabilities to: have multiple typed links in each feed entry, query and update the feeds using the Atom Publishing Protocol (AtomPub), and exploit Google's GData standard which builds on top of AtomPub.

The one part I didn't ponder too hard is what should be in the <category> tag to categorize our services. The full taxonomy problem, of course, is a morass. However, we could just fall back to text keywords that each service publisher makes up.

The second attached file, EsipFederationServices.opml , demonstrates how a list of RSS/Atom feeds can be aggregated into an 'outline' (OPML) document. Almost all Feed Readers can import/export sets of feeds in OPML format, although I discovered that one cannot use more than two levels of hierarchy in the outline or import results vary (chaos ensues). In any case, we could continuously accumulate a master OPML file that contains all of the Federation's services and make it available via a URL on the Federation web page. Creating the master file is as simple as maintaining a current (and growing) list of Service Casting feeds in a Feed Reader that can export to OPML. Thus, 'discovering' Federation web services can be reduced to a matter of reading or querying (e.g., via GData) the aggregated feeds kept at a bookmarked link.

Of course, much more discussion will be necessary to finalize the standard. The first step should be to solicit feedback from all interested parties, and learn more about how the large variety of Feed Readers behave. I certainly haven't thought of all of the kinds of 'link types' we could or should have, or how to categorize services. But, I believe this is a good start at making it trivial to aggregate and discover the Federation's services. (Since we have been trying to get compliance on any mechanism for many years, I hope that this is so trivial, and enticing, that we will finally succeed.)

More Details of the proposed Service Cast feed standard

Advertise web services in a structured manner, with machine-callable interfaces, by using the Atom 1.0 feed standard. Each entry in the feed advertises a bundle of services (e.g. SOAP) described by a machine-readable interface description (e.g. WSDL), callable at a service endpoint URL, and accompanied by links to human-readable documentation (the alternate link).

Atom was chosen over RSS for multiple reasons. Each entry can have multiple 'link' tags with structured meanings, using the 'rel' attribute. In addition, one can use 'rel=enclosure' for enclosures or the content tag for in-line content. As shown below, the 'content' tag can contain XHTML or any XML information from additional namespaces. Finally, Atom feeds can be updated and queried using the Atom Publishing Protocol (AtomPub), which has been embraced in Google's GData protocol.

I've created a serviceCasting namespace, and trivial XML schema, to describe the possible service types and the new allowed kinds of links (rel=). Tentatively, the enumeration of service types could be:

 SOAP    - for SOAP/WSDL services
 REST    - for REST (one-line URL services), possibly described by WSDL or ??
 OGC.WXS - for OGC WMS, WCS, WFS, etc. services (REST versions)
 HUMAN   - web apps intended for human consumption (could be Java web start, browser AJAX, etc.)

Also tentatively, I've defined/used several machine-readable 'link' types:

 rel=None:  the primary link should point to the interface description or service documentation
 rel="scast:interfaceDescription":  interface description, WSDL or ??
 rel="scast:serviceEndpoint":  service URL (so it can be detached from endpoint in WSDL doc.)
 rel="scast:serviceDocumentation":  URL pointing to human-readable documentation for the services
 rel="alternate":  (same as service documentation)

It is permissible to have more than one of the 'rel=scast:serviceEndpoint' links.

If there isn't a 'rel=None' link, then most Feed Readers will use the 'rel=alternate' link as the single hyperlink for that entry. It may be useful to have the default link point to the human documentation rather than the machine-readable interface description. Suggestions are welcome, of course.

One can import a list of RSS/Atom feeds into most Feed Readers by expressing the list in OPML (Outline Processor Markup Language). Thus, we could aggregate all of the service feed entries across the ESIP Federation and then distribute the OPML document via a URL on the ESIP Fed. web site.

Comments & Suggestions from Steve Olding

• Should somewhere identify the owning organization of the service. (This may not be the same as the feed author.)

• Each entry should include a brief human readable description of the service.

• I think that there are 2 main things that each entry needs to reference - the formal services definition (e.g. the WSDL) and a human readable description, if it exists. I would not include the example call in the feed. This better belongs in the full service description.

• I would like to see something that describes the availability and/or maturity of the feed - e.g. experimental and randomly available or fully production ready and available 24x7.

• Should we also include something about who is allowed to use the service?

• How about using the category element for keywords. This could be used to attach a few standard tags that provide some general domain classification, describe the function that the service performs, and describe the data that it operates on. Provide a little bit of information that would allow for some automated searching.

• How about adding another entry type that would point to other service casting feeds. This could be for related feeds or recommended alternative feeds. This would provide a basic mechanism for discovering a network of feeds.