OSLC implementation in Maximo Asset Management

OSLC specifications for representing and exchanging linked data between applications are maintained and developed by the OASIS consortium. Maximo® Asset Management supports version 2.0 of the OSLC core specification that you can enable and extend with Maximo Integration Framework.

OSLC specifications define how lifecycle applications represent, link to, and access resources based on established internet and linked-data standards including representational state transfer (REST) architecture, resource description framework (RDF) specifications, and hyper-text transfer protocol (HTTP) methods. Specifications are designed to be minimal in nature to address common integration use cases and integrators can extend these specifications or add new ones to address specific integration scenarios. The Maximo Asset Management OSLC core specification focuses on general requirements and a number of additional specifications represent the resources for particular functional domains, such as change management, or requirements management.

Maximo Asset Management is configured as an OSLC provider with the following components:

• The provider application makes data resources available for integration based on integration object structures that include the primary business object and any associated child business objects.
• OSLC resource shape documents describe resource objects in RDF/XML format. A shape document indicates what are the required characteristics of a resource and can also describe many aspects of the resource object, including its dependencies, attributes, and properties. A resource shape document can include links to the shape documents for any child objects of the resource.
• Resources are grouped by functional domain. Functional groupings can be based on the existing domain specifications that are developed and maintained by the OASIS OSLC group. Integrators can extend these existing domain specifications or create additional domain specifications to support business requirements.
• The resources in a domain are made available to consuming applications through service providers.
• A single service provider is supported for each domain. Service providers support the OSLC creation factory and query capability operations that provide consuming applications with the URI to create or search supported resources.
• The security framework supports authentication and authorization for OSLC services. Native and J2EE authentication are supported. Authorization control is provided by the object structure for a resource and application-level and user-based authorization are applied.

An OSLC consumer uses the following HTTP methods and header information to interact with the OSLC provider:

• Sends a GET request to perform login if explicit login is required and includes an authorization property in the HTTP header if native authentication is used. If explicit logout is required, a GET request is also used.
• Sends GET requests that include OSLC query parameters to a service provider URI to query OSLC resources.
• Sends a POST request to create an instance of an OSLC resource. The request includes a JSON document that conforms to the published shape document for the OSLC resource. When the resource instance is created, the OSLC provider sends a HTTP response that includes the URI for the new resource.
• Sends a PUT or PATCH request to update an OSLC resource. A PUT request updates the entire resource. A PATCH request updates part of the resource.
• Uses entity tags (ETags) in HTTP headers to ensure that a resource entity is current and can combine ETags with If-Match headers in PUT and PATCH requests to enable conditional updates.
• Can request stable paging in GET requests for collection resources so that the response redirects the consumer application to a URI where multiple pages are loaded. For collection resources, performance improves because the consumer application can load stable pages without accessing the database for each page.