![OSLC_logo.png](../../../../../pub/Main/OslcCoreSpecification/OSLC_logo.png) |
Open Services for Lifecycle Collaboration Reconciliation Specification Version 2.0
|
Status: 2.0 Draft Specification - 22 June 2012
NOTE: This version of the specification has version 2.0 to indicate that it is an OSLC Core 2.0 compliant specification. This specification is the initial version of an OSLC Reconciliation specification.
This Version
Latest Version
Authors
Contributors
Table of Contents
Contents
License
![Creative Commons Attribution license](../../../../../../licensebuttons.net/l/by/3.0/us/88x31.png)
This work is licensed under a Creative Commons Attribution License.
Notation and Conventions
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC2119. Domain name examples use RFC2606.
Introduction
(this section is informative)
This specification builds on the OSLC Core Specification to define the resources and operations supported by Open Services for Lifecycle Collaboration (OSLC) providers who have a need to reconcile resource instance information with other providers.
Reconciliation resources define records such that disparate tools can identify and reconcile their data. Reconciliation resources represent individual resources as well as their relationships to other resources and to other linked resources outside of the Reconcilation Workgroup. The goal of this effort is to define the resources, constraints and methods useful for answering this category of questions, so that multiple tools can have a common understanding of their data when they integrate. The capabilities of the interface definitions are driven by key integration scenarios and therefore don’t represent a complete setup of operations on resources or resource types. The resource formats and operations may not match exactly the native models supported by existing implementations but are intended to be compatible with them.
Reconciliation, as referenced in this specification, refers to the case where there exists a need to combine (that is, reconcile) the perspectives from multiple observations on the same resource instance. See the Reconciliation Scenarios page for several specific examples.
Importance of Identity
(this section is informative)
Whenever there is a situation where one product is communicating with another product about a resource instance, it is important to the user using both products to understand how to identify the resource as the “same thing” across multiple systems. For example, if a user launches in context to another product, without proper identity information the user does not know if the context view is correct for the resource.
Identity allows users to know they have visibility and control on the correct “thing” when there are multiple products in use to perform those operations.
How we propose solving this is through a solution that can receive resource information from each of the products, process this information, and then make a determination as to which resource data should combine together and create a reconciled representation of the resources across the various products. What this specification defines is the set of properties that are not only common across multiple products, but also how these properties create a way to uniquely identify a resource instance when the properties are combined as a set.
Terminology
Service Provider - an implementation of the OSLC Reconciliation specification as a server. OSLC Reconciliation domain clients consume these services.
Base Requirements
Compliance
This specification is based on OSLC Core Specification. OSLC Reconciliation Workgroup consumers and service providers MUST be compliant with both the core specification and this Reconciliation Workgroup specification, and SHOULD follow all the guidelines and recommendations in both these specifications.
The following table summarizes the requirements from OSLC Core Specification as well as some (but not all) additional requirements specific to Reconciliation. See the full content of the Reconcilation specification and Common Resource Type Vocabulary for all requirements.
Note that this specification further restricts some of the requirements for OSLC Core Specification as noted in the Origin column of the compliance table. See further sections in this specification or the OSLC Core Specification to get further details on each of these requirements.
Any consumer or service provider behaviors are allowed unless explicitly prohibited by this or dependent specifications; conditional permissive requirements, especially those qualified with MAY, are implicitly covered by the preceding clause. While technically redundant in light of that broad permission, OSLC specifications do still make explicit MAY-qualified statements in cases where the editors believe doing so is likely to add clarity.
Requirements on OSLC Consumers
Requirement |
Level |
Origin(s) |
Meaning |
Unknown properties and content |
MUST |
Core |
OSLC clients MUST preserve unknown content |
Requirements on OSLC Service Providers
Requirement |
Level |
Origin(s) |
Meaning |
Unknown properties and content |
MAY |
Core |
OSLC service providers MAY ignore unknown content |
Resource Operations |
MUST |
Core |
OSLC service providers MUST support resource operations via standard HTTP operations |
Resource Paging |
MAY |
Core |
OSLC services MAY provide paging for resources |
Partial Resource Representations |
MUST |
Core |
OSLC service providers MUST support HTTP GET requests for retrieval of a subset of a resource’s properties via the oslc.properties URL parameter |
Partial Resource Representations |
MAY |
Core |
OSLC service providers MAY support HTTP PUT requests for updating a subset of a resource’s properties via the oslc.properties URL parameter |
Service Provider Resources |
MAY |
Core |
OSLC service providers MAY provide a Service Provider Catalog resource |
Service Provider Resources |
MUST |
Core |
OSLC service providers MUST provide a Service Provider resource |
Creation Factories |
MAY |
Core |
OSLC service providers MAY provide creation factories to enable resource creation via HTTP POST |
Query Capabilities |
SHOULD1 |
Reconciliation, Core |
OSLC service providers SHOULD provide query capabilities to enable clients to query for resources |
Query Syntax |
MUST2 |
Reconciliation, Core |
If a service provider supports a OSLC query capabilities, the query capabilities MUST support the OSLC Core Query Syntax |
Query Syntax |
MAY |
Core |
OSLC query capabilities MAY support other query syntax |
Delegated UI Dialogs |
SHOULD |
Core |
OSLC service providers SHOULD allow clients to discover, via their service provider resources, any Delegated UI Dialogs they offer. |
Delegated UI Dialogs |
SHOULD |
Core |
OSLC service providers SHOULD offer delegated UI dialogs for resource creation |
Delegated UI Dialogs |
SHOULD |
Core |
OSLC service providers SHOULD offer delegated UI dialogs for resource selection |
UI Preview |
SHOULD |
Core |
OSLC Services SHOULD offer UI previews for resources that may be referenced by other resources WG question Is this applicable to this workgroup ? |
HTTP Basic Authentication |
MAY |
Core |
OSLC Services MAY support Basic Auth |
HTTP Basic Authentication |
SHOULD |
Core |
OSLC Services SHOULD support Basic Auth only over HTTPS |
OAuth Authentication |
MAY |
Core |
OSLC service providers MAY support OAuth |
OAuth Authentication |
SHOULD |
Core |
OSLC service providers that support OAuth SHOULD allow clients to discover the required OAuth URLs via their service provider resource |
Error Responses |
MAY |
Core |
OSLC service providers MAY provide error responses using Core-defined error formats |
- 1The OSLC Core Specification indicates service providers MAY provide Query Capabilities. This specification strengthens the requirement.
- 2The OSLC Core Specification indicates service providers MAY support the OSLC Query Syntax. This specification makes OSLC Query Syntax support a MUST requirement for service providers providing query capabilities.
Specification Versioning
See OSLC Core Specification Versioning section.
Namespaces
In addition to the namespace URIs and namespace prefixes defined in the OSLC Core specification, OSLC Reconciliation Workgroup defines 2 namespaces
http://open-services.net/ns/recon#
with a namespace prefix of
oslc_recon
. This namespace URI and prefix are used to designate the
resources defined in this specification and their properties.
http://open-services.net/ns/crtv#
with a namespace prefix of
oslc_crtv
. This namespace URI and prefix are used to designate the
resources defined by the Common Resource Type vocabulary.
Service Providers that wish to use the specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. In addition to the requirements for OSLC Defined Resource Representations, Refer to the Domain-specific statements regarding Resource Format requirements.
Authentication
See OSLC Core Authentication section. This specification puts no additional constraints on authentication.
Error Responses
See OSLC Core Error Responses section. This specification puts no additional constraints on error responses.
The Reconciliation Workgroup does not specify a Service Provider Resource. Service Providers that wish to use the specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. Refer to the Domain-specific statements regarding pagination of query results.
Labels for Relationships
Relationships to other resources are represented as properties whose values are the URI of the object or target resource. When an relationship property is to be presented in a user interface, it may be helpful to provide an informative and useful textual label for that relationship instance. (This in addition to the relationship property URI and the object resource URI, which are also candidates for presentation to a user.) OSLC Core Links Guidance allows OSLC providers to support a dcterms:title
link property in resource representations, using the anchor approach (reification), but this specification discourages its use (providers SHOULD NOT use it, and consumers SHOULD NOT depend on it). At the time this specification was written, the W3C RDF working group was on a path to remove reification from the next version of RDF, and it was noted that reification never was normatively defined even in the RDF/XML syntax Recommendation where it occurs informatively.
Resource Definitions
The Reconciliation Workgroup resource properties are not limited to the ones defined in this specification; service providers may provide additional properties. It is recommended that any additional properties exist in their own unique namespace and not use the namespaces defined in this specification.
A list of properties is defined for each type of resource. Most of these properties are identified in OSLC Core Appendix A: Common Properties. Any exceptions are noted. Relationship properties refer to other resources. These resources may be in any OSLC domain (including Reconciliation Workgroup).
The diagram below shows the relationships between Reconciliation Workgroup Resources and Resources from other Domains.
Question to WG: do we need to draft a diagram showing this association ?
For all resource types defined in this specification, all required properties (those defined with an occurrence of exactly-one or one-or-many) MUST exist for each resource and must be provided when requested. All other properties are optional, and might not exist on some or any resources; those that do not exist will not be present in the returned representation even if requested, while those that do exist MUST be provided if requested. Providers MAY define additional provider-specific properties; providers SHOULD use their own namespaces for such properties, or use standard Dublin Core or RDF namespaces and properties where appropriate.
If no specific set of properties is requested, all properties are returned - both those defined in this specification as well as any provider-specific ones. See Selective Property Values in OSLC Core Specification.
Consumers of should note that some resources may have a very large number of related resources, and that some resources may be very large and/or expensive to compute. For this reason, consumers are strongly encouraged to use the oslc.properties
parameter to limit the properties returned from a request to the subset required. See Selective Property Values in OSLC Core Specification.
Resource: ComputerSystem
- Name:
ComputerSystem
- Description: An intelligent device, such as a computer, that can perform computing, data collection, and/or communication operations. This category includes general purpose computers, such as laptops, servers, and virtual machines; computers with specific functions, such as Networking and Storage hardware, Voice over IP Telephony devices, HVAC systems; monitoring data collection devices in buildings, automobiles, or electronic grids.
- Type URI
http://open-services.net/ns/crtv#ComputerSystem
ComputerSystem Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:manufacturer |
zero-or-one |
False |
String |
n/a |
n/a |
Name of the device manufacturer. This attribute SHOULD be a publicly available manufacturer name vocabulary. This attribute must be set using one of a predefined set of manufacturer names. ( See below for more specific rules regarding Windows and Intel Linux systems ) Providers must normalize the manufacturer name. If the manufacturer name cannot be mapped to a value in a list, apply the following transformations to the value before setting this attribute: do not use punctuation if the company name is an acronym; do not use the model type or any characteristics other than the commonly understood name of a manufacturer; and do not use terms such as: LLC, Inc., Corporation, Incorporated, GmbH, AG, SRL, Ltd., sp. z o.o., or sarl. Do not include leading or trailing spaces. On Windows systems, use the raw output from WMI Win32_ComputerSystemProduct (attribute Vendor). If you do not have access to WMI, use the list of manufacturers from CRTV. On Linux Intel machines, use the raw output from dmidecode (value of Manufacturer: field). If you do not have access to dmidecode, use the list of manufacturers from CRTV. For Windows and Linux Intel machines that are running VMware virtual machines, use string “VMware” as the manufacturer value. |
crtv:model |
zero-or-one |
False |
String |
n/a |
n/a |
Value of the device model. The model number as provided by the device manufacturer. For system z machines, use the 4-digit “Machine type” value with no embedded special characters or blanks. Do not use the “Model ID” value as this can change when a hardware component is replaced. In all cases, the model number must be normalized according to the following rules: use the string provided by the system and apply the following: if the string returned by the system command contains [], extract the value within [];remove all non-alphanumeric characters including spaces;convert remaining characters to upper case. An example valid model value is “7978K8G” from a Windows machine via a call to Windows WMI class Win32_ComputerSystemProduct (Name) Example: the output from the system call is “IBM,9133-55A”, apply transformation rules and populate model with value “913355A”. Example: the output from the system call is “IBM eServer 325 -[88355EX]-“, apply the transformation rules and populate model with “88355EX”. |
crtv:serialNumber |
zero-or-one |
False |
String |
n/a |
n/a |
Serial number assigned by the manufacturer. The value should be provided by the manufacturer of the resource. The value must be as it is provided by the manufacturer of the resource, with the following transformations applied: remove everything before a comma ( for example, when the value is “…IBM,123456…”); remove string “VMware-” ( this is to handle cases where the serial number is automatically generated for virtual machines, e.g. “…VMware-123456…”; remove all non-alphanumeric characters including blanks; convert the remaining characters to upper case. An example valid serialNumber value is “KDFDXTT” from a Windows machine via a call to Win32_ComputerSystemProduct(IdentifyingNumber). Example: the output from the system call is “VMware-56 4d c6 9e d1 37 ff 34-a6 72 b0 ae d2 62 c5 64”. Apply the transformation rules and populate serialNumber with “564DC69ED137FF34A672B0AED262C564”. For AIX machines, if you are using the Object Data Manager to retrieve the serial number then you MUST apply the following transformation : remove all characters before the first comma, the comma itself and the first character after the comma. This is so that the value will match the output of the lsconf command which returns the true serial number of the machine. Example: odm returns “IBM,0310DD5AG”. Apply the transformation rules and populate serialNumber with “10DD5AG” |
crtv:systemBoardUUID |
zero-or-one |
False |
String |
n/a |
n/a |
The unique identifier of the system board. Provide the SystemBoardUUID in human-readable string format, in the form 8-4-4-4-12, where there are 8 hexadecimal values separated by a hyphen, followed by 4 hexadecimal values separated by a hyphen, and so forth; the hexadecimal values from ‘a’ to ‘f’ are to be given as lower-case characters; do not include the manufacturer, model or serial number of the machine in this attribute. Do not include leading or trailing spaces. An example valid systemBoardUUID is “62f05081-40d1-b238-98fd-d418846eaebe” from a Windows machine via a call to WMI class Win32_ComputerSystemProduct (UUID attribute). If the machine type you are working with has a designated system board UUID that has the correct number of digits (32) but does not have the ‘-’ characters, transform the UUID string to the 8-4-4-4-12 format. For example, VMware returns “56 4d c6 9e d1 37 ff 34-a6 72 b0 ae d2 62 c5 64”. Populate systemBoardUUID with “564dc69e-d137-ff34-a672-b0aed262c564”. If the machine type you are working with has a designated system board UUID that does not have the correct number of hexadecimal characters then use the raw output from the system command. For example, the AIX unamex() command returns “36e2374d20f2e00”. Populate systemBoardUUID as “36e2374d20f2e00” |
crtv:vmid |
zero-or-one |
False |
String |
n/a |
n/a |
The VMID is a unique identifier for the virtual machine. When setting the vmid property : remove leading and trailing blanks. Otherwise leave the string value as-is. Non alphanumeric characters are valid. Case is significant as well since some manufacturers differentiate between upper and lower case. An example valid vmid is “5” from an AIX machine via command uname -L |
crtv:hostid |
zero-or-one |
False |
String |
n/a |
n/a |
A globally unique ID assigned to their machines by some manufacturers (.e.g Sun Solaris). The hostid MUST be normalized according to the following rules: remove leading and trailing blanks;remove non-alphanumeric characters;convert all remaining characters to upper case. An example valid hostd is “84FB046F” from a Solaris machine via command hostid |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
any |
The qualifier to describe the kind of ComputerSystem as well as the functions provided by the ComputerSystem. A system may provide more than one function at the same time. |
Additional requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:hostid, crtv:vmid
- crtv_hostid
- crtv:manufacturer, crtv:model,crtv:serialNumber, crtv:vmid
- crtv:manufacturer, crtv:model,crtv:serialNumber
- crtv:systemBoardUUID
If you are unable to obtain a valid value for any of these bulleted properties, do NOT substitute an informational
value such as “Unknown” or “Not Available” ; instead, do not populate the property at all.
Resource: Database
- Name:
Database
- Description: An organized collection of digital data that is managed by a database management system (DBMS). (A Database Management System, in turn, is represented as a SoftwareServer)
- Type URI
http://open-services.net/ns/crtv#Database
Database Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:name |
zero-or-one |
False |
String |
n/a |
n/a |
The name assigned to the database by the DBA. For DB2 and Oracle, use the database name. |
crtv:dbInstance |
zero-or-many |
False |
Resource |
Reference |
any |
The SoftwareServer representing the database instance that manages this database. |
Additional requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- name, (set of) dbInstance
Resource: IPAddress
- Name:
IPAddress
- Description: Represents an IP address, either IPv4-based or IPv6-based.
- Type URI
http://open-services.net/ns/crtv#IPAddress
IPAddress Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:address |
zero-or-one |
False |
String |
n/a |
n/a |
The canonical string representation of the IP address. The expected form for IPv6 Address instances is x:x:x:x:x:x:x:x, where: x represents one to four hexadecimal digits of the eight 16-bit pieces of the address. Any hexadecimal letters are in lower case. Do not write the leading zeros in a individual field. There must be at least one numeral in every field. The expected form for IPv4 Address instances is y.y.y.y, where: y represents an integer ranging from “0” to “255”. When the address is an Ipv4-mapped address ( e.g. ::ffff:10.43.1.101) or a tunnelling address (e.g. fe80::5efe:10.43.1.101) then populate the property with the Ipv4 portion of the address in dotted decimal format. |
crtv:contextAddressSpace |
zero-or-one |
False |
Resource |
Reference |
any |
For each IP Address inside NAT, Anchor Prefix and Anchor IP form the Address Space.This attribute is required if the IPv4 Address is within the set of IANA privately defined address ranges of: 10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255 |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- address, contextAddressSpace
When you are representing a public IP address, populate the contextAddressSpace property with the crtv URI representing null [http://open-services.net/ns/crtv#NULL]
Resource: Path
- Name:
Path
- Description:
Path represents individual components of a directed graph of resources, where specific ordering is necessary to preserve a graph. Examples of such directed graphs are the representation of workflows or processes.
- Type URI
http://open-services.net/ns/crtv#Path
Path Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:elementFrom |
exactly-one |
False |
Resource |
Reference |
any |
The resource acting as the origination point in the ordered path. |
crtv:elementTo |
exactly-one |
False |
Resource |
Reference |
any |
The resource acting as the destination point in the ordered path. |
crtv:occursBefore |
zero-or-one |
False |
Resource |
Reference |
any |
If there is a temporal order between other Path or ServiceInstance Resource Definitions, the Resource Definition action that occur after this Resource Instance are listed here. |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:elementFrom, crtv:elementTo, crtv:occursBefore
If the occursBefore property is not applicable, populate crtv:occursBefore with the crtv URI representing null
Resource: ServiceInstance
- Name:
ServiceInstance
- Description: A Service Instance is the representation of a service offering that was selected by the customer and then instantiated for that specific customer. Service Instances are supported by definite and measurable warranties or guarantees that the expected level of service/value will be met. Instances of the resource carry exposure from the group that is responsible for supporting the offering externally to the group that is utilizing the offering. It is common to group or nest instances together to form a service instance hierarchy.
This resource definition does not represent the individual processes and/or activities that comprise an overall service except in the case where such processes are viewed as an independent service. In this condition, an instance of ServiceInstance would be created to represent the ServiceInstance of the process, then creating a hierarchy of ServiceInstances (to the containing ServiceInstance).
* Type URI http://open-services.net/ns/crtv#ServiceInstance
ServiceInstance Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:name |
exactly-one |
False |
String |
n/a |
n/a |
Name of the entity as it is known to the organization. The contents of this attribute are assumed to be unique within the context of the organization. |
crtv:parentServiceInstance |
zero-or-one |
unspecified |
Resource |
Reference |
any |
When context is required, this is the containing Application for the set of Transactions. |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
any |
The type of service being delivered. |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:parentServiceInstance, crtv:name
If the ServiceInstance does not have an applicable parentServiceInstance, populate the parentServiceInstance property with the crtv URI representing null
Resource: ServerAccessPoint
- Name:
ServerAccessPoint
- Description: A network endpoint, i.e. the combination of IP address and port number that clients connect to when accessing a SoftwareServer.
- Type URI
http://open-services.net/ns/crtv#ServerAccessPoint
ServerAccessPoint Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:ipAddress |
zero-or-one |
False |
Resource |
Reference |
any |
The specific IPAddress resource which the ServerAccessPoint uses. |
crtv:portNumber |
zero-or-one |
False |
String |
n/a |
n/a |
the port number as defined by IETF and IANA |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:portNumber , crtv:ipAddress
Resource: SoftwareServer
- Name:
SoftwareServer
- Description: Represents an instance of software that participates in hosting a particular application.
- Type URI
http://open-services.net/ns/crtv#SoftwareServer
SoftwareServer Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:name |
zero-or-one |
False |
String |
n/a |
n/a |
An Application Server-specific set of values that uniquely identify the Software Server. Depending on its rdf:type, a SoftwareServer may have accompanying rules for constructing the value of this property. For MQ, use the queue manager name. For databases, use the db instance name. For WebSphere, use the concatenation of Cell Name, NodeName and AppServer name (e.g. “CELL0:NODE0:appserver 1”) using “:” as the delimiter. For HTTP servers, use the web server name |
crtv:serverAccessPoint |
zero-or-many |
False |
Resource |
Reference |
any |
The Server Access Point clients use for communications with this resource. |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
any |
The qualifier to describe the kind of (or function of) this software. A SoftwareServer may have more than one function at the same time. Value must be a URI. |
crtv:instancePath |
zero-or-one |
False |
String |
n/a |
n/a |
The directory where the files for this SoftwareServer are stored. For MQ and databases, use the file directory path for the instance. For WebSphere, use the file directory path to the profile. |
crtv:runsOn |
zero-or-one |
False |
Resource |
Reference |
any |
The ComputerSystem this SoftwareServer instance is running on. |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:name, crtv:instancePath, crtv:runsOn
- crtv:name, (set of) crtv:serverAccessPoint
- crtv:name, crtv:runsOn
Resource: SoftwareModule
- Name:
SoftwareModule
- Description:
Represents packaged components that are deployed to a SoftwareModule.
- Type URI
http://open-services.net/ns/crtv#SoftwareModule
SoftwareModule Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:deployedTo |
zero-or-one |
False |
Resource |
Reference |
any |
The SoftwareServer on which this SoftwareModule is deployed. |
crtv:fileName |
zero-or-one |
False |
String |
n/a |
n/a |
The file name of the package containing the SoftwareModule. You should use the syntax specified in RFC 1630 and 1738, for example [file:///inst1.config] . For MQ, use the MQ queue name. For Websphere, use the application module name |
crtv:name |
zero-or-one |
False |
String |
n/a |
n/a |
The name of the SoftwareModule. For MQ, use the MQ queue name. For WebSphere, use the app name. |
rdf:type |
zero-or-many |
unspecified |
Resource |
Reference |
any |
The qualifier to describe the kind of (or function of) this software module. A SoftwareModule may have more than one function at the same time. |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
- crtv:deployedTo, crtv:name, crtv:fileName
Resource: StorageVolume
- Name:
StorageVolume
- Description:
StorageVolume represents an identifiable unit of data storage. A StorageVolume can be a physical device ( e.g. a removable hard drive ) or a logical unit created by combining one or more other storage volumes.
- Type URI
http://open-services.net/ns/crtv#StorageVolume
StorageVolume Properties
Prefixed Name |
Occurs |
Read-only |
Value-type |
Representation |
Range |
Description |
OSLC Reconciliation: Start of additional properties |
|
|
|
|
|
|
crtv:name |
zero-or-one |
False |
String |
n/a |
n/a |
The unique name for the storage extent | |
crtv:path |
exactly-one |
False |
String |
n/a |
n/a |
the absolute volume UUID. The absolute volume UUID in human-readable string format, in the form 8-4-4-4-12 where there are 8 hexadecimal values separted by a hyphen, followed by 4 hexadecimal values and so forth. The hexadecimal values from ‘a’ to ‘f’ must be in lower case. |
Additional Requirements
Note: you MUST satisfy these requirements if you want your resource instance to be reconciled with instances from other service providers.
Valid instances of the Resource Definition MUST contain at least 1 set of properties in the bulleted list below. All properties within a single bullet point (row) must contain a value in order to be valid. Multiple bullets may be satisfied.
Reconciliation Service Provider Capabilities
Service Discovery and Description
Resource Shapes
Reconciliation service providers MAY support Resource Shapes as defined in OSLC Core Specification Appendix A
Service Provider Resource
The Reconciliation Workgroup does not specify a Service Provider Resource. Service Providers that wish to use the specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. Refer to the Domain-specific statements regarding the Service Provider Resource requirements.
Creation Factories
The Reconciliation Workgroup does not specify support statements regarding Creation Factories. Service Providers that wish to use the Reconciliation Workgroup specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. Refer to the Domain-specific statements regarding Creation Factory requirements.
Query Capabilities
The Reconciliation Workgroup does not specify support statements regarding Query Capabilities of resources as defined by Query Capabilities in OSLC Core. Service Providers that wish to use the Reconciliation Workgroup specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. Refer to the Domain-specific statements regarding Query Capability requirements.
Delegated UIs
The Reconciliation Workgroup does not specify support statements regarding the selection and creation of resources as defined by Delegated UIs in OSLC Core. Service Providers that wish to use the Reconciliation Workgroup specifications for ensuring reconciliation use the contents of the Reconciliation Workgroup specification within the context of another OSLC Domain. Refer to the Domain-specific statements regarding the selection and creation of resources when communicating about resource definitions within the contenxt of a specific Domain.
Service Provider HTTP Method Support
The Reconciliation Workgroup does not specify support statements regarding HTTP method support for resource definitions. Refer to the Domain-specific statements when communicating about resource definitions within the contenxt of a specific Domain.
Appendix A: Samples
(this section is informative)
See OSLC Reconciliation Version 2.0 Appendix A: Samples
Appendix B: Resource Shapes
(this section is informative)
See OSLC Reconciliation Version 2.0 Appendix B: Resource Shapes
Appendix C: Notices and References
Contributors
Reporting Issues on the Specification
The working group participants who author and maintain this working draft specification, monitor a distribution list where issues or questions can be raised, see Reconciliation Workgroup Mailing List
Also the issues found with this specification and their resolution can be found at OSLC Reconciliation Version 2.0 Issues.
Intellectual Property Covenant
The members of the Working Group (or as appropriate, their employers) have documented a Patent Non-Assertion Covenant and/or Patent License for implementations of the Reconciliation Workgroup 2.0 Specification, as described in the open-services.net Terms of Use.
References