Technical specification for System Architect as provider for non-IBM products
The following technical specifications show how System Architect can provide resources for linking and how it complies with the Open Services for Lifecycle Collaboration (OSLC) protocol.
The root services URL typically has the following format:
http://server_name:8889/SAOSLC/rootservices
The port is configurable by the local administrator. The preferred server name format is fully qualified host name. For example, the server name can be
testserver123.acmeinc.com
Authentication
The System Architect provider supports the OAuth protocol.
A request for a protected resource results in a HTTP 401 (forbidden) with the header “WWW-Authenticate: OAuth”. This error is an indicator for the client to start the OAuth process and obtain the access token for requesting protected resources. You can obtain the URLs for the request/access token and authorization steps from the root services document.
As part of the protocol, the user must authenticate in the second step of OAuth dance and the supported scheme is NTLM.
OSLC compliance
The table below contains links to specific areas of the Open Services for Lifecycle Collaboration Core Specification Version 2.0.
Service providers MUST provide a service provider resource (http://open-services.net/ns/core#ServiceProvider) for clients to discover service endpoints.
Service providers MUST provide RDF/XML representations for all resources. Service providers MUST accept valid GET requests with application/rdf+xml Accept headers.
Service providers MUST provide standard HTTP based REST services using standard HTTP responses for resource access.
MUST
System Architect: Yes
If service providers support update and delete of resources MUST support the standard HTTP If-Match header in PUT and DELETE for concurrency protection of resources.
If service providers support update and delete of resources MUST support the standard HTTP If-Match header in PUT and DELETE for concurrency protection of resources.
Service providers SHOULD support a query interface for oslc_am:LinkType resources that support a GET for all link type resources. Such a GET does not require any simple query syntax parameters. Service providers MAY support the full query syntax for Link Type resources.
Service providers SHOULD support resource modifications with standard HTTP PUT and DELETE methods. Service providers MAY limit modifications in any way they want.
Service providers MAY provide creation factories for resource formats that it supports. Service providers MAY support creation factories for OSLC AM defined resources formatted as application/rdf+xml. Service providers MAY support creation factories for other formats, and will indicate such with a non-default identifier in the oslc:usage property of the creation factory definition in the service provider document.
Service providers MAY ignore unknown content, including link types that have not been registered with the server. Providers MAY discard such properties and continue the POST or PUT operation without warning to the client.
The System Architect provider does not support the oslc.properties URL parameter on a HTTP GET request on individual resource request or a collection of resources by query.
Examples of System Architect responses
The sections below contain code samples of various document types, including root services, service provider, service, and XML/RDF for a resource.