Integrating > Open Services for Lifecycle Collaboration (OSLC) > Linking System Architect and non-IBM products > Technical specification for System Architect as provider for non-IBM products
  
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 provider resource
http://open-services.net/bin/view/Main/OslcCoreSpecification#Service_Provider_Resources
MUST
System Architect: Yes
Service providers MUST provide a service provider resource (http://open-services.net/ns/core#ServiceProvider) for clients to discover service endpoints.
Absolute URIs
http://open-services.net/bin/view/Main/OslcCoreSpecification#OSLC_Defined_Resource_Representa
MUST
System Architect: Yes
Service providers MUST use absolute URIs for all references to resources by properties.
RDF/XML format
http://open-services.net/bin/view/Main/OslcCoreSpecification#OSLC_Defined_Resource_Representa
MUST
System Architect: Yes
Service providers MUST provide RDF/XML representations for all resources. Service providers MUST accept valid GET requests with application/rdf+xml Accept headers.
HTTP REST services
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Operations
MUST
System Architect: Yes
Service providers MUST provide standard HTTP based REST services using standard HTTP responses for resource access.
HTTP REST services
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Operations
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.
HTTP If-Match use
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Operations
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.
MUST
System Architect: No
Resource Query Capability
http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities
Service providers MUST support a query interface for oslc_am:Resource resources.
MUST
System Architect: Yes: Limited see below
Authentication
http://open-services.net/bin/view/Main/OslcCoreSpecification#Authentication
Service providers SHOULD provide at least one OSLC Core recognized form of authentication (Basic, Form, or OAuth).
SHOULD
System Architect: OAuth
Link Type Query Capability
http://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities
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.
SHOULD
System Architect: No
Delegated selection UI
http://open-services.net/bin/view/Main/OslcCoreSpecification#Delegated_User_Interface_Dialogs
Service providers SHOULD support the OSLC Core 2.0 Delegated UI specification for resource selection of oslc_am:Resource resources.
SHOULD
System Architect: Yes
Error format
http://open-services.net/bin/view/Main/OslcCoreSpecification#Error_Responses
Service providers SHOULD support the OSLC Core 2.0 common error response format.
SHOULD
System Architect: Yes
Paging of queries
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Paging
Service providers SHOULD support paging of query results.
SHOULD
System Architect: No
HTTP resource PUT/DELETE
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Operations
Service providers SHOULD support resource modifications with standard HTTP PUT and DELETE methods. Service providers MAY limit modifications in any way they want.
SHOULD
System Architect: No
Service provider catalog
http://open-services.net/bin/view/Main/OslcCoreSpecification#Service_Provider_Resources
Service providers MAY organize services they provide on a context or project basis and use the OSLC define catalog resource to organize them.
MAY
System Architect: Yes
Creation Factory
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Operations
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.
MAY
System Architect: No
Ignore unknown content
http://open-services.net/bin/view/Main/OslcCoreSpecification#Unknown_properties_and_content
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.
MAY
System Architect: No
Partial update
http://open-services.net/bin/view/Main/OSLCCorePartialUpdateDRAFT
Service providers MAY support partial updates of resources.
MAY
System Architect: No
Paging of resource properties
http://open-services.net/bin/view/Main/OslcCoreSpecification#Resource_Paging
Service providers MAY page the results of a GET on an AM resource that contains a large number of properties.
MAY
System Architect: No
Selective properties
http://open-services.net/bin/view/Main/OslcCoreSpecification#Selective_Property_Values
Service providers MAY support selective properties on resource GET calls.
MAY
System Architect: No
Delegated creation UI
http://open-services.net/bin/view/Main/OslcCoreSpecification#Delegated_User_Interface_Dialogs
Service providers MAY support the OSLC Core 2.0 Delegated UI specification for resource creation.
MAY
System Architect: No
Basic authentication
http://open-services.net/bin/view/Main/OslcCoreSpecification#HTTP_Basic_Authentication
Service providers MAY support standard HTTP Basic authentication.
MAY
System Architect: No
Oauth authentication
http://open-services.net/bin/view/Main/OslcCoreSpecification#OAuth_Authentication
Service providers MAY support OAuth authentication.
MAY
System Architect: Yes
Form authentication
http://open-services.net/bin/view/Main/OslcCoreSpecification#Form_Based_Authentication
Service providers MAY support standard HTTP Form based authentication.
MAY
System Architect: No
Query
The System Architect provider supports queries in the following format:
http://SASERVER:8889/SAOSLC/query/SQL/LogicalServername/EncyclopediaName/1?oslc.where=*=<SA Resource URL>&oslc.select=*
This format ensures that a consumer can determine the links from System Architect to a given URL.
Accept headers
The System Architect provider recognizes the following accept headers:
application/rdf+xml, application/x-jazz-compact-rendering, application/x-oslc-compact+xml,application/xhtml+xml,text/html.
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.
Root services document (service provider catalog)
Service provider document
Service document
XML/RDF for a resource
See also
Linking System Architect and non-IBM products