Due Date: August 17, 2001 Annex B: OWS Architecture

Appendix B: General Services Model

B.1. Introduction

The objective of the OGC General Services Model (GSM) is to detail how geospatial software can plug into broader interoperability infrastructures to use and extend diverse, loosely coupled sources of data and services. The GSM draws on Topic 12 of the OGC Abstract Specification (Service Architecture) [1] but focuses more specifically on current technologies, platforms and mechanisms for enabling implementation of interoperable services. The vision is that applications can be dynamically composed of services discovered and marshaled at runtime for use by e-business, information clearinghouse, and enterprise applications. The GSM recognizes that there are many ways to instantiate a service and therefore describes the principles and basic model for creating dynamic, loosely coupled systems but no single implementation.

B.2. GSM Requirements

This section presents specific minimal functional requirements for the specification of services that aim for an appropriate balance of completeness, expressiveness, extensibility, and simplicity. They are intended to facilitate decision-making during development of interoperability specifications by the OGC. These functional requirements will change over time.

Promote interoperability.

It should be possible to implement services using a large number of different underlying infrastructures. The interaction between services should be completely platform and language independent. XML-based interface definition, service description and a protocol of collaboration and negotiation are the basis for shared understanding between services. Additional requirements include:

o The need to support many independently developed implementations of a given service (e.g., a gazetteer service).

o The need to support many independently provided instantiations of different kinds of services.

Enable just-in-time integration.

Discovery of services should be possible dynamically at runtime. A service requester should be able to describe the capabilities of the service required. Once a provider of service is found, there must be enough information to connect and access it. Additional requirements include:

o The need to find at runtime specific instantiations of services based on service type, service content, and service characteristics or quality-of-service. Automated discovery of services of unknown type is not required.

o The need to discover at runtime what services can be used with specific data holdings

o The need to enable ad-hoc chaining of services to satisfy aggregated workflow processes.

Reduce complexity.

In the GSM, all components are services. It is their behavior, through their published capabilities that is important, not how they are implemented. A service provider should have no knowledge of how a service requestor uses its service and, similarly, a service requestor should have no knowledge of how a service provider implements its service.

Page 1

Due Date: August 17, 2001 Annex B: OWS Architecture

Support legacy implementations.

By wrapping existing components, systems or applications and exposing them as services, the GSM should enable new levels of interoperability between and with legacy as well as new applications.

B.3. Service Roles and Operations

A service is a collection of operations, accessible through an interface, which allows a user to evoke a behavior of value to the user. [1] Typically, a service can be invoked using standardized protocols by a client from across a network independently of the platform, language and object model on which it was deployed.

In the GSM, there are three essential roles:

Service Provider – publishes services to a broker (registry) and delivers services to service requestors.

Service Requestor – performs discovery operations on the service broker to find the service providers it needs and then accesses service providers for provision of the desired service.

Service Broker – helps service providers and service requestors to find each other by acting as a registry or clearinghouse of services and content. Catalog and Registry services can be used as brokers.

Figure 5 depicts three basic and one optional operation that occur between requestor, provider and broker services.

Figure 1. Service Types and Operations of the GSM

Page 2

Due Date: August 17, 2001 Annex B: OWS Architecture

As shown, there are three essential kinds of operations performed by services:

Publish – The publish (and unpublish) operation is used to advertise (or remove) data and services to a broker (e.g., a registry, catalog or clearinghouse). A service provider contacts the service broker to publish or unpublish a service. A service provider typically publishes to the broker metadata describing, for example, its capabilities and network address.

Find – Service requestors and service brokers collaborate to perform the find operation. Service requestors describe the kinds of services they’re looking for to the broker and the broker delivers the results that match the request. Service requestors typically use metadata published to the broker to find service providers of interest.

Bind – The bind operation takes place between a service requestor and a service provider. The two parties negotiate as appropriate so the requestor can access and invoke services of the provider. A service requestor typically uses service metadata provided by the broker to bind to a service provider.

And one optional operation:

Chain – The chain operation binds a sequence of services where, for each adjacent pair of services, occurrence of the first action is necessary for the occurrence of the second action. [1]

The GSM distinguishes between service description and service implementation. This allows service requesters to bind to a specific implementation of a service provider at development time, at deployment time, or dynamically at runtime. The GSM uses service descriptions (i.e., metadata about services) to support Publish, Find, Bind and Chain operations. Service metadata plays three distinct roles in the GSM:

1. Metadata specifies the characteristics of a service provider. Service brokers use these characteristics to categorize service providers to support the find operation. The classification of services can be based on one or more hierarchical service taxonomies. Service requesters use these characteristics to match a service provider to their requirements.

2. Metadata specifies non-functional characteristics such as security, transactional requirements, cost of using the service provider, and others. Non-functional characteristics may be used to help a service requester find a service provider.

3. Metadata describes the interfaces used to access the service. The interface description includes its signature, allowed operations, data typing, and the access protocols. Service requesters use this information to bind to the service provider and invoke its services using the published interfaces.

Page 3

Due Date: August 17, 2001 Annex B: OWS Architecture

B.4. Elements of the General Service Model

The building blocks of the General Service Model are shown in Figure 6.

Figure 2. Building Blocks of GSM

A message (or more precisely, message type) is an abstract, typed definition of data being exchanged between services. Messages may be used (reused) by more than one operation. Concrete messages are defined as part of a concrete interface. [10]

An operation (aka, method or procedure) is an abstract, named specification of an action (e.g., a transformation or query) that a service may be requested to execute. It has a name a list of one or more input messages (parameters) and output messages (results). An operation is scoped by its interface such that the same operation (name and messages) could be used in multiple interfaces, even if the operation has different semantics in different interfaces. Concrete operations are defined as part of a concrete interface. (Adapted from [UML Reference Manual, p. 369] and [10].)

An interface is an abstract, named set of operations that characterize the behavior of a service. An interface is abstract when it is specified independently of a binding. When an interface is associated with a service through a binding, the interface is said to be concrete. An interface may have one or more concrete interfaces. One or more services may implement an interface. The interface defines the scope of its operations. (Adapted from [UML Reference Manual, p. 369] and [10].)

A service is a named set of concrete interfaces that together provide a distinct set of functionality. A service is an implementation of one or more interfaces. (Adapted from [1].)

A binding is a concrete protocol and data format specification for a particular interface implementation. A binding is used to relate an interface to a network-addressable service. [10]

Page 4

Due Date: August 17, 2001 Annex B: OWS Architecture

B.5. Service Capabilities, Interfaces and Content

The most basic operation that all services must provide is the ability to describe them. This is commonly called a “Get Capabilities” operation. The result of invoking this operation of a service is an XML-encoded message containing a “capabilities document” describing the service.

The capabilities document is a container of several units of information about a service. The first unit describes the service interface in sufficient detail so that an automated process can read the description and invoke an operation that the service advertises. A second unit describes the data content of the service (or the data it operates on) in a way that enables service requestors to dynamically compose requests for service. This content unit description is optional, depending on whether the service contains or operates on data content. Additional description units provide information specific to particular types of services as well as specific instances of services.

Per the GSM Publish-Find-Bind paradigm, all services must be able to describe themselves in sufficient detail such that:

1. An automated process can parse the description and determine how to invoke any operation the service advertises.

2. An automated process could harvest the description for inclusion in a broker service (e.g., registry or catalog).

In addition, services should, if appropriate, describe the content they serve or operate on so that:

1. Someone (a client) accessing the service directly can know what data the service has or can operate on and their schema,

2. A catalog (or registry) can automatically harvest the information.

B.6. The Basic Service Model (BSM)

Open Web Services are the subject of detailed implementation specifications. The services all differ in their purposes and details, but share a number of common elements. The BSM normatively specifies those common elements of OWS interfaces, operations, messages and encodings. The BSM additionally defines a hierarchy of service interfaces defining a framework on which new operations and interfaces can be defined through extension, restriction or both.

B.7. The Interoperability Stack

The “interoperability stack” presented here and in Figure 7 describes a layered architecture of technology and standards on which services can be implemented and deployed. The lowest levels of the stack enable connectivity of software components by enabling them to bind, send and receive messages. Higher levels in the stack enable interoperability and, via publish-find-bind mechanisms, allow software components to transparently work together in more integrated and dynamic ways.

Page 5

Due Date: August 17, 2001 Annex B: OWS Architecture

Figure 3. Services Interoperability Stack

At the foundation of the stack are communication protocols such as TCP/IP, HTTP, SMTP, IIOP and FTP. With the exception of pure binary data, structured data will typically be encoded as XML. Formats for data encoding are described in a schema language such as DTD, XML Schema, RDF or XMI. OGC has defined a family of schemas for encoding simple features as “well-known” binary (WKB) and plain text (WKT) as well as GML for encoding features as XML.

The distributed computing platform (DCP) layer is focused primarily on the infrastructure for enabling distributed services. A DCP is a standardized software environment enabling distributed computing by supporting cooperation between software executing on multiple computers that communicate over a communications network. [16] To the extent services are constructed from reusable software components, standard (or at least widely used) DCPs such as COM, CORBA, J2EE and SQL reside in this layer. Similarly, HTTP and SOAP are infrastructure technologies specifically enabling binding to services deployed across the Web.

For the services layer, OGC has defined implementation specifications for accessing and manipulating “simple features” via bindings for the COM, CORBA and SQL platforms. Additional implementation specifications from OGC include Gridded Coverages and Coordinate Transformations. New implementation specifications are emerging from the OGC specification process for Feature and Coverage access, Portrayal, Gazetteer, Geocoder and Geoparser services for the Web.

The Service Description layer is used to provide fundamental information required for services to discover, bind and interoperate. These include:

Types of messages being exchanged between a service provider and a service requestor.

Operations supported by a service provider.

Rules for binding to a service provider.

Page 6

Due Date: August 17, 2001 Annex B: OWS Architecture

The network address of a service provider.

The Service Discovery layer is the set of standards and technologies for publishing and finding service providers. Service descriptions tell where and how to access web services. Service discovery enable web service descriptions to be found and utilized by service requestors. The UDDI is an emerging technology for defining mechanisms for discovery of Web Services. The OGC Catalog Service implementation specification defines a service for supporting the discovery of geospatial content and services.

The top-level Integration and Workflow layer is focused on standards and technologies for enabling integration of services to support decision-making, modeling, workflow and business process integration within organizations and among Information Communities.

B.8. GSM Profiles

This section describes “profiles” of the GSM. A profile, in this context, is a set of standards and technologies that can be used to implement and deploy services. Five profiles have been identified:

Web Services

HTTP GET/POST

CORBA

COM

J2EE

SQL

B.8.1. Web Services

A Web Service is a network-based, distributed, modular component that performs specific tasks, and conforms to a specific set of technical specifications that make it interoperable with compatible components. Figure 8 shows five types of technology stacks, one for each of the basic publish-find-bind-chain operations of the GSM (plus Security) that are relevant to Web Services.

Page 7

Due Date: August 17, 2001 Annex B: OWS Architecture

Figure 4. Web Services Technology Stacks

The core Web Services technologies of WSDL, UDDI, SOAP and XLANG/WSFL are discussed briefly below. .

B.8.1.1. WSDL

Web Services Description Language (WSDL) is a new specification from W3C to describe networked services. WSDL is used to describe what a web service can do, where it resides, and how to invoke it. It provides a simple way for service providers to describe the basic format of requests to their systems. WSDL is a key complement to the effort of the Universal Description, Discovery and Integration (UDDI) initiative to provide directories and descriptions of such on-line services for electronic business. According to the W3C Specifications “WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).”

The Web Services Description Language (WSDL) describes web services at the level of UDDI green pages. WSDL defines a Web service as a set of ports. A port represents a mapping of an abstract port type to a concrete communication protocol used to invoke the Web service. WSDL supports the definition of data types that comprise the messages. A service provider uses WSDL documents to publish Web services, to find published services and to bind to services dynamically.

B.8.1.2. UDDI

Universal Description, Discovery, and Integration (UDDI) provides a mechanism for clients to dynamically find web services. UDDI consists of two main parts: 1. The UDDI cloud of operator nodes, an Internet-wide repository (made up of white, yellow, and green pages) for Web services metadata; and 2. An API and data model standard for a Web services metadata repository. The former hosts the data while the latter provides a means to access it.

UDDI defines open, platform-neutral, XML-based service description. It also defines an API for a service broker. UDDI provides an open, extensible model for describing Web services, and relies on numerous business technologies and standards. UDDI provides a three-layered approach to describe web services:

The "white pages" contain basic nonfunctional information on service provider.

The "yellow pages" contain more descriptive information, such as industry classification and geographic location. UDDI adopts three standards for categorizing industries, services, geographic locations:

o The NAICS US Government standard industry codes,

o The UN/SPSC (ECMA) product and services codes

o Geographic taxonomies.

The "green pages" contain the interface definitions required to invoke a Web service made available by a service provider.

Currently, the most important form of UDDI is the UDDI operator cloud. The UDDI operator cloud is a collection of UDDI nodes coordinated by an operator's agreement to provide uniform access to Web services metadata from any of the operator nodes. If Web services metadata is entered in one operator node, it can, with some reasonable time delay, be retrieved from any of the other operator nodes. The operator nodes share the data using a well-defined replication scheme.

Page 8

Due Date: August 17, 2001 Annex B: OWS Architecture

UDDI registries define four basic data elements within the data model in version 1.0: businessEntity (modeling business information), businessService (high level service description), tModel (modeling a technology type or service type), and bindingTemplate (mapping between businessService and tModels):

Business information: Contained in a BusinessEntity object, which in turn contains information about services, categories, contacts, URLs, and other things necessary to interact with a given business. This corresponds the Information Communities defined in OWS

Service information: Describes a group of Web services. These are contained in a BusinessService object.

Binding information: The technical details necessary to invoke a Web service. This includes URLs, information about method names, argument types, and so on.

Information about specifications for services: This is metadata about the various specifications implemented by a given Web service. These are called tModels in the UDDI specification.

B.8.1.3. SOAP

The Simple Object Access Protocol (SOAP) is a protocol specification that defines a uniform way of passing XML-encoded data. It also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol.

SOAP has three major parts for defining a message exchanged between two components:

The envelope defines a framework for describing message content and how to process it.

The encoding rules define a serialization mechanism used to exchange application-defined data types.

The remote procedure call (RPC) convention enables basic request/response interactions.

B.8.1.4. WSFL and XLANG

In addition to the work at ISO and OGC, IBM and Microsoft have introduced their own methods of supporting business workflows, and thus deal with service chaining to some degree. The Web Services Flow Language [17], developed by IBM, "is an XML language for the description of Web Services compositions. WSFL considers two types of Web Services compositions: The first type (flow models) 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 (global models) specifies the interaction pattern of a collection of Web Services; in this case, the result is a description of the overall partner interactions." XLANG, developed by Microsoft, is a "notation for the specification of message exchange behavior among participating Web services" supporting mainly the automation of business processes. [18] XLANG “is expected to serve as the basis for automated protocol engines that can track the state of process instances and help enforce protocol correctness in message flows”. XLANG is an "XML business process language, which provides a way to orchestrate applications and XML Web services into larger-scale, federated applications by enabling developers to aggregate even the largest applications as components in a long-lived business process. XLANG has a two-fold relationship with WSDL. An XLANG service description is a WSDL service description with an extension element that describes the behavior of the service as a part of a business process. XLANG service behavior may also rely on simple WSDL services as providers of basic functionality for the implementation of the business process." IBM's Web Services Flow Language, under development in Q2 2001, may be harmonized with the Microsoft XLANG specification.

Page 9

Due Date: August 17, 2001 Annex B: OWS Architecture

Note: Per Gartner analysis, "...Gartner expects IBM and Microsoft to jointly agree to submit a proposal to W3C that combines XLANG and WSFL by year-end 2001".

B.8.2. HTTP (GET/POST/MIME)

OGC has defined a suite of Web Service interfaces that have explicit bindings for HTTP [13]. Specifically, there are two HTTP bindings for invoking operations of a service (i.e., sending a message): GET and POST. Thus the Online Resource of each operation supported by a service instance is an HTTP Uniform Resource Locator (URL). The URL may be different for each operation, or the same, at the discretion of the service provider. Each service URL must conform to the description in [13] but is otherwise implementation-dependent; only the parameters comprising the service request itself are mandated by OGC Web Service specifications for HTTP.

The normative rules for HTTP bindings are specified in the OGC Basic Service Model Discussion Paper [15]. They are summarized briefly here:

An Online Resource URL intended for HTTP GET requests is in fact only a URL prefix to which additional parameters must be appended in order to construct a valid Operation request. A URL prefix is defined as an opaque string including the protocol, hostname, optional port number, path, a question mark '?', and, optionally, one or more server-specific parameters ending in an ampersand '&'. The prefix uniquely identifies the particular service instance. A client appends the necessary request parameters as name/value pairs in the form "name=value" using the “&” character to separate the pairs. The resulting URL must be valid according to the HTTP Common Gateway Interface (CGI) standard.

An Online Resource URL intended for HTTP POST requests is a complete and valid URL to which a Client transmits request parameters in the body of the POST request (typically as an XML instance). Services implementing pure HTTP bindings must not require additional parameters to be appended to the URL in order to construct a valid target for the Operation request.

Upon receiving a valid request, the service must send a response corresponding exactly to the request as detailed in the appropriate specification. Only in the case of Version Negotiation between service requestors and service providers, may the service provider offer a differing result. Response objects must be accompanied by the appropriate Multi-purpose Internet Mail Extensions (MIME) type [14] for that object.

B.8.3. CORBA

TBD.

B.8.4. COM

TBD.

B.8.5. J2EE

TBD.

B.8.6. SQL

TBD.

B.9. Future Work

Next steps for refining the GSM include the following work items:

Page 10

Due Date: August 17, 2001 Annex B: OWS Architecture

1. Investigate and specify Service Description Languages (e.g., WSDL or an extended WSDL)

2. Investigate and specify Content Description Languages (such as FGDC, GILS, ISO-19115) for describing data served by or operated on a service implementation.

3. Design and/or refactor the BSM service capabilities document.

4. Design and/or refactor the BSM common elements of OWS interfaces, operations and encodings.

5. Develop a BSM taxonomy of service types and interfaces.

6. Develop a GSM glossary.

B.10. References

1. Topic 12, Service Architecture. OGC Abstract Specification, available online: http://www.opengis.org/public/abstract/01-112.pdf

2. OpenGIS® Simple Features Specification for OLE/COM, available online: http://www.opengis.org/techno/specs/99-050.pdf

3. OpenGIS® Simple Features Specification for CORBA, available online: http://www.opengis.org/public/sfr1/sfcorba_rev_1_0.pdf

4. OpenGIS® Simple Features Specification for SQL, available online: http://www.opengis.org/techno/specs/99-049.pdf

5. OpenGIS® Grid Coverages Implementation Specification, available online: http://www.opengis.org/techno/specs/01-004.pdf

6. OpenGIS® Coordinate Transformation Services Implementation Specification, available online: http://www.opengis.org/techno/specs/01-009.pdf

7. OpenGIS® Web Map Server Interfaces Implementation Specification, available online: http://www.opengis.org/techno/specs/01-047r2.pdf

8. OpenGIS® Geography Markup Language (GML) Implementation Specification, available online: http://www.opengis.net/gml/01-029/GML2.html

9. OpenGIS® Catalog Interface Implementation Specification, available online: http://www.opengis.org/techno/specs/99-051.pdf

10. Web Services Description Language. W3C. Available online: http://www.w3.org/TR/2001/NOTE-wsdl-20010315

11. Simple Object Access Protocol (SOAP) 1.1. W3C. Available online: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

12. Universal Description, Discovery and Integration 2.0. uddi.org. Available online: http://www.uddi.org/

13. Fielding et. al., “RFC 2616: Hypertext Transfer Protocol – HTTP 1/1” June 1999, Internet Society Network Working Group, ftp://ftp.isi.edu/in-notes/rfc2616.txt

14. Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

Page 11

Due Date: August 17, 2001 Annex B: OWS Architecture

15. de La Beaujardière, J. (ed.), "OpenGIS Discussion Paper #01-022r1: OpenGIS Basic Services Model Draft Candidate Implementation Specification 0.0.8," March 2001, http://www.opengis.org/techno/discussions.htm.

16. Whiteside, A. (ed), “OpenGIS Discussion Paper #01-013r1.doc: High-Level Ground Coordinate Transformation Interface,” February 2001, http://www.opengis.org/techno/discussions.htm.

17. Web Service Flow Language (WSFL), available at: www.oasis-open.org/cover/wsfl.html

18. XLANG. Available at: http://xml.coverpages.org/xlang.html

Page 12

Due Date: August 17, 2001 Annex B: OWS Architecture

Page 13