Service Types
Service Type Description
The following table describes the full range of SIF 3 Service types provided to SIF 3 service consumers. They are distinguished in a consumer request by the value of the “serviceType” HTTP Header Field.
Service Type | Description | HTTP Header servcieType value |
---|---|---|
Object Service | An Object Service relates to a service of a specific data object. A data object is typically defined in a locale’s data model and is made up of a self-contained collection of XML/JSON data elements. Its format is standardized in an XML Schema that is part of the locale-specific Data Model rather than the SIF 3 Infrastructure. The Data Object Service is the “authoritative source” for all data elements contained in all data objects of a specific type. Each Object Service has a well defined set of REST endpoints. Please refer to the Open API page for more details on each locale’s specific endpoint definition. For details of the object definition (XML/JSON elements) please refer to the locale’s specific SIF Data Model Specifications page. | serviceType = OBJECT This is the default if not provided by the service consumer |
Utility Object | A Utility object is also a self-contained collection of XML/JSON data elements. Its format is standardized in an XML Schema that is defined by the SIF 3.x infrastructure and is independent of any locale-specific Data Model. The Utility Service (and by implication the Environments Provider which often implements it) is the “authoritative source” for all data elements contained in all Utility Service objects of a specific type. For further details refer to the Utility Services page. | serviceType = UTILITY |
Named eXtended Query | eXtended Query technology is used to standardize the way in which Query Responses can be defined to meet important service consumer requirements. When the token representing an Named eXtended Query is specified in a Query Request, the Response can do some or all of the following:
The format of the Named eXtended Query Response is specified in an XML schema such as object in the data model or one specifically defined to match that eXtended Query. In terms of validation however, all elements of the schema are generally considered optional. In addition, the inclusion of the template itself in the Data Model binding standardizes how the defined elements of the Response must be produced. For further details refer to the Named eXtended Query page | serviceType = XQUERYTEMPLATE |
Service Path | Service Paths are predefined URL segments that are used to optimize Consumer Queries in important use cases, by expressing object joins succinctly. For example, a Query made to a URL containing “sections/1234/students” will return all Students enrolled in Section 1234. Such Service Paths are typically defined as part of the of a locale’s specific Data Model. Each locale is responsible to define and publish its supported service paths. The XML schema defining the formats of the objects contained in the Response payload is determined by the last segment of the Service Path (“students” in this case.). | serviceType = SERVICEPATH |
Functional Service (Job Object) | A Functional (or Job Object) Service encapsulates stateful process behavior as well as the data exchanged between applications implementing that process. It does this by supporting some or all of the methods of a Data Object Service Provider interface but applying them to educational processes such as StudentLocator and EndOfYearRollover rather than Object data elements. When a service consumer issues a “Create” request to a Functional Service, it results in the creation of a new executing instance of the Function (a “Job Object instance”) rather than a new Data Object. From a conceptual point of view, each Job instance contains a set of named “phases”, identical to every other Job created by that Function Service. These discrete phases define and encapsulate the sub-actions that need to be done, but they do not explicitly determine the ordering (since the phases defining a Function may be executed in different order, depending upon the implementation and the needs of the site where the Functional Service is deployed). Once created, the Job instance can be queried to find out where in the process it is (what is happening, what is the current status of each completed phase) and the Job may issue Events as its internal phases are completed. Each Job Phase is represented by:
The creator of the Job can therefore:
| serviceType = FUNCTIONAL |
Privacy Service | The Data Protection Enforcer Service applies those data protection obligation rules to a payload which are appropriate for the given consumer and provider. It operates as a filter, and invoking it is optional in SIF implementations—although SIF implementations are expected to observe the rules captured in Privacy Obligation Documents somehow. The Data Protection Enforcer Service requires Service Consumers to obtain a token (Data Privacy Marker) associated with the latest form of the applicable Privacy Obligation Document, and to include it with their request. The service will confirm that the Data Privacy Marker is current (which can be used to cache responses), and if so, will apply the current Privacy Obligation Document ruleset to the submitted payload as a filter. | serviceType = SERVICE |
Supported Functionality
Verious service types support a number of functional concepts such as events, delayed request/response, batch operations etc. This table below summarises which core concepts and functionality each service type supports. This is intended as a overview only. Additional details can be found in respect sections.
CRUD: (C)reate, (R)ead, (U)pdate, (D)elete.
NA: Not applicable
Functionality | OBJECT | SERVICEPATH | FUNCTIONAL | XQUERYTEMPLATE | UTILITY | SERVICE |
---|---|---|---|---|---|---|
CRUD Operations - Single Object | C,R,U,D | NA | C,R,D on Service, C,R,U,D on Phase | NA | Depends on service. |
|
CRUD Operations - Batch | C,R,U,D | R | C,R,D | R | Depends on service. |
|
Events | Yes | No | Yes | No | Yes |
|
Query By Example (QBE) | Yes | No | No | NA | No |
|
DELAYED Request/Response | Yes | Yes | Yes | Yes | No |
|
Admin Directives Support | Yes | No | Yes | No | No | No |