Registry Integration Module (RIM) 1.0.0

Implementation Specification October 2017

Table of Contents

• 1 Scope
• 1.1 Scope
• 1.2 Introduction
• 1.3 Audience
• 1.4 Applicability
• 1.4 Notational Conventions
• 2 References
• 3 Architecture
• 3.1 Resources
• 3.2 Data Model
• 3.2.1 Logical Data Model
• 3.2.2 XML Schema
• 3.3 Binding
• 4 Interface
• 4.1 Request
• 4.2 Response
• 5 Operations
• 5.1 GetRegistry
• 5.2 GetIndex
• 5.3 GetServiceDescription
• 5.4 GetServiceProfile
• 6 Security
• Appendixes
• Appendix A WADL Document
• Appendix B WSDL Document




1 Scope

1.1 Scope

This specification prescribes requirements for the development of the Registry Integration Module (RIM) for System Wide Information Management (SWIM) registries. This document specifies the interfaces, bindings, and a data model for defining application profiles required to publish and access services-related information in SWIM registries through machine-readable interfaces..

1.2 Introduction

Growing collaboration between international SWIM communities has presented new requirements for SWIM implementers, not just to exchange data among service components but also to exchange metadata including information about available services. To address these needs, the U.S. Federal Aviation Administration (FAA) and EUROCONTROL engaged in a joint effort to develop RIM, as a part of the Single European Sky ATM Research Programme (SESAR) Joint Undertaking (SJU) Coordination Plan 2.1.

RIM is a pluggable registry module whose goal is to enable dynamic exchange of service metadata among registries. RIM utilizes a well-known architectural paradigm, REST [REST], and a set of ubiquitous Web standards and protocols (e.g., URI, HTTP, XML).

Although RIM was designed to exchange service metadata between two SWIM registries, the SESAR European SWIM Registry and the FAA National Airspace System (NAS) Service Registry/Repository (NSRR), it also can be utilized by any other registry, or by any Web application supporting this specification.



Figure 1 Integrating SWIM Registries by using RIM

1.3 Audience

The intended audience of this specification includes:

• Architects and developers designing, identifying, developing or maintaining service registries that will participate in national or international SWIM efforts.
• Standards architects and analysts developing specifications for finding or exchanging information about services (service metadata) maintained in SWIM service registries.
• Developers designing or creating Web applications for finding or exchanging service metadata maintained in SWIM service registries.
• Users who want a better understanding of the SWIM registry integration effort.

1.4 Applicability

This specification does not prescribe or limit the technological solutions for any registry. Rather, it seeks to provide a syntactic basis for building Web applications for finding or sharing services-related information in different SWIM registry implementations. This specification does not prescribe any configuration management (CM) or quality assurance (QA) policies, rules or assertions that a service registry may be subjected to. Finally, this specification does not prescribe any governance policies, rules or procedures that a service registry may be subjected to.

1.5 Notational Conventions

The keywords "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this document are to be interpreted as described in the IETF RFC 21196. When these words are not capitalized, they are meant in their natural-language sense.





2 References

[REST]	Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, Fielding, Roy Thomas, University of California, Irvine, 2000 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
[UML]	Unified Modeling Language™ version 2.5, Object Management Group (OMG), 2015, http://www.omg.org/spec/UML/2.5/
[HTTP-RFC]	HTTP/1.1, RFC 2616, Fielding, Roy T., Tim Berners-Lee, et al., RFC Editor, 1999 http://www.rfc-editor.org/rfc/rfc2616.txt
[URI-RFC]	Uniform Resource Identifier (URI): Generic Syntax, RFC 3986, Berners-Lee, Tim, Roy T. Fielding, et al., RFC Editor, 2005 http://www.rfc-editor.org/rfc/rfc3986.txt
[SDCM]	Service Description Conceptual Model (SDCM) 2.0, June 2016 http://swim.aero/sdcm/2.0.0/sdcm-2.0.0.html
[XML-1.0]	Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008 http://www.w3.org/TR/2008/REC-xml-20081126/
[WADL]	Web Application Description Language, W3C Member Submission 31 August 2009 http://www.w3.org/Submission/2009/SUBM-wadl-20090831/
[WSDL]	Web Service Description Language, W3C Recommendation 26 June 2007 https://www.w3.org/TR/wsdl20/
[HTTP-Auth]	HTTP Authentication: Basic and Digest Access Authentication, RFC 2617, J. Franks., et al, RFC Editor, 1999 https://tools.ietf.org/html/rfc2617
[OAuth]	The OAuth 2.0 Authorization Framework, RFC 6749, D. Hardt., RFC Editor, 2012 https://tools.ietf.org/html/rfc6749





3 Architecture

RIM deploys a number of architectural and technological approaches, including:

• Using HTTP as a transport protocol, the most interoperable protocol on the Web.
• Exposing information as resources that are uniquely identified using Web standards. Since service data are exchanged among multiple registries, such unique identification allows users to quickly identify the authoritative information source for each service.
• Supporting easy navigation. Links are provided between information resources so that a user can quickly discover information of interest, another key feature of the Web. For example, a registry may provide an index of all published services, and then allow the user to follow navigable links to individual service descriptions, even specific metadata elements within a service description.

RIM utilizes the Service Description Conceptual Model (SDCM) [SDCM] – another joint effort by EUROCONTROL and FAA – to describe relationships between elements of a service description and provide a common vocabulary for terms used within the model.

As depicted in the conceptual architecture in Figure 2, the RIM can be realized as a pluggable component that would provide the registry with additional functionalities without affecting current registry operations. By utilizing the existing registry’s database as a data source, RIM can ensure the information’s consistency across all interfaces provided by the registry.



Figure 2 RIM Conceptual Architecture

3.1 Resources

The RIM interface is a collection of interlinked resources identified by URIs [URI-RFC]. Registries that implement the RIM specification SHALL assign a globally unique, HTTP-based URI called a global registry identifier (GRID) when a service is first published. Furthermore, the registry MUST ensure that the GRID is dereferenceable, i.e., a resource representation will be returned when an HTTP request is received with the GRID as the requested URI.

The RIM interface SHALL include the resources as listed in Table 1.

Table 1 RIM Resources

Resource URI template	Description
/registry	A resource representing the registry. It includes a basic description of the registry and contact information for the registry provider.
/index	A resource representing all the services published in the registry. It includes an index of all services registered.
/service-description?{GRID}	A resource representing the description of a service published in the registry. The registry must redirect an HTTP request addressed to the GRID to this resource.
/profile?{GRID}	A resource representing the profile of a service published in the registry. The registry must redirect an HTTP request addressed to the URI {GRID}/profile to this resource.

A registry MAY define additional resources. Furthermore, a registry MAY support additional query parameters for GET requests. For example, a registry may allow retrieval of registered entities modified after a certain date. Therefore, when a registry receives an HTTP request with query parameters it does not support, it MUST reject the request with HTTP response code 400. (See Section 4.2 below.)

All resources exposed by the RIM SHALL be interlinked to allow a user to traverse through the entire collection of resources.

The RIM resource model reflected in the UML class diagram [UML] in Figure 3 uses the following diagrammatic conventions:

• Each resource exposed through the RIM is modeled as a UML class with the stereotype "Resource". The Resource stereotype has a property describing the resource’s URL pattern.
• Navigable links between resources are modeled as attributes or directed associations with the stereotype "locator". The GRID is a locator.


Figure 3 Resource Model

Web Application Description Language (WADL) [WADL] and Web Service Description Language (WSDL) [WSDL] definitions of these resources are included in Appendix A and Appendix B.

3.2.1 Data Model

3.2.1 Logical Data Model

The data model of the data accessible via the RIM has two components, as shown in Figure 4:

A Service Description model that is based on the Service Description Conceptual Model (SDCM) [SDCM]. The SDCM does not suggest any technologies or implementation details but rather seeks to provide a common understanding that is expected to be used unambiguously between different implementations. This specification defines a data model that derives from the SDCM and supports the given architecture and resource model. Note: as a part of the initial implementation of the RIM, this data model only includes a subset of information defined in the SDCM.

Navigable links between resources are modeled as attributes or directed associations with the stereotype "locator". The GRID is a locator.



Figure 4 Data Model

3.2.2 XML Schema

The XML Schema presented in this section serves as the physical data model for describing data elements transmitted via the RIM. Based on the logical model described in the previous section, the RIM defines two XML schemas:

• A registry schema that defines types and elements representing RIM resources, as shown below. The registry schema has the namespace "http://swim.aero/rim/1.0.0".
• A service description schema (SDM-X) based on the SDCM. The service description schema has the namespace "http://swim.aero/sdm-x/1.0.0".

  
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:reg="http://swim.aero/rim/1.0.0"
	xmlns:sd="http://swim.aero/sdm-x/1.0.0"
	targetNamespace="http://swim.aero/rim/1.0.0"
	elementFormDefault="qualified"
	version="1.0.0">
	<xsd:annotation>
		<xsd:appinfo>
			<dc:identifier>http:/swim.aero/rim/</dc:identifier>
			<dc:title> "Registry Interchange Model (RIM)"</dc:title>
			<dc:version>1.0.0</dc:version>
			<dc:description>This schema defines data elements to be used for
			exchange of information among RIM-implementing registries.
			</dc:description>
			<dc:publisher>FAA/SESAR</dc:publisher>
			<dc:issued>2017-10-12</dc:issued>
			<dc:format>XML</dc:format>
		</xsd:appinfo>
	</xsd:annotation>
	<xsd:import namespace="http://swim.aero/sdm-x/1.0.0"
		schemaLocation="http://swim.aero/sdm-x/1.0.0/service-description.xsd"/>
	<xsd:import namespace="http://www.w3.org/1999/xlink"
		schemaLocation="https://www.w3.org/1999/xlink.xsd" />

	<xsd:element name="Registry" type="reg:RegistryType">
		<xsd:annotation>
			<xsd:documentation>
				This element represents an instance of a RIM-implementing registry.
				It is a root element for this schema.
			</xsd:documentation>
		</xsd:annotation>
	</xsd:element>

	<xsd:element name="Index" type="reg:IndexType">
		<xsd:annotation>
			<xsd:documentation>
			This element represents an indexed list of all entities registered
			-- defined by the RegisteredEntity element -- in the Registry.
			</xsd:documentation>
		</xsd:annotation>
	</xsd:element>

	<xsd:complexType name="RegistryType">
		<xsd:sequence>
			<xsd:element name="Name" type="xsd:string" />
			<xsd:element name="Description" type="xsd:string" />
			<xsd:element name="Version" type="xsd:string" />
			<xsd:element name="Provider" type="sd:ProviderType" />
			<xsd:element name="Index" type="reg:IndexType" minOccurs="0"/>
		</xsd:sequence>
		<xsd:attribute name="registryId" type="xsd:anyURI" />
	</xsd:complexType>

	<xsd:complexType name="IndexType">
		<xsd:sequence>
			<xsd:element name="RegisteredService" type="reg:RegisteredServiceType"
				minOccurs="0" maxOccurs="unbounded" />
		</xsd:sequence>
		<xsd:attribute ref="xlink:type" fixed="locator" />
		<xsd:attribute ref="xlink:href" use="required" />
		<xsd:attribute ref="xlink:title" fixed="registryId" />
	</xsd:complexType>

	<xsd:complexType name="RegisteredEntityType" abstract="true">
		<xsd:annotation>
			<xsd:documentation >
			This abstract element represents the notion that different entities can
			be registered and subsequently presented by a RIM-implementing registry via the
			described interface. Although in this version
			only services are expected to be registered and presented, this element
			is established for future use.
			 Name - the name of the entity.
			 Description - a brief description of the entity.
			 Category - one of the values from a predefined set of taxonomies.
			 Created - the time and date when the entity was created or added to the
			 registry.
			 LastModified - the time and date of last update of the entity.
			 GRID - the Global Registry Identifier that references the entity in the
			 context of its hosting registry.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="Name" type="xsd:string" />
			<xsd:element name="Description" type="xsd:string" />
			<xsd:element name="Category" type="sd:CategoryType"
				minOccurs="0" maxOccurs="unbounded" />
			<xsd:element name="Created" type="xsd:dateTime" />
			<xsd:element name="LastModified" type="xsd:dateTime" />
		</xsd:sequence>
		<xsd:attribute ref="xlink:type" fixed="locator" />
		<xsd:attribute ref="xlink:href" use="required" />
		<xsd:attribute ref="xlink:title" fixed="GRID" />
	</xsd:complexType>

	<xsd:complexType name="RegisteredServiceType">
		<xsd:annotation>
			<xsd:documentation >
			This element represents a registered service in the context of a RIM
			registry. It extends RegistryEntityType by adding to the base class
			content a predefined set of values from three standard taxonomies.
			These taxonomies are designed to classify registered services and also
			are used to support a search via RIM.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="reg:RegisteredEntityType">
				<xsd:sequence>
					<xsd:element name="ServiceProductCategory"
						type="reg:ServiceProductCategoryType" />
					<xsd:element name="AvailabilityStatusCategory"
						type="reg:AvailabilityStatusCategoryType" />
					<xsd:element name="InterfaceTypeCategory"
						type="reg:InterfaceTypeCategoryType" />
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="ServiceProductCategoryType">
		<xsd:annotation>
			<xsd:documentation >
			A classification of services based on the type of SWIM data product that
			they deliver.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="sd:CategoryType">
				<xsd:sequence>
					<xsd:element name="Taxonomy" type="xsd:anyURI"
						fixed="http://semantics.aero/service-product" />
					<xsd:element name="Code">
						<xsd:simpleType>
						<xsd:restriction base="xsd:anyURI">
						<xsd:pattern
							value="http://semantics.aero/service-product#[\S]+" />
						</xsd:restriction>
						</xsd:simpleType>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="InterfaceTypeCategoryType">
		<xsd:annotation>
			<xsd:documentation >
			A classification of services based on the type of technological solution
			that they deploy.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="sd:CategoryType">
				<xsd:sequence>
					<xsd:element name="Taxonomy" type="xsd:anyURI"
					fixed="http://semantics.aero/interface-type" />
					<xsd:element name="Code">
						<xsd:simpleType>
							<xsd:restriction base="xsd:anyURI">
								<xsd:pattern
							value="http://semantics.aero/interface-type#[\S]+" />
							</xsd:restriction>
						</xsd:simpleType>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="AvailabilityStatusCategoryType">
		<xsd:annotation>
			<xsd:documentation >
			A classification of services based on their current, past, or future
				availability for provisioning.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="sd:CategoryType">
				<xsd:sequence>
					<xsd:element name="Taxonomy" type="xsd:anyURI"
					fixed="http://semantics.aero/availability-status" />
					<xsd:element name="Code">
						<xsd:simpleType>
							<xsd:restriction base="xsd:anyURI">
				<xsd:pattern
				value="http://semantics.aero/availability-status#[\S]+" />
							</xsd:restriction>
						</xsd:simpleType>
					</xsd:element>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:complexType name="ProfileType">
		<xsd:annotation>
			<xsd:documentation>
				This element represents a Profile resource by extending the
				ProfileType defined in the ServiceDescription schema,
				and adding a link to the Service Description resource.
			</xsd:documentation>
		</xsd:annotation>
		<xsd:complexContent>
			<xsd:extension base="sd:ProfileType">
				<xsd:attribute ref="xlink:type" fixed="locator" />
				<xsd:attribute ref="xlink:href" use="required" />
				<xsd:attribute ref="xlink:title" fixed="GRID" />
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

	<xsd:element name="ServiceDescription" type="sd:ServiceDescriptionType">
		<xsd:annotation>
			<xsd:documentation >
			This element is fully defined in the ServiceDescription schema.
			It is re-declared in this schema only to make the described RIM API complete.
			</xsd:documentation>
		</xsd:annotation>
	</xsd:element>

	<xsd:element name="Profile" type="reg:ProfileType">
		<xsd:annotation>
			<xsd:documentation>
				Represents a Profile resource.
			</xsd:documentation>
		</xsd:annotation>
	</xsd:element>
</xsd:schema>
  

3.3 Binding

The RIM deploys a multilayer binding model typical for Web applications, with each layer binding to a specific protocol or a model.

Table 2 RIM Binding Model

Layer	Protocol or Model
Transport	Public Internet (TCP/IP)
Data	Data model as defined in section 3.2 of this specification.
Message	HTTP v.1.1 [HTTP-RFC]
Presentation	XML 1.0 [XML-1.0]/HTML 1.1[HTTP-RFC]




4 Interface

The RIM inherently supports all aspects of HTTP including request methods, response codes and message headers. All messages consumed and produced by the RIM SHALL conform to the syntax defined in HTTP 1.1 [HTTP-RFC].

Sections 4.1 and 4.2 specify requirements for HTTP request and response messages respectively.

4.1 Request

The RIM MUST accept GET HTTP request messages as listed in Section 5.

The RIM MAY reject an HTTP request when the request header field "Accept" does not contain the value "application/xml".

4.2 Response

When the client request indicates an HTTP method not supported by the registry (for example "PUT" or "DELETE"), the RIM SHOULD respond with HTTP status code "405 Method Not Allowed". The response message SHALL include a header field "Allow" with the value ‘GET’.

When a request message includes an "Accept" header field with values other than "application/xml", the RIM SHALL return HTTP status code "406 Not Acceptable".

When a requested resource(s) is returned by the RIM, the response message SHALL include HTTP status code "200 OK". The response body SHALL include a representation of the requested resource as specified in Section 5.

When a resource name (resource URI) in an HTTP request line (e.g., GET /services/fps HTTP/1.1) is syntactically invalid, i.e., does not conform to one of the URI templates listed in Table 1, or the request includes an HTTP parameter that the registry does not support, the RIM SHALL respond with HTTP status code "400 Bad Request".

When a resource name supplied in the RIM HTTP request is syntactically valid, that is, compliant with the set of URI templates listed in Table 1, but no resource exists for a given URI (e.g., there is no service in the registry with a provided GRID), HTTP status code "404 Not Found" SHALL be returned.

When a requested resource contains no data (e.g., Grounding may have no data entered in a registry in the early stages of a service’s development), HTTP status code "204 No Content" SHALL be returned to signal that the response body is intentionally empty.




5 Operations

The RIM SHALL implement the operations described in this section.

5.1 GetRegistry

Description	Allows clients to retrieve basic information about the registry.
HTTP Method	GET
URI template	/registry
Obligation	Required
Input	None
Output	A representation of Registry object.

Example of code:

# Request
GET /registry HTTP/1.1 Host: nsrr.faa.gov
Accept: application/xml

# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<reg:Registry registryId="http://nsrr.faa.gov" xmlns:reg="http://swim.aero/rim/1.0.0"
    xmlns:sd="http://swim.aero//sdm-x/1.0.0" xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <reg:Name>NSRR</reg:Name>
    <reg:Description>NAS Service Registry and Repository</reg:Description>
    <reg:Version>2.0.0</reg:Version>
    <reg:Provider>
        <sd:Name>Federal Aviation Administration (FAA) </sd:Name>
        <sd:Description>Maintained by the FAA SWIM program</sd:Description>
        <sd:WebPage>http://www.faa.gov</sd:WebPage>
        <sd:PointsOfContact>
            <sd:POC>
                <sd:Name>John Doe</sd:Name>
                <sd:Function>System Administrator</sd:Function>
                <sd:Phone>tel:+1-202-555-1212</sd:Phone>
                <sd:Email>admin@example.gov</sd:Email>
            </sd:POC>
        </sd:PointsOfContact>
    </reg:Provider>
</reg:Registry>

5.2 GetIndex

Description	Allows clients to retrieve basic information about the registry.
HTTP Method	GET
URI template	/registry
Obligation	Required
Input	None
Output	A representation of Registry object.

The GetIndex request has the following parameters:

Name	availability-status
Permissible Value	Values as defined in http://semantics.aero/availability-status
Optional	Yes

Name	service-product
Permissible Value	Values as defined in http://semantics.aero/service-product
Optional	Yes

Name	interface-type
Permissible Value	Values as defined in http://semantics.aero/interface-type
Optional	Yes

The taxonomy parameters in the GetIndex request can be specified by either using the full URI or just the last URI fragment. If the full URI is used for a taxonomy parameter, the registry MUST assume the URI has been encoded to escape special characters. In such cases, the registry MUST interpret the parameter by decoding it in accordance with [URI-RFC]. For example, http%3A%2F%2Fswim.aero%2Fsemantics%2Favailability-status%23operational specified in a GetIndex request will be decoded to http://semantics.aero/availability-status#operational.

The registry MUST return the same result in response to the following requests:

• GET /index?availability-status=http%3A%2F%2Fswim.aero%2Fsemantics%2Favailability-status%23operational
• GET /index?availability-status=operational

When a GetIndex request contains multiple parameters, it SHALL be interpreted as a logical AND. However, when multiple values are specified for the same parameter, they are interpreted as a logical OR. Values for the same parameter are separated by ",". For example, when a registry receives the following request:

GET /index?availability-status=operational,retired&interface-type=resource-oriented

The response MUST include only services that have an availability status of "operational" OR “retired” AND an interface type of "resource-oriented".

Example of code:

# Request
GET /index HTTP/1.1
Host: nsrr.faa.gov
Accept: application/xml
Authorization: Basic dXNlcjpwYXNzd29yZA==

# Response
HTTP/1.1 200 OK
Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<reg:Index xmlns:reg="http://swim.aero/rim /1.0.0" xmlns:sd="http://swim.aero/sdm-x/1.0.0"
    xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xlink:title="registryId " xlink:type="locator" xlink:href="https://nsrr.faa.gov">
    <reg:RegisteredService xlink:href="https://nsrr.faa.gov/services/fps" xlink:title="GRID"
        xlink:type="locator">
        <reg:Name>Flight Plan Service (FPS)</reg:Name>
        <reg:Description>A service for filing, updating, or canceling an IFR (Instrument Flight
            Rules) flight plan.</reg:Description>
        <reg:Created>2001-12-31T12:00:00</reg:Created>
        <reg:LastModified>2001-12-31T12:00:00</reg:LastModified>
        <sd:Taxonomy>
            <sd:Title>ATM Service Category</sd:Title>
            <sd:Value>Flight Planning</sd:Value>
        </sd:Taxonomy>
        <reg:ServiceProduct>
            <reg:Taxonomy>http://swim.aero/semantics/service-product</reg:Taxonomy>
            <reg:Code>http://swim.aero/semantics/service-product#flight</reg:Code>
        </reg:ServiceProduct>
        <reg:AvailabilityStatus>
            <reg:Taxonomy>http://swim.aero/semantics/availability-status</reg:Taxonomy>
            <reg:Code>http://swim.aero/semantics/availability-status#operational</reg:Code>
        </reg:AvailabilityStatus>
        <reg:InterfaceType>
            <reg:Taxonomy>http://swim.aero/semantics/interface-type</reg:Taxonomy>
            <reg:Code>http://swim.aero/semantics/interface-type#message-oriented</reg:Code>
        </reg:InterfaceType>
    </reg:RegisteredService>
</reg:Index>

5.3 GetServiceDescription

Description	Allows clients to retrieve information about a registered service.
HTTP Method	GET
URI template	/service-description?{GRID}, where {GRID} is the global registry ID for the service being requested.
Obligation	Required
Input	None
Output	A representation of ServiceDescription object.

This operation can also be invoked when the GRID is dereferenced. For example, the following URIs should cause the registry to return the same resource representation:

• http://nsrr.faa.gov/service-description?http://nsrr.faa.gov/services/fps
• http://nsrr.faa.gov/services/fps
Example of code:

# Request
GET /services/fps HTTP/1.1
Host: nsrr.faa.gov
Accept: application/xml
Authorization: Basic dXNlcjpwYXNzd29yZA==

# Response HTTP/1.1 200 OK
Content-Type: application/xml;charset=UTF-8

<ServiceDescription xmlns="http://swim.aero/rim/1.0.0">
	<Profile>
		<ServiceName>Flight Plan Service (FPS)</ServiceName>
		<ServiceVersion>1.0.0</ServiceVersion>
		<ServiceDescription>
		(This fictitious service is for instructional use only and cannot be consumed).
		A service for filing, updating, or canceling an IFR (Instrument Flight Rules) flight plan.
		</ServiceDescription>
		<sd:Categories xmlns:sd="http://swim.aero/rim/1.0.0">
			<sd:Category>
				<sd:Title>ATM Service Category</sd:Title>
				<sd:Value>Flight Planning</sd:Value>
			</sd:Category>
			<sd:Category>
				<sd:Title>SWIM Service Product Category</sd:Title>
				<sd:Value>Flight</sd:Value>
			</sd:Category>
			<sd:Category>
				<sd:Title>Lifecycle Status</sd:Title>
				<rim:Value xmlns:rim="http://swim.aero/rim/1.0.0">Development</rim:Value>
			</sd:Category>
		</sd:Categories>
		<Provider>
			<Name>FAA En Route Services Modernization Group (ESMG)</Name>
			<Description>A program within the FAA Air Traffic Organization
			responsible for developing Web services.
			</Description>
			<WebPage>http://www.faa.gov/air_traffic/flight_info</WebPage>
			<PointsOfContact>
				<POC>
					<Name>John  D. Doe</Name>
					<Function>ATO-X ESMG Manager</Function>
					<Phone>(609) 444-5555</Phone>
					<Email>Joe.doe@faa.gov</Email>
				</POC>
			</PointsOfContact>
		</Provider>
		<Functions>
			<Function>
				<Description>File a flight plan.</Description>
				<RealWorldEffect>A flight plan has been filed and persists in the FAA Web server
				for distribution to the FAA flight data processing application within
				some parameter time of the estimated departure time.
				</RealWorldEffect>
			</Function>
			<Function>
				<Description>Cancel a flight plan.</Description>
				<RealWorldEffect>A previously filed flight plan has been retracted
				before being submitted to FAA Air Traffic Services, thereby reducing
				the flight plan processing load and systemic workload of the FAA air
				traffic planning system.
				</RealWorldEffect>
			</Function>
			<Function>
				<Description>Change destination aerodrome of a flight plan.</Description>
				<RealWorldEffect>The destination aerodrome of a filed flight
				plan has been changed.
				</RealWorldEffect>
			</Function>
		</Functions>
		<SecurityMechanisms>
			<SecurityMechanism>
				<Name>Authorization</Name>
				<Description>The FPS deploys role-based access control (RBAC) for
				implementing authorization in accordance with ANSI/INCITS 359-2004.
				 Two roles are defined, “Reader” (a user who only has permission to view a filed
				flight plan) and “Originator” (a user, generally a pilot or operator, who submits
				a flight plan and has permission to file and subsequently modify or cancel
				the filed flight plan).
				</Description>
				<RegulatingProtocol>
					<Title/>
					<Location>
				http://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/ANSI+INCITS+359-2004.pdf
					</Location>
				</RegulatingProtocol>
			</SecurityMechanism>
			<SecurityMechanism>
				<Name>Integrity</Name>
				<Description>The FPS deploys Transport Layer Security (TLS) Version 1.2,
				RFC 5246; therefore data is checked for possible corruption.
				</Description>
				<RegulatingProtocol>
					<Title/>
					<Location>
					http://tools.ietf.org/html/rfc5246
					</Location>
				</RegulatingProtocol>
			</SecurityMechanism>
			<SecurityMechanism>
				<Name>Non-Repudiation</Name>
				<Description>The FPS complies with W3C's Recommendation for XML
				Signature Syntax and Processing to ensure that each user’s message
				is digitally signed.
				</Description>
				<RegulatingProtocol>
					<Title/>
					<Location>
					http://www.w3.org/TR/xmldsig-core
					</Location>
				</RegulatingProtocol>
			</SecurityMechanism>
			<SecurityMechanism>
				<Name>Authentication</Name>
				<Description>The FPS requires each service consumer to authenticate
				itself to the FPS at the transport level by deploying a Username/Token
				credential in accordance with the Web Services Security UsernameToken
				Profile 1.0, OASIS Standard 200401.
				</Description>
				<RegulatingProtocol>
					<Title/>
					<Location>
			http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
					</Location>
				</RegulatingProtocol>
			</SecurityMechanism>
			<SecurityMechanism>
				<Name>Auditing</Name>
				<Description>The FPS keeps an audit trail of all service requests.
				Each FPS service request is timestamped with the date and time the request was made.
				Each audit trail record includes user ID, date, time, operation requested, and an
				error description if the operation failed. Access to the audit trail is limited
				to users with system administrator privileges.
				</Description>
			</SecurityMechanism>
		</SecurityMechanisms>
		<Policies>
			<Policy>
				<Title>Flight Plan Service (FPS) Policy Document Version 1</Title>
				<Location>
				https://www.faa.gov/atm/policies/fps-policy.xml
				</Location>
			</Policy>
			<Policy>
				<Title>Runtime Policy</Title>
				<Location>
				http://www.faa.gov/air_traffic/flight_info/operation_policy.pdf
				</Location>
			</Policy>
			<Policy>
				<Title>FAA Order 1370.92A, Password and PIN Management Policy</Title>
				<Location>
				http://www.faa.gov/documentLibrary/media/Order/1370.92A.pdf
				</Location>
			</Policy>
			<Policy>
				<Title>NIST FIPS Publication 200, Minimum Security Requirements
				for Federal Information and Information Systems</Title>
				<Location>
				http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
				</Location>
			</Policy>
		</Policies>
		<QualityOfService>
			<QualityOfServiceParameter>
				<Name>Response Time</Name>
				<Value>3</Value>
				<UnitOfMeasure>Seconds</UnitOfMeasure>
			</QualityOfServiceParameter>
			<QualityOfServiceParameter>
				<Name>Capacity</Name>
				<Value>20 per minute</Value>
				<Definition>Number of service requests that the service can
				accommodate within a given time period.
				</Definition>
				<CalculationMethod>Simple count.
				</CalculationMethod>
				<UnitOfMeasure>Whole positive number, per period of time</UnitOfMeasure>
			</QualityOfServiceParameter>
			<QualityOfServiceParameter>
				<Name>Availability</Name>
				<Value>= 99.900</Value>
				<Definition>Probability that the service is present or ready for immediate use.
				</Definition>
				<CalculationMethod>100 * ((24 – Total Outage Time) / 24).
				Measurements are taken daily and apply to the preceding 24-hour period.
				</CalculationMethod>
				<UnitOfMeasure>Percentage, accurate to 3 decimal places</UnitOfMeasure>
			</QualityOfServiceParameter>
		</QualityOfService>
		<EnvironmentalConstraints>
			<Constraint>
				<Description>The FPS operates within the FAA Telecommunications
				Infrastructure (FTI) and is subject to its performance constraints.
				 All FPS requests and responses are brokered via the NAS Enterprise
				Messaging Service (NEMS).
				</Description>
			</Constraint>
		</EnvironmentalConstraints>
	</Profile>
	<Model/>
	<Grounding/>
</ServiceDescription>

5.4 GetServiceProfile

Description	Allows clients to retrieve profile information about a registered service.
HTTP Method	GET
URI template	/profile?{GRID}, where {GRID} is the global registry ID for the service being requested.
Obligation	Required
Input	None
Output	A representation of Profile object. The Index MUST include an XLink reference to the registry.

This operation can also be invoked when the {GRID}/profile is dereferenced. For example, the following URIs should cause the registry to return the same resource representation:

• http://nsrr.faa.gov/profile?http://nsrr.faa.gov/services/fps/profile
• http://nsrr.faa.gov/services/fps/profile
Example of code:

# Request
GET /services/fps/profile HTTP/1.1
Host: nsrr.faa.gov
Accept: application/xml
Authorization: Basic dXNlcjpwYXNzd29yZA==

# Response HTTP/1.1 200 OK
Content-Type: application/xml;charset=UTF-8

<rim:Profile xmlns:rim="http://swim.aero/rim/1.0.0"
			xmlns:xlink="http://www.w3.org/1999/xlink"
			xlink:title="GRID" xlink:type="locator"
			xlink:href="http://nsrr.faa.gov/services/fps">
    <rim:ServiceName>Flight Plan Service (FPS)</rim:ServiceName>
    <rim:ServiceVersion>1.0.0</rim:ServiceVersion>
    <rim:ServiceDescription>(This fictitious service is for instructional
	use only and cannot be consumed) A service for filing, updating,
	or canceling an IFR (Instrument Flight Rules) flight plan.
	</rim:ServiceDescription>
    <sd:Categories xmlns:sd="http://swim.aero/rim/1.0.0">
        <sd:Category>
            <sd:Title>ATM Service Category</sd:Title>
            <sd:Value>Flight Planning</sd:Value>
        </sd:Category>
        <sd:Category>
            <sd:Title>SWIM Service Product Category</sd:Title>
            <sd:Value>Flight</sd:Value>
        </sd:Category>
        <sd:Category>
            <sd:Title>Lifecycle Status</sd:Title>
            <rim:Value xmlns:rim="http://swim.aero/rim/1.0.0">Development</rim:Value>
        </sd:Category>
    </sd:Categories>
    <rim:Provider>
        <rim:Name>FAA En Route Services Modernization Group (ESMG)</rim:Name>
        <rim:Description>A program within the FAA Air Traffic Organization
		responsible for developing Web services.
	</rim:Description>
        <rim:WebPage>http://www.faa.gov/air_traffic/flight_info</rim:WebPage>
        <rim:PointsOfContact>
            <rim:POC>
                <rim:Name>John  D. Doe</rim:Name>
                <rim:Function>ATO-X ESMG Manager</rim:Function>
                <rim:Phone>(609) 444-5555</rim:Phone>
                <rim:Email>Joe.doe@faa.gov</rim:Email>
            </rim:POC>
        </rim:PointsOfContact>
    </rim:Provider>
    <rim:Functions>
        <rim:Function>
            <rim:Description>File a flight plan.</rim:Description>
            <rim:RealWorldEffect>A flight plan has been filed and persists
			in the FAA Web server for distribution to the FAA flight
			data processing application within some parameter time
			of the estimated departure time.
	</rim:RealWorldEffect>
        </rim:Function>
        <rim:Function>
            <rim:Description>Cancel a flight plan.</rim:Description>
            <rim:RealWorldEffect>A previously filed flight plan has been
			retracted before being submitted to FAA Air Traffic Services,
			thereby reducing the flight plan processing load and systemic
			workload of the FAA air traffic planning system.
	</rim:RealWorldEffect>
        </rim:Function>
        <rim:Function>
            <rim:Description>Change destination aerodrome of a flight plan.</rim:Description>
            <rim:RealWorldEffect>The destination aerodrome of a filed flight
			plan has been changed.
	</rim:RealWorldEffect>
        </rim:Function>
    </rim:Functions>
    <rim:SecurityMechanisms>
        <rim:SecurityMechanism>
            <rim:Name>Authorization</rim:Name>
            <rim:Description>The FPS deploys role-based access control
			(RBAC) for implementing authorization in accordance with
			ANSI/INCITS 359-2004.
			Two roles are defined, “Reader” (a user who only has permission
			to view a filed flight plan) and “Originator”
			(a user, generally a pilot or operator, who submits a flight
			plan and has permission to file and subsequently modify
			or cancel the filed flight plan).
	</rim:Description>
            <rim:RegulatingProtocol>
                <rim:Title></rim:Title>
                <rim:Location>
			http://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/ANSI+INCITS+359-2004.pdf
				</rim:Location>
            </rim:RegulatingProtocol>
        </rim:SecurityMechanism>
        <rim:SecurityMechanism>
            <rim:Name>Integrity</rim:Name>
            <rim:Description>The FPS deploys Transport Layer Security (TLS)
			Version 1.2, RFC 5246; therefore data is checked for
			possible corruption.
	</rim:Description>
            <rim:RegulatingProtocol>
                <rim:Title></rim:Title>
                <rim:Location>
				http://tools.ietf.org/html/rfc5246
				</rim:Location>
            </rim:RegulatingProtocol>
        </rim:SecurityMechanism>
        <rim:SecurityMechanism>
            <rim:Name>Non-Repudiation</rim:Name>
            <rim:Description>The FPS complies with W3C's Recommendation
			for XML Signature Syntax and Processing to ensure that
			each user’s message is digitally signed.
	</rim:Description>
            <rim:RegulatingProtocol>
                <rim:Title></rim:Title>
                <rim:Location>http://www.w3.org/TR/xmldsig-core</rim:Location>
            </rim:RegulatingProtocol>
        </rim:SecurityMechanism>
        <rim:SecurityMechanism>
            <rim:Name>Authentication</rim:Name>
            <rim:Description>The FPS requires each service consumer
			to authenticate itself to the FPS at the transport level
			by deploying a Username/Token credential in accordance
			with the Web Services Security UsernameToken Profile 1.0,
			OASIS Standard 200401.
	</rim:Description>
            <rim:RegulatingProtocol>
                <rim:Title></rim:Title>
                <rim:Location>
			ttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
				</rim:Location>
            </rim:RegulatingProtocol>
        </rim:SecurityMechanism>
        <rim:SecurityMechanism>
            <rim:Name>Auditing</rim:Name>
            <rim:Description>The FPS keeps an audit trail of all service requests.
			Each FPS service request is timestamped with the date and time the
			request was made. Each audit trail record includes user ID, date, time,
			operation requested, and an error description if the operation failed.
			Access to the audit trail is limited to users with system
			administrator privileges.
	</rim:Description>
        </rim:SecurityMechanism>
    </rim:SecurityMechanisms>
    <rim:Policies>
        <rim:Policy>
            <rim:Title>Flight Plan Service (FPS) Policy Document Version 1</rim:Title>
            <rim:Location>https://www.faa.gov/atm/policies/fps-policy.xml</rim:Location>
        </rim:Policy>
        <rim:Policy>
            <rim:Title>Runtime Policy</rim:Title>
            <rim:Location>
			http://www.faa.gov/air_traffic/flight_info/operation_policy.pdf
			</rim:Location>
        </rim:Policy>
        <rim:Policy>
            <rim:Title>FAA Order 1370.92A, Password and PIN Management Policy</rim:Title>
            <rim:Location>
			http://www.faa.gov/documentLibrary/media/Order/1370.92A.pdf
			</rim:Location>
        </rim:Policy>
        <rim:Policy>
            <rim:Title>NIST FIPS Publication 200, Minimum Security Requirements
			for Federal Information and Information Systems</rim:Title>
            <rim:Location>
			http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf
			</rim:Location>
        </rim:Policy>
    </rim:Policies>
    <rim:QualityOfService>
        <rim:QualityOfServiceParameter>
            <rim:Name>Response Time</rim:Name>
            <rim:Value>3</rim:Value>
            <rim:UnitOfMeasure>Seconds</rim:UnitOfMeasure>
        </rim:QualityOfServiceParameter>
        <rim:QualityOfServiceParameter>
            <rim:Name>Capacity</rim:Name>
            <rim:Value>20 per minute</rim:Value>
            <rim:Definition>Number of service requests that the service can
			accommodate within a given time period.
		</rim:Definition>
            <rim:CalculationMethod>Simple count.
		</rim:CalculationMethod>
            <rim:UnitOfMeasure>Whole positive number, per period of time</rim:UnitOfMeasure>
        </rim:QualityOfServiceParameter>
        <rim:QualityOfServiceParameter>
            <rim:Name>Availability</rim:Name>
            <rim:Value>= 99.900</rim:Value>
            <rim:Definition>
			Probability that the service is present or ready for immediate use.
			</rim:Definition>
            <rim:CalculationMethod>100 * ((24 – Total Outage Time) / 24).
			Measurements are taken daily and apply to the preceding 24-hour period.
			</rim:CalculationMethod>
            <rim:UnitOfMeasure>Percentage, accurate to 3 decimal places</rim:UnitOfMeasure>
        </rim:QualityOfServiceParameter>
    </rim:QualityOfService>
    <rim:EnvironmentalConstraints>
        <rim:Constraint>
            <rim:Description>The FPS operates within the FAA Telecommunications
			Infrastructure (FTI) and is subject to its performance constraints.
			 All FPS requests and responses are brokered via the NAS Enterprise
			Messaging Service (NEMS).
			</rim:Description>
        </rim:Constraint>
    </rim:EnvironmentalConstraints>
</rim:Profile>




6 Security

A registry should establish a single set of user identities across the RIM and its Web-based interface, and enforce the same authentication and access control policies across all interfaces. It is strongly recommended that the RIM require authentication and employ access control mechanisms when a client invokes an operation that will modify the content of the registry.

When security is required, the registry will be expected to use an authentication method that is compatible with the HTTP protocol, such as HTTP basic or digest authentication [HTTP-Auth], or a token-based based authentication mechanism such as the OAuth 2.0 Authorization Framework [OAuth].

An authentication token MUST be included in the HTTP Authorization header. If no HTTP Authorization header is included in the request, the RIM SHALL respond with HTTP response code 401 “Unauthorized”. If the client is authenticated but not allowed to access the resource requested, the RIM MAY respond with the HTTP response code 403 “Forbidden”.





Appendixes

Appendix A Web Application Description Language (WADL) Definition

<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://wadl.dev.java.net/2009/02 https://www.w3.org/Submission/wadl/wadl.xsd"
	xmlns:tns="http://swim.aero/rim/1.0.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:rim="http://swim.aero/rim/1.0.0" xmlns="http://wadl.dev.java.net/2009/02">
	<doc xml:lang="en">
		Registry Interchange Module (RIM) 1.0.0
	</doc>
	<grammars>
		<!-- RIM Schema -->
		<include href="http://swim.aero/rim/1.0.0/rim-1.0.0.xsd" />
	</grammars>

	<resource_type id="Registry">
		<method name="GET" id="GetRegistry">
			<doc>Returns basic information about the Registry</doc>
			<request />
			<response status="200">
				<representation mediaType="application/xml" element="rim:Registry" />
			</response>
			<response status="406">
				<doc>Not acceptable: if the client has requested a media
					type that is not supported.
				</doc>
			</response>
		</method>
	</resource_type>
	<resource_type id="Index">
		<method name="GET" id="GetIndex">
			<doc>Returns an index of registered entities within the Registry
			</doc>
			<request>
				<doc>The request may include optional parameters to filter the
					result based on common taxonomies
				</doc>
				<param name="interface_type" style="query" type="xsd:NCName"
					repeating="true" required="false">
					<doc>Example: request only resource oriented OR message oriented services
						/index?interface_type=resource_oriented,message_oriented
					</doc>
				</param>
				<param name="availability_status" style="query" type="xsd:NCName"
					repeating="true" required="false" />
				<param name="service_product" style="query" type="xsd:NCName"
					repeating="true" required="false" />
			</request>
			<response status="200">
				<representation mediaType="application/xml" element="rim:Registry" />
			</response>
			<response status="406">
				<doc>Not acceptable: if the client has requested a media
					type that is not supported.
				</doc>
			</response>
		</method>
	</resource_type>
	<resource_type id="ServiceDescription">
		<method name="GET" id="GetServiceDescription">
			<doc>Returns the representation of a Service Description</doc>
			<request />
			<response status="200">
				<representation mediaType="application/xml" element="rim:ServiceDescription" />
			</response>
			<response status="404">
				<doc>Not found: if the client has requested a service that does not
					exist.
				</doc>
			</response>
			<response status="406">
				<doc>Not acceptable: if the client has requested a media
					type that is not supported.
				</doc>
			</response>
		</method>
	</resource_type>
	<resource_type id="ServiceProfile">
		<method name="GET" id="GetServiceProfile">
			<doc>Returns the representation of a Service Profile</doc>
			<request />
			<response status="200">
				<representation mediaType="application/xml" element="rim:Profile" />
			</response>
			<response status="404">
				<doc>Not found: if the client has requested a service that does not
					exist.
				</doc>
			</response>
			<response status="406">
				<doc>Not acceptable: if the client has requested a media
					type that is not supported.
				</doc>
			</response>
		</method>
	</resource_type>
</application>

Appendix B Web Service Description Language (WSDL) Definition

<wsdl:description xmlns:wsdl="http://www.w3.org/ns/wsdl"
	targetNamespace="http://swim.aero/rim/1.0.0"
	xmlns:rim="http://swim.aero/rim/1.0.0"
	xmlns:whttp="http://www.w3.org/ns/wsdl/http"
	xmlns:wsdlx="http://www.w3.org/ns/wsdl-extensions"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<wsdl:documentation>Registry Integration Module (RIM) 1.0.0</wsdl:documentation>
	<wsdl:types>
		<xs:import namespace="http://swim.aero/rim/1.0.0"
			schemaLocation="http://swim.aero/rim/1.0.0/rim-1.0.0.xsd" />
		<xs:schema targetNamespace="http://swim.aero/rim/1.0.0"
			xmlns:rim="http://swim.aero/rim/1.0.0"
			xmlns:xs="http://www.w3.org/2001/XMLSchema">
			  <xs:complexType name="QueryParameters">
			  <!-- optional query parameters -->
			    <xs:sequence>
			      <xs:element name="interface_type" type="xs:NCName"
					minOccurs="0" maxOccurs="unbounded"/>
			      <xs:element name="availability_status" type="xs:NCName"
					minOccurs="0" maxOccurs="unbounded"/>
			      <xs:element name="service_product" type="xs:NCName"
					minOccurs="0" maxOccurs="unbounded"/>
			    </xs:sequence>
			  </xs:complexType>
			  <xs:element name="queryParameters" type="rim:QueryParameters"/>
			  <xs:element name="GRID" type="xs:anyURI"/>
			  	<!-- An HTTP URL assigned by the registry to the Service Description -->
			  <xs:element name="lid" type="xs:NCName">
			  	<!-- the local part of GRID -->
			  </xs:element>
		</xs:schema>
	</wsdl:types>

	<wsdl:interface name="RIM">
		<wsdl:operation name="GetRegistry" pattern="http://www.w3.org/ns/wsdl/in-out"
			style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true">
			<wsdl:documentation>
				This operation returns a description of the registery.
			</wsdl:documentation>
			<wsdl:input/>
			<wsdl:output element="rim:Registry" />
		</wsdl:operation>
		<wsdl:operation name="GetIndex" pattern="http://www.w3.org/ns/wsdl/in-out"
			style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true">
			<wsdl:documentation>
				This operation returns a list of registered entities.
			</wsdl:documentation>
			<wsdl:input element="rim:queryParameters"/>
			<wsdl:output element="rim:Index" />
		</wsdl:operation>
		<wsdl:operation name="GetServiceDescription" pattern="http://www.w3.org/ns/wsdl/in-out"
			style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true">
			<wsdl:documentation>
				This operation returns a representation of service description
			</wsdl:documentation>
			<wsdl:input element="rim:GRID"/>
			<wsdl:output element="rim:ServiceDescription" />
		</wsdl:operation>
		<wsdl:operation name="GetServiceProfile"
			pattern="http://www.w3.org/ns/wsdl/in-out"
			style="http://www.w3.org/ns/wsdl/style/iri" wsdlx:safe="true">
			<wsdl:documentation>
				This operation returns a representation of service profile
			</wsdl:documentation>
			<wsdl:input element="rim:GRID"/>
			<wsdl:output element="rim:Profile" />
		</wsdl:operation>
	</wsdl:interface>

	<wsdl:binding name="RIM_REST"
		type="http://www.w3.org/ns/wsdl/http"
		interface="rim:RIM">
		<wsdl:documentation>
			The RESTful HTTP binding for RIM.
		</wsdl:documentation>
		<wsdl:operation ref="GetIndex"
			whttp:location="/index/"
			whttp:method="GET"
			whttp:outputSerialization="text/xml" />
		<wsdl:operation ref="GetRegistry"
			whttp:location="/registry/"
			whttp:method="GET"
			whttp:outputSerialization="text/xml" />
		<wsdl:operation ref="GetServiceDescription"
			whttp:location="/service-description?{GRID}"
			whttp:method="GET"
			whttp:outputSerialization="text/xml" />
		<wsdl:operation ref="GetServiceProfile"
			whttp:location="/profile?{GRID}"
			whttp:method="GET"
			whttp:outputSerialization="text/xml" />
	</wsdl:binding>
</wsdl:description>