A Virtual GIS
Web Registry
In general, a registry is a facility that stores relevant descriptive information about registered
objects [Gallagher, 2000], and a registered object is something important that an author or
producer wants to have visible to the world so that it can be discovered and used by a client
or customer. A registry can operate independently, or it can be paired with a repository that
stores the registered objects. A repository is simply a storage facility for registered objects,
with an access method allowing one to retrieve individual objects by object reference. A
registry/repository implementation supports a registry services interface that can be used to
register new objects, provide appropriate metadata for those objects, browse or query registry
content, filter out irrelevant references, and retrieve the content of selected items. Since the
majority of information that might be registered in such a way has some location attribution
it is an obvious extension to this to add the ability to geo-reference the registry entry for the
registered objects and to extend the registry services interface to support the location-based
services that are possible, such as adding a map-based browser interface and spatial query
capabilities.
By separating the registry and repository structures, it is possible for a registry entry to point
to external registered objects by URL, and to registered objects or registry entries in other
conforming registry/repositories by URN.
Web Services
A Web Service is programmable application logic accessible using standard Internet
protocols. Web Services combine the best aspects of component-based development and the
WWW. Like components, Web Services represent black-box functionality that can be reused
without worrying about how the service is implemented. Unlike current component
technologies, Web Services are not accessed via object-model specific protocols, such as the
Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or
Internet Inter-ORB Protocol (IIOP). Instead, Web Services are accessed via ubiquitous Web
protocols and formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup
Language (XML). Furthermore, a Web Service interface is defined strictly in terms of the
messages the Web Service accepts and generates. Consumers of the Web Service can be
implemented on any platform, and in any programming language, as long as they can create
and consume the messages defined for the Web Service interface.
There are some key specifications and technologies being defined or available today that
address the five basic requirements for service-based development:
-
A standard way to represent data - XML is the obvious choice for a standard way to
represent data. Most Web Service related specifications use XML for data
representation, as well as XML schemas to describe data types [OpenLS, 2001].
- A common, extensible, message format - The Simple Object Access Protocol (SOAP)
defines a lightweight protocol for information exchange. Part of the SOAP
specification defines a set of rules for how to use XML to represent data. Other parts
of the SOAP specification define an extensible message format, conventions for
representing remote procedure calls (RPCs) using the SOAP message format, and
bindings to the HTTP protocol. SOAP is basically an HTTP POST with an XML
envelope as payload.
- A common, extensible, service description language - Given a Web Service, it would
be nice to have a standard way to document what messages the Web Services accepts
and generates – that is, to document the Web Service contract. The Web Services
Description Language (WSDL) is an XML-based contract language jointly developed
by Microsoft and IBM.
- A way to discover services located on a particular website – Developers will also
need some way to discover Web Services. This can be done using Advertisement and
Discovery of Services (ADS), an IBM solution, or Discovery of Web Services
(DISCO), a Microsoft solution. The Discovery Protocol (DISCO) specification
defines a discovery document format (based on XML) and a protocol for retrieving
the discovery document, enabling developers to discover services at a known URL.
- A way to discover service providers – In many cases the developer will not know the
URLs where services can be found. Universal Description, Discovery, and
Integration (UDDI) specifies a mechanism for Web Service providers to advertise the
existence of their Web Services and for Web Service consumers to locate Web
Services of interest, using a publish, find, and bind mechanism, see Figure 1 below.
Figure 1: Web Services Mechanism
For more information on the Web Services Architecture see [Kreger, 2001], or either the
IBM or Microsoft websites, as well as http://www.uddi.org for the latest on the Universal
Description, Discovery, and Integration specification.
The Web Services Flow Language (WSFL) is an XML language for the description of Web
Services compositions [Leymann, 2001], or service chaining. WSFL considers two types of
Web Services compositions:
- The first type specifies the appropriate usage pattern of a collection of Web Services,
in such a way that the resulting composition describes how to achieve a particular
business goal; typically, the result is a description of a business process.
- The second type specifies the interaction pattern of a collection of Web Services; in
this case, the result is a description of the overall partner interactions.
